서버 TIMEWAIT 와 CLOSEWAIT 분석 및 해결 방법

TIME 보기WAIT 와 CLOSEWAIT 수의 명령:

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

다음 과 같은 정 보 를 표시 합 니 다: TIMEWAIT 、CLOSE_WAIT 、FIN_WAIT1 、ESTABLISHED 、SYN_RECV 、LAST_ACK 가 자주 사용 하 는 세 가지 상 태 는: ESTABLISHED 는 통신 중, TIMEWAIT 는 자 진 폐쇄, CLOSEWAIT 는 수 동적 으로 닫 혔 다 고 밝 혔 다.
서버 에 이상 이 가장 오래 발생 한 상황 은:

서버 에 대량의 TIME 유지WAIT 상태.

서버 는 대량의 CLOSE 를 유지 했다.WAIT 상태.

리 눅 스 시스템 에서 모든 사용자 에 게 나 누 어 주 는 파일 핸들 수 는 한계 가 있다 는 것 을 잘 알 고 있 습 니 다. TIMEWAIT 와 CLOSEWAIT 라 는 두 가지 상태 가 계속 유지 된다 면 해당 하 는 수량의 채널 (여기 서 socket 으로 이해 해 야 합 니 다. 보통 하나의 socket 은 서버 엔 드 의 포트 를 차지 하고 서버 엔 드 의 포트 최대 수 는 65535) 이 계속 점용 되 었 습 니 다. 상한 선 에 도달 하면 새로운 요청 이 처리 되 지 않 습 니 다. 그 다음 에 대량의 Too Many Open Files 이상, 그리고 tomcat, nginx,apache 붕괴...
다음은 이 두 가지 상태의 처리 방법 을 토론 하 겠 습 니 다. 인터넷 에서 도 많은 자료 가 이 두 가지 상황 을 혼동 하여 커 널 파 라 메 터 를 최적화 하면 해결 할 수 있다 고 생각 합 니 다. 사실은 이것 은 적절 하지 않 습 니 다.커 널 매개 변 수 를 최적화 하면 timewait 과 다 한 문제, 하지만 closewait 는 응용 프로그램 자체 에서 출발 해 야 합 니 다.

서버 는 대량의 timewait 상태

이런 상황 은 흔히 볼 수 있 는데, 일반적으로 파충류 서버 와 웹 서버 (커 널 파라미터 최적화 가 되 지 않 았 다 면) 에 나타 나 는데, 이런 문 제 는 어떻게 발생 했 을 까?
위의 그림 에서 timewait 는 연결 을 주동 적 으로 닫 는 측 이 유지 하 는 상태 입 니 다. 파충류 서버 에 있어 자신 은 클 라 이언 트 입 니 다. 기어 오 르 기 작업 을 완성 한 후에 주동 적 으로 연결 을 닫 고 time 에 들 어 갑 니 다.wait 상태 에서 이 상태 로 2MSL 시간 을 유지 한 후 회수 자원 을 철저히 닫 습 니 다.여 기 는 왜 자원 2MSL 시간 을 유지 합 니까?이것 도 TCP / IP 디자이너 가 규정 한 것 이다.
TCP 는 모든 가능 한 상황 에서 모든 데 이 터 를 정확하게 전송 할 수 있 도록 해 야 한다.socket 을 닫 으 면 한쪽 socket 을 주동 적 으로 닫 으 면 TIME 에 들 어 갑 니 다.WAIT 상태, 수 동적 으로 닫 힌 쪽 은 CLOSED 상태 로 전 환 됩 니 다. 모든 데이터 가 전송 되 는 것 을 보장 할 수 있 습 니 다.하나의 socket 이 닫 혔 을 때 양 끝 에서 네 번 의 악 수 를 통 해 이 루어 졌 습 니 다. 한 끝 에서 close () 를 호출 할 때 이 단 에 데이터 가 전송 되 지 않 았 음 을 설명 합 니 다.악수 가 끝 난 후에 socket 은 모두 최초의 CLOSED 상태 에 있 을 수 있 을 것 같 지만 사실은 그렇지 않다.그 이 유 는 이러한 배정 상태 에 두 가지 문제 가 있 기 때문이다. 우선, 우 리 는 마지막 ACK 가 정상적으로 전송 할 수 있 도록 보장 하 는 어떠한 메커니즘 도 없다. 둘째, 네트워크 에 남아 있 는 패 킷 (wandering Duplicates) 이 있 을 수 있 고 우리 도 정상적으로 처리 해 야 한다.
TIMEWAIT 는 이 두 가지 문 제 를 해결 하기 위해 태 어 났 다.

마지막 ACK 를 잃 어 버 렸 다 고 가정 하면 한 측 이 마지막 ACK 를 받 지 못 하면 FIN 을 다시 보 냅 니 다.이 때 한 쪽 을 주동 적 으로 닫 으 려 면 ACK 를 다시 보 낼 수 있 도록 유효한 (time wait 상태 에서 유지) 상태 정 보 를 유지 해 야 합 니 다.주동 적 으로 닫 힌 socket 이 이러한 상 태 를 유지 하지 않 고 close 상태 에 들 어가 면 주동 적 으로 닫 힌 쪽 은 수 동적 으로 닫 힌 쪽 에서 다시 보 낸 FIN 을 받 았 을 때 수 동적 인 쪽 에 게 RST 에 응답 합 니 다.수 동적 으로 이 RST 를 받 으 면 이번 대답 이 틀 렸 다 고 생각 할 것 이다.따라서 TCP 가 필요 한 조작 을 완성 하고 쌍방의 데이터 흐름 전송 을 중지 하려 면 네 번 의 악수 의 네 걸음 을 정확하게 전송 해 야 하 며 잃 어 버 리 지 않도록 해 야 한다.이것 이 바로 socket 이 닫 힌 후에 마음대로 timewait 상태의 첫 번 째 이유.그 는 ACK 를 다시 보 낼 수 있 도록 발생 할 수 있 는 오 류 를 기 다 려 야 하기 때문이다.

현재 연 결 된 통신 쌍방 이 close () 를 호출 했다 고 가정 하면 쌍방 은 동시에 closed 의 종결 상태 에 들 어 갔 고 timewait 상태.다음 과 같은 문제 가 발생 할 수 있 습 니 다. 만약 에 현재 새로운 연결 이 구축 되면 사용 하 는 IP 주 소 는 이전 포트 와 똑 같 습 니 다. 현재 구축 한 연결 은 이전 연결 의 완전 재 활용 입 니 다. 우 리 는 이전 연결 에 데이터 신문 이 네트워크 에 남아 있다 고 가정 합 니 다. 그러면 현재 연결 되 어 있 는 데 이 터 는 이전에 연 결 된 메시지 일 수 있 습 니 다.그 걸 막 기 위해 서TCP 는 새로운 연결 재 활용 을 허용 하지 않 습 니 다 timewait 상태의 socket.에 처 하 다,...wait 상태의 socket 은 2MSL 시간 을 기다 린 후 (MSL 이 두 배 인 이 유 는 MSL 이 네트워크 에서 단 방향 으로 손실 을 인정 하 는 시간 을 보 내기 때 문 입 니 다. 즉, (Maximum Segment Lifetime)메 시 지 는 가장 오래 생존 할 수 있 으 며, 하나의 데이터 메 시 지 는 발송 도중에 또는 그 응답 과정 에서 잔여 데이터 메시지 가 될 수 있 으 며, 하나의 데이터 메 시 지 를 확인 하고 그 응답 을 버 리 는 데 두 배의 MSL 이 필요 하 다) 는 것 을 확인 하면 closed 상태 로 전 환 될 것 이다.이것 은 성공 적 으로 구 축 된 연결 이 이전의 네트워크 에 남아 있 는 데이터 신문 을 모두 잃 어 버 려 야 한 다 는 것 을 의미한다.

네트워크 의 한 단락 을 참조 하 십시오:

주의해 야 할 것 은 TCP 기반 http 프로 토 콜 입 니 다. 보통 (여기 서 왜 보통 이 라 고 하 죠? keepalive 시간 내 에 서버 쪽 에 대한 연결 을 주동 적 으로 닫 을 때 주동 적 으로 닫 는 쪽 이 클 라 이언 트 입 니 다. 그렇지 않 으 면 클 라 이언 트 가 수 동적 으로 닫 는 쪽 입 니 다. 다음 파충류 의 예 는 이 경우 입 니 다) tcp 한쪽 을 주동 적 으로 닫 는 것 은 server 쪽 입 니 다.이렇게 하면 server 엔 드 가 timewait 상태, 짐작 할 수 있 듯 이 방 문 량 이 많은 웹 서버 에 대량의 time 가 존재 합 니 다.wait 상태, server 가 1 초 에 1000 개의 요청 을 받 으 면 240 * 1000 = 240000 timewait 상태.(RFC 793 에 서 는 MSL 을 2 분 으로 정 하고 있 고, 실제 애플 리 케 이 션 에 서 는 30 초, 1 분, 2 분 등 을 많이 사용 하고 있다.) 이 상 태 를 유지 하 는 것 은 서버 측 에 큰 부담 을 준다.물론 현대 운영 체 제 는 빠 른 검색 알고리즘 으로 TIME 를 관리 합 니 다.WAIT, 그래서 새로운 TCP 연결 요청 에 대해 hit 중 하나의 TIME 여 부 를 판단 합 니 다.WAIT 는 시간 이 많이 걸 리 지 는 않 지만 이렇게 많은 상 태 를 유지 해 야 하 는 것 은 항상 좋 지 않다.

HTTP 프로 토 콜 1.1 버 전 은 default 행 위 를 keep - Alive 라 고 규정 하고 있 습 니 다. 즉, tcp 연결 을 다시 사용 하여 여러 개의 request / response 를 전송 합 니 다.이렇게 하 는 주요 원인 은 우리 가 위 에서 말 한 이 문 제 를 발 견 했 기 때문이다.

서버 가 대량의 close 를 유지 하 였 습 니 다.wait 상태
time_wait 문 제 는 커 널 파라미터 조정 과 웹 서버 의 kep - alive 값 을 적 절 히 설정 하여 해결 할 수 있 습 니 다.왜냐하면 timewait 는 자신 이 제어 할 수 있 는 것 입 니 다. 상대방 이 연결 한 이상 이거 나 자원 을 신속하게 회수 하지 않 았 습 니 다. 어쨌든 자신의 프로그램 오류 로 인 한 것 이 아 닙 니 다.하지만 closewait 는 다 릅 니 다. 위의 그림 에서 서버 가 대량의 close 를 유지 하 는 것 을 볼 수 있 습 니 다.wait 는 한 가지 경우 만 있 습 니 다. 바로 상대방 이 FIN 을 보 낸 후에 프로그램 은 자신 에 게 더 이상 ACK 를 보 내지 않 았 습 니 다.다시 말 하면 상대방 이 연결 을 닫 은 후에 프로그램 에서 감지 되 지 않 았 거나 프로그램 자체 가 연결 을 닫 아야 한 다 는 것 을 잊 어 버 렸 기 때문에 이 자원 은 프로그램 에 의 해 계속 점용 되 고 있다.이때 빠 른 해결 방법 은:

실행 중인 프로그램 을 닫 으 려 면 업무 상황 에 따라 정 해 야 합 니 다.

가능 한 한 빨리 프로그램의 bug 를 수정 한 후에 온라인 서버 에 제출 하 는 것 을 테스트 합 니 다.

주:
이 글 을 쓸 때 가 되 어서 야 나 는 이전에 업무 중 에 겪 었 던 문 제 를 완전히 알 게 되 었 다.프로그래머 는 파충류 (phop) 가 채집 서버 A 에서 실행 되 고 있다 고 썼 다. 프로그램 은 B 서버 에 가서 자원 을 수집 하 였 으 나 A 서버 는 곧 대량의 close 가 나 타 났 다 는 것 을 발견 하 였 다.wait 상태의 연결.나중에 수 동 으로 검사 해 보 니 closewait 상태의 요청 결 과 는 404 입 니 다. B 서버 에 요청 할 자원 이 없다 는 뜻 입 니 다.
다음은 네티즌 분석의 결론 을 인용 한다.
서버 A 는 파충류 서버 입 니 다. 간단 한 HttpClient 를 사용 하여 자원 서버 B 에 있 는 apache 에 파일 자원 을 가 져 오 라 고 요청 합 니 다. 정상 적 인 상황 에서 요청 이 성공 하면 자원 을 캡 처 한 후에 서버 A 는 자발적으로 연결 을 닫 아 달 라 는 요청 을 합 니 다. 이 때 는 주동 적 으로 연결 을 닫 는 것 입 니 다. 서버 A 의 연결 상 태 는 TIME 임 을 알 수 있 습 니 다.WAIT。이상 이 생기 면?요청 한 자원 서버 B 에 존재 하지 않 는 다 고 가정 하면 이 럴 때 서버 B 에서 연결 을 닫 아 달 라 는 요청 을 보 냅 니 다. 서버 A 는 수 동적 으로 연결 을 닫 았 습 니 다. 서버 A 가 수 동적 으로 연결 을 닫 은 후에 프로그래머 가 HttpClient 에 연결 을 풀 어 달라 고 하 는 것 을 잊 어 버 리 면 CLOSE 가 됩 니 다.WAIT 상태 입 니 다.