목차
2.1 송신 시 고정 길이 구조와 비고정 길이 구조의 차이점
2.2 그렇다면 불연속 메모리가 있는 구조체는 왜 send를 사용하여 직접 전송할 수 없습니까?
인터뷰 질문: 누가 더 안전한지, GET 방법 또는 POST
주로 응용 계층 과 전송 계층 에 대해 이야기합니다.
1. 맞춤형 프로토콜
응용 계층 에서 응용 계층 형식 에 대한 프로그래머 의 동의 입니다.
먼저 계산기의 웹 버전을 구현해 보겠습니다.
아이디어:
성취하다:
맞춤형 프로토콜이란 정확히 무엇입니까?
2. TCP 스티키 패킷 문제
tcp의 바이트 스트림 지향 특성으로 인해 tcp sticky 패킷 문제가 발생합니다.
수신자 에게는 데이터가 여러 번 전송되었는지 여부를 구분할 방법이 없으며 이전과 이후에 전송된 데이터는 스페이서가 없고 함께 접착됩니다.
2.1 송신 시 고정 길이 구조와 비고정 길이 구조의 차이점
2.2 그렇다면 불연속 메모리가 있는 구조체는 왜 send를 사용하여 직접 전송할 수 없습니까?
먼저 메모리 연속 구조의 전송 원리를 살펴보겠습니다.
가변 길이의 구조를 살펴보자
2.2 그러면 가변 길이의 데이터는 어떻게 받나요?
예를 들어 10바이트 한 번, 100바이트 한 번 데이터를 두 번 보내면 어떻게 받을까?
1.tcp는 데이터를 전송할 때 크기를 추가할 수 있습니다.
먼저 4바이트를 수신하고 데이터 패킷의 길이를 분석한 후 다음 내용을 수신합니다.
이것은 고착 문제를 해결합니다
2. 사용자 지정 구분 기호(\r\n)를 추가할 수도 있습니다.
2.3 불연속 메모리는 어떻게 받나요?
예를 들어, 이러한 종류의 데이터는 첫 번째 문자의 주소를 저장합니다.
이를 위해서는 직렬화 및 역직렬화가 필요합니다.
2.4 직렬화 및 역직렬화
직렬화: 프로그램의 데이터 구조를 이진 시퀀스로 변환합니다.
데이터 구조:
메모리가 연속적 이면 직접 보낼 수 있습니다. 예를 들어 구조의
메모리가 불연속 적인 경우 직렬화는 서로 다른 메모리를 결합하여 연속적인 공간에 넣고 내보내는 것입니다. 예: 연결된 목록의 여러 노드
Deserialization : 바이너리를 데이터 구조로 변환합니다.
3. HTTP 프로토콜
3.1 http 프로토콜 개요
하이퍼 텍스트 전송 프로토콜
3.2 HTTP의 URL 해석
전체 URL을 살펴보겠습니다.
계층이 있는 파일 경로:
쿼리 문자열:
URL의 각 부분에 대한 요약 :
3.3 HTTP 프로토콜의 데이터 흐름
먼저 알아야 할 사항: HTTP 프로토콜은 응용 계층 프로토콜이고 네트워크 프로토콜 스택에서 사용하는 하위 계층(전송 계층) 프로토콜은 TCP 프로토콜입니다.
간단히 말해서 HTTP 프로토콜에 의해 생성된 데이터는 전송 계층에서 TCP 프로토콜에 의해 전송됩니다.
3.4 HTTP 프로토콜의 형식
3.4.1 요청 형식
tcp를 사용하여 HTTP 서버를 시뮬레이트하여 브라우저에서 서버로 보낸 요청을 수락합니다.
코드는 이전 코드와 비슷합니다. 작업자 스레드의 기능을 살펴보겠습니다.
사이트에서 검색할 URL을 모방합니다.
현재 웹페이지로 메시지를 보내지 않아 웹페이지가 제대로 작동하지 않는 것으로 표시됩니다.
그러나 현재 웹 페이지에서 보낸 요청을 받았음을 알 수 있습니다. 다음은 요청 내용입니다.
이것이 무엇인지 분석하고 HTTP 요청 형식이 무엇 인지 분석할 수 있습니다.
요청의 첫 줄 : 요청 방법, 경로, 프로토콜 버전
3.4.2 응답 형식
이제 브라우저에 응답을 보내는 서버를 시뮬레이션합니다.
브라우저에서 서버에 요청을 보내고 받은 응답이 어떻게 보이는지 관찰합니다.
3.5 HTTP 요청 방법:
요청 방법은 GET 및 POST 에 중점을 둡니다.
GET: 일부 리소스를 삭제하도록 서버에 요청
PST: 서버에 데이터 제출
POST에서 제출한 데이터는 본문에 있습니다.
예: 사용자 이름=xxx&&passwd=xxx
예: 특정 웹 페이지에 로그인하려는 경우 POST 요청을 사용하면 제출을 위해 요청 본문에 계정과 비밀번호가 입력됩니다.
인터뷰 질문: 누가 더 안전한지, GET 방법 또는 POST
길:
리소스를 요청하려는 경로입니다.
프로토콜 버전:
HTTP 0.9, HTTP 1.0, HTTP 1.1 , HTTP 2.0(아직 개발 중)
현재 가장 많이 사용되는 HTTP1.1
3.6 요청 본문의 내용을 분석합니다.
요청 본문에는 많은 키가 있을 수 있습니다.
3.7 HTTP 응답 상태 코드
3.7.1 상태 코드가 필요한 이유는 무엇입니까?
브라우저는 HTTP 요청을 시작하고 웹 서버는 브라우저에 상태 코드(방금 시작된 요청이 성공적으로 처리되었는지 또는 실패했는지 여부)를 알려야 합니다.
일반적인 테스트 코드:
3.8 일반적인 HTTP 헤더
- Content-Length: 텍스트의 길이
- Content-Type : 본문의 유형
- location : 리디렉션 주소, 일반적으로 3 xx와 함께 사용됨
- Set-Cookie: HTTP 쿠키 설정
쿠키 및 세션
쿠키: 브라우저가 저장하는 정보는 일반적으로 클라이언트의 일부 둔감한 정보이며 쿠키 데이터의 출처는 서버에서 가져옵니다 .
브라우저에 저장합니다. 다음에 서버에서 리소스를 요청할 때
세션: 세션 데이터는 서버 측에 저장되며 일반적으로 현재 세션 정보(예: 브라우저 정보, 브라우저가 방문하는 페이지 등)를 설명합니다.
쿠키:
애플리케이션 시나리오:
이유: Baidu를 방문할 때 처음 로그인 해야 하지만 두 번째 는 다시 로그인할 필요가 없습니다.
처음 로그인할 때 로그인에 성공하면 Baidu 서버가 성공적인 로그인 응답을 브라우저에 반환하고 응답에 일부 쿠키 정보가 있기 때문입니다.
다음에 방문할 때 이러한 쿠키 정보를 가지고 다니게 되며, 서버는 이러한 쿠키 정보를 분석하여 누가 로그인했는지 알 수 있습니다.
코드를 사용하여 쿠키의 역할을 실험할 수도 있습니다.
당사 서버는 브라우저에 쿠키 정보를 반환합니다.
물론 여기에서 쿠키 정보 설정은 매우 임의적이며 웹 사이트의 쿠키 디자인은 매우 복잡합니다.