linux java提高recv q,linux – 使用Recv-Q和Send-Q

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

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

解决方法:

从我的手册页：

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实现(通常在操作系统级别)问题.

请注意,如果我的Linux TCP实现行为不端并且在TCP窗口下降到0后继续发送数据,上面描述的Send-Q场景也可能是发送方问题(我方)：接收方没有更多的空间这个数据 – >不承认.

另请注意,Send-Q问题可能不是由于接收器引起的,而是由发送方和接收方之间的某些路由问题引起的.一些数据包在两台主机之间“在运行中”,但尚未确认.另一方面,Recv-Q问题绝对是在主机上：收到的数据包,已确认,但尚未从应用程序中读取.

编辑：

在现实生活中,对于你可以合理预期的非蹩脚的主机和应用程序,我敢打赌Send-Q问题大部分时间是由于发送方和接收方之间的某些路由问题/网络性能不佳引起的.永远不要忘记“正在运行”的数据包状态：

>数据包可能位于发送方和接收方之间的网络上,

>(或收到但ACK还没发送,见上文)

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

它需要RTT(往返时间)才能发送数据包然后进行确认.

标签：netstat,linux,networking,unix

来源： https://codeday.me/bug/20190930/1835134.html