前言:
大家好,我是良辰丫,我們已經(jīng)學(xué)習(xí)了網(wǎng)絡(luò)原理基礎(chǔ)版,初步認(rèn)識(shí)了網(wǎng)絡(luò),還學(xué)習(xí)了網(wǎng)絡(luò)編程,了解了網(wǎng)絡(luò)通信的各種程序,接下來我們更深入的了解網(wǎng)絡(luò)是如何工作的.這篇文章我們主要介紹協(xié)議,UDP和TCP的一些原理.????

??個(gè)人主頁(yè)：良辰針不戳
??所屬專欄：javaEE初階
??勵(lì)志語(yǔ)句：生活也許會(huì)讓我們遍體鱗傷，但最終這些傷口會(huì)成為我們一輩子的財(cái)富。
??期待大家三連，關(guān)注，點(diǎn)贊，收藏。
??作者能力有限，可能也會(huì)出錯(cuò)，歡迎大家指正。
??愿與君為伴，共探Java汪洋大海。

1. 自定義協(xié)議(約定)

我們?cè)谇懊娴奈恼轮谐醪秸J(rèn)識(shí)了協(xié)議,現(xiàn)在我們來了解一下應(yīng)用層的自定義協(xié)議.

• 應(yīng)用層和數(shù)據(jù)直接相關(guān),決定了數(shù)據(jù)要傳輸什么,拿到數(shù)據(jù)后如何傳輸.
• 應(yīng)用層存在許多現(xiàn)有的協(xié)議(比如http),但是很多情況下還需要我們自定義協(xié)議.
• 約定應(yīng)用層數(shù)據(jù)報(bào),數(shù)據(jù)格式,就是在自定義協(xié)議.

簡(jiǎn)述一下社交軟件的數(shù)據(jù)報(bào)格式如下(并非真的,只是舉例讓大家理解)

那么如何約定(自定義協(xié)議)呢?我們慢慢往下看.

1.1 確定要傳輸哪些信息

自定義協(xié)議之前,我們需要根據(jù)需求,確定要傳輸哪些信息.
以購(gòu)物平臺(tái)為例.

傳輸?shù)男畔⒂?

• 用戶id.
• 用戶信息(保密處理)
• 商品信息.
• 商家信息.
• 類型
  評(píng)分等.內(nèi)容

上述傳輸?shù)男畔⒉皇枪潭ǖ?是根據(jù)產(chǎn)品經(jīng)理的需求做的.

1.2 確定數(shù)據(jù)以怎樣的格式組織(如何約定)(應(yīng)用層)

其實(shí)在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù),本質(zhì)上都是01的二進(jìn)制字符串,我們需要把傳輸?shù)男畔⒄铣梢粋€(gè)特殊的字符串.

• 屬性之間需要進(jìn)行分割,可以用任意符號(hào)作為分隔符,只要分割符不會(huì)影響正文內(nèi)容就行.
• 約定商家之間的信息用\n進(jìn)行分割.
• 約定每一個(gè)信息的結(jié)束標(biāo)志為分號(hào).

上述就是對(duì)信息做了一個(gè)約束,只要服務(wù)器與客戶端對(duì)約束的條件一一對(duì)應(yīng),接收方按照上述的約定就能很好的解析數(shù)據(jù).

1.3 常見的約定符號(hào)

在我們實(shí)際開發(fā)中,有許多特殊的格式,可以作為約定的符號(hào),我們可以直接拿來使用,非常方便.

1.3.1 xml格式

xml格式是一種非常流行的格式,但是最近用到比較少,這是一種通過標(biāo)簽的形式來組織數(shù)據(jù)的.

<request>
	<userId>100</userId>
	<usePos>100-100<userPos>
</request>

大家可能會(huì)有疑惑,這不是和web標(biāo)簽非常相似嘛,為什么不直接使用web標(biāo)簽?zāi)?

• web標(biāo)簽中每個(gè)標(biāo)簽都有固定的用法(大佬約定的).
• xml中的標(biāo)簽都是用戶自定義的,每個(gè)標(biāo)簽的名字都是自己取得.

1.3.2 json格式(目前常用)

使用大括號(hào)作為標(biāo)識(shí).

• 大括號(hào)里面是若干個(gè)鍵值對(duì).
• 每個(gè)鍵值對(duì)之間使用逗號(hào)分割.
• 鍵和值之間使用冒號(hào)分割.
• 鍵必須是字符串.
• 值可以是數(shù)字,字符串,數(shù)組,甚至是另一個(gè)json等.

數(shù)據(jù)組織方式有很多,比較常見的是xml和json,咱們也先簡(jiǎn)單了解一下這兩種.

2. 傳輸層的協(xié)議

2.1 UDP數(shù)據(jù)報(bào)

以UDP為例,來簡(jiǎn)單看一下UDP的報(bào)文格式,好多教材書的UDP報(bào)文格式如下,但是下圖并不是那么準(zhǔn)確.

下面為一個(gè)完整的應(yīng)用層報(bào)文.
前四個(gè)為UDP報(bào)頭.

• 每個(gè)端口號(hào)在UDP報(bào)文中,占兩個(gè)字節(jié),端口號(hào)的取值范圍為0-65535.
• 一個(gè)UDP報(bào)文的最大長(zhǎng)度就是64kb(根據(jù)65535得來的).

UDP報(bào)文的最大長(zhǎng)度那么小,為什么不擴(kuò)一下呢?

• UDP是在操作系統(tǒng)內(nèi)核中實(shí)現(xiàn),要想擴(kuò)容,必須升級(jí)系統(tǒng),全世界的主機(jī)都需要升級(jí),是非常麻煩的.
• 最大長(zhǎng)度小,需要傳輸一個(gè)較大的數(shù)據(jù),怎么辦呢?可以把一個(gè)數(shù)據(jù)拆分成多個(gè)部分,使用 UDP數(shù)據(jù)報(bào)來進(jìn)行數(shù)據(jù)傳輸,可行但是比較麻煩;我們還可以使用TCP,因?yàn)門CP沒有限制.

2.2 校驗(yàn)和

• 網(wǎng)絡(luò)傳輸不一定永遠(yuǎn)那么穩(wěn)定,可能會(huì)出現(xiàn)我們想象不到的錯(cuò)誤,通過電信號(hào)的形式進(jìn)行傳輸數(shù)據(jù),電信號(hào)使用高低電頻表示,如果出現(xiàn)一些情況情況的影響,傳輸數(shù)據(jù)可能就會(huì)出錯(cuò).
• 校驗(yàn)和就是為了檢測(cè)是否出錯(cuò)了.

老師讓去書店買四本書,這個(gè)四就可以看做一個(gè)校驗(yàn)和,買了三本是時(shí)候,我們可以回憶道缺一本,肯定錯(cuò)了.買了四本,此時(shí)也不一定買對(duì)了.那么我們可以得到以下結(jié)論.

• 如果校驗(yàn)和不對(duì).此時(shí)你的數(shù)據(jù)一定不對(duì).
• 如果你的校驗(yàn)和對(duì),你的數(shù)據(jù)也不定完全正確,也有一定的概率錯(cuò)誤.

校驗(yàn)和使用流程如下:

• 發(fā)送方把載荷數(shù)據(jù)代入到校驗(yàn)和算法中,計(jì)算生成校驗(yàn)和結(jié)果m.
• 發(fā)送方然后把這一串?dāng)?shù)據(jù)發(fā)送給接收方.
• 接收方收到的數(shù)據(jù),既有載荷,也有校驗(yàn)和m.
• 接收方就可以按照同樣的算法,再計(jì)算一次校驗(yàn)和,得出結(jié)果n.
• 然后接收方比較m與n是否相同.
• 如果不相同,數(shù)據(jù)一定有問題.
  咱們約定的是只比較校驗(yàn)和的結(jié)果,m和n不一樣的時(shí)候就認(rèn)為數(shù)據(jù)有問題,即使數(shù)據(jù)沒問題,我們也認(rèn)為有問題.
• 校驗(yàn)和的計(jì)算通常用循環(huán)冗余檢測(cè)法,在這里咱們簡(jiǎn)單了解一下即可.

2.2 TCP原理

在前面的文章中我們已經(jīng)簡(jiǎn)單的認(rèn)識(shí)了TCP的基本特性.

• 有連接.
• 可靠傳輸.
• 面向字節(jié)流.
• 全雙工.

以前已經(jīng)提到這些性質(zhì)了,我這里還是簡(jiǎn)單的列舉出來,因?yàn)槭侵攸c(diǎn),哈哈哈.
其中,TCP最重要的特性是可靠傳輸,這是TCP存在的初心,非常重要的機(jī)制.
接下來我們介紹一下TCP的幾個(gè)機(jī)制,保證可靠傳輸?shù)臋C(jī)制.

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

確認(rèn)應(yīng)答是實(shí)現(xiàn)可靠性最核心的機(jī)制.

A向B發(fā)一個(gè)消息,B向A做出回應(yīng),做出的回應(yīng)就是應(yīng)答報(bào)文(ACK),我們叫做ACK報(bào)文.

有時(shí)候網(wǎng)絡(luò)不穩(wěn)定會(huì)出現(xiàn)后發(fā)先至的情況,連發(fā)好幾條消息,不按照應(yīng)有的順序,尤其是當(dāng)接收方做回應(yīng)的時(shí)候出現(xiàn)錯(cuò)誤,就不能很好的知道哪幾條消息相匹配.

• 為了解決這個(gè)問題,我們給每條信息進(jìn)行編號(hào),于是,我們又引入了確認(rèn)序號(hào)的概念,每條應(yīng)答報(bào)文都有一個(gè)確認(rèn)信號(hào).
• TCP其實(shí)對(duì)每個(gè)字節(jié)都進(jìn)行編號(hào).

確認(rèn)序號(hào)的規(guī)則

• 確認(rèn)序號(hào)取的是發(fā)送方發(fā)送方發(fā)過來的所有數(shù)據(jù),最后一個(gè)字節(jié)的下一個(gè)序號(hào).
• 確認(rèn)序號(hào)的含義,在它之前的數(shù)據(jù)已經(jīng)收到,接下來向發(fā)送方索要從確認(rèn)序號(hào)開始的數(shù)據(jù).
• 這樣接收方就可以通過ack的確認(rèn)序號(hào),告訴發(fā)送方的哪些信號(hào)已經(jīng)收到了.

TCP如何處理后發(fā)先至的情況?

• TCP會(huì)有一個(gè)接收緩沖區(qū)(一塊內(nèi)核中的內(nèi)存空間),每個(gè)socket都有一份自己的緩沖區(qū).
• TCP可以按照序號(hào)針對(duì)收到的消息進(jìn)行整隊(duì)了(這也是TCP序號(hào)的一個(gè)及其重要的用途)

2.2.2 超時(shí)重傳

丟包是我們經(jīng)常遇到的問題.

• 一個(gè)轉(zhuǎn)發(fā)設(shè)備,承擔(dān)著許多轉(zhuǎn)發(fā)任務(wù),每個(gè)設(shè)備的轉(zhuǎn)發(fā)能力都是有限的.
• 當(dāng)流量達(dá)到上限的時(shí)候,就可能引起數(shù)據(jù)丟包.
• 刷視頻不敏感,因?yàn)橐曨l具有緩存功能;打游戲會(huì)有感覺,卡一下,就會(huì)影響游戲體驗(yàn).

• 如果包丟了接收方就收不到了,自然就不會(huì)返回ack.
• 發(fā)送方在一定時(shí)間內(nèi)拿不到應(yīng)答報(bào)文,就認(rèn)為剛剛發(fā)的數(shù)據(jù)丟包了.
• 這樣發(fā)送方就會(huì)重新發(fā)送,這就是超時(shí)重傳.
• 網(wǎng)絡(luò)丟包是概率性事件,上個(gè)包丟了,重傳往往會(huì)傳過去的,因?yàn)閬G包的概率很小.

發(fā)送方對(duì)于丟包的判定:

• 數(shù)據(jù)丟了,接收方?jīng)]有收到,自然不會(huì)發(fā)ack.
• 接收方收到數(shù)據(jù)了,但是ack丟了.

那么,發(fā)送方根本區(qū)分不了是上述哪種情況,因此只能重傳.
如果是ack丟了,數(shù)據(jù)沒有丟,那么重傳不會(huì)有重復(fù)的數(shù)據(jù)嘛?
TCP有一個(gè)接收緩沖區(qū),會(huì)根絕緩沖區(qū)的數(shù)據(jù)的序號(hào)自動(dòng)去重,這樣就保證了應(yīng)用程序讀到的數(shù)據(jù)只有一份.

重傳也會(huì)出現(xiàn)數(shù)據(jù)丟包,如果連續(xù)重傳數(shù)據(jù)仍然丟失,這說明你的網(wǎng)絡(luò)有一定的問題.TCP的宗旨是能重傳就重傳,重傳不了就關(guān)閉連接,盡最大可能完成傳輸.

• TCP針對(duì)多個(gè)包丟失,處理的辦法是繼續(xù)超時(shí)重傳.
• 但是如果丟包異常,超時(shí)等待時(shí)間就會(huì)變長(zhǎng)(重傳的頻率降低了).
• 連續(xù)多次重傳,都無法得到ack,此時(shí)TCP就會(huì)嘗試重置連接(嘗試重連)
• 如果重置連接也失敗,TCP就會(huì)關(guān)閉連接,放棄網(wǎng)絡(luò)通信了.

確認(rèn)應(yīng)答與超時(shí)重傳是TCP可靠性的基石.

• 順利發(fā)送消息,使用確認(rèn)應(yīng)答保證可靠性.
• 出現(xiàn)丟包,使用超時(shí)重傳作為補(bǔ)充,有效的提高了消息接收的概率.

2.2.3 連接管理

2.2.3.1 三次握手

TCP是如何實(shí)現(xiàn)可靠性的?

• 我們可以回答確認(rèn)應(yīng)答+超時(shí)重傳.
• 很多人往往回答三次握手與四次揮手,這往往是不準(zhǔn)確的.

握手指的是通信雙方進(jìn)行一次網(wǎng)絡(luò)交互,這就相當(dāng)于客戶端與服務(wù)器之間,通過三次交互,真正建立了連接(雙方各自記錄對(duì)方的信息)

• syn稱為同步報(bào)文段,意思就是一方向另一方申請(qǐng)建立連接(也就是驗(yàn)證自己能否把消息發(fā)送過去).
• 這時(shí)接收方向發(fā)送方發(fā)送syn/ack,這表示我同意與你建立連接.(發(fā)送確認(rèn)應(yīng)答表示發(fā)送方能發(fā)送過去消息,syn也是證明接收端能否發(fā)送消息.)
• 第三次,發(fā)送端發(fā)送ack表示接收端也沒問題.

雙方都確認(rèn)了自己沒問題,于是可以實(shí)現(xiàn)正常的網(wǎng)絡(luò)通信.
其實(shí)三次握手就是一個(gè)投石問路的過程,驗(yàn)證各自是否能正常與對(duì)方進(jìn)行通信.(發(fā)送能力與接收能力是否正常)

兩次握手可以嗎?四次握手呢?

• 三次握手是一個(gè)投石問路的過程,如果只有兩次握手.接收方始終不知道是否能正常把消息發(fā)送給發(fā)送方.
• 四次握手也可以,但是沒有必要,浪費(fèi)資源,第二次握手合并syn與sck,因?yàn)樗麄儍蓚€(gè)時(shí)機(jī)相同,可以一起發(fā)送.

• ACK為1時(shí)表示TCP數(shù)據(jù)報(bào)是一個(gè)應(yīng)答報(bào)文.
• syn為1時(shí)表示當(dāng)前數(shù)據(jù)報(bào)是一個(gè)同步報(bào)文.

2.2.3.2 四次揮手

揮手就是斷開連接的過程.各自給雙方發(fā)送一個(gè)結(jié)束報(bào)文.

• 建立連接一般都是由客戶端發(fā)起的.
• 但是斷開連接兩方都有可能.

四次握手不能合并成三次嘛?

• 三次握手中,ack與syn是同一個(gè)時(shí)機(jī)觸發(fā)的,都是由內(nèi)核來完成.
• 四次揮手中,ack與fin是不同時(shí)機(jī)觸發(fā)的.ack是內(nèi)核完成的,會(huì)在收到fin的時(shí)候第一時(shí)間返回,fin是應(yīng)用程序代碼控制的,在調(diào)用socket的close方法的時(shí)候才會(huì)觸發(fā)fin.

2.2.4 滑動(dòng)窗口

TCP不僅要保證可靠性,還要保證效率,但是往往二者不能得皆.

上述圖中A花費(fèi)了大量的時(shí)間等待B的ack,要想提高效率,就需要縮短等待時(shí)間,批量的發(fā)送數(shù)據(jù),一次發(fā)送多條數(shù)據(jù),一次等待多個(gè)ack.

• 每次收到一個(gè)ack就立即發(fā)送下一條,而不是收到多條才開始發(fā)送下一條.
• 使用一份時(shí)間,等待多份ack,這樣整體的效率就提升了.
• TCP再怎么提升效率,也沒有UDP快.

上述過程就是滑動(dòng)窗口.滑動(dòng)窗口其實(shí)就是批量傳輸.

• 批量不是無限發(fā)送,而是有一定的限制,發(fā)送到一定的程度,就等待ack,因?yàn)閿?shù)據(jù)量是有上限的.
• 回來一個(gè)ack就立即發(fā)送下一條,相當(dāng)于批量等待的數(shù)據(jù)是一致的.
• 批量等待數(shù)據(jù)的數(shù)量,就是窗口大小.
• 當(dāng)收到的ack非?？斓臅r(shí)候,此時(shí)狂口就會(huì)快速的往后移動(dòng).

批量發(fā)送的過程,會(huì)不會(huì)出現(xiàn)丟包呢?

當(dāng)然會(huì)出現(xiàn)丟包,但是咱們要保證可靠性第一,效率第二.

1. 數(shù)據(jù)正常到達(dá),ack丟了.

• 上述情況,相當(dāng)于大多數(shù)ack丟了,這是非常高的丟包率.
• 其實(shí)上面情況只是ack丟了,但是對(duì)可靠性并沒有影響.確認(rèn)序號(hào)表示該序號(hào)之前數(shù)據(jù)已經(jīng)收到了,后一個(gè)ack能夠包含前一個(gè)ack.
• 那么,前一個(gè)ack丟了,后面的ack只要收到了,并不影響.
• 如果最后一個(gè)ack丟了,就需要超時(shí)重傳了.

2. 數(shù)據(jù)丟了.

• 如果1001-2000這個(gè)數(shù)據(jù)丟了,接收方仍然會(huì)索要1001,不會(huì)因?yàn)槭盏搅?001-3000就返回3001.
• 接下來幾次的數(shù)據(jù)的ack,確認(rèn)序號(hào)都是1001.
• 接收方再向發(fā)送方反復(fù)索要1001這個(gè)數(shù)據(jù).
• 發(fā)送方會(huì)收到接收方的請(qǐng)求,然后重傳了1001-2000這個(gè)數(shù)據(jù).
• 當(dāng)發(fā)送方把1001-2000這個(gè)數(shù)據(jù)重傳,接收方收到數(shù)據(jù)后,返回的ack的確認(rèn)號(hào)不是2001,因?yàn)?001之后的一些數(shù)據(jù)已經(jīng)用過了,2001這個(gè)確認(rèn)序號(hào)已經(jīng)占用了.之后哪個(gè)確認(rèn)序號(hào)沒有用,它用哪個(gè).

• 上述重傳過程中,沒有任何冗余的操作,丟了數(shù)據(jù)才會(huì)重傳,不丟數(shù)據(jù)就不會(huì)重傳,因此整體的速度是比較快的,這個(gè)重傳過程也稱為快速重傳.
• 滑動(dòng)窗口與快速重傳,是在批量傳輸大量數(shù)據(jù)的時(shí)候,會(huì)采取的措施,如果你只傳輸了少量的數(shù)據(jù)(低頻的操作),就不會(huì)按照滑動(dòng)窗口那樣做了.它會(huì)按照確認(rèn)應(yīng)答與超時(shí)重傳的方式.

2.2.5 流量控制

滑動(dòng)窗口在批量發(fā)送的時(shí)候,窗口越大批量發(fā)送的數(shù)據(jù)越多,整體的速度就越快.但是呢?越快越好嘛?我們要把可靠傳輸放在第一位.

• 如果你發(fā)的太快了,瞬間會(huì)把接收方的緩沖區(qū)擠滿了,接下來如果繼續(xù)發(fā)送就會(huì)出現(xiàn)丟包問題,可靠性得不到保障,那快有什么用呢?
• 通過流量控制,本質(zhì)上就是讓接收方來限制一下發(fā)送的速度(或者阻塞等待).

那么具體怎樣來進(jìn)行流量控制呢?

在ack報(bào)文里面,有一個(gè)16位窗口大小這樣的字段.

• 當(dāng)ack為1的時(shí)候,ack報(bào)文的窗口大小就會(huì)生效,這里的16位狂口的值就是建議發(fā)送方發(fā)送的窗口大小.
• 接收方是如何計(jì)算窗口的大小的,它直接拿接收緩沖區(qū)的剩余空間作為窗口的大小.(接收緩沖區(qū)滿了,發(fā)送方就會(huì)暫停發(fā)送了)
• 當(dāng)發(fā)送方發(fā)現(xiàn)對(duì)方滿了之后,就會(huì)暫停發(fā)送,但是仍然會(huì)每隔一段時(shí)間觸發(fā)一個(gè)窗口探測(cè)報(bào)文,如果探測(cè)一會(huì)發(fā)現(xiàn)對(duì)方這里不是0了,這就有空間了,應(yīng)用程序從socket讀數(shù)據(jù)就會(huì)消費(fèi)接收緩沖區(qū)的內(nèi)容也就騰出空間了.
• 發(fā)送方的窗口 = 流量控制 + 擁塞控制.

2.2.6 擁塞控制

滑動(dòng)窗口的大小取決于流量控制和擁塞控制.

• 流量控制:衡量接收方的處理能力.
• 擁塞控制:衡量了傳輸路徑的處理能力.

• 傳輸路徑上,任何一個(gè)設(shè)備,處理能力如果遇到瓶頸的話,都會(huì)對(duì)整體的傳輸速率產(chǎn)生明顯影響.
• 而擁塞控制做的事情,就是衡量中間節(jié)點(diǎn)與傳輸?shù)哪芰?有時(shí)候,每次傳輸,走的路徑都不一樣.

動(dòng)態(tài)平衡:

• 通過實(shí)驗(yàn)的方式,找到一個(gè)合適的發(fā)送速率.
• 開始的時(shí)候按照一個(gè)小的速率發(fā)送.
• 如果不丟包,就可以提高一下速率(擴(kuò)大窗口的大小).
• 如果出現(xiàn)丟包,就立即把速率調(diào)小.
  (反反復(fù)復(fù)重復(fù)上述過程)

上述就是擁塞窗口圖,流量控制的窗口.

• 實(shí)際發(fā)送方的窗口大小 = min(擁塞窗口,流控窗口)
• 剛開始的時(shí)候,暫時(shí)不考慮流量控制的情況,剛開始傳,會(huì)給一個(gè)非常小的窗口(比較小的初始速度),也就是慢開始.
• 每次翻倍,指數(shù)增長(zhǎng)速度很快,可以讓窗口在短時(shí)間內(nèi)就達(dá)到一個(gè)比較大的值,快速接近當(dāng)前網(wǎng)絡(luò)傳輸路徑的能力瓶頸.
• 增長(zhǎng)到一定的程度的時(shí)候,出現(xiàn)丟包,就認(rèn)為當(dāng)前窗口的大小已經(jīng)達(dá)到了當(dāng)前路徑的傳輸上限.
• 指數(shù)增長(zhǎng)達(dá)到一定閾值就會(huì)變成線性增長(zhǎng),避免一下子突然超過上限很多,這樣可以使得傳輸速度,逐漸接近傳輸上限.
• 13輪的時(shí)候又立即把窗口大小回歸到一個(gè)比較小的初值,然后重復(fù)上述過程.

2.2.7 延時(shí)應(yīng)答

• TCP可靠性的核心是確認(rèn)應(yīng)答.
• ack要發(fā),但是有時(shí)候不是立即發(fā),而是一會(huì)再發(fā).
• TCP中決定傳輸速率的關(guān)鍵元素就是窗口大小.

• 其實(shí)延時(shí)應(yīng)答也可以理解為阻塞,流量達(dá)到上限的時(shí)候不能立即發(fā)送確認(rèn)報(bào)文,需要等待一段時(shí)間才能發(fā)送(流量恢復(fù),擁塞得到緩和).
• 延時(shí)應(yīng)答的效果,就是通過這個(gè)延時(shí),讓接收方的應(yīng)用程序,趁機(jī)多消費(fèi)一點(diǎn)數(shù)據(jù),此時(shí)反饋的窗口大小就會(huì)更大一些,此時(shí)發(fā)送方的發(fā)送速率也就能更快一些,這樣同時(shí)也能滿足讓接收方處理數(shù)據(jù).

2.2.8 捎帶應(yīng)答

• 捎帶應(yīng)答基于延時(shí)應(yīng)答.
• 客戶端服務(wù)器之間的通信模型,通常就是一問一答的模型.

客戶端服務(wù)器的通信模型:

• 一問一答,大多數(shù)服務(wù)器都這樣.
• 多問一答,上傳大文件.
• 一問一答,下載大文件.
• 多問多答,游戲串流.

四次揮手為什么可能會(huì)三次完成?
就是捎帶應(yīng)答,可能會(huì)把第二次和第三次聯(lián)合起來.因?yàn)楹铣梢粋€(gè),比分成兩個(gè)效率更高.

• 第二次揮手是在ack內(nèi)核負(fù)責(zé),立即返回.
• 第三次揮手是在應(yīng)用程序中,通過write寫的數(shù)據(jù),通一些代碼執(zhí)行到才返回.
• 這兩個(gè)實(shí)際本來是不相同的,但是通過延時(shí)應(yīng)答,此時(shí)ack就可能等一會(huì)再發(fā)送,然后等到第三次揮手,一起發(fā)送.

2.2.9 面向字節(jié)流

粘包問題:

• 一句話其實(shí)就相當(dāng)于一個(gè)應(yīng)用層數(shù)據(jù)報(bào).
• 當(dāng)A給B連續(xù)發(fā)送多個(gè)應(yīng)用層數(shù)據(jù)報(bào)后,這些數(shù)據(jù)報(bào)就累計(jì)到B的接收緩沖區(qū),這樣緊緊的挨在一起.此時(shí)B的應(yīng)用程序在讀數(shù)據(jù)的時(shí)候,就難以區(qū)分哪一個(gè)是完整的數(shù)據(jù)報(bào).這樣就很容易讀出半個(gè)包/一個(gè)半的包.
  數(shù)據(jù)到了接收緩沖區(qū)已經(jīng)是分用過的,把TCP報(bào)頭都拆掉了,只剩下應(yīng)用層數(shù)據(jù)報(bào)(TCP載荷了),應(yīng)用程序read的時(shí)候讀不出TCP序號(hào).

如何有效的解決粘包問題.

• 我們可以約定一個(gè)數(shù)據(jù)報(bào)以某個(gè)符號(hào)結(jié)尾,這樣就可以區(qū)分哪些是完整的一句話.
• 定長(zhǎng)的包,保證每次都按照固定的大小讀取.
• 變長(zhǎng)的包,可以在包頭的位置,約定一個(gè)包總長(zhǎng)度的字段,這樣就知道了包的結(jié)束位置.

2.2.10 異常情況

1. 進(jìn)程關(guān)閉/進(jìn)程崩潰

進(jìn)程沒了.socket是文件,隨之被關(guān)閉,雖然進(jìn)程沒了,但是連接還在,仍然可以進(jìn)行四次揮手.

2. 主機(jī)關(guān)機(jī)(正常關(guān)機(jī))

先殺死用戶的所有進(jìn)程.
這樣也會(huì)觸發(fā)四次揮手,如果揮完就釋放連接;如果沒有揮完,就關(guān)機(jī)了,此時(shí)對(duì)方就會(huì)重傳,重傳幾次fin后,如果沒有收到ack,嘗試重置連接,如果還不行,就釋放連接.

3. 主句掉電(拔電源)/網(wǎng)線斷開

瞬間及其關(guān)機(jī),來不及進(jìn)行任何揮手操作.

• 對(duì)端是發(fā)送方,對(duì)端就會(huì)收不到ack,然后就會(huì)超時(shí)重傳,緊接著重置連接,還不行的情況下就會(huì)釋放連接.
• 對(duì)端是接收方,對(duì)端沒法立即知道,你這邊是還沒來得及發(fā)新的數(shù)據(jù),還是直接沒了,TCP內(nèi)置了心跳包?；顧C(jī)制.這樣對(duì)端就會(huì)定期給咱們發(fā)一個(gè)心跳包(ping),咱們返回一個(gè)(pong);如果每個(gè)ping都有及時(shí)的pong,這個(gè)時(shí)候就說明當(dāng)前對(duì)端的狀況良好,如果ping過去之后,沒有pong,這樣幾說明心跳沒了,就認(rèn)為是掛了.

心跳包的特點(diǎn).

• 周期性.
• 如果心跳沒了,就掛了.

TCP與UDP的區(qū)別文章來源地址http://www.zghlxwxcb.cn/news/detail-424114.html

• TCP是可靠的通信方式。通過TCP連接傳送的數(shù)據(jù)，TCP通過超時(shí)重傳、 數(shù)據(jù)校驗(yàn)等方式來確保數(shù)據(jù)無差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá)；而UDP由于無需連接的原因，將會(huì)以最大速度進(jìn)行傳輸，但不保證可靠交付，也就是會(huì)出現(xiàn)丟失、重復(fù)等等問題。
• TCP面向連接，通過三次握手建立連接，四次揮手解除連接;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接，這種方式為UDP帶來了高效的傳輸效率，但也導(dǎo)致無法確保數(shù)據(jù)的發(fā)送成功。
• TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流，由于連接的問題，當(dāng)網(wǎng)絡(luò)出現(xiàn)波動(dòng)時(shí)，連接可能出現(xiàn)響應(yīng)問題；UDP是面向報(bào)文的，UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低。
• 每一條TCP連接只能是點(diǎn)到點(diǎn)的；而UDP不建立連接，所以可以支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信，也就是可以同時(shí)接受多個(gè)人的包。
• TCP需要建立連接，首部開銷20字節(jié)相比8個(gè)字節(jié)的UDP顯得比較大。
• TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道。

到了這里，關(guān)于【網(wǎng)絡(luò)原理進(jìn)階篇】自定義協(xié)議,協(xié)議約定符,三次握手,四次揮手,TCP(保證可靠性機(jī)制)和UDP原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！