TCP每秒30小数据包与服务器的洪流连接

Question

我正在测试通过TCP连接与flash客户端和云服务器(boost::asio用于软件)的连接。我与服务器的连接已经非常糟糕-平均120毫秒平。我发现当我开始发送2字节大小的数据包(没有tcp头)时，速度为30包/S- ping平均增长到170-200个。我认为这是非常糟糕的，我的坏连接和坏的云提供商是为什么这么高的平没有任何负载。你认为如何？(我测试了我的软件-它可以计算大约50k小包/S，所以软件不是一个问题)。

我通过flash客户端测量我的ping --用时间戳发送数据包，并立即从服务器发送到客户端。

Answer 1

我与服务器的连接已经非常糟糕-平均120毫秒平。

我做了一个与www.google.com类似的测试，测试了TCP上的响应时间，得到了160毫秒。谷歌的连通性差吗？TCP不是为快速响应时间而设计的。

我通过flash客户端测量我的ping --用时间戳发送数据包，并立即从服务器发送到客户端。

根据设计，TCP可延迟200毫秒，以提供更有效的网络利用率。除了TCP之外，您没有测量任何东西，而是专门做它设计要做的事情。如果仔细观察网络流量，就会发现大多数TCP数据包实际上包含了两个以上字节的数据。

你正期待着极其低效的行为。每秒发送30个数据包，每个数据包只包含两个字节的数据，这是令人难以置信的愚蠢之举，而TCP不足以做到这一点。

有两项建议：

别把这叫做“平”。这让人们认为这是一种网络往返测量，而不是TCP上的响应时间测量。

不要说“30个数据包/S”，除非你实际测量了网络流量。当您将一些字节写入TCP连接时，没有理由期望它与数据包相对应。数据包是网络的东西。写入TCP连接是应用程序。当您处理TCP时，混淆应用程序和网络级别的概念确实会使您陷入困境。

还有，你为什么要写这么多小文章？将数据收集到更大的写入中。是的，TCP会为您做到这一点，但是如果您在应用程序中这样做的话，它仍然会更高效。

如果您只是做这些可怕的小写测试性能，就不要再这样做了。它不会给你有用的数据。如果这些可怕的小书写复制了您的实际使用场景，并且响应时间很重要，那么您需要致力于修复您的协议，以便它具有某种意义。