TIME_WAIT TCP 설정
우리는 TCP를 통해 메시지를 받아들이고 일부 내부 메시징에 TCP를 사용하는 애플리케이션을 조정하려고합니다. 부하 테스트 중에 시스템에 더 많은 동시 요청이 이루어짐에 따라 응답 시간이 크게 저하 된 다음 완전히 중지되는 것을 확인했습니다. 이 시간 동안 많은 TCP 연결이 TIME_WAIT상태에 있으며 누군가 TIME_WAIT환경 변수를 기본값 인 60 초에서 30 초로 낮추라고 제안 했습니다.
에서 내가 이해 의 TIME_WAIT설정은 기본적으로 연결이 종료 된 후 TCP 리소스가 시스템에 다시 사용할 수 있습니다 시간을 설정합니다.
나는 "네트워크 전문가"가 아니며 이것에 대해 거의 알지 못합니다. 링크 된 게시물에있는 내용이 많이 필요하지만 약간 "벙어리"입니다.
TIME_WAIT값을 0으로 설정할 수없는 이유를 이해한다고 생각 하지만 안전하게 5로 설정할 수 있습니까? 10은 어때? 이 값에 대한 "안전한"설정을 결정하는 것은 무엇입니까?- 이 값의 기본값이 60 인 이유는 무엇입니까? 나보다 훨씬 똑똑한 사람들이 이것을 합리적인 기본값으로 선택하는 데 좋은 이유가 있다고 생각합니다.
- 이 값을 재정의 할 경우 잠재적 인 위험과 이점에 대해 알아야 할 또 다른 사항은 무엇입니까?
TCP 연결은 튜플 (소스 IP, 소스 포트, 대상 IP, 대상 포트)에 의해 지정됩니다.
세션 종료 후 TIME_WAIT 상태가 발생하는 이유는 네트워크에서 사용자에게 (또는 일종의 응답을 요청할 수있는) 라이브 패킷이 여전히있을 수 있기 때문입니다. 동일한 튜플을 다시 생성하고 해당 패킷 중 하나가 나타나면 연결에 대한 유효한 패킷으로 처리됩니다 (시퀀싱으로 인해 오류가 발생할 수 있음).
따라서 TIME_WAIT 시간은 일반적으로 패킷 최대 수명의 두 배로 설정됩니다. 이 값은 네트워크가 패킷을 버리기 전에 패킷이 도달 할 수있는 최대 수명입니다.
이는 동일한 튜플을 사용하여 연결을 생성하기 전에 해당 튜플의 이전 구현에 속한 모든 패킷이 종료되도록 보장합니다.
일반적으로 사용해야하는 최소값을 지정합니다. 최대 패킷 수명은 네트워크 속성에 의해 결정됩니다. 예를 들어 패킷이 훨씬 더 멀어지기 때문에 위성 수명이 LAN 수명보다 높습니다.
일반적으로 '활성 닫기'를 실행하는 엔드 포인트 만 TIME_WAIT 상태가됩니다. 따라서 가능하면 클라이언트가 TIME_WAIT를 서버가 아닌 클라이언트에 남겨 두는 활성 닫기를 실행하도록합니다.
여기를 참조하십시오 : http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html 및자세한 내용은 http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ (나중에 TIME_WAIT를 고려하지 않는 프로토콜 설계로 인해 항상 가능하지 않은 이유도 설명합니다).
Pax는 TIME_WAIT의 이유와 기본 설정을 낮추는 데주의해야하는 이유에 대해 정확합니다.
더 나은 해결책은 소켓의 원래 끝에 사용되는 포트 번호를 변경하는 것입니다. 이렇게하면 개별 소켓을 기다리는 시간에 대해 신경 쓰지 않아도됩니다.
청취 소켓의 경우 SO_REUSEADDR을 사용하여 TIME_WAIT 소켓이 주위에 앉아 있음에도 불구하고 청취 소켓이 바인딩되도록 할 수 있습니다.
; Set the TIME_WAIT delay to 30 seconds (0x1E)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
tcp_reuse를 설정하는 것은 매개 변수 (커널 3.2 이상, 불행히도 모든 버전의 RHEL 및 XenServer가 무효화 됨)가있는 한 time_wait를 변경하는 것보다 더 유용합니다.
특히 VPN 연결 사용자의 경우 값을 낮추면 아웃 바운드 연결에서 프록시 터널이 지속적으로 다시 생성 될 수 있습니다. 기본 Linux 구성보다 낮은 기본 Netscaler (XenServer) 구성을 사용하면 Chrome에서 웹 페이지 하나를 검색하기 위해 프록시 터널을 최대 12 번 다시 만들어야하는 경우가 있습니다. Maven 및 Eclipse P2와 같이 재 시도하지 않는 애플리케이션은 실패합니다.
매개 변수의 원래 동기 (중복 방지)는 모든 TCP 요청에 타임 스탬프 포함을 지정하는 TCP RFC에 의해 중복되었습니다.
20 스레드가있는 테스트 프로그램을 사용하여 (리눅스에서) 서버 응용 프로그램을로드 테스트했습니다.
959,000 개의 연결 / 닫기주기에서 TIME_WAIT에 44,000 개의 실패한 연결과 수천 개의 소켓이있었습니다.
닫기 호출 전에 SO_LINGER를 0으로 설정하고 테스트 프로그램의 후속 실행에서 TIME_WAIT에서 연결 실패가 없었고 소켓이 20 개 미만이었습니다.
TIME_WAIT가 범인이 아닐 수도 있습니다.
int listen(int sockfd, int backlog);
Unix Network Programming Volume1에 따르면 백로 그는 완료된 연결 대기열과 불완전한 연결 대기열의 합으로 정의됩니다.
백 로그가 5라고 가정 해 보겠습니다. 3 개의 완료된 연결 (ESTABLISHED 상태)과 2 개의 불완전한 연결 (SYN_RCVD 상태)이 있고 SYN을 사용한 다른 연결 요청이있는 경우. TCP 스택은 SYN 패킷을 무시하고 다른 시간에 재전송 될 것임을 알고 있습니다. 이로 인해 성능이 저하 될 수 있습니다.
적어도 그게 제가 읽은 내용입니다. ;)
참고 URL : https://stackoverflow.com/questions/337115/setting-time-wait-tcp
'Development Tip' 카테고리의 다른 글
| 삭제하지 않고 Github 포크 해제 (0) | 2020.11.17 |
|---|---|
| 열거 형 값 검증 (0) | 2020.11.17 |
| 여러 자식 행을 하나의 행으로 결합 MYSQL (0) | 2020.11.17 |
| 자바 스크립트 개체 속성의 기본값 설정 (0) | 2020.11.16 |
| "for = id"를 사용하지 않고 레이블을 확인란과 연결할 수 있습니까? (0) | 2020.11.16 |