서버가 SYN 패킷에 대한 응답으로 SYN / ACK 패킷을 보내지 않는 이유

최근에 우리는 웹 사이트를 탐색하는 mac 및 Linux 사용자로 주로 제한되는 TCP 연결 문제를 알게되었습니다.

사용자 관점에서 볼 때, 그것은 우리 웹 사이트와의 연결 시간이 정말 길다 (> 11 초).

이 문제의 기술적 인 서명을 추적했지만 문제가 발생하는 이유 또는 해결 방법을 파악할 수 없습니다.

기본적으로 클라이언트 시스템이 TCP 연결을 설정하기 위해 SYN 패킷을 보내고 웹 서버가이를 수신하지만 SYN / ACK 패킷으로 응답하지 않습니다. 클라이언트가 많은 SYN 패킷을 보낸 후 서버는 마지막으로 SYN / ACK 패킷으로 응답하며 나머지 연결에는 문제가 없습니다.

물론 문제에 대한 키커 : 간헐적이며 항상 발생하지는 않습니다 (시간의 10-30 % 사이에 발생하지만)

우리는 Fedora 12 Linux를 OS로 사용하고 Nginx를 웹 서버로 사용하고 있습니다.

wireshark 분석의 스크린 샷

최신 정보:

클라이언트에서 창 크기 조정을 끄면 문제가 발생하지 않았습니다. 이제 서버 측 해상도가 필요합니다 (모든 클라이언트 가이 작업을 수행 할 수는 없습니다) :)

최종 업데이트 :

해결책은 공개적으로 액세스 할 수있는 서버에서 TCP 창 스케일링 과 TCP 타임 스탬프 를 모두 끄는 것이 었습니다 .

우리도 똑같은 문제가있었습니다. TCP 타임 스탬프를 비활성화하면 문제가 해결되었습니다.

sysctl -w net.ipv4.tcp_timestamps=0

이 변경 사항을 영구적으로 적용하려면에 항목을 작성하십시오 /etc/sysctl.conf.

TCP Window Scale 옵션을 비활성화하는 데 매우주의하십시오. 이 옵션은 인터넷을 통해 최대 성능을 제공하는 데 중요 합니다. 왕복 시간 (기본적으로 핑과 동일)이 55ms 이상인 경우 10 메가 비트 / 초 연결을 가진 사람은 최적이 아닌 전송을합니다 .

동일한 NAT 뒤에 여러 장치가있을 때이 문제가 실제로 나타났습니다. 타임 스탬프 필드에 완전히 다른 값을 입력했기 때문에 서버가 Android 장치 및 OSX 시스템에서 동시에 타임 스탬프를 보는 것이 혼란 스러울 수 있습니다.

필자의 경우 다음 명령으로 Linux 서버에서 누락 된 SYN / ACK 응답 문제를 해결했습니다.

sysctl -w net.ipv4.tcp_tw_recycle=0

TCP 타임 스탬프는 고성능 (PAWS, 창 스케일링 등)에 유용하기 때문에 TCP 타임 스탬프를 비활성화하는 것보다 더 정확하다고 생각합니다 .

tcp_tw_recycle많은 IP 공유기가 타임 스탬프를 유지하므로 동일한 IP의 타임 스탬프가 일치하지 않기 때문에 PAWS가 시작되기 때문에이를 활성화하지 않는 것이 문서에 명시되어 있습니다.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

궁금한 점이 있지만 왜 SYN 패킷 (프레임 # 539; 허용 된 것)의 WS 및 TSV 필드가 "정보"열에 누락되어 있습니까?

WS는 TCP Window Scaling 이고 TSV는 Timestamp Value 입니다. 둘 다 tcp.options 필드에 있으며 Wireshark는 여전히 존재하는 경우이를 표시해야합니다. 8 번째 시도에서 클라이언트 TCP / IP 스택이 다른 SYN 패킷을 재전송했을 수 있으며 이것이 갑자기 확인 된 이유일까요?

프레임 539 내부 값을 제공 할 수 있습니까? SYN / ACK는 항상 WS를 활성화하지 않은 SYN 패킷에 제공됩니까?

우리는 똑같은 문제에 부딪 쳤습니다 (실제로 동기화를 보내지 않는 서버에 고정시키는 데 꽤 오랜 시간이 걸렸습니다).

"해결책은 일반 사용자가 액세스 할 수있는 서버에서 tcp windows 스케일링 및 tcp 타임 스탬프를 끄는 것입니다."

Ansis가 말한 것을 이행하기 위해 방화벽이 TCP Windows Scaling을 지원하지 않을 때 이와 같은 문제가 발생했습니다. 이 두 호스트 사이에 어떤 make / model 방화벽이 있습니까?

방화벽에서 SYNFLOOD 보호 한계가 너무 낮아서 누락 된 SYN / ACK가 발생할 수 있습니다. 서버 사용자에 대한 연결 수에 따라 다릅니다. spdy를 사용하면 연결 수가 줄어들고 net.ipv4.tcp_timestamps끄지 않아도 도움이 될 수 있습니다.

백 로그가 가득 찬 경우 수신 TCP 소켓의 동작입니다.

Ngnix는 백 로그 인수가 구성에서 청취되도록 허용합니다. http://wiki.nginx.org/HttpCoreModule#listen

청취 80 백 로그 = 수

1024를 기본값보다 큰 값으로 설정하십시오 (1024).

전체 청취 대기열이 실제로 문제라는 것을 보장하지는 않지만 확인하는 것이 가장 좋습니다.

방금 3 번 시도한 후 Linux TCP 클라이언트가 SYN 패킷을 변경하고 Window Scaling 옵션을 제거한다는 것을 알았습니다. 커널 개발자는 이것이 인터넷에서 연결 실패의 일반적인 원인이라고 생각했습니다.

이 클라이언트가 11 초 후에 연결하는 이유를 설명합니다 (기본 설정으로 간단한 테스트에서 9 초 후에 창없는 TCP SYN이 발생 함)

비슷한 문제가 있었지만 제 경우에는 잘못 계산 된 것이 TCP 체크섬이었습니다. 클라이언트는 veth 뒤에 있었고 ethtool -K veth0 rx off tx off를 실행하여 트릭을 수행했습니다.