TCP KeepAlive(소켓 옵션 SO_KEEPALIVE)는 세 가지 옵션, 즉 메커니즘을 트리거하는 시간, 프로브 간격, 연결이 중단된 후 실패했다고 선언할 프로브 수에 의해 제어됩니다.
기본값은 다음과 같습니다.
- tcp_keepalive_time = 7200
- tcp_keepalive_intvl = 75
- tcp_keepalive_probes = 9
9번의 프로브 실패 후 실패를 선언하는 것처럼 1/4분 후에 프로브를 보내는 것이 합리적으로 들리지만 초기 생각은 무엇이었습니까?2시간?
심지어TCP(7)설명하다
기본 연결 추적 메커니즘과 애플리케이션 시간 초과는 훨씬 더 짧을 수 있습니다.
Keepalive를 활성화하는 주요 목적은 상태 저장 네트워크 요소가 상태 정보를 삭제하는 것을 방지하는 것입니다. 그러나 이러한 요소는 몇 번 내에 연결을 끊는 경향이 있습니다.분. 속도가 제한된 일부 서버의 경우 curl짧은 시간이 --keepalive-time다운로드 안정성을 크게 향상시키는 것으로 보입니다.
그렇다면 기본값이 왜 이렇게 긴 걸까요?
답변1
TCP 연결 유지는 방화벽(상태 저장 방화벽이나 NAT는 물론)의 개념이 아직 널리 보급되지 않았을 때 정의되었습니다. ~에서RFC 1122(1989년 10월):
4.2.3.6 TCP 연결 유지
구현자는 TCP 구현에 "연결 유지"를 포함할 수 있지만
이 방법이 보편적으로 허용되는 것은 아닙니다
. 연결 유지가 포함된 경우 애플리케이션은
각 TCP 연결에 대해 연결 유지를 열거나 닫을 수 있어야 하며
기본적으로 닫힘으로 설정되어야 합니다.Keep-alive 패킷은 특정 시간 간격 내에 연결에 대한 데이터 또는 승인 패킷이 수신되지 않은 경우에만
전송되어야 합니다 . 이 간격은 구성 가능
해야 하며
기본값은 2시간 이상이어야 합니다..
[...]
당시 주요 아이디어는 상태 정보 손실에 관한 것이 아니었습니다.
설명: 연결이 유휴 상태일
때 전송할 데이터가 없더라도 "연결 유지" 메커니즘은 연결의 다른 쪽 끝을 주기적으로 조사합니다. TCP 사양에는 다음과 같은 이유로
연결 유지 메커니즘이 포함되어 있지 않습니다 .
(1) 짧은 인터넷 중단 동안 양호한 연결을 방해합니다
. (2)
불필요한 대역폭을 소비합니다("아무도
연결을 사용하지 않으면 연결 상태가 양호한지 누가 신경쓰나요?")
. 인터넷 접속에는 비용이 든다.
[...]
TCP 연결 유지 메커니즘은
서버 애플리케이션 내에서만 호출해야 합니다. 그렇지 않으면 네트워크 장애 중에 클라이언트가 충돌하거나 연결을 중단하는 경우 서버 애플리케이션이
무기한 중단되고 불필요한 리소스를 소비할 수 있습니다.
업데이트된 RFC를 살펴봤지만 연결 유지에 대한 좋은 언급이 없습니다.