다음을 고려하여TCP_USER_TIMEOUT에 대한 설명:
값이 0보다 큰 경우 TCP가 해당 연결을 강제로 닫고 애플리케이션에 ETIMEDOUT을 반환하기 전에 전송된 데이터가 승인되지 않은 상태로 유지될 수 있는 최대 시간(밀리초)을 지정합니다.
그리고RFC의 이 의견:
매우 짧은 USER TIMEOUT 값은 지연 시간이 긴 경로를 통한 TCP 전송에 영향을 미칠 수 있습니다. 패킷 손실로 인해 미해결 세그먼트에 대한 승인이 도착하기 전에 사용자 시간 초과가 발생하면 연결이 닫힙니다. 많은 TCP 구현에서는 기본적으로 USER TIMEOUT 값을 몇 분으로 설정합니다. UTO 옵션을 사용하면 짧은 시간 초과를 제안할 수 있지만 이를 광고하는 애플리케이션은 이러한 효과를 고려해야 합니다.
2ms의 TCP_USER_TIMEOUT은 치명적인 결과를 가져올 것으로 예상됩니다. RTT가 2ms 미만인 네트워크에서는 전송된 모든 TCP 패킷이 ACK를 기다리는 동안 시간 초과되어 연결이 닫힙니다. 그러나 내 환경에서는 이러한 현상이 발생하지 않습니다. 연결이 설정되고 데이터가 정상적으로 전송 및 수신됩니다. 그러나 코드를 당기거나 수신 인터페이스를 아래로 내리면 TCP_USER_TIMEOUT이 연결 손실을 효과적으로 감지하고 적시에 연결이 닫히는 것을 알 수 있습니다. 따라서 TCP_USER_TIMEOUT이 작동하고 있지만 예상한 대로 작동하지 않습니다.
TCP_USER_TIMEOUT에 대해 내가 무엇을 오해하고 있습니까? RTT보다 낮은 값으로 인해 연결이 끊어지지 않는 이유는 무엇입니까?
도움이 된다면 제 클라이언트는 2.6.32 커널이 포함된 Scientific Linux 6.1 상자입니다.
답변1
Linux의 UTO 구현은 부정확했으며 최근 이 패치 세트로 수정되었습니다.(이 패치 세트의 작성자가 아닌 경우를 대비해): https://lkml.org/lkml/2018/7/18/1090
그러나 UTO가 발생한 후에도 호스트는 재전송을 중지하고 TCP_CLOSE 상태로 이동하지만 연결을 재설정하지 않습니다. RST를 보내는 것은 애플리케이션의 책임입니다.