查看linux中的TCP鏈接數

轉載：https://www.cnblogs.com/felixzh/p/7737160.html

 

 

 

1、查看哪些IP鏈接本機

netstat -an

2、查看TCP鏈接數

1)統計80端口鏈接數
netstat -nat|grep -i "80"|wc -l

2）統計httpd協議鏈接數
ps -ef|grep httpd|wc -l

3）、統計已鏈接上的，狀態爲「established
netstat -na|grep ESTABLISHED|wc -l

4)、查出哪一個IP地址鏈接最多,將其封了.
netstat -na|grep ESTABLISHED|awk {print 5}|awk -F: {print5}|awk -F: {print1}|sort|uniq -c|sort -r +0n

netstat -na|grep SYN|awk {print 5}|awk -F: {print5}|awk -F: {print1}|sort|uniq -c|sort -r +0n

---------------------------------------------------------------------------------------------

一、查看apache當前併發訪問數：
netstat -an | grep ESTABLISHED | wc -l

對比httpd.conf中MaxClients的數字差距多少。

二、查看有多少個進程數：
ps aux|grep httpd|wc -l

三、可使用以下參數查看數據
server-status?auto

#ps -ef|grep httpd|wc -l
1388
統計httpd進程數，連個請求會啓動一個進程，使用於Apache服務器。
表示Apache可以處理1388個併發請求，這個值Apache可根據負載狀況自動調整。

#netstat -nat|grep -i "80"|wc -l
4341
netstat -an會打印系統當前網絡連接狀態，而grep -i "80"是用來提取與80端口有關的鏈接的，wc -l進行鏈接數統計。
最終返回的數字就是當前全部80端口的請求總數。

#netstat -na|grep ESTABLISHED|wc -l
376
netstat -an會打印系統當前網絡連接狀態，而grep ESTABLISHED 提取出已創建鏈接的信息。 而後wc -l統計。
最終返回的數字就是當前全部80端口的已創建鏈接的總數。

netstat -nat||grep ESTABLISHED|wc - 可查看全部創建鏈接的詳細記錄

查看Apache的併發請求數及其TCP鏈接狀態：
　　Linux命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

（

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
TIME_WAIT 8947 等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認
FIN_WAIT1 15 等待遠程TCP鏈接中斷請求，或先前的鏈接中斷請求的確認
FIN_WAIT2 1 從遠程TCP等待鏈接中斷請求
ESTABLISHED 55 表明一個打開的鏈接
SYN_RECV 21 再收到和發送一個鏈接請求後等待對方對鏈接請求的確認
CLOSING 2 沒有任何鏈接狀態
LAST_ACK 4 等待原來的發向遠程TCP的鏈接中斷請求的確認

TCP鏈接狀態詳解 
LISTEN： 偵聽來自遠方的TCP端口的鏈接請求
SYN-SENT： 再發送鏈接請求後等待匹配的鏈接請求
SYN-RECEIVED：再收到和發送一個鏈接請求後等待對方對鏈接請求的確認
ESTABLISHED： 表明一個打開的鏈接
FIN-WAIT-1： 等待遠程TCP鏈接中斷請求，或先前的鏈接中斷請求的確認
FIN-WAIT-2： 從遠程TCP等待鏈接中斷請求
CLOSE-WAIT： 等待從本地用戶發來的鏈接中斷請求
CLOSING： 等待遠程TCP對鏈接中斷的確認
LAST-ACK： 等待原來的發向遠程TCP的鏈接中斷請求的確認
TIME-WAIT： 等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認
CLOSED： 沒有任何鏈接狀態

）
　　LAST_ACK 5
　　SYN_RECV 30
　　ESTABLISHED 1597
　　FIN_WAIT1 51
　　FIN_WAIT2 504
　　TIME_WAIT 1057
　　其中的
SYN_RECV表示正在等待處理的請求數；
ESTABLISHED表示正常數據傳輸狀態；
TIME_WAIT表示處理完畢，等待超時結束的請求數。

---------------------------------------------------------------------------------------------

查看Apache併發請求數及其TCP鏈接狀態

查看httpd進程數（即prefork模式下Apache可以處理的併發請求數）：
　　Linux命令：

ps -ef | grep httpd | wc -l

　　返回結果示例：
　　1388
　　表示Apache可以處理1388個併發請求，這個值Apache可根據負載狀況自動調整，我這組服務器中每臺的峯值曾達到過2002。

查看Apache的併發請求數及其TCP鏈接狀態：
　　Linux命令：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
返回結果示例：
　　LAST_ACK 5
　　SYN_RECV 30
　　ESTABLISHED 1597
　　FIN_WAIT1 51
　　FIN_WAIT2 504
　　TIME_WAIT 1057
　　其中的SYN_RECV表示正在等待處理的請求數；ESTABLISHED表示正常數據傳輸狀態；TIME_WAIT表示處理完畢，等待超時結束的請求數。
　　狀態：描述

　　CLOSED：無鏈接是活動 的或正在進行

　　LISTEN：服務器在等待進入呼叫

　　SYN_RECV：一個鏈接請求已經到達，等待確認

　　SYN_SENT：應用已經開始，打開一個鏈接

　　ESTABLISHED：正常數據傳輸狀態

　　FIN_WAIT1：應用說它已經完成

　　FIN_WAIT2：另外一邊已贊成釋放

　　ITMED_WAIT：等待全部分組死掉

　　CLOSING：兩邊同時嘗試關閉

　　TIME_WAIT：另外一邊已初始化一個釋放

　　LAST_ACK：等待全部分組死掉

 

如發現系統存在大量TIME_WAIT狀態的鏈接，經過調整內核參數解決，
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 = 30
而後執行 /sbin/sysctl -p 讓參數生效。

net.ipv4.tcp_syncookies = 1 表示開啓SYN cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN攻擊，默認爲0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間

下面附上TIME_WAIT狀態的意義：

客戶端與服務器端創建TCP/IP鏈接後關閉SOCKET後，服務器端鏈接的端口
狀態爲TIME_WAIT

是否是全部執行主動關閉的socket都會進入TIME_WAIT狀態呢？
有沒有什麼狀況使主動關閉的socket直接進入CLOSED狀態呢？

主動關閉的一方在發送最後一個 ack 後
就會進入 TIME_WAIT 狀態 停留2MSL（max segment lifetime）時間
這個是TCP/IP必不可少的，也就是「解決」不了的。

也就是TCP/IP設計者原本是這麼設計的
主要有兩個緣由
1。防止上一次鏈接中的包，迷路後從新出現，影響新鏈接
（通過2MSL，上一次鏈接中全部的重複包都會消失）
2。可靠的關閉TCP鏈接
在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會從新發
fin, 若是這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。因此
主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。

TIME_WAIT 並不會佔用很大資源的，除非受到攻擊。

還有，若是一方 send 或 recv 超時，就會直接進入 CLOSED 狀態

如何合理設置apache httpd的最大鏈接數？

手頭有一個網站在線人數增多，訪問時很慢。初步認爲是服務器資源不足了，但經反覆測試，一旦鏈接上，不斷點擊同一個頁面上不一樣的連接，都能迅速打開，這種現象就是說明apache最大鏈接數已經滿了，新的訪客只能排隊等待有空閒的連接，而若是一旦鏈接上，在keeyalive 的存活時間內（KeepAliveTimeout，默認5秒）都不用從新打開鏈接，所以解決的方法就是加大apache的最大鏈接數。

1.在哪裏設置？
apache 2.24，使用默認配置（FreeBSD 默認不加載自定義MPM配置），默認最大鏈接數是250

在/usr/local/etc/apache22/httpd.conf中加載MPM配置（去掉前面的註釋）：
# Server-pool management (MPM specific)
Include etc/apache22/extra/httpd-mpm.conf

可見的MPM配置在/usr/local/etc/apache22/extra/httpd-mpm.conf，但裏面根據httpd的工做模式分了不少塊，哪一部纔是當前httpd的工做模式呢？可經過執行 apachectl -l 來查看：
Compiled in modules:
              core.c
              prefork.c
              http_core.c
              mod_so.c

看到prefork 字眼，所以可見當前httpd應該是工做在prefork模式，prefork模式的默認配置是：
<IfModule mpm_prefork_module>
                StartServers                      5
                MinSpareServers                   5
                MaxSpareServers                  10
                MaxClients                      150
                MaxRequestsPerChild               0
</IfModule>

2.要加到多少？

鏈接數理論上固然是支持越大越好，但要在服務器的能力範圍內，這跟服務器的CPU、內存、帶寬等都有關係。

查看當前的鏈接數能夠用：
ps aux | grep httpd | wc -l

或：
pgrep httpd|wc -l

計算httpd佔用內存的平均數:
ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'

因爲基本都是靜態頁面，CPU消耗很低，每進程佔用內存也不算多，大約200K。

服務器內存有2G，除去常規啓動的服務大約須要500M（保守估計），還剩1.5G可用，那麼理論上能夠支持1.5*1024*1024*1024/200000 = 8053.06368

約8K個進程，支持2W人同時訪問應該是沒有問題的（能保證其中8K的人訪問很快，其餘的可能須要等待一、2秒才能連上，而一旦連上就會很流暢）

控制最大鏈接數的MaxClients ，所以能夠嘗試配置爲：
<IfModule mpm_prefork_module>
                StartServers                      5
                MinSpareServers                   5
                MaxSpareServers                  10
                ServerLimit                    5500
                MaxClients                     5000
                MaxRequestsPerChild               100
</IfModule>

注意，MaxClients默認最大爲250，若要超過這個值就要顯式設置ServerLimit，且ServerLimit要放在MaxClients以前，值要不小於MaxClients，否則重啓httpd時會有提示。

重啓httpd後，經過反覆執行pgrep httpd|wc -l 來觀察鏈接數，能夠看到鏈接數在達到MaxClients的設值後再也不增長，但此時訪問網站也很流暢，那就不用貪心再設置更高的值了，否則之後若是網站訪問突增不當心就會耗光服務器內存，可根據之後訪問壓力趨勢及內存的佔用變化再逐漸調整，直到找到一個最優的設置值。

(MaxRequestsPerChild不能設置爲0，可能會因內存泄露致使服務器崩潰）

更佳最大值計算的公式：

apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5

附：

實時檢測HTTPD鏈接數：
watch -n 1 -d "pgrep httpd|wc -l"

歡迎關注微信公衆號：大數據從業者