[Networks] TCP timers
/*
TCP에 존재하는 타이머들에 대해서 작성한 글입니다
*/
Retransmission Timer, Persistence Timer, Keepalive Timer, TIME-WAIT Timer에 대해서 알아보겠습니다.
Persistence Timer(영속 타이머)
교착 상태(Deadlock)를 해결하기 위하여 사용되는 타이머입니다. 송신자 측에서는 수신자 측으로부터 rwnd가 0이라는 ACK을 받음과 동시에 이 영속 타이머를 동작하게 됩니다.
타이머가 만료될 때까지 수신자 측으로부터 rwnd가 갱신이 되지 않았다면, 송신자 측은 수신자에게 '아직도 rwnd 0이야?'라는 느낌의 probe 세그먼트를 보내게 됩니다. 수신자 측에서 이 probe 세그먼트를 받게 되면, 이 세그먼트에 대한 ACK과 함께 rwnd를 보내게 되는데, 여기서 넘어오는 rwnd 값으로부터 수신자 측의 rwnd가 갱신이 되었는지를 확인할 수 있게 됩니다.
- 교착 상태 : 수신자로부터 ACK과 함께 온 rwnd가 0일 때, 송신자는 수신자 측의 receiving buffer에 자리가 날 때까지, 즉 rwnd가 0이 아닐 때까지 데이터 송신을 멈춥니다. 수신자 측에 자리가 생겨 rwnd를 갱신하는 ACK을 보냈는데 이 ACK이 사라져서, 송신자 측은 여전히 rwnd가 갱신될 때까지 기다리고 수신자 측은 송신자 측에서 데이터를 보내줄 때까지 기다리는, 즉 서로 기다리는 상황에 빠지게 됩니다. 이를 교착 상태, Deadlock에 빠졌다고 합니다.
Keepalive Timer
이미 연결된 서버와 클라이언트 사이에 오랜 시간동안 아무 상호작용이 일어나지 않는 긴 휴지상태(Long idle time)에 빠지는 것을 방지하기 위해 사용되는 타이머입니다.
Keepalive timer는 서버 측에서 사용하는 타이머입니다. 클라이언트로부터 데이터가 올 때마다 Keepalive Timer는 초기화되게 됩니다. 클라이언트로부터 데이터를 마지막으로 받은 시점으로부터 특정 시간(리눅스 환경에서는 2시간)이 지나게 되면 클라이언트에게 Probe 세그먼트를 보냅니다.
- Idle Time : 서버와 클라이언트가 TCP로 연결이 되어 있으며 데이터를 주고 받다가 클라이언트 측에서 비정상적인 방법으로 종료를 하게 되면, 서버 측에서는 클라이언트가 종료된지 모르기 때문에 서버와 클라이언트 사이의 연결이 아직 유효하다고 여겨 연결을 유지할 것입니다. 유효하지 않은 연결이 계속해서 이어지는 이 상황을 휴지 상태(Idle Time)라고 합니다.
TIME-WAIT
연결 종료 요청을 하는 쪽(대부분 클라이언트 쪽)이 연결 종료 후에 2MSL 만큼을 기다리는데 사용하는 타이머입니다. TIME-WAIT 타이머가 만료되면 Close 상태로 바뀌게 됩니다.
이 타이머를 사용하는 이유는 다음과 같습니다.
- 서버가 보낸 FIN에 대한 클라이언트 측의 ACK이 lose 되면 서버는 계속해서 FIN을 보낼 것이기에, 2MSL 만큼을 기다리며 Packet Lose로 인해 생길 수 있는 문제를 대비합니다.
- TIME-WAIT 없이 바로 Close 상태로 가게되면, 새로 생기는 연결이 방금 종료된 연결과 동일한 소켓 주소를 가질 수 있습니다. 이렇게 되면 서버 측에서는 기존 연결과 새로운 연결을 구분할 수 없기 때문에 세그먼트가 꼬이게 될 수도 있습니다. 이를 방지하기 위해 Time-WAIT 타이머를 사용하여 2MSL이라는 충분한 시간동안 기다렸다가 종료합니다. 새로운 연결이 해당 소켓의 주소를 사용하지 못하게 하기 위함입니다.
Retransmission Timer(RTT)
Packet Loss를 detect 하기 위한 타이머입니다. 3 duplicative ACKs 보다 빠른 Packet Loss를 detect 할 수 있다는 장점이 있습니다. 이 타이머가 만료되게 되면 송신자 측은 수신자 측이 해당 패킷을 받지 못했다고 간주하고 패킷을 retransmission 합니다.
RTO란 Retransmission Timer의 Time out 값을 의미합니다. 즉 Timer가 만료될 때까지의 시간을 의미합니다.
RTO = RTTs(RTT의 평균) + 4 * RTTd(RTT의 편차) 와 같은 식으로 정의됩니다. 이와 같이 특정값들에게 각자의 가중치를 두어서 더하는 방식을 EWMA 방식이라고 합니다.
Smoothed RTT(RTTs)
초기값 => RTTs에는 아무값도 설정되어 있지 않습니다.
첫번째 측정 이후 => RTTs에는 첫번째 측정값 RTTm이 설정되게 됩니다.
그 후 => RTTs = (1-α)RTTs + αRTTm 으로 정의됩니다.
α = 1/8
RTT Deviation
초기값 => RTTd에는 아무 값도 설정되어 있지 않습니다.
첫번째 측정 이후 => RTTd에는 첫번째 측정값 RTTm의 절반 값이 설정되게 됩니다.
그 후 => RTTd = (1-β)RTTd + β|RTTs-RTTm| 으로 정의됩니다. 편차의 평균값(RTTd)에 3/4, 방금 측정한 값의 평균과의 편차(|RTTs-RTTm|)에 1/4을 곱하는 것으로 보아 RTTd 역시 기존의 편차 평균값에 더 높은 비중을 두는 것을 확인할 수 있습니다.
β = 1/4
<첫번째 측정 전>
RTO Default Value = 6.0 (시스템마다 상이)
RTTm, RTTs, RTTd에는 어떠한 값도 설정되어 있지 않습니다.
<첫번째 측정 후>
RTTm = 1.50
RTTs = RTTm = 1.50
RTTd = 1/2 * RTTm = 0.75
RTO = RTTS + 4 * RTTd = 1.5 + 4 * 0.75 = 4.5
이미 RTT 측정이 시작되었다면, 즉 RTO 타이머가 시작되었다면 그 후 보내는 데이터들에 대한 RTT 측정은 하지 않습니다.
<두번째 측정 후>
RTTm = 2.5
RTTs = 7/8 * RTTs + 1/8 * RTTm = 7/8 * 1.5 + 1/8 * 2.5 = 1.625
RTTd = 3/4 * RTTd + 1/4 * |RTTs - RTTm| = 3/4 * 0.75 + 1/4 * 0.875 = 0.78
RTO = RTTs + 4 * RTTd = 1.625 + 4 * 0.78 = 4.74
위를 정리하여 그림으로 나타내면 위 그림과 같습니다.
Karn's Algorithm : 재전송되는 패킷에 대한 RTT 값을 없데이트 하지 말자! 정상적인 패킷에 대한 ACK이 돌아올 때부터 측정 시작!
(a)와 같이 Sender 측에서 보낸 패킷이 loss 돼서 retransmission 하였을 때 정상적으로 ACK이 돌아오는 경우, 즉 정상적인 경우에는 retransmission을 보낸 시점부터 ACK이 돌아온 시점까지의 RTT 값을 RTTs, RTTd ,RTO를 업데이트 하는데 사용해도 문제가 없습니다.
하지만 (b)를 보면 Original Transmission이 loss 된게 아니라 가고 오는 시간이 오래 걸려서 RTO가 지났음에도 Original Transmission에 대한 ACK이 돌아올 때 문제가 됩니다. Sender 측에서는 RTO 가 지났으므로 Retransmission을 보냈는데 이 Retransmission에 대한 ACK이 아닌 Original Transmission에 대한 ACK이 곧바로 들어왔을 때 Sender 측에서는 이 두 ACK을 구분할 수 없게 됩니다. 여기서 측정된 RTT 값을 업데이트 하는데 사용해버리면 RTO의 정확도를 떨어뜨릴게 분명합니다. 그렇기에 Karn's Algorithm에서는 이러한 retransmission으로 측정한 RTT값은 정상적이든(a) 비정상적이든(b) RTTs, RTTd, RTO 값을 업데이트 하는데 사용하지 않기로 정하였습니다.
위 그림에서 확인할 수 있는 점은 다음과 같습니다.
- Retransmission을 보낼 시 RTO 값은 기존의 값 * 2 로 설정됩니다. 이는 Retransmission에만 해당되는 RTO 입니다. 여기서 측정된 RTT 값은 업데이트에 사용되지 않습니다.
- Retransmission이 아닌 Original Transmission에서는 기존의 RTTm, RTTs, RTTd, RTO를 사용합니다.