我正在boost::asio通过 TCP 连接测试与 flash 客户端和云服务器（用于软件）的连接。我与服务器的连接已经很差了 - 平均 ping 为 120 毫秒。我发现当我开始以 30 数据包/秒的速度发送 2 字节大小的数据包（没有 TCP 标头）时 - ping 平均增长到 170-200。我认为这真的很糟糕，我的连接不好和云提供商不好是造成这种高 ping 而没有任何负载的原因。你怎么看？（我测试了我的软件 - 它可以计算大约 50k 个小数据包/秒，所以软件不是问题）。
我通过 flash 客户端测量我的 ping - 发送带有时间戳的数据包并立即从服务器发送到客户端。
答案1
我与服务器的连接已经很差了 — — 平均 ping 时间为 120 毫秒。
我做了一个类似的测试www.google.com，测试了 TCP 上的响应时间，结果为 160 毫秒。Google 的连接性是否很差？TCP 的设计并不是为了实现快速响应时间。
我通过 flash 客户端测量我的 ping - 发送带有时间戳的数据包并立即从服务器发送到客户端。
TCP 的设计延迟时间最多为 200 毫秒，以提供更有效的网络利用率。除了 TCP 专门执行其设计用途之外，您无需测量任何其他内容。如果您仔细观察网络流量，您会发现大多数 TCP 数据包实际上包含的数据远不止两个字节。
您期望的行为非常低效。每秒发送 30 个数据包，每个数据包仅包含两个字节的数据，这非常愚蠢，而 TCP 不会愚蠢到这样做。
两个建议：
不要将其称为“ping”。这会让人认为这是网络往返测量，而不是 TCP 响应时间的测量。
除非您实际测量了网络流量，否则不要说“30 个数据包/秒”。当您将一些字节写入 TCP 连接时，没有理由期望它们对应于数据包。数据包是网络事物。写入 TCP 连接是应用程序事物。混淆应用程序和网络级别的概念会在您处理 TCP 时让您陷入困境。
另外，你为什么要进行这么多小的写入？将数据集中到更大的写入中。是的，TCP 会为你做到这一点，但如果你在应用程序中这样做，效率会更高。
如果您只是为了测试性能而进行这些可怕的小写入，请停止这样做。它不会给您提供有用的数据。如果这些可怕的小写入复制了您的实际使用场景并且响应时间很重要，那么您需要努力修复协议，使其具有某种意义。