서버가 끊겼습니다. 클라이언트의 TCP 연결이 아직 있습니까?

저자: 고바야시 코딩

컴퓨터 스테레오타입 에세이 웹사이트: https://xiaolincoding.com

안녕하세요 여러분 샤오린입니다.

"the server hangs"가 " the server process crashes " 를 의미하는 경우 , 서버 프로세스가 충돌할 때 커널은 FIN 메시지를 보내고 클라이언트에 4번 웨이브합니다.

그러나 "the server hang up"이 " the server host is down " 을 의미한다면 네 개의 손을 흔드는 일은 없을 것입니다. 다음에 무슨 일이 일어날까요? 또한 클라이언트가 데이터를 보낼지 여부에 따라 달라집니다.

클라이언트가 데이터를 보내면 서버가 더 이상 존재하지 않기 때문에 클라이언트의 데이터 패킷은 시간이 지남에 따라 재전송되고 재전송 횟수가 특정 임계값에 도달하면 TCP 연결이 끊어집니다.
클라이언트가 데이터를 전송하지 않는 경우 클라이언트가 TCP keepalive 메커니즘을 활성화했는지 확인하십시오.
- 활성화된 경우 클라이언트는 일정 시간 후에 서버의 TCP 연결이 더 이상 존재하지 않음을 감지한 후 자체 TCP 연결을 끊습니다.
- 활성화하지 않으면 클라이언트의 TCP 연결이 항상 존재하며 연결이 끊기지 않습니다.

위의 내용은 요약된 답변이므로 아래에서 자세히 설명하겠습니다.

서버 프로세스가 충돌하면 클라이언트는 어떻게 됩니까?

TCP 연결 정보는 커널에 의해 유지되므로 서버 프로세스가 충돌하면 커널은 프로세스의 모든 TCP 연결 리소스를 회수해야하므로 커널은 첫 번째 waving FIN 메시지를 보내고 후속 waving 프로세스도 커널 완성에는 프로세스의 참여가 필요하지 않으므로 서버 프로세스가 종료되더라도 클라이언트와 함께 TCP 4방향 웨이브 프로세스를 완료할 수 있습니다.

또한 프로세스 충돌을 시뮬레이션하기 위해 kill -9 명령을 사용하여 직접 실험을 수행했으며 프로세스를 종료한 후 서버가 클라이언트에 FIN 메시지와 웨이브를 4번 보냅니다 .

서버 호스트가 다운된 후 클라이언트는 어떻게 됩니까?

서버 측 호스트의 전원이 갑자기 꺼지면 서버 측 호스트가 다운된 경우입니다.

서버 호스트가 다운되면 클라이언트와 4번 웨이브할 방법이 없기 때문에 서버 호스트가 다운되는 순간 클라이언트는 서버 호스트가 다운된 것을 즉시 인지할 수 없습니다. 후속 데이터 상호 작용은 더 이상 존재하지 않습니다.

따라서 두 가지 경우를 논의해야 합니다.

서버 호스트가 다운된 후 클라이언트는 데이터를 보냅니다.
서버 호스트가 다운되면 클라이언트는 데이터를 보내지 않습니다.

서버 호스트가 다운된 후 클라이언트가 데이터를 보낼 경우

서버 호스트가 다운된 후 클라이언트는 데이터 패킷을 보냅니다.클라이언트는 응답을 받을 수 없기 때문에 일정 시간 동안 대기한 후 타임아웃 재전송 메커니즘을 트리거하여 응답을 받지 못한 데이터 패킷을 다시 전송 합니다 .

재전송 횟수가 특정 임계값에 도달하면 커널은 TCP 연결에 문제가 있음을 확인한 다음 소켓 인터페이스를 통해 응용 프로그램에 TCP 연결에 문제가 있음을 알리므로 클라이언트의 TCP 연결이 해제됩니다. 연결이 끊어졌습니다.

TCP 데이터 패킷은 몇 번 재전송됩니까?

Linux 시스템에서는 아래 그림과 같이 tcp_retries2라는 구성 항목이 제공되며 기본값은 15입니다.

이 커널 매개변수는 TCP 연결이 설정될 때 제한 시간 초과 재전송의 최대 횟수를 제어합니다.

단, tcp_retries2는 15번으로 설정되어 있는데, 이는 TCP timeout 재전송 15번 이후에 응용 프로그램이 TCP 연결을 종료하라는 알림을 받는 것이 아니라 커널이 tcp_retries2에서 설정한 값에 따라 시간 초과를 계산할 것입니다(tcp_retries2 =15인 경우 , 그런 다음 계산된 시간 초과 = 924600ms ), 재전송 간격이 이 시간 초과를 초과하면 임계값을 초과한 것으로 간주되어 재전송이 중지되고 TCP 연결이 끊어집니다 .

오버타임 재전송 과정에서 각 라운드의 RTO(Timeout Time)가 곱해지며 , 예를 들어 첫 번째 라운드의 RTO가 200밀리초라면 두 번째 라운드의 RTO는 400밀리초, 세 번째 라운드의 RTO는 800이다. 밀리초 등.

RTO는 RTT(패킷의 왕복 시간)를 기준으로 계산되며, RTT가 클수록 계산된 RTO도 커지게 되며, 여러 라운드의 재전송 후에는 곧 위의 타임아웃 값에 도달하게 됩니다.

예를 들어, tcp_retries2 =15이면 계산된 시간 초과 = 924600ms이고 총 재전송 간격이 시간 초과에 도달하면 재전송이 중지되고 TCP 연결이 끊어집니다.

RTT가 상대적으로 작은 경우 RTO의 초기값은 대략 하한값인 200ms, 즉 1라운드의 타임아웃 기간이 200ms이고 총 타임아웃 시간이 924600ms이므로 나타나는 현상은 다음과 같다. 단 15번의 재전송으로 제한 시간 값을 초과하여 TCP 연결을 끊습니다.
RTT가 상대적으로 크면 RTO의 초기값이 1000ms로 계산된다고 가정하면, 즉 1라운드의 타임아웃 기간이 1초라면 15번 재전송할 필요가 전혀 없고 총 재전송 간격은 924600ms를 초과합니다.

최소 RTO 및 최대 RTO는 Linux 커널에서 정의됩니다.

#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))

Linux 2.6+는 1000ms의 HZ를 사용하므로 TCP_RTO_MIN약 200ms는 TCP_RTO_MAX약 120초입니다.

tcp_retries로 설정하고 RTT가 상대적으로 작은 경우 15RTO의 초기값은 대략 하한값인 200ms와 같으며, 이는 상위 계층(즉, 응용 프로그램)에 알림을 보내는 데 924.6초가 걸린다는 것을 의미합니다. 연결이 끊어진 TCP 연결 각 라운드의 RTO 성장 관계는 다음과 같습니다.

서버 호스트가 다운된 후 클라이언트가 데이터를 보내지 않은 경우

서버 호스트가 다운된 후 클라이언트가 데이터를 전송하지 않은 경우 TCP keepalive 메커니즘(TCP keepalive 메커니즘)이 활성화되었는지 여부에 따라 달라집니다.

TCP keepalive 메커니즘이 활성화되지 않은 경우 서버 호스트가 데이터 전송에 실패한 후 클라이언트가 데이터를 전송하지 않으면 클라이언트의 TCP 연결이 항상 존재하므로 TCP keepalive 메커니즘이 사용되지 않는 시점을 알 수 있습니다. 그리고 두 당사자가 데이터를 전송하지 않고 한 당사자의 TCP 연결이 ESTABLISHED 상태에 있다고 해서 상대방의 TCP 연결이 정상이어야 한다는 의미는 아닙니다.

그리고 TCP keepalive 메커니즘이 켜져 있으면 서버 호스트가 다운된 후 클라이언트가 데이터를 보내지 않더라도 일정 시간이 지나면 TCP는 서버가 살아 있는지 감지하기 위해 감지 메시지를 보냅니다.

피어가 정상적으로 작동하는 경우 . 피어에게 TCP 연결 유지 감지 메시지를 보내면 피어는 정상적으로 응답하므로 TCP 연결 유지 시간이 재설정되고 다음 TCP 연결 유지 시간이 도래하기를 기다립니다.
피어 호스트가 충돌하거나 다른 이유로 피어에 연결할 수 없는 경우 . TCP keep-alive 탐지 메시지가 피어에게 전송되면 응답이없고 응답이 없습니다.여러 번 연속으로 keep-alive 탐지 횟수에 도달 한 후 TCP는 TCP 연결이 끊어 졌다고보고합니다 . .

따라서 TCP keepalive 메커니즘은 양 당사자 간에 데이터 교환이 없을 때 패킷을 감지하여 상대방의 TCP 연결이 활성 상태인지 확인할 수 있습니다.

TCP keepalive 메커니즘이 정확히 무엇입니까?

TCP keepalive 메커니즘 메커니즘의 원칙은 다음과 같습니다.

기간을 정의합니다. 이 기간 동안 연결 관련 활동이 없으면 TCP 연결 유지 메커니즘이 작동하기 시작합니다. 다른 시간 간격마다 프로브 메시지가 전송됩니다. 프로브 메시지에는 데이터가 거의 없습니다. 연속된 여러 감지 메시지에 대한 응답이 없으면 현재 TCP 연결이 끊어진 것으로 간주하고 시스템 커널은 오류 메시지를 상위 계층 응용 프로그램에 알립니다 .

Linux 커널에는 연결 유지 시간, 연결 유지 감지 횟수 및 연결 유지 감지 시간 간격을 설정하는 해당 매개변수가 있을 수 있습니다. 기본값은 다음과 같습니다.

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9

각 매개변수의 의미는 다음과 같습니다.

tcp_keepalive_time=7200: keepalive 시간이 7200초(2시간)임을 나타냅니다. 즉, 2시간 이내에 연결 관련 활동이 없으면 keepalive 메커니즘이 활성화됩니다.
tcp_keepalive_intvl=75: 각 탐지 사이의 간격이 75초임을 나타냅니다.
tcp_keepalive_probes=9: 9회 탐지 후 응답이 없고, 상대방이 도달할 수 없는 것으로 간주하여 이 연결을 끊는다는 의미입니다.

즉, Linux 시스템에서 "죽은" 연결을 찾는 데 최소 2시간 11분 15초가 걸립니다.

애플리케이션이 TCP 연결 유지 메커니즘을 사용하려면 소켓 인터페이스를 통해 SO_KEEPALIVE옵션을 적용됩니다. 설정하지 않으면 TCP 연결 유지 메커니즘을 사용할 수 없습니다.

TCP keepalive 메커니즘의 감지 시간이 너무 길습니까?

예, 조금 깁니다.

TCP keepalive는 TCP 계층(커널 상태) 에 의해 구현 되며 TCP 전송 프로토콜을 기반으로 하는 모든 프로그램에 대한 포괄적인 솔루션입니다.

실제로 우리의 응용 프로그램 계층은 일련의 탐지 메커니즘을 자체적으로 구현할 수 있어 비교적 짧은 시간 내에 상대방이 살아 있는지 여부를 탐지할 수 있습니다.

예를 들어 웹 서비스 소프트웨어는 일반적으로 HTTP 영구 연결의 제한 시간을 지정하는 keepalive_timeout매개 변수를 . HTTP 긴 연결의 시간 초과 기간이 60초로 설정되면 웹 서비스 소프트웨어는 타이머를 시작합니다 .클라이언트가 마지막 HTTP 요청 후 60초 이내에 새 요청을 시작하지 않으면 타이머 시간이 지나면 콜백이 발생합니다. 기능이 트리거되어 연결을 해제합니다.

요약하다

클라이언트가 데이터를 보내면 서버가 더 이상 존재하지 않기 때문에 클라이언트의 데이터 패킷은 시간이 지남에 따라 재전송되고 총 재전송 간격이 특정 임계값에 도달하면(커널은 tcp_retries2에서 설정한 값을 기반으로 임계값을 계산함), 중단됩니다. TCP 연결을 엽니다.
클라이언트가 데이터를 전송하지 않는 경우 클라이언트가 TCP keepalive 메커니즘을 활성화했는지 확인하십시오.
- 활성화된 경우 클라이언트는 상대방의 존재를 감지하기 위해 일정 시간 동안 데이터 상호 작용이 없을 때 TCP 연결 유지 메커니즘을 트리거하고 상대방이 사망한 것을 감지하면 자신의 TCP 연결을 끊습니다.
- 활성화되지 않은 경우 클라이언트의 TCP 연결은 항상 존재하며 ESTABLISHED 상태로 유지됩니다.

매우 흥미로운 또 다른 질문이 있습니다. " 네트워크 케이블을 몇 초 동안 분리한 다음 다시 연결합니다. 원래 TCP 연결이 여전히 존재합니까? " 이전에 작성했습니다. 다음 문서를 참조할 수 있습니다. 몇 초, 원래 TCP 연결이 여전히 존재합니까?

위에!

더 많은 웹 기사

웹사이트: www.xiaolincoding.com
웹사이트: xiaolincoding.com

네트워크 기본 사항:

HTTP 문서:

TCP 기사:

IP 기사:

학습 경험: