uTorrent provoca l'interruzione occasionale del DNS


8

Durante l'utilizzo di uTorrent, il DNS smette periodicamente di rispondere.

Il problema sembra non essere correlato a un uso eccessivo della larghezza di banda (visto dal router al computer), ma potrebbe essere correlato a una qualche forma di protezione dalle inondazioni fornita dal router (più connessioni in entrata al router di quelle accettate da Windows).

Come faccio a far funzionare correttamente la rete (pur essendo in grado di usare uTorrent, ovviamente)?


Cosa ti dice che non puoi risolvere i nomi di dominio? Funziona nslookup google.com? In caso contrario, che ne dici nslookup google.com 8.8.8.8? Aggiungi l'output di questi comandi alla tua domanda.
Bob

Il ping di @Bob non è riuscito a risolvere il nome, non sapevo del comando nslookup, controllerò una volta che smette di funzionare, (un) fortunatamente ora funziona. Grazie!
Andrey,

Mentre ci sei, annota l'indirizzo IP di qualunque sito stai testando e prova a eseguire il ping dell'indirizzo IP quando scende (non importa davvero, ma non fa male a controllare).
Bob

@Bob L'ho fatto, sapevo IP di un sito che visito. Quindi è totalmente cosa DNS.
Andrey,

@Bob potresti dare un'occhiata alla domanda aggiornata?
Andrey,

Risposte:


13

i client bittorent si collegano in modo aggressivo ai peer ... e alcuni router lo interpretano come un syn-flood.


Apri connessioni

Quando uTorrent viene caricato e upload / download vengono messi in pausa (non arrestati), mantiene connessioni aperte con i tuoi colleghi. Nel frattempo legioni di colleghi di Internet cercheranno comunque di connettersi a te per scoprire se hai i bit che desiderano.

Alla fine raggiungerai il limite di connessione aperta imposto dal tuo sistema operativo (in Windows 7 sono 10 connessioni) e le connessioni da nuovi client inizieranno ad accodare sul tuo router.

I client in coda controlleranno in modo aggressivo se una connessione è gratuita. Questo polling aggressivo può essere interpretato come un attacco syn-flood dal router.

soluzioni

  • abbassa il limite di connessione semiaperta nel tuo software bittorent al di sotto del limite di connessione imposto dal tuo sistema operativo
  • disabilita la protezione IP flood dal tuo router / modem.

Saturazione della larghezza di banda

Inoltre, con la connessione uTorrent (o qualsiasi traffico di massa) in esecuzione senza restrizioni, la pipe di upload (e possibilmente download) raggiunge il pieno utilizzo, costringendo un po 'di traffico di "manutenzione" a prendere un posto indietro, che finisce per diminuire l'utilità della rete.

Ecco un esempio:

  1. Il download ad alta velocità (torrent o altro) satura il collegamento a valle.
  2. L'utente tenta di accedere a un sito non visitato di recente. Il computer genera una richiesta di informazioni DNS per il sito desiderato. Il "caricamento" della richiesta sul server DNS ha esito positivo (non contestato per l'accesso alla pipe a monte).
  3. Il server DNS risponde (o tenta di), ma la risposta viene bloccata nel tentativo di accedere al computer dell'utente perché la pipe di download è satura di contenuti di download e poiché qualcosa deve essere eliminato e il download è aggressivo nel mantenere la velocità, il La risposta DNS viene eliminata (a un certo punto prima che arrivi al router locale).

La stessa cosa può succedere se il caricamento è illimitato. Con il caricamento saturo, i pacchetti noti come TCP-ACK (che vengono inviati come "Ehi, ho ottenuto con successo i pacchetti xyz") vengono bloccati, facendo arrestare i download, facendo in modo che la navigazione sul web diventi molto irregolare.

soluzioni

  • Scopri quali sono le massime capacità della tua connessione (su e giù, individualmente) e imposta la velocità massima dei tuoi client di trasferimento di massa in modo che non utilizzino più dell'80% di quella velocità. Ciò lascerà "spazio" per cose come i pacchetti DNS e TCP-ACK per aggirare il traffico di massa e far fronte rapidamente.
  • Utilizzare un router in grado di gestire la modellizzazione del traffico in modo tale che un determinato traffico (DNS, IMCP Ping, TCP-ACK) possa essere prioritario rispetto ad altre forme di traffico e alcune forme di traffico (in particolare il torrent) possano essere prioritarie. Questo è il mio metodo preferito. Ciò può dare l'ulteriore vantaggio di consentire che l'intero tubo su e giù sia utilizzabile per il traffico torrent quando il traffico con priorità più elevata non lo sfida.
  • Usa una combinazione di 1 e 2 per limitare il traffico "a comportamento anomalo".

Se interessati a maggiori informazioni sul traffico che modella le distro Linux / BSD, MonoWall e IPCop hanno entrambe delle buone informazioni.


Questo è corretto in generale, ma in questo caso non era il problema. Tutti i caricamenti e i download sono stati messi in pausa. Quindi uTorrent ha generato solo il suo traffico di servizi. Il problema era che in qualche modo uTorrent ha forzato un allarme falso positivo sul firewall del router.
Andrey,

Se uTorrent non stava saturando il tubo su o giù (o entrambi), non avrebbe dovuto causare alcun problema ... a meno che uTorrent e il router tramite UPNP (che avrei disabilitato, personalmente) stessero configurando erroneamente il router . Non ho MAI avuto UPNP altro che un problema.
assassino

@JeremyW che finalmente sembra una risposta. Ridurre il limite di connessione semiaperta non ha aiutato, li ho impostati su 10 ma DNS non ha funzionato correttamente.
Andrey,

@Andrey O forse la soluzione è andare nella direzione opposta. Se Windows è in grado di gestire le connessioni, aumentale, in modo che non vengano intrappolate nel router, trasformandosi in arretrati.
assassino

@killermist mentre sono d'accordo con le nostre modifiche, la domanda non è più come posso avere sia uTorrent che DNS, perché ho dato una risposta, la domanda è più perché è così.
Andrey,

5

Quando ho qualcosa del genere, Wireshark è il mio migliore amico.

Ma prima è bene realizzare queste tre cose:

  • Il fatto che il ping funzioni non significa che il DNS (o qualsiasi altro servizio) funzioni e viceversa.

    Questo perché ping utilizza un protocollo completamente diverso (ICMP, mentre DNS utilizza IP e una combinazione di UDP e TCP), a un livello completamente diverso di modello di rete. Qualunque cosa sulla strada, dal tuo firewall personale attraverso il numero di router all'host reale in cui è in esecuzione il servizio, può potenzialmente essere configurata per eliminare uno di questi ma non l'altro (che si tratti della paranoia dell'amministratore o di un caso di errore), anche se di solito succede piuttosto all'ICMP che ad altri

  • In generale, è anche bene chiarire se sono le tue richieste (DNS) o le risposte a perdersi.

    Bene, il particolare programma che stai usando dovrebbe renderti chiaro questo, ma come regola generale, è più facile vederlo da solo nella GUI di Wireshark :)

  • Come ho già detto, DNS normalmente utilizza UDP come modo per fornire i contenuti di richiesta e risposta.

    Contrariamente al suo fratello TCP, UDP è definito in modo tale che non vi sia alcuna garanzia che il pacchetto verrà consegnato affatto, e non c'è nulla che un router non debba (né possa) fare per informarvi del fallimento. (Questo è un sacrificio per un'altra caratteristica di UDP: è incredibilmente veloce. I router non devono conservare alcuna informazione sul mittente né sull'ordine dei pacchetti, li trasmettono e dimenticano rapidamente. Possono persino dare loro una priorità più sicura rispetto a TCP.)

Di solito la prima cosa che farei sarebbe:

  1. Avvia Wireshark
  2. Fai clic su Opzioni di acquisizione
  3. Per il filtro Acquisisci, host 1.2.3.4assicurati di catturare solo il traffico tra te e 1.2.3.4
  4. Inizia l'acquisizione
  5. Una volta che hai acceso tutto in questo modo, prova i tuoi comandi

Tuttavia, in base al tuo ultimo aggiornamento: non conosco questo software, ma sospetterei sicuramente il client uTorrent. È possibile che un'applicazione invii troppi UDP che, ad esempio, un limite viene raggiunto sul router di casa e inizia a eliminare i pacchetti UDP.


Quando hai dei timeout per le richieste, non sono sicuro che Wireshark possa aiutarti. Dal lato client sembra che il server DNS ignori solo le richieste, ma il router elimina le richieste o le risposte a causa di un falso avviso positivo sull'inondazione IP.
Andrey,

@Andrey Hai ragione sul fatto che Wireshark non ti chiamerà dove si è perso il pacchetto: se era sulla strada o sulla via del ritorno. Tuttavia, può essere sicuro che i pacchetti abbiano effettivamente lasciato la tua scatola, nel caso succeda qualcosa di veramente strano. (Come se il tuo firewall personale sia paranoico o qualcos'altro sia misteriosamente rotto.) Mi piace sempre mettere queste cose al di
sopra

3

Vorrei provare lo strumento DNS Benchmark da GRC . Verifica i server DNS che sei configurato per l'utilizzo, oltre a molti altri server DNS. Non solo verifica la loro velocità, ma anche la loro affidabilità. È gratuito e non deve essere installato (è solo Windows). Ci sono anche molte buone informazioni sul DNS anche su quelle pagine.


Ho provato questa app, i risultati sono strani, di solito la maggior parte dei server DNS non risponde. Ovviamente è impossibile che tutti i server improvvisamente smettano di funzionare. Qualcosa non va tra me e i server e non so cosa potrebbe essere.
Andrey,

3

Vorrei sapere in quale parte del mondo ti trovi, e sarebbe utile avere un risultato tracert / traceroute per google.com e per 8.8.8.8.

Il problema potrebbe essere causato dal tuo router o dalla tua connessione ai server di Google. La natura intermittente del tuo problema ha l'odore della cattiva connettività, ma ci sono semplicemente troppi fattori quando si analizzano i problemi di connettività Internet per darti una risposta immediata.

La rete di Google può occasionalmente sovraccaricare. Ho casi quotidiani in cui una richiesta a google.com scade e deve essere riavviata e utilizzo il suo server locale per il mio paese. In parte è una questione di fortuna a quale segmento della rete di Google viene instradata la richiesta e potrebbero esserci persino inefficienze negli algoritmi di distribuzione delle richieste interni di Google.

Probabilmente è allo stesso modo con i server dei nomi di Google. Sebbene Google ne abbia diversi, la richiesta può essere indirizzata a un server interno o un segmento di rete sovraccaricato momentaneamente.

Non hai menzionato in quale parte del mondo ti trovi. Se non ci si trova negli Stati Uniti, ogni richiesta potrebbe seguire una strada diversa e potrebbero verificarsi problemi o ritardi occasionali se dipendenti da troppi server intermedi.

Per non parlare di eventuali "ottimizzazioni" o possibili carenze del proprio ISP o di eventuali ottimizzazioni che Google potrebbe aver fatto per suddividere l'onere in tutto il mondo sui propri server.

L'uso di un server DNS remoto può penalizzarti in altri modi. Vedi:

Perché usare Google DNS / OpenDNS è una cattiva idea
Dovrei usare il mio ISP DNS o Google 8.8.8.8?


2

Ho trovato la soluzione, anche se non la capisco del tutto, se qualcuno può spiegarla correttamente, per favore pubblicala come risposta e gli darò generosità, perché altre risposte non hanno aiutato.

Come ho accennato nell'appendice della domanda, uTorrent era legato al problema, perché la chiusura di uTorrent ha risolto il problema. Ho deciso di scoprire come risolverlo senza dover chiudere uTorrent. In questo thread e in questo (è stato molto rilevante perché le persone hanno lo stesso ISP e router) ho trovato suggerimenti per disabilitare la protezione da inondazioni IP sul mio router e ha funzionato! Il problema e la soluzione erano esotici, forse specifici per il router Cisco EPC3925 o persino per un particolare ISP (popolare in Europa, ecco perché era difficile google qualcosa in inglese).


Se avessi detto che ciò accade solo quando uTorrent è attivo, le nostre risposte sarebbero state più pertinenti.
harrymc,

@harrymc All'inizio non lo sapevo quando mi hanno fatto una domanda. Una volta scoperto che è uTorrent sta causando problemi l'ho immediatamente aggiunto al testo della domanda.
Andrey,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.