為了盡量講的清晰明了，以下面這個流程進行：

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

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

預備知識：回顧網絡分層、三次握手、四次揮手等網絡基礎知識

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

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

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

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

1. 異常信息

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

網絡異常棧

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

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

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

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

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

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

2. 網絡抓包

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

抓包聊天截圖

抓包命令如下：

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

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

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

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

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

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

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

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

2.1 Wireshark 簡介

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

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

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

頂部是菜單欄

淺綠色背景是過濾器，這個對于分析包很重要，后面會講

列表那一欄是包列表信息

最下面的這個是包詳細信息，包含各層協議的內容（應用層、傳輸層、網絡層、數據鏈路層、物理層）

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 網絡包，會一臉懵逼，看多了就會越看越喜歡。重點看框出來的，前三行就是三次握手的過程：

上圖第一行，客戶端向服務端發送SYN 數據包，數據長度len 為0，Seq（隨機生成包序列號）為2421858999；

上圖第二行，服務端向客戶端回應ACK 數據包，并且發送SYN 數據包，合并一起就是SYN + ACK 數據包，數據長度len 為0，Seq（隨機生成包序列號）為1988635269，ack為2421859000 = 第一次握手Seq（2421858999）+1；

上圖第三行，客戶端回應客戶端的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 ），如下：

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

3.2 三次握手

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

TCP報文格式

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

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

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

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

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

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

數據報狀態標志位（非常重要），分為以下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，表明此報文的發送方的數據已經發送完畢，并且要求釋放。

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

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

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

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

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

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

TCP連接三次握手

三次握手

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

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

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

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

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

三次握手第二步：服務端收到來自客戶端的連接請求報文后，需要確認收貨，響應報文中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是確認序號。

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

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

3.3 四次揮手

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

四次揮手

四次揮手wireshark 包信息如下，可以對照著上圖看，

Wireshark四次揮手

四次揮手的具體過程如下：

客戶端發送FIN 釋放連接報文，表示結束連接，報文seq = u（等于前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN_WAIT1（終止等待1）狀態。

服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，并且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE_WAIT（關閉等待）狀態。TCP接收方通知上層的應用進程，客戶端向服務器方向的發送通道關閉了，這時候處于半關閉狀態，即客戶端已經沒有數據要發送了（已經發了FIN結束信號），但是服務器若發送數據，客戶端依然要接受。這個狀態要持續一段時間，也就是整個CLOSE_WAIT狀態持續的時間。

客戶端收到服務器的確認請求后，此時，客戶端就進入FIN_WAIT2（終止等待2）狀態，等待服務器發送連接釋放報文（在服務端Close_Wiat期間還可以接受服務器發送的最后的數據）。

服務端發送完最后的數據，向客戶端發送FIN 連接釋放報文，ACK =1，由于在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，ack 和回復ACK報文一致，ack = u+1, 此時，服務器就進入了LAST_ACK（最后確認）狀態，等待客戶端的確認。

客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME_WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2 個MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。

服務器只要收到了客戶端發出的確認，立即進入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 問題定位

供應商接口查看狀態

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

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

結果如下：

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

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 狀態過多可能會有問題，這個我會在擴展閱讀詳細說，繼續分析異常。

確認連接方式

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

為什么服務端主動發起FIN 關閉連接呢？

為什么客戶端在接收到服務端的FIN 并回復ACK 報文之后，為什么沒有發送FIN 關閉連接報文呢？

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

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

5.1 HttpClient 長連接改為短連接

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

長連接主要代碼

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

1http{2?keepalive_timeout?60s;??#連接保持的超時時間34?upstream?servers?{5???????keepalive?10;6???}78?server?{9????listener?20004?so_keepalive=on?#這個是支持長連接的配置 10???} 11}

代碼問題修復

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

番外

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

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

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

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

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

1tcp.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 連接建立流程如下圖：

上圖所示，這里有兩個隊列：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 隊列滿時的處理機制：

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

1netstat?-s?|?grep?"listen"

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

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

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

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

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

答：accept queue（全連接隊列）取決于 min(backlog, somaxconn) ，backlog是在socket創建的時候傳入的，somaxconn是一個os級別的系統參數，somaxconn 定義了系統中每一個端口最大的監聽隊列的長度, 這是個全局的參數, 默認值為128。

- 可以通過?echo 1024 >/proc/sys/net/core/somaxconn 來臨時修改somaxconn這個參數；

- 可以在/etc/sysctl.conf 中添加如下??net.core.somaxconn = 1024 然后在終端中執行sysctl -p 讓配置永久生效；

對于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等框架的連接保活等。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的遇到网络问题你是怎么解决的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。