2.6 UDP 協(xié)議的收發(fā)操作

2.6.1 不需要重發(fā)的數(shù)據(jù)用 UDP 發(fā)送更高效

大多數(shù)的應(yīng)用程序都像之前介紹的一樣使用 TCP 協(xié)議來收發(fā)數(shù)據(jù)，但當(dāng)然也有例外。

有些應(yīng)用程序不使用 TCP 協(xié)議，而是使用 UDP 協(xié)議來收發(fā)數(shù)據(jù)。

向 DNS 服務(wù)器查詢 IP 地址的時(shí)候我們用的也是 UDP 協(xié)議。下面就簡(jiǎn)單介紹一下 UDP 協(xié)議。

TCP 為什么要設(shè)計(jì)得如此復(fù)雜

因?yàn)槲覀冃枰獙?shù)據(jù)高效且可靠地發(fā)送給對(duì)方。為了實(shí)現(xiàn)可靠性，我們就需要確認(rèn)對(duì)方是否收到了我們發(fā)送的數(shù)據(jù)，如果沒有還需要再發(fā)一遍。

要實(shí)現(xiàn)上面的要求，最簡(jiǎn)單的方法是數(shù)據(jù)全部發(fā)送完畢之后讓接收方返回一個(gè)接收確認(rèn)。

這樣一來，如果沒收到直接全部重新發(fā)送一遍就好了，根本不用像 TCP 一樣要管理發(fā)送和確認(rèn)的進(jìn)度。

但是，如果漏掉了一個(gè)包就要全部重發(fā)一遍，怎么看都很低效。

為了實(shí)現(xiàn)高效的傳輸，我們要避免重發(fā)已經(jīng)送達(dá)的包，而是只重發(fā)那些出錯(cuò)的或者未送達(dá)的包。TCP 之所以復(fù)雜，就是因?yàn)橐獙?shí)現(xiàn)這一點(diǎn)。

可以不使用TCP的情形

數(shù)據(jù)很短，用一個(gè)包就能裝得下時(shí)，即便沒有 TCP 這樣復(fù)雜的機(jī)制，我們也能夠高效地重發(fā)數(shù)據(jù)。

如果只有一個(gè)包，就不用考慮哪個(gè)包未送達(dá)了，因?yàn)槿恐匕l(fā)也只不過是重發(fā)一個(gè)包而已

如果不使用 TCP，也不需要發(fā)送那些用來建立和斷開連接的控制包了。

此外，我們發(fā)送了數(shù)據(jù)，對(duì)方一般都會(huì)給出回復(fù)，只要將回復(fù)的數(shù)據(jù)當(dāng)作接收確認(rèn)就行了，也不需要專門的接收確認(rèn)包了。

像 DNS 查詢等交換控制信息的操作基本上都可以在一個(gè)包的大小范圍內(nèi)解決，這種場(chǎng)景中就可以用 UDP 來代替TCP。

?

2.6.2 控制用的短數(shù)據(jù)

UDP和TCP的區(qū)別

UDP不需要交換控制信息

UDP 沒有 TCP 的接收確認(rèn)、窗口等機(jī)制，因此在收發(fā)數(shù)據(jù)之前也不需要交換控制信息。

也就是說不需要建立和斷開連接的步驟，只要在從應(yīng)用程序獲取的數(shù)據(jù)前面加上 UDP 頭部，然后交給 IP 進(jìn)行發(fā)送就可以了。

UDP接收只需要IP地址和端口號(hào)

接收也很簡(jiǎn)單，只要根據(jù) IP 頭部中的接收方和發(fā)送方 IP 地址，以及 UDP 頭部中的接收方和發(fā)送方端口號(hào)，找到相應(yīng)的套接字并將數(shù)據(jù)交給相應(yīng)的應(yīng)用程序就可以了。

UDP只負(fù)責(zé)發(fā)送包

UDP遇到錯(cuò)誤或者丟包也一概不管，因?yàn)?UDP 只負(fù)責(zé)單純地發(fā)送包而已，并不像TCP 一樣會(huì)對(duì)包的送達(dá)狀態(tài)進(jìn)行監(jiān)控，所以協(xié)議棧也不知道有沒有發(fā)生錯(cuò)誤。

但這樣并不會(huì)引發(fā)什么問題，因此出錯(cuò)時(shí)就收不到來自對(duì)方的回復(fù)，應(yīng)用程序會(huì)注意到這個(gè)問題，并重新發(fā)送一遍數(shù)據(jù)。

這樣的操作本身并不復(fù)雜，也并不會(huì)增加應(yīng)用程序的負(fù)擔(dān)。

UDP可發(fā)送的數(shù)據(jù)長(zhǎng)度

UDP 可發(fā)送的數(shù)據(jù)最大長(zhǎng)度為 IP 包的最大長(zhǎng)度減去 IP 頭部和 UDP 頭部的長(zhǎng)度，這個(gè)長(zhǎng)度與 MTU、MSS 不是一個(gè)層面上的概念。

MTU 和MSS 是基于以太網(wǎng)和通信線路上網(wǎng)絡(luò)包的最大長(zhǎng)度來計(jì)算的，而 IP 包的最大長(zhǎng)度是由 IP 頭部中的“全長(zhǎng)”字段決定的。

“全長(zhǎng)”字段的長(zhǎng)度為 16比特，因此從 IP 協(xié)議規(guī)范來看，IP 包的最大長(zhǎng)度為 65 535 字節(jié)，再減去IP 頭部和 UDP 頭部的長(zhǎng)度，就是 UDP 協(xié)議所能發(fā)送的數(shù)據(jù)最大長(zhǎng)度。

如果不考慮可選字段的話，一般來說 IP 頭部為 20 字節(jié)，UDP 頭部為 8 字節(jié)，因此 UDP 的最大數(shù)據(jù)長(zhǎng)度為 65 507 字節(jié)。

當(dāng)然，這么長(zhǎng)的數(shù)據(jù)已經(jīng)超過了以太網(wǎng)和通信線路的最大傳輸長(zhǎng)度，因此需要讓 IP 模塊使用分片功能拆分之后再傳輸。

?

2.6.3 音頻和視頻數(shù)據(jù)

有另一個(gè)場(chǎng)景會(huì)使用 UDP，就是發(fā)送音頻和視頻數(shù)據(jù)的時(shí)候。

音頻和視頻數(shù)據(jù)必須在規(guī)定的時(shí)間內(nèi)送達(dá)，一旦送達(dá)晚了，就會(huì)錯(cuò)過播放時(shí)機(jī)，導(dǎo)致聲音和圖像卡頓。

如果像 TCP 一樣通過接收確認(rèn)響應(yīng)來檢查錯(cuò)誤并重發(fā)，重發(fā)的過程需要消耗一定的時(shí)間，因此重發(fā)的數(shù)據(jù)很可能已經(jīng)錯(cuò)過了播放的時(shí)機(jī)。

一旦錯(cuò)過播放時(shí)機(jī)，重發(fā)數(shù)據(jù)也是沒有用的，因?yàn)槁曇艉蛨D像已經(jīng)卡頓了，這是無法挽回的。

當(dāng)然，我們可以用高速線路讓重發(fā)的數(shù)據(jù)能夠在規(guī)定的時(shí)間內(nèi)送達(dá)，但這樣一來可能要增加幾倍的帶寬才行。

UDP 經(jīng)常會(huì)被防火墻阻止，因此當(dāng)需要穿越防火墻傳輸音頻和視頻數(shù)據(jù)時(shí)，盡管需要消耗額外的帶寬，但有時(shí)候也只能使用 TCP。

此外，音頻和視頻數(shù)據(jù)中缺少了某些包并不會(huì)產(chǎn)生嚴(yán)重的問題，只是會(huì)產(chǎn)生一些失真或者卡頓而已，一般都是可以接受的。

在這些無需重發(fā)數(shù)據(jù)，或者是重發(fā)了也沒什么意義的情況下，使用UDP 發(fā)送數(shù)據(jù)的效率會(huì)更高。

?

章節(jié)測(cè)驗(yàn)

表示網(wǎng)絡(luò)包收件人的接收方 IP 地址是位于 IP 頭部還是 TCP 頭部中呢？

IP頭部

端口號(hào)用來指定服務(wù)器程序的種類，那么它位于 TCP 頭部還是 IP頭部中呢？

TCP頭部

會(huì)對(duì)包是否正確送達(dá)進(jìn)行確認(rèn)的是 TCP 還是 IP 呢？

IP

根據(jù) IP 地址查詢 MAC 地址的機(jī)制叫什么？

ARP

在收到 ACK 號(hào)之前繼續(xù)發(fā)送下一個(gè)包的方式叫什么？

滑動(dòng)窗口

轉(zhuǎn)載于:https://www.cnblogs.com/errornull/p/9971076.html

總結(jié)

以上是生活随笔為你收集整理的网络是怎样连接的-UDP协议的收发操作的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。