我正在开发一个流媒体应用程序，我得到一个框架，将其编码为h264，然后通过tcp将其发送到客户端，然后客户端接收编码的框架，它将其解码为显示器。我发现，当在很短的时间间隔内多次调用写入方法时，传输速率会受到很大影响。
间隔时间介于12 ms和17 ms之间，这是抓取帧并对其进行编码所需的时间。在客户端，我正在计算读取一帧和另一帧所花费的时间。使用12/17 ms到达客户端所需的时间约为400 ms。但是，如果我在写入中添加睡眠，从12/17 ms到150 ms，客户端的时间减少到~150 ms。
所以我尝试发送一个帧，一旦客户端收到它，它发送一个确认，然后服务器抓住下一帧。使用这种方法，延迟相同~150毫秒。
我将数据拆分为指定大小的块（目前使用512字节），客户端接收块并组装它们，使用sha256我确认信息到达正确，帧大小不同（VBR）从1200字节到65kb。所以我的结论是，如果你用大量写入来强调套接字，传输速率会受到影响，这是正确的还是我可能做错了什么？
除此之外，150毫秒就像是6帧/秒，VNC和其他流媒体应用程序是如何做到的？他们缓冲一些帧然后播放它们？那么会有延迟，但“体验”的帧速率会更高？
由于
答案 0 :(得分：0)
TCP / IP协议栈可以自由地优化其行为，以消除延迟与带宽之间的关系。你没有证明你缺乏带宽，只是你没有经常得到你想要的到达数据的通知 - 因为这种愿望没有技术上的理由。协议本身中的 nothing 可以保证数据以任何特定大小的块的形式到达接收端。
因此，假设您在write上的单个QIODevice中发送每个帧。接收端可以在一个或多个组块中接收该数据，并且它可以在任意延迟之后接收该数据。这正是你所看到的。
您发送的数据类型与性能无关：您应该能够为发送方创建一个10行测试用例，并为接收方创建一个类似大小的测试用例，并确认您确实收到了所有数据你想要的，只有它比你错误的期望更大的块。这很好，这很正常。要保持流式传输，您应该在接收端预先缓冲“足够”的数据量。