使用Recv-Q和Send-Q

从我的手册页：

的recv-Q

已建立：连接到此套接字的用户程序未复制的字节数。

监听：从2.6.18内核开始，这一列包含了当前的syn backlog。

发送-Q

已建立：远程主机未确认的字节数。

监听：从2.6.18内核开始，此列包含syn backlog的最大大小。

如果你坚持到0，这意味着你的应用程序，在连接的两端，以及它们之间的网络，都是OK的。 实际的瞬间值可能与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实现（通常在操作系统级）的问题。

请注意， 如果我的Linux TCP实现不正常，并且在TCP窗口下降到0之后继续发送数据，则上面描述的Send-Q场景也可能是发送端问题（我的一面）：接收端没有更多空间这个数据 – >不确认。

还要注意，Send-Q问题可能不是因为接收方，而是由发送方和接收方之间的某个路由问题引起的 。 一些数据包在两个主机之间“即时”，但尚未确认。 另一方面，Recv-Q问题确定在主机上：数据包已接收，已确认，但尚未从应用程序中读取。

编辑：

在现实生活中，如果您可以合理预期的是非蹩脚的主机和应用程序， 我敢打赌，由于发送和接收端之间的一些路由问题/网络性能差，大部分时间都会导致Send-Q问题。 永远不要忘记数据包的“动态”状态：

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

• （或收到，但ACK还没有发送，见上）

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

需要RTT（往返时间）来发送数据包，然后进行确认。