[[353775]]

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

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

運輸層概述

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

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

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

TCP 如何判斷是哪個端口的呢?

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

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

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

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

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

TCP 和 UDP 前置知識

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

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

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

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

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

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

套接字

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

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

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

套接字類型

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

• 數(shù)據(jù)報套接字(Datagram sockets)：數(shù)據(jù)報套接字提供一種無連接的服務(wù)，而且并不能保證數(shù)據(jù)傳輸?shù)目煽啃?。?shù)據(jù)有可能在傳輸過程中丟失或出現(xiàn)數(shù)據(jù)重復(fù)，且無法保證順序地接收到數(shù)據(jù)。數(shù)據(jù)報套接字使用UDP( User DatagramProtocol)協(xié)議進(jìn)行數(shù)據(jù)的傳輸。由于數(shù)據(jù)報套接字不能保證數(shù)據(jù)傳輸?shù)目煽啃裕瑢τ谟锌赡艹霈F(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ī)網(wǎng)絡(luò)中，要想實現(xiàn)通信，必須至少需要兩個端系統(tǒng)，至少需要一對兩個套接字才行。下面是套接字的通信過程。

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

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

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

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

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

聊聊 IP

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

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

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

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

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

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

端口號

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

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

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

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

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

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

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

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

所以僅憑端口號來確定某一條報文顯然是不夠的。

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

確定端口號

在實際通信之前，需要先確定一下端口號，確定端口號的方法分為兩種：

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

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

時序分配的端口號

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

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

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

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

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

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

UDP 套接字就是一個二元組，二元組包含目的 IP 地址和目的端口號。

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

這里思考一個問題，主機(jī) A 給主機(jī) B 發(fā)送一個消息，為什么還需要知道源端口號呢?比如我給妹子表達(dá)出我對你有點意思的信息，妹子還需要知道這個信息是從我的哪個器官發(fā)出的嗎?知道是我這個人對你有點意思不就完了?實際上是需要的，因為妹子如果要表達(dá)出她對你也有點意思，她是不是可能會親你一口，那她得知道往哪親吧?

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

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

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

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

UDP

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

UDP 的全稱是 用戶數(shù)據(jù)報協(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ù)，會附加上多路復(fù)用/多路分解的源和目的端口號字段，以及其他字段，然后將形成的報文傳遞給網(wǎng)絡(luò)層，網(wǎng)絡(luò)層將運輸層報文段封裝到 IP 數(shù)據(jù)報中，然后盡力而為的交付給目標(biāo)主機(jī)。最關(guān)鍵的一點就是，使用 UDP 協(xié)議在將數(shù)據(jù)報傳遞給目標(biāo)主機(jī)時，發(fā)送方和接收方的運輸層實體間是沒有握手的。正因為如此，UDP 被稱為是無連接的協(xié)議。

UDP 特點

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

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

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

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

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

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

這些 16 比特的前兩個和是

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

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

下面來想一個問題，為什么 UDP 會提供差錯檢測的功能?

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

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

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

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

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

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