netstat监控大量ESTABLISHED连接数和TIME_WAIT连接数，TCP端口状态说明

查看网络连接数：

netstat -an |wc -l

netstat -an |grep xx |wc -l        查看某个/特定ip的连接数

netstat -an |grep TIME_WAIT|wc -l    查看连接数等待time_wait状态连接数

netstat -an |grep ESTABLISHED |wc -l    查看建立稳定连接数量

查看不同状态的连接数数量：

[root@cp-nginx ~]# netstat -an | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'

LISTEN 8

ESTABLISHED 2400

FIN_WAIT1 2

TIME_WAIT 6000

查看每个ip跟服务器建立的连接数：

[root@cp-nginx ~]# netstat -nat|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn

     31 45.116.147.178

     20 45.116.147.186

     12 23.234.45.34

     11 103.56.195.17

（PS：正则解析：显示第5列，-F : 以：分割，显示列，sort 排序，uniq -c统计排序过程中的重复行，sort -rn 按纯数字进行逆序排序）

查看每个ip建立的ESTABLISHED/TIME_OUT状态的连接数：

[root@cp-nginx ~]# netstat -nat|grep ESTABLISHED|awk '{print$5}'|awk -F : '{print$1}'|sort|uniq -c|sort -rn

     24 103.56.195.17

     19 45.116.147.186

     18 103.56.195.18

     17 45.116.147.178

问题1：解决time_wait连接数大量问题

查询到time_wait连接数过多情况下，调整内核参数：/etc/sysctl.conf

vim /etc/sysctl.conf

添加以下配置文件：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 300

/sbin/sysctl -p 让参数生效，调优完成

问题2：ESTABLISHED连接数过大问题

怎么解决请求结束后依然存在大量ESTABLISHED没有被释放

初步推断是tomcat服务器回收session时出了问题，这个一般都跟服务器的Timeout设置有联系。

查看tomcat的配置文件 server.xml

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />
*****

检查配置得出20000毫秒的时候acceptCount=”100” ，明显不合理，最大连接数也太小了吧。

所以进一步优化：

connectionTimeout="20000" 改为 connectionTimeout="100"

acceptCount="100"改为acceptCount="5000"

优化完毕，继续压测…

在服务器的日常维护过程中，会经常用到下面的命令：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

显示：
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

具体每种状态什么意思，其实无需多说，看看下面这种图就明白了，注意这里提到的服务器应该是业务请求接受处理的一方：

TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不 会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得 注意的状态有两个：CLOSE_WAIT和TIME_WAIT。

1、LISTENING状态
FTP服务启动后首先处于侦听（LISTENING）状态。
2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。
3、CLOSE_WAIT
对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭
4、TIME_WAIT
我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分 段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情 况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。
目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。
5、SYN_SENT状态
SYN_SENT状态表示请求连接，当你要访问其它的计算机的服务时首先要发个同步信号给该端口，此时状态为SYN_SENT，如果连接成功了就变为 ESTABLISHED，此时SYN_SENT状态非常短暂。但如果发现SYN_SENT非常多且在向不同的机器发出，那你的机器可能中了冲击波或震荡波 之类的病毒了。这类病毒为了感染别的计算机，它就要扫描别的计算机，在扫描的过程中对每个要扫描的计算机都要发出了同步请求，这也是出现许多 SYN_SENT的原因。

参考文献：
1、https://blog.csdn.net/bluetjs/article/details/80965967 20200526
2、https://blog.csdn.net/weixin_33705053/article/details/92757593 20200526
3、https://blog.csdn.net/wenqian1991/article/details/40110703?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase 20200526