QTcpSocket 高频写入减慢传输速率

Question

我正在开发一个流媒体应用程序，我得到一个帧，将其编码为 h264，然后通过 tcp 将其发送到客户端，然后客户端接收编码帧，解码并显示它。我发现，当以较小的时间间隔多次调用 write 方法时，传输速率会受到很大影响。

间隔时间在 12 毫秒到 17 毫秒之间，这是抓取一帧并对其进行编码所花费的时间。在客户端中，我正在计算读取一帧和另一帧所花费的时间。使用 12/17 毫秒，到达客户端所需的时间约为 400 毫秒。但是，如果我在写入中添加 sleep ，从 12/17 毫秒到 150 毫秒，客户端中的时间将减少到 ~150 毫秒。

所以我尝试发送一个帧，一旦客户端收到它，它就会发送一个确认，然后服务器获取下一帧。使用这种方法，延迟是相同的 ~150 毫秒。

我将数据分成指定大小的 block (目前使用 512 字节)，客户端接收 block 并使用 sha256 组装它们我确认信息正确到达，帧大小变化(VBR)从 1200 字节到 65kb。所以我的结论是，如果您对具有大量写入的套接字施加压力，传输速率会受到影响，这是正确的还是我可能做错了什么？

此外，150 毫秒相当于 6 fps，VNC 和其他流媒体应用程序如何做到这一点？他们缓冲一些帧然后播放它们？所以会有延迟，但“体验”会更高的帧率？

谢谢

Answer 1

TCP/IP 协议(protocol)栈可以自由优化其行为以权衡延迟与带宽。您没有证明您缺乏带宽，只是您收到到达数据的通知频率低于您希望的频率 - 这种希望没有技术理由。协议(protocol)本身没有任何内容可以保证数据将以任何特定大小的 block 形式到达接收端。

因此，假设您在QIODevice 上通过一次write 发送每个帧。接收端可以在一个或多个 block 中接收此数据，并且可以在任意延迟后接收此数据。而这正是您所看到的。

您发送的数据类型与性能无关:您应该能够为发送方创建一个 10 行的测试用例，为接收方创建一个类似大小的测试用例，并确认您确实收到了所有数据你想要的，只是它比你错误地期望的更大。这很好，很正常。为了保持流式传输，您应该在接收端预缓冲“足够”的数据量。