Flow Control
상대와 나와 버퍼 크기를 맞추어가면서 받을 수 있는 상황에만 상대방이 보내도록 하는 것이
Flow control
!
TCP header 안 receive window 항목에
현재 버퍼에 받을 수 있는 만큼의 공간인 rwnd
부분 value 를 채워서 상대에게 보내고,
상대는 최대 그만큼의 데이터만 보내게 된다.
→ 따라서 buffer overflow 가 일어나지 않음 !
초기에는 receive window 에 RcvBuffer 사이즈가 설정되고 (일반적으로 4096)
이후에는 받을 수 있는 만큼(rwnd 값)을 receive window 에 보내면서 흐름 제어 !
Congestion Control
한 번에 너무 많은 데이터를 보내면 네트워크에 문제가 생길 수 있다.
→ 그래서 한 번에 너무 많이 보내지 못하도록 제어하는 것이 Congestion control
!
flow control 과 다르다. (밀접하게 관련 있지만)
flow control 은 window size 를 가지고 상대방이 받을 수 있는만큼 보내는 것이고, (종단간)
congestion control 은 종단 뿐 아니라 중간 라우터들도 관여하게 됨 !
라우터가 처리할 수 있는 데이터의 양은 물리적으로 한정되어 있다.
버퍼가 가득차서 패킷이 loss 되기도 하고, 받지 못함으로 인해 패킷 재전송이 일어나면서
중복 패킷이 발생하기도 한다.
이로 인해 효율성이 떨어지고 계속해서 혼잡한 상태가 되는 것을 막고자 제어를 해줘야 한다.
additive increase, multiplicative decrease
네트워크가 혼잡하지 않을 때는 window size 를 조금씩 늘리다가,
네트워크 전송량이 많아져 혼잡해지게 되면 window size 를 확 줄이는 접근법
TCP 데이터를 보낼 수 있는 비율 (sending rate) 은
cwnd / RTT 로 계산할 수 있다.
cwnd 가 클수록 데이터를 많이 보낼 수 있지만, RTT 가 크면 클 수록 데이터를 많이 보내기 어렵다.
Slow Start
처음엔 cwnd 를 MSS (Maximum segment size) 로 설정한다.
이후 window size 를 두배로 늘려 두 개의 segment 를 한번에 보낸다.
이런 식으로 계속해서 두배씩 늘려나가다보면 timeout 에 걸려서 loss 가 생기는 시점이 있다.
loss 가 생기면 바로 cwnd 를 1 MSS 로 변환시킨다.
또는 triple duplicate ACKs
이 발생하면 cwnd 를 줄인다.
triple duplicate ACKs : 3번 연속 동일한 ACK 이 발생하면 못 받은 것으로 간주하는 것
cwnd 를 줄이는 것에도 두 가지 방법이 있다.
- TCP RENO : window size 를 절반으로 줄이는 방법
- TCP Tahoe : window size 를 1 로 줄이는 방법
결국 평균적인 TCP throughput 은 약 3/4 * window size/RTT 정도가 된다.
혼잡 상황이 발생되면
네트워크 전송이 되다가 혼잡한 상황이 되면,
중간에 라우터가 IP header 의 ToS
필드 안 ECN
비트로 표시를 한다.
TCP destination 이 받아서 ECN
비트가 켜져있다면 TCP ACK segment 에
ECE
비트나 CWR
비트를 켜서 Sender 에게 응답을 전송 !