요약

  • 재전송 시간은 언제 다시 보낼지 결정하고, USER TIMEOUT은 언제 연결을 끊을지 결정한다.
  • RFC 5482는 상대방의 선호를 전달하지만, 로컬 한도와 CHANGEABLE이 통제권을 수신 측에 유지한다.

재시도와 포기는 같은 시계를 쓰지 않는다

유용한 응답이 도착하지 않으면 재전송 타이머가 만료되고 TCP는 큐 맨 앞의 세그먼트를 다시 보낸다. 그다음 그 타이머를 다시 시작한다. 이 사실만으로 애플리케이션이 연결을 얼마나 오래 유지할 의사가 있는지는 알 수 없다.

USER TIMEOUT은 정확히 이 두 번째 질문에 답한다. RFC 793은 이를 전송된 데이터가 TCP를 중단하기 전까지 제대로 전달되지 않은 채 머물 수 있는 한도로 설명했다. RFC 9293은 두 사건을 명확히 구분한다. 재전송 타이머 만료는 첫 세그먼트를 재전송하고 타이머를 재시작하고, USER TIMEOUT 만료는 큐를 비우고 중단을 알리고 TCB를 제거하며 연결을 CLOSED로 이동시킨다.

따라서 두 시계가 서로 다른 결정을 가리킬 수 있어도 모순은 없다. 지속성 예산이 이미 끝났는데도 또 한 번 시도를 예약하는 것은 여전히 가능하다. RTO는 왕복 시간과 손실 관측에 맞춰 재시도 간격을 조정한다. USER TIMEOUT은 상태, 버퍼, 그리고 전달에 대한 불확실성이 얼마나 오래 허용 가능한지를 표현한다.

이는 애플리케이션 요청의 기한이 아니기도 하다. 애플리케이션은 작업을 취소하면서 연결을 유지할 수도 있고, 미전달 데이터를 더 이상 전달할 수 없게 되면 연결 전체가 사라져야 할 수도 있다.

초 또는 분 단위로 인코딩된 제안

원래 이 값은 로컬 것이었다. 한 끝점은 중단의 영향을 받은 연결을 상대방이 얼마나 유지하고 싶어하는지 알 수 없었다. RFC 5482는 TCP User Timeout 옵션을 도입해 이 기대값을 전달했다.

이 옵션은 Kind 28, Length 4를 사용한다. granularity 비트 하나가 초 또는 분을 선택하고, 나머지 15비트가 제안된 구간을 담는다. 1초부터 9시간 이상, 또는 1분부터 22일 이상까지 표현할 수 있다.

제안은 상대방을 안내할 뿐, 중단을 명령하지는 않는다. RFC 5482가 정의한 상태에는 USER_TIMEOUT, ADV_UTO, ENABLED, CHANGEABLE이 있다. ENABLED는 기본적으로 꺼져 있으며 옵션의 송신과 처리 여부를 제어한다. CHANGEABLE은 수신한 값이 로컬 USER_TIMEOUT을 바꿀 수 있는지 결정한다.

애플리케이션이 기한을 정했고 CHANGEABLE이 거짓이라면, 원격 값이 이를 대체할 수 없다. 그래도 TCP는 수신한 제안을 애플리케이션에 알려야 한다. 정보는 연결을 넘어가지만, 권한은 넘어가지 않는다.

한도는 설계의 일부다

구현은 상한과 하한을 설정해야 한다. 지나치게 작은 값은 느린 경로나 일시적 중단을 지나는 연결을 끊을 수 있다. 지나치게 큰 값은 메모리와 상태를 너무 오래 유지해 자원 고갈 위험을 키운다. 인증과 상대별(per-peer) 한도가 가능한 완화책이다.

옵션이 없다고 해서 USER TIMEOUT이 존재하지 않는다는 뜻도 아니다. 미지원 수신자는 이를 조용히 무시할 수 있고, TCP 옵션 공간의 한계로 송신자가 옵션을 담지 못할 수도 있다. 또한 방화벽이 끝점보다 먼저 상태를 지울 수도 있다. 패킷 캡처는 그 시점에 제안이 존재했다는 것만 증명하며, 이를 채택했거나 중간 장비가 살아남았다는 증거가 아니다.

keepalive가 활성화된 경우, 그 타이머는 채택된 USER_TIMEOUT보다 커야 한다. keepalive는 유휴 연결의 생존을 점검하고, USER TIMEOUT은 미전달 데이터의 지속성을 다룬다. 둘은 같은 메커니즘이 아니다.

RFC 5482는 로컬 정책을 한도가 있는 선호로 가시화했다. 기대값을 조율하면서도 중단 시점의 소유권은 상대방에 넘기지 않았다.

출처