QTcpSocket高频写入降低传输速率

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

间隔时间介于12 ms和17 ms之间，这是抓取帧并对其编码所需的时间。在客户端中，我正在计算读取一帧和另一帧所需的时间。使用12/17毫秒，到达客户机所需的时间约为400毫秒。但是，如果我在写操作中添加睡眠，从12/17毫秒减少到150毫秒，客户机中的时间将减少到150毫秒

所以我尝试发送一个帧，一旦客户端接收到它，它就会发送一个确认，然后服务器抓取下一个帧。使用这种方法，潜伏期在150ms左右

我将数据拆分为指定大小的块（目前使用512字节），客户端接收块并使用sha256进行组装。我确认信息正确到达，帧大小（VBR）从1200字节到65kb不等。所以我的结论是，如果你用大量的写操作来强调套接字，那么传输速率就会受到影响，这是对的还是我可能做错了什么

另外，150ms就像6fps，VNC和其他流媒体应用是如何做到的？他们缓冲一些帧然后播放它们？所以会有延迟，但“体验”会有更高的帧速率

---

感谢

TCP/IP协议栈可以自由地优化其行为，以权衡延迟和带宽。您并没有证明您缺乏带宽，只是您收到到达数据的通知的频率比您希望的要低——而这种希望没有技术上的理由。协议本身没有任何东西可以保证数据以任何特定大小的块到达接收端

因此，假设您在

QIODevice

上以单个

write

发送每个帧。接收端可以在一个或多个块中接收该数据，并且可以在任意延迟后接收该数据。这正是你所看到的

---

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

TCP/IP协议栈可以自由地优化其行为，以权衡延迟和带宽。您并没有证明您缺乏带宽，只是您收到到达数据的通知的频率比您希望的要低——而这种希望没有技术上的理由。协议本身没有任何东西可以保证数据以任何特定大小的块到达接收端

因此，假设您在

QIODevice

上以单个

write

发送每个帧。接收端可以在一个或多个块中接收该数据，并且可以在任意延迟后接收该数据。这正是你所看到的

---

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

除非您禁用缓冲，否则它们通常都使用缓冲，这会增加很多延迟。。。大概半秒钟或更长时间。为什么不更频繁地传输较大的数据块？150毫秒对于视频来说非常好。缓冲将有助于“平滑”延迟的变化。显然，它不会神奇地增加带宽，但它将以延迟为代价提供更平滑的播放。较大的缓冲区也会减少CPU负载，例如在实时音频处理中，较小的缓冲区可能会导致丢失，增加缓冲区可以显著改善这一点。我不是说对网络传输禁用缓冲，而是对流式客户端禁用缓冲。例如，默认情况下，VLC将在播放开始前缓冲或缓存一整秒钟的帧，这显然会在流延迟的基础上增加一秒钟的延迟。BTW视频流通常使用UDP，这会给您带来更好的延迟。谢谢，我会在切换到UDP之前尝试缓冲，要让UDP正常工作需要很多工作，我现在完全依赖TPC。除非您禁用它，否则它们通常都使用缓冲，这会增加很多延迟。。。大概半秒钟或更长时间。为什么不更频繁地传输较大的数据块？150毫秒对于视频来说非常好。缓冲将有助于“平滑”延迟的变化。显然，它不会神奇地增加带宽，但它将以延迟为代价提供更平滑的播放。较大的缓冲区也会减少CPU负载，例如在实时音频处理中，较小的缓冲区可能会导致丢失，增加缓冲区可以显著改善这一点。我不是说对网络传输禁用缓冲，而是对流式客户端禁用缓冲。例如，默认情况下，VLC将在播放开始前缓冲或缓存一整秒钟的帧，这显然会在流延迟的基础上增加一秒钟的延迟。BTW视频流通常使用UDP，这会给你更好的延迟。谢谢，我会在切换到UDP之前尝试缓冲，要让UDP正常工作需要很多工作，我现在完全依赖TPC。