Windows TCP:诊断TCP网络瓶颈

我正在实现一个客户机-服务器解决方案，其中服务器不断地通过TCP向客户机发送消息流

当我进行一些测试并通过代码直接在内存中连接客户机和服务器时，我获得了非常高的吞吐量。当我在网络上使用TCP时，我得到的吞吐量要低得多。这并不奇怪。然而，我很难诊断和理解瓶颈在哪里

客户端接收消息的速度似乎不如服务器生成消息的速度快。服务器太快了。如果我停止服务器发送更多消息，我可以看到，实际上，即使服务器停止发送消息（在应用程序级别），客户机仍会在几秒钟（最多20秒！）内从服务器接收一些消息。 因此，我猜测TCP试图变得更聪明，并且正在限制服务器消息速率，导致消息排队（有趣的是，在服务器上）

我如何才能真正验证这是真的发生了什么？如何以编程方式检测这种情况？还是用工具？ 我在Windows XP下运行，在“网络接口”类别下发现了一个名为“输出队列长度”的Windows性能计数器：“输出数据包队列的长度（以数据包为单位）”。 但是，这始终保持为0（服务器和客户端）

还有一件事，我希望发送方和接收方都有较高的CPU使用率，但并没有那么高。我再次猜测这是因为网络的副作用。 是否有任何方法来衡量TCP处理（校验和等）所产生的开销

---

让您了解一下，服务器每秒发送大约150万字节。

这是通过internet还是通过本地网络？20秒延迟听起来很奇怪，你确定它不在你的应用程序中吗？另外，您是否可以尝试修改服务器以使用UDP，并查看是否得到相同的结果？客户端和服务器是否在同一网络上，或者两者之间是否有路由器？它们之间最慢的连接速度是多少？网络堆栈中有许多位置可以进行缓冲，但20秒听起来相当极端。您是根据客户端的行为来查看数据包的时间，还是使用数据包捕获工具？它位于直接的内部本地网络上，没有路由器。我无法更改为UDP，我正在使用内置的库来处理TCP。我可以查看数据包，但检查网络发送和接收字节/秒的性能计数器以及一些自定义性能计数器。