[network] TCP의 신뢰성 확보를 위한 Timeout 한방정리 / Fast Retransmission

tcp는 통신과정의 신뢰성을 확보하기 위해 패킷에러와 패킷유실에 대해 대처한다. 그 중에서 패킷의 유실을 처리하기 위한 메커니즘으로 타이머를 이용한다.

 

타이머를 통한 패킷유실 처리 원리와 타이머의 시간이 얼마로 설정되는지에 대해 알아보자

 

Packet loss 대처

- timer

만약 sender가 패킷을 보내고 receiver에게 도달하기도 전에 패킷이 유실되었다면 어떻게 될까. receiver는 자신에게 어떤 패킷도 오지 않았으므로 그저 침묵이 흐를 것이다. 이러한 경우에 대비하기 위해 timer를 사용한다. timer를 통해서 일정시간동안 feedback이 오지 않을 경우 패킷이 유실되었다고 판단하여 재전송을 한다.

 

- timer의 시간설정 문제

그렇다면 timer의 시간은 얼마로 설정해야 할까? 결론만 말하자면 정답은 없다. ‘적당히’ 설정해야 한다. 짧으면 무조건 좋을까? 만약 짧다면 네트워크 상황으로 인해 패킷이 약간 지연될 경우 오는 도중에 timer가 터져서 재전송이 진행될 수 있다. 정말로 패킷유실이었다면 빠른 대처가 되는 것이지만 그렇지 않을 경우에는 중복된 패킷으로 인해 네트워크 상황만 더 혼잡하게 만드는 가능성이 있다. 너무 길면 통신 자체가 원할하지 않을 수 있겠다.

 

TimeOut Value

timeout의 값은 어떻게 설정해야 할까? 일단 segment가 전송이 되었다가 되돌아오는 시간인 RTT(Round trip time)을 기준으로 한다. 하지만 RTT는 패킷마다 다르고 같은 경로를 지나간다고 하더라도 네트워크 상황에 따라 라우터에서 발생하는 queueing daley 등으로 인해 RTT가 달라질 수 있다. 즉 RTT는 상황에 따라 천차만별이다. 따라서 현재시점까지의 RTT 샘플을 계산하여 고려한 EstimatedRTT를 사용한다.

 

EstimatedRTT = (1-a)*EstimatedTRR + a*SampleRTT

 

하지만 EstimatedRTT를 사용하면 타임아웃의 기준이 다소 빡빡할 수 있다. 그래서 실제 tcp통신에는 Deviation(편차)의 4배 정도를 더한 값으로 사용한다.

 

TimeOut Value = EstimatedRTT + 4*DevRTT

 

RTT를 기준으로 하되 마진을 더해주는 느낌이다.

 

 

Fast Retransmission

timer가 터지기 전에 패킷의 유실을 판단할 수 있는 tcp의 권고사항이다. tcp는 cumulative ack를 사용하기 때문에 만약에 중간에 10번째 패킷이 유실되었다면 그 이후에 보내진 패킷들에 대해 모두 ack10이라는 피드백을 받을 것이다. 하지만 10번째 패킷이 다소 늦게도착해서 먼저 도착한 11,12,13…번째 패킷에 대해 ack10을 받은 것일 수도 있다. tcp에서는 3번의 duplication ack를 받은 경우 즉 4번의 같은 ack를 받은 경우 유실로 판단해도 좋다고 권고하고 있다. 이는 tcp의 필수구성 요건은 아니며 timer의 optimizaion이다.