我正在通过TCP连接testing与Flash客户端和云服务器（ boost::asio for software）的连接。 我与服务器的连接已经非常差 – 平均120ms ping。 我发现，当我开始发送2字节大小的数据包（没有TCP报头），速度为30包/秒 – 平均增长到170-200。 我认为这是非常糟糕的，我的糟糕的连接和糟糕的云提供商是没有任何负载这个高ping的原因。 你怎么看？ （我testing了我的软件 – 它可以计算大约5万个小包/秒，所以软件不是问题）。
我通过flash客户端测量我的ping – 发送带有时间戳的数据包，立即从服务器发送到客户端。
我与服务器的连接已经非常差 – 平均120ms ping。
我对www.google.com进行了类似的testing，testing了TCP的响应时间，并获得了160毫秒的时间。 Google的连接性差吗？ TCP不是为了快速响应而devise的。
我通过flash客户端测量我的ping – 发送带有时间戳的数据包，立即从服务器发送到客户端。
TCP在devise上延迟了200毫秒，以提供更有效的networking利用率。 除了TCP之外，你并没有测量任何东西，特别是做它devise要做的事情。 如果仔细观察networkingstream量，您会发现大多数TCP数据包实际上包含的数据多于两个字节。
你期待可怕的低效行为。 每秒只发送30个数据包，每个数据只包含两个字节的数据是非常愚蠢的，TCP不够愚蠢。
两点build议：
不要称之为“平”。 这使得人们认为这是一个networking往返测量，而不是TCP上的响应时间的度量。
除非实际测量networkingstream量，否则不要说“30包/秒”。 当你写一些字节到TCP连接时，没有理由期望它会对应一个数据包。 数据包是networking的东西。 写入TCP连接是应用程序的事情。 混淆应用程序和networking级别的概念在处理TCP时会让你感到困惑。
另外，你为什么这么做小写？ 将数据收集到较大的写入。 是的，TCP会为你做这件事，但是如果你在你的应用程序中这样做的话，效率会更高。
如果你只是在做这些可怕的小写入来testing性能，就停止这样做吧。 它不会给你有用的数据。 如果这些可怕的小写复制您的实际使用情况和响应时间是非常重要的，那么你需要努力修复你的协议，使其具有某种意义。