아래영상을 보며 정리한 내용입니다. 
TCP/IP 연결(3-way handshake)은 되어있다 가정하고, File download를(Server to Client) 받는 상황을 가정해보자
- Web server 에서 socket이 열려 있으며 client에 접속중
- Servers는 Process, Socket은 File이며, Process가 File에게 할수있는 operation은 RWX이며, 소켓에 대해서는 RW만 할것이다. (소켓 통신엔 당연히 실행 개념 x)
- 소켓통신에서 RW는 다음과 같은 의미를 가진다. R: Receive, W: Send
- HDD에서 1.4MB 를 읽을때에는 프로그램에 할당된 Memory 단위 (ex 64kb)만큼씩 끊어서 읽게된다.
- Socket → TCP에서는 Socket Buffer와 TCP Buffer 각각 존재하고, Socket → TCP로 이동한다. Buffered I/O
- 꼭 이렇게 해야하는건 아니지만, 주로 이렇게 함
- 왜 이렇게 하는지는 할말이 많다… 크기를 어떻게 지정하는지도 할말이 많다…
- TCP → IP에서는 TCP memory에 있는 내용을 Segment 단위로 쪼갠다.
- 각 segment에 번호를 붙이며 쪼개짐
- Packet은 택배박스에 비유할 수 있다. 쪼개진 segment를 넣은
- 이 Packet이 Client쪽으로 전달되게 된다.
- 택배 배달부는 안에 내용물(Packet)은 관심없고, 트럭(FRAME, L2 level)으로 그대로 넣게된다.
- 트럭은 여러번 갈아타는 상황에서, 트럭의 목적지는 어디지?
- Client에 도착한 다른 트럭
- Frame은 Client의 IP에서 Packet (택배박스)
- TCP에서는 Packet(택배박스)를 까서 segment로 튀어나올것이다.
- 이 segment에서는 번호가 붙어있고, TCP Buffer에 원래대로 정돈된다.
- segment가 2개쯤 오면 조립을 하고 잘 수신했다고 서버에게 알린다. (ACK)
- ACK#3 : 1, 2번 잘받았다. 3번 달라
- 서버쪽에서는 ACK#3을 받은 후에야 3번을 보낸다. → 이거 떄문에 TCP가 UDP보다 느림
- Client TCP에는 아직 Buffer 여유가 있다. window size (수신측에서 segment를 날라오면 집어넣을 수 있는 공간)
- ACK#3에 window size를 포함하고 있다.
- 이 window size를 보고 3번 packet을 보낼까 말까 결정한다.
- window size > message size → 보낸다
- window size < message size → wait
- 주로 느리다는 것 → client TCP Buffer를 빨리 퍼올려서 Client Process로 보내야하는데 Client Process의 Receive 속도가 느린것
- Client Process Read 속도 < Network 수신 속도 → TCP Buffer의 여유가 점점 줄어든다.
- ⇒ window size를 check하면, application의 문제 원인을 파악하기 좋다.
- window size가 점점 줄어든다 → 네트워크 수신 속도보다 Client Process Read속도가 느린것 → Network가 아닌 프로그램이 문제이다