Độ trễ lớn khi tìm nạp một trang từ một trang web cụ thể

Tôi gặp vấn đề sau: khi tôi truy xuất một trang từ Hackage , tôi gặp một độ trễ lớn (khoảng 30 giây). Yêu cầu thêm rất nhanh, nhưng nếu tôi không kết nối với nó trong vài phút, vấn đề sẽ quay trở lại.

Điều thú vị về vấn đề này là:

• nó dành riêng cho trang web cụ thể này (Hackage) - Tôi không gặp vấn đề tương tự với bất kỳ trang web nào khác (và tôi truy cập khá nhiều);
• nó dường như là đặc trưng cho ISP của tôi - khi tôi kết nối từ những nơi khác, không có vấn đề nào như vậy;

• nó không liên quan đến DNS hoặc các vấn đề kết nối - trên thực tế, kết nối TCP được thiết lập nhanh chóng; đó là phản hồi HTTP mất quá nhiều thời gian, như có thể thấy từ việc chụp gói mẫu sau:

    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
  

  ( chụp gói ở định dạng pcap-ng ). Chụp này cho thấy những gì xảy ra trong một đơn giản curl http://hackage.haskell.org/packages/hackage.html.

Việc tôi đứng sau một bộ định tuyến cũng không thành vấn đề - cũng giống như vậy khi tôi kết nối trực tiếp. Kiểu kết nối là PPPoE.

Tôi đã tái tạo vấn đề trên 3 máy tính chạy Linux và Windows.

Làm thế nào để chẩn đoán một vấn đề như vậy?

"30 giây" và "sau hai phút" là một tiếng chuông báo động cho vấn đề DNS đối với tôi.

Nếu chúng tôi cho rằng trang bạn đang kết nối thực hiện một cái gì đó giống như truy vấn DNS trên IP kết nối và vì lý do nào đó không thành công, bạn sẽ thấy:

• Kết nối TCP gần như tức thời do máy chủ không thực hiện kiểm tra DNS
• đoạn script chạy một truy vấn DNS và bị kẹt .
• sau 30 giây, thời gian chờ mặc định hết hạn và tập lệnh sẽ tiếp tục (bạn hiện là "Không xác định")
• trong các truy vấn tiếp theo, lần truy cập DNS âm vẫn được lưu trong bộ nhớ cache và giai đoạn 1 được truyền vào bên cạnh không có thời gian
• sau khi hết thời gian âm (RFC 2308) và đó là bất cứ điều gì trong khoảng từ 2 đến 5 phút, một truy vấn mới được đưa ra trong kết nối tiếp theo và câu chuyện lặp lại.

... Và đây chính xác là những triệu chứng bạn đang mô tả.

Bạn có thể thử chạy truy vấn DNS từ một ISP khác (giả sử, ISP2) trên IP bạn nhận được từ ISP1. Nó không phải là bằng chứng 100%, nhưng tôi hy vọng khả năng cao là truy vấn sẽ mất 30 giây để hoàn thành. Điều đó có nghĩa là máy chủ DNS ISP1 đang gặp vấn đề khi trả lời các truy vấn từ bên ngoài .

Một nguyên nhân có thể khác có thể là DNS của ISP1 bị tường lửa bởi Hackage vì một số lý do (có thể bị nhầm lẫn) (trong trang phục của tôi , lý do sẽ là "một netadmin hạnh phúc kích hoạt" và tôi có thể đặt tên cho tên). Trong trường hợp đó, bạn sẽ khó chẩn đoán hơn nhiều, đối với mọi xét nghiệm thông qua ISP2 sẽ không có gì bất thường; bạn sẽ phải leo thang này để Hackage.

Vấn đề có vẻ như là một vấn đề với "MTU". Nếu bạn google "windows settings mtu", bạn sẽ đưa ra một số câu trả lời sẽ chỉ cho bạn cách kiểm tra lý thuyết này và hạ MTU của bạn cho phù hợp. (Nếu bạn đang sử dụng bộ định tuyến Linux, tôi có thể tạo lệnh IPTables để thực hiện việc này một cách linh hoạt cho bạn, nhưng tôi không "làm" Windows.)

Tôi đã lặp đi lặp lại các gói tin của bạn, trông giống như vậy ở phía cuối của tôi:

Thực tế, có một sự tạm dừng nhỏ không thể phát hiện được trong khi gói được lắp lại, nhưng không ở đâu miễn là của bạn. Tôi cũng đã xác minh tất cả các địa chỉ IP và HTML, và mọi thứ đều chính xác và trông cực kỳ đơn giản và vô hại.

Nói tóm lại, không có lý do cho sự chậm trễ này, khi có liên quan đến Internet. Kết luận là có vấn đề với ISP của bạn.

Những gì bạn có thể làm để thu hẹp các khả năng là:

1. Hãy thử kết nối với gói haskell.org khác và xem có độ trễ tương tự không
2. Hãy thử sử dụng bộ định tuyến khác từ vị trí của bạn với một số máy tính sử dụng các bộ điều hợp mạng khác nhau
3. Cố gắng có ai đó trong khu vực của bạn sử dụng cùng một ISP lặp lại kết nối
4. Cố gắng có ai đó trong khu vực của bạn sử dụng ISP khác lặp lại kết nối
5. Với thông tin này, nếu bạn vẫn không có lời giải thích nào cho sự chậm trễ này, hãy liên hệ với bộ phận Hỗ trợ của ISP để hỏi chuyện gì đang xảy ra.

[BIÊN TẬP]

Tôi nhận thấy rằng haskell.org gửi một ETag , vì vậy điều đó giải thích tại sao truy cập đầu tiên chậm nhưng các truy cập tiếp theo lại nhanh: Bởi vì miễn là ETag hợp lệ, trang thực sự xuất phát từ bộ đệm của trình duyệt của bạn.

Phần kỳ lạ ở đây là lý do tại sao ISP không chậm khi truyền yêu cầu ETag. Một lời giải thích có thể là trong một thời gian giới hạn, họ đáp ứng yêu cầu từ bộ đệm của chính họ, thay vì truy cập haskell.org.

Nghe có vẻ như một vấn đề máy chủ. Nó tải nhanh cho tôi. Để kiểm tra xem máy chủ có không thích bạn hay không, hãy thử truy cập nó từ proxy, chẳng hạn như TOR hoặc HideMyAss.com. Nếu nó nhanh, thì có vấn đề giữa haskell.org và nhà của bạn.

Một thử nghiệm khác mà bạn có thể chạy là tìm một tài nguyên trong tầm nhìn đó, chẳng hạn như tệp HTML, tệp CSS hoặc tệp XML và chuyển liên kết đó đến trình xác thực HTML, v.v. Nếu dịch vụ của bên thứ 3 mất nhiều thời gian để tìm nạp, thì nó là một vấn đề với máy chủ.

Một thử nghiệm khác: xóa bộ đệm DNS của bạn. Có thể tìm kiếm địa chỉ IP của haskell.org mất nhiều thời gian. ipconfig /flushdns. Cũng thử ping hackage.haskell.orgtừ dòng lệnh để xem mất bao lâu để tra cứu địa chỉ IP.

Một thử nghiệm khác: mở phiên duyệt web riêng tư với Chrome (và các phiên khác) để tránh gửi cookie.

Một thử nghiệm khác: Mở F12 trong Chrome hoặc Opera, chuyển đến tab Mạng và sau đó truy cập trang web để xem thời gian cho từng tài nguyên.