使用Recv-Q和Send-Q [英] Use of Recv-Q and Send-Q

问题描述

netstat输出中Recv-Q和Send-Q列的用途是什么?在实际情况下如何使用它?

What is the use of the Recv-Q and Send-Q columns in netstat's output? How do I use use this in a realistic scenario?

在我的系统上，两列始终显示为零.那是什么意思?

On my system, both of the columns are always shown as zero. What is the meaning for that?

推荐答案

在我的手册页中:

Recv-Q

Recv-Q

已建立:用户程序未复制的字节数 连接到此插座.

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

收听:从内核2.6.18开始，此列包含当前syn 积压.

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

发送Q

已建立:远程未确认的字节数 主机.

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

收听:从内核2.6.18开始，此列包含最大大小 的syn积压订单.

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

如果将其设置为0，则仅表示连接两侧的应用程序以及它们之间的网络都正常.实际的即时值可能不同于0，但是以一种瞬态，逃逸的方式，您没有机会实际观察到它.

If you have this stuck to 0, this just mean that your applications, on both side of the connection, and the network between them, are doing OK. Actual instant values may be different from 0, but in such a transient, fugitive manner that you don't get a chance to actually observe it.

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

我最近研究了一种Linux嵌入式设备，该设备与(设计不良的)第三方设备通信.在此第三方设备上，应用程序有时显然卡住了，没有读取它在TCP连接上接收到的数据，导致其TCP窗口下降到0并停留在那里数十秒(现象是通过Wireshark在镜像端口之间观察到的2个主机).在这种情况下:

I recently worked on a Linux embedded device talking to a (poorly designed) third party device. On this third party device, the application clearly got stuck sometimes, not reading the data it received on TCP connection, resulting in its TCP window going down to 0 and staying stuck there for tens of seconds (phenomenon observed via wireshark on a mirrored port between the 2 hosts). In such case:

• Recv-Q::在第三方设备上运行netstat (我没有 的意思)可能会显示Recv-Q不断提高，直至达到一定的屋顶价值 另一端(我)停止发送数据的位置，因为该窗口 降至0，因为应用程序不会读取以下位置上的可用数据 它的套接字，并且这些数据保留在TCP实现中的缓冲中 操作系统，而不是从接收器转到卡住的应用程序-> 方面，应用程序问题.

• Recv-Q: running netstat on the third party device (which I had no mean to do) may have show an increasing Recv-Q, up to some roof value where the other side (me) stop sending data because the window get down to 0, since the application does not read the data available on its socket, and these data stay buffered in the TCP implementation in the OS, not going to the stuck application -> from the receiver side, application issue.

发送Q:在我端运行netstat(我之所以没有尝试，是因为 1/从wireshark可以清楚地看出问题，并且是上面的第一种情况 和2/这不是100％可重复的)可能显示为非零 Send-Q， if 在操作系统级别的另一端TCP实现具有 被卡住并停止从发件人确认我的数据-> 方面，收到TCP实现(通常在OS级别)问题.

Send-Q: running netstat on my side (which I did not tried because 1/ the problem was clear from wireshark and was the first case above and 2/ this was not 100% reproducible) may have show a non-zero Send-Q, if the other side TCP implementation at the OS level have been stucked and stopped ACKnowleding my data -> from the sender side, receiving TCP implementation (typically at the OS level) issue.

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

Note that the Send-Q scenario depicted above may also be a sending side issue (my side) if my Linux TCP implementation was misbehaving and continued to send data after the TCP window went down to 0: the receiving side then has no more room for this data -> does not ACKnowledge.

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

Note also that the Send-Q issue may be caused not because of the receiver, but by some routing issue somewhere between the sender and the receiver. Some packets are "on the fly" between the 2 hosts, but not ACKnowledge yet. On the other hand, the Recv-Q issue is definitly on a host: packets received, ACKnowledged, but not read from the application yet.

在现实生活中，如您可以合理预期的那样，使用不笨拙的主机和应用程序，我敢打赌，在大多数情况下，Send-Q问题是由发送之间的某些路由问题/网络性能不佳引起的和接收方.永远不要忘记数据包的运行中"状态:

In real life, with non-crappy hosts and applications as you can reasonably expect, I'd bet the Send-Q issue to be caused most of the time by some routing issue/network poor performances between the sending and receiving side. The "on the fly" state of packets should never be forgotten:

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

• The packet may be on the network between the sender and the receiver,

(或已收到，但尚未发送ACK，请参见上文)

(or received but ACK not send yet, see above)

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

or the ACK may be on the network between the receiver and the sender.

发送数据包然后经过ACK需要RTT(往返).

It takes a RTT (round time trip) for a packet to be send and then ACKed.

这篇关于使用Recv-Q和Send-Q的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！