?????? write in front????????
?????????大家好，我是xiaoxie.希望你看完之后,有不足之處請多多諒解，讓我們一起共同進(jìn)步????? . ?? ?xiaoxie?????????—CSDN博客
本文由xiaoxie??????????原創(chuàng) CSDN?如需轉(zhuǎn)載還請通知?????
個人主頁：xiaoxie?????????—CSDN博客

系列專欄:xiaoxie的計算機網(wǎng)絡(luò)學(xué)習(xí)系列專欄——CSDN博客●'?'σσ??

"探索未來,掌握人工智能"🚀 點擊加入我們的AI學(xué)習(xí)之旅，讓技術(shù)變得有趣又易懂,點擊跳轉(zhuǎn)
我的目標(biāo):"團團等我💪( ??_?? ?)"?

(?????????? )歡迎各位→點贊👍 + 收藏?? + 留言📝?+關(guān)注（互三必回）!

目錄

?編輯??一.TCP協(xié)議

1.TCP協(xié)議的特點

2.TCP協(xié)議的格式

1.簡單介紹各個字段

3.TCP的十個重要的機制

1.確認(rèn)應(yīng)答

2.超時重傳

1.傳輸?shù)臄?shù)據(jù)出現(xiàn)丟包

2.ACK丟包

3.超時重傳的超時時間如何設(shè)定

?4.TCP的可靠性是如何保證的(面試題)

3.連接管理

1.三次握手

1.三次握手的意義是什么,解決了啥問題

2.TCP為啥要三次握手,兩次可以嗎,四次可以嗎

3.TCP三次握手的狀態(tài)和Socket api

2.四次揮手

1. 四次揮手是否可以像三次握手一樣,合并成三次揮手呢?

2.TCP四次揮手的狀態(tài)(重要)

?3.TCP狀態(tài)轉(zhuǎn)換的詳細(xì)圖片

4.滑動窗口

1. 滑動窗口出現(xiàn)丟包的情況:

情況一:數(shù)據(jù)包抵達(dá)了,ACK出現(xiàn)了丟包

情況二:數(shù)據(jù)包出現(xiàn)了丟包

?編輯

5.流量控制

6.擁塞控制

1.擁塞控制,擁塞窗口, 大小動態(tài)變化,具體是咋變的? 是否有規(guī)律??

7.延時應(yīng)答

?8.捎帶應(yīng)答

9.粘包問題

10.異常情況

?1.其中某一個進(jìn)程崩潰

2.某個主機被關(guān)機(正常關(guān)機)

3.某個主機電源斷電(非正常關(guān)機)

4.網(wǎng)線斷開

4.如何使用UDP實現(xiàn)可靠性傳輸(面試題)

?編輯

---

??一.TCP協(xié)議

1.TCP協(xié)議的特點

1.有連接

在數(shù)據(jù)傳輸開始之前，TCP需要建立一個連接，這通常通過三次握手來完成。一旦連接建立，數(shù)據(jù)就可以在兩個端點之間雙向傳輸，直到連接被關(guān)閉。

2.可靠傳輸

TCP通過使用序列號、確認(rèn)應(yīng)答、數(shù)據(jù)重傳以及窗口機制等技術(shù)，確保數(shù)據(jù)的可靠傳輸。如果數(shù)據(jù)包在傳輸過程中丟失或損壞，TCP會重新發(fā)送丟失或損壞的數(shù)據(jù)包，直到接收端正確接收到所有數(shù)據(jù)。

3.面向字節(jié)流

TCP不像UDP那樣傳輸數(shù)據(jù)報，而是將數(shù)據(jù)視為連續(xù)的字節(jié)流。這意味著TCP不保留數(shù)據(jù)包邊界，它負(fù)責(zé)將整個數(shù)據(jù)流從一個端點傳輸?shù)搅硪粋€端點。

4.全雙工

TCP允許通信雙方同時發(fā)送和接收數(shù)據(jù)，即數(shù)據(jù)傳輸是雙向的，并且雙方可以獨立控制數(shù)據(jù)的發(fā)送和接收速率。

2.TCP協(xié)議的格式

?

這里只是簡單的介紹一下 ,每一個字段表示的是什么意思,后續(xù)會結(jié)合具體的TCP機制和字段一起詳細(xì)的介紹

1.簡單介紹各個字段

1. 源端口號（Source Port）：16位，用于標(biāo)識發(fā)送方的端口號。端口號用于區(qū)分同一IP地址上的不同服務(wù)或應(yīng)用程序。

2. 目的端口號（Destination Port）：16位，用于標(biāo)識接收方的端口號。端口號同樣用于區(qū)分不同服務(wù)或應(yīng)用程序。

3. 序列號（Sequence Number）：32位，用于標(biāo)識從發(fā)送方發(fā)送的數(shù)據(jù)字節(jié)的順序。序列號用于確保數(shù)據(jù)的有序傳輸，并允許接收方檢測丟包。

4. 確認(rèn)號（Acknowledgment Number）：32位，用于期望從接收方接收的下一個字節(jié)的序列號。這是發(fā)送方期望接收的下一個字節(jié)，用于確認(rèn)已成功接收數(shù)據(jù)。

5. 數(shù)據(jù)偏移（Data Offset）：4位，實際上表示頭部中數(shù)據(jù)起始處距離報文段開始處的字節(jié)數(shù)。因為TCP頭部最小長度是20字節(jié)，最大可以達(dá)到60字節(jié)（如果包含所有選項）。這個字段也被稱為“頭部長度”字段。

6. 保留（Reserved）：6位，目前未使用，必須設(shè)置為0。

7. 標(biāo)志位（Flags）：6位，用于控制TCP的行為，具體包括：

   • URG（緊急指針有效 Urgent Pointer）：當(dāng)設(shè)置時，表明緊急指針字段有效，指示應(yīng)優(yōu)先處理報文段中的緊急數(shù)據(jù)。
   • ACK（確認(rèn)號有效 Acknowledgment）：當(dāng)設(shè)置時，表明確認(rèn)號字段包含有效的確認(rèn)信息。
   • PSH（推 Push）：當(dāng)設(shè)置時，指示接收方應(yīng)盡快將數(shù)據(jù)推送給應(yīng)用程序，而不是緩沖。
   • RST（重置 Reset）：當(dāng)設(shè)置時，表明需要立即重置連接。
   • SYN（同步序列編號 Synchronize Sequence Numbers）：當(dāng)設(shè)置時，用于建立連接時的握手階段，同步雙方的序列號。
   • FIN（結(jié)束 Finish）：當(dāng)設(shè)置時，表明發(fā)送方?jīng)]有更多的數(shù)據(jù)要發(fā)送，請求釋放連接。

8. 窗口大小（Window Size）：16位，用于流量控制，指示接收方可以接收的字節(jié)數(shù)。窗口大小隨時間變化，取決于接收方的緩沖區(qū)容量。

9. 校驗和（Checksum）：16位，用于錯誤檢測。包含整個TCP報文段，包括頭部和數(shù)據(jù)，但不包括數(shù)據(jù)鏈路層的頭部。

10. 緊急指針（Urgent Pointer）：16位，僅當(dāng)URG標(biāo)志位被設(shè)置時使用，指示緊急數(shù)據(jù)的結(jié)束位置。

11. 選項（Options）：長度可變，用于各種用途，如：

    • 最大報文段大小（MSS - Maximum Segment Size）：通常在連接建立時設(shè)置，指示發(fā)送方可以接收的最大TCP報文段大小。
    • 窗口縮放（Window Scale）：允許使用更大的窗口大小，超過16位可以表示的范圍。
    • 選擇性確認(rèn)（Selective Acknowledgment, SACK）：允許接收方指示哪些數(shù)據(jù)段已經(jīng)成功接收，有助于更有效地處理丟包。

12. 填充（Padding）：確保整個頭部是32位的倍數(shù)，如果必要的話。

13. 數(shù)據(jù)（Data）：實際傳輸?shù)臄?shù)據(jù)負(fù)載。數(shù)據(jù)字段的大小取決于頭部的長度和MSS。

TCP頭部的設(shè)計旨在提供一種可靠、有序、全雙工的數(shù)據(jù)傳輸方式，同時允許流量控制和擁塞控制，以適應(yīng)不同的網(wǎng)絡(luò)條件。

3.TCP的十個重要的機制

1.確認(rèn)應(yīng)答

對于TCP協(xié)議來說,最重要的就是可靠性問題,注意這里的可靠性并不是說使用TCP傳輸數(shù)據(jù),數(shù)據(jù)100%可以從發(fā)送方傳輸?shù)浇邮辗?而是TCP盡最大的努力使數(shù)據(jù)從接收方傳輸?shù)浇邮辗?這其中最重要的就是讓發(fā)送方知道,接收方是否收到數(shù)據(jù).所以當(dāng)發(fā)生方發(fā)生一個數(shù)據(jù)之后,接收方就會回復(fù)一個應(yīng)答報文,表示自己接收到了信息.

?

那么如何知道這個報文是應(yīng)答報文呢? 是通過TCP協(xié)議格式里的6位標(biāo)志位來判斷該報文為應(yīng)答報文的

?而應(yīng)答 - > acknowledge - > ACK,即ACK這個標(biāo)志位為1,即可用來表示該報文為應(yīng)答報文.并且該報文段是一個對之前接收到的數(shù)據(jù)的應(yīng)答。接收方使用這個應(yīng)答來告知發(fā)送方它已經(jīng)成功接收了特定的數(shù)據(jù)，并準(zhǔn)備好接收接下來的數(shù)據(jù)。

上述單純的應(yīng)答,如果是批量發(fā)送數(shù)據(jù)的時候,就會出現(xiàn)問題,例如下圖這個情況:

可以看到接收方的ACK并沒有按照順序到達(dá)發(fā)送方,而是出現(xiàn)了后發(fā)先至的效果,這種情況在網(wǎng)絡(luò)通信中是不可避免的,那我們該如何區(qū)分那個ACK是對應(yīng)的發(fā)送方發(fā)送的數(shù)據(jù)的應(yīng)答了,這個時候就需要對傳輸?shù)臄?shù)據(jù)進(jìn)行編號,并且使應(yīng)答報文的編號和發(fā)送的數(shù)據(jù)的編號對應(yīng)起來,這個時候就需要用到TCP報頭格式的32位序號和32位確認(rèn)序號

?TCP序號是按照字節(jié)來編號的,并且每個字節(jié)都有編號,例如第一個字節(jié)序號為1,第二個字節(jié)序號為2,字節(jié)的編號是連續(xù)遞增的,所以我們只要知道第一個字節(jié)的序號,剩下的字節(jié)的序號就明白了.注意序號不一定是由0或者1開始的,而是根據(jù)接收和發(fā)送雙方協(xié)商好的,(這個后續(xù)解釋)例:

如果 一個TCP數(shù)據(jù)報的載荷為1000字節(jié)那么它的序號就為1(這里只是為了簡單就設(shè)為1,真實情況可能為別的數(shù),但是其連續(xù)遞增的性質(zhì)不變);

它的確認(rèn)序號就非常有意思了,它的取值就為要應(yīng)答的數(shù)據(jù)的最后一個字節(jié)在 + 1;

也就是如果以上圖這個TCP數(shù)據(jù)報舉例,那么它的應(yīng)答報文的確認(rèn)序號就為1001,即:

其中的確認(rèn)序號可以從兩個方面來理解:

1.對于接收方來說, < 1001 的數(shù)據(jù)已經(jīng)確認(rèn)收到了

2.接收方在向發(fā)送方索要從1001開始的數(shù)據(jù).

這個序號和確認(rèn)序號設(shè)計的非常精妙不僅完美的解決了網(wǎng)絡(luò)傳輸先發(fā)后至的問題,還未后續(xù)的機制帶來了很多遍歷.

2.超時重傳

TCP中最核心的就是可靠性傳輸,而可靠性傳輸主要就是依靠確認(rèn)應(yīng)答,但是如果出現(xiàn),ACK或者數(shù)據(jù)在網(wǎng)絡(luò)傳輸?shù)倪^程出現(xiàn)丟包的情況,這個是無法避免的,是客觀存在的,這個時候TCP就是使用超時重傳這個策略來應(yīng)對這個情況的,可以說,超時重傳時確認(rèn)應(yīng)答的重要補充,TCP之所以可以可靠性傳輸,全靠,確認(rèn)應(yīng)答和傳輸重傳這兩個機制.

在網(wǎng)絡(luò)傳輸?shù)倪^程中,有可能是傳輸?shù)臄?shù)據(jù)出現(xiàn)丟包的情況,也有可能是ACK應(yīng)答報文出現(xiàn)丟包的情況.不同的情況,自然TCP解決的方式就不一樣了.

1.傳輸?shù)臄?shù)據(jù)出現(xiàn)丟包

正常情況下,TCP是依靠確認(rèn)應(yīng)答來確定接收方是否接收到發(fā)送方傳輸?shù)臄?shù)據(jù).如果出現(xiàn)下圖的情況,即發(fā)送方發(fā)送的數(shù)據(jù)在網(wǎng)絡(luò)傳輸?shù)倪^程中,出現(xiàn)丟包的情況,接收方?jīng)]有收到數(shù)據(jù)自然也就不會發(fā)送ACK應(yīng)答報文了

而發(fā)送方就可以根據(jù)是否收到ACK,來判斷是否出現(xiàn)丟包的情況.正常情況下,發(fā)送方發(fā)送數(shù)據(jù)到接收方,到接收方發(fā)送ACK給發(fā)送方,在網(wǎng)絡(luò)傳輸可能會經(jīng)歷一段時間的,但如果超過規(guī)定的超時時間的一個閾值(超時),發(fā)送方就會認(rèn)為數(shù)據(jù)丟包了,就會重傳數(shù)據(jù)給接收方,注意:哪怕數(shù)據(jù)并沒有出現(xiàn)丟包,只是傳輸時間過長即超過閾值(這個是有可能發(fā)生的),也會被認(rèn)為數(shù)據(jù)發(fā)生丟包.這個就是超時重傳機制.至于接收方會收到兩份相同的數(shù)據(jù),不用擔(dān)心,接收方會有相應(yīng)的策略進(jìn)行數(shù)據(jù)的去重(后續(xù)介紹).

2.ACK丟包

傳輸?shù)臄?shù)據(jù)出現(xiàn)丟包,ACK自然也可能出現(xiàn)丟包的情況.如下圖所示:

?站在A的視角之中,它無法判斷是數(shù)據(jù)發(fā)生了丟包,還是ACK發(fā)生了丟包的情況,只要超過一定的時間之內(nèi),它就會重傳數(shù)據(jù).這個時候B就會收到兩份相同的數(shù)據(jù)了,發(fā)生這種情況如果B沒有相應(yīng)的策略的話,就會造成很嚴(yán)重的后果,就比如,你轉(zhuǎn)賬時,觸發(fā)了超時重傳機制就會發(fā)生重復(fù)轉(zhuǎn)賬的操作,所以TCP為了防止這個情況的發(fā)生,就設(shè)計了一個策略,通過序號對數(shù)據(jù)進(jìn)行去重,那么是如何實現(xiàn)這個策略的呢;

在接收方操作系統(tǒng)的內(nèi)核中,有一個數(shù)據(jù)結(jié)構(gòu) ->接收緩沖區(qū) - > 優(yōu)先級阻塞隊列;

B(接收方)在收到數(shù)據(jù)的時候?qū)訉臃钟?到了傳輸層的時候,就會把傳輸?shù)臄?shù)據(jù)先存儲到這個阻塞隊列中,再從阻塞隊列中以此的讀取數(shù)據(jù).在放的過程中是阻塞隊列就會根據(jù)當(dāng)前數(shù)據(jù)的序號來判斷當(dāng)前這個數(shù)據(jù)是否存在過,如果存在就丟棄,不存在才放到隊列中.那么阻塞隊列是如何判斷數(shù)據(jù)是否存在過的呢,這個時候就要根據(jù)之前提到過的數(shù)據(jù)的序號是連續(xù)遞增的,如果當(dāng)前數(shù)據(jù)出現(xiàn)和在隊首的數(shù)據(jù)的序號相同或者小于的情況就說明,當(dāng)前數(shù)據(jù)曾經(jīng)存在或者現(xiàn)在就在隊列中,就會把這個數(shù)據(jù)給丟棄掉.從而達(dá)到去重的效果.

由于隊首元素為1000,這個時候有個序號為500的數(shù)據(jù)想要加入隊列中,就會被丟棄,因為隊首元素的序號為1000就說明序號為500的數(shù)據(jù)曾經(jīng)出現(xiàn)過,就不能重復(fù)傳輸了.

3.超時重傳的超時時間如何設(shè)定

首先需要明確,這個時間并不是固定的,而是動態(tài)變化的,也就是說,假設(shè)第一次的超時時間為 50ms(這個時間是操作系統(tǒng)規(guī)定,我這里是隨意寫的),等待50ms后沒有收到數(shù)據(jù),觸發(fā)超時重傳,第二次的超時時間就為100ms如果還是沒有收到,就繼續(xù)重傳,這個時候超時時間就變成了150ms.當(dāng)然這個時間并不一定是這樣增長的,具體的增長是由操作系統(tǒng)決定,總之,這個超時時間它是會動態(tài)增長的.而不是一直是固定某個數(shù)值,也不會縮短(畢竟發(fā)生多次丟包,后續(xù)成功的可能性也就越來越低了,縮短超時時間反而浪費系統(tǒng)資源).

注意:如果網(wǎng)絡(luò)出現(xiàn)故障,重傳多次后,依然不成功,達(dá)到一定的閾值之后,就會嘗試重置連接即觸發(fā)一個"復(fù)位報文"重置連接即6位標(biāo)志位其中一位的"RST"這個時候就會把之前TCP連接傳輸?shù)闹虚g狀態(tài)給清空,例如接收緩沖區(qū)的數(shù)據(jù)都會清空.重新開始傳輸.這個時候如果還是無法傳輸?shù)脑?就會斷開連接

?4.TCP的可靠性是如何保證的(面試題)

這個時候就需要回答也只能回答依靠 確認(rèn)應(yīng)答機制和傳輸重傳機制不能多也不能少然后在回答具體的機制的內(nèi)容即可.這里就不過多的贅述了.

3.連接管理

1.三次握手

TCP建立起連接就是,通過實現(xiàn)三次握手實現(xiàn)的,三次握手即,通信的雙方通過三次網(wǎng)絡(luò)交互,互相保存對方的信息,即為建立起了連接.

注意:第一次發(fā)起連接的 一定是客戶端,也就是說誰發(fā)起的誰就是客戶端,假如是服務(wù)端發(fā)起的,它就不是服務(wù)器了,而是客戶端了,同時這個在三次握手期間,發(fā)送的數(shù)據(jù)報是不攜帶任何業(yè)務(wù)數(shù)據(jù)的,也就是該數(shù)據(jù)的載荷部分是空的,只有TCP報頭,如果是同步報文,它的六位標(biāo)志位其中的一位"SYN"為1.

?同時在上述建立連接的過程中,其實就是客戶端和服務(wù)端,互相給對方發(fā)送SYN,再各自給對方發(fā)送ACK,其實是四次交互,那為什么是三次握手呢,主要是因為在建立連接的過程中,傳輸?shù)臄?shù)據(jù)都沒有載荷,就可以把,中間過程的服務(wù)端向客戶端發(fā)送,ACK和SYN就可以合并,即在服務(wù)端給客戶端發(fā)送數(shù)據(jù)的TCP報頭的標(biāo)志位中的"ACK"和 "SYN"的bit為1即可,實現(xiàn)合并操作就可以減少消耗,提高性能.

?這里解釋一下雙方為什么要向?qū)Ψ桨l(fā)送SYN:

首先我們要知道建立連接就是,通信雙方要互相保存對方的信息,也就是客戶端發(fā)送SYN給服務(wù)端,服務(wù)端收到SYN就保存了客服端的信息,并且給服務(wù)端發(fā)送ACK和?SYN,客服端接收到了ACK,就表明客服端的發(fā)送數(shù)據(jù)的能力沒問題,服務(wù)端的接收能力沒問題,并且客戶端接收到了服務(wù)端的SYN后,也就保存了服務(wù)端的信息,就返回ACK,服務(wù)端接收到ACK后就說明服務(wù)端的發(fā)送數(shù)據(jù)的能力沒問題,客戶端接收數(shù)據(jù)的能力沒問題,這樣通信雙方都保存了對方的信息,并且雙方的接收能力和發(fā)送的能力沒問題,就說明連接成功了.

1.三次握手的意義是什么,解決了啥問題

1.三次握手就是在正式傳輸數(shù)據(jù)之前,確認(rèn)通信線路是否通暢,確?？梢越⒁粋€穩(wěn)定的連接,相當(dāng)于TCP可靠性傳輸?shù)囊粋€輔助機制,注意:如果如果在面試中被問到TCP如何保證可靠性傳輸,不可以回答三次握手,而是回答,確認(rèn)應(yīng)答和超時重傳即可.

2.通過三次握手來確認(rèn)通信雙方,發(fā)送能力和接收能力都是正常的,這一點就不過多的解釋了.

3.三次握手的過程中還需要協(xié)商一些必要的參數(shù),這里重點介紹一下,TCP通信時使用的序號就是在三次握手的過程中出來的,也就是說序號一般并不是從 0 /1 開始的,而是在通信雙方協(xié)商出來的,至于時如何協(xié)商的,協(xié)商出來的序號到底都是啥,比較復(fù)雜,再加上也不是重點,博主就不過多的解釋了,這里的重點是要明白,每一次建立連接協(xié)商的序號的差異往往非常大的,至于`為什么要這樣設(shè)計,這里重點解釋一下:

就是在通信的過程中,通信雙方先建立連接,進(jìn)行數(shù)據(jù)交互,之后斷開連接,過了一會,又建立了連接,進(jìn)行數(shù)據(jù)交互,假如在這個過程中,某個數(shù)據(jù)報在網(wǎng)絡(luò)傳輸?shù)倪^程中花費的時間比較長? -> 等它傳輸?shù)椒?wù)端的時候,這個服務(wù)端已經(jīng)是斷開連接后,又重新建立一個新的連接了 - > 這個時候服務(wù)端接收到這個數(shù)據(jù)是該丟棄還是按照正常的邏輯執(zhí)行呢 - > 自然是應(yīng)該丟棄,因為客戶端和服務(wù)端斷開連接后,又重新建立連接,重新建立連接的服務(wù)端不一定是之前的服務(wù)進(jìn)程了,即執(zhí)行的業(yè)務(wù)就不相同了,自然就得丟棄.? - > 如何判斷這個數(shù)據(jù)報是之前的連接的數(shù)據(jù)報呢,自然是通過序號咯,如果是同一個連那么序號的差別就不大,不是一個連接序號的差別就非常大,這個時候就可以區(qū)分出來該數(shù)據(jù)報是否為前一個連接的數(shù)據(jù)報,這也就是為什么每一次連接協(xié)商的數(shù)據(jù)報的序號的起始差別要非常大的原因了.

通過序列號的機制，TCP協(xié)議可以防止舊的數(shù)據(jù)包干擾到新的連接，確保數(shù)據(jù)傳輸?shù)臏?zhǔn)確性和可靠性。這確保了即使在網(wǎng)絡(luò)條件不穩(wěn)定、連接頻繁斷開和重新建立的情況下，數(shù)據(jù)傳輸也能夠保持有序和正確。

2.TCP為啥要三次握手,兩次可以嗎,四次可以嗎

兩次不可以:服務(wù)端無法確保它的發(fā)送數(shù)據(jù)的能力和客戶端的接收能力,無法確保雙向通信的可靠性四次可以但不建議:如果把"ACK" 和 "SYN"改成分兩次發(fā)送是可以實現(xiàn),但是這樣并不會提高傳輸數(shù)據(jù)的準(zhǔn)確性,反而降低了性能,例如:網(wǎng)絡(luò)交互增加,消耗的網(wǎng)絡(luò)資源增加,還增加了丟包的可能性等等減低性能的缺點.

3.TCP三次握手的狀態(tài)和Socket api

Socket api 就不過多的解釋了,主要介紹一下三次握手過程中客戶端和服務(wù)端的狀態(tài),?

listen: 只有服務(wù)端才會存在的狀態(tài),也就是在服務(wù)端綁定端口成功后,就會進(jìn)入 Listen 狀態(tài),即為 監(jiān)聽狀態(tài),表示隨時都會有客戶端連接上來.

Established: 表明連接建立完成.

至于其他的狀態(tài)就不是很重要了.

2.四次揮手

斷開連接即通信的雙方把對方的信息給刪除掉,即四次揮手.同時注意三次握手,一定是客戶端發(fā)起第一次的,而四次揮手,通信雙方都可以都可以主動發(fā)起,這里就以客戶端主動發(fā)起為例:

在四次揮手過程中傳輸?shù)臄?shù)據(jù)也是一樣不攜帶任何業(yè)務(wù)數(shù)據(jù),即TCP數(shù)據(jù)報的載荷為空,只有TCP報頭,其中的FIN結(jié)束報文,就是6位標(biāo)志位的FIN位的bit位為1.

1. 四次揮手是否可以像三次握手一樣,合并成三次揮手呢?

答案是如能--- 在特殊情況下可以,一般情況下不能 為什么呢?

三次握手的ACK和 SYN的發(fā)送都是由系統(tǒng)內(nèi)核控制的自動發(fā)送,也就是說他們的發(fā)送的時間是一至,所以就可以合并成一次`發(fā)送 ACK + SYN.

而四次揮手的ACK是由系統(tǒng)內(nèi)核控制的,但是服務(wù)端的FIN(結(jié)束報文)卻是由應(yīng)用程序代碼控制的,也就是說只有當(dāng)代碼調(diào)用 close 的時候才會發(fā)送FIN(結(jié)束報文),通常在應(yīng)用程序完成數(shù)據(jù)傳輸并調(diào)用close()函數(shù)時觸發(fā),

所以這兩個數(shù)據(jù)報的觸發(fā)時間是不一樣的,所以難以合并,至于什么時候可以合并,

那就是當(dāng),TCP觸發(fā)延時應(yīng)答機制的時候(要回復(fù)ACK,但是不是立即發(fā)送,而是稍等一會)這個情況就可以合并.

快速關(guān)閉：如果客戶端和服務(wù)器幾乎同時決定關(guān)閉連接，并且他們的FIN包在網(wǎng)絡(luò)中相遇，那么接收方可以在回復(fù)對方的FIN時同時發(fā)送ACK和自己的FIN，這樣就減少了一次握手。

但畢竟是上述都是特殊情況,所以我們一般認(rèn)為它就是進(jìn)行四次揮手.

2.TCP四次揮手的狀態(tài)(重要)

1.Close_Wait?

就是被動的一方進(jìn)入的狀態(tài),等待代碼調(diào)用 close()方法,代碼調(diào)用close()越及時,就越不可能看到,假如我們在服務(wù)器中看到大量的 Close_Wait 狀態(tài)的時候 => 代碼可能忘調(diào)用close, 或者是 close 調(diào)用的不夠及時.

2.Time_Wait

Time_Wait狀態(tài)是TCP連接終止過程中的一個正常階段，它發(fā)生在主動關(guān)閉連接的一方（通常是客戶端）在發(fā)送完FIN包并接收到對方的FIN包后，進(jìn)入的一個等待狀態(tài),它主要是為了應(yīng)對最后一個ACK丟包的情況.同時需要注意?Close_Wait 并不是一定為服務(wù)端的狀態(tài),而是被動一方的狀態(tài),Time_Wait也不一定是客戶端的狀態(tài),而是主動一方的狀態(tài)

也就是當(dāng)客戶端在收到服務(wù)端返回的FIN以及發(fā)送ACK的時候并不會立即釋放連接,就是為了服務(wù)端沒有收到客戶端的ACK(丟包)的情況,觸發(fā)重傳FIN,要是釋放了連接后,客戶端就無法返回ACK了,當(dāng)然Time_Wait的持續(xù)時間是有限的,也就是說,客戶端在等待一般是 2 msL 之后這個時間足夠長，以確保所有可能的重傳數(shù)據(jù)包都被處理完畢。就不在等待而是釋放連接了,默認(rèn)服務(wù)端接收到了ACK了.當(dāng)然也是有可能發(fā)送ACK又丟包的情況的,但是只要超過了限定的時間客戶端直接就斷開連接.

1.如果服務(wù)端出現(xiàn)大量的Time_Wait時該如何處理

服務(wù)端出現(xiàn)大量的Time_Wait就說明服務(wù)端在大量的主動斷開TCP連接,這顯然是不科學(xué)的,

代碼審查：檢查應(yīng)用程序代碼，特別是與網(wǎng)絡(luò)通信相關(guān)的部分。

短連接模式：如果應(yīng)用程序頻繁地創(chuàng)建和關(guān)閉連接，而不是重用連接，這將導(dǎo)致大量的TIME_WAIT。

網(wǎng)絡(luò)問題：網(wǎng)絡(luò)波動或不穩(wěn)定可能導(dǎo)致連接意外中斷，從而產(chǎn)生大量的TIME_WAIT。

?3.TCP狀態(tài)轉(zhuǎn)換的詳細(xì)圖片

注意掌握博主之前提及的 四種狀態(tài)即可,其余的狀態(tài)遇到了,看一下這個圖即可.

4.滑動窗口

TCP除了保證可靠性傳輸之外,也希望能夠盡可能高效的完成數(shù)據(jù)傳輸,其中滑動窗口就是一種,TCP用來提高傳輸效率的機制.

不引入滑動窗口,數(shù)據(jù)傳輸?shù)倪^程

引入滑動窗口后,就把一條一條發(fā)送數(shù)據(jù) = > 批量發(fā)送數(shù)據(jù),批量發(fā)送就把等待時間重疊了,就可以提高性能.同時注意雖然是批量發(fā)送,但還是需要等待ACK否則無法保證可靠性.

窗口大小:不等待ACK,批量發(fā)送數(shù)據(jù)的多少,就是窗口大小,這個值不是固定的,它是通過其他的機制,確定的,這個下文博主會介紹到.

上圖就表示,窗口大小為4,批量發(fā)送1001 - 5001這四組數(shù)據(jù),同時等待這四組數(shù)據(jù)的ACK,此時如果收到?2001ACK,就說明1001 - 2000 這個數(shù)據(jù)就得到了確認(rèn),就標(biāo)記為灰色了,此時就需要繼續(xù)等待2001-5001的ACK,于此同時,發(fā)送新的數(shù)據(jù)5001- 6001,依舊是四組數(shù)據(jù).也就是說批量發(fā)送四組數(shù)據(jù)并不是要等到接收四組ACK后再繼續(xù)批量發(fā)送,而是收到一個ACK,就往后發(fā)一個新的數(shù)據(jù),這個窗口就滑動起來了.

同時注意如果 收到的是3001的ACK,就說明 < 3001 的數(shù)據(jù)已經(jīng)接收到了,窗口就會往后滑動兩個"格子".

1. 滑動窗口出現(xiàn)丟包的情況:

要保證可靠性

情況一:數(shù)據(jù)包抵達(dá)了,ACK出現(xiàn)了丟包

假如是 1001 這個ACK丟包了,這個時候并不需要做任何的處理,因為,即使1001 這個 ACK丟了,主機A在收到2001這個ACK的時候,就說明1-1000 , 1001 - 2000 的數(shù)據(jù)都收到了,就涵蓋了1001這個ACK起到的效果,所以只要數(shù)據(jù)包抵達(dá)了,ACK出現(xiàn)丟包的情況,并不需要做任何處理,也能保證可靠性.

情況二:數(shù)據(jù)包出現(xiàn)了丟包

?假如是1001 - 2000 這個數(shù)據(jù)包出現(xiàn)了丟包的情況,主機A依然會繼續(xù)向主機B往后發(fā)送數(shù)據(jù),主機B? ?此時向主機A發(fā)3次重復(fù)的1001 ACK向主機A索要1001 - 2000 的數(shù)據(jù)包,如果主機A收到了3個同樣的ACK的話,就會進(jìn)行重發(fā)操作,注意這里只重發(fā) 1001 - 2000 這個數(shù)據(jù)包,別的數(shù)據(jù)包并不會重發(fā),當(dāng)主機A收到了7001這個ACK后,就說明 1 - 6000 這些數(shù)據(jù)包都收到了,

上述這兩個丟包情況,就是通過快速重傳這個機制實現(xiàn)的,整個過程是十分高效的那么,快速重傳和 超時重傳是否存在沖突呢.

答案當(dāng)然是不會咯,快速重傳就相當(dāng)于超時重傳的在滑動窗口下的一個變種機制,本質(zhì)上是一樣的.并且在傳輸?shù)臄?shù)據(jù)不多的時候是不會觸發(fā)滑動窗口機制的.這個時候發(fā)送丟包就需要用到超時重傳了.

注意:哪怕滑動窗口在牛逼,TCP在效率方面還是UDP更牛一些.

5.流量控制

滑動窗口中最關(guān)鍵的就是窗口大小,其中窗口大小是可變的,可以通過控制窗口大小從而控制發(fā)送方的發(fā)送速度,即窗口越大,發(fā)送的數(shù)據(jù)也就越多,效率也就越高,但是如果窗口過大,接收方處理不過來,就會導(dǎo)致丟包的情況,從而影響到可靠性,所以呢,應(yīng)該要接收方要根據(jù)自己的處理能力,然后反制約于發(fā)送方,使雙方到達(dá)一個平衡.這就是流量控制.

給如何,衡量接收方的處理速度呢?

主要使根據(jù)接收方的接收緩沖區(qū)來衡量的

接收方的窗口大小就為未使用空間的大小.每次接收方接收到數(shù)據(jù)后,返回的ACK的報頭中,就包含了16位窗口大小,告知,接收方的數(shù)據(jù)處理能力,從而控制發(fā)送方的窗口大小

?注意16位窗口大小并不意外著,窗口最大為64kb而是更大,因為窗口大小并不僅僅和16位窗口大小有關(guān),還和選項的窗口擴展因子有關(guān),這里就不展開說明如何計算了,只需要記住窗口大小是可以非常大的.

發(fā)送方接收到這個ACK后就根據(jù)上述接收方指定的窗口大小來發(fā)送數(shù)據(jù).

?當(dāng)接收方的接收緩沖區(qū)滿了之后,接收方就會告訴發(fā)送方,停止發(fā)送數(shù)據(jù),等過了一段數(shù)據(jù)后,接收方消費了一些數(shù)據(jù)后,接收緩沖區(qū)又有空閑空間了,但是發(fā)送方停止發(fā)送數(shù)據(jù)了,接收方自然就無法發(fā)送ACK告訴發(fā)送方了.那么該如何解決呢?

這個時候一旦發(fā)送方過了重發(fā)超時的時間,還沒有接收到接收方的ACK,就會向接收方發(fā)送一個不帶載荷的窗口探測包,詢問窗口大小,只要沒收到ACK或者沒收到窗口大小更新的通知,就會定時的發(fā)送.這個還是非常之精妙的.

6.擁塞控制

和流量控制一樣,擁塞控制也是用來和滑動窗口搭配的機制,也就是說擁塞控制也是控制窗口大小的.

流量控制是根據(jù)接收方的接受能力來反向制約發(fā)送方從而控制窗口大小.

擁塞控制考慮的則是考慮到發(fā)送方和接收方中間網(wǎng)絡(luò)通信節(jié)點的像設(shè)備,路徑等等之類的因素,然后把它們看做一個整體,通過實驗的方式,來確定窗口大小

動態(tài)的找到一個速度快并且可靠性高的窗口大小.

注意:流量控制可以控制窗口大小\,擁塞控制也可以控制窗口大小,那么具體的窗口大小到底是根據(jù)那個機制呢 => 那個機制確定的窗口小,就根據(jù)那個機制

1.擁塞控制,擁塞窗口, 大小動態(tài)變化,具體是咋變的? 是否有規(guī)律??

1.慢開始:剛開始以,比較小的窗口 來傳輸數(shù)據(jù)
2.按照指數(shù)方式擴大窗口(*2)
注意這里的“慢”說的是剛開始 窗口大小比較小,傳輸速度慢而不是窗口大小的變化速度慢 (指數(shù)增長非?？斓?
3.指數(shù)增長過程中,達(dá)到某個閫值,就要變成線性增長.(+n)
線性增長,也是增長,發(fā)送速度越來越快增長到一定程度，就會出現(xiàn)丟包.當(dāng)發(fā)送端檢測到丟包時（超時或者3個重復(fù)ACK）就開始縮小窗口(快速重傳)

縮小有兩種方式:
1.直接縮到底.(回到了最初慢啟動的時候)接下來指數(shù)增長-線性增長
現(xiàn)在已經(jīng)廢棄了.(之前TCP的做法).
2.快速恢復(fù):縮到出現(xiàn)丟包時窗口大小 一半 這樣的位置接下來線性增長.(目前使用的方法).
?

注意這里只是大體介紹了一下過程,具體過程的算法及公式什么的還是比較復(fù)雜的,這里就不過多的解釋了,感興趣的可以去查一下資料.

7.延時應(yīng)答

ACK不會立即返回,而是延時一會再返回.TCP四次揮手在特殊情況下就是因為這個機制就可以變成三次揮手.(簡單提一下前面的知識).

為什么要延時應(yīng)答呢,自然是為了提升效率,而TCP提升效率主要就是增加窗口大小,延時應(yīng)答就是在保證可靠性的前提下,提高窗口大小.

舉個例子

假設(shè)當(dāng)前接收緩沖區(qū)的空閑空間為5kb,當(dāng)接收到發(fā)送方的2kb數(shù)據(jù)后,空閑空間就變成3kb,這個時候就要根據(jù)空閑空間來返回窗口大小.如果為我們是立即返回這個ACK的話,那么窗口大小就是3kb(不考慮窗口擴展因子),如果延時返回ACK,用于接收緩沖區(qū)里的數(shù)據(jù)是會被消費和讀取的啊,我空閑空間就會變大,也就是返回的窗口大小是大于 3kb的(具體多少不過多計算了)從而提高了效率.

注意:這里的延時時間主要是根據(jù)一定時間和接收的數(shù)據(jù)量結(jié)合來規(guī)定的,具體如何計算不多說.
?

?8.捎帶應(yīng)答

建立在延時應(yīng)答的基礎(chǔ)上的一個提升效率的機制.

在我們?nèi)粘ｉ_發(fā)中,客戶端和服務(wù)端通常是"一問一答"這樣的模型

因為延時應(yīng)答機制,ACK會延時一會,在返回,如果這個時候服務(wù)端剛好執(zhí)行完業(yè)務(wù)邏輯要發(fā)送響應(yīng)的時候,這個響應(yīng)數(shù)據(jù)就會把TCP報頭的ACK標(biāo)志位設(shè)為1,以及窗口大小等.就把這個ACK給合并了.這樣兩次傳輸,就變成一次傳輸,提高了效率.

9.粘包問題

TCP是一個面向字節(jié)流的協(xié)議，這意味著TCP不保證數(shù)據(jù)包的邊界。在TCP連接上發(fā)送的數(shù)據(jù)是按字節(jié)序列傳輸?shù)?#xff0c;而TCP本身并不為每個消息添加開始和結(jié)束的標(biāo)記。因此，如果應(yīng)用程序發(fā)送了多個數(shù)據(jù)包，它們可能在接收端被“粘”在一起，變成一個更大的數(shù)據(jù)包，這就是所謂的“粘包”問題。

粘包問題可能導(dǎo)致接收方無法正確地識別單個消息的邊界，從而無法正確地處理接收到的數(shù)據(jù)。以下是一些可能導(dǎo)致粘包問題的情況：

1. 發(fā)送多個小數(shù)據(jù)包：如果發(fā)送方連續(xù)發(fā)送多個小的數(shù)據(jù)包，它們可能在網(wǎng)絡(luò)中的某個點被合并為一個較大的數(shù)據(jù)包。

2. 接收緩沖區(qū)大小：如果接收方的接收緩沖區(qū)足夠大，它可以一次性接收多個數(shù)據(jù)包，導(dǎo)致這些數(shù)據(jù)包被粘在一起。

3. 網(wǎng)絡(luò)延遲：由于網(wǎng)絡(luò)延遲或擁塞，發(fā)送方發(fā)送的數(shù)據(jù)包可能在網(wǎng)絡(luò)中被延遲，導(dǎo)致它們到達(dá)接收方時被合并。

4. 應(yīng)用程序處理速度：如果接收方處理數(shù)據(jù)的速度比發(fā)送方慢，它可能來不及處理接收到的數(shù)據(jù)包，導(dǎo)致數(shù)據(jù)包在接收緩沖區(qū)中累積。

為了解決粘包問題，可以采取以下幾種策略：

1. 固定長度消息：發(fā)送固定長度的消息，接收方可以根據(jù)消息長度來確定消息邊界。

2. 消息邊界標(biāo)記：在每個消息的末尾添加特殊的分隔符或標(biāo)記，接收方可以通過查找這些標(biāo)記來識別消息邊界。

3. 消息長度字段：在每個消息的開頭添加一個表示消息長度的字段，接收方可以根據(jù)這個長度來確定消息邊界。

4. 使用應(yīng)用層協(xié)議：使用應(yīng)用層協(xié)議（如HTTP、FTP等）來定義消息結(jié)構(gòu)，這些協(xié)議通常有自己的消息邊界定義。

粘包問題不僅僅是在TCP中會出現(xiàn),它可能出現(xiàn)在任何需要處理數(shù)據(jù)流的場合.,這個還是比較關(guān)鍵的,我們可以根據(jù)TCP的解決方法來解決其他協(xié)議或者是其他別的應(yīng)用粘包問題

10.異常情況

?1.其中某一個進(jìn)程崩潰

進(jìn)程崩潰也好,正常結(jié)束也好,操作系統(tǒng),都能夠回收釋放對應(yīng)的 PCB,可以釋放里面的文件描述符表也就相當(dāng)于調(diào)用 close.此時仍然會正常和對方進(jìn)行四次揮手操作

2.某個主機被關(guān)機(正常關(guān)機)

對于這種正常流程的關(guān)機,操作系統(tǒng)會先嘗試強制結(jié)束所有的用戶進(jìn)程,然后再進(jìn)入關(guān)機流程這個過程也會和上面一樣,結(jié)束進(jìn)程之后,進(jìn)行四次揮手.

如果主動觸發(fā) FIN 了之后的流程沒走完,系統(tǒng)就已經(jīng)關(guān)機了:
A 和 B 建立 TCP 連接, A 這邊關(guān)機了A 關(guān)機之前給B發(fā)送FINB 這邊收到了 FIN, B 返回 ACK, 代碼進(jìn)入下一階段流程B準(zhǔn)備發(fā)送 FIN此時如果 A 已經(jīng)關(guān)機了,意味著 B 接下里的 FIN 就會反復(fù)重傳幾次A就算沒有反應(yīng),B也會把保存A的信息給刪除A關(guān)機了自然就把B給刪除,這樣就斷開連接了.

3.某個主機電源斷電(非正常關(guān)機)

A 和 B 通信,A 突然掉電了:
A 無法做出任何反應(yīng),就關(guān)機了!
B 還傻傻的以為 A 還存在呢,這個時候又分兩種情況:
1.B 是發(fā)送數(shù)據(jù)方.
B 接下來發(fā)送給A的數(shù)據(jù),都不會有 ack 了,這個時候B 就會觸發(fā)超時重傳,重傳幾次之后,發(fā)送復(fù)位報文 (RST).RST 也沒有響應(yīng),B 就會單方面刪除保存的 A 的信息
2.B 是接收方
接收方(被動一方),無法知道對方啥時候給我發(fā)數(shù)據(jù)當(dāng) A 沒有發(fā)送數(shù)據(jù)之后, B 也不知道 A 是暫時暫停一會,還是 A掛了B 在一定時間之內(nèi)沒收到 A 的數(shù)據(jù)之后, 就會觸發(fā) 心跳包,
心跳包,就可以認(rèn)為是一個 沒有載荷 的數(shù)據(jù)包只是為了觸發(fā) ack
B 給 A 發(fā)了一個心跳包, 如果 A 正常, A 就會回應(yīng) ACK如果 A 掛了,B 不會收到任何回應(yīng).連續(xù)發(fā)了若干次,A 都沒有回應(yīng), 這個時候 B 就認(rèn)為 A 掛了,于是單方面釋放連接.

注意:
tcp 雖然內(nèi)置了心跳包,但是這個心跳包,周期比較長,依賴通過這個心跳發(fā)現(xiàn)對端掛了,往往需要 分鐘級別 這樣的時間在實際開發(fā)中,經(jīng)常會實現(xiàn)應(yīng)用層的心跳包,用更高頻率,更短周期發(fā)送心跳.(ping-pong)
A->B發(fā)-個 ping??B ->A 回復(fù)一個 pong 秒級/毫秒級~,一旦某個設(shè)備掛了,就可以更快速的發(fā)現(xiàn)問題

4.網(wǎng)線斷開

本質(zhì)上就是第三種情況A 和 B 之間建立 TCP 連接,A 和 B 之間的網(wǎng)線斷開了
比如,A 是發(fā)送方,B 是接收方,A 的角度,就會觸發(fā)超時重傳, 觸發(fā) RST, 單方面刪除信息,B 的角度,就會觸發(fā) 心跳包, 對方無響應(yīng),單方面刪除信息!

4.如何使用UDP實現(xiàn)可靠性傳輸(面試題)

這一題看似考的是UDP其實是考TCP如何保證可靠性傳輸,所以要使用UDP實現(xiàn)可靠性就要在應(yīng)用層中引入確認(rèn)應(yīng)答,超時重傳等機制.具體內(nèi)容就根據(jù)上述TCP機制來回答就可.

以上就算關(guān)于TCP的一些重點內(nèi)容,要想了解更詳細(xì)的內(nèi)容,博主推薦觀看<TCP/IP協(xié)議>這本書,感謝你的閱讀,祝你一天愉快.