从客户端PC到服务器（Windows Server 2008），WAN连接使用2 x 2 MBps E1链路。
1 <1ms <1ms <1ms 10.101.7.254 2 4ms 15ms 4ms 10.255.0.254 3 * 3ms 3ms 192.168.243.251 4 * 5ms * 192.168.242.253 5 6ms * 6ms 10.100.101.252 6 5ms 5ms 5ms 10.100.10.201 (SERVER) 当使用IIS端口80访问服务器托pipe的Web应用程序（金字塔应用程序）时，客户端电脑遇到了滞后问题。但是，使用Waitress WSGI服务器端口5432时发现连接顺畅。
我们可以注意到TIMEOUT正在3跳上发生。 这可能会导致系统响应速度缓慢。 我注意到在PING请求中接收响应超时的情况非常频繁。
Network Team提到traceroute显示了预期的networking性能。 对于广域网链路5ms远低于时延要求。 由于WAN云中的dynamicpath，dynamic路由中的traceroute超时是正常的，因此预期结果并不是networking问题。
对于这种情况，我不太确定这是应用程序devise问题还是networking问题。 任何人都可以请告诉我，我怎么能解决这个问题？ 非常感谢任何答复。
networking性能分析：你做错了。
Tracert和Ping不是networking性能分析工具。 它们是跟踪到主机的路由和testing到主机的基本连接的工具。
使用tracert作为networking性能分析工具的问题在于tracert发送ICMP数据包到路由中的每一跳。 Tracert不通过路线testing“真实”的交通。 因此，每跳可能会select忽略您的ICMPstream量，或者可能会select低优先级，这会给您带来类似于您在Tracerttesting中看到的结果。
你需要做的是testing通过路线的真实交通的performance。 你可以用iperf或者Qcheck这样的工具来做到这一点 。
你似乎有延迟和下降率混淆。 延迟是数据包通过networking所花费的时间。 丢弃率是从未交付的数据包的百分比（出于各种原因）。 你的延迟似乎很低，我不明白你为什么提到它。
你似乎有丢包问题，但你还没有提供确凿的信息。 运行ping -n 1000 -w 100 10.100.10.201 ，看看结果是什么。
在大型networking中会出现一些丢包现象，但不是很多。 如果您遇到超过1％的数据包丢失，则存在问题。 另外，不要使用“云”这个词，这意味着什么。