c - 使用 tcp_nodelay 发送大消息时出现奇怪的延迟

Question

我正在编写一个 c 程序，它通过 tcp 连接发送 bash shell 的输出。为了使我的程序更具响应性，我使用 setsockopt() 来启用 TCP_NODELAY，这会禁用 Nagle 的缓冲算法。这很好用，除了很少有大消息滞后。例如，如果消息超过 500 字节(可能是 512)。前 500 个字节将通过(在小消息中很快)，然后在一次接收完其余字节之前会有 1-2 秒的延迟。每收到 10-15 次大消息，这种情况只会发生一次。在服务器端，消息正在一次一个字节地写入套接字，并且所有字节都可用，所以这种行为对我来说是出乎意料的。

我最好的猜测是套接字中某处有一个 512 字节的缓冲区导致阻塞？我做了一些时间测试来查看滞后的位置，我很确定它是发生滞后的 socket 本身。服务器端的所有数据都是无阻塞写入的，但是客户端在一个滞后后接收到消息的结尾。然而，我使用 getsockopt() 来查找套接字的接收和发送缓冲区，它们远远超过 512 字节 - 分别为 66000 和 130000。在客户端，我使用 express js 在处理程序 (app.on('data', function(){})) 中接收数据。但是我读到这个 ​​express 函数不缓冲数据？

有人能猜出这是为什么吗？谢谢!

Answer 1

由于 TCP_NODELAY 意味着在不将数据组合在一起的情况下尽快将每条数据作为一个数据包发送，听起来您正在发送大量数据包。由于您一次写入一个字节，因此它可以发送只有一个字节有效负载和更大帧的数据包。这在大多数情况下都可以正常工作，但是一旦第一个数据包由于某种原因丢失，接收方就需要在 TCP 套接字上进入纠错模式以请求重新传输丢失的数据包。这将导致至少一次往返延迟，甚至可能多次延迟。听起来您对前几百个数据包(值(value) 500 字节)很幸运，然后通常会遇到第一个数据包丢失并由于纠错而减慢速度。一个简单的解决方案可能是写入更大的 block ，比如一次 10 个字节，而不是 1 个字节，这样命中丢弃数据包的机会就会小得多。然后，您会希望看到此问题的频率与仅针对大约 5000 字节左右的消息所做的一样。一般来说，设置 TCP_NODELAY 会导致事情一开始变得更快，但最终会更快地击中第一个丢弃的数据包，因为 TCP_NODELAY 不会减少您发送的每数据量的数据包数量。因此，它会增加或保持数据包数量不变，这意味着您在一定数量的数据中击中丢弃数据包的机会将会增加。在交互感觉和第一次打嗝之间有一个权衡。通过避免 TCP_NODELAY，您可以平均延迟在第一次错误重传命中之前发送的典型数据量。