TCP相關(guān)知識(shí)

tcp簡(jiǎn)介 ：面向字節(jié)流 可靠的 面相連接的協(xié)議

面向連接：意味著交換數(shù)據(jù)之前，需要建立完整的TCP連接，

基于字節(jié)流：交換的數(shù)據(jù)格式是字節(jié)（byte）構(gòu)成有序，但是無結(jié)構(gòu)的 字節(jié)流，連接正常建立完成，客戶端發(fā)送無特殊格式的字節(jié)流，存在緩沖結(jié)構(gòu)用于接收數(shù)據(jù)。

TCP報(bào)文結(jié)構(gòu)：

1. 端口號(hào)：

2. 序號(hào)

3. 確認(rèn)序號(hào)

4. 首部長(zhǎng)度

5. 保留字段

6. 控制位

7. 窗口大小

8. 校驗(yàn)和

9. 緊急指針

10. 選項(xiàng)

11. 有效數(shù)據(jù)部分

可靠性：確?？煽啃砸揽咳缦率侄?/p>

1. 合理的數(shù)據(jù)大?。?/p>

2. 校驗(yàn)和

3. 序號(hào)和確認(rèn)序號(hào)

4. 超時(shí)重傳

5. 連接管理：三次握手，四次揮手

6. 流量控制

7. 擁塞控制

TCP 和 UDP 的區(qū)別

具體區(qū)別：

UDPTCP是否連接無連接面向連接是否可靠不可靠，沒有確認(rèn)機(jī)制、流量控制和擁塞控制可靠，有確認(rèn)機(jī)制、流量控制和擁塞控制連接對(duì)象個(gè)數(shù)支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多交互通信只支持一對(duì)一通信傳輸方式面向報(bào)文面向字節(jié)流首部開銷首部開銷小，固定8字節(jié)首部開銷較大，最小20字節(jié)，最大60字節(jié)適用場(chǎng)景適用于實(shí)時(shí)應(yīng)用(IP電話、視頻會(huì)議、直播等)適用于要求可靠傳輸?shù)膽?yīng)用，如文件傳輸?shù)?/p>

TCP的連接控制：

建立連接

三次握手：

1. 第一次握手：客戶端發(fā)送SYN=1 標(biāo)識(shí)建立連接，并初始化seq，發(fā)送完成客戶端進(jìn)入 SYN-SENT狀態(tài)，等待服務(wù)端確認(rèn)

2. 第二次握手：序號(hào) seq 設(shè)置為服務(wù)器初始序號(hào)y。發(fā)送完報(bào)文段2后，服務(wù)器進(jìn)入 SYN-RECEIVED 狀態(tài)

3. 第三次握手：客戶端在收到報(bào)文段2后，向服務(wù)器發(fā)送報(bào)文段3，其 ACK 標(biāo)志位為1，代表對(duì)服務(wù)器做出應(yīng)答，確認(rèn)序號(hào)字段 ack 為 y + 1，序號(hào)字段 seq 為 x + 1。此報(bào)文段發(fā)送完畢后，雙方都進(jìn)入 ESTABLISHED 狀態(tài)，表示連接已建立。

常見面試題 1： TCP 建立連接為什么要三次握手而不是兩次？

A1：

1. TCP 實(shí)現(xiàn)了可靠的數(shù)據(jù)傳輸，原因之一就是 TCP 報(bào)文段中維護(hù)了序號(hào)字段和確認(rèn)序號(hào)字段，如果是兩次握手，只有發(fā)起方的初始序號(hào)可以得到確認(rèn)，而另一方的初始序號(hào)則得不到確認(rèn)。

2. 三次握手才能讓雙方均確認(rèn)自己和對(duì)方的發(fā)送和接收能力都正常

3. 防止已過期的連接請(qǐng)求報(bào)文突然又傳送到服務(wù)器，因而產(chǎn)生錯(cuò)誤

常見面試題2： TCP 建立連接為什么要三次握手而不是四次？

A2：相比上個(gè)問題而言，這個(gè)問題就簡(jiǎn)單多了。因?yàn)槿挝帐忠呀?jīng)可以確認(rèn)雙方的發(fā)送接收能力正常，雙方都知道彼此已經(jīng)準(zhǔn)備好，而且也可以完成對(duì)雙方初始序號(hào)值得確認(rèn)，也就無需再第四次握手了。

常見面試題3： 有一種網(wǎng)絡(luò)攻擊是利用了 TCP 建立連接機(jī)制的漏洞，你了解嗎？這個(gè)問題怎么解決？

A3：在三次握手過程中，服務(wù)器在收到了客戶端的 SYN 報(bào)文段后，會(huì)分配并初始化連接變量和緩存，并向客戶端發(fā)送 SYN + ACK 報(bào)文段，攻擊者發(fā)送大量的 SYN 報(bào)文段到服務(wù)器請(qǐng)求建立連接，但是卻不進(jìn)行第三次握手，這會(huì)導(dǎo)致服務(wù)器打開大量的半開連接，消耗大量的資源，最終無法進(jìn)行正常的服務(wù)。

四次揮手：

1. 客戶端發(fā)送關(guān)閉連接的報(bào)文段，F(xiàn)IN 標(biāo)志位1，請(qǐng)求關(guān)閉連接，并停止發(fā)送數(shù)據(jù)。序號(hào)字段 seq = x (等于之前發(fā)送的所有數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加一)，然后客戶端會(huì)進(jìn)入 FIN-WAIT-1 狀態(tài)，等待來自服務(wù)器的確認(rèn)報(bào)文。

2. 服務(wù)器收到 FIN 報(bào)文后，發(fā)回確認(rèn)報(bào)文，ACK = 1， ack = x + 1，并帶上自己的序號(hào) seq = y，然后服務(wù)器就進(jìn)入 CLOSE-WAIT 狀態(tài)。服務(wù)器還會(huì)通知上層的應(yīng)用程序?qū)Ψ揭呀?jīng)釋放連接，此時(shí) TCP 處于半關(guān)閉狀態(tài)，也就是說客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器還可以發(fā)送數(shù)據(jù)，客戶端也還能夠接收。

3. 客戶端收到服務(wù)器的 ACK 報(bào)文段后隨即進(jìn)入 FIN-WAIT-2 狀態(tài)，此時(shí)還能收到來自服務(wù)器的數(shù)據(jù)，直到收到 FIN 報(bào)文段。

4. 服務(wù)器發(fā)送完所有數(shù)據(jù)后，會(huì)向客戶端發(fā)送 FIN 報(bào)文段，各字段值如圖所示，隨后服務(wù)器進(jìn)入 LAST-ACK 狀態(tài)，等待來自客戶端的確認(rèn)報(bào)文段。

5. 客戶端收到來自服務(wù)器的 FIN 報(bào)文段后，向服務(wù)器發(fā)送 ACK 報(bào)文，隨后進(jìn)入 TIME-WAIT 狀態(tài)，等待 2MSL(2 * Maximum Segment Lifetime，兩倍的報(bào)文段最大存活時(shí)間) ，這是任何報(bào)文段在被丟棄前能在網(wǎng)絡(luò)中存在的最長(zhǎng)時(shí)間，常用值有30秒、1分鐘和2分鐘。如無特殊情況，客戶端會(huì)進(jìn)入 CLOSED 狀態(tài)。

6. 服務(wù)器在接收到客戶端的 ACK 報(bào)文后會(huì)隨即進(jìn)入 CLOSED 狀態(tài)，由于沒有等待時(shí)間，一般而言，服務(wù)器比客戶端更早進(jìn)入 CLOSED 狀態(tài)。

常見面試題1： 為什么 TCP 關(guān)閉連接為什么要四次而不是三次？

A1：在數(shù)據(jù)發(fā)送完后，服務(wù)器會(huì)向客戶單發(fā)送 FIN 報(bào)文，表示數(shù)據(jù)已經(jīng)發(fā)送完畢，請(qǐng)求關(guān)閉連接，然后客戶端再做出應(yīng)答，因此一共需要四次揮手。

常見面試題2： 客戶端為什么需要在 TIME-WAIT 狀態(tài)等待 2MSL 時(shí)間才能進(jìn)入 CLOSED 狀態(tài)？

A2：客戶端為了確保服務(wù)器收到了 ACK，會(huì)設(shè)置一個(gè)定時(shí)器，并在 TIME-WAIT 狀態(tài)等待 2MSL 的時(shí)間，如果在此期間又收到了來自服務(wù)器的 FIN 報(bào)文段，那么客戶端會(huì)重新設(shè)置計(jì)時(shí)器并再次等待 2MSL 的時(shí)間，如果在這段時(shí)間內(nèi)沒有收到來自服務(wù)器的 FIN 報(bào)文，那就說明服務(wù)器已經(jīng)成功收到了 ACK 報(bào)文，此時(shí)客戶端就可以進(jìn)入 CLOSED 狀態(tài)了。

TCP 的流量控制與滑動(dòng)窗口

什么是 流量控制 ？

TCP 連接雙方的主機(jī)都為該連接設(shè)置了發(fā)送緩存和接收緩存，這些緩存起到了蓄水池的作用

滑動(dòng)窗口

發(fā)送緩存中的字節(jié)分類

1. 第一類：已發(fā)送且已確認(rèn)，這些數(shù)據(jù)已經(jīng)發(fā)送成功并已經(jīng)被確認(rèn)的數(shù)據(jù)，比如圖中的前31個(gè)bytes，這些數(shù)據(jù)其實(shí)的位置是在窗口之外了，下一步將被移出發(fā)送緩存。窗口內(nèi)順序最低的字節(jié)被確認(rèn)之后，窗口左邊界會(huì)向右移動(dòng)，稱為窗口合攏。

2. 第二類：已發(fā)送但未收到確認(rèn)，這部分?jǐn)?shù)據(jù)已經(jīng)被發(fā)送出去，但是還沒有收到接收端的 ACK，認(rèn)為并沒有完成發(fā)送，這部分?jǐn)?shù)據(jù)屬于窗口內(nèi)的數(shù)據(jù)。

3. 第三類：未發(fā)送但是接收方已經(jīng)準(zhǔn)備好接收，這部分是盡快發(fā)送的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)已經(jīng)被加載到緩存中，也在發(fā)送窗口中，正在等待發(fā)送，其實(shí)這個(gè)窗口是完全有接收方告知的，接收方告知當(dāng)前可以接受這些數(shù)據(jù)，所以發(fā)送方需要盡快的發(fā)送。

4. 第四類：未發(fā)送且接收方未準(zhǔn)備好接收，這些數(shù)據(jù)屬于未發(fā)送，同時(shí)接收端也不允許發(fā)送的，因?yàn)檫@些數(shù)據(jù)已經(jīng)超出了發(fā)送端所接收的范圍。