연결지향형 트랜스포트(TCP) - 왕복시간(RTT) 예측과 타임아웃(timeout)

TCP의 손실 세그먼트에 대한 처리 : 타임아웃/재전송 메커니즘

 

왕복시간(RTT, round-trip time) : 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간

RTT는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함.

ex) 사용자가 하이퍼링크를 클릭했을 때 발생하는 일

1. 클릭 - 브라우저가 브라우저와 웹 서버 사이에서 TCP 연결을 시도 (three-way handshake를 포함 - 클라이언트가 tcp 메시지를 서버로 보내고, 서버가 메시지로 응답 후 마지막으로 클라이언트가 다시 서버에 응답, 이 중 핸드셰이크 중 처음 두 단계가 경과하면 한 RTT가 계산됨.)

2. 핸드 셰이크의 처음 두 과정이 끝난 후, 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 핸드셰이크의 세 번째 부분(응답)을 함께 보냄. 

3. 요청 메시지가 서버에 도착하면 서버는 HTML 파일을 TCP 연결로 보냄. 이 HTTP 요청/응답이 또 하나의 RTT를 필요로 함

총 응답 시간 : 2 RTT + HTML 파일 전송 시간

 

 

타임아웃 주기

타임아웃은 연결의 왕복시간(RTT)보다는 커야 함.

 

왕복시간 예측

TCP가 송수신자 간 왕복시간(RTT, rount-trip time)을 예측하는 방법

SampleRTT(세그먼트에 대한 RTT 샘플) : 세그먼트가 송신된 시간(IP에게 넘겨진 시간)으로부터 그 세그먼트에 대한 긍정응답이 도착한                                                                 시간까지의 시간 길이

대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행함. (어떤 시점에서 SampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정되고, 이는 대략 왕복시간마다 SampleRTT의 새로운 값을 얻게 함)

또한 재전송한 세그먼트에 대한 SampleRTT는 계산하지 않고, 한 번 전송된 세그먼트에 대해서만 측정함.

SampleRTT값은 라우터에서의 혼잡과 종단 시스템에서의 부하 변화 때문에 세그먼트마다 달라 불규칙적임.

대체로 RTT를 추정하기 위해서 SampleRTT값의 평균값(EstimatedRTT)을 채택하고 TCP는 이 평균값을 유지함.

TCP는 긍정 확인응답을 수신하고 새로운 SampleRTT를 획득하자마자 다음 공식에 따라 EstimatedRTT를 갱신함.

EstimatedRTT = ( 1 - α ) * EstimatedRTT + α * SampleRTT

즉, 새로운 EstimatedRTT 값은 EstimatedRTT 이전 값과 SampleRTT에 대한 새로운 값의 가중된 조합으로 표현

권장되는 α의 값은 α = 0.125(1/8) [RFC 6298]이며, 이러한 경우 아래와 같은 공식을 사용

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT

EstimatedRTT는 SampleRTT값의 가중평균(weighted average)이고 가중평균은 예전 샘플보다 최근 샘플에 높은 가중치를 주어, 

최근의 샘플들이 네트워크상의 현재 혼잡을 더 잘 반영함.

이러한 평균을 통계에서 지수적 가중 이동 평균(exponential weighted moving average, EWMA)라 함.

SampleRTT의 가중치가 갱신 절차가 진행됨에 따라 빠르게 지수적으로 감소하므로 EWMA에서 "지수적(exponential)"이라 명칭

RTT 샘플과 RTT 추정치

위 그림은 gaia.cs.umass.edu(매사추세츠 주 애머스트)와 fantasia.eurecom.fr(프랑스 남부) 사이의 TCP 연결에 대한

α = 0.125(1/8)의 값에 대한 SampleRTT 값들과 EstimatedRTT를 보여 준다. 

SampleRTT의 변화율(variation)은 EstimatedRTT 계산에 의해 완만하게 된다.

 

RTT의 예측 외에도 RTT의 변화율을 측정하는 것도 매우 유용한데, [RFC 6298]은 RTT 변화율을 의미하는 DevRTT를 SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 예측으로 정의한다.

DevRTT = ( 1 - β ) * DevRTT + β * | SampleRTT - EstimatedRTT |      ( β 권장값 : 0.25 )

DevRTT는 SampleRTT와 EstimatedRTT 값 차이의 EWMA로, SampleRTT값에 변화가 없다면 DevRTT는 작을 것이고, SampleRTT의 변화가 크다면 DevRTT도 클 것이다. 

 

재전송 타임아웃 주기의 설정 및 관리

주어진 EstimatedRTT와 DevRTT의 값에서, TCP 타임아웃 주기에는 어떤 값이 사용되어야 할까?

타임아웃 주기는 EstimatedRTT보다는 커야할 것이다. (그렇지 않으면 불필요한 재전송 발생 가능성 높음)

그러나 타임아웃 주기가 EstimatedRTT보다 너무 크면 세그먼트를 잃었을 때, 재전송이 느려져 데이터 전송 지연 문제 발생함.

그러므로 EstimatedRTT + safety margin(약간의 여유 값) 으로 설정하는 것이 바람직한데,

SampleRTT값에 많은 변동이 있을 때는 safety margin이 커야 하고, 변동이 작을 때에는 safety margin이 작아야 한다.

이 safety margin의 역할을 DevRTT의 값이 하게 되어 아래와 같이 재전송 타임아웃 주기를 결정한다.

TimeoutIntervral = EstimatedRTT + 4 * DevRTT

초기 TimeoutInterveral의 값으로 1초를 권고[RFC 6298]하고, 타임아웃이 발생할 때, TimeoutInterval의 값을 두 배로 하여 확인응답 할 후속 세그먼트에게 발생할 수 있는 조기 타임아웃을 방지한다. 이후 세그먼트가 수신되고 EstimatedRTT가 수정되면 TimeoutInterval은 다시 위 공식에 따라 계산된다.

 

 

 

참고 도서 :

컴퓨터 네트워킹 하향식 접근 - 제7판