從本章開始，我們開始介紹最重要的傳輸層。傳輸層位于 OSI 七層模型的第四層（由下往上）。顧名思義，傳輸層的主要作用是實現(xiàn)應(yīng)用程序之間的通信。網(wǎng)絡(luò)層主要是保證不同數(shù)據(jù)鏈路下數(shù)據(jù)的可達(dá)性，至于如何傳輸數(shù)據(jù)則是由傳輸層負(fù)責(zé)。

傳輸層協(xié)議簡介

常見的傳輸層協(xié)議主要有 TCP 協(xié)議和 UDP 協(xié)議。TCP 協(xié)議是面向有連接的協(xié)議，也就是說在使用 TCP 協(xié)議傳輸數(shù)據(jù)之前一定要在發(fā)送方和接收方之間建立連接。一般情況下建立連接需要三步，關(guān)閉連接需要四步。

建立 TCP 連接后，由于有數(shù)據(jù)重傳、流量控制等功能，TCP 協(xié)議能夠正確處理丟包問題，保證接收方能夠收到數(shù)據(jù)，與此同時還能夠有效利用網(wǎng)絡(luò)帶寬。然而 TCP 協(xié)議中定義了很多復(fù)雜的規(guī)范，因此效率不如 UDP 協(xié)議，不適合實時的視頻和音頻傳輸。

UDP 協(xié)議是面向無連接的協(xié)議，它只會把數(shù)據(jù)傳遞給接收端，但是不會關(guān)注接收端是否真的收到了數(shù)據(jù)。但是這種特性反而適合多播，實時的視頻和音頻傳輸。因為個別數(shù)據(jù)包的丟失并不會影響視頻和音頻的整體效果。

IP 協(xié)議中的兩大關(guān)鍵要素是源 IP 地址和目標(biāo) IP 地址。而剛剛我們說過，傳輸層的主要作用是實現(xiàn)應(yīng)用程序之間的通信。因此傳輸層的協(xié)議中新增了三個要素：源端口號，目標(biāo)端口號和協(xié)議號。通過這五個信息，可以唯一識別一個通信。

不同的端口用于區(qū)分同一臺主機(jī)上不同的應(yīng)用程序。假設(shè)你打開了兩個瀏覽器，瀏覽器 A 發(fā)出的請求不會被瀏覽器 B 接收，這就是因為 A 和 B 具有不同的端口。

協(xié)議號用于區(qū)分使用的是 TCP 還是 UDP。因此相同兩臺主機(jī)上，相同的兩個進(jìn)程之間的通信，在分別使用 TCP 協(xié)議和 UDP 協(xié)議時也可以被正確的區(qū)分開來。

用一句話來概括就是：“源 IP 地址，目標(biāo) IP 地址，源端口號，目標(biāo)端口號和協(xié)議號”這五個信息只要有一個不同，都被認(rèn)為是不同的通信。

UDP 首部

UDP 協(xié)議最大的特點(diǎn)就是簡單，它的首部如下圖所示：

UPD 首部

包長度表示 UDP 首部的長度和 UPD 數(shù)據(jù)長度之和。

校驗和用來判斷數(shù)據(jù)在傳輸過程中是否損壞。計算這個校驗和的時候，不僅考慮源端口號和目標(biāo)端口號，還要考慮 IP 首部中的源 IP 地址，目標(biāo) IP 地址和協(xié)議號（這些又稱為 UDP 偽首部）。這是因為以上五個要素用于識別通信時缺一不可，如果校驗和只考慮端口號，那么另外三個要素收到破壞時，應(yīng)用就無法得知。這有可能導(dǎo)致不該收到包的應(yīng)用收到了包，改收到包的應(yīng)用反而沒有收到。

這個概念同樣適用于即將介紹的 TCP 首部。

TCP 首部

和 UDP 首部相比，TCP 首部要復(fù)雜得多。解析這個首部的時間也相應(yīng)的會增加，這是導(dǎo)致 TCP 連接的效率低于 UDP 的原因之一。

TCP 首部

其中某些關(guān)鍵字段解釋如下：

• 序列號：它表示發(fā)送數(shù)據(jù)的位置，假設(shè)當(dāng)前的序列號為 s，發(fā)送數(shù)據(jù)長度為 l，則下次發(fā)送數(shù)據(jù)時的序列號為 s + l。在建立連接時通常由計算機(jī)生成一個隨機(jī)數(shù)作為序列號的初始值。

• 確認(rèn)應(yīng)答號：它等于下一次應(yīng)該接收到的數(shù)據(jù)的序列號。假設(shè)發(fā)送端的序列號為 s，發(fā)送數(shù)據(jù)的長度為 l，那么接收端返回的確認(rèn)應(yīng)答號也是 s + l。發(fā)送端接收到這個確認(rèn)應(yīng)答后，可以認(rèn)為這個位置以前所有的數(shù)據(jù)都已被正常接收。

• 數(shù)據(jù)偏移：TCP 首部的長度，單位為 4 字節(jié)。如果沒有可選字段，那么這里的值就是 5。表示 TCP 首部的長度為 20 字節(jié)。

• 控制位：改字段長度為 8 比特，分別有 8 個控制標(biāo)志。依次是 CWR，ECE，URG，ACK，PSH，RST，SYN 和 FIN。在后續(xù)的文章中你會陸續(xù)接觸到其中的某些控制位。

• 窗口大小：用于表示從應(yīng)答號開始能夠接受多少個 8 位字節(jié)。如果窗口大小為 0，可以發(fā)送窗口探測。

• 緊急指針：盡在 URG 控制位為 1 時有效。表示緊急數(shù)據(jù)的末尾在 TCP 數(shù)據(jù)部分中的位置。通常在暫時中斷通信時使用（比如輸入 Ctrl + C）。

TCP 握手

TCP 是面向有連接的協(xié)議，連接在每次通信前被建立，通信結(jié)束后被關(guān)閉。了解連接建立和關(guān)閉的過程通常是考察的重點(diǎn)。連接的建立和關(guān)閉過程可以用一張圖來表示：

TCP 連接建立和關(guān)閉

通常情況下，我們認(rèn)為客戶端首先發(fā)起連接。

三次握手建立連接

這個過程可以用以下三句形象的對話表示：

（客戶端）：我要建立連接了。

（服務(wù)端）：我知道你要建立連接了，我這邊沒有問題。

（客戶端）：我知道你知道我要建立連接了，接下來我們就正式開始通信。

為什么是三次握手

根據(jù)一般的思路，我們可能會覺得只要兩次握手就可以了，第三步確認(rèn)看似是多余的。那么 TCP 協(xié)議為什么還要費(fèi)力不討好的加上這一次握手呢？

這是因為在網(wǎng)絡(luò)請求中，我們應(yīng)該時刻記住：“網(wǎng)絡(luò)是不可靠的，數(shù)據(jù)包是可能丟失的”。假設(shè)沒有第三次確認(rèn)，客戶端向服務(wù)端發(fā)送了 SYN，請求建立連接。由于延遲，服務(wù)端沒有及時收到這個包。于是客戶端重新發(fā)送一個 SYN 包。回憶一下介紹 TCP 首部時提到的序列號，這兩個包的序列號顯然是相同的。

假設(shè)服務(wù)端接收到了第二個 SYN 包，建立了通信，一段時間后通信結(jié)束，連接被關(guān)閉。這時候最初被發(fā)送的 SYN 包剛剛抵達(dá)服務(wù)端，服務(wù)端又會發(fā)送一次 ACK 確認(rèn)。由于兩次握手就建立了連接，此時的服務(wù)端就會建立一個新的連接，然而客戶端覺得自己并沒有請求建立連接，所以就不會向服務(wù)端發(fā)送數(shù)據(jù)。從而導(dǎo)致服務(wù)端建立了一個空的連接，白白浪費(fèi)資源。

在三次握手的情況下，服務(wù)端直到收到客戶端的應(yīng)答后才會建立連接。因此在上述情況下，客戶端會接受到一個相同的 ACK 包，這時候它會拋棄這個數(shù)據(jù)包，不會和服務(wù)端進(jìn)行第三次握手，因此避免了服務(wù)端建立空的連接。

ACK 確認(rèn)包丟失怎么辦

三次握手其實解決了第二步的數(shù)據(jù)包丟失問題。那么第三步的 ACK 確認(rèn)丟失后，TCP 協(xié)議是如何處理的呢？

按照 TCP 協(xié)議處理丟包的一般方法，服務(wù)端會重新向客戶端發(fā)送數(shù)據(jù)包，直至收到 ACK 確認(rèn)為止。但實際上這種做法有可能遭到 SYN 泛洪攻擊。所謂的泛洪攻擊，是指發(fā)送方偽造多個 IP 地址，模擬三次握手的過程。當(dāng)服務(wù)器返回 ACK 后，攻擊方故意不確認(rèn)，從而使得服務(wù)器不斷重發(fā) ACK。由于服務(wù)器長時間處于半連接狀態(tài)，最后消耗過多的 CPU 和內(nèi)存資源導(dǎo)致死機(jī)。

正確處理方法是服務(wù)端發(fā)送 RST 報文，進(jìn)入 CLOSE 狀態(tài)。這個 RST 數(shù)據(jù)包的 TCP 首部中，控制位中的 RST 位被設(shè)置為 1。這表示連接信息全部被初始化，原有的 TCP 通信不能繼續(xù)進(jìn)行。客戶端如果還想重新建立 TCP 連接，就必須重新開始第一次握手。

四次握手關(guān)閉連接

這個過程可以用以下四句形象的對話表示：

（客戶端）：我要關(guān)閉連接了。

（服務(wù)端）：你那邊的連接可以關(guān)閉了。

（服務(wù)端）：我這邊也要關(guān)閉連接了。

（客戶端）：你那邊的連接可以關(guān)閉了。

由于連接是雙向的，所以雙方都要主動關(guān)閉自己這一側(cè)的連接。

關(guān)閉連接的最后一個 ACK 丟失怎么辦

實際上，在第三步中，客戶端收到 FIN 包時，它會設(shè)置一個計時器，等待相當(dāng)長的一段時間。如果客戶端返回的 ACK 丟失，那么服務(wù)端還會重發(fā) FIN 并重置計時器。假設(shè)在計時器失效前服務(wù)器重發(fā)的 FIN 包沒有到達(dá)客戶端，客戶端就會進(jìn)入 CLOSE 狀態(tài)，從而導(dǎo)致服務(wù)端永遠(yuǎn)無法收到 ACK 確認(rèn)，也就無法關(guān)閉連接。

示意圖如下：

TCP 關(guān)閉連接

文／bestswifter（簡書作者）
原文鏈接：http://www.jianshu.com/p/dc456cf57e06
著作權(quán)歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，并標(biāo)注“簡書作者”。

總結(jié)

以上是生活随笔為你收集整理的TCP/IP（四）：TCP 与 UDP 协议简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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