Saya memiliki masalah berikut: ketika saya mengambil halaman dari Hackage , saya mendapat penundaan besar (sekitar 30 detik). Permintaan lebih lanjut cepat, tetapi jika saya tidak terhubung selama beberapa menit, masalahnya kembali.
Yang menarik dari masalah ini adalah:
- itu khusus untuk situs khusus ini (Peretasan) - Saya tidak mendapatkan masalah serupa dengan situs lain (dan saya mengunjungi beberapa);
- tampaknya khusus untuk ISP saya - ketika saya terhubung dari tempat lain, tidak ada masalah seperti itu;
itu tidak terkait dengan masalah DNS atau konektivitas - pada kenyataannya, koneksi TCP dibuat dengan cepat; itu adalah respons HTTP yang terlalu lama, seperti yang dapat dilihat dari pengambilan paket sampel berikut:
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( paket capture dalam format pcap-ng ). Capture ini menunjukkan apa yang terjadi selama proses sederhana
curl http://hackage.haskell.org/packages/hackage.html.
Itu juga tidak masalah bahwa saya di belakang router - itu sama ketika saya terhubung secara langsung. Jenis koneksi adalah PPPoE.
Saya mereproduksi masalah pada 3 komputer yang menjalankan Linux dan Windows.
Bagaimana cara mendiagnosis masalah seperti itu?
Jawaban:
"30 detik" dan "setelah dua menit" adalah dering mati untuk masalah DNS bagi saya.
Jika kami mengira bahwa halaman yang Anda sambungkan melakukan sesuatu seperti permintaan DNS pada IP yang terhubung, dan permintaan itu gagal karena beberapa alasan, Anda akan melihat:
... dan ini persis gejala yang Anda gambarkan.
Anda bisa mencoba menjalankan permintaan DNS dari ISP lain (katakanlah, ISP2) pada IP yang Anda dapatkan dari ISP1. Ini bukan 100% bukti, tapi saya berharap kemungkinan tinggi bahwa kueri akan selesai 30 detik. Itu berarti bahwa server DNS ISP1 mengalami masalah dalam menjawab pertanyaan dari luar .
Penyebab lain yang mungkin adalah DNS ISP1 yang dihadang oleh Hackage untuk beberapa alasan (kemungkinan salah) (dalam pakaian saya , alasannya adalah "netadmin yang memicu trigger", dan saya dapat menyebutkan nama). Dalam hal ini Anda akan mengalami kesulitan mendiagnosis, karena tes apa pun melalui ISP2 tidak akan menghasilkan apa pun yang tidak biasa; Anda harus meningkatkan ini ke Hackage.
sumber
dig +trace -x 80.90.233.38. Saya 95% yakin bahwa ini penyebabnya, hanya menunggu konfirmasi bahwa peretasan memang melakukan pencarian DNS terbalik.Masalah terdengar seperti masalah dengan "MTU". Jika Anda google "windows setting mtu" Anda harus datang dengan sejumlah tanggapan yang akan menunjukkan kepada Anda bagaimana menguji teori ini, dan menurunkan MTU Anda yang sesuai. (Jika Anda menggunakan router Linux saya bisa menghasilkan perintah IPTables untuk melakukan ini secara dinamis untuk Anda, tetapi saya tidak "melakukan" Windows.)
sumber
Saya telah mengulangi penangkapan paket Anda, yang terlihat seperti ini pada saya:
Secara efektif ada jeda kecil yang tidak terdeteksi saat paket dipasang kembali, tetapi tidak ada tempat selama Anda. Saya juga telah memverifikasi semua alamat IP dan HTML, dan semuanya benar dan terlihat sangat sederhana dan tidak berbahaya.
Singkatnya, tidak ada alasan untuk keterlambatan ini, sejauh menyangkut Internet. Kesimpulannya adalah bahwa ada masalah dengan ISP Anda.
Apa yang dapat Anda lakukan untuk mempersempit kemungkinan adalah:
[EDIT]
Saya perhatikan bahwa haskell.org mengirimkan ETag , jadi itu menjelaskan mengapa akses pertama lambat tetapi yang berikutnya cepat: Karena selama ETag valid, halaman sebenarnya berasal dari cache browser Anda.
Bagian yang aneh di sini adalah mengapa ISP tidak lambat saat mengirimkan permintaan ETag. Penjelasan mungkin bahwa untuk waktu yang terbatas mereka memenuhi permintaan dari cache mereka sendiri, daripada pergi ke haskell.org.
sumber
Kedengarannya seperti masalah server. Ini dimuat cepat untukku. Untuk menguji apakah server tidak menyukai Anda, cobalah mengaksesnya dari proxy, seperti TOR atau HideMyAss.com. Jika cepat, maka ada masalah antara haskell.org dan rumah Anda.
Tes lain yang dapat Anda jalankan adalah menemukan sumber daya pada pandangan itu seperti file HTML, file CSS, atau file XML, dan meneruskan tautan itu ke validator HTML, dll. Jika layanan pihak ke-3 membutuhkan waktu lama untuk mengambil, maka itu masalah dengan server.
Tes lain: kosongkan cache DNS Anda. Bisa jadi mencari alamat IP haskell.org membutuhkan waktu lama.
ipconfig /flushdns. Coba jugaping hackage.haskell.orgdari baris perintah untuk melihat berapa lama waktu yang dibutuhkan untuk mencari alamat IP.Tes lain: buka sesi penelusuran pribadi dengan Chrome (dan lainnya) untuk menghindari pengiriman cookie.
Tes lain: Buka F12 di Chrome atau Opera, buka tab Network, lalu buka situs untuk melihat waktu untuk setiap sumber daya.
sumber