[[353775]]

運(yùn)輸層位于應(yīng)用層和網(wǎng)絡(luò)層之間，是 OSI 分層體系中的第四層，同時(shí)也是網(wǎng)絡(luò)體系結(jié)構(gòu)的重要部分。運(yùn)輸層主要負(fù)責(zé)網(wǎng)絡(luò)上的端到端通信。

運(yùn)輸層為運(yùn)行在不同主機(jī)上的應(yīng)用程序之間的通信起著至關(guān)重要的作用。下面我們就來一起探討一下關(guān)于運(yùn)輸層的協(xié)議部分

運(yùn)輸層概述

計(jì)算機(jī)網(wǎng)絡(luò)的運(yùn)輸層非常類似于高速公路，高速公路負(fù)責(zé)把人或者物品從一端運(yùn)送到另一端，而計(jì)算機(jī)網(wǎng)絡(luò)的運(yùn)輸層則負(fù)責(zé)把報(bào)文從一端運(yùn)輸?shù)搅硪欢?，這個(gè)端指的就是 端系統(tǒng)。在計(jì)算機(jī)網(wǎng)絡(luò)中，任意一個(gè)可以交換信息的介質(zhì)都可以稱為端系統(tǒng)，比如手機(jī)、網(wǎng)絡(luò)媒體、電腦、運(yùn)營(yíng)商等。

在運(yùn)輸層運(yùn)輸報(bào)文的過程中，會(huì)遵守一定的協(xié)議規(guī)范，比如一次傳輸?shù)臄?shù)據(jù)限制、選擇什么樣的運(yùn)輸協(xié)議等。運(yùn)輸層實(shí)現(xiàn)了讓兩個(gè)互不相關(guān)的主機(jī)進(jìn)行邏輯通信的功能，看起來像是讓兩個(gè)主機(jī)相連一樣。

運(yùn)輸層協(xié)議是在端系統(tǒng)中實(shí)現(xiàn)的，而不是在路由器中實(shí)現(xiàn)的。路由只是做識(shí)別地址并轉(zhuǎn)發(fā)的功能。這就比如快遞員送快遞一樣，當(dāng)然是要由地址的接受人也就是 xxx 號(hào)樓 xxx 單元 xxx 室的這個(gè)人來判斷了!

TCP 如何判斷是哪個(gè)端口的呢?

還記得數(shù)據(jù)包的結(jié)構(gòu)嗎，這里來回顧一下

數(shù)據(jù)包經(jīng)過每層后，該層協(xié)議都會(huì)在數(shù)據(jù)包附上包首部，一個(gè)完整的包首部圖如上所示。

在數(shù)據(jù)傳輸?shù)竭\(yùn)輸層后，會(huì)為其附上 TCP 首部，首部包含著源端口號(hào)和目的端口號(hào)。

在發(fā)送端，運(yùn)輸層將從發(fā)送應(yīng)用程序進(jìn)程接收到的報(bào)文轉(zhuǎn)化成運(yùn)輸層分組，分組在計(jì)算機(jī)網(wǎng)絡(luò)中也稱為 報(bào)文段(segment)。運(yùn)輸層一般會(huì)將報(bào)文段進(jìn)行分割，分割成為較小的塊，為每一塊加上運(yùn)輸層首部并將其向目的地發(fā)送。

在發(fā)送過程中，可選的運(yùn)輸層協(xié)議(也就是交通工具) 主要有 TCP 和 UDP ，關(guān)于這兩種運(yùn)輸協(xié)議的選擇及其特性也是我們著重探討的重點(diǎn)。

TCP 和 UDP 前置知識(shí)

在 TCP/IP 協(xié)議中能夠?qū)崿F(xiàn)傳輸層功能的，最具代表性的就是 TCP 和 UDP。提起 TCP 和 UDP ，就得先從這兩個(gè)協(xié)議的定義說起。

TCP 叫做傳輸控制協(xié)議(TCP，Transmission Control Protocol)，通過名稱可以大致知道 TCP 協(xié)議有控制傳輸?shù)墓δ?，主要體現(xiàn)在其可控，可控就表示著可靠，確實(shí)是這樣的，TCP 為應(yīng)用層提供了一種可靠的、面向連接的服務(wù)，它能夠?qū)⒎纸M可靠的傳輸?shù)椒?wù)端。

UDP 叫做 用戶數(shù)據(jù)報(bào)協(xié)議(UDP，User Datagram Protocol)，通過名稱可以知道 UDP 把重點(diǎn)放在了數(shù)據(jù)報(bào)上，它為應(yīng)用層提供了一種無需建立連接就可以直接發(fā)送數(shù)據(jù)報(bào)的方法。

怎么計(jì)算機(jī)網(wǎng)絡(luò)中的術(shù)語對(duì)一個(gè)數(shù)據(jù)的描述這么多啊?

在計(jì)算機(jī)網(wǎng)絡(luò)中，在不同層之間會(huì)有不同的描述。我們上面提到會(huì)將運(yùn)輸層的分組稱為報(bào)文段，除此之外，還會(huì)將 TCP 中的分組也稱為報(bào)文段，然而將 UDP 的分組稱為數(shù)據(jù)報(bào)，同時(shí)也將網(wǎng)絡(luò)層的分組稱為數(shù)據(jù)報(bào)

但是為了統(tǒng)一，一般在計(jì)算機(jī)網(wǎng)絡(luò)中我們統(tǒng)一稱 TCP 和 UDP 的報(bào)文為 報(bào)文段，這個(gè)就相當(dāng)于是約定，到底如何稱呼不用過多糾結(jié)啦。

套接字

在 TCP 或者 UDP 發(fā)送具體的報(bào)文信息前，需要先經(jīng)過一扇 門，這個(gè)門就是套接字(socket)，套接字向上連接著應(yīng)用層，向下連接著網(wǎng)絡(luò)層。在操作系統(tǒng)中，操作系統(tǒng)分別為應(yīng)用和硬件提供了接口(Application Programming Interface)。而在計(jì)算機(jī)網(wǎng)絡(luò)中，套接字同樣是一種接口，它也是有接口 API 的。

使用 TCP 或 UDP 通信時(shí)，會(huì)廣泛用到套接字的 API，使用這套 API 設(shè)置 IP 地址、端口號(hào)，實(shí)現(xiàn)數(shù)據(jù)的發(fā)送和接收。

現(xiàn)在我們知道了， Socket 和 TCP/IP 沒有必然聯(lián)系，Socket 的出現(xiàn)只是方便了 TCP/IP 的使用，如何方便使用呢?你可以直接使用下面 Socket API 的這些方法。

套接字類型

套接字的主要類型有三種，下面我們分別介紹一下

• 數(shù)據(jù)報(bào)套接字(Datagram sockets)：數(shù)據(jù)報(bào)套接字提供一種無連接的服務(wù)，而且并不能保證數(shù)據(jù)傳輸?shù)目煽啃浴?shù)據(jù)有可能在傳輸過程中丟失或出現(xiàn)數(shù)據(jù)重復(fù)，且無法保證順序地接收到數(shù)據(jù)。數(shù)據(jù)報(bào)套接字使用UDP( User DatagramProtocol)協(xié)議進(jìn)行數(shù)據(jù)的傳輸。由于數(shù)據(jù)報(bào)套接字不能保證數(shù)據(jù)傳輸?shù)目煽啃裕瑢?duì)于有可能出現(xiàn)的數(shù)據(jù)丟失情況，需要在程序中做相應(yīng)的處理。
• 流套接字(Stream sockets)：流套接字用于提供面向連接、可靠的數(shù)據(jù)傳輸服務(wù)。能夠保證數(shù)據(jù)的可靠性、順序性。流套接字之所以能夠?qū)崿F(xiàn)可靠的數(shù)據(jù)服務(wù)，原因在于其使用了傳輸控制協(xié)議，即 TCP(The Transmission Control Protocol)協(xié)議
• 原始套接字(Raw sockets): 原始套接字允許直接發(fā)送和接收 IP 數(shù)據(jù)包，而無需任何特定于協(xié)議的傳輸層格式，原始套接字可以讀寫內(nèi)核沒有處理過的 IP 數(shù)據(jù)包。

套接字處理過程

在計(jì)算機(jī)網(wǎng)絡(luò)中，要想實(shí)現(xiàn)通信，必須至少需要兩個(gè)端系統(tǒng)，至少需要一對(duì)兩個(gè)套接字才行。下面是套接字的通信過程。

• socket 中的 API 用于創(chuàng)建通信鏈路中的端點(diǎn)，創(chuàng)建完成后，會(huì)返回描述該套接字的套接字描述符。

就像使用文件描述符來訪問文件一樣，套接字描述符用來訪問套接字。

• 當(dāng)應(yīng)用程序具有套接字描述符后，它可以將唯一的名稱綁定在套接字上，服務(wù)器必須綁定一個(gè)名稱才能在網(wǎng)絡(luò)中訪問
• 在為服務(wù)端分配了 socket 并且將名稱使用 bind 綁定到套接字上后，將會(huì)調(diào)用 listen api。listen 表示客戶端愿意等待連接的意愿，listen 必須在 accept api 之前調(diào)用。
• 客戶端應(yīng)用程序在流套接字(基于 TCP)上調(diào)用 connect 發(fā)起與服務(wù)器的連接請(qǐng)求。
• 服務(wù)器應(yīng)用程序使用acceptAPI 接受客戶端連接請(qǐng)求，服務(wù)器必須先成功調(diào)用 bind 和 listen 后，再調(diào)用 accept api。
• 在流套接字之間建立連接后，客戶端和服務(wù)器就可以發(fā)起 read/write api 調(diào)用了。
• 當(dāng)服務(wù)器或客戶端要停止操作時(shí)，就會(huì)調(diào)用 close API 釋放套接字獲取的所有系統(tǒng)資源。

雖然套接字 API 位于應(yīng)用程序?qū)雍蛡鬏攲又g的通信模型中，但是套接字 API 不屬于通信模型。套接字 API 允許應(yīng)用程序與傳輸層和網(wǎng)絡(luò)層進(jìn)行交互。

在往下繼續(xù)聊之前，我們先播放一個(gè)小插曲，簡(jiǎn)單聊一聊 IP。

聊聊 IP

IP 是Internet Protocol(網(wǎng)際互連協(xié)議)的縮寫，是 TCP/IP 體系中的網(wǎng)絡(luò)層協(xié)議。設(shè)計(jì) IP 的初衷主要想解決兩類問題

提高網(wǎng)絡(luò)擴(kuò)展性：實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)互聯(lián)

對(duì)應(yīng)用層和鏈路層進(jìn)行解藕，讓二者獨(dú)立發(fā)展。

IP 是整個(gè) TCP/IP 協(xié)議族的核心，也是構(gòu)成互聯(lián)網(wǎng)的基礎(chǔ)。為了實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)的互通互聯(lián)，IP 更加注重適應(yīng)性、簡(jiǎn)潔性和可操作性，并在可靠性做了一定的犧牲。IP 不保證分組的交付時(shí)限和可靠性，所傳送分組有可能出現(xiàn)丟失、重復(fù)、延遲或亂序等問題。

我們知道，TCP 協(xié)議的下一層就是 IP 協(xié)議層，既然 IP 不可靠，那么如何保證數(shù)據(jù)能夠準(zhǔn)確無誤地到達(dá)呢?

這就涉及到 TCP 傳輸機(jī)制的問題了，我們后面聊到 TCP 的時(shí)候再說。

端口號(hào)

在聊端口號(hào)前，先來聊一聊文件描述以及 socket 和端口號(hào)的關(guān)系

為了方便資源的使用，提高機(jī)器的性能、利用率和穩(wěn)定性等等原因，我們的計(jì)算機(jī)都有一層軟件叫做操作系統(tǒng)，它用于幫我們管理計(jì)算機(jī)可以使用的資源，當(dāng)我們的程序要使用一個(gè)資源的時(shí)候，可以向操作系統(tǒng)申請(qǐng)，再由操作系統(tǒng)為我們的程序分配和管理資源。通常當(dāng)我們要訪問一個(gè)內(nèi)核設(shè)備或文件時(shí)，程序可以調(diào)用系統(tǒng)函數(shù)，系統(tǒng)就會(huì)為我們打開設(shè)備或文件，然后返回一個(gè)文件描述符fd(或稱為ID，是一個(gè)整數(shù))，我們要訪問該設(shè)備或文件，只能通過該文件描述符?？梢哉J(rèn)為該編號(hào)對(duì)應(yīng)著打開的文件或設(shè)備。

而當(dāng)我們的程序要使用網(wǎng)絡(luò)時(shí)，要使用到對(duì)應(yīng)的操作系統(tǒng)內(nèi)核的操作和網(wǎng)卡設(shè)備，所以我們可以向操作系統(tǒng)申請(qǐng)，然后系統(tǒng)會(huì)為我們創(chuàng)建一個(gè)套接字 Socket，并返回這個(gè) Socket 的ID，以后我們的程序要使用網(wǎng)絡(luò)資源，只要向這個(gè) Socket 的編號(hào) ID 操作即可。而我們的每一個(gè)網(wǎng)絡(luò)通信的進(jìn)程至少對(duì)應(yīng)著一個(gè) Socket。向 Socket 的 ID 中寫數(shù)據(jù)，相當(dāng)于向網(wǎng)絡(luò)發(fā)送數(shù)據(jù)，向 Socket 中讀數(shù)據(jù)，相當(dāng)于接收數(shù)據(jù)。而且這些套接字都有唯一標(biāo)識(shí)符——端口號(hào)。

端口號(hào)是 16 位的非負(fù)整數(shù)，它的范圍是 0 - 65535 之間，這個(gè)范圍會(huì)分為三種不同的端口號(hào)段，由 Internet 號(hào)碼分配機(jī)構(gòu) IANA 進(jìn)行分配

• 周知/標(biāo)準(zhǔn)端口號(hào)，它的范圍是 0 - 1023
• 注冊(cè)端口號(hào)，范圍是 1024 - 49151
• 私有端口號(hào)，范圍是 49152 - 6553

一臺(tái)計(jì)算機(jī)上可以運(yùn)行多個(gè)應(yīng)用程序，當(dāng)一個(gè)報(bào)文段到達(dá)主機(jī)后，應(yīng)該傳輸給哪個(gè)應(yīng)用程序呢?你怎么知道這個(gè)報(bào)文段就是傳遞給 HTTP 服務(wù)器而不是 SSH 服務(wù)器的呢?

是憑借端口號(hào)嗎?當(dāng)報(bào)文到達(dá)服務(wù)器時(shí)，是端口號(hào)來區(qū)分不同應(yīng)用程序的，所以應(yīng)該借助端口號(hào)來區(qū)分。

舉個(gè)例子反駁一下 cxuan，假如到達(dá)服務(wù)器的兩條數(shù)據(jù)都是由 80 端口發(fā)出的你該如何區(qū)分呢?或者說到達(dá)服務(wù)器的兩條數(shù)據(jù)端口一樣，協(xié)議不同，該如何區(qū)分呢?

所以僅憑端口號(hào)來確定某一條報(bào)文顯然是不夠的。

互聯(lián)網(wǎng)上一般使用 源 IP 地址、目標(biāo) IP 地址、源端口號(hào)、目標(biāo)端口號(hào) 來進(jìn)行區(qū)分。如果其中的某一項(xiàng)不同，就被認(rèn)為是不同的報(bào)文段。這些也是多路分解和多路復(fù)用 的基礎(chǔ)。

確定端口號(hào)

在實(shí)際通信之前，需要先確定一下端口號(hào)，確定端口號(hào)的方法分為兩種：

標(biāo)準(zhǔn)既定的端口號(hào)

標(biāo)準(zhǔn)既定的端口號(hào)是靜態(tài)分配的，每個(gè)程序都會(huì)有自己的端口號(hào)，每個(gè)端口號(hào)都有不同的用途。端口號(hào)是一個(gè) 16 比特的數(shù)，其大小在 0 - 65535 之間，0 - 1023 范圍內(nèi)的端口號(hào)都是動(dòng)態(tài)分配的既定端口號(hào)，例如 HTTP 使用 80 端口來標(biāo)識(shí)，F(xiàn)TP 使用 21 端口來標(biāo)識(shí)，SSH 使用 22 來標(biāo)識(shí)。這類端口號(hào)有一個(gè)特殊的名字，叫做 周知端口號(hào)(Well-Known Port Number)。

時(shí)序分配的端口號(hào)

第二種分配端口號(hào)的方式是一種動(dòng)態(tài)分配法，在這種方法下，客戶端應(yīng)用程序可以完全不用自己設(shè)置端口號(hào)，憑借操作系統(tǒng)進(jìn)行分配，操作系統(tǒng)可以為每個(gè)應(yīng)用程序分配互不沖突的端口號(hào)。這種動(dòng)態(tài)分配端口號(hào)的機(jī)制即使是同一個(gè)客戶端發(fā)起的 TCP 連接，也能識(shí)別不同的連接。

多路復(fù)用和多路分解

我們上面聊到了在主機(jī)上的每個(gè)套接字都會(huì)分配一個(gè)端口號(hào)，當(dāng)報(bào)文段到達(dá)主機(jī)時(shí)，運(yùn)輸層會(huì)檢查報(bào)文段中的目的端口號(hào)，并將其定向到相應(yīng)的套接字，然后報(bào)文段中的數(shù)據(jù)通過套接字進(jìn)入其所連接的進(jìn)程。下面我們來聊一下什么是多路復(fù)用和多路分解的概念。

多路復(fù)用和多路分解分為兩種，即無連接的多路復(fù)用(多路分解)和面向連接的多路復(fù)用(多路分解)

無連接的多路復(fù)用和多路分解

開發(fā)人員會(huì)編寫代碼確定端口號(hào)是周知端口號(hào)還是時(shí)序分配的端口號(hào)。假如主機(jī) A 中的一個(gè) 10637 端口要向主機(jī) B 中的 45438 端口發(fā)送數(shù)據(jù)，運(yùn)輸層采用的是 UDP 協(xié)議，數(shù)據(jù)在應(yīng)用層產(chǎn)生后，會(huì)在運(yùn)輸層中加工處理，然后在網(wǎng)絡(luò)層將數(shù)據(jù)封裝得到 IP 數(shù)據(jù)報(bào)，IP 數(shù)據(jù)包通過鏈路層盡力而為的交付給主機(jī) B，然后主機(jī) B 會(huì)檢查報(bào)文段中的端口號(hào)判斷是哪個(gè)套接字的，這一系列的過程如下所示

UDP 套接字就是一個(gè)二元組，二元組包含目的 IP 地址和目的端口號(hào)。

所以，如果兩個(gè) UDP 報(bào)文段有不同的源 IP 地址和/或相同的源端口號(hào)，但是具有相同的目的 IP 地址和目的端口號(hào)，那么這兩個(gè)報(bào)文會(huì)通過套接字定位到相同的目的進(jìn)程。

這里思考一個(gè)問題，主機(jī) A 給主機(jī) B 發(fā)送一個(gè)消息，為什么還需要知道源端口號(hào)呢?比如我給妹子表達(dá)出我對(duì)你有點(diǎn)意思的信息，妹子還需要知道這個(gè)信息是從我的哪個(gè)器官發(fā)出的嗎?知道是我這個(gè)人對(duì)你有點(diǎn)意思不就完了?實(shí)際上是需要的，因?yàn)槊米尤绻磉_(dá)出她對(duì)你也有點(diǎn)意思，她是不是可能會(huì)親你一口，那她得知道往哪親吧?

這就是，在 A 到 B 的報(bào)文段中，源端口號(hào)會(huì)作為 返回地址 的一部分，即當(dāng) B 需要回發(fā)一個(gè)報(bào)文段給 A 時(shí)，B 需要從 A 到 B 中的源端口號(hào)取值，如下圖所示

面向連接的多路復(fù)用與多路分解

如果說無連接的多路復(fù)用和多路分解指的是 UDP 的話，那么面向連接的多路復(fù)用與多路分解指的是 TCP 了，TCP 和 UDP 在報(bào)文結(jié)構(gòu)上的差別是，UDP 是一個(gè)二元組而 TCP 是一個(gè)四元組，即源 IP 地址、目標(biāo) IP 地址、源端口號(hào)、目標(biāo)端口號(hào) ，這個(gè)我們上面也提到了。當(dāng)一個(gè) TCP 報(bào)文段從網(wǎng)絡(luò)到達(dá)一臺(tái)主機(jī)時(shí)，這個(gè)主機(jī)會(huì)根據(jù)這四個(gè)值拆解到對(duì)應(yīng)的套接字上。

上圖顯示了面向連接的多路復(fù)用和多路分解的過程，圖中主機(jī) C 向主機(jī) B 發(fā)起了兩個(gè) HTTP 請(qǐng)求，主機(jī) A 向主機(jī) C 發(fā)起了一個(gè) HTTP 請(qǐng)求，主機(jī) A、B、C 都有自己唯一的 IP 地址，當(dāng)主機(jī) C 發(fā)出 HTTP 請(qǐng)求后，主機(jī) B 能夠分解這兩個(gè) HTTP 連接，因?yàn)橹鳈C(jī) C 發(fā)出請(qǐng)求的兩個(gè)源端口號(hào)不同，所以對(duì)于主機(jī) B 來說，這是兩條請(qǐng)求，主機(jī) B 能夠進(jìn)行分解。對(duì)于主機(jī) A 和主機(jī) C 來說，這兩個(gè)主機(jī)有不同的 IP 地址，所以對(duì)于主機(jī) B 來說，也能夠進(jìn)行分解。

UDP

終于，我們開始了對(duì) UDP 協(xié)議的探討，淦起!

UDP 的全稱是 用戶數(shù)據(jù)報(bào)協(xié)議(UDP，User Datagram Protocol)，UDP 為應(yīng)用程序提供了一種無需建立連接就可以發(fā)送封裝的 IP 數(shù)據(jù)包的方法。如果應(yīng)用程序開發(fā)人員選擇的是 UDP 而不是 TCP 的話，那么該應(yīng)用程序相當(dāng)于就是和 IP 直接打交道的。

從應(yīng)用程序傳遞過來的數(shù)據(jù)，會(huì)附加上多路復(fù)用/多路分解的源和目的端口號(hào)字段，以及其他字段，然后將形成的報(bào)文傳遞給網(wǎng)絡(luò)層，網(wǎng)絡(luò)層將運(yùn)輸層報(bào)文段封裝到 IP 數(shù)據(jù)報(bào)中，然后盡力而為的交付給目標(biāo)主機(jī)。最關(guān)鍵的一點(diǎn)就是，使用 UDP 協(xié)議在將數(shù)據(jù)報(bào)傳遞給目標(biāo)主機(jī)時(shí)，發(fā)送方和接收方的運(yùn)輸層實(shí)體間是沒有握手的。正因?yàn)槿绱?，UDP 被稱為是無連接的協(xié)議。

UDP 特點(diǎn)

UDP 協(xié)議一般作為流媒體應(yīng)用、語音交流、視頻會(huì)議所使用的傳輸層協(xié)議，我們大家都知道的 DNS 協(xié)議底層也使用了 UDP 協(xié)議，這些應(yīng)用或協(xié)議之所以選擇 UDP 主要是因?yàn)橐韵逻@幾點(diǎn)

• 速度快，采用 UDP 協(xié)議時(shí)，只要應(yīng)用進(jìn)程將數(shù)據(jù)傳給 UDP，UDP 就會(huì)將此數(shù)據(jù)打包進(jìn) UDP 報(bào)文段并立刻傳遞給網(wǎng)絡(luò)層，然后 TCP 有擁塞控制的功能，它會(huì)在發(fā)送前判斷互聯(lián)網(wǎng)的擁堵情況，如果互聯(lián)網(wǎng)極度阻塞，那么就會(huì)抑制 TCP 的發(fā)送方。使用 UDP 的目的就是希望實(shí)時(shí)性。
• 無須建立連接，TCP 在數(shù)據(jù)傳輸之前需要經(jīng)過三次握手的操作，而 UDP 則無須任何準(zhǔn)備即可進(jìn)行數(shù)據(jù)傳輸。因此 UDP 沒有建立連接的時(shí)延。如果使用 TCP 和 UDP 來比喻開發(fā)人員：TCP 就是那種凡事都要設(shè)計(jì)好，沒設(shè)計(jì)不會(huì)進(jìn)行開發(fā)的工程師，需要把一切因素考慮在內(nèi)后再開干!所以非?？孔V;而 UDP 就是那種上來直接干干干，接到項(xiàng)目需求馬上就開干，也不管設(shè)計(jì)，也不管技術(shù)選型，就是干，這種開發(fā)人員非常不靠譜，但是適合快速迭代開發(fā)，因?yàn)榭梢择R上上手!
• 無連接狀態(tài)，TCP 需要在端系統(tǒng)中維護(hù)連接狀態(tài)，連接狀態(tài)包括接收和發(fā)送緩存、擁塞控制參數(shù)以及序號(hào)和確認(rèn)號(hào)的參數(shù)，在 UDP 中沒有這些參數(shù)，也沒有發(fā)送緩存和接受緩存。因此，某些專門用于某種特定應(yīng)用的服務(wù)器當(dāng)應(yīng)用程序運(yùn)行在 UDP 上，一般能支持更多的活躍用戶
• 分組首部開銷小，每個(gè) TCP 報(bào)文段都有 20 字節(jié)的首部開銷，而 UDP 僅僅只有 8 字節(jié)的開銷。

這里需要注意一點(diǎn)，并不是所有使用 UDP 協(xié)議的應(yīng)用層都是不可靠的，應(yīng)用程序可以自己實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸，通過增加確認(rèn)和重傳機(jī)制。所以使用 UDP 協(xié)議最大的特點(diǎn)就是速度快。

UDP 報(bào)文結(jié)構(gòu)

下面來一起看一下 UDP 的報(bào)文結(jié)構(gòu)，每個(gè) UDP 報(bào)文分為 UDP 報(bào)頭和 UDP 數(shù)據(jù)區(qū)兩部分。報(bào)頭由 4 個(gè) 16 位長(zhǎng)(2 字節(jié))字段組成，分別說明該報(bào)文的源端口、目的端口、報(bào)文長(zhǎng)度和校驗(yàn)值。

• 源端口號(hào)(Source Port) :這個(gè)字段占據(jù) UDP 報(bào)文頭的前 16 位，通常包含發(fā)送數(shù)據(jù)報(bào)的應(yīng)用程序所使用的 UDP 端口。接收端的應(yīng)用程序利用這個(gè)字段的值作為發(fā)送響應(yīng)的目的地址。這個(gè)字段是可選項(xiàng)，有時(shí)不會(huì)設(shè)置源端口號(hào)。沒有源端口號(hào)就默認(rèn)為 0 ，通常用于不需要返回消息的通信中。
• 目標(biāo)端口號(hào)(Destination Port): 表示接收端端口，字段長(zhǎng)為 16 位
• 長(zhǎng)度(Length): 該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報(bào)長(zhǎng)度，包含 UDP 報(bào)文頭和 UDP 數(shù)據(jù)長(zhǎng)度。因?yàn)?UDP 報(bào)文頭長(zhǎng)度是 8 個(gè)字節(jié)，所以這個(gè)值最小為 8，最大長(zhǎng)度為 65535 字節(jié)。
• 校驗(yàn)和(Checksum)：UDP 使用校驗(yàn)和來保證數(shù)據(jù)安全性，UDP 的校驗(yàn)和也提供了差錯(cuò)檢測(cè)功能，差錯(cuò)檢測(cè)用于校驗(yàn)報(bào)文段從源到目標(biāo)主機(jī)的過程中，數(shù)據(jù)的完整性是否發(fā)生了改變。發(fā)送方的 UDP 對(duì)報(bào)文段中的 16 比特字的和進(jìn)行反碼運(yùn)算，求和時(shí)遇到的位溢出都會(huì)被忽略，比如下面這個(gè)例子，三個(gè) 16 比特的數(shù)字進(jìn)行相加

這些 16 比特的前兩個(gè)和是

然后再將上面的結(jié)果和第三個(gè) 16 比特的數(shù)進(jìn)行相加

最后一次相加的位會(huì)進(jìn)行溢出，溢出位 1 要被舍棄，然后進(jìn)行反碼運(yùn)算，反碼運(yùn)算就是將所有的 1 變?yōu)?0 ，0 變?yōu)?1。因此 1000 0100 1001 0101 的反碼就是 0111 1011 0110 1010，這就是校驗(yàn)和，如果在接收方，數(shù)據(jù)沒有出現(xiàn)差錯(cuò)，那么全部的 4 個(gè) 16 比特的數(shù)值進(jìn)行運(yùn)算，同時(shí)也包括校驗(yàn)和，如果最后結(jié)果的值不是 1111 1111 1111 1111 的話，那么就表示傳輸過程中的數(shù)據(jù)出現(xiàn)了差錯(cuò)。

下面來想一個(gè)問題，為什么 UDP 會(huì)提供差錯(cuò)檢測(cè)的功能?

這其實(shí)是一種 端到端 的設(shè)計(jì)原則，這個(gè)原則說的是要讓傳輸中各種錯(cuò)誤發(fā)生的概率降低到一個(gè)可以接受的水平。

文件從主機(jī)A傳到主機(jī)B，也就是說AB主機(jī)要通信，需要經(jīng)過三個(gè)環(huán)節(jié)：首先是主機(jī)A從磁盤上讀取文件并將數(shù)據(jù)分組成一個(gè)個(gè)數(shù)據(jù)包packet,，然后數(shù)據(jù)包通過連接主機(jī)A和主機(jī)B的網(wǎng)絡(luò)傳輸?shù)街鳈C(jī)B，最后是主機(jī)B收到數(shù)據(jù)包并將數(shù)據(jù)包寫入磁盤。在這個(gè)看似簡(jiǎn)單其實(shí)很復(fù)雜的過程中可能會(huì)由于某些原因而影響正常通信。比如：磁盤上文件讀寫錯(cuò)誤、緩沖溢出、內(nèi)存出錯(cuò)、網(wǎng)絡(luò)擁擠等等這些因素都有可能導(dǎo)致數(shù)據(jù)包的出錯(cuò)或者丟失，由此可見用于通信的網(wǎng)絡(luò)是不可靠的。

由于實(shí)現(xiàn)通信只要經(jīng)過上述三個(gè)環(huán)節(jié)，那么我們就想是否在其中某個(gè)環(huán)節(jié)上增加一個(gè)檢錯(cuò)糾錯(cuò)機(jī)制來用于對(duì)信息進(jìn)行把關(guān)呢?

網(wǎng)絡(luò)層肯定不能做這件事，因?yàn)榫W(wǎng)絡(luò)層的最主要目的是增大數(shù)據(jù)傳輸?shù)乃俾?，網(wǎng)絡(luò)層不需要考慮數(shù)據(jù)的完整性，數(shù)據(jù)的完整性和正確性交給端系統(tǒng)去檢測(cè)就行了，因此在數(shù)據(jù)傳輸中，對(duì)于網(wǎng)絡(luò)層只能要求其提供盡可能好的數(shù)據(jù)傳輸服務(wù)，而不可能寄希望于網(wǎng)絡(luò)層提供數(shù)據(jù)完整性的服務(wù)。

UDP 不可靠的原因是它雖然提供差錯(cuò)檢測(cè)的功能，但是對(duì)于差錯(cuò)沒有恢復(fù)能力更不會(huì)有重傳機(jī)制。

本文轉(zhuǎn)載自微信公眾號(hào)「 程序員cxuan」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 程序員cxuan公眾號(hào)。