uTorrentによりDNSが時々機能しなくなる
UTorrentを使用している間、DNSは定期的に応答を停止します。
この問題は、（ルーターからコンピューターへの）帯域幅の使用量が多すぎることとは関係がないようですが、ルーターによって提供される何らかの形のフラッド保護に関連している可能性があります（Windowsが受け入れるよりも多くのルーターへの受信接続）.
ネットワークを正しく機能させるにはどうすればよいですか（もちろん、もちろんuTorrentを使用できます）？
bittorentクライアントは積極的にピアに接続します...一部のルーターはこれをsyn-floodと解釈します。
接続を開く
UTorrentがロードされ、アップロード/ダウンロードが一時停止された（停止されていない）場合、ピアとのオープンな接続を維持します。その間、インターネットピアのレギオンは引き続き、必要なビットがあるかどうかを確認するために接続しようとします。
最終的には、OSによって課せられるオープン接続の制限に達し（Windows 7ではこれは10接続です）、新しいクライアントからの接続がルーターでキューイングを開始します。
キューに入れられたクライアントは、接続が解放されているかどうかを積極的にチェックします。この積極的なポーリングは、ルータによるsyn-flood攻撃として解釈される場合があります。
ソリューション
- ご使用のOSによって課された接続制限よりも、bittorentソフトウェアのハーフオープン接続制限を下げます
- ルーター/モデムでIPフラッド保護を無効にします。
帯域幅飽和
さらに、uTorrent（または任意のバルクトラフィック）接続が無制限で実行されていると、アップロード（および場合によってはダウンロード）パイプがフル使用に達し、一部の「維持」トラフィックがバックシートに強制されるため、ネットワークの有用性が低下します。
次に例を示します。
- 高速ダウンロード（トレントなど）により、ダウンストリームリンクが飽和状態になります。
- ユーザーが最近アクセスしていないサイトを閲覧しようとしました。コンピューターは、目的のサイトのDNS情報の要求を生成します。 DNSサーバーへの要求の "アップロード"は成功します（アップストリームパイプアクセスは要求されません）。
- 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の組み合わせを使用）を使用するためです。パーソナルファイアウォールからルーターの数を経由してサービスが実行されている実際のホストに至るまでのすべてが、潜在的にこれらの1つを捨てるように構成できますが、他のものは捨てません（管理者のパラノイアであろうと、何らかの失敗の場合であろうと）それは通常他よりICMPに起こります
一般的に、それが（DNS）リクエストなのか、失われている返信なのかを明確にするのも良いことです。
まあ、あなたが使用している特定のプログラムはあなたにこれを明確にするはずですが、一般的には、Wireshark GUIで自分でそれを見る方が簡単です:)
前述のとおり、DNSは通常、要求と応答のコンテンツを配信する方法としてUDPを使用します。
兄弟のTCPとは対照的に、UDPは、パケットがまったく配信されない保証がないように定義されており、ルーターは、失敗について通知するために（することはできません）しなければなりません。 （これは、UDPの別の機能の犠牲です：信じられないほど高速です。ルーターは、送信者やパケットの順序に関する情報を保持する必要がなく、すぐにそれを渡して忘れてしまいます。非常に安全に、優先順位をTCP）
通常、私が最初に行うことは次のとおりです。
- Wiresharkを起動する
- [キャプチャオプション]をクリックします
- キャプチャフィルタの場合、
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（ヨーロッパでは人気があるため、英語で何かをググるのが困難でした）に固有です。