TIME_WAIT의 과도한 처리

앞에 쓰다

많은 사람들이 서버를 만났을 거라고 믿어요 TIME_WAIT의 경우, 대부분의 해결 방법은 sysctl에서 다음과 같은 매개 변수를 수정하는 것이다

net.ipv4.tcp_tw_recycle = 1   #  TIME_WAIT

net.ipv4.tcp_tw_reuse = 1    #reuse TIME_WAIT

net.ipv4.tcp_timestamps = 1# 위의 두 항목은 TCP 연결 양쪽 끝에 모두 TCP 타임 스탬프를 사용하도록 전제합니다.
이따가 TIME_WAIT 수가 급격히 줄어든 후에 서비스도 문제가 없는 것 같습니다. ok 문제 해결!사실은 그렇지 않다.이른바 "대량의 TIME_WAIT의 문제"를 진정으로 이해하려면 TIME_WAIT.

2. 개념 해석

TIME_WAIT는 우호적입니다. 불필요한 것이 아니라 TCP 연결을 주동적으로 닫는 쪽이 socker의close 조작을 호출하면 최종적으로 TIME_WAIT 상태.서버가 클라이언트의 요청을 처리할 때, 만약 당신의 프로그램이 서버를 자발적으로 닫도록 설계되었다면, 당신은 이 타임웨이 상태의 과도한 문제에 관심을 가져야 할 수 있습니다.만약 당신의 서버가 수동적으로 닫히도록 설계되었다면, 가장 먼저 주목해야 할 것은 CLOSE_WAIT.
다시 말하면 부하가 균형 잡힌 서버에서 (Nginx를 예로 들면) 클라이언트가 Nginx에 요청한 것은 서버로서 수동적인 연결에 속한다.웹 서버에 대한 Nginx의 요청은 활성 접속에 속합니다.토론 TIME_WAIT를 최적화할 때 우리가 주목해야 할 것은 주동적인 연결, 즉 웹 서버에 대한 Nginx의 연결이다.

셋, TIME_WAIT 역할

1. 이전 연결이 지연된 데이터가 뒤에 복용된 연결 오류로 수신되는 것을 방지한다.
2. TCP 연결을 안정적으로 닫습니다.
TIME_ 정보WAIT 역할에 대한 깊은 이해는 Socket 연결 5원조, RFC 793 등 개념에 맞춰야 한다. 본고는 중점적으로 토론하지 않고 관심 있는 아동화는 올드보이 블로그로 옮겨 주십시오.

넷째, TIME_WAIT의 과도한 성능 영향

커널에 모든 연결을 저장하는hash table가 있습니다. 이hash table에는 TIME_WAIT 상태의 연결은 다른 상태의 연결도 포함합니다.주로 새로운 데이터가 왔을 때 이hashtable에서 이 연결을 빠르게 찾을 수 있습니다.모든boundports를 저장하는 데 사용되는hashtable도 있습니다. 주로 사용할 수 있는 포트나 무작위 포트를 신속하게 찾을 수 있습니다.
따라서 커널에 이 데이터를 저장하면 반드시 일정한 메모리를 차지할 것이다. 같은 이치로 매번 무작위 포트를 찾을 때boundports를 한 번 훑어봐야 하고 CPU 시간이 필요할 것이다!
TIME_WAIT는 메모리와 CPU를 모두 소모하는 경우가 많지만 1만 개의 TIME_WAIT 연결은 1M 정도의 메모리를 더 소모하기 때문에 현재 서버에 있어서는 아무것도 아니다.CPU에 대해서도 1만여 개의hash item 때문에 걱정할 정도는 아니다.적어도 TIME_Time_ 때문에 WAIT가 수천 개 수준에 도달할 경우 너무 긴장할 필요가 없습니다.WAIT가 차지하는 메모리는 매우 적고, 사용 가능한 로컬 포트를 기록하고 찾는 데 소모되는 CPU도 기본적으로 무시할 수 있다.

5. 넷을 엽니다.ipv4.tcp_tw_recycle 매개 변수의 부작용

TIME_WAIT의 존재는 TIME_를 무시할 경우 중요합니다.WAIT는 데이터가 흐트러지거나 일시적인 연결이 실패할 확률이 높습니다.비교적 직접적인 현상은 NAT 이후의 IP를 통해 대량으로 서비스에 접근할 때 몇 분 동안 정지된 후에 연결이 실패하거나 여러 클라이언트가 동시에 접근하는 데 빈번하게 실패하는 경우가 많다는 것이다.
또 다른 상황은 클라이언트-서버가 1대1일 때 아무런 문제가 없지만 원본 IP가 NAT를 통과한 주소나 서버가 부하균형기 뒤에 있을 때 원본 주소가 같은 IP이다. 만약에 공교롭게도 두 번 원본 포트를 연결했을 때 이 서버는 먼저 두 개의 패키지를 받았고 첫 번째 패키지의 timestamp는 서버에 저장되어 있고 두 번째 패키지가 왔다.두 번째 가방의timestamp가 첫 번째 가방보다 더 오래된 것을 발견했습니다. 클라이언트의 시간이 일치하지 않습니다.서버는 PAWS를 기반으로 두 번째 패키지를 중복 메시지로 판단하여 폐기합니다.반영된 상황은 서버에서 가방을 캡처하는데 SYN 가방이 있는 것을 발견했지만 서버는 ACK 가방을 돌려주지 않았다. 왜냐하면 SYN 가방은 이미 버려졌기 때문이다.출력 내의 packets rejects in established connections because of timestamp 항목의 수량 변화를 보려면 아래의 명령 검증을 사용할 수 있습니다.

netstat -s | grep timestamp

여섯, 넷.ipv4.tw_recycle 구성 방법

이렇게 많이 썼는데 그럼 tw_recycle 매개 변수는 도대체 어떻게 사용해야 합니까?여기서 올드보이 블로그에서 제시한 두 가지 전형적인 장면의 설정 방안을 참고로 인용한다

방안 1: 부하 균형 서버가 먼저 연결을 닫습니다

이 경우 로드 밸런스 서버가 웹 서버에 연결되기 때문입니다(참고, 로드 밸런스가 웹 서버에 시작하는 활성 연결), TIME_WAIT는 대부분 로드 밸런싱 서버에 나타나기 때문에 로드 밸런싱 서버에 대한 구성은 다음과 같습니다.

net.ipv4.tcp_tw_reuse = 1//가능한 연결 재사용

net.ipv4.tcp_tw_recycle = 0//클라이언트가 NAT에 없는 네트워크가 웹 서버에 구성되어 있는지 확인할 수 없음:

net.ipv4.tcp_tw_reuse = 1//이 설정은 웹 서버와 DB 서버의 연결 재사용에 영향을 미친다

net.ipv4.tcp_tw_recycle: 1과 0으로 설정하는 것은 아무런 의미가 없습니다.생각해봐, 부하 균형과 그 연결에서 그것은 서버이지만, TIME_WAIT가 로드 밸런싱 서버에 나타납니다.DB와 연결되어 있습니다. 클라이언트입니다.recycle은 아무런 영향을 미치지 않습니다. 관건은reuse

방안 2: 웹 서버가 먼저 부하 균형 서버에서 연결을 닫습니다

이 경우 웹 서버는 TIME_WAIT의 재해 지역로드 밸런싱 웹 서버에 대한 연결, 웹 서버에서 먼저 연결을 닫습니다, TIME_WAIT가 웹 서버에 나타납니다.DB 서버에 대한 웹 서버 연결, 웹 서버에 의한 연결 해제, TIME_워크로드 밸런싱 서버의 구성이 WAIT에도 나타납니다.

net.ipv4.tcp_tw_reuse:0 또는 1 모두 가능, 모두 실제 의미가 없음

net.ipv4.tcp_tw_recycle=0//웹 서버에서 recycle의 설정을 닫아야 합니다:

net.ipv4.tcp_tw_reuse = 1//이 설정은 웹 서버와 DB 서버의 연결 재사용에 영향을 미친다

net.ipv4.tcp_tw_recycle=1//부하 균형과 웹 서버 사이에 NAT 네트워크가 없기 때문에 recycle를 켜는 것을 고려할 수 있습니다. 부하 균형과 웹 서버 간의 연결로 인한 대량의 TIME_ 가속화WAIT

7. 참고와 인용 자료

http://blog.oldboyedu.com/tcp-wait/
http://blog.chinaunix.net/uid-24517549-id-4048652.html
http://blog.chinaunix.net/uid-28337979-id-4107112.html
마지막으로 내부 핵의 최적화는 당연하다고 생각할 수 없고 해당하는 업무 장면에 협조해야 한다.물론 이것은 장기적으로 축적된 과정이기 때문에 끊임없는 연구와 모색이 필요하고 여러분도 함께 많이 나누고 가르침을 많이 받아야 합니다!당신과 함께 노력하겠습니다!
다음에서 시작합니다.https://blog.51cto.com/cangzihu/1888622