서버 측에서 많은 TIME_WAIT의 비용은 얼마입니까?

Question

서버에 단기 연결을 많이 하는 클라이언트가 있다고 가정해 보겠습니다.

클라이언트가 연결을 닫으면 해당 포트에 많은 포트가 있게 됩니다. TIME_WAIT 클라이언트 측에서 상태.클라이언트의 로컬 포트가 부족해지면 새로운 연결을 빠르게 시도하는 것이 불가능해집니다.

서버가 연결을 닫으면 많은 것을 볼 수 있습니다 TIME_WAIT서버 측에 있습니다.그러나 이것이 해를 끼치나요?클라이언트(또는 다른 클라이언트)는 로컬 포트가 부족하지 않기 때문에 계속 연결을 시도할 수 있으며, TIME_WAIT 상태는 서버 측에서 증가합니다.결국에는 어떻게 되나요?뭔가 나쁜 일이 일어나나요?(속도 저하, 충돌, 연결 끊김 등)

내 질문은 "목적이 무엇입니까?"가 아닙니다. TIME_WAIT?"가 아니라 "그렇게 많으면 어떻게 될까요? TIME_WAIT 상태가 서버에 있습니까?" 나는 TCP/IP에서 연결이 닫히면 무슨 일이 일어나는지, 그리고 그 이유는 이미 알고 있습니다. TIME_WAIT 상태가 필요합니다.문제를 해결하려는 것이 아니라 잠재적인 문제가 무엇인지 알고 싶습니다.

쉽게 말하면 netstat -nat | grep :8080 | grep TIME_WAIT | wc -l 인쇄물 100000.무슨 일이 일어날 지?O/S 네트워크 스택이 느려지나요?"열린 파일이 너무 많습니다" 오류가 발생합니까?아니면 그냥 걱정할 게 없나요?

Answer 1

각 소켓은 TIME_WAIT 커널에서 약간의 메모리를 소비합니다. 일반적으로 메모리보다 약간 적습니다. ESTABLISHED 소켓은 아직 중요합니다.너무 큰 수는 커널 메모리를 소모하거나 적어도 성능을 저하시킬 수 있습니다. 해당 메모리는 다른 목적으로 사용될 수 있기 때문입니다. TIME_WAIT 소켓은 열린 파일 설명자를 보유하지 않으므로(올바르게 닫혔다고 가정) "열린 파일이 너무 많습니다" 오류에 대해 걱정할 필요가 없습니다.

소켓은 또한 그 특정을 묶습니다. src/dst IP 주소와 포트를 사용하여 해당 기간 동안 재사용할 수 없습니다. TIME_WAIT 간격.(이것이 의도된 목적이다. TIME_WAIT 상태.) 동일한 포트 쌍을 사용하여 다시 연결해야 하는 경우를 제외하고 포트 연결은 일반적으로 문제가 되지 않습니다.대부분의 경우 한쪽은 임시 포트를 사용하며 한쪽만 잘 알려진 포트에 고정됩니다.그러나 매우 많은 수의 TIME_WAIT 동일한 두 IP 주소 간에 반복적이고 자주 연결하는 경우 소켓은 임시 포트 공간을 소모할 수 있습니다.이는 이 특정 IP 주소 쌍에만 영향을 미치며 다른 호스트와의 연결 설정에는 영향을 미치지 않습니다.

Answer 2

지금까지의 결과 :

서버가 시스템 호출을 사용하여 소켓을 닫더라도 Time_wait 상태에 들어가면 파일 디스크립터가 해제되지 않습니다. 파일 디스크립터는 Time_wait 상태가 사라지면 나중에 릴리스됩니다 (예 : 2*MSL 초 후). 따라서 너무 많은 Time_waits는 서버 프로세스에서 '너무 많은 파일'오류로 이어질 수 있습니다.

O/S TCP/IP 스택은 적절한 데이터 구조 (예 : 해시 테이블)로 구현되었다고 생각하므로 Time_Waits의 총 수는 O/S TCP/IP 스택의 성능에 영향을 미치지 않아야합니다. time_wait 상태에서 소켓을 소유 한 프로세스 (서버)만이 어려움을 겪습니다.

Answer 3

각 연결은 튜플 (서버 IP, 서버 포트, 클라이언트 IP, 클라이언트 포트)으로 식별됩니다. 결정적으로, TIME_WAIT 연결 (서버 쪽이든 클라이언트쪽에 있든)는 각각이 튜플 중 하나를 차지합니다.

이랑 TIME_WAIT클라이언트 측면에서 더 이상 연결할 수없는 이유를 쉽게 알 수 있습니다. 더 이상 로컬 포트가 없습니다. 그러나 서버 측에서 동일한 문제가 적용됩니다. 일단 64K 연결이 있으면 TIME_WAIT 상태 단일 클라이언트의 경우, 더 이상 연결을 받아 들일 수 없습니다 그 고객으로부터, 이전 연결과 새로운 연결의 차이를 알 수있는 방법이 없기 때문에 두 연결은 동일한 튜플로 식별됩니다. 서버는 다시 보내야합니다 RST이 경우 해당 클라이언트의 새로운 연결 시도에 대한 s.

Answer 4

많은 다른 클라이언트 IP에서 서버 IP에 이르기까지 많은 연결이있는 경우 연결 추적 테이블의 제한 사항이 달라질 수 있습니다.

확인하다:

sysctl net.ipv4.netfilter.ip_conntrack_count
sysctl net.ipv4.netfilter.ip_conntrack_max

모든 SRC IP/PORT 및 DEST IP/포트 튜플을 통해 추적 테이블에 net.ipv4.netfilter.ip_conntrack_max 만 가질 수 있습니다. 이 한계가 맞으면 로그에 "NF_CONNTRACK : TABLE FULL, DROPPING PACKET"에 메시지가 표시됩니다. 그리고 서버는 추적 테이블에 다시 공간이있을 때까지 새로운 들어오는 연결을 허용하지 않습니다.

이 제한은 임시 포트가 다 떨어지기 오래 전에 당신을 때릴 수 있습니다.

Answer 5

내 시나리오에서 파일을 반복적으로 스케줄링하는 스크립트를 실행했으며, 내 제품은 일부 계산을 수행하고 클라이언트 IE 클라이언트에 대한 응답을 보냅니다. IE 클라이언트는 각 파일의 응답을 얻기 위해 반복적 인 HTTP 호출을하고 있습니다. time_wait 상태와 HTTP 연결을 열어주는 클라이언트에서 예외가 발생합니다.

 Error : [Errno 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

결과는 내 응용 프로그램이 교수형을 일으켰습니다. 나는 대기 상태에서 스레드 셰이브가 사라 졌을 수도 있고 무슨 일이 있었는지 모르지만 모든 프로세스를 죽이거나 응용 프로그램을 다시 시작하여 다시 작동하도록해야합니다.

기본적으로 240 초이기 때문에 대기 시간을 30 초로 줄이려했지만 작동하지 않았습니다.

그래서 기본적으로 전반적인 영향은 내 응용 프로그램이 응답하지 않기 때문에 중요했습니다.

Answer 6

서버가 포트가 부족하여 들어오는 연결 (기존 TIMED_WAITS 기간 동안) (DOS 공격의 경우)에 할당 할 수 있습니다.