哈嘍，大家好~我是你們的老朋友：保護(hù)小周???
本期為大家?guī)?lái)的是網(wǎng)絡(luò)編程的 TCP 傳輸控制協(xié)議的概念 ，首先會(huì)講解 TCP 協(xié)議的報(bào)文格式，在學(xué)習(xí)報(bào)文格式之后，會(huì)學(xué)習(xí)兩種 TCP 保證數(shù)據(jù)可靠傳輸?shù)臋C(jī)制，確認(rèn)應(yīng)答，超時(shí)重傳，這也是TCP 中較為核心的機(jī)制，以及接收緩沖區(qū)可以將數(shù)據(jù)排序，去重的功能。
本期收錄于博主的專欄：JavaEE_保護(hù)小周?的博客-CSDN博客
適用于編程初學(xué)者，感興趣的朋友們可以訂閱，查看其它 “JavaEE基礎(chǔ)知識(shí)”。
更多精彩敬請(qǐng)期待：保護(hù)小周? *★,°*:.☆(￣▽￣)/$:*.°★* ‘
?一、網(wǎng)絡(luò)編程簡(jiǎn)介
真實(shí)的網(wǎng)絡(luò)通信是基于 TCP / IP 五層網(wǎng)絡(luò)模型實(shí)現(xiàn)，協(xié)議分層，自上而下，應(yīng)用層-> 傳輸層-> 網(wǎng)絡(luò)層-> 數(shù)據(jù)鏈路層->物理層，協(xié)議分層管理，規(guī)定下層協(xié)議為上層協(xié)議提供服務(wù)（接口 - API），上層協(xié)議可以直接調(diào)用下層協(xié)議，但是不允許跨層調(diào)用。除應(yīng)用層以外，其余幾層都被操作系統(tǒng)封裝好了，并且提供一個(gè)傳輸層的接口（API）—— Socket， 那么應(yīng)用層基于 Socket 開(kāi)發(fā)，也就是我們常說(shuō)的網(wǎng)絡(luò)編程。
Socket ——套接字，主要提供兩組傳輸層的協(xié)議接口。
1. 基于 UDP 傳輸協(xié)議的Socket 接口開(kāi)發(fā)
2. 基于 TCP 傳輸協(xié)議的Socket 接口開(kāi)發(fā)?
簡(jiǎn)單講述一下各個(gè)層級(jí)的協(xié)議主要的功能：
應(yīng)用層：主要就是開(kāi)發(fā)的程序需要具備一個(gè)聯(lián)網(wǎng)，進(jìn)行網(wǎng)絡(luò)交互的功能和模式，這個(gè)一點(diǎn)是程序猿根據(jù)業(yè)務(wù)的實(shí)際需求設(shè)計(jì)開(kāi)發(fā)的（選擇使用那種傳輸層協(xié)議）。
傳輸層：主要負(fù)責(zé)數(shù)據(jù)在傳輸過(guò)程中的真實(shí)性，有效性等，例如：檢測(cè)到數(shù)據(jù)沒(méi)有傳輸成功那就再發(fā)一份，保證數(shù)據(jù)從源頭到達(dá)目的，傳輸層給應(yīng)用層提供服務(wù)。
網(wǎng)絡(luò)層：主要負(fù)責(zé)數(shù)據(jù)的傳輸，利用IP 地址在網(wǎng)絡(luò)中找到目的主機(jī)的位置，路由轉(zhuǎn)發(fā)，提供一條可靠的傳輸路徑。
數(shù)據(jù)鏈路層：主要給兩個(gè)相鄰的節(jié)點(diǎn)之間交互數(shù)據(jù)，例如將網(wǎng)卡中的數(shù)據(jù)交給物理層轉(zhuǎn)化識(shí)別。
物理層：硬件設(shè)備，將二進(jìn)制數(shù)據(jù)以各種形式傳播，高低電平電信號(hào)——網(wǎng)線，光纖的光信號(hào)，以及廣播等等。
二、TCP 傳輸協(xié)議簡(jiǎn)介
TCP（Transmission Control Protocol）是一種面向連接、可靠的傳輸協(xié)議，它在互聯(lián)網(wǎng)協(xié)議模型中屬于傳輸層，也是在日常開(kāi)發(fā)中最廣泛使用的協(xié)議，TCP 協(xié)議可以保證可靠的數(shù)據(jù)傳輸。
本篇博客將圍繞著 TCP 協(xié)議如何保證可靠的數(shù)據(jù)傳輸來(lái)展開(kāi)。
TCP 協(xié)議的特點(diǎn)：
- 面向有連接 ：傳輸數(shù)據(jù)之前，通信雙方先建立可靠連接
- 可靠傳輸 ：?TCP 協(xié)議有超時(shí)重傳的機(jī)制和確認(rèn)應(yīng)答機(jī)制等一系列的措施，當(dāng)發(fā)現(xiàn)連接沒(méi)有問(wèn)題，但數(shù)據(jù)沒(méi)有成功傳輸?shù)臅r(shí)候會(huì)重新發(fā)送數(shù)據(jù)。
- 面向字節(jié)流：字面意思，使用字節(jié)流傳輸。
- 緩沖區(qū)：在進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)通信時(shí)，用于存儲(chǔ)待發(fā)送或已接收數(shù)據(jù)的緩沖區(qū)，有了緩沖區(qū)的概念，可以幫助協(xié)調(diào)發(fā)送方和接收方之間的數(shù)據(jù)傳輸速度，并最大限度地減少數(shù)據(jù)丟失或混亂的風(fēng)險(xiǎn)……
- 傳輸數(shù)據(jù)的大小不受限制：字節(jié)流，流式傳輸，前提是有連接。
- 全雙工通信：通信雙方都可以同時(shí)進(jìn)行信息交互，例如：電話通信
?2. 1 TCP 協(xié)議報(bào)文格式
我們學(xué)習(xí)一種協(xié)議最好是從該協(xié)議的數(shù)據(jù)報(bào)開(kāi)始分析。
TCP 報(bào)文的結(jié)構(gòu)圖：
仔細(xì)觀察 TCP 數(shù)據(jù)報(bào)文結(jié)構(gòu)圖，我們會(huì)發(fā)現(xiàn)整個(gè)TCP 固定首部占20個(gè)字節(jié)，160 二進(jìn)制位，但是根據(jù)我們畫(huà)的結(jié)構(gòu)圖，所有的的節(jié)點(diǎn)相加只有 158 個(gè)二進(jìn)制。
在數(shù)據(jù)偏移的這一行，4 + 4 + 6 + 16 = 30位， 其實(shí)有兩個(gè)二進(jìn)制位是被 “浪費(fèi)掉了”。
TCP 報(bào)文解析：
源端口和目的端口：兩個(gè)端口各占 16個(gè)二進(jìn)制位?端口可以認(rèn)為是應(yīng)用程序的身份標(biāo)識(shí)，每一個(gè)入網(wǎng)的程序在啟動(dòng)的時(shí)就會(huì)隨機(jī)的綁定一個(gè)端口號(hào), 也可以手動(dòng)給程序指定一個(gè)端口號(hào)，但是注意在同一主機(jī)中端口號(hào)不可重復(fù)，另一點(diǎn)，就是小于等于 1024 的端口號(hào)，被稱為“知名端口號(hào)”，提供給一些名氣比較大的服務(wù)器使用，例如：http 80。 使用端口號(hào)用于確認(rèn)信息的發(fā)送方是那個(gè)應(yīng)用程序，信息的接收方是那個(gè)應(yīng)用程序。
序號(hào)和確認(rèn)號(hào)：各占 32個(gè)二進(jìn)制位?用于實(shí)現(xiàn)數(shù)據(jù)的可靠傳輸，所傳送的字節(jié)流的每一個(gè)字節(jié)都會(huì)按順序編號(hào)，保證數(shù)據(jù)傳輸?shù)捻樞蚝徒邮盏捻樞蛞粯?。序?hào)表示當(dāng)前發(fā)送的數(shù)據(jù)包的序號(hào)，確認(rèn)號(hào)表示期望接收的下一個(gè)數(shù)據(jù)包的序號(hào)。
發(fā)送方： 1. 哥們?cè)绨玻?2. 周末有沒(méi)有興趣出去玩啊。
接收方：?2. 周末有沒(méi)有興趣出去玩啊 ，1. 哥們?cè)绨病?/strong>
這種情況很明顯是不可靠的的，序列號(hào)和確認(rèn)號(hào)存在的意義就在于保證數(shù)據(jù)傳輸?shù)捻樞蚝徒邮盏捻樞蛞粯印? ? ? ? ? ? ? ?
數(shù)據(jù)偏移量：占4 個(gè)二進(jìn)制位?確定 TCP 報(bào)文頭部的長(zhǎng)度，告訴接收端的應(yīng)用程序，除去TCP 頭部報(bào)文，身后數(shù)據(jù)部分從何處開(kāi)始。
標(biāo)志位：包括ACK、SYN、FIN、RST、PSH、URG六種各占一個(gè)二進(jìn)制位。
如果為標(biāo)志位置為 1表示 true 的意思。
ACK用于確認(rèn)收到數(shù)據(jù)包；
SYN判斷通信雙方是否建立了連接；
FIN用于關(guān)閉連接；
RST用于重置連接；
PSH用于提示接收方立即將數(shù)據(jù)推送給應(yīng)用程序，而不是進(jìn)入接收緩沖區(qū)；
URG用于指示TCP包中有緊急數(shù)據(jù)。
窗口大小：用于流量控制，的校驗(yàn)和值是否正確，判斷數(shù)據(jù)在傳輸?shù)倪^(guò)程中是否受到影響（例如：電磁信號(hào)干擾表示發(fā)送方能夠發(fā)送的未經(jīng)確認(rèn)數(shù)據(jù)的最大字節(jié)數(shù)，該字段可以用于 TCP 的流量控制，下文滑動(dòng)窗口詳細(xì)講述。
TCP校驗(yàn)和：用于檢測(cè)TCP頭和數(shù)據(jù)造成數(shù)據(jù)的偏差。保證數(shù)據(jù)的正確性。
緊急指針：僅在URG標(biāo)志被設(shè)置為 1 時(shí)才使用，用于指示緊急數(shù)據(jù)的末尾位置。
保留：TCP報(bào)文頭中的保留字段主要用于保留未來(lái)使用、兼容舊版本和防止出現(xiàn)錯(cuò)誤，并為T(mén)CP協(xié)議提供了可擴(kuò)展性和靈活性。
三、TCP 保證數(shù)據(jù)可靠傳輸?shù)臋C(jī)制?
3.1 確認(rèn)應(yīng)答
確認(rèn)應(yīng)答：TCP 協(xié)議中，每次發(fā)送數(shù)據(jù)，接收方都會(huì)發(fā)送一個(gè)確認(rèn)應(yīng)答，告訴發(fā)送方數(shù)據(jù)已接收到了，如果發(fā)送方“遲遲”沒(méi)有收到確認(rèn)應(yīng)答，就會(huì)認(rèn)為數(shù)據(jù)沒(méi)有發(fā)送成功，就會(huì)將數(shù)據(jù)重新傳輸。
這也是 TCP 協(xié)議實(shí)現(xiàn)可靠傳輸最核心的機(jī)制。
ACK（acknowledge）標(biāo)志位用于確認(rèn)收到數(shù)據(jù)包，會(huì)給予通信雙方一個(gè) ACK 反饋，利用這個(gè)反饋我們就發(fā)送端就可以判斷接收端已經(jīng)成功接收到信息了。同時(shí)這也意味著傳輸“效率”會(huì)有所降低，辛苦傳輸過(guò)去，還得等待對(duì)方反饋回來(lái)，如果遲遲沒(méi)有反饋就會(huì)嘗試重新發(fā)送一份~
TCP的確認(rèn)應(yīng)答（ACK）是指接收方在成功接收到發(fā)起方發(fā)送過(guò)來(lái)的TCP數(shù)據(jù)包后，向發(fā)起方發(fā)送帶有確認(rèn)標(biāo)志位的TCP報(bào)文段作為響應(yīng)的一種機(jī)制。
在網(wǎng)絡(luò)通信中也常常遇到信息“后發(fā)先至”?的情況，前兩年qq 聊天就存在這個(gè)情況，我也遇到過(guò)這種情況，什么意思呢，當(dāng)我給我的朋友發(fā)送一大堆消息，理論上來(lái)說(shuō)，對(duì)方接受到的消息順序應(yīng)該與我發(fā)送消息的順序一致，其實(shí)不然，消息有時(shí)候沒(méi)按照我們預(yù)想的順序來(lái)，這樣就容易引起一些誤會(huì)，舉個(gè)例子：
?網(wǎng)絡(luò)通信中消息后發(fā)先至的原因可以有多種可能性，以下是幾種可能性：
網(wǎng)絡(luò)擁塞：當(dāng)網(wǎng)絡(luò)中的數(shù)據(jù)量過(guò)大時(shí)，會(huì)導(dǎo)致網(wǎng)絡(luò)擁堵，從而導(dǎo)致一些消息被延遲發(fā)送或丟失，而其他消息在其之前被傳輸完畢并被接收方處理。這種情況下，即使先發(fā)送的消息比后發(fā)送的消息早，但后發(fā)送的消息可能會(huì)在先發(fā)送的消息之前到達(dá)接收方。
傳輸錯(cuò)誤：網(wǎng)絡(luò)傳輸過(guò)程中可能會(huì)出現(xiàn)傳輸錯(cuò)誤，例如數(shù)據(jù)包損壞、丟失等等原因。如果一個(gè)數(shù)據(jù)包出現(xiàn)了錯(cuò)誤，通過(guò)應(yīng)答報(bào)文的反饋，發(fā)送方就需要將它重新發(fā)送，這可能會(huì)導(dǎo)致某些后發(fā)送的消息比先發(fā)送的消息更快地到達(dá)接收方。
排隊(duì)延遲：當(dāng)多個(gè)消息同時(shí)到達(dá)接收方時(shí)，接收方可能會(huì)將它們放入隊(duì)列中進(jìn)行處理。如果先發(fā)送的消息排在了后發(fā)送的消息前面，但由于其他因素（例如消息大小、處理時(shí)間等）導(dǎo)致后發(fā)送的消息比先發(fā)送的消息更快地被處理，那么后發(fā)送的消息就會(huì)先于先發(fā)送的消息到達(dá)接收方。
為了解決“信息后發(fā)先至”?的情況，可以對(duì)消息進(jìn)行編號(hào)，給發(fā)送的消息分配一個(gè)"序號(hào)" ，同時(shí)應(yīng)答報(bào)文給出“確認(rèn)序號(hào)”。
TCP 協(xié)議數(shù)據(jù)傳輸就是引入了序號(hào)和確認(rèn)序號(hào)。
TCP 協(xié)議會(huì)將每個(gè)字節(jié)的數(shù)據(jù)從前往后都進(jìn)行編號(hào)，稱之為“序列號(hào)”，因?yàn)門(mén)CP 是面向字節(jié)流傳輸?shù)模淮嬖谝粭l消息，兩條消息的說(shuō)法。
?發(fā)送方的TCP 報(bào)文確認(rèn)序號(hào)并沒(méi)有多大的意義：
確認(rèn)序號(hào)的規(guī)則：根據(jù)發(fā)送方發(fā)過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)序號(hào)的下一個(gè)字節(jié)的序號(hào)。
依據(jù)序號(hào) 1001 的含義：
1. 如果應(yīng)答報(bào)文的確認(rèn)序號(hào)，< 1001 ，接受方給發(fā)送方透露的信息就是我已經(jīng)收到
2. 接收方接下來(lái)想向發(fā)送方索要從 1001 開(kāi)始的字節(jié)流。
使用這種機(jī)制，我們就可以保證數(shù)據(jù)傳輸?shù)捻樞?，?shù)據(jù)到達(dá)接收方也不是立馬給到應(yīng)用程序處理，上文提到TCP 有一個(gè)緩沖區(qū)的概念，緩沖區(qū)就可以將數(shù)據(jù)按照 “序號(hào)” 排序，即使數(shù)據(jù)在傳輸?shù)倪^(guò)程中受到影響改變了數(shù)據(jù)傳輸?shù)捻樞颍€有緩沖區(qū)兜底呢~ 保證應(yīng)用程序讀取數(shù)據(jù)，讀到數(shù)據(jù)的順序一定是和發(fā)送的順序一樣的。
如果傳輸一切順利，接收方就會(huì)反饋確認(rèn)應(yīng)答（反饋一個(gè)“TCP 首部” ?其中ACK = 1）。
3.2 超時(shí)重傳
數(shù)據(jù)在傳輸?shù)倪^(guò)程中，難免會(huì)造成 “丟包” 問(wèn)題（數(shù)據(jù)缺失），好在TCP 協(xié)議有確認(rèn)應(yīng)答的機(jī)制，如果那一部分的數(shù)據(jù)遲遲沒(méi)有反饋應(yīng)答（ACK），發(fā)送方就視為剛才的那部分?jǐn)?shù)據(jù)丟包了，就會(huì)重新再發(fā)一遍，如果重發(fā)了好幾次都沒(méi)有得到接收方的應(yīng)答，就會(huì)考慮連接這方面的問(wèn)題，嘗試重新建立連接等，下文講述。
超時(shí)重傳：TCP協(xié)議中，如果發(fā)送方?jīng)]有收到確認(rèn)應(yīng)答，就會(huì)進(jìn)行超時(shí)重傳。發(fā)送方會(huì)設(shè)置一個(gè)超時(shí)時(shí)間，如果在這個(gè)時(shí)間內(nèi)沒(méi)有收到確認(rèn)應(yīng)答，就會(huì)重新發(fā)送數(shù)據(jù)。
發(fā)送方對(duì)于丟包的判定，是一定時(shí)間內(nèi)，沒(méi)有收到確認(rèn)應(yīng)答（帶有確認(rèn)標(biāo)志位（ACK）的TCP報(bào)文段）—— ACK =? 0
這個(gè)時(shí)候存在三種情況：
1. 數(shù)據(jù)直接在傳輸?shù)倪^(guò)程中丟失，接收方?jīng)]有收到數(shù)據(jù)，也就不會(huì)反饋 帶有確認(rèn)標(biāo)志位（ACK）的TCP報(bào)文段。2. 接受方收到數(shù)據(jù)后，反饋帶有確認(rèn)標(biāo)志位（ACK）的TCP報(bào)文段(TCP 首部信息包含 ACK)，然后這個(gè)報(bào)文段丟了。
3. 當(dāng)發(fā)送方一定時(shí)間沒(méi)有接收到反饋，就會(huì)觸發(fā)超時(shí)重傳，然后重傳的數(shù)據(jù)也丟了
第一種情況：
?第二種情況：
第三種情況：
連續(xù)丟失多個(gè)數(shù)據(jù)包 “接收方無(wú)反饋” 的情況，大概率就是網(wǎng)絡(luò)環(huán)境出現(xiàn)了非常嚴(yán)重的問(wèn)題，TCP協(xié)議針對(duì)這種連續(xù)發(fā)多個(gè)數(shù)據(jù)都再丟失的情況，處理的思路是繼續(xù)超時(shí)重傳，但是每丟一次數(shù)據(jù)包，超時(shí)等待的時(shí)間就會(huì)越長(zhǎng)（重傳的頻率降低了），如果連續(xù)多次傳輸超時(shí)重傳都無(wú)法獲取到接收方反饋的（ACK-TCP 首部信息包含 ACK），就嘗試給通信雙方重新建立連接，此時(shí)如果重新建立連接也是失敗，TCP 協(xié)議就會(huì)放棄本次網(wǎng)絡(luò)通信。
四、總結(jié)
TCP 傳輸控制協(xié)議，是互聯(lián)網(wǎng)通信中使用最為廣泛的協(xié)議，使用TCP 協(xié)議傳輸數(shù)據(jù)，數(shù)據(jù)安全可靠、真實(shí)性高，傳輸速度較快。
學(xué)習(xí)一個(gè)協(xié)議的核心先熟悉他的報(bào)文格式。
確認(rèn)應(yīng)答：
當(dāng)接收方收到發(fā)送方的數(shù)據(jù)時(shí)，會(huì)給予發(fā)送方一個(gè)帶有 TCP 首部的字段，其中ACK = 1， 表示我已經(jīng)收到數(shù)據(jù)。?
如果發(fā)送方一定時(shí)間內(nèi)沒(méi)有等到接收方反饋的確認(rèn)應(yīng)答，就會(huì)對(duì)該段“數(shù)據(jù)包” 進(jìn)行重傳，期間如果還是沒(méi)有接收到反饋，發(fā)送方就會(huì)降低重傳的頻率，超過(guò)一定的次數(shù)，TCP 就嘗試給通信雙發(fā)重新建立連接，如果連接失敗，就會(huì)終止本次的網(wǎng)絡(luò)通信。
TCP 為了解決數(shù)據(jù)發(fā)送的數(shù)據(jù)和接收的數(shù)據(jù)順序不一樣，所以給每一個(gè)字節(jié)進(jìn)行編碼，面向字節(jié)流傳輸嘛，序號(hào)字段描述了當(dāng)前"數(shù)據(jù)包"的序列號(hào)， 發(fā)送端的確認(rèn)序號(hào)沒(méi)有實(shí)際的意義，接收方反饋的確認(rèn)序號(hào)描述的期望下一個(gè)“數(shù)據(jù)包”的序號(hào)，如此發(fā)送方就知道下一次對(duì)方需要 “那一段” 數(shù)據(jù)，然后就是接收緩沖區(qū)的作用，傳輸?shù)臄?shù)據(jù)都有了編號(hào)，就可以利用“數(shù)據(jù)包”的序號(hào)對(duì)數(shù)據(jù)進(jìn)行排序，這樣數(shù)據(jù)的順序也就得到了保障。
遇到接收方數(shù)據(jù)接收成功，但反饋ACK 包丟失的情況，發(fā)送端超時(shí)重傳，接收緩沖區(qū)就會(huì)對(duì)數(shù)據(jù)進(jìn)行去重操作，保證應(yīng)用程序拿到的數(shù)據(jù)是獨(dú)一份的。
好了，到這里，網(wǎng)絡(luò)編程中的【TCP 協(xié)議】報(bào)文格式，數(shù)據(jù)可靠傳輸?shù)臋C(jī)制（一）博主已經(jīng)分享完了，今天主要是學(xué)習(xí) 的是 TCP的報(bào)文結(jié)構(gòu)，以及兩種保證數(shù)據(jù)可靠傳輸?shù)臋C(jī)制，這也是較為核心的機(jī)制，希望對(duì)大家有所幫助，如有不妥之處歡迎批評(píng)指正~
下期預(yù)告：【TCP 協(xié)議】連接管理之 “三次握手，四次揮手”
感謝每一個(gè)觀看本篇文章的朋友，更多精彩敬請(qǐng)期待：保護(hù)小周? *★,°*:.☆(￣▽￣)/$:*.°★*?文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-428038.html
遇見(jiàn)你，所有的星星都落在我的頭上……
文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-428038.html
到了這里，關(guān)于【TCP 協(xié)議】報(bào)文格式，數(shù)據(jù)可靠傳輸?shù)臋C(jī)制（一）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
