uTorrent导致DNS偶尔停止工作

使用uTorrent时，DNS会定期停止响应。

该问题似乎与带宽使用过多（从路由器到计算机）无关，但可能与路由器提供的某种形式的洪泛保护有关（与Windows相比，到路由器的传入连接更多）。

如何使网络正常工作（当然，仍然可以使用uTorrent）？

棘手的客户端积极地连接到对等节点，并且某些路由器将其解释为同步洪水。

打开连接

当uTorrent加载并且上载/下载被暂停（而不是停止）时，它保持与对等方的开放连接。同时，许多互联网同行仍会尝试与您建立联系，以了解您是否拥有他们想要的东西。

最终，您将达到由操作系统施加的开放连接限制（在Windows 7中为10个连接），并且来自新客户端的连接将开始在路由器上排队。

排队的客户端将积极检查连接是否空闲。这种积极的轮询可能被解释为路由器的同步洪水攻击。

解决方案

• 将Bittorent软件中的半开连接限制降低到低于操作系统所施加的连接限制
• 在路由器/调制解调器上禁用IP泛洪保护。

带宽饱和

此外，在不受限制地运行uTorrent（或任何大流量）连接的情况下，上载（并可能是下载）管道已充分使用，从而迫使某些“维持”流量退居二线，最终降低了网络的实用性。

这是一个例子：

1. 高速下载（torrent或其他）会使下游链接饱和。
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是我最好的朋友。

但是首先要意识到这三件事：

• 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 Benchmark工具。它会测试您配置为使用的DNS服务器以及许多其他DNS服务器。它不仅测试它们的速度，还测试它们的可靠性。它是免费的，不需要安装（尽管仅Windows）。在这些页面上也有很多关于DNS的很好的信息。

我想知道您位于世界的哪一部分，这对于google.com和8.8.8.8的tracert / traceroute结果会有所帮助。

您的路由器或与Google服务器的连接都可能导致此问题。您的问题的断断续续的性质具有连接不良的味道，但是在分析Internet连接问题时，因素太多，无法为您提供直接的答案。

Google的网络有时会变得负担沉重。我每天都会遇到对google.com的请求超时并且需要重新启动的情况，并且确实在我的国家/地区使用其本地服务器。将请求路由到Google网络的哪个部分部分是运气的问题，而且Google内部的请求分配算法甚至可能效率低下。

Google的名称服务器可能采用相同的方式。尽管Google有其中几个，但请求可能会路由到暂时超负荷的内部服务器或网络段。

您没有提到您位于世界的哪一部分。如果您不在美国，则每个请求可能采用不同的路线，并且如果依赖于过多的中间服务器，则可能会偶尔遇到问题或延迟。

更不用说您的ISP的任何“优化”或可能的缺陷，或者Google为在全球范围内划分其服务器负担而进行的任何优化。

使用远程DNS服务器可能会以其他方式对您造成不利影响。见：

为什么使用Google DNS / OpenDNS是一个坏主意，
我应该使用ISP的DNS还是Google的8.8.8.8？

我找到了解决方案，尽管我不完全理解它，但是如果有人可以正确解释它，请将其发布为答案，我会赏金给他，因为其他答案没有帮助。

正如我在问题附录中提到的那样，uTorrent与问题有关，因为关闭uTorrent可以解决问题。我决定找出解决方法，而无需关闭uTorrent。在此线程和这个（这是非常相关的，因为那里有相同的ISP和路由器的人），我发现的建议，我应该禁用IP防洪我的路由器，它的伎俩！问题和解决方案很奇怪，可能特定于路由器Cisco EPC3925或什至特定的ISP（在欧洲很受欢迎，这就是为什么很难用英语搜索某些东西的原因）。