특정 사이트에서 페이지를 가져올 때 큰 지연

다음과 같은 문제가 있습니다. Hackage 에서 페이지를 검색 하면 큰 지연 (약 30 초)이 발생합니다. 추가 요청은 빠르지 만 몇 분 동안 연결하지 않으면 문제가 다시 발생합니다.

이 문제에서 흥미로운 점은 다음과 같습니다.

• 이 사이트는 특정 사이트에만 적용됩니다 (해커 지) — 다른 사이트와 비슷한 문제가 발생하지 않습니다 (그리고 꽤 많은 방문).
• 다른 곳에서 연결할 때 그러한 문제는 없습니다.

• DNS 나 연결 문제와 관련이 없습니다. 실제로 TCP 연결은 빠르게 설정됩니다. 다음 샘플 패킷 캡처에서 볼 수 있듯이 너무 오래 걸리는 HTTP 응답입니다.

    1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
    2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
    3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
    4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
    5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
    6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
    7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
    8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
    9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
   10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
   11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
   12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0
  

  ( pcap-ng 형식의 패킷 캡처 ). 이 캡처는 간단한 동안 어떤 일이 발생하는지 보여줍니다 curl http://hackage.haskell.org/packages/hackage.html.

또한 라우터 뒤에 있다는 것은 중요하지 않습니다. 직접 연결할 때도 마찬가지입니다. 연결 유형은 PPPoE입니다.

Linux와 Windows를 실행하는 3 대의 컴퓨터에서 문제를 재현했습니다.

그러한 문제를 진단하는 방법?

"30 초"와 "2 분 후"는 DNS 문제로 인해 죽은 사람입니다.

연결중인 페이지가 연결 IP에서 DNS 쿼리와 같은 작업을 수행하고 어떤 이유로 쿼리에 실패한다고 가정하면 다음과 같은 결과가 나타납니다.

• 서버 가 DNS 확인을 수행하지 않기 때문에 TCP 연결이 거의 즉시
• 스크립트는 DNS 쿼리를 실행하고 중단 됩니다.
• 30 초 후 기본 시간 초과가 만료되고 스크립트가 계속 진행됩니다 (이제 "알 수 없음").
• 후속 쿼리에서 네거티브 DNS 적중은 계속 캐시되고 1 단계가 다음 시간에 전달됩니다.
• 음의 시간 초과가 만료 된 후 (RFC 2308) 2 분에서 5 분 사이이면 다음 연결에서 새 쿼리가 발행되고 스토리가 반복됩니다.

... 이것들은 정확히 당신이 묘사하는 증상입니다.

ISP1에서 얻은 IP의 다른 ISP (예 : ISP2)에서 DNS 쿼리를 실행할 수 있습니다. 100 % 증거는 아니지만 쿼리를 완료하는 데 30 초가 걸릴 가능성이 높습니다. 이는 ISP1 DNS 서버가 외부의 쿼리에 응답하는 데 문제가 있음을 의미합니다 .

또 다른 원인은 ISP1의 DNS의 존재가 일부 (아마 잘못) 이유 Hackage하여 방화벽이 될 수있다 (에 내 옷을, 이유는 "트리거 - 행복 NETADMIN"것, 그리고 내가 이름을 이름을 수있다). 이 경우 진단하는 데 훨씬 더 많은 시간이 소요됩니다. ISP2를 통한 모든 테스트는 비정상적인 결과를 반환하지 않습니다. 이것을 Hackage로 이관해야합니다.

"MTU"에 문제가있는 것 같습니다. google "windows setting mtu"를 사용하는 경우이 이론을 테스트하는 방법을 보여주는 여러 응답을 제시하고 적절하게 MTU를 낮추십시오. (리눅스 라우터를 사용하는 경우 IPTables 명령을 생성하여 동적으로 수행 할 수 있지만 Windows는 "하지"않습니다.

나는 당신의 패킷 캡처를 반복했습니다.

사실상 패킷이 재 조립되는 동안 감지 할 수없는 작은 일시 정지가 있지만, 귀하의 패킷은 어디에도 없습니다. 또한 모든 IP 주소와 HTML을 확인했으며 모든 것이 정확하고 매우 단순하고 무해한 것으로 보입니다.

요컨대, 인터넷에 관한 한이 지연의 이유는 없습니다. 결론은 ISP에 문제가 있다는 것입니다.

가능성을 좁히기 위해 할 수있는 일은 :

1. 다른 haskell.org 패키지에 연결 하고 비슷한 지연이 있는지 확인하십시오
2. 다른 네트워크 어댑터를 사용하는 여러 컴퓨터에서 다른 라우터를 사용하십시오.
3. 같은 ISP 를 사용하는 지역의 누군가 에게 연결을 반복하도록하십시오
4. 다른 ISP 를 사용하는 지역의 누군가 에게 연결을 반복하도록하십시오
5. 이 정보와 함께이 지연에 대한 설명이 여전히없는 경우 ISP 지원 부서에 문의하여 진행 상황을 문의하십시오.

[편집하다]

haskell.org가 ETag를 전송한다는 것을 알았 으므로 첫 번째 액세스는 왜 느리지 만 다음 액세스는 빠른지 설명합니다.

여기서 이상한 부분은 ETag 요청을 전송할 때 ISP가 느려지지 않는 이유입니다. 제한된 시간 동안 haskell.org로 이동하지 않고 자체 캐시의 요청을 만족시킬 수 있습니다.

서버 문제인 것 같습니다. 그것은 나를 위해 빨리로드되었습니다. 서버가 귀하를 싫어하는지 테스트하려면 TOR 또는 HideMyAss.com과 같은 프록시에서 액세스하십시오. 빠르면 haskell.org와 집 사이에 문제가 있습니다.

실행할 수있는 또 다른 테스트는 HTML 파일, CSS 파일 또는 XML 파일과 같이 해당 사이트에서 리소스를 찾고 해당 링크를 HTML 유효성 검사기 등에 전달하는 것입니다. 타사 서비스를 가져 오는 데 시간이 오래 걸리면 가져옵니다. 서버에 문제가 있습니다.

또 다른 테스트 : DNS 캐시를 지우십시오. haskell.org의 IP 주소를 찾는 데 시간이 오래 걸립니다. ipconfig /flushdns. 또한 ping hackage.haskell.org명령 줄에서 IP 주소를 조회하는 데 걸리는 시간을 확인하십시오.

또 다른 테스트 : 쿠키를 보내지 않기 위해 Chrome 및 기타 사용자와의 개인 브라우징 세션을 엽니 다.

다른 테스트 : Chrome 또는 Opera에서 F12를 열고 네트워크 탭으로 이동 한 다음 사이트로 이동하여 각 리소스의 시간을 확인하십시오.