TIME_WAIT 및 CLOSE_WAIT 상태 차이

서버의 일상적인 유지 관리 과정에서 다음 명령이 자주 사용됩니다.

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 

다음과 같은 정보가 표시됩니다.
TIME_WAIT 814 CLOSE_WAIT 1 FIN_WAIT1 1 ESTABLISHED 634 SYN_RECV 2 LAST_ACK 1
자주 사용하는 세 가지 상태: ESTABLISHED는 통신 중임을 나타냅니다. TIME_WAIT는 활성 종료를 나타냅니다. CLOSE_WAIT는 수동적으로 종료됨을 나타냅니다.
TCP 프로토콜에 따르면 이미 구축된 연결에 대해 네트워크 쌍방은 네 번의 악수를 해야만 연결을 성공적으로 끊을 수 있으며, 그 중 어느 절차가 부족하면 연결을 가사 상태로 만들고 연결 자체가 차지하는 자원이 방출되지 않는다.네트워크 서버 프로그램은 대량의 연결을 동시에 관리해야 하기 때문에 쓸모없는 연결이 완전히 끊어지지 않도록 보장할 필요가 있다. 그렇지 않으면 대량의 경직된 연결은 많은 서버 자원을 낭비할 것이다.여러 TCP 상태 중 가장 주목할 만한 상태는 두 가지입니다. CLOSE_WAIT 및 TIME_WAIT.  
TIME_WAIT 
TIME_WAIT는 2MSL 대기 시간으로 약 4분 동안 링크를 자동으로 닫습니다.주로 마지막 ACK가 손실되지 않도록 합니다.때문에 TIME_WAIT 시간이 매우 길기 때문에 서버 측은 주동적으로 연결을 닫는 것을 최소화해야 한다
CLOSE_WAIT CLOSE_WAIT는 수동으로 연결을 닫습니다.TCP 상태기에 따라 서버 측에서 클라이언트로부터 FIN을 받으면 TCP에 따라 ACK를 보내기 때문에 CLOSE_WAIT 상태.그러나 서버 측이 close()를 실행하지 않으면 CLOSE_WAIT에서 LAST로 마이그레이션_ACK, 시스템에 CLOSE_WAIT 상태 접속이 때, 시스템이 읽기, 쓰기 작업을 처리하느라 바쁠 수도 있고, 이미 받은 FIN 연결을 close하지 않았을 수도 있습니다.이 때,recv/read는 FIN의 연결 소켓을 받았습니다. 0을 되돌려줍니다.
왜 TIME_WAIT 상태?최종 ACK가 분실되면 서버는 FIN을 재발송합니다. 클라이언트는 최종 ACK를 재발송할 수 있도록 TCP 상태 정보를 유지해야 합니다. 그렇지 않으면 RST가 발송됩니다. 결과 서버는 오류가 발생했다고 생각합니다.TCP는 연결을 안정적으로 종료해야 하는 두 가지 방향(전이중화 종료)을 실현하고 클라이언트는 TIME_클라이언트가 최종 ACK를 재발행할 수 있기 때문에 WAIT 상태입니다.
왜 TIME_WAIT 상태를 2MSL로 유지하는 데 시간이 얼마나 걸립니까?하면, 만약, 만약...WAIT 상태가 2MSL 미만으로 오래 유지되지 않으면 첫 번째 연결이 정상적으로 종료됩니다.두 번째는 같은 관련 5원조의 연결이 나타났고 첫 번째 연결의 중복 메시지가 도착해 두 번째 연결을 방해했다.TCP 구현은 연결이 종료된 후에 반복 메시지가 표시되지 않도록 해야 하므로 TIME_WAIT 상태가 2MSL(2mSL) 이상 유지되면 해당 방향에 연결된 TCP 메시지가 완전히 응답되거나 버림됩니다.두 번째 연결을 만들 때 헷갈리지 않습니다.
 TIME_WAIT 및 CLOSE_WAIT 상태 소켓 과다
서버에 이상이 발생하면 890%는 다음 두 가지 상황입니다.
1. 서버에서 많은 TIME_ 유지WAIT 상태
2. 서버는 대량의 CLOSE_를 유지합니다.WAIT 상태, 간단히 말해 CLOSE_WAIT 수가 너무 많은 것은 수동적인 연결 해제 처리가 부적절하기 때문이다.linux가 사용자에게 할당하는 파일 핸들은 제한되어 있기 때문에 TIME_WAIT 및 CLOSE_WAIT의 두 가지 상태가 계속 유지된다면 대응하는 수량의 통로가 계속 점유되고'뒷구멍을 차지하고 힘을 쓰지 않는다'는 것을 의미한다. 일단 핸들 수 상한선에 도달하면 새로운 요청은 처리될 수 없다. 이어서 대량의 Too Many Open Files가 이상하고 Tomcat이 붕괴된다.