요약

  • TCP keep-alive 프로브는 유휴 피어에게 자신의 시퀀스 상태에서 응답해 달라고 요청합니다. 다만 애플리케이션 전반의 정상 여부를 증명하지는 않습니다.
  • ACK만으로 구성된 세그먼트는 신뢰성 있게 전달되지 않으므로, 프로브에 응답이 없다고 해서 연결이 끊어졌다고 결론 내리기에는 부족합니다.

오랜 시간 동안 어떤 세그먼트도 도착하지 않고 보낼 새 데이터도 미확인 데이터도 없으면, TCP 연결은 조용한 채로 남을 수 있습니다. 이 침묵은 애플리케이션이 정상이며 전달할 내용이 없다는 뜻일 수도 있고, 경로나 피어가 더 이상 접근 가능하지 않다는 뜻일 수도 있습니다. keep-alive는 바로 이 경계에서 작동하여, 수립된 시퀀스 상태에 대한 한 번 더 관찰을 요청합니다.

이 메커니즘은 재전송을 대체하지 않습니다. 미확인 상태로 보낸 데이터가 남아 있는 동안 TCP에는 이미 재전송과 User Timeout이 있어 전달 지속 여부를 판단합니다. keep-alive는 연결이 그 외의 면에서 유휴일 때에만 시작됩니다.

RFC 1122는 시퀀스 번호가 보통SND.NXT-1, 즉 새 데이터에 쓰일 다음 옥텟 바로 앞인 프로브를 설명합니다. 자신의 TCP 상태를 유지하고 있는 피어는 이를 근거로 응답할 수 있습니다. 프로브는 데이터를 실어서는 안 되며, 데이터 없는 형태를 올바르게 처리하지 못하는 결함 있는 구현을 위해 1옥텟 호환 형태가 허용될 수 있습니다. 이는 전송 계층 제어 평면의 교환이지, 일반적인 애플리케이션 메시지가 아닙니다.

keep-alive는 선택 사항입니다. 구현한다면 애플리케이션이 연결별로 켜거나 끌 수 있어야 하고, 기본값은 꺼진 상태여야 합니다. 프로브는 미확인 상태로 보낸 데이터가 더 이상 남아 있지 않고, 설정된 간격 동안 데이터나 확인 응답이 도착하지 않았을 때만 보낼 수 있습니다. 이 간격은 구성 가능해야 하며, 규범적 기본값은 2시간보다 짧을 수 없습니다.

RFC 9293은 RFC 1122의 결정적인 제약을 그대로 유지합니다. TCP는 ACK만 담은 세그먼트를 신뢰성 있게 전송하지 않습니다. 피어는 프로브를 받고 기대한 확인 응답을 생성할 수 있지만, 그 응답은 경로에서 사라질 수 있습니다. 따라서 특정 프로브에 대한 무응답만으로는 고장의 증거가 되지 않습니다. 규범의 통합 역시 이 메커니즘을 보편적인 가용성 서비스로 바꾸지는 못했습니다.

출처