摘要：一般產生的原因是系統沒有主動關閉連接如連接資源沒有關閉關于網絡鏈路中追蹤異常用到的運維命令以下顯示的和端口均為假數據中查看的狀態參數說明已使用的所有協議套接字總量正在使用正在偵聽的套接字數量。其值等于已分配已建立已申請到的套接字數量。

用戶輸入url如http:www.baidu.com到瀏覽器，瀏覽器如chrom需要將其解析為ip地址才知道需要到哪里去訪問哪個服務器。瀏覽器解析DNS步驟如下

搜索瀏覽器自身的dns緩存，這個緩存緩存時間短，緩存數目有限。

搜索操作系統的dns緩存

讀取host文件的dns映射(一般做本地開發映射都是修改這個文件來達到攔截瀏覽器請求到本地服務器的目的，從而使本地可以成功映射服務器地址)

先本地網卡配置里的dns服務器發起域名解析請求，這里好像還有一套運營商的處理流程就不在展開了。

下面好像還有一些流程，由于基本不會執行到這一步，一般所以dns運營商的dns服務器都會搞定的。

解析失敗，以上任何一步成功都會返回一個成功的ip地址

瀏覽器以一個隨機的端口享這個ip地址的特定端口(默認80)發起著名的TCP3次握手。關于一個http請求是如何到達nginx服務的流程大致如下：

握手完成后的瀏覽器和服務器就可以愉快地發送http請求了，具體在nginx上流程如下：

對于一個PHP的web程序來說，web服務器（如：nginx）要想與它通信需要通過CGI協議。當一個web請求觸達web服務器時，web服務器會創建一個CGI進程,CGI進程將web的請求按照固定的格式進行解析，然后寫入標準輸入(STDIN)和環境變量中，然后PHP啟動的CGI解析器會從標準輸入(STDIN)和環境變量中讀取http請求的數據，所以$_SERVER才會有數據，然后做出相應的邏輯處理，然后將處理結果放入標準輸出(STDOUT)，CGI進程從STDOUT中讀取響應數據然后傳輸給瀏覽器，這樣服務端就完成了一次http請求。

上面是CGI的實現流程，但是使用CGI協議的服務器在用戶每次訪問服務器的時候都需要fork/銷毀CGI進程，必然照成多余的系統開銷，所以FASTCGI就是為了解決這個問題的。

FastCGI會創建一個常駐的master進程和多個worker進程，master進程負責管理和為worker進程反派任務，worker進程負責內部嵌入了CGI解析器用于解釋php代碼。

PHP-FPM是一個FastCGI進程管理器，在LNMP體系中就是由它來實現FastCGI協議的。同樣，它也會創建一個常駐的master進程和多個worker進程，master進程負責監聽端口和接收來自nginx的請求，指派任務給worker進程。worker進程的負責解釋php代碼。PHP-FPM可以通過配置預先啟動一定數量的worker進程，這樣當http請求觸達時就可以更快速的響應。

nginx與PHP-FPM之間的通信一般通過其ngx_http_fastcgi_module模塊來實現。其中fastcgi_pass用于設置fastcgi服務器的IP地址;fastcgi_param設置傳入fastcgi服務器的參數。這個模塊出現的配置問題一般集中在這一塊。

相對于并發狀態下出現的問題，一般也都集中在fastcgi服務器上，具體表現為fastcgi服務器為了應對大量的http請求必須不停的fork新的worker進程，這時就需要考慮服務器可支持的最大鏈接數和最大打開文件數（可通過ulimit -n查看）以及php-fpm配置里的最低開啟worker數和最高開啟worker數的限制。高性能服務器可以在這個方向上調優。

在四次揮手斷開連接中,發起socket主動關閉的一方 socket將進入TIME_WAIT狀態,TIME_WAIT狀態將持續2個MSL(Max Segment Lifetime),TIME_WAIT狀態下的socket不能被回收使用.

具體現象是對于一個處理大量短連接的服務器,如果是由服務器主動關閉客戶端的連接,將導致服務器端存在大量的處于TIME_WAIT狀態的socket, 甚至比處于Established狀態下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,停止服務.

TIME_WAIT是TCP協議用以保證被重新分配的socket不會受到之前殘留的延遲重發報文影響的機制,是必要的邏輯保證。一般產生的原因是系統沒有主動關閉連接,如mysql連接資源沒有關閉

(以下顯示的IP和端口均為假數據)

cat /proc/net/sockstat

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

tcpdump -n port 3306

11:38:45.693382 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [F.], seq 123, ack 144, win 227, options [nop,nop,TS val 3000355 ecr 2997359], length 0 # MySQL發送fin包給我
11:38:45.740958 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 124, win 229, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # 我回復ack給它
11:38:45.740960 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [F.], ack 125, win 231, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # MySQL發送fin包給客戶端
11:38:45.740965 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 125, win 229, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # 客戶端回復ack給我
......

src > dst: flags data-seqno ack window urgent options
# 發生了 3次握手
11:38:15.679863 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [S], seq 4065722321, win 29200, options [mss 1460,sackOK,TS val 2997352 ecr 0,nop,wscale 7], length 0
11:38:15.679923 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [S.], seq 780487619, ack 4065722322, win 28960, options [mss 1460,sackOK,TS val 2997352 ecr 2997352,nop,wscale 7], length 0
11:38:15.679936 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 1, win 229, options [nop,nop,TS val 2997352 ecr 2997352], length 0

傳送門