netstat命令输出中的Recv-Q和Send-Q列有什么用？当我们在实时场景中使用它时？在我的系统中，列的两个值始终显示为零。这是什么意思？
答案 0 :(得分：20)
从我的手册页：
的Recv-Q
Established：用户程序未复制的字节数 连接到这个插座。
倾听：从内核2.6.18开始，此列包含当前的syn 积压。
发送-Q
Established：远程未确认的字节数 主机。
倾听：自内核2.6.18起，此列包含最大大小 同步积压。
如果你坚持0，这只是意味着连接两端的应用程序和它们之间的网络都正常。实际的即时值可能与0不同，但是这种短暂的，逃逸的方式使你没有机会实际观察它。
现实生活场景的示例，其中可能与0不同（在已建立的连接上，但我认为您会得到这个想法）：
我最近在Linux嵌入式设备上与一个（设计不佳的）第三方设备进行了交谈。在这个第三方设备上，应用程序有时显然卡住，而不是读取它在TCP连接上收到的数据，导致其TCP窗口下降到0并在那里停留数十秒（在镜像端口之间通过wireshark观察到的现象） 2个主人）。在这种情况下：
Recv-Q：在第三方设备上运行netstat （我没有
意味着可能已经显示出增加的Recv-Q，达到一些屋顶值
另一边（我）停止发送数据因为窗口得到了
降至0，因为应用程序没有读取可用的数据
它的套接字，这些数据在TCP实现中保持缓冲
操作系统，而不是卡住的应用程序 - ＆gt; 来自接收者
方面，申请问题。
发送-Q：在我的一侧运行netstat（我没有尝试过，因为
1 / wireshark的问题很清楚，这是上面的第一个案例
和/ /这不是100％可重复的）可能显示非零
Send-Q， if OS级别的另一端TCP实现
被卡住并停止确认我的数据 - ＆gt; 来自发件人
接收TCP实施（通常在操作系统级别）问题。
请注意，上面描述的Send-Q场景也可能是发送方问题（我的身边）如果我的Linux TCP实现行为不端，并在TCP窗口下降到0后继续发送数据：接收方则没有更多空间容纳这些数据 - ＆gt;不承认。
另请注意，Send-Q问题可能不是由于接收方引起的，而是由发送方和接收方之间的某些路由问题引起的。有些数据包正在飞行中＃34;在两台主机之间，但尚未确认。 另一方面，Recv-Q问题绝对存在于主机上：收到的数据包已确认，但尚未从应用程序中读取。
修改
在现实生活中，你可以合理地预期非蹩脚的主机和应用程序，我敢打赌Send-Q问题大部分时间都是由某些路由问题/网络性能差造成的发送方和接收方。 ＆＃34;在飞行中＆＃34;永远不要忘记数据包的状态：
数据包可能位于发送方和接收方之间的网络上，
（或已收到，但尚未发送，请参见上文）
或者ACK可能在接收者和发送者之间的网络上。
需要RTT（往返时间）才能发送数据包然后进行确认。