TCP 연결에서 TIME WAIT의 목적은 무엇입니까?

액티브 클로저가 TIME WAIT에 들어가는 이유는 최종 ACK가 손실되지 않도록하기위한 것입니다. 그러나 최종 ACK가 손실되는지 어떻게 알 수 있습니까? 패시브 클로저는 FIN을 다시 보내고 액티브 클로저는 ACK가 손실되었음을 알 수 있습니까? 다음은 TCP FSM의 사진입니다.

패시브 클로저는 FIN을 다시 보내고 액티브 클로저는 ACK가 손실되었음을 알 수 있습니까?

예. TCP 연결 관리 섹션의 TCP / IP Illustrated Volume 1 에서 인용 :

3. 마감을 완료하기 위해 마지막 세그먼트에는 마지막 FIN에 대한 ACK가 포함됩니다. FIN이 손실되면, ACK가 수신 될 때까지 재전송된다.

타임 아웃이 있습니다. 에있을 때 시간 초과가 발생 LAST_ACK하면 패시브 클로저 FIN가 손실되었다고 가정하여 다시 전송 합니다. 실제로 손실 된 경우 활성 클로저는 결국 재전송 된 메시지를 수신 FIN하고에 들어갑니다 TIME_WAIT. 이 경우 FIN손실되지하지만 마지막이 ACK분실 한 후 가까운 활성이있는 TIME_WAIT및 수신 FIN을 다시. 이 경우 - 수신 FIN에 TIME_WAIT-는 ACK재전송된다.

시간 초과 값의가 TIME_WAIT있다 NOT 재전송 목적으로 사용. 에 시간 초과가 있으면 패시브 클로저가 패킷을 다시 전송 하지 않기 때문에 TIME_WAIT최종 결과 ACK가 성공적으로 전달 된 것으로 가정합니다 FIN. 따라서 타임 아웃 시간 TIME_WAIT은 다른 쪽 끝이 아무것도 보내지 않으면 최종 ACK연결 을 수신 하고 연결을 닫았 기 때문에 안전하다고 가정 할 수있는 시간 입니다.

그러나 최종 ACK가 손실되는지 어떻게 알 수 있습니까?

타임 아웃 기간 내에받지 못했기 때문입니다. 나는 그것이 "duh"답변이라는 것을 알고 있지만, 이것이 바로 이러한 상태와 시간 초과가 존재하는 이유입니다.

패시브가 FIN을 다시 보내겠습니까?

해당 스트림에 추가 패킷이 도착하지 않으면 "RST"(재설정)가 전송되지 않습니다.

전체 프로세스는 네트워크 장애 가능성에도 불구하고 순서대로 종료하기 위해 복잡한 상태 시스템입니다. 네트워크가 끊어지고, 링크에 오류가 발생하고, 링크가 포화되어 패킷을 삭제해야하고, 장치가 실패해야합니다. 연습으로 엔드 포인트 중 하나가 사라지면 (예 : 정전) 활성 연결에 대한 상태 트리를 실행하십시오.

TL; DR 상태 트리는 가능한 모든 실패 모드를 처리하도록 설계되었습니다.

TIME_WAIT의 목적은 네트워킹이 '기존의 기존'연결에 속하는 것으로 도착한 패킷을 새 것과 구별 할 수 있도록하는 것입니다. TIME_WAIT 타이머를 최대 세그먼트 수명 (MSL)의 두 배로 설정하는 것이 좋습니다. 내 시스템에서 MSL은 1 분이므로 연결은 TIME_WAIT 상태에 2 분 동안 남아 있습니다.

이 시간이 지나면 도착한 패킷이 더 이상 이전 연결과 연결되지 않습니다.

TIME_WAIT는 ACK 패킷 전송을 직접 기다리지 않습니다. CLOSE_WAIT 및 FIN_WAIT 상태에 의해 구동됩니다. TIME_WAIT 상태에 도달하면 소켓이 이미 닫혀 있습니다.

참고 문헌 : http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ linux-tcpip-tuning /