☰

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

tag-icon • tag-icon http
특정 사이트에서 페이지를 가져올 때 큰 지연

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

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

  • 이 특정 사이트(Hackage)에만 해당됩니다. 다른 사이트에서는 비슷한 문제가 발생하지 않습니다(그리고 꽤 많은 사이트를 방문합니다).
  • 내 ISP에만 해당되는 것 같습니다. 다른 곳에서 연결할 때는 그런 문제가 없습니다.

  • 이는 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대의 컴퓨터에서 문제를 재현했습니다.

그러한 문제를 진단하는 방법은 무엇입니까?

답변1

"30초"와 "2분 후"는 DNS 문제에 대한 데드 링어입니다.

연결하려는 페이지가 연결 IP에 대한 DNS 쿼리와 같은 작업을 수행하고 어떤 이유로 해당 쿼리가 실패한다고 가정하면 다음과 같은 메시지가 표시됩니다.

  • 이후 거의 즉시 TCP 연결이 이루어집니다.서버은(는) DNS 확인을 수행하지 않습니다
  • 스크립트가 DNS 쿼리를 실행합니다.그리고 막힌다.
  • 30초 후에 기본 제한 시간이 만료되고 스크립트가 계속됩니다(이제 "알 수 없음"임)
  • 후속 쿼리에서는 부정적인 DNS 적중이 여전히 캐시되고 1단계가 거의 시간 없이 전달됩니다.
  • 네거티브 시간 초과가 만료된 후(RFC 2308) 2~5분 사이에 다음 연결 시 새 쿼리가 실행되고 스토리가 반복됩니다.

...이것이 바로 귀하가 설명하는 증상입니다.

ISP1에서 얻은 IP에 대해 다른 ISP(예: ISP2)의 DNS 쿼리를 실행할 수 있습니다. 100% 증명은 아니지만 쿼리가 완료되는 데 30초 정도 걸릴 가능성이 높을 것으로 예상합니다. 이는 ISP1 DNS 서버가 쿼리에 응답하는 데 문제가 있음을 의미합니다.바깥으로부터.

또 다른 가능한 원인은 ISP1의 DNS가 어떤 (아마도 잘못된) 이유로 Hackage에 의해 방화벽으로 차단된 것일 수 있습니다.나의이유는 "방아쇠를 당기는 netadmin"이기 때문이며 이름을 지정할 수 있습니다). 이 경우 ISP2를 통한 모든 테스트에서는 이상한 결과가 반환되지 않으므로 진단하는 데 훨씬 더 어려움을 겪게 됩니다. 이 문제를 Hackage로 에스컬레이션해야 합니다.

답변2

문제는 "MTU" 문제인 것 같습니다. Google에서 "windows 설정 mtu"를 검색하면 이 이론을 테스트하고 적절하게 MTU를 낮추는 방법을 보여주는 여러 응답이 나와야 합니다. (Linux 라우터를 사용하는 경우 IPTables 명령을 생성하여 이 작업을 동적으로 수행할 수 있지만 Windows에서는 "실행"하지 않습니다.)

답변3

나는 귀하의 패킷 캡처를 반복했는데, 내 쪽에서는 다음과 같이 보입니다.

이미지 캡처

실제로 패킷이 재조립되는 동안 감지할 수 없는 약간의 일시 중지가 있지만 사용자의 경우만큼 길지는 않습니다. 또한 모든 IP 주소와 HTML을 확인했으며 모든 것이 정확하고 매우 단순하고 무해해 보입니다.

간단히 말해서, 인터넷에 관한 한 이러한 지연이 발생할 이유가 없습니다. 결론은 ISP에 문제가 있다는 것입니다.

가능성을 좁히기 위해 할 수 있는 일은 다음과 같습니다.

  1. 연결해 보세요또 다른 haskell.org 패키지비슷한 지연이 있는지 확인하세요.
  2. 다른 네트워크 어댑터를 사용하는 여러 대의 컴퓨터에서 다른 라우터를 사용해 보세요.
  3. 귀하의 지역에 다음을 사용하는 누군가를 두도록 노력하십시오.같은ISP가 연결을 반복합니다
  4. 귀하의 지역에 다음을 사용하는 사람을 두십시오.또 다른ISP가 연결을 반복합니다
  5. 이 정보를 바탕으로 지연에 대한 설명을 아직 알 수 없는 경우 ISP 지원팀에 문의하여 무슨 일이 일어나고 있는지 문의하세요.

[편집하다]

나는 haskell.org가 다음을 보내는 것을 발견했습니다.E태그, 첫 번째 액세스는 느리지만 다음 액세스는 빠른 이유를 설명합니다. ETag가 유효한 한 페이지는 실제로 브라우저의 캐시에서 가져오기 때문입니다.

여기서 이상한 부분은 ETag 요청을 전송할 때 ISP가 느리지 않은 이유입니다. 제한된 시간 동안 haskell.org로 이동하는 대신 자체 캐시에서 요청을 충족한다는 설명이 있을 수 있습니다.

답변4

서버 문제 같네요. 나에게는 빠르게 로드되었습니다. 서버가 사용자를 싫어하는지 테스트하려면 TOR 또는 HideMyAss.com과 같은 프록시에서 서버에 액세스해 보십시오. 속도가 빠르면 haskell.org와 귀하의 집 사이에 문제가 있는 것입니다.

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

또 다른 테스트: DNS 캐시를 지우세요. haskell.org의 IP 주소를 찾는 데 시간이 오래 걸릴 수 있습니다. ipconfig /flushdns. 또한 ping hackage.haskell.org명령줄에서 IP 주소를 찾는 데 걸리는 시간을 확인해 보세요.

또 다른 테스트: 쿠키 전송을 방지하기 위해 Chrome(및 기타)으로 비공개 브라우징 세션을 엽니다.

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

관련 정보