TCP 2-way handshake의 문제점
client가 req_conn(x)를 보낸 후 acc_conn이 늦게 도착해 timeout되어 다시 재전송하는데, 이 재전송한 패킷이 모든 데이터 교환이 끝난 후 서버에 도착하여 half open connection이 일어나고, retransmit한 데이터로 duplicate data acception이 일어날 수 있다.
TCP 3-way handshake 과정
- client가 SYNbit=1과 random init seq num x를 보냄 (SYNbit=1, Seq=x)
- server가 init seq num y를 선택하고 TCP SYNACK 메시지를 보냄
(SYNbit=1, Seq=y, ACKbit=1; ACKnum=x+1) - server가 LISTEN 상태에서 SYN RCVD(received)상태로 전환
- client는 받은 SYNACK에 대해 ACKbit=1를 보냄, ACKnum = y+1
- server는 ESTAB상태로 전환
만약 retransmit req_conn이 늦게 도착하면 서버는 SYNACK패킷을 보내고 client는 RESET패킷을 보냄
connection 종료는 양측에서 FIN과 ACK를 주고받아야 끝남.
congestion control
- network-assisted: router provide direct feedback
- TCP ECN, ATM, DECbit protocol
- end-end congestion control
cwnd (congestion window)
cwnd는 tcp congestion control을 따르면서 혼잡도에 따라 동적으로 조정된다.
TCP rate(throughput) =~ cwnd/RTT (bytes/sec)
TCP congestion control: AIMD
additive increase, multiplicative decrease
- increase sending rate by 1 every RTT
- cut sending rate in half at loss(triple duplicate ACK)
어느 정도는 데이터가 도착했기 때문
= TCP Reno - cut to 1Maximum segement size(더 급격하게 줄임) when timeout
= TCP Tahoe
ssthresh값을 넘어서면 cwnd를 1만큼씩 증가
왜 AIMD방식을 쓰나?
-> TCP가 싱크를 맞추지 않고 각자 동작함, optimal함, stablity property들이 있음
TCP CUBIC
bottleneck link
결국 bottleneck link를 넘지 않도록 속도를 맞춰서 증가시켜야 한다.
그렇지 않으면 queuing이 발생하여 delay가 점점 증가한다.
-> just full enough, but no fuller
avoid hight delays, buffering
delay-based TCP congestion control
minimum RTT를 계속 측정하여 업데이트 = RTTmin
uncongested throughput = cwnd/RTTmin
measured throughput이 uncongested throughput에 가까우면 cwnd를 linear하게 늘림
measured throughput이 uncongested throughput보다 많이 낮으면 = RTT가 큰것 => cwnd를 linear하게 줄임
packet loss가 발생하지 않도록 하는
queue에 패킷들이 차지 않도록 하는
ECN = explicit congestion notification
network assisted congestion control임
router는 IP까지만 이해하고 TCP를 이해하지 않기 때문에, IP header의 2bit(ecn)를 사용
congestion이 일어난 곳에서 ECN비트값을 10-> 11로 바꾸어 destination으로 전송하면 목적지에서 TCP ACK segment중 ECE비트를 1로 설정하여 source로 보냄
