下面描述了我所遇到的最奇怪的网络问题。
故事
我正在与一位客户合作，他报告说从今天早上开始无法查看电子邮件。两周前，他们完成了一次大型升级，更换了所有 PC，并在 Windows 域中添加了一台新的 SBS 服务器。
客户端使用 Windows 7 上的 Outlook 2010 通过 POP3 获取电子邮件，但未收到邮件。发送/接收进度窗口显示下载停滞在完成度约 1% 处。
我尝试使用客户端连接到 POP3 服务器telnet，并观察到了类似的行为。发出命令后，RETR 1我看到小块数据（约 1K）通过，中间的停顿越来越长。在数据块之间，停顿的长度似乎加倍了——我观察到停顿持续了 1、3、7、14 和 28 秒。之后我停止了计数。
telnet在同一域中的终端服务器（Svr 2008 Std）上执行相同的 POP3 消息下载测试得出了相同的结果。
然后上传了一个小型 PHP 脚本，该脚本会将任意长度的页面返回到互联网上的服务器，并尝试从 LAN 上的终端服务器访问它。我测试了从 1K 到 1MB 的各种大小，没有观察到任何停顿。HTTP 似乎不受影响。
最后，我将我的个人笔记本电脑（不是域成员）插入网络并再次尝试 POP3 测试——整个消息立即下载。
更新（2011-03-10）
我今天使用 Wireshark 清晰地捕获了 POP3 对话的数据包。初始对话（USER、PASS、LIST）按预期工作，服务器立即响应。（LIST 的结果包含在一个数据包中。）发出 RETR 命令并开始传输消息后，延迟就开始了。我之前的估计稍有偏差，延迟实际上是预期的持续时间：1、2、4、8、16 秒等。客户端在收到每个数据包后的 200 毫秒内立即发送 ACKS。
此外，我们尝试将其中一个受影响的工作站直接连接到互联网，它能够全速下载消息。此时，我强烈怀疑路由器（Cisco 1711）有问题，但我对 IOS 了解不够，无法进行进一步诊断。
我知道的
- 对于网络外的客户端来说，POP3 服务器运行正常。
- 电缆调制解调器正在提供全速连接。
- 路由器可能没有出现故障，因为当我将自己的机器连接到网络时，它工作正常。
- L2 交换机以千兆速度传输 LAN 流量。
- 只有新安装的计算机才会出现问题。
- 新电脑安装大约两周后就出现了这个问题。
我不知道
- 到底是什么原因造成这种停滞？
答案1
以管理员身份从客户端的命令行运行以下命令：
netsh interface tcp set global autotuninglevel=disabled
这会禁用 TCP 窗口缩放吗？问题仍然存在吗？如果没有，则问题出在客户端和服务器之间的网络设备中，包括电缆、网络接口及其驱动程序、交换机和路由器。
答案2
是否安装了某种软件防火墙或防病毒软件？它可能会拦截所有端口 110 流量，以便针对其病毒数据库运行。它可能会导致速度变慢。它像这样分块 1kb 的方式表明，如果它是 AV，它可能会占用 CPU/磁盘 IO/等。
尝试启动资源监视器（启动任务管理器（Ctrl+Shift+Esc）、性能、资源监视器）并观察 CPU 和磁盘的进程列表，以查看下载消息时是否有任何特定进程激增。（我建议仍然使用 telnet 进行测试，以避免使用 Outlook/等污染数据。）
您可能还想使用数据包嗅探器查看流量以获取更多线索。我想知道客户端（由于 AV 或其他原因）是否在向服务器的数据包返回 ACK 时速度非常慢，这导致了TCP 拥塞避免继续增加退避，从而增加每个数据包之间的延迟。据我所知，略大于 1KB 就足以让您接近最大段大小（单个数据包的大小），这就可以解释为什么您每次“突发”只能接收那么多数据。（免责声明：我在这方面的知识已经过时了。不要太依赖它。）
如果是 TCP 退避，也可能是由于丢包，但我怀疑所有新机器的电缆都坏了或出了什么问题。似乎更有可能是软件问题，因为我猜它们都出现了类似的问题。
编辑：根据提供的信息和 adamo 的另一个回答，我找到了一篇似乎直接解决您的问题的 Microsoft 知识库文章：
KB-935400 从 Outlook 2007 或 Outlook 2010 中的 POP3 服务器下载电子邮件所花的时间比预期的要长得多
具体来说，问题在于：
“如果网络硬件设备（例如路由器）不支持 TCP 窗口缩放，就会出现此问题。TCP 窗口缩放是 Windows Vista 的一项新功能。”
运行 adamo 提供的命令是一种解决方法。看起来你也可以更新路由器。查看功能导航器在 Cisco 的网站上，您的硬件的较新 IOS 版本似乎支持 TCP 窗口缩放。如果您获取路由器的较新映像并将其刷新到那里，它应该可以解决您的问题，而不会失去 TCP 窗口缩放的好处。