>  기사  >  운영 및 유지보수  >  Linux 튜토리얼: Nginx의 동시 연결 수 및 연결 상태 쿼리

Linux 튜토리얼: Nginx의 동시 연결 수 및 연결 상태 쿼리

巴扎黑
巴扎黑원래의
2017-08-22 13:56:322422검색

Linux에서 동시 연결 수와 Nginx 등의 연결 상태를 확인하세요.

1. 웹 서버(Nginx Apache)의 동시 요청 수와 해당 TCP 연결 상태를 확인합니다.

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

or:

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t ",state [key]}' 반환 결과는 일반적으로 다음과 같습니다.

LAST_ACK 5(처리 대기 중인 요청 수)

SYN_RECV 30

ESTABLISHED 1597(정상적인 데이터 전송 상태)

FIN_WAIT1 51

FIN_WAIT2 504

TIME_ WAIT 1057(처리 완료, 시간 초과가 끝날 때까지 기다리는 요청 수)

기타 매개변수 설명:

CLOSED: 연결이 활성화되어 있지 않거나 진행 중입니다.

LISTEN: 서버가 수신 호출을 기다리고 있습니다.

SYN_RECV: 연결 요청이 도착했고 확인을 기다리고 있습니다.

SYN_SENT: 애플리케이션이 시작되었으며 연결이 열려 있습니다.

ESTABLISHED: 정상적인 데이터 전송 상태

FIN_WAIT1: 애플리케이션에서 완료되었다고 표시됩니다.

FIN_WAIT2: 상대방이 동의함 릴리스

ITMED_WAIT: 모든 패킷이 죽을 때까지 대기

CLOSING: 양쪽이 동시에 닫으려고 시도

TIME_WAIT: 상대방이 릴리스를 초기화함

LAST_ACK: 모든 패킷이 죽을 때까지 대기

일반적으로 사용되는 세 가지 상태는 다음과 같습니다. ESTABLISHED는 통신을 의미하고, TIME_WAIT는 활성 종료를 의미하며, CLOSE_WAIT는 수동 종료를 의미합니다.

TCP 프로토콜은 연결이 설정된 경우 네트워크의 양쪽 당사자가 4방향 핸드셰이크를 수행하여 연결을 성공적으로 끊어야 한다고 규정합니다. 이러한 단계 중 하나가 누락되면 연결이 일시 중지된 상태가 되고 리소스가 점유됩니다. 연결 자체로는 해제되지 않습니다. 네트워크 서버 프로그램은 동시에 많은 수의 연결을 관리해야 하므로 불필요한 연결이 완전히 끊어졌는지 확인하는 것이 필요합니다. 그렇지 않으면 연결이 끊어진 수가 많아지면 서버 리소스가 많이 낭비됩니다. 많은 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을 수신한 연결을 닫지 않았을 수 있습니다. 이때, recv/read는 FIN 연결 소켓을 수신했으며 0을 반환합니다.

TIME_WAIT 상태가 왜 필요한가요?

최종 ACK가 손실되었다고 가정하면 서버는 FIN을 다시 보냅니다. 클라이언트는 최종 ACK를 다시 보낼 수 있도록 TCP 상태 정보를 유지해야 합니다. 그렇지 않으면 서버가 오류가 있다고 생각하게 됩니다. 발생했습니다. TCP 구현은 연결의 양방향(전이중 폐쇄)을 안정적으로 종료해야 하며, 클라이언트는 최종 ACK를 재전송해야 할 수 있으므로 TIME_WAIT 상태로 들어가야 합니다.

왜 TIME_WAIT 상태가 그렇게 오랫동안 2MSL을 유지해야 합니까?

TIME_WAIT 상태가 충분히 오랫동안 유지되지 않으면(예: 2MSL 미만) 첫 번째 연결이 정상적으로 종료됩니다. 두 번째 연결은 동일한 5중 연결로 나타나고 첫 번째 연결의 중복 패킷이 도착하여 두 번째 연결을 방해합니다. TCP 구현은 연결이 종료된 후 특정 연결에서 중복된 메시지가 나타나는 것을 방지해야 하므로 TIME_WAIT 상태를 충분히 길게(2MSL) 유지하면 해당 연결 방향의 TCP 메시지는 완전히 응답되거나 삭제됩니다. 두 번째 연결을 설정할 때 혼동이 없습니다.

TIME_WAIT 및 CLOSE_WAIT 상태 소켓이 너무 많습니다.

서버에 예외가 있는 경우 80% 또는 90%는 다음 두 가지 상황이 됩니다.

1 서버가 많은 양의 TIME_WAIT 상태를 유지합니다

2. 서버는 많은 양의 CLOSE_WAIT 상태를 유지합니다. 간단히 말해서 과도한 CLOSE_WAIT 수는 수동적으로 닫힌 연결을 부적절하게 처리하여 발생합니다.

리눅스에서 사용자에게 할당하는 파일 핸들은 제한되어 있기 때문에 TIME_WAIT, CLOSE_WAIT 두 가지 상태가 항상 유지된다는 것은 해당 개수의 채널이 항상 점유된다는 의미이며, "노력하지 않고 피트를 점유하는 것"입니다. 노력", 핸들 수의 상한에 도달하면 새 요청을 처리할 수 없으며 열린 파일이 너무 많음 예외가 발생하고 Tomcat이 충돌합니다.

위 내용은 Linux 튜토리얼: Nginx의 동시 연결 수 및 연결 상태 쿼리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.