서버 측`TIME_WAIT`는 실제로 어떻게 작동합니까?

나는 이것에 대해 몇 가지 SE 질문이 있다는 것을 알고 있으며,이 시점에 오기 전에 중요한 질문을 많이 읽습니다.

"서버 측 TIME_WAIT"이란 서버 측에서 close ()가 시작된 서버 측 소켓 쌍의 상태를 의미합니다.

나는 종종 나에게 모순되는 이러한 진술을 본다.

1. 서버 측은 TIME_WAIT무해합니다
2. 클라이언트가 close ()를 시작하도록 클라이언트에 네트워크 응용 프로그램을 설계해야합니다. TIME_WAIT

이 모순을 찾는 이유 TIME_WAIT는 클라이언트에서 문제가 될 수 있기 때문 입니다. 클라이언트는 사용 가능한 포트가 부족할 수 있으므로 본질적으로 위의 TIME_WAIT문제는 클라이언트 측으로 문제 를 옮기는 것이 좋습니다 . 문제가 아닌 서버 측.

클라이언트 측은 TIME_WAIT물론 제한된 수의 유스 케이스에만 문제가됩니다. 대부분의 클라이언트-서버 솔루션에는 하나의 서버와 많은 클라이언트가 포함되며, 클라이언트는 일반적으로 문제가 발생하기에 충분한 양의 연결을 처리하지 않으며, "그렇게해도" "잘못"하는 여러 가지 권장 사항이 있습니다 ( 반대로 SO_LINGER0 시간 제한, 또는) tcp_tw의 sysctls와 전투 클라이언트 측 간섭 TIME_WAIT너무 빨리 너무 많은 연결을 만들어 피함으로써. 그러나 다음과 같은 응용 프로그램 클래스와 같이 항상 실현 가능한 것은 아닙니다.

• 모니터링 시스템
• 부하 발생기
• 프록시

다른 한편으로, 나는 서버 측 TIME_WAIT이 전혀 도움이되는 방법조차 이해하지 못합니다 . 그 이유 TIME_WAIT는 더 이상 존재 TCP하지 않는 스트림에 오래된 조각을 주입 하지 못하기 때문입니다. 클라이언트 측 TIME_WAIT의 ip:port경우이 오래된 연결이 가질 수 있는 것과 동일한 쌍 (사용 된 쌍이에 의해 잠김 TIME_WAIT) 으로 연결을 작성하는 것을 불가능하게함으로써 달성됩니다 . 그러나 서버 측의 경우 로컬 주소에 허용 포트가 있고 항상 동일하므로 서버를 막을 수 없으므로 서버는 (AFAIK, 경험적 증거 만 있음) 단순히 연결을 거부 할 수 없습니다. 들어오는 피어는 소켓 테이블에 이미 존재하는 것과 동일한 주소 쌍을 만듭니다.

서버 측 TIME-WAIT가 무시되는 것을 보여주는 프로그램을 작성했습니다. 또한 테스트는 127.0.0.1에서 수행되었으므로 커널에는 서버 쪽인지 클라이언트 쪽인지를 알려주는 특수 비트가 있어야합니다 (그렇지 않으면 튜플이 동일하기 때문에).

출처 : http://pastebin.com/5PWjkjEf , 기본 넷 구성 Fedora 22에서 테스트되었습니다.

$ gcc -o rtest rtest.c -lpthread
$ ./rtest 44400 s # will do server-side close
Will initiate server close
... iterates ~20 times successfully
^C
$ ss -a|grep 44400
tcp    TIME-WAIT  0      0            127.0.0.1:44400         127.0.0.1:44401   
$ ./rtest 44500 c # will do client-side close
Will initiate client close
... runs once and then
connecting...
connect: Cannot assign requested address

따라서 서버 측의 TIME_WAIT경우 정확히 동일한 포트 쌍의 연결을 즉시 성공적으로 다시 설정하고 클라이언트 측의 TIME-WAIT경우 두 번째 반복에서 connect()올바르게 실패 할 수 있습니다

요약하면 문제는 두 가지입니다.

• 서버 측은 TIME_WAIT실제로 아무 작업도하지 않으며, RFC필요로 하므로 그대로 남아 있습니까?
• 서버 TIME_WAIT가 쓸모 없기 때문에 클라이언트가 close ()를 시작하도록 권장하는 이유 입니까?

에서 TCP 용어의 서버 측이 여기 상태를 LISTEN에서 소켓이 호스트를 의미한다.

RFC1122 는 TIME-WAIT 상태의 소켓이 일부 조건에서 새 연결을 수락하도록 허용합니다.

        When a connection is closed actively, it MUST linger in
        TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
        However, it MAY accept a new SYN from the remote TCP to
        reopen the connection directly from TIME-WAIT state, if it:

조건에 대한 자세한 내용은 RFC1122 를 참조하십시오 . 소켓에 일치하는 수동 OPEN이 있어야합니다 (LISTEN 상태의 소켓).

활성 OPEN (클라이언트 측 연결 호출)에는 이러한 예외가 없으며 RFC793 에 따라 소켓이 TIME-WAIT 상태에있을 때 오류가 발생해야합니다 .

클라이언트에 대한 권장 사항 (TCP 용어로 활성 OPEN 즉 연결을 수행하는 호스트)에 대한 내 추측은 귀하와 거의 동일합니다. 일반적인 경우 많은 자원이있는 더 많은 호스트에 TIME-WAIT 소켓을 확산시킵니다 소켓. 일반적으로 클라이언트는 서버에서 TIME-WAIT 소켓을 재사용하는 SYN을 보내지 않습니다. 이러한 권장 사항을 적용하는 것은 여전히 ​​사용 사례에 달려 있음에 동의합니다.

이것은 아마도 TIME-WAIT가 실제로하는 일의 가장 분명한 예이며 더 중요한 이유입니다. 또한 Linux 시스템에서 TIME-WAIT를 '감소'시키기 위해 '전문가'팁을 피해야하는 이유도 설명합니다.

tcp 세션은 tupple (sourceIP, sourcePort, destIP, destPort)로 식별됩니다. 따라서 TIME_WAIT는 모든 TCP 연결에서 작동합니다.

닫는 쪽과 관련하여 일부 시나리오에서는 클라이언트 쪽에서 닫으면 서버의 TIME_WAIT 소켓이 줄어들어 메모리가 약간 줄어 듭니다. 소켓 공간이 소진 될 수있는 경우 (예 : 임시 포트 고갈로 인해) (예 : 동일한 서버에 많은 연결이있는 욕심 많은 클라이언트)이 문제는 어느 쪽에서 나 해결해야합니다.

신뢰할 수없는 프로토콜로 확신 할 수 없으며, 피어 장치에서 마지막 메시지를 수신 했으므로 피어가 갑자기 전화를 끊었다 고 가정하는 것은 위험합니다. TCP 프로토콜의 주요 단점은 65000 개 정도의 포트만 동시에 열 수 있다는 것입니다. 그러나이를 극복하는 방법은 포트 번호를 빠르게 재활용하는 것보다 서버 팜으로 이동하는 것입니다. 클라이언트 측에서는 기본 워크 스테이션 인 경우 포트가 부족할 가능성이 거의 없습니다.