linux的tcp連接數

㈠ linux 網路連接數查看方法

1、查看系統tcp連接中各個狀態的連接數。

netstat-an|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'

㈡ 如何查看linux並發連接數

1、查看Web伺服器（Nginx Apache）的並發請求數及其TCP連接狀態：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}
netstat -n|grep ^tcp|awk '{print $NF}'|sort -nr|uniq -c
或者：
netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}
返回結果一般如下：
LAST_ACK 5 （正在等待處理的請求數）
SYN_RECV 30
ESTABLISHED 1597 （正常數據傳輸狀態）
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057 （處理完畢，等待超時結束的請求數）
其他參數說明：
CLOSED：無連接是活動的或正在進行
LISTEN：伺服器在等待進入呼叫
SYN_RECV：一個連接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個連接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另一邊已同意釋放
ITMED_WAIT：等待所有分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT：另一邊已初始化一個釋放
LAST_ACK：等待所有分組死掉
2、查看Nginx運行進程數
ps -ef | grep nginx | wc -l
返回的數字就是nginx的運行進程數，如果是apache則執行
ps -ef | grep httpd | wc -l
3、查看Web伺服器進程連接數：
netstat -antp | grep 80 | grep ESTABLISHED -c

㈢ linux下tcp通信怎麼限制客戶端的連接數量

listen的backlog參數指定的是已經三次握手完成，達到了established狀態但是等待accept的隊列的容量。當這個容量超過上限的時候伺服器端便不處理客戶端的三次握手了。這個隊列的容量當然不是樓主所說的並發連接數。
但是lisen的再後一道程序便是accept了。如果你想要的是在tcp並發連接數量超過上限的時候伺服器不再處理了三次握手那麼只有兩種辦法：
1.關閉listen的socket
2.自己修改tcp協議棧的實現，當然這個就比較麻煩了。

用iptables防火牆來限制tcp連接，
如下，限制用戶的tcp連接數為50

iptables -I INPUT-p tcp -m connlimit --connlimit-above 50 -j REJECT

㈣ 在Linux操作系統中怎麼評估tcp連接數

1.首先，客戶端和伺服器建立的每個TCP連接都會佔用伺服器內存，所以最大TCP連接數和內存成正比。簡單估算為最大內存除以單TCP連接佔用的最小內存

2.Linux操作系統中，一切都是文件。所以每個TCP連接，都會打開一個文件。為此Linux操作系統限制了每個用戶能打開的文件數量，通過ulimit -n 查看。修改方式：

vi /etc/security/limits.conf文件，在文件中添加如下行（限制修改為10240）：

speng soft nofile 10240

speng hard nofile 10240

3.Linux操作系統中，TCP連接數量還受到埠數量限制，由於埠號只有1-65535，所以最大TCP連接數也只有65535個(包括系統埠1-1024)

4.Linux操作系統對所有用戶最大能打開文件的限制：cat /proc/sys/fs/file-max。

5.網路核心模塊對tcp連接的限制(最大不能超過65535)：

vi /etc/sysctl.conf

net.ipv4.ip_local_port_range = 1024 65000

6.防火牆對tcp連接的限制

綜上，在Linux操作系統中，首先對TCP連接數量的限制依次有：埠數量限制，網路核心限制，最大文件數量限制(因為每建立一個連接就要打開一個文件)，防火牆限制，用戶打開文件限制

㈤ 查看linux中的TCP連接數

1)統計80埠連接數

2）統計httpd協議連接數

3）、統計已連接上的，狀態為「established

4)、查出哪個IP地址連接最多,將其封了.

1、查看apache當前並發訪問數：

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

2、查看有多少個進程數：

3、可以使用如下參數查看數據

統計httpd進程數，連個請求會啟動一個進程，使用於Apache伺服器。
表示Apache能夠處理1388個並發請求，這個值Apache可根據負載情況自動調整。

4341
netstat -an會列印系統當前網路鏈接狀態，而grep -i "80"是用來提取與80埠有關的連接的，wc -l進行連接數統計。
最終返回的數字就是當前所有80埠的請求總數。

netstat -an會列印系統當前網路鏈接狀態，而grep ESTABLISHED 提取出已建立連接的信息。 然後wc -l統計。
最終返回的數字就是當前所有80埠的已建立連接的總數。

查看Apache的並發請求數及其TCP連接狀態：

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能夠處理的並發請求數）：

返回結果示例：
1388
表示Apache能夠處理1388個並發請求，這個值Apache可根據負載情況自動調整，我這組伺服器中每台的峰值曾達到過2002。

查看Apache的並發請求數及其TCP連接狀態：

返回結果示例：
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：等待所有分組死掉

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 時間

客戶端與伺服器端建立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配置（去掉前面的注釋）：

Include etc/apache22/extra/httpd-mpm.conf

可見的MPM配置在/usr/local/etc/apache22/extra/httpd-mpm.conf，但裡面根據httpd的工作模式分了很多塊，哪一部才是當前httpd的工作模式呢？可通過執行 apachectl -l 來查看：
Compiled in moles:
core.c
prefork.c
http_core.c
mod_so.c

看到prefork 字眼，因此可見當前httpd應該是工作在prefork模式，prefork模式的默認配置是：
<IfMole mpm_prefork_mole>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfMole>

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的人訪問很快，其他的可能需要等待1、2秒才能連上，而一旦連上就會很流暢）

控制最大連接數的MaxClients ，因此可以嘗試配置為：
<IfMole mpm_prefork_mole>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 5500
MaxClients 5000
MaxRequestsPerChild 100
</IfMole>

注意，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"

㈥ linux 支持多少tcp 16404

常識一：文件句柄限制
在linux下編寫網路伺服器程序的朋友肯定都知道每一個tcp連接都要佔一個文件描述符，一旦這個文件描述符使用完了，新的連接到來返回給我們的錯誤是「Socket/File:Can't open so many files」。
這時你需要明白操作系統對可以打開的最大文件數的限制。
進程限制
執行 ulimit -n 輸出 1024，說明對於一個進程而言最多隻能打開1024個文件，所以你要採用此默認配置最多也就可以並發上千個TCP連接。
臨時修改：ulimit -n 1000000，但是這種臨時修改只對當前登錄用戶目前的使用環境有效，系統重啟或用戶退出後就會失效。
重啟後失效的修改（不過我在CentOS 6.5下測試，重啟後未發現失效）：編輯 /etc/security/limits.conf 文件， 修改後內容為
* soft nofile 1000000
* hard nofile 1000000
永久修改：編輯/etc/rc.local，在其後添加如下內容
ulimit -SHn 1000000
全局限制
執行 cat /proc/sys/fs/file-nr 輸出 9344 0 592026，分別為：1.已經分配的文件句柄數，2.已經分配但沒有使用的文件句柄數，3.最大文件句柄數。但在kernel 2.6版本中第二項的值總為0，這並不是一個錯誤，它實際上意味著已經分配的文件描述符無一浪費的都已經被使用了 。
我們可以把這個數值改大些，用 root 許可權修改 /etc/sysctl.conf 文件:
fs.file-max = 1000000
net.ipv4.ip_conntrack_max = 1000000
net.ipv4.netfilter.ip_conntrack_max = 1000000
常識二：埠號范圍限制？
操作系統上埠號1024以下是系統保留的，從1024-65535是用戶使用的。由於每個TCP連接都要佔一個埠號，所以我們最多可以有60000多個並發連接。我想有這種錯誤思路朋友不在少數吧？（其中我過去就一直這么認為）
我們來分析一下吧
如何標識一個TCP連接：系統用一個4四元組來唯一標識一個TCP連接：{local ip, local port,remote ip,remote port}。好吧，我們拿出《UNIX網路編程：卷一》第四章中對accept的講解來看看概念性的東西，第二個參數cliaddr代表了客戶端的ip地址和埠號。而我們作為服務端實際只使用了bind時這一個埠，說明埠號65535並不是並發量的限制。
server最大tcp連接數：server通常固定在某個本地埠上監聽，等待client的連接請求。不考慮地址重用（unix的SO_REUSEADDR選項）的情況下，即使server端有多個ip，本地監聽埠也是獨占的，因此server端tcp連接4元組中只有remote ip（也就是client ip）和remote port（客戶端port）是可變的，因此最大tcp連接為客戶端ip數×客戶端port數，對IPV4，不考慮ip地址分類等因素，最大tcp連接數約為2的32次方（ip數）×2的16次方（port數），也就是server端單機最大tcp連接數約為2的48次方。
總結

㈦ 有人說linux的TCP連接數量最大不能超過65535個嗎，是真的嗎

linux的TCP連接數量最大不能超過65535個，這種說法是錯誤的。

基於以上的原因，在Linux操作系統中，對TCP連接數量的限制依次有：埠數量限制，網路核心限制，最大文件數量限制(因為每建立一個連接就要打開一個文件)，防火牆限制，用戶打開文件限制。但並不存在65535這個數量限制。

㈧ linux伺服器tcp連接數過大怎麼辦

不管是什麼系統的伺服器，客戶連接到伺服器的最明顯的看出來就是TCP的顯示。
一般分為兩種情況：
1.CC攻擊的表現情況
CC攻擊會造成訪問量增大，帶寬圖上的代表TCP訪問量（紅色）會忽然不正常的增高。CPU的佔用量增大，然後造成打開慢或者卡死的情況。
所以看到如果是TCP，突然增大的話，證明你的伺服器在遭受CC攻擊，可以聯系伺服器商，讓機房做下防禦策略。
2.如果TCP的連接量一直在一個區域一直很大的話，那檢查伺服器的資源，可能無法支撐訪問量，需要更大的資源，更高的配置支持。