Belirli bir siteden bir sayfa getirilirken büyük gecikme

Aşağıdaki sorun var: Hackage bir sayfa aldığımda , büyük bir gecikme (yaklaşık 30 saniye) alıyorum. Diğer istekler hızlı, ancak birkaç dakika içinde bağlanmazsam sorun geri gelir.

Bu sorunla ilgili ilginç olan:

• bu belirli siteye özgü (Hackage) - Ben başka bir site ile benzer bir sorun alamadım (ve ben çok az ziyaret);
• ISS'ime özgü gibi görünüyor - başka yerlerden bağlandığımda böyle bir sorun yok;

• DNS veya bağlantı sorunları ile ilgili değildir - aslında, TCP bağlantısı hızlı bir şekilde kurulur; aşağıdaki örnek paket yakalamada görülebileceği gibi çok uzun süren HTTP yanıtıdır:

    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 formatında paket yakalama ). Bu yakalama bir basit sırasında neler olduğunu gösterir curl http://hackage.haskell.org/packages/hackage.html.

Bir yönlendiricinin arkasında olduğum da önemli değil - doğrudan bağlandığımda da aynı. Bağlantı tipi PPPoE'dir.

Sorunu Linux ve Windows çalıştıran 3 bilgisayarda yeniden oluşturdum.

Böyle bir problem nasıl teşhis edilir?

"30 saniye" ve "iki dakika sonra" bir DNS sorunu için ölü bir zil sesi.

Bağlandığınız sayfanın bağlanan IP'de DNS sorgusu gibi bir şey yaptığını varsayarsak ve bu sorgu bir nedenle başarısız olursa, şunu görürsünüz:

• Sunucu DNS kontrolleri yapmadığı için TCP bağlantısı neredeyse anlık
• komut dosyası bir DNS sorgusu çalıştırır ve takılır .
• 30 saniye sonra varsayılan zaman aşımı süresi sona erer ve kod devam eder (artık "Bilinmiyor "sunuz)
• sonraki sorgularda, negatif DNS isabeti hala önbelleğe alınır ve aşama 1 hemen geçilmez
• negatif zaman aşımı süresi dolduktan sonra (RFC 2308) ve bu 2 ile 5 dakika arasında bir şeydir, bir sonraki bağlantıda yeni bir sorgu yayınlanır ve hikaye tekrarlanır.

... ve bunlar tam olarak tanımladığınız belirtiler.

ISP1'den aldığınız IP'de başka bir ISS'den (örneğin, ISP2) bir DNS sorgusu çalıştırmayı deneyebilirsiniz. Bu% 100 kanıt değil, ancak sorgunun tamamlanması 30 saniye alacaktır. Bu, ISP1 DNS sunucusunun dışarıdan gelen sorgulara yanıt vermede sorun yaşadığı anlamına gelir .

Bir diğer olası nedeni isp1 DNS varlık bazı (olasılıkla yanlış) bir nedenle Hackage tarafından güvenlik duvarlı olabilir (içinde benim kıyafeti, nedeni "Bir sorumsuz netadmin" olacağını ve İsimleri sayabilirim). Bu durumda, tanı koymak çok daha zor olurdu, çünkü ISP2 aracılığıyla yapılan herhangi bir test olağandışı bir şey getirmez; bunu Hackage'a yükseltmeniz gerekecek.

Sorun "MTU" ile ilgili bir sorun gibi geliyor. Google "windows mtu ayarı" yaparsanız, bu teoriyi nasıl test edeceğinizi ve MTU'nuzu uygun şekilde nasıl düşüreceğinizi gösteren bir dizi yanıt bulmalısınız. (Bir Linux yönlendirici kullanıyorsanız, bunu sizin için dinamik olarak yapmak için bir IPTables komutu üretebilirdim, ancak Windows'u "yapmıyorum".)

Sonunda şu şekilde görünen paket yakalama işleminizi tekrarladım:

Paket yeniden monte edilirken etkili bir şekilde algılanamayan küçük bir duraklama var, ancak sizinki kadar hiçbir yerde yok. Ayrıca tüm IP adreslerini ve HTML'yi doğruladım ve her şey doğru ve son derece basit ve zararsız görünüyor.

Kısacası, internet söz konusu olduğunda bu gecikmenin bir nedeni yoktur. Sonuç, ISS'nizde bir sorun olduğu yönündedir.

Olanakları daraltmak için yapabileceğiniz şey:

1. Başka bir haskell.org paketine bağlanmayı deneyin ve benzer bir gecikme olup olmadığını görün
2. Farklı ağ bağdaştırıcıları kullanan birkaç bilgisayarla yerinizden başka bir yönlendirici kullanmayı deneyin
3. Bölgenizde aynı ISS'yi kullanan birinin bağlantıyı tekrar etmesini sağlayın
4. Bölgenizde başka bir ISS kullanan birinin bağlantıyı tekrar etmesini sağlayın
5. Bu bilgilerle, bu gecikme hakkında hala bir açıklamanız yoksa, neler olup bittiğini öğrenmek için ISS'nizin Destek bölümüyle iletişime geçin.

[DÜZENLE]

Haskell.org'un bir ETag gönderdiğini fark ettim , bu yüzden ilk erişimin neden yavaş olduğunu, ancak bir sonraki erişimin hızlı olduğunu açıklıyor: ETag geçerli olduğu sürece sayfa aslında tarayıcınızın önbelleğinden geliyor.

Buradaki garip kısım, bir ETag isteği iletirken ISS'nin neden yavaş olmadığıdır. Bir açıklama, sınırlı bir süre için haskell.org'a gitmek yerine kendi önbelleklerinden gelen talebi karşılamaları olabilir.

Bir sunucu sorunu gibi geliyor. Benim için hızlı yüklendi. Sunucunun sizi beğenip beğenmediğini test etmek için, sunucuya TOR veya HideMyAss.com gibi bir proxy'den erişmeyi deneyin. Hızlıysa, haskell.org ve eviniz arasında bir sorun var.

Çalıştırabileceğiniz başka bir test, HTML dosyası, CSS dosyası veya XML dosyası gibi bir görüşte bir kaynak bulmak ve bu bağlantıyı bir HTML doğrulayıcıya vb. İletmektir. 3. taraf hizmetlerin getirilmesi uzun sürüyorsa, sunucuda bir sorundur.

Başka bir test: DNS önbelleğinizi temizleyin. Haskell.org'un IP adresine bakmak uzun zaman alabilir. ipconfig /flushdns. Ayrıca ping hackage.haskell.orgIP adresini aramanın ne kadar sürdüğünü görmek için komut satırından deneyin .

Başka bir test: Çerez göndermekten kaçınmak için Chrome (ve diğerleri) ile özel bir tarama oturumu açın.

Başka bir test: Chrome veya Opera'da F12'yi açın, Ağ sekmesine gidin ve ardından her bir kaynağın saatini görmek için siteye gidin.