[컴퓨터 네트워크] 14-3. TCP의 흐름제어(+ silly window syndrome), 오류제어, 혼잡제어

TCP flow control

• TCP에서는 수신 호스트의 수신 buffer overflow를 막기 위해서 송신 호스트와 수신 호스트 간의 흐름 제어를 진행한다.
• 송신 호스트의 응용 프로그램과 TCP 계층 간의 흐름제어도 존재하긴 한다.
• 흐름 제어를 위하여 송신 버퍼의 전체 크기를 수신 버퍼 크기에 맞춰주는 방법을 택할 수 있다.
• 이때, 수신 측이 ACK를 보내면서 포함한 rwnd크기에 송신자는 송신 버퍼 크기, 윈도우 크기를 조절하여 데이터를 송신한다.

 

Silly Window Syndrome

• silly window syndrome은 TCP의 성능 문제 중 하나로, 수신 쪽 응용 프로그램의 처리 속도가 너무 느리거나 송신 측이 지속적으로 작은 양의 데이터를 전송시킬 때 발생하는 문제다.
• 예를 들어서 송신 측이 느린 속도로 1 바이트씩 데이터를 처리하여 전송하는 경우, 데이터 1 바이트를 전송하기 위해서 IP 헤더 최소 20바이트, TCP 헤더 최소 20바이트가 붙는다. 1 바이트를 처리하기 위해서 40 바이트가 붙는 것은 굉장히 Overhead고, 네트워크 자원을 낭비하는 결과를 맞는 것이다.
• 이를 해결하기 위해서 송신 측에서 Nagle 알고리즘을 사용한다. 처음에는 응용 프로그램이 1 바이트만 송신해도 첫 바이트는 그대로 전송하고, 그다음에는 데이터를 누적시키면서 수신 측의 ACK를 받거나, MSS만큼 데이터를 채울 때까지 송신을 보류하는 것이다. 이로써 네트워크 속도와 응용 프로그램의 처리 속도를 맞출 수 있게 된다.
• 수신 측에서는 Clark method를 사용할 수 있다. 처음에 송신측으로부터 패킷을 받았을 때, 수신 즉시 ACK를 보내며 rwin(슬라이딩 윈도우) 크기를 0으로 셋팅하여 보내는 것이다. 이러면 수신 처리 속도가 늦음을 알리는 효과를 일으킨다.
• 이후 수신 측 응용 프로그램에서 데이터를 수신 버퍼에서 충분히 많이 ( 수신 버퍼의 1/2 이상 ) 가져갔을 때, rwin을 다시 넉넉하게 잡은 ACK를 송신 쪽에 보내면서 데이터를 다시 받아온다.
• 혹은 dealyed ACK를 사용할 수 있는데, 수신 즉시 ACK를 보내지 않고 수신 버퍼가 넉넉해질 때까지 지연시키는 방식이다.

 

Error control

• 데이터 전송 중 발생하는 에러를 검출하기 위해 checksum, ACK, time-out, 재전송과 같은 방법을 사용할 수 있다.

  ㅇ 빠른 재전송 (Fast Retransmission : Fast Recovery, Fast Retransmit)
     - 수신측으로부터의 궤환(재전송 요청) 형태에 기반을 두고,
        . 패킷 손실 추정
     - 지연 없이 바로 타임아웃, 즉각 재전송 실시
        . 즉, RTO(재전송 타임아웃 시간)을 끝까지 기다리지 않는 빠른 재전송

     * 주로, 빠른 재전송은, 중복 ACK에 의해 유발됨
        . 중복 ACK (Duplicate Acknowledgement)  :  하나의 원래 ACK와 중복된 ACK
           .. 일련의 세그먼트를 연이어 전송할 때, 중간 세그먼트가 손실되어 수신되면, 
           .. 수신측은, 모두 같은 순서번호인 중복 ACK를 발생시키며, 즉각 확인응답을 함
           .. 즉, 중복 ACK는, 순서 역전 및 중간에 뻥뚫린 구멍이 있음을 의미
        . 한편, 송신측은, 중복 ACK를 받으면, 이를 손실인지 지연인지를 구분키 위해,
           .. 수 개 정도(통상,3개) 기다림 (duplicate ACK threshold or dupthresh)

• 첫 번째로, Fast retransmission(빠른 재전송)이라는 방법은 송신 측이 중복된 ACK를 수신 측으로부터 여러개 받으면 TIME-OUT이 일어나기 전에 패킷을 빠르게 재전송하는 방법이다.

빠른 재전송 예시

• 빠른 재전송은 주로 수신 측의 중복된 ACK에 의해 발생한다.
• 위 그림처럼, Segment 4~7을 연달아서 송신 측이 보냈는데, 통신 오류 때문에 segment 4가 수신 누락 됐다고 가정하자.
• TCP는 패킷을 받을때 순서를 맞춰서 응용 프로그램으로 보내주기 때문에, 패킷 순서가 틀리면 안된다.
• 이때 수신 측은 모두 같은 순서 번호(sequence number)인 ACK를 발생시키면서 중간에 패킷 손실이 났음을 알린다.
• 송신 측은 중복 ACK를 받으면 이를 손실인지 지연인지 구분하기 위해 통상 3개 정도 패킷을 기다리다가, 타임 아웃이 일어나기 전에 재전송한다.

 

 

---

 

Lost Ack에 의한 Deadlock

 

packet loss에 의한 deadlock

• 위 그림처럼 deadlock이 발생하는 상황도 나타날 수 있다.
• 수신 측이 데이터를 받은 후, 수신 응용이 데이터를 처리하며 수신 윈도우가 다시 여유가 생겼다는 ACK를 송신에 보냈는데, 이 패킷이 loss된 것이다. 그러면 송신은 수신 측의 버퍼가 빈 것을 계속 모르고, 수신 측은 ACK를 보냈는데 왜 데이터를 더 보내지 않는가 계속 기다리기 때문에 deadlock이 발생한다.
• 이를 해결하기 위해서 송신 측에서 영속 타이머(persistence Timer)를 사용한다. ACK(rwin=0)를 수신측으로부터 받았을 때 타이머를 동작시켜서, 일정 시간 동안 수신 측으로 부터 여유의 rwin이 생겼다는 ACK를 받지 못하면 Probe 패킷을 보낸다.
• "너 진짜 아직도 rwin=0 맞냐?"라는 Probe 패킷을 받은 수신 측은 요청에 응답하는 패킷을 보내게 된다. 이후 오류가 제어된다.

 

 

TCP Congestion control

• 송신 윈도우 크기를 수신 윈도우 크기에 맞춰뒀다는 점을 기억하는가.
• 사실 수신자 버퍼 용량뿐만 아니라, 네트워크 용량도 고려해야 하는 부분이다.
• 수식으로 나타내면, swin = min(rwin, cwin)인데, cwin은 congestion window라고 한다.
• rwin를 조절하는 부분은 흐름 제어에서 하겠지만 cwin을 조절하는 부분은 혼잡 제어에서 한다.
• congestion window는 계산이 어려우며, 따라서 송신자가 추측을 한다. 이것이 congestion control의 목적이다.
• congestion window를 추측하는 방법으로는 slow start가 있다.
• 송신에서 cwin을 1,2,4, ... 2의 배수로 천천히 늘려서 수신 측에 패킷을 보내보는 것이다.
• 수신 측에서는 패킷 개수만큼 ACK를 보낼 것이다.
• 여기서 어느 순간 2의 배수로 보내지 못하는 순간이 올텐데, 이때부터는 congestion avoidance 방법으로 cwin을 (i+1)처럼 Linear하게 증가시켜서 congestion window를 추측한다.