一個生產網絡問題Broken Pipe引發的思考

原創 安琪拉的博客 2020-06-16 15:48

本文是以安琪拉在項目中解決的一個網絡異常(Broken Pipe)爲出發點寫的，我想玩家們應該多少遇到過項目中的網絡問題，這篇文章也提供了一種解決網絡問題的思路，玩家們遇到其他網絡問題時可以借鑑這個思路。

爲了儘量講的清晰明瞭，以下面這個流程進行：

  1. 背景：安琪拉遇到網絡異常
  2. 小試牛刀：在Wireshark數據包中看三次握手
  3. 預備知識：回顧網絡分層、三次握手、四次揮手等網絡基礎知識
  4. 異常定位：Wireshark 分析定位Broken Pipe 異常原因
  5. 代碼修復：調整客戶端代碼
  6. 擴展閱讀：其他網絡知識及面試題

1. 背景：安琪拉遇到網絡異常

1. 異常信息

安琪拉做的一部分工作是和公司外部機構對接系統，對接方式很多種，有機構提供封裝好的SDK，提供統一網關平臺、還有一個接口一個HTTP URL等。涉及到的應用層協議主要有https、http、sftp、ftp等。最近對接的一家機構生產環境聯調日誌出現了網絡異常，異常棧如下：

網絡異常棧

第一眼看異常棧直譯過來就是管道破裂，爲什麼會出現管道破裂呢？ 這篇文章就由此而來，背後牽涉的是我們常常掛在嘴邊，面試也經常被問的http 和 tcp 協議的知識，這裏埋個伏筆，後面我們由淺入深，慢慢把這個問題解決，同時瞭解如何運用網絡知識解決實際生產問題。

安琪拉遇到異常是很興奮的，又可以學知識了，咳咳哈！當然咯，前提是不影響到正常業務。這裏現象是每個http 請求發起總是失敗，請求重試大概率會成功。

閒扯一段：其實一般應用本地的異常還是比較好排查的，像空指針、內存溢出、數組越界等都比較好搞！網絡問題，尤其是跟外部公網打交道的網絡問題有時間還是會稍微棘手的，因爲公網環境比較複雜，中間涉及的跳轉節點比較多，很考驗工程師的計網水平。

安琪拉知道運維中有個詞叫根故障定位，實際生產中很多異常的根故障最後都會定位到網絡這一層。

想說點題外話，安琪拉工作這幾年的一點體會，工程師的能力分二種，有一種能力叫掌握知識的能力，也叫學習能力，另一種能力叫解決問題的能力，學生時代前一種能力很容易體現，成績和分數，而工作以後，公司更關注或者說更看重的是解決問題的能力，因爲企業招工程師最終還是爲了創造業務價值，創造業務價值就需要不斷解決實際業務的一個一個問題，不論是新業務需求還是系統bug都可以看做是面臨的問題。當然這二種能力不是完全割裂的，往往相輔相成，解決問題能力強的人學習能力不會弱。只是看個人更偏重哪一方面? 學習能力強的人適合做學術型人才，解決問題能力強的適合做工程型人才。

閒扯扯完了，舒服！ 發現寫體會、感受比寫技術文章輕鬆流暢多了！技術需要嚴謹細緻，體會感受就是很個人，很感性的東西，對錯因人而異！

2. 網絡抓包

遇到上面Broken Pipe這個問題，不急，第一步企微上撩一下運維大哥，讓他幫我抓個包下來看下。

抓包聊天截圖

抓包命令如下：

tcpdump tcp port 20004 and host  **.**.com -w brokenpipe.cap

tcpdump : dump the traffic on a network，根據使用者的定義對網絡上的數據包進行截獲的包分析工具。

大家也可以邊看邊自己抓包，常用的命令格式如下：

tcpdump tcp port 端口號 and host 域名 -w  保存文件

如果網絡流量高，不要抓太久，不然包會很大，分析的時候加載慢！

tcpdump 完整命令可以用tcpdump --help 查看。

2. 小試牛刀：在Wireshark數據包中看三次握手

之前如果沒有用過Wireshark做過網絡包分析的，安琪拉擔心直接上來就看包分析有點費勁，下面安琪拉會對wireshark 先做個簡單的介紹。

2.1 Wireshark 簡介

首先，把運維給的包存在本地， 打開wireshark 導入網絡包，開始有趣的網絡漫遊之旅。

wireshark 是一款非常流行的網絡包分析工具，經常是網絡工程師/後端工程師用來分析網絡包，解決網絡問題的利器。先放一張圖出來聞聞味：

安琪拉截了一張自己本機裝的 wireshark 軟件，分爲四個部分：

  1. 頂部是菜單欄
  2. 淺綠色背景是過濾器，這個對於分析包很重要，後面會講
  3. 列表那一欄是包列表信息
  4. 最下面的這個是包詳細信息，包含各層協議的內容（應用層、傳輸層、網絡層、數據鏈路層、物理層）

Wireshark介紹

吐槽一下微信的截圖，文字的樣式都不能改，太難看！

2.2 Wireshark 過濾器

過濾器單獨拿出來說下，因爲確實很有用，後面異常分析會用到。

你導入的包可能內容很多，需要使用過濾器篩選一下，過濾器很多種過濾的規則，我列舉一下常用的幾種：

  • 協議過濾

    如果抓的包有很多種協議類型，可以輸入 tcp 回車只看tcp 協議的包

  • IP 過濾

    例如 ip.src == 192.168.1.23 （過濾發起地址ip）ip.dst == 12.8.0.1（過濾目標地址ip） ip == 12.0.0.1（過濾源或目的地址）

  • 端口過濾

    tcp.port == 4980 ， 還可以 tcp.port == 4542 or tcp.port == 4528 加入表達式 and、or、in 等等

    例如：tcp.port in {80 443 8080}

  • HTTP 模式過濾

    http.request.method == “GET” 或者 http.request.method == “POST”

  • 報文內容過濾

    tcp.segment_data contains “202005190001” 過濾tcp 報文內容包括 202005190001 的報文

更多wireshark 過濾器可以參考：wireshark-filter

wireshark 的詳細使用教程不是今天的重點，就介紹這二部分，後面分析數據包時會穿插着講，安琪拉覺得大家有興趣可以自己抽空玩一玩這個軟件。

2.3 三次握手初探

安琪拉寫的三次握手初探 這部分如果看不懂沒關係，這裏是爲了介紹Wireshark寫的三次握手，後面會詳細解釋，詳細到直接從網絡協議分層開始講起，如果你這看不懂可以Diss 安琪拉。

三次握手

如果第一次看Wireshark 網絡包，會一臉懵逼，看多了就會越看越喜歡。重點看框出來的，前三行就是三次握手的過程：

  1. 上圖第一行，客戶端向服務端發送SYN 數據包，數據長度len 爲0，Seq（隨機生成包序列號）爲2421858999；
  2. 上圖第二行，服務端向客戶端迴應ACK 數據包，並且發送SYN 數據包，合併一起就是SYN + ACK 數據包，數據長度len 爲0，Seq（隨機生成包序列號）爲1988635269，ack爲2421859000 = 第一次握手Seq（2421858999）+1；
  3. 上圖第三行，客戶端迴應客戶端的SYN 數據包，發送ACK 確認數據包，Seq 爲 二次握手的ack（2421859000），ack爲 1988635270= 二次握手的seq（1988635269）+1；

公衆號【安琪拉的博客】後面會更新一個網絡系列：列舉常見的網絡問題，解決的思路，wireshark分析包方法等。

3. 回顧網絡協議分層、三次握手、四次揮手等網絡基礎知識

3.1 網絡協議分層

在解決文章開頭的異常，分析數據包之前，我們需要一些預備知識，需要一丟丟基礎的網絡知識。

首先在直接看Wireshark 的包信息之前，需要來回顧一下計算機網絡的知識，大家知道目前主流使用的TCP/IP 五層協議，而不是國際標準化組織（ISO）出的OSI（Open System Interconnection）七層協議。TCP/IP協議棧如下圖所示：

TCP/IP五層協議

我們可以看到Wireshark 包詳情就是TCP/IP 五層的信息，對比上面的圖從下往上看 (取每個英文單詞首字母就是協議簡稱，例如 HTTP：Hypertext Transfer Protocol ），如下：

image-20200515005055601

後面我們看 Wireshark 數據報文時，主要看TCP 所在的傳輸層報文。

3.2 三次握手

首先我們先看下TCP 報文的報文格式：

TCP報文格式

下面把TCP 報文的各個部分做了詳細說明，分析網絡問題不用全看，把加重的部分關注一下就可以了。好學的玩家可以把所有的都看了，不用記，有個概念就可以了。

  1. 源端口號和目的端口號：各佔2個字節（16位），分別寫入源端口和目的端口；

  2. 序號：4字節（32位），TCP連接中字節流每個字節都按順序編號，這個序號用於標識這個報文段。

例如：一段報文序號seq 是201，而報文數據長度爲100，下一個報文段的數據序號應該爲301（201+100）。

  1. 確認號 ：4字節（32位），期望收到對方下一個報文的序號。這個確認號是和序號seq 有點關係的，不要和ACK（狀態標誌位）混淆了。

  2. 首部長度：4位，表示報文數據距離報文起始位置的長度。 保留：保留今後可以會用到。

  3. 數據報狀態標誌位（非常重要），分爲以下6種，二進制1 位表示一種（1代表開啓 0 關閉）

URG：URG=1 代表報文有緊急數據

ACK：ACK = 1，確認位，TCP中連接建立後，所有報文的ACK 位置都爲1；

PSH: 發送端和接收端都有緩衝區（發送端：寫緩衝區 接收端：讀緩衝區） 對於發送端：帶PSH=1，報文會立即從緩衝區報文推送給服務端 對於服務端：服務端立即將讀緩衝區內容推給進程。

RST：RST=1，代表連接出現嚴重錯誤，TCP連接的一方將連接重置了，必須釋放連接，重新建立連接；

SYN：同步SYN，在連接建立時用來同步序號。三次握手時會用到，當SYN=1，ACK =0，表明是發起方請求建立連接，服務方同意建立連接，響應報文SYN=1，ACK =1，前者表明同步連接，後者是確認報文。

FIN：用來釋放連接。當FIN =1，表明此報文的發送方的數據已經發送完畢，並且要求釋放。

  1. 窗口：佔2字節，通常用於告知對方自己的能夠接受的數據量大小。窗口本質就是一個緩衝區buffer，該字段的值用於告知對方自己剩餘的可用緩衝區大小。

  2. 校驗和：奇偶校驗，此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 數據，以 16 位字進行計算所得。由發送端計算和存儲，並由接收端進行驗證。

  3. 緊急指針：只有當 URG 標誌置 1 時緊急指針纔有效。緊急指針是一個正的偏移量，和順序號字段中的值相加表示緊急數據最後一個字節的序號。

  4. 選項：可選的。最常見的可選字段是最長報文大小，又稱MSS(Maxinum Segment Size), 每個連接方通常在通信的第一個報文段（連接建立的SYN標誌位爲1的數據報文）設置這個選項，表示本端能接受的最大報文段的長度。因爲長度不一定是32的整數倍，因此要加額外的0作爲填充。

  5. 數據部分：可選的。連接建立和終止時，報文段只有TCP首部。

我們先回顧一下以前計算機網絡課堂上學過的TCP傳輸的三次握手流程：

TCP連接三次握手

三次握手
三次握手的具體過程如下：

  1. 服務端進程啓動，準備接收客戶端進程的連接請求，此時接收方進入LISTEN（監聽）模式；

  2. 三次握手第一步：客戶端向服務端發出連接請求報文，這時報文首部SYN 標誌位爲1，同時設置一個初始序列號seq = x（隨機數）; 做完這步動作，發送方進入SYN_SENT (同步已發送狀態) 。

    名稱解釋： SYN：同步標誌位 seq：包序列編號(每個包都有一個序列號)

    第一次握手客戶端發送的報文稱爲同步請求報文，希望與服務端建立同步連接，SYN報文不攜帶數據。

  3. 三次握手第二步：服務端收到來自客戶端的連接請求報文後，需要確認收貨，響應報文中ACK（確認標誌位）設置爲1，將確認號ack 設置爲第一步的請求序列號seq 加1（ack =x+1），另外自己也回客戶端一個SYN包（可以建立同步連接），即SYN + ACK包，包序列號seq = y，服務端進入SYN_RCVD（同步收到）狀態。

    名詞解釋：ACK：確認狀態位（這裏ACK=1），這個一定和ack（32位確認序號，這裏ack=x+1）區分開，可以看下面的TCP 報文結構體圖，ACK是包的狀態標誌，ack是確認序號。

  4. 三次握手第三步：客戶端收到來自服務端的 SYN + ACK 包，會發送一個ACK 確認包，ACK =1，seq = x+1( 第二步的ack)，ack = y+1（第二步的seq+1）。

玩家們如果覺得看安琪拉寫的有收穫，歡迎關注公衆號【安琪拉的博客】，來找安琪拉草叢互動！

3.3 四次揮手

四次揮手的狀態圖如下所示：

四次揮手
四次揮手wireshark 包信息如下，可以對照着上圖看，Wireshark四次揮手
四次揮手的具體過程如下：

  1. 客戶端發送FIN 釋放連接報文，表示結束連接，報文seq = u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN_WAIT1（終止等待1）狀態。
  2. 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE_WAIT（關閉等待）狀態。TCP接收方通知上層的應用進程，客戶端向服務器方向的發送通道關閉了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了（已經發了FIN結束信號），但是服務器若發送數據，客戶端依然要接受。這個狀態要持續一段時間，也就是整個CLOSE_WAIT狀態持續的時間。
  3. 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN_WAIT2（終止等待2）狀態，等待服務器發送連接釋放報文（在服務端Close_Wiat期間還可以接受服務器發送的最後的數據）。
  4. 服務端發送完最後的數據，向客戶端發送FIN 連接釋放報文，ACK =1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，ack 和回覆ACK報文一致，ack = u+1, 此時，服務器就進入了LAST_ACK（最後確認）狀態，等待客戶端的確認。
  5. 客戶端收到服務器的連接釋放報文後，必鬚髮出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME_WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2 個MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
  6. 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。

4.異常定位：Wireshark 分析定位Broken Pipe 異常原因

4.1 網絡包分析

上面我們已經看了正常的四次揮手的流程和截圖，下面我們來看下線上遇到的 Broken Pipe異常，再次看一眼異常棧，如下圖：

網絡異常棧

我們可以看Wireshark 的包信息如下圖，
在這裏插入圖片描述

可以看到，我們來看一下流程，第一步是區分服務端和客戶端：

  • 服務端：IP後綴爲132 ，端口20004是，
  • 客戶端：IP後綴爲156，端口爲4528。

前三行是三次握手，沒有問題，但是最後的四次揮手這裏有問題（可以對照着四次揮手的圖看）：

  • No.189 行：服務端發起FIN 報文希望關閉連接，服務端進入FIN_WAIT1 狀態；

  • No.190 行：客戶端響應服務端的FIN 報文發送ACK 報文，進入CLOSE_WAIT 狀態；

  • No.191 ~ No.197：服務端接收到客戶端的ACK 進入FIN_WAIT2 狀態，此時服務端是不接收數據傳輸的，但是我們可以看到Wireshark 191 ~ 196 行客戶端還在發送數據報文，正常應該是客戶端發送FIN 報文關閉連接，讓服務端進入TIME_WAIT 狀態，但是客戶端沒有發送FIN報文，而是向已經準備關閉的連接通道中發送了數據報文，因爲服務端不認你客戶端的數據，所以發送了RST 信號報文來重置連接。

下面是正常的四次揮手和異常的四次揮手對照圖：

對比

4.2 問題定位

  1. 供應商接口查看狀態

    讓HTTP 請求的被調用方（供應商）查看當前網絡狀態，Linux 命令如下所示：

    netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'

    結果如下：

    image-20200522214047234

    可以對照着四次揮手流程圖看狀態：

    ESTABLISHED: 處於連接建立狀態的連接數

    FIN_WAIT1: 處於連接關閉FIN_WAIT1 狀態的連接數

    FIN_WAIT2: 處於連接關閉FIN_WAIT2 狀態的連接數

    TIME_WAIT：處於 TIME_WAIT 狀態的連接數

    可以看到TIME_WAIT 狀態很多，這個是正常的，只要記住，正常四次揮手流程中，主動關閉的一方會經過TIME_WAIT 狀態，被動關閉一方會經過 CLOSE_WAIT 狀態，這二個狀態（TIME_WAIT & CLOSE_WAIT）需要做個區分，如果 CLOSE_WAIT 狀態過多可能會有問題，這個我會在擴展閱讀詳細說，繼續分析異常。

  2. 確認連接方式

    通過上面Wireshark 異常包可以知道是服務端進入FIN_WAIT2 狀態後，客戶端繼續發送數據包，導致服務端RST 連接。這裏有二個問題：

    1. 爲什麼服務端主動發起FIN 關閉連接呢？
    2. 爲什麼客戶端在接收到服務端的FIN 並回復ACK 報文之後，爲什麼沒有發送FIN 關閉連接報文呢？

    不賣關子了，講了這麼多吊足了玩家們的胃口，真實原因都不好意思講了，其實是因爲供應商不支持長連接，但是我們爲了資源複用，降低HTTP 連接創造銷燬的開銷，使用了連接池，連接池的連接是複用的，是長連接，所以纔會出現服務端第二次發送數據時不進行三次握手，而是直接傳輸數據報文的情況。

5. 代碼修復：調整客戶端代碼

5.1 HttpClient 長連接改爲短連接
  1. 服務端那邊配置的Nginx 是短連接方式，客戶端代碼使用長連接，客戶端HTTP 請求的代碼（刪除了部分代碼），請求結束之後，連接不進行關閉，連接池複用連接。如下：

長連接主要代碼

如果要支持長連接，服務端Nginx 配置需要做些修改，如下：

http{
  keepalive_timeout 60s;  #連接保持的超時時間
  
  upstream servers {
		keepalive 10;
	}
  
  server {
     listener 20004 so_keepalive=on #這個是支持長連接的配置
	}
}

  1. 代碼問題修復

    客戶端連接方式從長連接改成短連接，設置連接不復用就可以了，如下：

    image-20200525203700284

  2. 番外

    從現象上看因爲長連接的連接複用，導致了 Broken Pipe 異常，但是從實際業務角度，業務測試成功率沒有明顯變化。因爲連接池設置了異常重試策略，如果發生Broken Pipe 異常，會再從連接池獲取連接重試，重試的成功率非常高，因爲大多數時候是新建的連接來重試。這點從wireshark 網絡包中可以看出。

    因爲每一筆業務都有流水號，因爲可以使用Wireshark 過濾器過濾網絡包的數據內容，如下所示：

    過濾器輸入業務日誌中的請求的流水號，過濾器過濾包的命令如下：

    tcp.segment_data contains "TCP包中業務流水號"

    image-20200525205104904

    如上圖所示，可以看到有二筆TCP 數據包中數據包含有這個業務流水號，這個就是因爲第一次TCP 失敗後重試造成的，可以看到一筆是從4528端口發出，一筆是4542端口發出的，我們可以把這二筆單獨拉出來看一下，使用過濾器的命令如下，4542端口失敗後新建一個連接（端口爲4528）發送數據：

    tcp.port == 4542 or tcp.port == 4528

    過濾後的數據包如下圖所示：

wireshark過濾數據包

6. 擴展閱讀：其他網絡知識及面試題

6.1 爲什麼需要三次握手來建立TCP 連接？

答： 第一次握手客戶端發送報文給服務端，收到服務端的應答表明客戶端發送數據的能力ok；第二次握手服務端發送數據給客戶端表示服務端接收數據能力ok（我正常收到你的數據了，告訴你一聲）；第三次客戶端發報文給服務端表明服務端的發送數據的能力也ok，客戶端接收數據能力也ok（我能正常收到你的數據，代表你發的數據沒問題，我的接收能力也沒問題，所以告知你一聲）。所以要驗證客戶端和服務端發送&接收數據的能力都ok至少需要三次握手才能達到。舉個實際的例子，比如你投遞簡歷，相當於第一次握手，HR回覆你簡歷已收到，相當於第二次握手，你回覆HR已收到批准通知了，這相當於三次握手，HR可以給你安排面試了。因爲每一次握手都有消息丟失的風險，所以需要往返至少三次才能保證連接的建立。

6.2 TIME_WAIT 和 CLOSE_WAIT 有什麼區別？

答：這二個狀態是四次揮手中的狀態，TIME_WAIT 是主動關閉的一方發出 FIN 包會經過的狀態，CLOSE_WAIT 是被動關閉連接的一端會經過的狀態。TIME_WAIT 經過2個MSL(最大報文段生存時間)才能到CLOSE狀態，CLOSE_WAIT 如果不發送FIN 報文會一直處在CLOSE_WAIT 狀態。所以一般在看機器連接狀態，幾千個TIME_WAIT 一般是正常的（過2MSL自動關閉），處於CLOSE_WAIT 狀態的連接很多，證明有問題。

6.3 處於CLOSE_WAIT 狀態的連接很多，怎麼辦？

答：處於CLOSE_WAIT 狀態的連接很多，證明有問題，有幾種可能：

  • 代碼問題：短連接模式，忘記 close 連接，就不會發出 FIN 包，導致連接處於 CLOSE_WAIT狀態；或者程序在close 連接之前陷入死循環或者執行時間過長；

  • backlog太大：backlog太大這裏指的accept 的連接隊列設置的太大，這個參數是在服務端創建ServerSocket作爲參數傳入的，默認爲50，支持自定義，設置的太少容易出現連接reset或者拒絕，太大如果服務端處理連接不及時會放到accept隊列等待太長時間。accept隊列以及socket 連接建立流程如下圖：

    image-20200527234141069

上圖所示，這裏有兩個隊列：syns queue(半連接隊列）；accept queue（全連接隊列）。我們很多時候排查網絡問題時也需要考慮到accept queue，很多場景需要對accept queue 大小做些調整。

6.4 如何判斷是否需要調整 accept queue（全連接隊列）大小？

答：例如我們機器併發量很高，accept queue（全連接隊列） 可能會出現不夠用的情況，會出現類似connection reset 和 connection timeout 異常，這個取決於機器上 tcp_abort_on_overflow 的設置，不同值服務端不同處理機制：

tcp_abort_on_overflow爲0：連接建立過程中三次握手第三步時，發生全連接隊列滿了，server扔掉client 發過來的ack，那麼client 會重新發送ack，直到超時，所以客戶端會出現連接超時（connection timeout ）；

tcp_abort_on_overflow爲1：遇到全連接隊列滿了，server會發一個reset包給client，表示廢掉這個這個連接，這個握手過程無效，客戶端會看到很多connection reset by peer的錯誤；

查看服務器處理accept queue 隊列滿時的處理機制：

image-20200527235838846

那怎麼判斷服務端有沒有發生accept queue（全連接隊列）滿呢？ 在linux 可以採用如下指令：

netstat -s | grep "listen"

每隔幾秒打印一次，如下圖所示：

image-20200527235626558

如果overflowed 代表隊列溢出次數一直在增加，是accept 隊列大小不夠或者隊列中連接等待處理時間太長導致的。

另外通過ss 命令可以看具體端口的隊列佔用情況，如下所示：

image-20200528000349200

Send-Q 這列代表第四列端口上全連接隊列的最大值，Recv-Q 代表當前隊列有多少個連接，如果長期是滿的，代表可以適當增加全連接隊列大小了。

6.5 如何修改accept queue（全連接隊列）大小呢?

答：accept queue（全連接隊列）取決於 min(backlog, somaxconn) ，backlog是在socket創建的時候傳入的，somaxconn是一個os級別的系統參數。

對於Java後端程序，在創建Socket 時是可以傳入參數設置backlog 大小的，很多人可能沒關注過這個這個參數，看到很多程序直接使用的默認構造函數創建Socket 的。

服務端Socket構造函數 參考自JDK 1.8 文檔

如上圖所示，在創建Socket 時，可以通過傳入backlog 設置全連接隊列大小。如果不傳這個參數，默認值是50，Tomcat 默認短連接，這個值默認是100， Nginx默認是511。

6.6 爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，揮手過程中的四個報文都發送完畢，主動關閉連接的一方應當是可以直接進入CLOSE狀態了，但是必須考慮到網絡環境是十分複雜且不可靠的，有可以四次揮手最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文，假設在Client發送出最後的ACK回覆，但該ACK 如果丟失，Server沒有收到ACK，Server會重複發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了第四次揮手的ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。這個2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送加上一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。

6.7 如果三次握手連接已經建立，但是客戶端突然出現故障了怎麼辦？

答：首先，從協議設計角度來講，客戶端如果出現故障，服務端肯定不能一直死等客戶端，所以考慮這種情況的存在，TCP 協議中服務端有個計時器，每次收到客戶端的響應報文都會重置這個計時器，服務端有個超時時間，通常是2個小時，2個小時沒收到客戶端的數據，服務端會每隔75秒發送探測報文段，連續10次探測報文沒響應，認爲客戶端出現問題，服務器會關閉這個連接。一般程序設計者不會依賴這個機制，2個小時實在太長，框架裏面都會自己做連接的檢查，無效連接的關閉，例如連接池的連接驅逐策略，Apollo等框架的連接保活等。

寫在最後的話

安琪拉很早就想寫網絡這個主題了，一方面是感覺網絡這塊內容確實非常龐大，另一方面覺得自己還沒完全研究透徹，不敢寫，這篇文章也只是從我們項目中遇到的一個網絡問題引申出來的，還只是滄海一粟，要想把TCP/IP 底層的實現機制講明白不是一二篇文章能做到的，如果未來工作有需要大家也感興趣，我會把TCP/IP 這塊內容繼續深入挖掘，儘量用淺顯易懂的文字表述出來，也可能用面試對話的方式，玩家們關注【安琪拉的博客】公衆號，一起探索後端技術，還原技術背後的本質。

這又是一篇萬字長文，希望玩家們能耐着性子看完，實在嫌長可以先收藏評論再慢慢讀。我文章更新的很慢，但是每寫一篇文章，都會希望在一篇文章中能把技術都聊清楚，聊透，所以目前也一共才寫10篇文章，希望大家都能從文章中有所收穫吧！

我是安琪拉，一個在互聯網摸爬滾打的草叢技術流！

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章