筆記只是通過學(xué)習(xí)以及網(wǎng)上的博文對自己需要的內(nèi)容進(jìn)行梳理和記錄。大部分的基礎(chǔ)知識是來自一篇文章帶你熟悉 TCP/IP 協(xié)議（網(wǎng)絡(luò)協(xié)議篇二)。

計算機(jī)結(jié)構(gòu)分層

OSI模型和TCP/IP概念模型

結(jié)構(gòu)分層.png

TCP/IP 基礎(chǔ)

IP 地址、端口號、協(xié)議號標(biāo)識網(wǎng)絡(luò)中的唯一的進(jìn)程。

1.IP基礎(chǔ)

• IP協(xié)議:無連接的網(wǎng)絡(luò)協(xié)議
  • IP（IPv4、IPv6）相當(dāng)于 OSI 參考模型中的第3層——網(wǎng)絡(luò)層。網(wǎng)絡(luò)層的主要作用是“實(shí)現(xiàn)終端節(jié)點(diǎn)之間的通信”。這種終端節(jié)點(diǎn)之間的通信也叫“點(diǎn)對點(diǎn)通信”。
• IP地址: 為了識別通信對端,類似于地址的識別碼進(jìn)行標(biāo)識
  • IP 地址用于在“連接到網(wǎng)絡(luò)中的所有主機(jī)中識別出進(jìn)行通信的目標(biāo)地址"。
  • 負(fù)責(zé)將數(shù)據(jù)包路至目標(biāo)網(wǎng)絡(luò)地址。

2.TCP協(xié)議

• 有連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議。
• 充分地實(shí)現(xiàn)了數(shù)據(jù)傳輸時各種控制功能，可以進(jìn)行丟包時的重發(fā)控制，還可以對次序亂掉的分包進(jìn)行順序控制。
• 能夠?qū)崿F(xiàn)高可靠性的通信（ 主要通過檢驗(yàn)和、序列號、確認(rèn)應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機(jī)制實(shí)現(xiàn)）。

3.UDP協(xié)議

• 利用 IP 提供面向無連接的通信服務(wù)。
• 傳輸途中出現(xiàn)丟包，UDP 也不負(fù)責(zé)重發(fā)。
• 獲取數(shù)據(jù)包沒有順序糾正功能。

4.TCP與UDP協(xié)議

TCP/IP 進(jìn)階

1.TCP 三次握手（連接）

所謂三次握手是指建立一個 TCP 連接時需要客戶端和服務(wù)器端總共發(fā)送三個包以確認(rèn)連接的建立。

控制位

• ACK:確認(rèn)序號標(biāo)志
• SYN:同步序列號，用于建立連接過程
• FIN：用于釋放連接

圖解

三次握手.png

文字解釋

1. 第一次握手：客戶端將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，客戶端進(jìn)入SYN_SENT狀態(tài)，服務(wù)端進(jìn)入LISTEN階段，等待服務(wù)器端確認(rèn)。
2. 第二次握手：服務(wù)器端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請求建立連接，服務(wù)器端將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請求，服務(wù)器端進(jìn)入SYN_RCVD狀態(tài)。
3. 第三次握手：客戶端收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務(wù)器端，服務(wù)器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務(wù)器端之間可以開始傳輸數(shù)據(jù)了。

2.TCP 四次揮手（終止連接）

四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務(wù)端總共發(fā)送4個包以確認(rèn)連接的斷開。

圖解

四次揮手.png

文字解釋

1. 客戶端進(jìn)程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。
   TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。
2. 服務(wù)器收到連接釋放報文，發(fā)出確認(rèn)報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。
3. 客戶端收到服務(wù)器的確認(rèn)請求后，此時，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
4. 服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。
5. 客戶端收到服務(wù)器的連接釋放報文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。
6. 服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接?？梢钥吹剑?wù)器結(jié)束TCP連接的時間要比客戶端早一些。

相關(guān)問題

1. 為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

   • 確保足夠的時間讓對方收到ACK包，如果被動方關(guān)閉的沒收到ACK，就會觸發(fā)被動方再次發(fā)送ACK包，一來一去正好是2MSL。
   • 避免連接混淆。

2.關(guān)閉的時候需要四次握手？

• 因?yàn)門CP是全雙工（允許數(shù)據(jù)在兩個方向上同時傳輸即客戶端可以發(fā)送數(shù)據(jù)給服務(wù)端，服務(wù)端可以發(fā)送數(shù)據(jù)給客戶端）。服務(wù)器和客戶端都需要FIN報文和ACK報文。因此兩方各需兩次揮手即可，只不過其中一個是被動方。

3.滑動窗口

圖解

滑動窗口.png

文字解釋

• 上圖中的窗口內(nèi)的數(shù)據(jù)即便沒有收到確認(rèn)應(yīng)答也可以被發(fā)送出去。不過，在整個窗口的確認(rèn)應(yīng)答沒有到達(dá)之前，如果其中部分?jǐn)?shù)據(jù)出現(xiàn)丟包，那么發(fā)送端仍然要負(fù)責(zé)重傳。為此，發(fā)送端主機(jī)需要設(shè)置緩存保留這些待被重傳的數(shù)據(jù)，直到收到他們的確認(rèn)應(yīng)答。
• 在滑動窗口以外的部分包括未發(fā)送的數(shù)據(jù)以及已經(jīng)確認(rèn)對端已收到的數(shù)據(jù)。當(dāng)數(shù)據(jù)發(fā)出后若如期收到確認(rèn)應(yīng)答就可以不用再進(jìn)行重發(fā)，此時數(shù)據(jù)就可以從緩存區(qū)清除。
• 收到確認(rèn)應(yīng)答的情況下，將窗口滑動到確認(rèn)應(yīng)答中的序列號的位置。這樣可以順序地將多個段同時發(fā)送提高通信性能。這種機(jī)制也別稱為滑動窗口控制。