- [ ] 01 복습
- [ ] 02 복습
- [ ] 03 복습
01 프로토콜 스택에 HTTP 리퀘스트 메시지를 넘긴다.
- 연결이 성립되면, 애플리케이션은 프로토콜 스택에 송신할 데이터를 전달합니다.
- 이 때, 프로토콜 스택은 데이터의 내용은 모릅니다.
- 단지 송신 데이터의 길이 만큼의 바이너리 데이터가 1바이트씩 차례로 나열되어 있다고 인식합니다.
- 프로토콜 스택은 전달받은 데이터를 곧바로 보내지는 않습니다.
- 대신 송신용 버퍼 메모리 영역에 일단 저장합니다.
- 받은 데이터가 보내려는 데이터의 전부인지 모르기 때문입니다.
- 애플리케이션에 따라 한번에 전체 데이터를 전달할수도 있고, 나누어서 전달할 수도 있습니다.
- 그냥 받을 때마다 보내면 안될까요?
- 그러면 네트워크의 이용 효율이 떨어집니다.
- 극단적으로 1바이트씩 100번 보내는 것보다, 조금 기다려도 100바이트를 한번에 보내는게 네트워크 부하 측면에서 도움이 될 것입니다.
- 그러면 어느 정도까지 저장하다가 보내는 것일까요?
- OS 의 종류나 버전에 따라 달라집니다.
- 언제 보낼 지 고려에 포함되는 중요한 요소 두 가지가 있습니다.
02 데이터가 클 때는 분할하여 보낸다
- HTTP 리퀘스트 메시지는 보통 한 개의 패킷에 들어갑니다.
- 하지만 폼을 사용하여 긴 데이터를 보내는 경우, 한 개의 패킷에 들어가지 않을 수도 있습니다.
- 이 때 송신 버퍼에 저장된 데이터는 MSS 의 길이를 초과하므로, 다음 데이터를 기다릴 필요가 없습니다.
- 기다려봤자 어차피 최대 MSS 의 크기로 나누어서 보내야하기 때문입니다.
- MSS : Maximum Segment Size ( 데이터 조각 자체의 최대 크기를 가리킵니다.)
- MTU : Maximum Transmission Unit ( IP 헤더 + TCP 헤더 + 데이터 조각의 최대 크기를 가리킵니다.)
- 따라서 송신 버퍼에 들어있는 데이터들을 맨 앞부터 차례대로 MSS 의 크기에 맞게 분할하고, 한 조각씩 패킷에 넣어 송신합니다.
- 애플리케이션의 데이터는 HTTP 헤더 와 메시지 본문으로 구성되어 있습니다.
- TCP 는 이것을 MSS 크기의 조각으로 나누고 조각마다 TCP 헤더를 붙입니다.
- 여기서 내가 깨닫게 된 것은, 데이터를 분할 할 때, HTTP 헤더와 메시지의 경계의 구분 없이 나뉜다는 것입니다.
- 아래 계층으로 가면서 또 헤더를 하나씩 붙이게 됩니다.
- IP 헤더 + TCP 헤더 + 조각 데이터 = MTU의 크기 입니다.
- 이후 소켓에 기록되어 있는 제어 정보 ( 송신처 포트 번호, 수신처 포트 번호 등) 필요한 정보를 TCP 헤더에 기록하고 IP 담당부분에게 건네줍니다.
03 ACK 번호를 사용하여 패킷이 도착했는지 확인한다
TCP 는 신뢰성 있는 통신을 보장합니다.
- 즉, 상대에게 올바르게 도착했는지 확인하고 만약 도착하지 않았으면 재송신합니다.
- 이를 위해서 패킷을 보내고 확인하는 동작이 필요합니다.
확인 방법의 개념