查看網絡連接數：
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