如何解决客户端和服务器之间的过度延迟问题？
在一个大型的私人networking上，我控制的两个盒子之间似乎存在过多的延迟。 这会阻止向客户端提供Web服务的服务器导致超时。
查尔斯logging了一个缓慢的请求
Timing Request Start Time 03/11/10 23:21:33 Request End Time 03/11/10 23:21:33 Response Start Time 03/11/10 23:21:42 Response End Time 03/11/10 23:21:42 Duration 8.99 sec Request Duration 16 ms Response Duration 0 ms Latency 8.97 sec Speed 1.30 KB/s Response Speed ∞ KB/s Size Request Header Size 412 bytes Response Header Size 151 bytes Request Size - Response Size 11.17 KB (11436 bytes) Total Size 11.72 KB (11999 bytes) Request Compression - Response Compression - 作为一个testing，我只是试图通过浏览器获得一个423K的图像文件，但是这个下载速度太慢，它停滞不前。
如何解决问题所在？
我试过使用pingplotter 
看起来啤酒花3和4是罪魁祸首？ 我从哪里出发？
回答
如果路由器无法处理networkingTCP窗口缩放，则会发现这是运行Windows Web Server 2008 R2的客户端问题，以及已知的networking速度问题。 更新的路由器软件和问题已解决。
试图从尽可能多的不同点复制这个问题。 你可能会发现它们之间有一些共同的东西（不pipe是它们使用的服务器，交换机等）。 从每个端点收集traceroute数据。
使用洋葱方法总是更好：添加/删除图层。 你可以从客户端开始，靠近服务器。 或者相反。
确保检查错误计数的接口统计信息。 我发现启动两端的tcpdump / Wireshark并从TCP会话捕获数据包非常有用，然后比较两者。 Wireshark在指出最明显的问题（如校验错误或重传）方面做得很好。
看看pingplotter的结果，看起来主要的问题是path中的某些设备响应ICMP回应请求的速度很慢（如果＃10是你的terminal设备，你得到平均42毫秒的RTT，但你有设备在中间平均82毫秒的RTT，这可能是负载在设备上，但可能很难说）。
服务器在提供内容之前是否需要名称parsing？ 从“请求发送”到“请求已确认”似乎有9秒，唯一真正匹配的是如果服务器正在尝试查找（某种types）而不立即得到响应。
安装mtr并在客户端和服务器之间运行它，并且维护一个vesa。 您将能够看到每跳丢包和延迟。 非常有用的工具。 请注意，如果您的networking正在改变stream量，那么结果将不可靠。
如果路由器无法处理networkingTCP窗口缩放，则会发现这是运行Windows Web Server 2008 R2的客户端问题，以及已知的networking速度问题。 更新的路由器软件和问题已解决。
http://www.intel.com/support/motherboards/server/sb/CS-030717.htm