????????小猿的某同事不甘于現(xiàn)狀，近期到處投簡歷面試。某天，小猿只見某灰頭土臉、唉聲嘆氣，于是小猿本著看熱鬧不嫌事兒大的心態(tài)，一臉壞笑湊上去問：“大佬，最近面試咋樣，是不是都拿好幾個(gè)offer了~^_^”，某答道：“什么呀，面?zhèn)€試咋就這么難，一道面試題硬是讓面試官扯出了整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)知識(shí)圖譜，也是沒誰了~”，小猿好奇問：“啥題，啥題~”，某答：“爛大街的一道題，面試前也準(zhǔn)備了，唉，你說為啥面試官就能從這道題目扯出一堆題目...”(此處省略一萬字)
????????接下來小猿就給大家說說某遇到的這道題，還有它牽扯出的整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)圖譜。廢話不多說，直接上題目
????????題目描述一：請(qǐng)說說HTTP請(qǐng)求的整個(gè)過程
????????題目描述二：當(dāng)你在瀏覽器中輸出某個(gè)URL，按下回車后都經(jīng)歷了什么樣的流程
????????題目描述三：請(qǐng)簡單介紹一下HTTP是怎么工作的
????????相信各位猿對(duì)這道題應(yīng)該并不陌生，而且網(wǎng)上一搜一堆的講解與答案，但是某遇到的這個(gè)大牛面試官，卻可以從某的回答中延伸出更多的問題，如果想要過關(guān)，還是要對(duì)整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)體系有比較深刻的理解才行。下面先貼出小猿對(duì)這個(gè)題目的理解和可能從這道題目引出的計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)點(diǎn)，然后小猿對(duì)這些知識(shí)點(diǎn)慢慢的給大家分析。
小猿對(duì)題目的理解：
DNS解析：如果URL中是網(wǎng)址，需要向?qū)@個(gè)網(wǎng)址進(jìn)行域名解析，得到相應(yīng)的IP地址
TCP連接：根據(jù)IP，找到對(duì)應(yīng)的服務(wù)器，通過TCP的三次握手建立連接
發(fā)送HTTP請(qǐng)求：建立TCP連接后發(fā)起HTTP請(qǐng)求
服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文：服務(wù)器根據(jù)請(qǐng)求參數(shù)得到返回結(jié)果，并返回HTTP報(bào)文
瀏覽器解析渲染頁面：瀏覽器得到報(bào)文，解析HTML代碼，并請(qǐng)求HTML代碼中的資源（例如js、css等），然后渲染頁面
連接結(jié)束：TCP4次揮手，HTTP斷開連接
知識(shí)圖譜
OSI七層架構(gòu)
七層結(jié)構(gòu)簡介：
7層結(jié)構(gòu)數(shù)據(jù)傳輸流程：
詳細(xì)介紹每層的功能和
應(yīng)用層（Application Layer）
是計(jì)算機(jī)用戶，以及各種應(yīng)用程序和網(wǎng)絡(luò)之間的接口：
是用戶與網(wǎng)絡(luò)，以及應(yīng)用程序與網(wǎng)絡(luò)間的直接接口，使得用戶能夠與網(wǎng)絡(luò)進(jìn)行交互式聯(lián)系。
實(shí)現(xiàn)各種服務(wù)：該層具有的各種應(yīng)用程序可以完成和實(shí)現(xiàn)用戶請(qǐng)求的各種服務(wù)。
該層還負(fù)責(zé)協(xié)調(diào)各個(gè)應(yīng)用程序間的工作。
應(yīng)用層為用戶提供的服務(wù)和協(xié)議有：文件服務(wù)、目錄服務(wù)、文件傳輸服務(wù)（FTP）、遠(yuǎn)程登錄服務(wù)（Telnet）、電子郵件服務(wù)（E-mail）、打印服務(wù)、安全服務(wù)、網(wǎng)絡(luò)管理服務(wù)、數(shù)據(jù)庫服務(wù)等。
表示層（Presentation Layer）
對(duì)來自應(yīng)用層的命令和數(shù)據(jù)進(jìn)行解釋，對(duì)各種語法賦予相應(yīng)的含義，并按照一定的格式傳送給會(huì)話層。
主要功能：數(shù)據(jù)格式處理、編碼、壓縮解壓、加密解密等，具體說明如下：
數(shù)據(jù)格式處理：協(xié)商和建立數(shù)據(jù)交換的格式，解決各應(yīng)用程序之間在數(shù)據(jù)格式表示上的差異。
數(shù)據(jù)的編碼：處理字符集和數(shù)字的轉(zhuǎn)換。例如由于用戶程序中的數(shù)據(jù)類型（整型或?qū)嵭汀⒂蟹?hào)或無符號(hào)等）、用戶標(biāo)識(shí)等都可以有不同的表示方式，因此，在設(shè)備之間需要具有在不同字符集或格式之間轉(zhuǎn)換的功能。
壓縮和解壓縮：為了減少數(shù)據(jù)的傳輸量，這一層還負(fù)責(zé)數(shù)據(jù)的壓縮與恢復(fù)。
數(shù)據(jù)的加密和解密：可以提高網(wǎng)絡(luò)的安全性。
會(huì)話層（Session Layer）
其任務(wù)就是組織和協(xié)調(diào)兩個(gè)會(huì)話進(jìn)程之間的通信，并對(duì)數(shù)據(jù)交換進(jìn)行管理，具體如下：
會(huì)話管理：允許用戶在兩個(gè)實(shí)體設(shè)備之間建立、維持和終止會(huì)話，并支持它們之間的數(shù)據(jù)交換。例如提供單方向會(huì)話或雙向同時(shí)會(huì)話，并管理會(huì)話中的發(fā)送順序，以及會(huì)話所占用時(shí)間的長短。
會(huì)話流量控制：提供會(huì)話流量控制和交叉會(huì)話功能。
尋址：使用遠(yuǎn)程地址建立會(huì)話連接。
出錯(cuò)控制：從邏輯上講會(huì)話層主要負(fù)責(zé)數(shù)據(jù)交換的建立、保持和終止，但實(shí)際的工作卻是接收來自傳輸層的數(shù)據(jù)，并負(fù)責(zé)糾正錯(cuò)誤。會(huì)話控制和遠(yuǎn)程過程調(diào)用均屬于這一層的功能。但應(yīng)注意，此層檢查的錯(cuò)誤不是通信介質(zhì)的錯(cuò)誤，而是磁盤空間、打印機(jī)缺紙等類型的高級(jí)錯(cuò)誤。
傳輸層（Transport Layer）
向用戶提供可靠的端到端的差錯(cuò)和流量控制，保證報(bào)文的正確傳輸。傳輸層的作用是向高層屏蔽下層數(shù)據(jù)通信的細(xì)節(jié)，即向用戶透明地傳送報(bào)文。
傳輸連接管理：提供建立、維護(hù)和拆除傳輸連接的功能。傳輸層在網(wǎng)絡(luò)層的基礎(chǔ)上為高層提供“面向連接”和“面向無接連”的兩種服務(wù)。
處理傳輸差錯(cuò)：提供可靠的“面向連接”和不太可靠的“面向無連接”的數(shù)據(jù)傳輸服務(wù)、差錯(cuò)控制和流量控制。在提供“面向連接”服務(wù)時(shí)，通過這一層傳輸?shù)臄?shù)據(jù)將由目標(biāo)設(shè)備確認(rèn)，如果在指定的時(shí)間內(nèi)未收到確認(rèn)信息，數(shù)據(jù)將被重發(fā)。
監(jiān)控服務(wù)質(zhì)量。
該層常見的協(xié)議：TCP/IP中的TCP協(xié)議、Novell網(wǎng)絡(luò)中的SPX協(xié)議和微軟的NetBIOS/NetBEUI協(xié)議。
網(wǎng)絡(luò)層（Network Layer）
通過路由選擇算法，為報(bào)文或分組通過通信子網(wǎng)選擇最適當(dāng)?shù)穆窂?/p>
數(shù)據(jù)鏈路層的數(shù)據(jù)在這一層被轉(zhuǎn)換為數(shù)據(jù)包，然后通過路徑選擇、分段組合、順序、進(jìn)/出路由等控制，將信息從一個(gè)網(wǎng)絡(luò)設(shè)備傳送到另一個(gè)網(wǎng)絡(luò)設(shè)備。
尋址：數(shù)據(jù)鏈路層中使用的物理地址（如MAC地址）僅解決網(wǎng)絡(luò)內(nèi)部的尋址問題。在不同子網(wǎng)之間通信時(shí)，為了識(shí)別和找到網(wǎng)絡(luò)中的設(shè)備，每一子網(wǎng)中的設(shè)備都會(huì)被分配一個(gè)唯一的地址。由于各子網(wǎng)使用的物理技術(shù)可能不同，因此這個(gè)地址應(yīng)當(dāng)是邏輯地址（如IP地址）。
交換：規(guī)定不同的信息交換方式。常見的交換技術(shù)有：線路交換技術(shù)和存儲(chǔ)轉(zhuǎn)發(fā)技術(shù)，后者又包括報(bào)文交換技術(shù)和分組交換技術(shù)。
路由算法：當(dāng)源節(jié)點(diǎn)和目的節(jié)點(diǎn)之間存在多條路徑時(shí)，本層可以根據(jù)路由算法，通過網(wǎng)絡(luò)為數(shù)據(jù)分組選擇最佳路徑，并將信息從最合適的路徑由發(fā)送端傳送到接收端。
連接服務(wù)：與數(shù)據(jù)鏈路層流量控制不同的是，前者控制的是網(wǎng)絡(luò)相鄰節(jié)點(diǎn)間的流量，后者控制的是從源節(jié)點(diǎn)到目的節(jié)點(diǎn)間的流量。其目的在于防止阻塞，并進(jìn)行差錯(cuò)檢測(cè)。
數(shù)據(jù)鏈路層是解決同一網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)之間的通信，而網(wǎng)絡(luò)層主要解決不同子網(wǎng)間的通信。例如在廣域網(wǎng)之間通信時(shí)，必然會(huì)遇到路由（即兩節(jié)點(diǎn)間可能有多條路徑）選擇問題。?
數(shù)據(jù)鏈路層（Data Link Layer）
物理層提供的比特流的基礎(chǔ)上，通過差錯(cuò)控制、流量控制方法，使有差錯(cuò)的物理線路變?yōu)闊o差錯(cuò)的數(shù)據(jù)鏈路，即提供可靠的通過物理介質(zhì)傳輸數(shù)據(jù)的方法。
該層通常又被分為介質(zhì)訪問控制（MAC）和邏輯鏈路控制（LLC）兩個(gè)子層
MAC子層的主要任務(wù)是解決共享型網(wǎng)絡(luò)中多用戶對(duì)信道競爭的問題，完成網(wǎng)絡(luò)介質(zhì)的訪問控制；
LLC子層的主要任務(wù)是建立和維護(hù)網(wǎng)絡(luò)連接，執(zhí)行差錯(cuò)校驗(yàn)、流量控制和鏈路控制。數(shù)據(jù)鏈路層的具體工作是接收來自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層；同樣，也將來自上層的數(shù)據(jù)幀，拆裝為位流形式的數(shù)據(jù)轉(zhuǎn)發(fā)到物理層；并且，還負(fù)責(zé)處理接收端發(fā)回的確認(rèn)幀的信息，以便提供可靠的數(shù)據(jù)傳輸。
物理層（Physical Layer）
利用傳輸介質(zhì)為數(shù)據(jù)鏈路層提供物理連接，實(shí)現(xiàn)比特流的透明傳輸。
物理層的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么。
分享一張大而全的七層協(xié)議框架圖
TCP/IP協(xié)議-OSI的一種“實(shí)現(xiàn)”
傳輸控制協(xié)議TCP簡介
面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議
將應(yīng)用的數(shù)據(jù)流分割成報(bào)文段并發(fā)送個(gè)給目標(biāo)節(jié)點(diǎn)的TCP層，
分段的長度受數(shù)據(jù)鏈路層MTU(最大傳輸單元，Maximum Transmission Unit)的限制
TCP單個(gè)數(shù)據(jù)報(bào)的最大長度稱為最大段尺寸MSS；
在TCP三次握手建立連接的時(shí)候，雙方會(huì)商量傳輸中MSS的大??；
數(shù)據(jù)包都有序號(hào)以保證消息接收的順序，對(duì)方收到則發(fā)送ACK確認(rèn)，未收到則重傳
使用奇偶校驗(yàn)和來校驗(yàn)數(shù)據(jù)在傳輸過程中是否有誤
TCP報(bào)文頭
SourcePort：源端口，占用2個(gè)字節(jié)。源端口和IP地址的作用是標(biāo)識(shí)報(bào)文的返回地址。
p.s. IP可以唯一表示一臺(tái)主機(jī)，TCP協(xié)議和端口號(hào)可以唯一表示主機(jī)中的一個(gè)進(jìn)程；所以我們可以根據(jù)IP地址+協(xié)議+端口號(hào)唯一表示網(wǎng)絡(luò)中的一個(gè)進(jìn)程（即Socket的工作原理）。
DestinationPort：目的端口，占用2個(gè)字節(jié)；指明接收方計(jì)算機(jī)上的應(yīng)用程序的端口。
SequenceNumber（序號(hào)seq）：本報(bào)文段發(fā)送的數(shù)據(jù)組的第一個(gè)字節(jié)的序號(hào)。e.g.一個(gè)報(bào)文段的序號(hào)為300，此報(bào)文段數(shù)據(jù)部分共有100字節(jié)，則下一個(gè)報(bào)文段的序號(hào)為400。所以序號(hào)確保了TCP傳輸?shù)挠行蛐浴?/p>
AcknowledgmentNumber（確認(rèn)號(hào)ack）：指明下一個(gè)期待收到的字節(jié)序號(hào)，表明該序號(hào)之前的所有數(shù)據(jù)已經(jīng)正確無誤的收到。確認(rèn)號(hào)只有當(dāng)ACK標(biāo)志為1時(shí)才有效。
offset（數(shù)據(jù)偏移）：占用4bits。由于首部可能含有可選項(xiàng)內(nèi)容，因此TCP報(bào)頭的長度是不確定的，報(bào)頭不包含任何任選字段則長度為20字節(jié)，4位首部長度字段所能表示的最大值為1111，轉(zhuǎn)化為10進(jìn)制為15，15*32/8 = 60，故報(bào)頭最大長度為60字節(jié)。首部長度也叫數(shù)據(jù)偏移，是因?yàn)槭撞块L度實(shí)際上指示了數(shù)據(jù)區(qū)在報(bào)文段中的起始偏移值。
Reserved（保留字節(jié)）：為將來定義新的用途保留，現(xiàn)在一般置0。
TCP Flags（TCP控制位）
SYN：同步序號(hào)，用于建立連接過程，在連接請(qǐng)求中，SYN=1和ACK=0表示該數(shù)據(jù)段沒有使用捎帶的確認(rèn)域，而連接應(yīng)答捎帶一個(gè)確認(rèn)，即SYN=1和ACK=1。?
ACK：確認(rèn)序號(hào)標(biāo)志，為1時(shí)表示確認(rèn)號(hào)有效，為0表示報(bào)文中不含確認(rèn)信息，忽略確認(rèn)號(hào)字段。?
FIN：finish標(biāo)志，用于釋放連接，為1時(shí)表示發(fā)送方已經(jīng)沒有數(shù)據(jù)發(fā)送了，即關(guān)閉本方數(shù)據(jù)流。
URG：緊急指針標(biāo)志，為1時(shí)表示緊急指針有效，為0則忽略緊急指針。?
PSH：push標(biāo)志，為1表示是帶有push標(biāo)志的數(shù)據(jù)，指示接收方在接收到該報(bào)文段以后，應(yīng)盡快將這個(gè)報(bào)文段交給應(yīng)用程序，而不是在緩沖區(qū)排隊(duì)。?
RST：重置連接標(biāo)志，用于重置由于主機(jī)崩潰或其他原因而出現(xiàn)錯(cuò)誤的連接?；蛘哂糜诰芙^非法的報(bào)文段和拒絕連接請(qǐng)求。?
CWR：Congestion Window Reduced
ECE：ECN echo
Window（窗口）：滑動(dòng)窗口大小，用來告知發(fā)送端接受端的緩存大小，以此控制發(fā)送端發(fā)送數(shù)據(jù)的速率，從而達(dá)到流量控制。窗口大小時(shí)一個(gè)16bit字段，因而窗口大小最大為65535。
Checksum（校驗(yàn)和）：奇偶校驗(yàn)，此校驗(yàn)和是對(duì)整個(gè)的?TCP?報(bào)文段，包括?TCP?頭部和?TCP?數(shù)據(jù)，以 16位進(jìn)行計(jì)算所得。由發(fā)送端計(jì)算和存儲(chǔ)，并由接收端進(jìn)行驗(yàn)證。
UrgentPointer（緊急指針）：只有當(dāng)?URG?標(biāo)志置?1?時(shí)緊急指針才有效。緊急指針是一個(gè)正的偏移量，和順序號(hào)字段中的值相加表示緊急數(shù)據(jù)最后一個(gè)字節(jié)的序號(hào)。?TCP?的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式。
TCP Options（選項(xiàng)與填充）如果沒有選項(xiàng)，則TCP頭長度是20字節(jié)，TCP選項(xiàng)最大是40個(gè)字節(jié)。最常見的可選字段是最長報(bào)文大小，又稱為MSS（Maximum Segment Size），每個(gè)連接方通常都在通信的第一個(gè)報(bào)文段（為建立連接而設(shè)置SYN標(biāo)志為1的那個(gè)段）中指明這個(gè)選項(xiàng)，它表示本端所能接受的最大報(bào)文段的長度。選項(xiàng)長度不一定是32位的整數(shù)倍，所以要加填充位，即在這個(gè)字段中加入額外的零，以保證TCP頭是32的整數(shù)倍。
Data（數(shù)據(jù)部分）TCP?報(bào)文段中的數(shù)據(jù)部分是可選的。在一個(gè)連接建立和一個(gè)連接終止時(shí)，雙方交換的報(bào)文段僅有?TCP?首部。如果一方?jīng)]有數(shù)據(jù)要發(fā)送，也使用沒有任何數(shù)據(jù)的首部來確認(rèn)收到的數(shù)據(jù)。在處理超時(shí)的許多情況中，也會(huì)發(fā)送不帶任何數(shù)據(jù)的報(bào)文段。
說說TCP的三次握手
在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個(gè)連接
第一次握手：建立連接時(shí)，客戶端發(fā)送SYN包到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。這里發(fā)送的SYN包，SYN標(biāo)志位為1，seq序號(hào)初始為x
第二次握手：服務(wù)器收到SYN包，必須確認(rèn)客戶的SYN，同時(shí)自己也發(fā)送一個(gè)SYN包給客戶端，此時(shí)服務(wù)端進(jìn)入SYN_RECV狀態(tài)。這里服務(wù)端發(fā)送的SYN包中SYN標(biāo)志位和ACK標(biāo)志位都是1，seq序號(hào)初始為y，ack為x+1（表示客戶端下次再發(fā)送包seq從x+1開始）
第三次握手：客戶端收到服務(wù)器的SYN+ACK的包，向服務(wù)器發(fā)送確認(rèn)包，此包ACK標(biāo)志位1，seq序號(hào)為x+1，ack為y+1（表示服務(wù)端下一次發(fā)送數(shù)據(jù)seq從y+1開始）。此包發(fā)送完畢，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，開始數(shù)據(jù)傳送。
為什么需要三次握手才能建立連接
為了初始化SequenceNumber
為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷以及防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
三次握手的隱患-SYN Flood
問題描述
Server收到Client的SYN，回復(fù)SYN-ACK的時(shí)候未收到ACK確認(rèn)
Server不斷重試直至超時(shí)，Linux默認(rèn)等待63秒才斷開連接（Linux默認(rèn)重試5次，每次等待時(shí)間翻倍，第一次重試前等待時(shí)間為1秒，第五次重試后等待時(shí)間是32秒，然后才斷開連接）
惡意攻擊者，不斷向服務(wù)端發(fā)送SYN請(qǐng)求后立刻下線，服務(wù)器端會(huì)等待63秒后才斷開連接，進(jìn)而導(dǎo)致服務(wù)端資源耗盡，讓正常的連接請(qǐng)求不能處理
針對(duì)SYN Flood的防護(hù)措施
針對(duì)上述問題的解決辦法
SYN隊(duì)列滿后，通過tcp_syncookies參數(shù)回發(fā)SYN Cookie
如果是正常連接，Client會(huì)回發(fā)SYN Cookie給服務(wù)端；如果是惡意攻擊，因?yàn)镃lient已經(jīng)下線，則不會(huì)返回。
正常連接返回SYN Cookie后，可以直接建立連接
建立連接后，Client出現(xiàn)故障怎么辦
?；顧C(jī)制
向?qū)Ψ桨l(fā)送保活探測(cè)報(bào)文，如果未收到響應(yīng)則繼續(xù)發(fā)送
嘗試次數(shù)達(dá)到保活探測(cè)數(shù)仍未收到響應(yīng)，則中斷連接
TCP四次揮手
揮手是為了終止連接，TCP采用四次揮手來釋放連接
第一次揮手：Client發(fā)送一個(gè)FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN-WAIT_1狀態(tài)；
第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給client，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），Server進(jìn)入CLOSE_WAIT狀態(tài)；Client接收到Server的FIN之后，進(jìn)入FIN_WAIT_2狀態(tài)；
第三次揮手：Server發(fā)送一個(gè)FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)；
第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server，確認(rèn)序號(hào)為收到序號(hào)+1，Server進(jìn)入CLOSED狀態(tài)，完成四次握手
為什么要有TIME_WAIT狀態(tài)
防止上一次連接中的包，迷路后重新出現(xiàn)，影響新連接（經(jīng)過2MSL，上一次連接中所有的重復(fù)包都會(huì)消失）
可靠的關(guān)閉TCP連接。為的是確認(rèn)服務(wù)器端是否收到客戶端發(fā)出的ACK確認(rèn)報(bào)文。當(dāng)客戶端發(fā)出最后的ACK確認(rèn)報(bào)文時(shí)，并不能確定服務(wù)器端能夠收到該段報(bào)文。所以客戶端在發(fā)送完ACK確認(rèn)報(bào)文之后，會(huì)設(shè)置一個(gè)時(shí)長為2MSL的計(jì)時(shí)器。MSL指的是Maximum Segment Lifetime：一段TCP報(bào)文在傳輸過程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報(bào)文和客戶端發(fā)出的ACK確認(rèn)報(bào)文所能保持有效的最大時(shí)長。
服務(wù)器端在1MSL內(nèi)沒有收到客戶端發(fā)出的ACK確認(rèn)報(bào)文，就會(huì)再次向客戶端發(fā)出FIN報(bào)文；
如果客戶端在2MSL內(nèi)，再次收到了來自服務(wù)器端的FIN報(bào)文，說明服務(wù)器端由于各種原因沒有接收到客戶端發(fā)出的ACK確認(rèn)報(bào)文?？蛻舳嗽俅蜗蚍?wù)器端發(fā)出ACK確認(rèn)報(bào)文，計(jì)時(shí)器重置，重新開始2MSL的計(jì)時(shí)；
否則客戶端在2MSL內(nèi)沒有再次收到來自服務(wù)器端的FIN報(bào)文，說明服務(wù)器端正常接收了ACK確認(rèn)報(bào)文，客戶端可以進(jìn)入CLOSED階段，完成“四次揮手”。
為什么需要四次握手
因?yàn)槿p工，發(fā)送方和接收方都需要FIN報(bào)文和ACK保報(bào)文
建立連接時(shí)，被動(dòng)方服務(wù)器端結(jié)束CLOSED階段進(jìn)入“握手”階段并不需要任何準(zhǔn)備，可以直接返回SYN和ACK報(bào)文，開始建立連接。釋放連接時(shí)，被動(dòng)方服務(wù)器，突然收到主動(dòng)方客戶端釋放連接的請(qǐng)求時(shí)并不能立即釋放連接，因?yàn)檫€有必要的數(shù)據(jù)需要處理，所以服務(wù)器先返回ACK確認(rèn)收到報(bào)文，經(jīng)過CLOSE-WAIT階段準(zhǔn)備好釋放連接之后，才能返回FIN釋放連接報(bào)文。
服務(wù)器出現(xiàn)大量CLOSE_WAIT狀態(tài)的原因
如果一直保持在CLOSE_WAIT狀態(tài)，那么只有一種情況，就是在對(duì)方關(guān)閉連接之后服務(wù)器程序自己沒有進(jìn)一步發(fā)出ack信號(hào)。換句話說，就是在對(duì)方連接關(guān)閉之后，程序里沒有檢測(cè)到，或者程序壓根就忘記了這個(gè)時(shí)候需要關(guān)閉連接，于是這個(gè)資源就一直被程序占著。
檢查代碼，特別是釋放資源的代碼
檢查配置，特別是處理請(qǐng)求的線程配置 ? ?
寫了這么多，請(qǐng)?jiān)试S小猿喘口氣~，今天就到這吧，未完待續(xù)...?
更多精彩可以搜索公眾號(hào)：隔壁王小猿（happy-gbwxy）關(guān)注，公眾號(hào)留言可以獲取JAVA面試寶典哦 (*^▽^*)
