netstat Send-Q Recv-Q,端口状态说明

最新推荐文章于 2024-06-26 11:48:43 发布

我心依依旧

最新推荐文章于 2024-06-26 11:48:43 发布

阅读量1.2k

点赞数

分类专栏： # linux命令

本文链接：https://blog.csdn.net/a200822146085/article/details/105957847

版权

linux命令专栏收录该内容

18 篇文章 0 订阅

订阅专栏

一、Send-Q Recv-Q说明

通过netstat -anp可以查看机器的当前连接状态：

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8139            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:26837           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:1046            0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -               
tcp6       0    910 10.100.83.145:57142     10.100.83.140:80        ESTABLISHED 7072/java       
tcp6       0      0 10.100.83.145:57114     10.100.83.140:80        ESTABLISHED 7072/java       
tcp6       0    914 10.100.83.145:57117     10.100.83.140:80        ESTABLISHED 7072/java       
tcp6       0    910 10.100.83.145:57126     10.100.83.140:80        ESTABLISHED 7072/java       
tcp6       0      0 10.100.83.145:57159     10.100.83.140:80        ESTABLISHED 7072/java       
tcp6       0      0 10.100.83.145:57128     10.100.83.140:80        ESTABLISHED 7072/java

对proto，localAddress等都比较好理解，其中Recv-Q Send-Q具体是什么含义呢？为什么Send-Q时长不为0呢？不为0是不是表示网络出口阻塞了呢？针对这个问题查了下相关资料。

一个较详细的解释是：
What It Means
“Proto” is short for protocol, which is either TCP or UDP. “Recv-Q” and “Send-Q” mean receiving queue and sending queue. These should always be zero; if they’re not you might have a problem. Packets should not be piling up in either queue, except briefly, as this example shows:
tcp 0 593 192.168.1.5:34321 venus.euao.com:smtp ESTABLISHED
That happened when I hit the “check mail” button in KMail; a brief queuing of outgoing packets is normal behavior. If the receiving queue is consistently jamming up, you might be experiencing a denial-of-service attack. If the sending queue does not clear quickly, you might have an application that is sending them out too fast, or the receiver cannot accept them quickly enough.
“Local address” is either your IP and port number, or IP and the name of a service. “Foreign address” is the hostname and service you are connected to. The asterisk is a placeholder for IP addresses, which of course cannot be known until a remote host connects. “State” is the current status of the connection. Any TCP state can be displayed here, but these three are the ones you want to see。
参考：http://hi.baidu.com/woshiceo2015/item/f0130d3190b0e9c51a969661

大致的意思是：
Recv-Q Send-Q分别表示网络接收队列，发送队列。Q是Queue的缩写。
这两个值通常应该为0，如果不为0可能是有问题的。packets在两个队列里都不应该有堆积状态。可接受短暂的非0情况。如文中的示例，短暂的Send-Q队列发送pakets非0是正常状态。

如果接收队列Recv-Q一直处于阻塞状态，可能是遭受了拒绝服务 denial-of-service 攻击。
如果发送队列Send-Q不能很快的清零，可能是有应用向外发送数据包过快，或者是对方接收数据包不够快。

Recv-Q：表示收到的数据已经在本地接收缓冲，但是还有多少没有被进程取走，recv()

Send-Q：对方没有收到的数据或者说没有Ack的,还是本地缓冲区.

通过netstat的这两个值就可以简单判断程序收不到包到底是包没到还是包没有被进程recv。

二、State

State状态列有： LISTEN、ESTABLISHED 、CLOSE_WAIT、TIME_WAIT。
LISTEN、ESTABLISHED 较容易理解，一下重点说一下CLOSE_WAIT、TIME_WAIT。
CLOSE_WAIT

对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭

TIME_WAIT

我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。

目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。

/proc/sys/net/ipv4/tcp_fin_timeout
如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2 状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60 秒。2.2 内核的通常值是180 秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB 服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2 的危险性比FIN-WAIT-1 要小，因为它最多只能吃掉1.5K 内存，但是它们的生存期长些。参见tcp_max_orphans 。

/proc/sys/net/ipv4/tcp_keepalive_time
当keepalive 起用的时候，TCP 发送keepalive 消息的频度。缺省是2 小时。
/proc/sys/net/ipv4/tcp_keepalive_intvl
当探测没有确认时，重新发送探测的频度。缺省是75 秒。
/proc/sys/net/ipv4/tcp_keepalive_probes
在认定连接失效之前，发送多少个TCP 的keepalive 探测包。缺省值是9 。这个值乘以tcp_keepalive_intvl 之后决定了，一个连接发送了keepalive 之后可以有多少时间没有回应。

参考：
1、https://blog.csdn.net/sjin_1314/article/details/9853163
2、https://blog.csdn.net/bao231/article/details/84479577