TCP Retransmission

본 포스팅은 개념에 대한 복습을 위해 작성되었습니다. 잘못된 내용은 댓글이나 이메일로 알려주시면 감사하겠습니다.

 

TCP Retransmission

  사실상 TCP 이야기가 나오면 항상 메인 토픽으로 다뤄지는 이야기가 있다. 바로 재전송 (Retransmission)에 관한 내용이다. TCP는 송신에 대한 응답이 오지않는 경우 일정시간을 대기 후에 다시 재전송을 한다. TCP Protocol 자체가 전송에 관한 Protocol이고 그 특성으로 Reliability를 갖고 있는 만큼 재전송에 대한 이야깃거리가 상당히 많다. 몇 가지 상황을 가정하고 TCP가 그 상황 위에서 어떻게 동작하는지 보자.

 

송신자는 패킷을 송신하고 나면 별도로 정의된 Timer를 시작한다. 그리고 Timer의 시간이 만료되면 다시 패킷을 전송한다. 기본적인 재전송 과정이다.

 

---

Retransmission : Packet lost

재전송이 발생할 수 있는 첫 번째 상황. 송신자는 패킷을 보냈지만, 어떤 이유에서인지 중간에 유실되어 수신측에 도달하지 못했다. 수신측은 당연히 패킷이 도착하지 않았으므로 ACK를 보내줄리가 없고, 송신자의 Timer는 만료된다.

 

Rrtransmssion : ACK lost

재전송이 발생할 수 있는 두 번째 상황. 송신자가 패킷을 보냈고, 수신 측 또한 응답으로 ACK를 보냈다. 그러나, 이번에는 중간에 ACK가 유실되어 송신자에게 도착하지 못했다. 송신자의 Timer는 만료된다.

 

Retransmission : Early Timeout

재전송이 발생할 수 있는 세 번째 상황. 송신자가 패킷을 보냈고, 수신 측에서 응답으로 ACK를 보냈다. 그러나, 네트워크 지연이 발생해서 송신자의 Timer가 만료되어버린 후에 ACK가 송신자에게 도착한다.

---

 

RTO (Retransmission Timeout) With RTT (Round Trip Time)

  위의 3가지 상황에서 공통점은 "Timeout 시간 안에 ACK를 받지 못했다."는 것이다. 여기서 Protocol이 할 수 있는 최선은 무엇일까? 바로 최선의 Timeout 시간을 정의하는 것이다. Timeout 시간이 지나치게 짧으면 재전송 패킷의 낭비가, 지나치게 길면 패킷이 손실되었을 때 기다려야하는 시간이 너무 길어진다. 어떤 기준을 통해서 정의된 적절한 시간이 필요한데, 그래서 RTO (Rtransmission Timeout)라는 개념을 사용하게 된다.

 

RTO는 운영체제 커널에 정의되어있다. 운영체제 별로 초기값을 갖고 있지만, 당연히 모든 네트워크 상황은 다르므로 RTO는 동적으로 변한다. RTO는 RTT에 의해서 변하는데, RTT는 호스트 간 송신에 대한 응답을 받기까지 걸리는 시간을 의미한다.

RTT를 측정된 RTT를 SampleRTT 라고 할 때,

 

어떤 Retranmission에 대한 ACK인지 송신자는 판단할 수가 없다.

송신자의 Original Transmission에 대한 ACK를 받기까지의 시간을 SampleRTT로 설정할 텐데, 재전송이 발생했을 경우, 응답해온 ACK가 Original에 대한 응답인지 재전송에 대한 응답인지 구분하기가 어렵다는 것이다.

---

 

Karn / Partridge Algorithm

그래서 SampleRTT는 안쓴다. 

는 아니고, 만약 RTO Timer가 만료되면 RTO 값을 2배로 늘린다. Exponential Backoff 라고 한다. SampleRTT는 안쓴다기 보다 송/수신이 완료된 전송에 대해서만 값을 기록하고, 이 값을 Computed RTO를 도출하는 데 사용한다.

 

Computed RTO

EstimatedRTT for computed RTO

 

이렇게 계산한다는 말인데... 위에 설명한 개념만 이해하면 되지 않을까? (...)

---

 

타이머가 최선일까 : Fast Retransmission

  재전송 방법에는 Timeout이 최선인 것 처럼 적었지만.. 사실 대안이 하나 더 있다. Triple-Duplicate-ACK 라고 하는데, 이름 그대로 3개의 중복된 ACK를 받으면 재전송하는 방법이다. 어떻게 보면 불필요한 시간 지연이 발생하지 않고, 수신자의 ACK를 일종의 타이머 처럼 사용하기 때문에 최대한 빠른 재전송을 시작할 수 있다.

 

화질이 별로다.

보이는 것 처럼 동작은 매우 직관적이다. A(128.1)는 신나서 B(62.97)에게 패킷을 뿌려주고 있지만, B는 됐고 23801 이나 빨리 내놓으라고 닥달한다.

 

한 번만 말해도 잘 알아듣자

 

---

 

Delayed ACK

응답을 위한 ACK 패킷을 줄이는 방법으로 효율적인 ACK 전송 방식을 이야기한다. 재전송을 ACK로 요청할 때, 들어오는 모든 요청에 대해서 ACK를 보내지 않고 정의된 Delayed ACK timeout 만큼 ( 보통 200ms ) 기다린다.

기다리는 도중에 패킷이 도착하면 다시 timeout을 초기화하고 만약, 어떠한 패킷도 받지 못한다면 그제서야 ACK를 보내준다.