Grande ritardo nel recupero di una pagina da un determinato sito

Ho il seguente problema: quando recupero una pagina da Hackage , ottengo un grande ritardo (circa 30 secondi). Ulteriori richieste sono veloci, ma se non mi connetto ad esso per un paio di minuti, il problema ritorna.

La cosa interessante di questo problema è:

• è specifico per questo particolare sito (Hackage) - non ho un problema simile con nessun altro sito (e ne visito parecchi);
• sembra essere specifico per il mio ISP - quando mi collego da altri posti, non c'è nessun problema del genere;

• non è correlato a problemi DNS o di connettività, infatti la connessione TCP viene stabilita rapidamente; è la risposta HTTP che impiega troppo tempo, come si può vedere dalla seguente acquisizione di pacchetti di esempio:

    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
  

  ( acquisizione di pacchetti in formato pcap-ng ). Questa acquisizione mostra cosa succede durante un semplice curl http://hackage.haskell.org/packages/hackage.html.

Inoltre, non importa che sia dietro un router: è lo stesso quando mi collego direttamente. Il tipo di connessione è PPPoE.

Ho riprodotto il problema su 3 computer che eseguono Linux e Windows.

Come diagnosticare un tale problema?

"30 secondi" e "dopo due minuti" sono una suoneria morta per un problema DNS.

Se supponiamo che la pagina a cui ti stai connettendo faccia qualcosa come una query DNS sull'IP di connessione e che la query non riesca per qualche motivo, vedresti:

• Connessione TCP quasi istantanea poiché il server non esegue controlli DNS
• lo script esegue una query DNS e si blocca .
• dopo 30 secondi il timeout predefinito scade e lo script continua (ora sei "Sconosciuto")
• sulle query successive, l'hit DNS negativo viene ancora memorizzato nella cache e la fase 1 viene passata in un batter d'occhio
• dopo la scadenza del timeout negativo (RFC 2308), compreso tra 2 e 5 minuti, al successivo collegamento viene emessa una nuova query e la trama si ripete.

... e questi sono esattamente i sintomi che stai descrivendo.

Puoi provare a eseguire una query DNS da un altro ISP (ad esempio, ISP2) sull'IP ottenuto da ISP1. Non è una prova al 100%, ma mi aspetto molto probabile che il completamento della query richiederà 30 secondi. Ciò significherebbe che il server DNS ISP1 sta riscontrando problemi nel rispondere alle query dall'esterno .

Un'altra possibile causa potrebbe essere il fatto che il DNS di ISP1 sia protetto da firewall da Hackage per qualche motivo (probabilmente errato) (nel mio vestito, il motivo sarebbe "un netadmin che fa scattare il grilletto" e potrei nominare i nomi). In tal caso, la diagnosi sarebbe molto più difficile, poiché qualsiasi test tramite ISP2 non restituirebbe nulla di insolito; dovresti inoltrarlo a Hackage.

Il problema sembra un problema con "MTU". Se google "windows setting mtu" dovresti trovare una serie di risposte che ti mostreranno come testare questa teoria e abbassare il tuo MTU come appropriato. (Se stessi usando un router Linux, potrei produrre un comando IPTables per farlo dinamicamente per te, ma non "faccio" Windows.)

Ho ripetuto la cattura dei pacchetti, che appare così dalla mia parte:

In effetti c'è una piccola pausa non rilevabile mentre il pacchetto viene riassemblato, ma da nessuna parte quanto la tua. Ho anche verificato tutti gli indirizzi IP e HTML e tutto è corretto e sembra estremamente semplice e innocuo.

In breve, non c'è motivo di questo ritardo, per quanto riguarda Internet. La conclusione è che c'è un problema con il tuo ISP.

Quello che puoi fare per restringere le possibilità è:

1. Prova a connetterti a un altro pacchetto haskell.org e vedi se c'è un ritardo simile
2. Prova a utilizzare un altro router da casa tua con diversi computer utilizzando diverse schede di rete
3. Cerca di avere qualcuno nella tua zona che utilizza lo stesso ISP per ripetere la connessione
4. Cerca di avere qualcuno nella tua zona che utilizza un altro ISP per ripetere la connessione
5. Con queste informazioni, se non si hanno ancora spiegazioni per questo ritardo, contattare il Supporto del proprio ISP per chiedere cosa sta succedendo.

[MODIFICARE]

Ho notato che haskell.org invia un ETag , quindi questo spiega perché il primo accesso è lento ma i successivi sono veloci: Perché finché ETag è valido, la pagina proviene effettivamente dalla cache del tuo browser.

La parte strana qui è perché l'ISP non è lento quando trasmette una richiesta ETag. Una spiegazione potrebbe essere che per un periodo di tempo limitato soddisfano la richiesta dalla propria cache, anziché andare su haskell.org.

Sembra un problema con il server. Mi ha caricato velocemente. Per verificare se il server non ti piace, prova ad accedervi da un proxy, come TOR o HideMyAss.com. Se è veloce, allora c'è un problema tra haskell.org e la tua casa.

Un altro test che puoi eseguire è trovare una risorsa in quella vista come file HTML, file CSS o file XML e passare quel link a un validatore HTML, ecc. Se i servizi di terze parti impiegano molto tempo a recuperare, allora è un problema con il server.

Un altro test: svuota la cache DNS. È possibile che la ricerca dell'indirizzo IP di haskell.org richieda molto tempo. ipconfig /flushdns. Prova anche ping hackage.haskell.orgdalla riga di comando per vedere quanto tempo ci vuole per cercare l'indirizzo IP.

Un altro test: aprire una sessione di navigazione privata con Chrome (e altri) per evitare l'invio di cookie.

Un altro test: Apri F12 in Chrome o Opera, vai alla scheda Rete, quindi vai al sito per vedere l'ora di ogni risorsa.