UDP 和 TCP 的區(qū)別

在上一則文章中，對 TCP 的三次握手建立連接和四次揮手釋放連接進(jìn)行了詳細(xì)地闡述，本節(jié)教程針對于 TCP 的其他內(nèi)容進(jìn)行講解，首先是同處于傳輸層協(xié)議的UDP協(xié)議，這兩者有什么區(qū)別與聯(lián)系呢？

相同點(diǎn)那就是說：UDP?和?TCP?是?TCP/IP?體系結(jié)構(gòu)運(yùn)輸層中的兩個(gè)重要協(xié)議,下圖是TCP/IP的體系結(jié)構(gòu)圖：

額外補(bǔ)充的一點(diǎn)就是說，在?TCP和?UDP?協(xié)議下層的IP協(xié)議，IP協(xié)議可以為各種網(wǎng)絡(luò)應(yīng)用提供服務(wù)，使用IP層協(xié)議互連不同的網(wǎng)絡(luò)接口，下面是一個(gè)結(jié)構(gòu)圖：

TCP和UDP的使用頻率也僅次于位于網(wǎng)際層的IP協(xié)議。

UDP也稱之為是用戶數(shù)據(jù)報(bào)協(xié)議，而TCP呢，被稱之為傳輸控制協(xié)議，比較顯著的一點(diǎn)區(qū)別就是說，UDP?是無連接的，而TCP?是面向連接的，下面是兩種通信方式通信的一個(gè)示意圖：

如上圖所示，對于UDP來講，其無需建立連接就能夠進(jìn)行數(shù)據(jù)傳輸，而對于?TCP來講，其在進(jìn)行數(shù)據(jù)傳輸之前，需要進(jìn)行“三報(bào)文握手”建立連接，然后才進(jìn)行數(shù)據(jù)傳輸，數(shù)據(jù)傳輸完成之后，還需要進(jìn)行“四報(bào)文揮手”釋放連接。

也正是因?yàn)?code style="box-sizing: border-box;margin-right: 2px;margin-left: 2px;padding: 2px 4px;font-size: inherit;color: rgb(233, 105, 0);line-height: inherit;overflow-wrap: break-word;border-radius: 4px;background: rgb(248, 248, 248);">UDP無連接的特性，對于UDP來說，其支持單播、多播以及廣播，而對于TCP來說，因?yàn)槿挝帐纸⒌牡倪B接，它有了一條可靠的信道，它也就僅僅支持單播，下面是兩個(gè)通信方式的示意圖：

緊接著，分析一下UDP和TCP數(shù)據(jù)傳輸?shù)脑敿?xì)過程

可以看到，對于?UDP來講，其是面向應(yīng)用報(bào)文的，發(fā)送方的應(yīng)用進(jìn)程將應(yīng)用報(bào)文交付給傳輸層的UDP,UDP直接給應(yīng)用層報(bào)文添加一個(gè)UDP首部，使之成為UDP用戶數(shù)據(jù)報(bào)，然后進(jìn)行發(fā)送，接收方的UDP收到該UDP用戶數(shù)據(jù)報(bào)后，去掉UDP首部，將應(yīng)用層報(bào)文交付給應(yīng)用進(jìn)程，換言之，就是說UDP對應(yīng)用進(jìn)程交下來的報(bào)文既不合并也不拆分，而是保留這些報(bào)文的邊界，也就是說,UDP是面向應(yīng)用報(bào)文的。

緊接著，上圖的右邊是TCP的數(shù)據(jù)發(fā)送流程，發(fā)送方的TCP把應(yīng)用進(jìn)程交付下來的數(shù)據(jù)塊看作是一連串的無結(jié)構(gòu)的字節(jié)流，TCP并不知道這些待傳送的字節(jié)流的含義，僅僅將他們編號，并存儲在自己的發(fā)送緩存中，TCP根據(jù)發(fā)送策略，從發(fā)送緩存中提取出一定數(shù)量的字節(jié)，構(gòu)建TCP報(bào)文段并發(fā)送，接收方的TCP一方面從接收到的TCP報(bào)文中取出數(shù)據(jù)載荷部分并存儲在接收緩存中，一方面將接收緩存中的一些字節(jié)交付給應(yīng)用進(jìn)程，TCP不保證所收到的數(shù)據(jù)塊與發(fā)送方應(yīng)用進(jìn)程所發(fā)出的數(shù)據(jù)塊具有對應(yīng)大小的關(guān)系，但是呢，接收方應(yīng)用進(jìn)程收到的字節(jié)流必須和發(fā)送方應(yīng)用進(jìn)程發(fā)出的字節(jié)流完全一樣，與此同時(shí)，接收方應(yīng)用進(jìn)程必須有能力識別收到的字節(jié)流，把它還原成有意義的應(yīng)用層數(shù)據(jù)。也就是說，TCP是面向字節(jié)流的，這也正是TCP實(shí)現(xiàn)可靠傳輸、流量控制以及擁塞控制的基礎(chǔ)。

緊接著，再來看另外一個(gè)對比，其示意圖如下所示：

就是說對于TCP/IP體系架構(gòu)來說，網(wǎng)際層向上提供無連接不可靠的傳輸服務(wù)，而對于?UDP來說，其所再運(yùn)輸層向上提供無連接不可靠的傳輸服務(wù)，這樣一種機(jī)制也就造成了數(shù)據(jù)包的丟失以及誤碼現(xiàn)象，但是對于UDP傳輸來講，它就僅僅是丟棄其他什么也不做；但是對于TCP傳輸協(xié)議來講呢，網(wǎng)際層向上提供無連接不可靠的傳輸服務(wù)，TCP所處的傳輸層向上提供面向連接的可靠傳輸服務(wù)，這也就實(shí)現(xiàn)了基于TCP連接的可靠信道，不會出現(xiàn)傳輸差錯(cuò)，誤碼，丟失，亂序以及重復(fù)的問題。

下面對比一下UDP和TCP報(bào)文的首部，一個(gè)UDP用戶數(shù)據(jù)報(bào)由首部和數(shù)據(jù)載荷兩部分組成，TCP報(bào)文段也是由首部和數(shù)據(jù)載荷部分組成，其中UDP用戶數(shù)據(jù)報(bào)首部僅僅8個(gè)字節(jié)，僅僅包含源端口，目的端口，長度以及校驗(yàn)和。而對于TCP來講，其首部包含的信息較多，其首部大小最小為20字節(jié)，最大為60字節(jié)。

小結(jié)

綜上所述，針對于TCP和UDP來說兩者的特點(diǎn)與區(qū)別匯總?cè)缦拢?/p>用戶數(shù)據(jù)報(bào)協(xié)議UDP

• 無連接

• 支持一對一，一對多，多對一和多對多交互通信

• 對應(yīng)用層交付的報(bào)文直接打包

• 盡最大努力交付，也就是不可靠；不使用流量控制和擁塞控制

• 首部開銷小，僅 8 字節(jié)

傳輸控制層協(xié)議TCP

• 面向連接

• 每一條TCP連接只能有兩個(gè)端點(diǎn)，只能是一對一通信

• 面向字節(jié)流

• 可靠傳輸，使用流量控制和擁塞控制

• 首部最小20字節(jié)，最大60字節(jié)

TCP 的流量控制

滑動(dòng)窗口的引出

在上一則文章敘述?TCP三次握手和四次揮手的那個(gè)過程中，我們知道對于TCP的通信來講，是每發(fā)送一個(gè)數(shù)據(jù)，都要進(jìn)行一次確認(rèn)應(yīng)答。當(dāng)上一個(gè)數(shù)據(jù)包收到應(yīng)答了，再發(fā)送下一個(gè)數(shù)據(jù)包，這樣一個(gè)通信的流程是如下所示的：

通過上述這個(gè)示意圖也可以看出，如果說每次發(fā)送一個(gè)數(shù)據(jù)包應(yīng)答一次再發(fā)送下一個(gè)數(shù)據(jù)包，這樣的效率也過于低下了，這時(shí)候也就引入了滑動(dòng)窗口的概念。那有了窗口，就可以指定窗口的大小了，窗口大小也就是指無需要等待應(yīng)答，而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值，比如說如果當(dāng)前的窗口是?3?的話，那么發(fā)送方就可以連續(xù)發(fā)送三個(gè)TCP段，而且如上圖所示如果其中的一個(gè)ACK丟失了，那么可以通過下一個(gè)確認(rèn)應(yīng)答進(jìn)行確認(rèn),比方說，如果ACK 600丟失了，那么ACK 700的確認(rèn)應(yīng)答就可以替代ACK 600的確認(rèn)應(yīng)答。

流量控制

根據(jù)上述引出的滑動(dòng)窗口機(jī)制，我們知道，因?yàn)榇藱C(jī)制的原因，我們能夠使得傳輸速率更快了，但是如果發(fā)送方的發(fā)送速率過快，那么接收方就可能來不及處理，這就會造成數(shù)據(jù)的丟失，而即將敘述的流量控制，就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方能夠來得及接收，而利用滑動(dòng)窗口機(jī)制可以很方便地在 TCP 連接上實(shí)現(xiàn)對發(fā)送方的流量控制。

在介紹流量控制是如何實(shí)現(xiàn)的之前，先來分別看看發(fā)送方和接收方的滑動(dòng)窗口，首先來介紹發(fā)送方的窗口，那對于發(fā)送方來講，這個(gè)窗口有多大呢？這是取決于接收方能夠處理多大的數(shù)據(jù)，也就是說在發(fā)送數(shù)據(jù)之前，接受方會給發(fā)送方報(bào)一個(gè)窗口大小，這個(gè)窗口大小也就是Advertised window，具體是什么意思呢？看如下示意圖：

• LastByteAcked:第一部分和第二部分的分界線

• LastByteSent:第二部分和第三部分的分界線

通過示意圖也可以看出來，對于Advertised window來說，這個(gè)窗口的大小應(yīng)該等于第二部分 第三部分。

對于接收端來講，它的緩存里面記錄的內(nèi)容要簡單一些，示意圖如下所示：

其中,MaxRcvBuffer也正如其字面意思，就是最大緩存的量，對于接收方的窗口大小也就如藍(lán)色方框所示，說到這里呢，也就引入了一個(gè)問題，就是說：接收窗口和發(fā)送窗口的大小是相等的么？

答案是并不是完全相等，接收窗口的大小是約等于發(fā)送窗口的大小的。

原因在于滑動(dòng)窗口不是一成不變的，比如說，當(dāng)接收方的應(yīng)用進(jìn)程讀取數(shù)據(jù)比較快的時(shí)候，這樣的話接收窗口就會很快空出來，但是要把這一消息告訴發(fā)送方，需要經(jīng)過網(wǎng)絡(luò)傳輸，那么這樣依賴就會出現(xiàn)不一致的情況，所以說，是約等于的。

發(fā)送方和接收方的窗口就基本這些內(nèi)容，接下來是關(guān)于流量控制的內(nèi)容：

先假設(shè)窗口不變，也就是9，當(dāng) 4 的確認(rèn)來的時(shí)候，窗口會向右移動(dòng)一個(gè)，整個(gè)時(shí)候，13這個(gè)序號的包也可以發(fā)送了。

如果說這個(gè)時(shí)候，發(fā)送方發(fā)送的過快，會將第三部分的10、11、12、13全部發(fā)送完畢，之后就停止發(fā)送了，未發(fā)送可發(fā)送部分為0

這個(gè)時(shí)候，只有當(dāng)包 5 的確認(rèn)到達(dá)的時(shí)候，在客戶端相當(dāng)于窗口再滑動(dòng)了一格，這個(gè)時(shí)候，第 14 個(gè)包才可以發(fā)送。

如果接收方處理的太慢了，那么就可以通過確認(rèn)信息來調(diào)整窗口的大小，現(xiàn)在假設(shè)一種比較極端的情況，就是說接收端一直不處理數(shù)據(jù)，那么當(dāng)數(shù)據(jù)包6的確認(rèn)到達(dá)之后，窗口大小就不能是 9了，就需要縮小一個(gè)變?yōu)?,下方是發(fā)送方在收到一個(gè)6的確認(rèn)包之后，窗口的變化情況，可以看到此時(shí)窗口的變化方式并不是向右移動(dòng)一格，而是窗口的左邊向由縮進(jìn)一格，窗口的整體大小并沒有發(fā)生變化。

如果說接收端一直不處理數(shù)據(jù)，那么隨著確認(rèn)的包越來越多，窗口也就越來越小，直到為0，下方是接收方窗口的變化情況：

與上圖接收方對應(yīng)的發(fā)送窗口的情況如下如所示，當(dāng) 14 的確認(rèn)到達(dá)發(fā)送端的時(shí)候，發(fā)送端的窗口也調(diào)整為0，停止發(fā)送。

如果到這種情況的話，發(fā)送方會定時(shí)發(fā)送窗口探測數(shù)據(jù)包，看是否有機(jī)會調(diào)整窗口的大小。當(dāng)接收方比較慢的時(shí)候，，要防止低能窗口綜合征，別空出一個(gè)字節(jié)來就趕快告訴發(fā)送方，然后馬上又填滿了，可以當(dāng)窗口太小的時(shí)候，不更新窗口，直到達(dá)到一定大小，或者緩沖區(qū)一半為空，才更新窗口。

上述就是TCP中的流量控制。

TCP 擁塞控制

在某段時(shí)間，如果對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能夠提供的可用部分，網(wǎng)絡(luò)性能就要變壞，這種情況就叫做擁塞。

在計(jì)算機(jī)網(wǎng)絡(luò)中的鏈路容量（即帶寬）、交換結(jié)點(diǎn)中的緩存和處理機(jī)等，都是網(wǎng)絡(luò)的資源

如果出現(xiàn)擁塞而不進(jìn)行控制，整個(gè)網(wǎng)絡(luò)的吞吐量將隨著輸入負(fù)荷的增大而下降。

下圖是理想擁塞控制，實(shí)際的擁塞控制，和無擁塞控制的一個(gè)曲線圖，曲線如下所示：

TCP 的擁塞控制算法主要涉及到四個(gè)，分別是：

• 慢開始算法

• 擁塞避免算法

• 快重傳算法

• 快恢復(fù)算法

在講解這四種擁塞控制算法之前，先假定如下條件：

• 數(shù)據(jù)是單方向傳送的，而另一個(gè)方向只傳送確認(rèn)

• 接收方總有足夠大的緩存空間，因而發(fā)送方發(fā)送的窗口的大小由網(wǎng)絡(luò)的擁塞程度來決定

• 以最大報(bào)文段?MSS?的個(gè)數(shù)作為討論問題的單位，而不是以字節(jié)為單位

也就是說現(xiàn)在發(fā)送方和接收方兩者之間的通信是這樣子的，具體過程如下圖所示：

發(fā)送方向接收方發(fā)送一個(gè) TCP 數(shù)據(jù)報(bào)文段，而接收方收到整個(gè)報(bào)文段之后，就向發(fā)送方回一個(gè)TCP確認(rèn)報(bào)文段

也就是說，發(fā)送方維護(hù)一個(gè)叫做擁塞窗口cwnd的狀態(tài)變量，其值取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)變化。

• 擁塞窗口cwnd的維護(hù)原則：只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口的值就增大一些；但是只要網(wǎng)絡(luò)中出現(xiàn)擁塞，擁塞窗口就減小一些。

• 判斷出現(xiàn)網(wǎng)絡(luò)擁塞的依據(jù)：沒有按時(shí)收到應(yīng)當(dāng)達(dá)到的確認(rèn)報(bào)文（也就是發(fā)生了超時(shí)重傳）。

發(fā)送方將擁塞窗口作為發(fā)送窗口，也就是 swnd = cwdn

維護(hù)一個(gè)慢開始門限ssthresh狀態(tài)變量：

• 當(dāng) cwnd < ssthresh 時(shí)，開始使用慢開始算法

• 當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法

• 當(dāng) cwnd = ssthresh 時(shí)，既可以使用慢開始算法，也可以使用擁塞避免算法

慢開始和擁塞避免算法

為了更改的闡述慢開始算法，我們給出下面這樣一個(gè)折線圖，其中折線圖的橫坐標(biāo)表示的是傳輸輪次，而一個(gè)傳輸輪次指的是發(fā)送方給接收方發(fā)送數(shù)據(jù)報(bào)文段之后，接收方給發(fā)送方回相應(yīng)的確認(rèn)報(bào)文段，一個(gè)傳輸輪次所經(jīng)歷的時(shí)間，其實(shí)就是往返時(shí)間，縱坐標(biāo)是擁塞窗口，這是一個(gè)動(dòng)態(tài)變化的值。

在 TCP 雙方建立邏輯連接關(guān)系時(shí)，擁塞窗口的值被設(shè)置為1 ，另外還需要設(shè)置慢開始門限的初始值為16，在執(zhí)行慢開始算法時(shí)，發(fā)送方每收到一個(gè)接收方發(fā)來的確認(rèn)報(bào)文段時(shí)，就將擁塞窗口值 1，然后再開始下一輪次的傳輸，當(dāng)擁塞窗口值增加到慢開始門限值時(shí)，就改為執(zhí)行擁塞避免算法。

上述的折線圖該如何解釋呢？就是說，如果最開始，發(fā)送方的擁塞窗口值為1，發(fā)送方發(fā)送一個(gè)TCP 報(bào)文段至接收方，接收方收到之后，發(fā)送TCP確認(rèn)報(bào)文段至發(fā)送方，當(dāng)發(fā)送方收到這個(gè)確認(rèn)報(bào)文段之后，就將擁塞窗口的值加1，因?yàn)樵谶@里，擁塞窗口的值就等于發(fā)送窗口的值，所以，此時(shí)發(fā)送窗口的值為 2，那么發(fā)送方就能夠發(fā)送兩個(gè)報(bào)文段到接收方，當(dāng)發(fā)送方收到這兩個(gè)報(bào)文段的確認(rèn)報(bào)文段后，就將擁塞窗口設(shè)置為 4，此時(shí)發(fā)送方就能發(fā)送4個(gè)TCP報(bào)文段至接收方，按照這樣一種原理，圖中數(shù)據(jù)包每增加一個(gè)輪次，擁塞窗口的值就呈現(xiàn)指數(shù)增長，直至增加到慢開始門限值，也就是 16，此時(shí)改為擁塞避免算法。

何為擁塞避免算法呢，也就是說當(dāng)前來講，每個(gè)傳輸輪次結(jié)束之后，擁塞窗口的值改為線性加1，而不是像慢開始算法那樣擁塞窗口的值呈現(xiàn)指數(shù)增長，比如說此時(shí)發(fā)送方能夠發(fā)送15~30號的數(shù)據(jù)報(bào)文段，當(dāng)發(fā)送方收到 15 ~30 號的數(shù)據(jù)確認(rèn)報(bào)文段，將擁塞窗口值加1增大到17，依據(jù)此原理，發(fā)送方和接收方又進(jìn)行了幾個(gè)輪次的數(shù)據(jù)傳輸，達(dá)到如下所示的一個(gè)折線圖：

如果說此時(shí)，在擁塞窗口值達(dá)到 24 的時(shí)候，發(fā)送方又向接收方發(fā)送了一串?dāng)?shù)據(jù)包，假設(shè)這串報(bào)文段在傳輸過程中，丟失了幾個(gè)，這必然會造成發(fā)送方對這些丟失報(bào)文段的超時(shí)重傳，發(fā)送方依據(jù)此判斷網(wǎng)絡(luò)很可能出現(xiàn)了擁塞，那么這個(gè)時(shí)候就需要做如下的工作：將慢開始門限值更新為發(fā)生擁塞時(shí)擁塞窗口值的一半，然后將擁塞窗口值調(diào)整為1 ，重新執(zhí)行慢開始算法，當(dāng)擁塞窗口達(dá)到慢開始門限值的時(shí)候，就執(zhí)行擁塞避免算法，具體過程如圖所示：

最后，對這一整個(gè)過程進(jìn)行標(biāo)注，標(biāo)注之后的折線圖如圖所示：

快重傳算法

有些時(shí)候，個(gè)別報(bào)文段會在網(wǎng)絡(luò)中丟失，但是實(shí)際網(wǎng)絡(luò)中并沒有發(fā)生擁塞，這也將導(dǎo)致發(fā)送方超時(shí)重傳，并且誤認(rèn)為是發(fā)生了擁塞，這個(gè)時(shí)候，發(fā)送方將擁塞窗口設(shè)置為最小值1，并且錯(cuò)誤地啟動(dòng)了慢開始算法，因而降低了傳輸效率。

而采用快重傳算法可以讓發(fā)送方盡可能早地知道發(fā)生了個(gè)別報(bào)文段的丟失，也就是說快重傳也就是讓發(fā)送方盡快進(jìn)行重傳，而不是等待超時(shí)重傳計(jì)時(shí)器超時(shí)再重傳。

具體是怎么樣呢？就是說接收方不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn)，而是要立即發(fā)送確認(rèn)；即使是收到了失序的報(bào)文段也要立即發(fā)出對已經(jīng)收到報(bào)文段的重復(fù)確認(rèn)，發(fā)送方一旦收到 3 個(gè)連續(xù)的重復(fù)確認(rèn)，就將相應(yīng)的報(bào)文段立即重傳，而不是等待該報(bào)文段超時(shí)重傳計(jì)時(shí)器超時(shí)再重傳。

具體的過程是怎么樣的呢，看如下所示的示意圖：

通過上圖可以看到，在發(fā)送M2時(shí)，并沒有等待M1的確認(rèn)報(bào)文段到達(dá)之后再發(fā)送，而是在確認(rèn)報(bào)文段到達(dá)之前就將?M2?的報(bào)文段發(fā)送出去了，發(fā)送?M3?的時(shí)候，數(shù)據(jù)報(bào)發(fā)生了丟失，在發(fā)送?M4?的時(shí)候，接收方收到之后，會繼續(xù)回傳報(bào)文段 M2 的確認(rèn)，一直到發(fā)送?M6?的時(shí)候，都是回傳的M2的確認(rèn)包，而此時(shí)對于M2的確認(rèn)包的接收已經(jīng)累計(jì)3個(gè)了,就立即重傳M3報(bào)文段，這樣也就不會造成對?M3?報(bào)文段的超時(shí)重傳，也就不會將擁塞窗口調(diào)整為 1 ，也就能夠大大提升網(wǎng)絡(luò)的傳輸效率。

快恢復(fù)算法

發(fā)送方一旦收到3個(gè)重復(fù)確認(rèn)，就知道現(xiàn)在只是丟失了個(gè)別的報(bào)文段。于是不啟動(dòng)慢開始算法，而執(zhí)行快恢復(fù)算法;發(fā)送方將慢開始門限值和擁塞窗口值調(diào)整為當(dāng)前窗口的一半;開始執(zhí)行擁塞避免算法。

小結(jié)

綜上所述，我們綜合前面所敘述的慢開始和擁塞避免算法，以及快重傳和快恢復(fù)算法舉一個(gè)例子，例子如下所示：

這個(gè)圖結(jié)合上述的理論能很好的進(jìn)行解釋，這里就不在進(jìn)行闡述了。

總結(jié)

至此，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)中 TCP 部分的闡述到此也就結(jié)束了，結(jié)合前面一則的 TCP 教程閱讀更佳哦~