uTorrentによりDNSが時々機能しなくなる

uTorrentの使用中、DNSは定期的に応答を停止します。

この問題は、帯域幅の使用量が多すぎる（ルーターからコンピューターまでの）とは関係がないようですが、ルーターによって提供される何らかの形のフラッド保護（Windowsが受け入れるよりも多くのルーターへの受信接続）に関連している可能性があります。

ネットワークを正しく機能させるにはどうすればよいですか（もちろん、もちろんuTorrentを使用できます）？

bittorentクライアントは積極的にピアに接続します...一部のルーターはこれをsyn-floodと解釈します。

接続を開く

uTorrentがロードされ、アップロード/ダウンロードが一時停止された（停止されていない）場合、ピアとのオープンな接続を維持します。その間、インターネットピアのレギオンは引き続き、必要なビットがあるかどうかを確認するために接続しようとします。

最終的には、OSによって課せられるオープン接続の制限に達し（Windows 7ではこれは10接続です）、新しいクライアントからの接続がルーターでキューイングを開始します。

キューに入れられたクライアントは、接続が解放されているかどうかを積極的にチェックします。この積極的なポーリングは、ルータによるシンフラッド攻撃として解釈される場合があります。

ソリューション

• ご使用のOSによって課された接続制限よりも、bittorentソフトウェアのハーフオープン接続制限を下げます
• ルーター/モデムでIPフラッド保護を無効にします。

帯域幅飽和

さらに、uTorrent（または任意のバルクトラフィック）接続が無制限に実行されていると、アップロード（および場合によってはダウンロード）パイプがフル使用に達し、一部の「維持」トラフィックがバックシートに強制されるため、ネットワークの有用性が低下します。

次に例を示します。

1. 高速ダウンロード（トレントなど）は、ダウンストリームリンクを飽和させます。
2. ユーザーが最近アクセスしていないサイトを閲覧しようとしました。コンピューターは、目的のサイトのDNS情報の要求を生成します。DNSサーバーへの要求の "アップロード"は成功します（上流のパイプアクセスではチャレンジされません）。
3. DNSサーバーは応答します（または試行します）が、ユーザーのマシンに到達しようとすると応答がハングします。これは、ダウンロードパイプがダウンロードコンテンツで飽和しているため、および何かをドロップする必要があり、ダウンロードは速度の維持に積極的であるため、 DNS応答が（ローカルルーターに到達する前のある時点で）ドロップされます。

アップロードが制限されていない場合も同じことが起こります。アップロードが飽和すると、TCP-ACKと呼ばれるパケット（「ねえ、パケットxyzが正常に取得されました」タイプの応答として送信されます）がハングアップし、ダウンロードが停止して、Webブラウジングが非常に不規則になります。

ソリューション

• 接続の最大機能（アップとダウン、個別）を把握し、バルク転送クライアントの最大速度を、その速度の約80％を超えないように設定します。これにより、DNSやTCP-ACKパケットなどの「ヘッドルーム」が残り、バルクトラフィックがバイパスされて迅速に処理されます。
• トラフィックシェーピングを処理できるルーターを使用して、特定のトラフィック（DNS、IMCP Ping、TCP-ACK）を他の形式のトラフィックよりも優先し、一部の形式のトラフィック（特にトレント）の優先順位を下げることができます。これは私の好みの方法です。これにより、優先度の高いトラフィックがチャレンジしない場合に、完全なアップパイプとダウンパイプをトレントトラフィックに使用できるという追加の利点が得られます。
• 1と2の組み合わせを使用して、「誤動作」トラフィックを抑制します。

Linux / BSDディストリビューションのトラフィックシェーピングに関する詳細情報に興味がある場合は、MonoWallとIPCopの両方に役立つ情報があります。

そのようなものがあったとき、Wiresharkは私の親友です。

しかし、最初にこれらの3つのことを実現するのは良いことです。

• pingが機能しているという事実は、DNS（またはその他のサービス）が機能していることを意味するわけではなく、その逆も同様です。

  これは、完全に異なるレベルのネットワークモデルでは、pingが完全に異なるプロトコル（ICMP、DNSはIPとUDPとTCPの組み合わせを使用）を使用するためです。パーソナルファイアウォールからルーターの数を経由してサービスが実行されている実際のホストに至るまでの途中で、これらのいずれかを破棄するように構成できます（管理者のパラノイアまたは何らかの障害の場合）。それは通常、他よりもむしろICMPに起こります

• 一般的に、それが（DNS）リクエストなのか、失われている返信なのかを明確にすることも有効です。

  まあ、あなたが使用している特定のプログラムはこれをあなたに明確にするはずですが、一般的には、Wireshark GUIで自分でそれを見る方が簡単です:)

• すでに述べたように、DNSは通常、要求と応答のコンテンツを配信する方法としてUDPを使用します。

  兄弟のTCPとは対照的に、UDPは 、パケットが配信されるという保証がまったくない方法で定義されており、ルーターが失敗について通知するために行う（または行うことができない）ことは何もありません。（これはUDPの別の機能の犠牲です：信じられないほど高速です。ルーターは送信者やパケットの順序に関する情報を保持する必要がなく、すぐにそれを渡して忘れてしまいます。非常に安全にそれらに高い優先順位を与えることさえできます。 TCP）

通常、私が最初に行うことは次のとおりです。

1. Wiresharkを起動する
2. [キャプチャオプション]をクリックします
3. キャプチャフィルターのhost 1.2.3.4場合、自分と1.2.3.4の間のトラフィックのみをキャプチャするように設定します
4. キャプチャを開始
5. この方法ですべてを起動したら、コマンドを試してください

ただし、前回の更新に基づいて：このソフトウェアはわかりませんが、uTorrentクライアントを疑っています。アプリケーションが大量のUDPを送信する可能性があります。たとえば、ホームルーターの制限に達し、UDPパケットが破棄され始めます。

GRCのDNSベンチマークツールを試してみます。使用するように構成されているDNSサーバーと、他の多くのDNSサーバーをテストします。速度だけでなく信頼性もテストします。これは無料で、インストールする必要はありません（ただし、Windowsのみです）。これらのページにもDNSに関する優れた情報がたくさんあります。

私はあなたが世界のどの地域にいるのか知りたいのですが、google.comと8.8.8.8でtracert / tracerouteの結果が得られると助かります。

この問題は、ルーターまたはGoogleのサーバーへの接続が原因である可能性があります。問題の断続的な性質には、接続不良の匂いがありますが、インターネット接続の問題を分析する場合、単純な答えを得るには、要素が多すぎます。

Googleのネットワークは時々過負荷になることがあります。google.comへのリクエストがタイムアウトして再起動する必要があるケースが毎日ありますが、私の国のローカルサーバーを使用しています。リクエストがルーティングされるのは、Googleのネットワークのどのセグメントへの運の問題でもあり、Googleの内部リクエスト配信アルゴリズムが非効率になる場合もあります。

それはおそらくGoogleのネームサーバーと同じ方法です。Googleにはそれらがいくつかありますが、リクエストは一時的に過負荷の内部サーバーまたはネットワークセグメントにルーティングされる可能性があります。

あなたはあなたが世界のどの地域にいるのか述べていません。米国内にいない場合、各リクエストは異なるルートを取る可能性があり、中間サーバーが多すぎると、問題が発生したり、遅延が発生したりする場合があります。

「最適化」やISPの潜在的な欠陥、あるいはGoogleがサーバーの負担を世界規模で分割するために行った最適化は言うまでもありません。

遠いDNSサーバーを使用すると、他の方法でペナルティが科せられる可能性があります。見る ：

Google DNS / OpenDNS を使用するのが悪い考えである理由
ISPのDNS、またはGoogleの8.8.8.8を使用する必要がありますか？

私はそれを完全には理解していませんが、解決策を見つけました。誰かがそれを適切に説明できる場合は、それを回答として投稿してください。他の回答が役に立たなかったため、彼に報奨金を差し上げます。

質問の付録で述べたように、uTorrentを閉じると問題が解決したため、uTorrentは問題に関連していました。私はuTorrentを閉じずに修正する方法を見つけることにしました。で、このスレッドと、この1（そこの人が同じISPやルーターを持っているので、それは非常に関連した）私は無効にする必要があることを示唆たIPフラッド保護を私のルータ上に、それがトリックをやりました！問題と解決策はエキゾチックで、おそらくルーターCisco EPC3925または特定のISP（ヨーロッパでは人気があるため、英語で何かをグーグル検索するのが困難でした）に固有です。