netstat的输出中Recv-Q和Send-Q列的用途是什么？在实际情况下如何使用它？
在我的系统上，两列始终显示为零。那是什么意思？
最佳答案
从我的手册页:
如果您将其设置为0，则仅表示连接两侧的应用程序以及它们之间的网络都正常。实际的即时值可能不同于0，但是以一种 transient ，逃逸的方式，您没有机会实际观察到它。
现实场景中的示例可能不同于0(在已建立的连接上，但我想您会明白的):
我最近在一个Linux嵌入式设备上工作，该设备与(设计不良的)第三方设备通信。在此第三方设备上，应用程序有时有时卡住，没有读取它在TCP连接上接收到的数据，导致其TCP窗口下降到0，并在那里停留了数十秒钟(现象是通过Wireshark在镜像端口之间观察到的2个主机)。在这种情况下:
netstat的(我没有的意思)可能会显示Recv-Q有所增加，直至达到一定的屋顶值(value)
另一端(我)停止发送数据的位置，因为该窗口
降至0，因为应用程序不会读取以下位置上的可用数据
它的套接字，并且这些数据保留在TCP实现中的缓冲中
操作系统，而不是从接收器转到卡住的应用程序->
方面，应用程序问题。
netstat(我没有尝试过，因为1/这个问题从wireshark很明显，并且是上面的第一种情况
和2/这不是100％可复制的)可能显示为非零
Send-Q，如果操作系统级别的另一端TCP实现具有
被卡住并停止确认我的数据->来自发件人
方面，收到TCP实现(通常在OS级别)问题。
请注意，如果我的Linux TCP实现行为异常并且在TCP窗口降至0后仍继续发送数据，则上述Send-Q场景也可能是发送方的问题(我这边):接收方没有更多空间此数据->不确认。
还请注意，Send-Q问题可能不是由接收方引起的，而是由发送方和接收方之间某处的路由问题引起的。有些数据包在2个主机之间“运行中”，但尚未确认。另一方面，Recv-Q问题明确地在主机上发生:已接收，已确认但尚未从应用程序读取的数据包。
编辑:
在现实生活中，如您合理预期的那样，如果主机和应用程序不灵活，我敢打赌，Send-Q问题大部分时间是由于发送方和接收方之间的某些路由问题/网络性能不佳引起的。永远不要忘记数据包的“运行中”状态:
发送数据包然后进行确认需要RTT(往返)。
关于linux - 使用Recv-Q和Send-Q，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36466744/