UTorrentを使用している間、DNSは定期的に応答を停止します。
この問題は、(ルーターからコンピューターへの)帯域幅の使用量が多すぎることとは関係がないようですが、ルーターによって提供される何らかの形のフラッド保護に関連している可能性があります(Windowsが受け入れるよりも多くのルーターへの受信接続).
ネットワークを正しく機能させるにはどうすればよいですか(もちろん、もちろんuTorrentを使用できます)?
bittorentクライアントは積極的にピアに接続します...一部のルーターはこれをsyn-floodと解釈します。
UTorrentがロードされ、アップロード/ダウンロードが一時停止された(停止されていない)場合、ピアとのオープンな接続を維持します。その間、インターネットピアのレギオンは引き続き、必要なビットがあるかどうかを確認するために接続しようとします。
最終的には、OSによって課せられるオープン接続の制限に達し(Windows 7ではこれは10接続です)、新しいクライアントからの接続がルーターでキューイングを開始します。
キューに入れられたクライアントは、接続が解放されているかどうかを積極的にチェックします。この積極的なポーリングは、ルータによるsyn-flood攻撃として解釈される場合があります。
ソリューション
さらに、uTorrent(または任意のバルクトラフィック)接続が無制限で実行されていると、アップロード(および場合によってはダウンロード)パイプがフル使用に達し、一部の「維持」トラフィックがバックシートに強制されるため、ネットワークの有用性が低下します。
次に例を示します。
アップロードが制限されていない場合も同じことが起こります。アップロードが飽和すると、TCP-ACKと呼ばれるパケット(「ねえ、パケットxyzが正常に取得されました」タイプの応答として送信されます)がハングアップし、ダウンロードが停止して、Webブラウジングが非常に不規則になります。
ソリューション
Linux/BSDディストリビューションのトラフィックシェーピングに関する詳細情報に興味がある場合は、 MonoWall と IPCop の両方に役立つ情報があります。
私がそのようなものを持っているとき、 Wireshark は私の親友です。
しかし、最初にこれら3つのことを実現するのは良いことです。
Pingが機能しているという事実は、DNS(またはその他のサービス)が機能していることを意味するわけではなく、その逆も同様です。
これは、完全に異なるレベルのネットワークモデルでは、pingは完全に異なるプロトコル(ICMP、DNSはIPとUDPとTCPの組み合わせを使用)を使用するためです。パーソナルファイアウォールからルーターの数を経由してサービスが実行されている実際のホストに至るまでのすべてが、潜在的にこれらの1つを捨てるように構成できますが、他のものは捨てません(管理者のパラノイアであろうと、何らかの失敗の場合であろうと)それは通常他よりICMPに起こります
一般的に、それが(DNS)リクエストなのか、失われている返信なのかを明確にするのも良いことです。
まあ、あなたが使用している特定のプログラムはあなたにこれを明確にするはずですが、一般的には、Wireshark GUIで自分でそれを見る方が簡単です:)
前述のとおり、DNSは通常、要求と応答のコンテンツを配信する方法としてUDPを使用します。
兄弟のTCPとは対照的に、UDPは、パケットがまったく配信されない保証がないように定義されており、ルーターは、失敗について通知するために(することはできません)しなければなりません。 (これは、UDPの別の機能の犠牲です:信じられないほど高速です。ルーターは、送信者やパケットの順序に関する情報を保持する必要がなく、すぐにそれを渡して忘れてしまいます。非常に安全に、優先順位をTCP)
通常、私が最初に行うことは次のとおりです。
Host 1.2.3.4
自分と1.2.3.4の間のトラフィックのみをキャプチャしていることを確認しますただし、前回の更新に基づいて:このソフトウェアはわかりませんが、uTorrentクライアントを疑っています。アプリケーションが送信するUDPが多すぎる可能性があります。ホームルーターの上限に達し、UDPパケットが破棄され始めます。
GRCのDNSベンチマークツール を試してみます。使用するように構成されているDNSサーバーと、他の多くのDNSサーバーをテストします。速度だけでなく信頼性もテストします。これは無料で、インストールする必要はありません(ただし、Windowsのみです)。これらのページにもDNSに関する優れた情報がたくさんあります。
私はあなたが世界のどの地域にいるのか知りたいのですが、google.comと8.8.8.8でtracert/tracerouteの結果が得られると助かります。
この問題は、ルーターまたはGoogleのサーバーへの接続が原因である可能性があります。問題の断続的な性質には、接続不良の匂いがありますが、インターネット接続の問題を分析する場合、単純な答えを得るには、要素が多すぎます。
Googleのネットワークは時々過負荷になる可能性があります。私は毎日google.comへのリクエストがタイムアウトして再起動する必要があり、私の国のローカルサーバーを使用しています。リクエストがGoogleのネットワークのどのセグメントにルーティングされるかは、運の問題の1つであり、Googleの内部リクエスト配信アルゴリズムが非効率になる場合さえあります。
それはおそらくGoogleのネームサーバーと同じ方法です。 Googleにはそれらがいくつかありますが、リクエストは一時的に過負荷の内部サーバーまたはネットワークセグメントにルーティングされる可能性があります。
あなたはあなたが世界のどの地域にいるのか述べていません。米国内にいない場合、各リクエストは異なるルートをたどる可能性があり、中間サーバーが多すぎると、問題が発生したり、遅延が発生したりすることがあります。
ISPの「最適化」や起こり得る欠陥、またはGoogleがサーバーの負担を世界規模で分割するために行った可能性のある最適化は言うまでもありません。
遠いDNSサーバーを使用すると、他の方法でペナルティが科せられる可能性があります。見る :
Google DNS/OpenDNSを使用するのは悪い考えです
ISPのDNS、またはGoogleの8.8.8.8を使用する必要がありますか?
私はそれを完全には理解していませんが、解決策を見つけました。誰かがそれを適切に説明できる場合は、回答として投稿してください。他の回答が役に立たなかったため、彼に報奨金を差し上げます。
質問の付録で述べたように、uTorrentを閉じると問題が解決したため、uTorrentは問題に関連していました。私はuTorrentを閉じずに修正する方法を見つけることにしました。 this thread および this one (同じ人々が同じISPとルーターを持っているため、非常に関連がありました)で、無効にする必要があるという提案を見つけました私のルーターのIPフラッド保護とそれはトリックをしました!問題と解決策はエキゾチックで、おそらくルーターCisco EPC3925または特定のISP(ヨーロッパでは人気があるため、英語で何かをググるのが困難でした)に固有です。