TCP 송/수신 원리

 

1. Client에서 요청을 받으면 데이터를 파일 시스템을 통하여 MemoryBuffer로 읽어옴 
   이때 메모리 버퍼 크기는 개발자가 정할 수 있다.
   
   
2. Memory Buffer에 담긴 데이터를 TCP Buffer로 복사한다. (Buffered I/O)
   Memory Buffer는 보통 64KB이다. (Window Size 개념이 있는데 송신 측도 관련 있는진 모르겠다.)
   
   
3. TCP Buffer에 담긴 데이터를 Segment화한다.(더 잘게 쪼갠다)
   이때 데이터 순서를 의미하는 id번호를 부여한다. = Packet
   
   
4. L2로 내려가게 되면서 Frame화 된다.
5. Frame을 전송하게 되면 같은 프레임으로 온다는 보장은 없다.
   택배도 판매점 - 서울 전달하는 택배기사님이 있고, 서울-부산, 부산-구매자 집으로 전달하는 택배기사님이 다 다른 것과 같은 개념
   Server가 Frame을 전송하고 난 후부터는 Client 측의 ACK신호를 받기까지 wait 한다.
   
   
6. NIC(Network Interface Card = 랜카드)를 통하여 전달받아 프레임을 벗겨냄
   
   
7. Packet 번호를 확인하여 TCP Buffer에 쌓는다.
8. Server측에 데이터를 잘 받았고 다음 패킷을 달라는 요청(ACK)과 함께 자신의 Window Size 정보를 함께 보낸다.
   Window Size는 Memory Buffer의 Size이며 TCP Header에 포함된다. 2^16 byte정도로 최대 64KB 정도 되며 통신상태에 따라 바뀐다.(=Sliding Window)
   ACK 신호를 받은 Server측은 Client의 Window Size를 읽고, 내가 보낼 다음 패킷(Segment?)의 크기가 Window Size보다 크다면 데이터를 전송하지 않고 wait 한다.
   즉, 처음에 수신된 Segment의 크기가 TCP Buffer(Window Size)에 담겨있고, 이 데이터를 처리하지 않고 Buffer에 남아있다고 가정하면 Server 측에서는 전송할 패킷이 Window Size보다 크기 때문에 wait를 하게 되고 이것은 시간지연으로 이어진다.
   그러므로 Client에서 9번 TCP Buffer -> File I/O Buffer로 처리가 늦어지면은 Window Size는 줄어들고 Server 측에서도 wait를 하게 된다.
   그래서 통신에서 버퍼링 같은 것이 Server 측의 느린 응답에 그럴 수도 있지만 Client측에서 데이터처리가 늦어서 그럴수도 있다.
   
   
9. TCP Buffer -> File I/O Buffer 복사

 

더 찾아봐야 할 점

1. Memory Buffer를 보통 64KB 잡는데, 그렇다면 컴퓨터마다 메모리 크기가 다를 수 있는데 client가 request 할 때 초기 window size 값을 보내는가?

2. 7번에서 세그먼트를 받고 ACK신호를 보내고 8번이 이루어지는 게 맞는가? 그렇다면 Window Size가 2번째 패킷부터는 64KB보다 항상 작은 건가?

3. Server 측에서 Client의 Window Size가 전송할 패킷보다 작으면 wait 한다고 했는데, 그렇다면 수시로 Window Size를 보내달라고 요청하는가? 아니면 Window Size가 패킷보다 커질 때 신호를 다시 달라고 하는가?

4. Socket 원리

5. 어렵다.

 

 

참고

https://www.youtube.com/watch?v=K9L9YZhEjC0

---

알고리즘으로 우연히 보게 되었는데, 이론으로 어느 정돈 알고 있었는데 Window Size개념은 처음 보는 거 같다.

버퍼링이 잘못된 데이터 전송, 서버가 느림, 클라이언트의 처리가 느리기 때문이라 생각은 했지만 Window Size로 wait를 하는 건 처음 알았다. 사실 Sliding Window를 정처기 시험 때 주관식으로 나왔던 건데 잊고 있었다.