linux - Recv-Q 和 Send-Q 的使用

Question

netstat 输出中的 Recv-Q 和 Send-Q 列有什么用？我如何在现实场景中使用它？

在我的系统上，两列始终显示为零。这是什么意思？

Answer 1

来 self 的手册页:

Recv-Q

Established: The count of bytes not copied by the user program connected to this socket.

Listening: Since Kernel 2.6.18 this column contains the current syn backlog.

Send-Q

Established: The count of bytes not acknowledged by the remote host.

Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.

如果您将其固定为 0，这仅意味着您的应用程序在连接的两端以及它们之间的网络都运行良好。实际的瞬时值可能不同于 0，但以一种短暂的、易变的方式，您没有机会实际观察到它。

这可能与 0 不同的现实场景示例(在已建立的连接上，但我想您会明白的):

我最近在与(设计不佳的)第三方设备通信的 Linux 嵌入式设备上工作。在这个第三方设备上，应用程序有时明显卡住了，没有读取它在 TCP 连接上收到的数据，导致它的 TCP 窗口下降到 0 并在那里停留数十秒(通过 wireshark 在镜像端口上观察到的现象) 2 个主机)。在这种情况下:

• Recv-Q: 在第三方设备上运行 netstat (我没有意思是做)可能已经显示出增加的 Recv-Q，达到某个屋顶值另一方(我)停止发送数据，因为窗口得到下降到 0，因为应用程序不读取可用的数据它的套接字，并且这些数据保留在 TCP 实现中的缓冲中操作系统，不会从接收器转到卡住的应用程序 -> 方面，应用问题。

• Send-Q: 在 我 端运行 netstat(我没有尝试，因为1/问题从 wireshark 很明显，是上面的第一个案例并且 2/这不是 100% 可重现的)可能已经显示非零Send-Q，如果操作系统级别的另一端 TCP 实现有被卡住并停止确认我的数据 -> 来自发件人端，接收 TCP 实现(通常在操作系统级别)问题。

请注意，上面描述的 Send-Q 场景也可能是发送方问题(我方)如果我的 Linux TCP 实现行为不当并在 TCP 窗口下降到 0 后继续发送数据: 接收方没有更多空间容纳此数据 -> 不确认。

另请注意，Send-Q 问题可能不是由接收方引起的，而是由发送方和接收方之间某处的某些路由问题引起的。一些数据包在 2 台主机之间“运行中”，但尚未确认。 另一方面，Recv-Q 问题肯定在主机上:数据包已收到，已确认，但尚未从应用程序中读取。

编辑:

在现实生活中，如您所料，主机和应用程序并不糟糕，我敢打赌 Send-Q 问题大部分时间是由发送之间的某些路由问题/网络性能不佳引起的和接收方。永远不要忘记数据包的“运行中”状态:

• 数据包可能在发送方和接收方之间的网络上，

• (或收到但 ACK 尚未发送，见上文)

• 或者 ACK 可能在接收方和发送方之间的网络上。

发送数据包然后确认需要一个 RTT(往返时间)。