TCP Overview
- point-point : 1 sender, 1 receiver
- Connection-oriented : Handshaking
- full-duplex data : bi-direction
- flow controlled: sender는 receiver를 보며 전송량을 조절
- reliable, in-order byte steam : 데이터는 순서대로 윗계층으로 옮겨지며, 바이트로 처리하기 때문에 message의 크기를 신경쓰지 않음
- pipelined : congestion, flow control이 window size를 결정
TCP segment structure
TCP sequence number, ACKs
-
TCP sequence number
- TCP에서 sequence number는 segment의 data만큼 증가함
- 예) pkt의 크기가 8byte일 때, seg num은 1, 9, 18, 25,,,, 순으로 증가
- TCP에서 sequence number는 segment의 data만큼 증가함
-
TCP ACKs
-
내가 너로부터 받기를 예상하는 ACK 번호
-
위의 그림처럼 ACK는 해당 pkt의 다음 seq num을 보내줘야함
-
TCP RTT, Timeout
- timeout을 어떻게 정해야할까?
- Too short : 불필요한 재전송이 잦아질 수 있음
- Too long : 너무 느린 전송이 될 수 있음
- Estimate
- k번째 Estimated RTT를 구하려면 k-1번째의 RTT에 k번째 sampling한 RTT를 더해주면 됨.
- 하지만 이를 바로 timeout에 적용하면 안됨 이는 평균값이기 때문에 실제와 크게 다를 수 있음. 따라서 표준편차를 더해줘야함.
- 그럼 DevRTT는 어떻게 구할까?
TCP : retransmission scenarios
- lost ACK scenario
- premature timeout
- retransmission에 대해 마지막으로 받은 pkt의 ACK를 보내줌으로서 둘 다 제대로 받았음을 알림
- ACK covers
- TCP에서 ACK는 누적됨. 위의 그림처럼 pkt은 정상적으로 받았지만, ACK가 소실된 경우 receiver는 두 pkt 모두 잘 받았다는 의미로 최근 수신받은 pkt에 대응되는 ACK를 전송
TCP : Fast retransmit
- Fast retransmit은 timeout이 되기 전에 중복된 ACK를 3번 받으면 해당 pkt을 재전송하는 방식이다.
- Timeout을 기다릴필요없이 빠른 송수신이 가능함.
TCP : Flow control
- Flow control : sender의 데이터 송신속도와 receiver의 수신속도의 차이로 인해 (송신속도에 비해 수신속도가 느릴 경우) 발생하는 buffer’s full로 data loss를 방지하기 위함.
- Receiver는 sender를 control함으로서 data loss를 방지함.
- Receiver는 TCP header에 있는 rwnd(r-window)의 공간에 자신의 여유버퍼상태를 표시함
- RcvBuffer는 socket의 옵션에 따라 정해짐 (일반적으로 4096bytes) → OS가 조정
- rwnd는 receiver의 버퍼가 overflow가 생기지 않음을 보장
TCP connection management
- Data 교환전에 sender-receiver는 서로 누구인지를 확인한다. → Handshaking
- 2-way handshaking은 신뢰성있는 연결을 하기에 불안정해서 보통 3-way handshaking을 함 (sender, receiver, network)
Principle of congestion control
- congestion : 수 많은 source들이 pkt을 너무 많이 보내서 생기는 교통체증 (수강신청, 티켓팅)
- 문제점 :
- long delay : router에 있는 buf queueing delay
- pkt loss : router buf보다 큰 pkt
Senario 1
- Router는 Infinite buf를 가지고 있음
- 두 host는 R/2의 처리량을 가짐 → 가장 이상적임
Senario 2
- Router는 finite buf를 가지고 있음. pkt loss 및 timeout에 의한 retransmit 발생 O
- 가장 이상적인 방법은 Host가 Router’s buf의 상태를 파악하여 이용가능할 때만 보내는 것
- Sender가 pkt loss 여부를 알아서 lost pkt만 보내주면 됨
- 위와 같은 상황으로 인해 이상적인 throughput인 R/2보다 낮은 처리량을 보임
- 이는 loss 발생으로 인함
- sender는 timeout으로 인한 duplicated pkt도 전송할 수 있음
- 이로 인해 위의 그림보다 더 처리량이 낮은 모습을 보임
⇒ 이상적인 처리량 R/2보다 낮은 원인은 pkt loss로 인한 retransmit, timeout으로 인한 delay
TCP congestion control : AIMD
- Additive Increase, Multiplicative Decrease
- segment size를 하나씩 늘려가면서 전송하다가 어느 부분부터 loss가 발생 → 일정비율 (1/2, 1/3, 등)로 전송량을 줄임
- 더할때는 하나씩, 줄일때는 확확
- 이 과정을 반복하면 네트워크 처리량에 수렴하여 제어가능
TCP congestion control : slow start
- 전송량을 2의 배수로 증가 → exponential
- 일정 구간(ssthresh)을 지나 pkt loss 발생하면 선형으로 증가시킴 → linear
TCP fairness
- Goal : 전체적인 대역폭을 공평하게 사용해야함
- 초반에는 slow start 방법을 사용하여 임계점(ssthresh)을 찾은 후에 AIMD 방식을 사용하여 점진적으로 조절함
- 이렇게 하여 fair하게 사용할 수 있음
- Q : 과연 모든 네트워크를 공평하게 사용해야할까?
A : No! multimedia app (동영상, 음악 등)은 UDP를 사용함. UDP는 flow, congestion control을 신경쓰지 않음
