특정 웹 사이트의 랜덤 TCP RST는 어떻게됩니까?

짧은 버전 : 특정 웹 사이트에 연결할 때 네트워크상의 한 Windows Server 2012 컴퓨터가 영구적이지만 간헐적 인 TCP RST를 받고 있습니다. 그들이 어디에서 왔는지 Dunno. 분석 및 질문에 대한 wireshark 로그를 확인하십시오.

긴 버전 :

소규모 사무실에 서비스를 제공하기 위해 서버 중 하나에서 캐싱 웹 프록시를 실행합니다. 동료가 특정 사이트에 연결할 때 많은 '연결 재설정'또는 '페이지를 표시 할 수 없습니다'오류가 발생한다고보고했지만 일반적으로 새로 고침하면 문제가 해결됩니다.

서버 자체에서 프록시되지 않은 브라우저를 시도하여 브라우저 동작을 확인한 다음 더 직접적으로 확인했습니다. 그러나 문제가있는 사이트에 대한 핑 및 추적 경로는 아무런 문제를 나타내지 않으며 문제는 TCP 연결에만 국한된 것으로 보입니다.

그런 다음 cURL을 통해 HTTP HEAD 요청을 직접 보내고 성공 빈도를 확인하여 영향을받는 사이트를 테스트하는 스크립트를 만들었습니다. 일반적인 테스트는 다음과 같습니다 (프록시되지 않은 서버에서 직접 실행).

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

장기적으로 요청의 약 60 %만이 성공하고 나머지는 컬 오류 코드 : "cURL 오류 (56) : 피어로부터 데이터를 수신 할 때 실패"와 함께 아무것도 반환하지 않습니다. 테스트 ( '더 나은 사이트'를 얻지 못한 사이트는 없었 음)는 매우 지속적이며 지금은 일주일 동안 문제를 해결하고 있으며 동료들은 몇 달 동안 문제가 있었다고보고했습니다.

우리 네트워크의 다른 컴퓨터에서 HEAD 요청 스크립트를 테스트했습니다. 문제 없습니다. 모든 연결은 테스트 목록의 모든 사이트로 연결됩니다. 그런 다음 개인 데스크톱에 프록시를 설정하고 문제가 발생한 서버에서 HEAD 요청을 실행할 때 모든 연결이 이루어집니다. 따라서 문제가 무엇이든이 서버에 매우 구체적입니다.

다음으로 연결 재설정 동작을 나타내는 웹 사이트를 격리하려고했습니다.

• 인트라넷 사이트 (192.168.xx) 중 어느 것도 연결을 끊지 않습니다.
• 테스트 한 ipv6 사이트가 연결 끊기를 테스트하지 않았습니다. (우리는 이중 스택입니다)
• 소수의 인터넷 ipv4 사이트 만 연결을 끊습니다.
• cloudflare를 CDN (테스트 한)으로 사용하는 모든 사이트는 연결을 끊습니다. (그러나 문제는 cloudflare 사이트에만 국한되지는 않습니다)

이 각도는 실제로 도움이되는 것으로 발전하지 않았으므로 다음에는 wireshark를 설치하여 요청이 실패했을 때 무슨 일이 있었는지 살펴 보았습니다. 실패한 HEAD 요청은 다음과 같습니다 (더 큰 스크린 샷 : http://imgur.com/TNfRUtX ).

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

내가 이것을 읽는 방식은 (내가 틀렸다면 정정하십시오. 실제로 내 영역이 아닙니다)는

• 웹 서버에 대한 TCP 연결을 엽니 다
• 웹 서버 ACK
• HTTP HEAD 요청이 전송됩니다
• 웹 서버 IP에서 표시된 RST 패킷이 연결을 종료합니다.
• 웹 서버가 ACK를 보낸다
• 유효한 HTTP 데이터로 HEAD 요청에 응답하기위한 웹 서버 (시도) (951 바이트 응답에는 올바른 HTTP 헤더가 포함됨)
• 웹 서버가 유효한 HTTP 응답을 재전송 (몇 초에 여러 번)하지만 연결이 RST이므로 성공할 수 없습니다

따라서 웹 서버가 유효한 RST를 보낸 경우 왜 요청을 계속 작성하려고합니까? 그리고 웹 서버가 RST를 생성하지 않았다면 도대체 무엇을 했습니까?

내가 시도한 것들은 효과가 없었습니다.

• NIC 팀 비활성화
• 네트워크 어댑터 변경 (교체 NIC가 작동하는 것으로 알려져 있음)
• 고정 IP 할당
• ipv6 비활성화
• 점보 프레임 비활성화
• 스위치와 라우터를 우회하여 어느 날 밤 모뎀에 서버를 직접 연결합니다.
• Windows 방화벽을 끕니다.
• netsh를 통한 TCP 설정 재설정
• 서버에서 실질적으로 다른 모든 서비스를 비활성화합니다. (우리는 주로 파일 서버로 사용하지만 아파치 및 몇 가지 DB가 있습니다)
• 책상에 머리를 두드리다 (반복적으로)

서버의 어떤 것이 RST 패킷을 생성하고 있다고 생각 하지만 내 인생에서 나는 그것을 찾을 수 없습니다. 내가 아는 것 같은 느낌이 든다. 왜이 서버인가? 또는 왜 일부 웹 사이트 만? 많은 도움이 될 것입니다. 여전히 궁금하지만, 궤도에서 출발하여 다시 시작하는 경향이 점점 커지고 있습니다.

아이디어 / 제안?

-감사

ECN 비트는 발신 SYN 패킷에 설정되었습니다.

명시 적 정체 알림 은 호스트가 네트워크 정체에보다 빠르게 반응 할 수 있도록하는 IP 프로토콜의 확장입니다. 15 년 전에 인터넷에 처음 소개되었지만 처음 배포 할 때 심각한 문제 가 발생했습니다. 가장 심각한 것은 ECN 비트가 설정된 SYN 패킷을 수신 할 때 많은 방화벽이 패킷을 삭제하거나 RST를 반환한다는 것 입니다.

결과적으로 대부분의 운영 체제는 최소한 나가는 연결에 대해 기본적으로 ECN을 비활성화했습니다. 결과적으로 많은 사이트 (및 방화벽 공급 업체!)가 단순히 방화벽을 고치지 않았다고 생각 합니다.

Windows Server 2012가 출시 될 때까지 Microsoft 는이 운영 체제 버전부터 기본적으로 ECN을 활성화 했습니다 .

안타깝게도 최근 메모리에 ECN에 대한 인터넷 사이트의 응답에 대한 중요한 테스트를 수행 한 사람은 아무도 없으므로 2000 년대 초반에 발생한 문제가 여전히 존재하는지 여부를 측정하기는 어렵지만 적어도 문제가 있고 트래픽이 적어도 그러한 장비를 통과하면서 시간의 일부.

내 데스크톱에서 ECN을 활성화 한 다음 Wireshark를 실행 한 후 몇 초 만에 SYN 및 ECN이 설정된 패킷에 RST를 얻은 호스트의 예를 찾았지만 대부분의 호스트는 정상적으로 작동합니다. 어쩌면 내가 직접 인터넷을 스캔하러 갈까 ...

서버에서 ECN을 비활성화하여 문제가 해결되는지 확인할 수 있습니다. 이것은 또한 DCTCP를 사용할 수 없게 만들지 만 소규모 사무실에서는 그렇게하거나 그렇게 할 필요가 거의 없습니다.

netsh int tcp set global ecncapability=disabled