Flow control
Flow control: process 사이 데이터를 주고 받을 때 receiver의 능력에 맞게 보내는 것
- receiver buffer가 받을 수 있는 available space만큼만 보내는 것
- TCP segment의 header에 receiver buffer size field 정보를 담음
보내는 속도 vs 보내는 양?
- 속도: 10Mbps 1초동안 얼마의 데이터를 보낼 것인가
- 보내는 양이 크면 보내는 속도도 빨라짐
- 즉, flow control은 전송량을 제한하여 전송속도도 낮춤
receiver buffer 남은 공간 없을 때
- B의 receiver buffer에 빈공간이 하나도 없으면 즉, 0바이트면 A는 send를 멈춰야함
빈공간이 생겼을 때 A가 어떻게 알 것인가? - 해결방법: A는 주기적으로 data가 없는(의미 없는) segment를 보냄
-> 그래야 B가 ACK를 보내 B의 상태를 알 수 있음 - flow control은 매우 중요한 기능이지만 receiver가 공간이 얼마나 남았는지를 알려주므로 구현은 단순
Connection management
- 자신의 sequence number를 상대방에게 주어야 함
- 상대방의 sequence number를 받아와야함
- = connection establishment
- connection을 만드는 동작 과정
TCP 3-way handshake
- 3번 왔다갔다해서 TCP 3-way handshake
- SYN Packet: client가 tcp connecion 열고 싶다는 의사표현을 함
- sequence number를 상대방에게 알려줌
- syn=1: TCP connection을 열고 싶다는 의사표현
- SYN ACK
- syn=1
- sequence number상대방에게 알려줌
- ack
- SYN ACK에 대한 ACK
- syn=0
- 데이터를 포함할 수 있음
- 3-way handshake를 사용하는 이유
- 2 way handshake를 사용하는 경우 client는 받으나 server 입장에서는 확실하지 않음
Closing TCP connection
- client가 FIN이라는 segment를 보냄
- server가 ACK를 보냄
- server도 보낼 데이터를 다 보내고 FIN을 보내면 종료
- client가 ACK를 보냄
- 둘다 FIN을 해도 timed wait동안 몇 초동안 기다림
- 만약, ACK가 유실되면 timeout되고 다시 보내야하는데 closed되면 다시 ACK를 보내줄 수 없음
Congestion control
- receiver의 능력치 고려 -> flow control - network의 능력치 고려 -> congestion control
- TCP는 네트워크 막혀있으면 재전송 -> 더 막힘악화
- -> network 막히면 안됨
- -> data 보내는 속도를 감소
Network 상황이 좋은지 안 좋은지 어떻게 아는가?
1. End-end congestion control
- end system들로 내부의 네트워크 상황을 유추하는 방식
- key: TCP segment
- ACK로 유추
- segment를 보냈는데 ACK가 느리게 오거나 안옴
- 아주 정확하지는 않음
2. Network-assisted congestion control
- network(router)에서 직접 네트워크 상황에 관한 정보를 주는 방식
- 실제로는 구현되지 않는 방식
- 라우터
