uTorrent menyebabkan DNS berhenti bekerja sesekali


8

Saat menggunakan uTorrent, DNS berhenti merespons secara berkala.

Masalahnya tampaknya tidak terkait dengan penggunaan bandwidth terlalu banyak (seperti yang terlihat dari router ke komputer), tetapi mungkin terkait dengan beberapa bentuk perlindungan banjir yang disediakan oleh router (lebih banyak koneksi masuk ke router daripada yang akan diterima Windows).

Bagaimana cara mendapatkan jaringan agar berfungsi dengan baik (tentu saja masih bisa menggunakan uTorrent)?


Apa yang memberitahu Anda bahwa Anda tidak dapat menyelesaikan nama domain? Apakah nslookup google.combekerja? Jika tidak, bagaimana nslookup google.com 8.8.8.8? Silakan tambahkan output dari perintah-perintah itu ke pertanyaan Anda.
Bob

@ Bob ping tidak bisa menyelesaikan nama, saya tidak tahu tentang perintah nslookup, saya akan memeriksa setelah berhenti bekerja, (un) untungnya itu berfungsi sekarang. Terima kasih!
Andrey

Saat Anda melakukannya, catat alamat IP dari situs mana pun yang Anda uji dan coba ping alamat IP ketika turun (tidak akan terlalu masalah, tetapi tidak ada salahnya untuk memeriksa).
Bob

@ Bob saya melakukannya, saya tahu IP dari satu situs yang saya kunjungi. Jadi itu benar-benar DNS.
Andrey

@ Bob bisa Anda melihat pertanyaan yang diperbarui?
Andrey

Jawaban:


13

klien bittorent secara agresif terhubung ke rekan-rekan ... dan beberapa router menafsirkan ini sebagai syn-banjir.


Buka Koneksi

Ketika uTorrent dimuat dan unggahan / unduhan dijeda (tidak dihentikan) ia mempertahankan koneksi terbuka dengan rekan-rekan Anda. Sementara legiun rekan-rekan internet masih akan berusaha untuk terhubung dengan Anda untuk mengetahui apakah Anda memiliki bit yang mereka inginkan.

Akhirnya Anda akan mencapai batas koneksi terbuka yang diberlakukan oleh OS Anda (pada Windows 7 ini adalah 10 koneksi) dan koneksi dari klien baru akan mulai mengantri di router Anda.

Klien yang antri akan memeriksa secara agresif untuk melihat apakah koneksi gratis. Polling agresif ini dapat diartikan sebagai serangan syn-flood oleh router.

Solusi

  • turunkan batas koneksi setengah terbuka Anda di perangkat lunak bittorent Anda di bawah batas koneksi yang dikenakan oleh OS Anda
  • nonaktifkan perlindungan banjir IP di router / modem Anda.

Saturasi Bandwidth

Selain itu, dengan koneksi uTorrent (atau lalu lintas massal) berjalan tanpa batas, pipa unggahan (dan mungkin unduhan) mencapai penggunaan penuh, memaksa lalu lintas "pemeliharaan" untuk mengambil kursi belakang, yang pada akhirnya mengurangi kegunaan jaringan.

Berikut ini sebuah contoh:

  1. Unduhan berkecepatan tinggi (torrent atau lainnya) memenuhi tautan hilir.
  2. Pengguna mencoba menjelajah ke situs yang belum lama dikunjungi. Komputer membuat permintaan untuk info DNS untuk situs yang diinginkan. "Unggah" permintaan ke server DNS berhasil (tidak ditantang untuk akses pipa hulu).
  3. Server DNS merespons (atau mencoba), tetapi respons terputus saat mencoba masuk ke mesin pengguna karena pipa unduhan dipenuhi dengan konten unduhan, dan karena ada sesuatu yang harus dijatuhkan, dan unduhan itu agresif untuk mempertahankan kecepatan, Respons DNS dijatuhkan (pada titik tertentu sebelum sampai ke router lokal).

Hal yang sama dapat terjadi jika unggahan tidak dibatasi. Dengan unggahan yang jenuh, paket yang dikenal sebagai TCP-ACK (yang dikirim sebagai "Hei, saya mendapat paket xyz berhasil" ketik tanggapan) terhenti, membuat unduhan terhenti, menyebabkan penjelajahan web menjadi sangat tambal sulam.

Solusi

  • Cari tahu apa kemampuan maksimum koneksi Anda (naik dan turun, satu per satu), dan tetapkan kecepatan maksimum klien transfer massal Anda untuk tidak menggunakan lebih dari sekitar 80% dari kecepatan itu. Ini akan meninggalkan "ruang kepala" untuk hal-hal seperti paket DNS dan TCP-ACK untuk memotong lalu lintas massal dan ditangani dengan cepat.
  • Gunakan router yang dapat menangani pembentukan lalu lintas sehingga lalu lintas tertentu (DNS, IMCP Ping, TCP-ACK) dapat diprioritaskan di depan bentuk lalu lintas lain, dan beberapa bentuk lalu lintas (khususnya torrent) dapat di-prioritaskan. Ini adalah metode yang saya sukai. Hal ini dapat memberikan manfaat tambahan dengan memungkinkan pipa penuh naik dan turun dapat digunakan untuk lalu lintas torrent ketika lalu lintas prioritas yang lebih tinggi tidak menantangnya.
  • Gunakan beberapa kombinasi 1 dan 2 untuk menahan lalu lintas "nakal".

Jika tertarik dengan info lebih lanjut tentang distro traffic Linux / BSD, MonoWall dan IPCop keduanya memiliki beberapa informasi yang baik.


Ini benar secara umum, tetapi dalam kasus ini bukan itu masalahnya. Semua unggahan dan unduhan dijeda. Jadi uTorrent hanya menghasilkan lalu lintas layanannya. Masalahnya adalah bahwa entah bagaimana uTorrent memaksakan peringatan positif palsu pada firewall router.
Andrey

Jika uTorrent tidak menjenuhkan pipa atas atau bawah (atau keduanya), maka seharusnya tidak menyebabkan masalah ... kecuali uTorrent dan router dengan cara UPNP (yang akan saya nonaktifkan, secara pribadi) salah mengkonfigurasi router. . Saya tidak pernah memiliki UPNP saya apa pun kecuali masalah.
killermist

@ JeremyW yang akhirnya tampak seperti jawaban. Tetapi menurunkan batas koneksi setengah terbuka tidak membantu, saya mengaturnya ke 10 tetapi DNS masih gagal berfungsi dengan baik.
Andrey

@ Andrew Atau, mungkin solusinya adalah pergi ke arah lain. Jika windows dapat menangani koneksi, tingkatkan mereka, sehingga mereka tidak terjebak di router, berubah menjadi backlog.
killermist

@killermist sementara saya setuju dengan suntingan kami, pertanyaannya adalah tidak lagi bagaimana saya bisa memiliki uTorrent dan DNS, karena saya memberikan jawaban, pertanyaannya adalah mengapa demikian.
Andrey

5

Ketika saya memiliki sesuatu seperti itu, Wireshark adalah sahabat saya.

Tetapi pertama-tama baik untuk menyadari tiga hal ini:

  • Fakta bahwa ping berfungsi tidak berarti bahwa DNS (atau layanan lain apa pun) berfungsi, dan sebaliknya.

    Itu karena ping menggunakan protokol yang sama sekali berbeda (ICMP, sementara DNS menggunakan IP dan kombinasi UDP dan TCP), pada tingkat model jaringan yang sama sekali berbeda. Apa pun yang terjadi, dari firewall pribadi Anda melalui jumlah router ke host aktual di mana layanan berjalan berpotensi dapat dikonfigurasi untuk membuang salah satu dari ini tetapi tidak yang lain (apakah itu paranoia admin atau beberapa kasus kegagalan), meskipun ini biasanya terjadi pada ICMP daripada yang lain

  • Secara umum, juga baik untuk memperjelas apakah permintaan (DNS) Anda atau balasan yang hilang.

    Nah, program khusus yang Anda gunakan harus menjelaskan ini untuk Anda, tetapi sebagai aturan umum, lebih mudah untuk melihatnya sendiri di GUI Wireshark :)

  • Seperti yang saya sebutkan, DNS biasanya menggunakan UDP sebagai cara untuk mengirimkan konten permintaan dan tanggapan.

    Berbeda dengan saudara TCP-nya, UDP didefinisikan sedemikian rupa sehingga tidak ada jaminan bahwa paket akan dikirimkan sama sekali, dan tidak ada yang harus dilakukan router (juga tidak bisa) untuk memberi tahu Anda tentang kegagalan. (Ini adalah pengorbanan untuk fitur lain dari UDP: ini sangat cepat. Router tidak harus menyimpan informasi tentang pengirim atau urutan paket, mereka hanya dengan cepat meneruskannya dan lupa. Mereka bahkan dapat dengan aman memberi mereka prioritas lebih tinggi daripada TCP.)

Biasanya hal pertama yang akan saya lakukan adalah:

  1. Mulai Wireshark
  2. Klik Opsi Tangkap
  3. Untuk filter Tangkap, atur host 1.2.3.4untuk memastikan Anda hanya menangkap lalu lintas antara Anda dan 1.2.3.4
  4. Mulai ambil
  5. Setelah Anda semua bersemangat seperti ini coba perintah Anda

Namun, berdasarkan pembaruan terakhir Anda: Saya tidak tahu software ini, tetapi saya pasti akan mencurigai klien uTorrent. Ada kemungkinan aplikasi mengirim terlalu banyak UDP sehingga mis. Beberapa batasan tercapai pada router rumah Anda dan itu mulai membuang paket-paket UDP.


Ketika Anda memiliki batas waktu atas permintaan, saya tidak yakin bahwa Wireshark dapat membantu. Dari sisi klien sepertinya server DNS hanya mengabaikan permintaan, tetapi router menjatuhkan permintaan atau tanggapan karena beberapa peringatan positif palsu pada banjir IP.
Andrey

@Andrey Anda benar bahwa Wireshark tidak akan menelepon Anda ketika paket itu hilang: apakah sedang dalam perjalanan ke sana atau dalam perjalanan kembali. Namun, dapat membantu untuk memastikan bahwa paket benar-benar meninggalkan kotak Anda, kalau-kalau sesuatu yang sangat funky terjadi. (Seperti firewall pribadi Anda adalah paranoid atau sesuatu yang lain rusak secara misterius.) Saya selalu suka meletakkan hal-hal ini persamaan ASAP;)
Alois Mahdal

3

Saya akan mencoba alat Tolok Ukur DNS dari GRC . Ini menguji server DNS yang Anda dikonfigurasi untuk digunakan, serta banyak server DNS lainnya. Tidak hanya menguji kecepatan mereka, tetapi juga keandalan mereka. Ini gratis dan tidak perlu diinstal (hanya Windows). Ada juga banyak informasi bagus tentang DNS di halaman itu juga.


Saya mencoba aplikasi ini, hasilnya aneh, biasanya sebagian besar server DNS tidak merespons. Jelas tidak mungkin semua server tiba-tiba berhenti bekerja. Ada yang salah antara saya dan server, dan saya tidak tahu apa itu.
Andrey

3

Saya ingin tahu di bagian dunia mana Anda berada, dan akan membantu memiliki hasil tracert / traceroute untuk google.com dan untuk 8.8.8.8.

Masalahnya mungkin disebabkan oleh router atau koneksi Anda ke server Google. Sifat intermiten dari masalah Anda memiliki aroma konektivitas yang buruk, tetapi ada terlalu banyak faktor ketika menganalisis masalah konektivitas Internet untuk memberi Anda jawaban langsung.

Jaringan Google terkadang menjadi kelebihan beban. Saya memiliki kasus harian di mana permintaan ke google.com habis dan perlu dimulai ulang, dan saya menggunakan server lokal untuk negara saya. Ini sebagian karena keberuntungan untuk segmen mana dari jaringan Google permintaan dialihkan, dan bahkan mungkin ada ketidakefisienan dalam algoritma distribusi-permintaan internal Google.

Mungkin cara yang sama dengan server nama Google. Meskipun Google memiliki beberapa di antaranya, permintaan tersebut dapat dialihkan ke server internal atau segmen jaringan yang kelebihan beban sementara.

Anda belum menyebutkan di bagian dunia mana Anda berada. Jika Anda tidak berada di AS, maka setiap permintaan dapat mengambil rute yang berbeda dan mungkin mengalami masalah atau keterlambatan jika tergantung pada terlalu banyak server perantara.

Belum lagi "optimasi" atau kemungkinan kekurangan ISP Anda, atau optimasi apa pun yang telah dilakukan Google untuk mempartisi beban di seluruh dunia pada server-servernya.

Menggunakan server DNS jauh dapat menghukum Anda dengan cara lain. Lihat :

Mengapa menggunakan Google DNS / OpenDNS adalah ide yang buruk
Haruskah saya menggunakan DNS ISP saya, atau Google 8.8.8.8?


2

Saya menemukan solusi, meskipun saya tidak sepenuhnya memahaminya, jika ada yang bisa menjelaskannya dengan benar, silakan posting sebagai jawaban dan saya akan memberikan hadiah kepadanya, karena jawaban lain tidak membantu.

Seperti yang saya sebutkan dalam lampiran pertanyaan, uTorrent terkait dengan masalah, karena penutupan uTorrent memecahkan masalah. Saya memutuskan untuk mencari tahu cara memperbaikinya tanpa perlu menutup uTorrent. Di utas ini dan yang ini (itu sangat relevan karena orang-orang di sana memiliki ISP dan router yang sama) Saya menemukan saran bahwa saya harus menonaktifkan perlindungan banjir IP pada router saya dan itu berhasil! Masalah dan solusinya sangat eksotis, mungkin khusus untuk router Cisco EPC3925 atau bahkan untuk ISP tertentu (populer di Eropa, itu sebabnya sulit untuk mencari sesuatu dalam bahasa Inggris).


Jika Anda menyebutkan bahwa ini hanya terjadi ketika uTorrent aktif, jawaban kami akan lebih relevan.
harrymc

@harrymc Saya tidak tahu itu di awal, ketika ditanya pertanyaan. Setelah saya menemukan bahwa itu adalah uTorrent yang menyebabkan masalah, saya segera menambahkannya ke teks pertanyaan.
Andrey
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.