40張圖帶你搞懂TCP和UDP
前言
拿下計(jì)網(wǎng)協(xié)議后，我就是公園里最靚的仔
TCP/IP 基礎(chǔ)知識總結(jié)
計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)知識總結(jié)
那么下面就開始我們本篇文章，文章組織脈絡(luò)如下
運(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ùn)輸層運(yùn)輸報(bào)文的過程中，會遵守一定的協(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)的。路由只是做識別地址并轉(zhuǎn)發(fā)的功能。這就比如快遞員送快遞一樣，當(dāng)然是要由地址的接受人也就是 xxx 號樓 xxx 單元 xxx 室的這個(gè)人來判斷了！
TCP 如何判斷是哪個(gè)端口的呢？
還記得數(shù)據(jù)包的結(jié)構(gòu)嗎，這里來回顧一下
數(shù)據(jù)包經(jīng)過每層后，該層協(xié)議都會在數(shù)據(jù)包附上包首部，一個(gè)完整的包首部圖如上所示。
在數(shù)據(jù)傳輸?shù)竭\(yùn)輸層后，會為其附上 TCP 首部，首部包含著源端口號和目的端口號。
在發(fā)送端，運(yùn)輸層將從發(fā)送應(yīng)用程序進(jìn)程接收到的報(bào)文轉(zhuǎn)化成運(yùn)輸層分組，分組在計(jì)算機(jī)網(wǎng)絡(luò)中也稱為?報(bào)文段(segment)。運(yùn)輸層一般會將報(bào)文段進(jìn)行分割，分割成為較小的塊，為每一塊加上運(yùn)輸層首部并將其向目的地發(fā)送。
在發(fā)送過程中，可選的運(yùn)輸層協(xié)議(也就是交通工具) 主要有?TCP?和?UDP?，關(guān)于這兩種運(yùn)輸協(xié)議的選擇及其特性也是我們著重探討的重點(diǎn)。
TCP 和 UDP 前置知識
在 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ù)語對一個(gè)數(shù)據(jù)的描述這么多啊？
在計(jì)算機(jī)網(wǎng)絡(luò)中，在不同層之間會有不同的描述。我們上面提到會將運(yùn)輸層的分組稱為報(bào)文段，除此之外，還會將 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í)，會廣泛用到套接字的 API，使用這套 API 設(shè)置 IP 地址、端口號，實(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ù)目煽啃?，對于有可能出現(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)，至少需要一對兩個(gè)套接字才行。下面是套接字的通信過程。
socket 中的 API 用于創(chuàng)建通信鏈路中的端點(diǎn)，創(chuàng)建完成后，會返回描述該套接字的
套接字描述符。
就像使用文件描述符來訪問文件一樣，套接字描述符用來訪問套接字。
當(dāng)應(yīng)用程序具有套接字描述符后，它可以將唯一的名稱綁定在套接字上，服務(wù)器必須綁定一個(gè)名稱才能在網(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ù)器或客戶端要停止操作時(shí)，就會調(diào)用?
close?API 釋放套接字獲取的所有系統(tǒng)資源。
雖然套接字 API 位于應(yīng)用程序?qū)雍蛡鬏攲又g的通信模型中，但是套接字 API 不屬于通信模型。套接字 API 允許應(yīng)用程序與傳輸層和網(wǎng)絡(luò)層進(jìn)行交互。
在往下繼續(xù)聊之前，我們先播放一個(gè)小插曲，簡單聊一聊 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)
對應(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)性、簡潔性和可操作性，并在可靠性做了一定的犧牲。IP 不保證分組的交付時(shí)限和可靠性，所傳送分組有可能出現(xiàn)丟失、重復(fù)、延遲或亂序等問題。
我們知道，TCP 協(xié)議的下一層就是 IP 協(xié)議層，既然 IP 不可靠，那么如何保證數(shù)據(jù)能夠準(zhǔn)確無誤地到達(dá)呢？
這就涉及到 TCP 傳輸機(jī)制的問題了，我們后面聊到 TCP 的時(shí)候再說。
端口號
在聊端口號前，先來聊一聊文件描述以及 socket 和端口號的關(guān)系
為了方便資源的使用，提高機(jī)器的性能、利用率和穩(wěn)定性等等原因，我們的計(jì)算機(jī)都有一層軟件叫做操作系統(tǒng)，它用于幫我們管理計(jì)算機(jī)可以使用的資源，當(dāng)我們的程序要使用一個(gè)資源的時(shí)候，可以向操作系統(tǒng)申請，再由操作系統(tǒng)為我們的程序分配和管理資源。通常當(dāng)我們要訪問一個(gè)內(nèi)核設(shè)備或文件時(shí)，程序可以調(diào)用系統(tǒng)函數(shù)，系統(tǒng)就會為我們打開設(shè)備或文件，然后返回一個(gè)文件描述符fd（或稱為ID，是一個(gè)整數(shù)），我們要訪問該設(shè)備或文件，只能通過該文件描述符。可以認(rèn)為該編號對應(yīng)著打開的文件或設(shè)備。
而當(dāng)我們的程序要使用網(wǎng)絡(luò)時(shí)，要使用到對應(yīng)的操作系統(tǒng)內(nèi)核的操作和網(wǎng)卡設(shè)備，所以我們可以向操作系統(tǒng)申請，然后系統(tǒng)會為我們創(chuàng)建一個(gè)套接字 Socket，并返回這個(gè) Socket 的ID，以后我們的程序要使用網(wǎng)絡(luò)資源，只要向這個(gè) Socket 的編號 ID 操作即可。而我們的每一個(gè)網(wǎng)絡(luò)通信的進(jìn)程至少對應(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)識符——文件描述符 fd。
端口號是?16?位的非負(fù)整數(shù)，它的范圍是 0 - 65535 之間，這個(gè)范圍會分為三種不同的端口號段，由 Internet 號碼分配機(jī)構(gòu) IANA 進(jìn)行分配
周知/標(biāo)準(zhǔn)端口號，它的范圍是 0 - 1023
注冊端口號，范圍是 1024 - 49151
私有端口號，范圍是 49152 - 6553
一臺計(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ù)器的呢？
是憑借端口號嗎？當(dāng)報(bào)文到達(dá)服務(wù)器時(shí)，是端口號來區(qū)分不同應(yīng)用程序的，所以應(yīng)該借助端口號來區(qū)分。
舉個(gè)例子反駁一下 cxuan，假如到達(dá)服務(wù)器的兩條數(shù)據(jù)都是由 80 端口發(fā)出的你該如何區(qū)分呢？或者說到達(dá)服務(wù)器的兩條數(shù)據(jù)端口一樣，協(xié)議不同，該如何區(qū)分呢？
所以僅憑端口號來確定某一條報(bào)文顯然是不夠的。
互聯(lián)網(wǎng)上一般使用?源 IP 地址、目標(biāo) IP 地址、源端口號、目標(biāo)端口號?來進(jìn)行區(qū)分。如果其中的某一項(xiàng)不同，就被認(rèn)為是不同的報(bào)文段。這些也是多路分解和多路復(fù)用?的基礎(chǔ)。
確定端口號
在實(shí)際通信之前，需要先確定一下端口號，確定端口號的方法分為兩種：
標(biāo)準(zhǔn)既定的端口號
標(biāo)準(zhǔn)既定的端口號是靜態(tài)分配的，每個(gè)程序都會有自己的端口號，每個(gè)端口號都有不同的用途。端口號是一個(gè) 16 比特的數(shù)，其大小在 0 - 65535 之間，0 - 1023 范圍內(nèi)的端口號都是動(dòng)態(tài)分配的既定端口號，例如 HTTP 使用 80 端口來標(biāo)識，F(xiàn)TP 使用 21 端口來標(biāo)識，SSH 使用 22 來標(biāo)識。這類端口號有一個(gè)特殊的名字，叫做?周知端口號(Well-Known Port Number)。
時(shí)序分配的端口號
第二種分配端口號的方式是一種動(dòng)態(tài)分配法，在這種方法下，客戶端應(yīng)用程序可以完全不用自己設(shè)置端口號，憑借操作系統(tǒng)進(jìn)行分配，操作系統(tǒng)可以為每個(gè)應(yīng)用程序分配互不沖突的端口號。這種動(dòng)態(tài)分配端口號的機(jī)制即使是同一個(gè)客戶端發(fā)起的 TCP 連接，也能識別不同的連接。
多路復(fù)用和多路分解
我們上面聊到了在主機(jī)上的每個(gè)套接字都會分配一個(gè)端口號，當(dāng)報(bào)文段到達(dá)主機(jī)時(shí)，運(yùn)輸層會檢查報(bào)文段中的目的端口號，并將其定向到相應(yīng)的套接字，然后報(bào)文段中的數(shù)據(jù)通過套接字進(jìn)入其所連接的進(jìn)程。下面我們來聊一下什么是多路復(fù)用和多路分解的概念。
多路復(fù)用和多路分解分為兩種，即無連接的多路復(fù)用(多路分解)和面向連接的多路復(fù)用(多路分解)
無連接的多路復(fù)用和多路分解
開發(fā)人員會編寫代碼確定端口號是周知端口號還是時(shí)序分配的端口號。假如主機(jī) A 中的一個(gè) 10637 端口要向主機(jī) B 中的 45438 端口發(fā)送數(shù)據(jù)，運(yùn)輸層采用的是?UDP?協(xié)議，數(shù)據(jù)在應(yīng)用層產(chǎn)生后，會在運(yùn)輸層中加工處理，然后在網(wǎng)絡(luò)層將數(shù)據(jù)封裝得到 IP 數(shù)據(jù)報(bào)，IP 數(shù)據(jù)包通過鏈路層盡力而為的交付給主機(jī) B，然后主機(jī) B 會檢查報(bào)文段中的端口號判斷是哪個(gè)套接字的，這一系列的過程如下所示
UDP 套接字就是一個(gè)二元組，二元組包含目的 IP 地址和目的端口號。
所以，如果兩個(gè) UDP 報(bào)文段有不同的源 IP 地址和/或相同的源端口號，但是具有相同的目的 IP 地址和目的端口號，那么這兩個(gè)報(bào)文會通過套接字定位到相同的目的進(jìn)程。
這里思考一個(gè)問題，主機(jī) A 給主機(jī) B 發(fā)送一個(gè)消息，為什么還需要知道源端口號呢？比如我給妹子表達(dá)出我對你有點(diǎn)意思的信息，妹子還需要知道這個(gè)信息是從我的哪個(gè)器官發(fā)出的嗎？知道是我這個(gè)人對你有點(diǎn)意思不就完了？實(shí)際上是需要的，因?yàn)槊米尤绻磉_(dá)出她對你也有點(diǎn)意思，她是不是可能會親你一口，那她得知道往哪親吧？
這就是，在 A 到 B 的報(bào)文段中，源端口號會作為?返回地址?的一部分，即當(dāng) B 需要回發(fā)一個(gè)報(bào)文段給 A 時(shí)，B 需要從 A 到 B 中的源端口號取值，如下圖所示
面向連接的多路復(fù)用與多路分解
如果說無連接的多路復(fù)用和多路分解指的是 UDP 的話，那么面向連接的多路復(fù)用與多路分解指的是 TCP 了，TCP 和 UDP 在報(bào)文結(jié)構(gòu)上的差別是，UDP 是一個(gè)二元組而 TCP 是一個(gè)四元組，即源 IP 地址、目標(biāo) IP 地址、源端口號、目標(biāo)端口號?，這個(gè)我們上面也提到了。當(dāng)一個(gè) TCP 報(bào)文段從網(wǎng)絡(luò)到達(dá)一臺主機(jī)時(shí)，這個(gè)主機(jī)會根據(jù)這四個(gè)值拆解到對應(yīng)的套接字上。
上圖顯示了面向連接的多路復(fù)用和多路分解的過程，圖中主機(jī) C 向主機(jī) B 發(fā)起了兩個(gè) HTTP 請求，主機(jī) A 向主機(jī) C 發(fā)起了一個(gè) HTTP 請求，主機(jī) A、B、C 都有自己唯一的 IP 地址，當(dāng)主機(jī) C 發(fā)出 HTTP 請求后，主機(jī) B 能夠分解這兩個(gè) HTTP 連接，因?yàn)橹鳈C(jī) C 發(fā)出請求的兩個(gè)源端口號不同，所以對于主機(jī) B 來說，這是兩條請求，主機(jī) B 能夠進(jìn)行分解。對于主機(jī) A 和主機(jī) C 來說，這兩個(gè)主機(jī)有不同的 IP 地址，所以對于主機(jī) B 來說，也能夠進(jìn)行分解。
UDP
終于，我們開始了對 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ù)，會附加上多路復(fù)用/多路分解的源和目的端口號字段，以及其他字段，然后將形成的報(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)槿绱耍琔DP 被稱為是無連接的協(xié)議。
UDP 特點(diǎn)
UDP 協(xié)議一般作為流媒體應(yīng)用、語音交流、視頻會議所使用的傳輸層協(xié)議，我們大家都知道的 DNS 協(xié)議底層也使用了 UDP 協(xié)議，這些應(yīng)用或協(xié)議之所以選擇 UDP 主要是因?yàn)橐韵逻@幾點(diǎn)
速度快，采用 UDP 協(xié)議時(shí)，只要應(yīng)用進(jìn)程將數(shù)據(jù)傳給 UDP，UDP 就會將此數(shù)據(jù)打包進(jìn) UDP 報(bào)文段并立刻傳遞給網(wǎng)絡(luò)層，然后 TCP 有擁塞控制的功能，它會在發(fā)送前判斷互聯(lián)網(wǎng)的擁堵情況，如果互聯(lián)網(wǎng)極度阻塞，那么就會抑制 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ì)不會進(jìn)行開發(fā)的工程師，需要把一切因素考慮在內(nèi)后再開干！所以非常靠譜；而 UDP 就是那種上來直接干干干，接到項(xiàng)目需求馬上就開干，也不管設(shè)計(jì)，也不管技術(shù)選型，就是干，這種開發(fā)人員非常不靠譜，但是適合快速迭代開發(fā)，因?yàn)榭梢择R上上手！無連接狀態(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)用程序運(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 位長（2 字節(jié)）字段組成，分別說明該報(bào)文的源端口、目的端口、報(bào)文長度和校驗(yàn)值。
源端口號(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í)不會設(shè)置源端口號。沒有源端口號就默認(rèn)為 0 ，通常用于不需要返回消息的通信中。目標(biāo)端口號(Destination Port): 表示接收端端口，字段長為 16 位長度(Length): 該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報(bào)長度，包含 UDP 報(bào)文頭和 UDP 數(shù)據(jù)長度。因?yàn)?UDP 報(bào)文頭長度是 8 個(gè)字節(jié)，所以這個(gè)值最小為 8，最大長度為 65535 字節(jié)。校驗(yàn)和(Checksum)：UDP 使用校驗(yàn)和來保證數(shù)據(jù)安全性，UDP 的校驗(yàn)和也提供了差錯(cuò)檢測功能，差錯(cuò)檢測用于校驗(yàn)報(bào)文段從源到目標(biāo)主機(jī)的過程中，數(shù)據(jù)的完整性是否發(fā)生了改變。發(fā)送方的 UDP 對報(bào)文段中的 16 比特字的和進(jìn)行反碼運(yùn)算，求和時(shí)遇到的位溢出都會被忽略，比如下面這個(gè)例子，三個(gè) 16 比特的數(shù)字進(jìn)行相加
這些 16 比特的前兩個(gè)和是
然后再將上面的結(jié)果和第三個(gè) 16 比特的數(shù)進(jìn)行相加
最后一次相加的位會進(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 會提供差錯(cuò)檢測的功能？
這其實(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è)看似簡單其實(shí)很復(fù)雜的過程中可能會由于某些原因而影響正常通信。比如：磁盤上文件讀寫錯(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ī)制來用于對信息進(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)去檢測就行了，因此在數(shù)據(jù)傳輸中，對于網(wǎng)絡(luò)層只能要求其提供盡可能好的數(shù)據(jù)傳輸服務(wù)，而不可能寄希望于網(wǎng)絡(luò)層提供數(shù)據(jù)完整性的服務(wù)。
UDP 不可靠的原因是它雖然提供差錯(cuò)檢測的功能，但是對于差錯(cuò)沒有恢復(fù)能力更不會有重傳機(jī)制。
TCP
UDP 是一種沒有復(fù)雜的控制，提供無連接通信服務(wù)的一種協(xié)議，換句話說，它將部分控制部分交給應(yīng)用程序去處理，自己只提供作為傳輸層協(xié)議最基本的功能。
而與 UDP 不同的是，同樣作為傳輸層協(xié)議，TCP 協(xié)議要比 UDP 的功能多很多。
TCP?的全稱是?Transmission Control Protocol，它被稱為是一種面向連接(connection-oriented)?的協(xié)議，這是因?yàn)橐粋€(gè)應(yīng)用程序開始向另一個(gè)應(yīng)用程序發(fā)送數(shù)據(jù)之前，這兩個(gè)進(jìn)程必須先進(jìn)行握手，握手是一個(gè)邏輯連接，并不是兩個(gè)主機(jī)之間進(jìn)行真實(shí)的握手。
這個(gè)連接是指各種設(shè)備、線路或者網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)應(yīng)用程序?yàn)榱讼嗷鬟f消息而專有的、虛擬的通信鏈路，也叫做虛擬電路。
一旦主機(jī) A 和主機(jī) B 建立了連接，那么進(jìn)行通信的應(yīng)用程序只使用這個(gè)虛擬的通信線路發(fā)送和接收數(shù)據(jù)就可以保證數(shù)據(jù)的傳輸，TCP 協(xié)議負(fù)責(zé)控制連接的建立、斷開、保持等工作。
TCP 連接是全雙工服務(wù)(full-duplex service)?的，全雙工是什么意思？全雙工指的是主機(jī) A 與另外一個(gè)主機(jī) B 存在一條 TCP 連接，那么應(yīng)用程數(shù)據(jù)就可以從主機(jī) B 流向主機(jī) A 的同時(shí)，也從主機(jī) A 流向主機(jī) B。
TCP 只能進(jìn)行?點(diǎn)對點(diǎn)(point-to-point)?連接，那么所謂的多播，即一個(gè)主機(jī)對多個(gè)接收方發(fā)送消息的情況是不存在的，TCP 連接只能連接兩個(gè)一對主機(jī)。
TCP 的連接建立需要經(jīng)過三次握手，這個(gè)我們下面再說。一旦 TCP 連接建立后，主機(jī)之間就可以相互發(fā)送數(shù)據(jù)了，客戶進(jìn)程通過套接字傳送數(shù)據(jù)流。數(shù)據(jù)一旦通過套接字后，它就由客戶中運(yùn)行的 TCP 協(xié)議所控制。
TCP 會將數(shù)據(jù)臨時(shí)存儲到連接的發(fā)送緩存(send buffer)?中，這個(gè) send buffer 是三次握手之間設(shè)置的緩存之一，然后 TCP 在合適的時(shí)間將發(fā)送緩存中的數(shù)據(jù)發(fā)送到目標(biāo)主機(jī)的接收緩存中，實(shí)際上，每一端都會有發(fā)送緩存和接收緩存，如下所示
主機(jī)之間的發(fā)送是以?報(bào)文段(segment)?進(jìn)行的，那么什么是 Segement 呢？
TCP 會將要傳輸?shù)臄?shù)據(jù)流分為多個(gè)塊(chunk)，然后向每個(gè) chunk 中添加 TCP 標(biāo)頭，這樣就形成了一個(gè) TCP 段也就是報(bào)文段。每一個(gè)報(bào)文段可以傳輸?shù)拈L度是有限的，不能超過最大數(shù)據(jù)長度(Maximum Segment Size)，俗稱?MSS。在報(bào)文段向下傳輸?shù)倪^程中，會經(jīng)過鏈路層，鏈路層有一個(gè)?Maximum Transmission Unit?，最大傳輸單元 MTU， 即數(shù)據(jù)鏈路層上所能通過最大數(shù)據(jù)包的大小，最大傳輸單元通常與通信接口有關(guān)。
那么 MSS 和 MTU 有啥關(guān)系呢？
因?yàn)橛?jì)算機(jī)網(wǎng)絡(luò)是分層考慮的，這個(gè)很重要，不同層的稱呼不一樣，對于傳輸層來說，稱為報(bào)文段而對網(wǎng)絡(luò)層來說就叫做 IP 數(shù)據(jù)包，所以，MTU 可以認(rèn)為是網(wǎng)絡(luò)層能夠傳輸?shù)淖畲?IP 數(shù)據(jù)包，而 MSS（Maximum segment size）可以認(rèn)為是傳輸層的概念，也就是 TCP 數(shù)據(jù)包每次能夠傳輸?shù)淖畲罅?/strong>。
TCP 報(bào)文段結(jié)構(gòu)
在簡單聊了聊 TCP 連接后，下面我們就來聊一下 TCP 的報(bào)文段結(jié)構(gòu)，如下圖所示
TCP 報(bào)文段結(jié)構(gòu)相比 UDP 報(bào)文結(jié)構(gòu)多了很多內(nèi)容。但是前兩個(gè) 32 比特的字段是一樣的。它們是?源端口號?和?目標(biāo)端口號，我們知道，這兩個(gè)字段是用于多路復(fù)用和多路分解的。另外，和 UDP 一樣，TCP 也包含校驗(yàn)和(checksum field)?，除此之外，TCP 報(bào)文段首部還有下面這些
32 比特的
序號字段(sequence number field)?和 32 比特的確認(rèn)號字段(acknowledgment number field)?。這些字段被 TCP 發(fā)送方和接收方用來實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。4 比特的
首部字段長度字段(header length field)，這個(gè)字段指示了以 32 比特的字為單位的 TCP 首部長度。TCP 首部的長度是可變的，但是通常情況下，選項(xiàng)字段為空，所以 TCP 首部字段的長度是 20 字節(jié)。16 比特的?
接受窗口字段(receive window field)?，這個(gè)字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量可變的
選項(xiàng)字段(options field)，這個(gè)字段用于發(fā)送方和接收方協(xié)商最大報(bào)文長度，也就是 MSS 時(shí)使用6 比特的?
標(biāo)志字段(flag field)，?ACK?標(biāo)志用于指示確認(rèn)字段中的值是有效的，這個(gè)報(bào)文段包括一個(gè)對已被成功接收報(bào)文段的確認(rèn)；RST、SYN、FIN?標(biāo)志用于連接的建立和關(guān)閉；CWR?和?ECE?用于擁塞控制；PSH?標(biāo)志用于表示立刻將數(shù)據(jù)交給上層處理；URG?標(biāo)志用來表示數(shù)據(jù)中存在需要被上層處理的?緊急?數(shù)據(jù)。緊急數(shù)據(jù)最后一個(gè)字節(jié)由 16 比特的緊急數(shù)據(jù)指針字段(urgeent data pointer field)?指出。一般情況下，PSH 和 URG 并沒有使用。
TCP 的各種功能和特點(diǎn)都是通過 TCP 報(bào)文結(jié)構(gòu)來體現(xiàn)的，在聊完 TCP 報(bào)文結(jié)構(gòu)之后，我們下面就來聊一下 TCP 有哪些功能及其特點(diǎn)了。
序號、確認(rèn)號實(shí)現(xiàn)傳輸可靠性
TCP 報(bào)文段首部中兩個(gè)最重要的字段就是?序號?和?確認(rèn)號，這兩個(gè)字段是 TCP 實(shí)現(xiàn)可靠性的基礎(chǔ)，那么你肯定好奇如何實(shí)現(xiàn)可靠性呢？要了解這一點(diǎn)，首先我們得先知道這兩個(gè)字段里面存了哪些內(nèi)容吧？
一個(gè)報(bào)文段的序號就是數(shù)據(jù)流的字節(jié)編號?。因?yàn)?TCP 會把數(shù)據(jù)流分割成為一段一段的字節(jié)流，因?yàn)樽止?jié)流本身是有序的，所以每一段的字節(jié)編號就是標(biāo)示是哪一段的字節(jié)流。比如，主機(jī) A 要給主機(jī) B 發(fā)送一條數(shù)據(jù)。數(shù)據(jù)經(jīng)過應(yīng)用層產(chǎn)生后會有一串?dāng)?shù)據(jù)流，數(shù)據(jù)流會經(jīng)過 TCP 分割，分割的依據(jù)就是 MSS，假設(shè)數(shù)據(jù)是 10000 字節(jié)，MSS 是 2000 字節(jié)，那么 TCP 就會把數(shù)據(jù)拆分成 0 - 1999 , 2000 - 3999 的段，依次類推。
所以，第一個(gè)數(shù)據(jù) 0 - 1999 的首字節(jié)編號就是 0 ，2000 - 3999 的首字節(jié)編號就是 2000 。
然后，每個(gè)序號都會被填入 TCP 報(bào)文段首部的序號字段中。
至于確認(rèn)號的話，會比序號要稍微麻煩一些。這里我們先拓展下幾種通信模型。
單工通信：單工數(shù)據(jù)傳輸只支持?jǐn)?shù)據(jù)在一個(gè)方向上傳輸；在同一時(shí)間只有一方能接受或發(fā)送信息，不能實(shí)現(xiàn)雙向通信，比如廣播、電視等。
雙工通信是一種點(diǎn)對點(diǎn)系統(tǒng)，由兩個(gè)或者多個(gè)在兩個(gè)方向上相互通信的連接方或者設(shè)備組成。雙工通信模型有兩種：全雙工(FDX)和半雙工(HDX)
全雙工：在全雙工系統(tǒng)中，連接雙方可以相互通信，一個(gè)最常見的例子就是電話通信。全雙工通信是兩個(gè)單工通信方式的結(jié)合，它要求發(fā)送設(shè)備和接收設(shè)備都有獨(dú)立的接收和發(fā)送能力。
半雙工：在半雙工系統(tǒng)中，連接雙方可以彼此通信，但不能同時(shí)通信，比如對講機(jī)，只有把按鈕按住的人才能夠講話，只有一個(gè)人講完話后另外一個(gè)人才能講話。
單工、半雙工、全雙工通信如下圖所示
TCP 是一種全雙工的通信協(xié)議，因此主機(jī) A 在向主機(jī) B 發(fā)送消息的過程中，也在接受來自主機(jī) B 的數(shù)據(jù)。主機(jī) A 填充進(jìn)報(bào)文段的確認(rèn)號是期望從主機(jī) B 收到的下一字節(jié)的序號。稍微有點(diǎn)繞，我們來舉個(gè)例子看一下。比如主機(jī) A 收到了來自主機(jī) B 發(fā)送的編號為 0 - 999 字節(jié)的報(bào)文段，這個(gè)報(bào)文段會寫入序號中，隨后主機(jī) A 期望能夠從主機(jī) B 收到 1000 - 剩下的報(bào)文段，因此，主機(jī) A 發(fā)送到主機(jī) B 的報(bào)文段中，它的確認(rèn)號就是 1000 。
累積確認(rèn)
這里再舉出一個(gè)例子，比如主機(jī) A 在發(fā)送 0 - 999 報(bào)文段后，期望能夠接受到 1000 之后的報(bào)文段，但是主機(jī) B 卻給主機(jī) A 發(fā)送了一個(gè) 1500 之后的報(bào)文段，那么主機(jī) A 是否還會繼續(xù)進(jìn)行等待呢？
答案顯然是會的，因?yàn)?TCP 只會確認(rèn)流中至第一個(gè)丟失字節(jié)為止的字節(jié)，因?yàn)?1500 雖然屬于 1000 之后的字節(jié)，但是主機(jī) B 沒有給主機(jī) A 發(fā)送 1000 - 1499 之間的字節(jié)，所以主機(jī) A 會繼續(xù)等待。
在了解完序號和確認(rèn)號之后，我們下面來聊一下 TCP 的發(fā)送過程。下面是一個(gè)正常的發(fā)送過程
TCP 通過肯定的確認(rèn)應(yīng)答(ACK)?來實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸，當(dāng)主機(jī) A將數(shù)據(jù)發(fā)出之后會等待主機(jī) B 的響應(yīng)。如果有確認(rèn)應(yīng)答(ACK)，說明數(shù)據(jù)已經(jīng)成功到達(dá)對端。反之，則數(shù)據(jù)很可能會丟失。
如下圖所示，如果在一定時(shí)間內(nèi)主機(jī) A 沒有等到確認(rèn)應(yīng)答，則認(rèn)為主機(jī) B 發(fā)送的報(bào)文段已經(jīng)丟失，并進(jìn)行重發(fā)。
主機(jī) A 給主機(jī) B 的響應(yīng)可能由于網(wǎng)絡(luò)抖動(dòng)等原因無法到達(dá)，那么在經(jīng)過特定的時(shí)間間隔后，主機(jī) A 將重新發(fā)送報(bào)文段。
主機(jī) A 沒有收到主機(jī) B 的響應(yīng)還可能是因?yàn)橹鳈C(jī) B 在發(fā)送給主機(jī) A 的過程中丟失。
如上圖所示，由主機(jī) B 返回的確認(rèn)應(yīng)答，由于網(wǎng)絡(luò)擁堵等原因在傳送的過程中丟失，并沒有到達(dá)主機(jī) A。主機(jī) A 會等待一段時(shí)間，如果在這段時(shí)間內(nèi)主機(jī) A 仍沒有等到主機(jī) B 的響應(yīng)，那么主機(jī) A 會重新發(fā)送報(bào)文段。
那么現(xiàn)在就存在一個(gè)問題，如果主機(jī) A 給主機(jī) B 發(fā)送了一個(gè)報(bào)文段后，主機(jī) B 接受到報(bào)文段發(fā)送響應(yīng)，此刻由于網(wǎng)絡(luò)原因，這個(gè)報(bào)文段并未到達(dá)，等到一段時(shí)間后主機(jī) A 重新發(fā)送報(bào)文段，然后此時(shí)主機(jī) B 發(fā)送的響應(yīng)在主機(jī) A 第二次發(fā)送后失序到達(dá)主機(jī) A，那么主機(jī) A 應(yīng)該如何處理呢？
TCP RFC 并未為此做任何規(guī)定，也就是說，我們可以自己決定如何處理失序到達(dá)的報(bào)文段。一般處理方式有兩種
接收方立刻丟棄失序的報(bào)文段
接收方接受失序到達(dá)的報(bào)文段，并等待后續(xù)的報(bào)文段
一般來說通常采取的做法是第二種。
傳輸控制
利用窗口控制提高速度
前面我們介紹了 TCP 是以數(shù)據(jù)段的形式進(jìn)行發(fā)送，如果經(jīng)過一段時(shí)間內(nèi)主機(jī) A 等不到主機(jī) B 的響應(yīng)，主機(jī) A 就會重新發(fā)送報(bào)文段，接受到主機(jī) B 的響應(yīng)，再會繼續(xù)發(fā)送后面的報(bào)文段，我們現(xiàn)在看到，這一問一答的形式還存在許多條件，比如響應(yīng)未收到、等待響應(yīng)等，那么對崇尚性能的互聯(lián)網(wǎng)來說，這種形式的性能應(yīng)該不會很高。
那么如何提升性能呢？
為了解決這個(gè)問題，TCP 引入了?窗口?這個(gè)概念，即使在往返時(shí)間較長、頻次很多的情況下，它也能控制網(wǎng)絡(luò)性能的下降，聽起來很牛批，那它是如何實(shí)現(xiàn)的呢？
如下圖所示
我們之前每次請求發(fā)送都是以報(bào)文段的形式進(jìn)行的，引入窗口后，每次請求都可以發(fā)送多個(gè)報(bào)文段，也就是說一個(gè)窗口可以發(fā)送多個(gè)報(bào)文段。窗口大小就是指無需等待確認(rèn)應(yīng)答就可以繼續(xù)發(fā)送報(bào)文段的最大值。
在這個(gè)窗口機(jī)制中，大量使用了?緩沖區(qū)?，通過對多個(gè)段同時(shí)進(jìn)行確認(rèn)應(yīng)答的功能。
如下圖所示，發(fā)送報(bào)文段中高亮部分即是我們提到的窗口，在窗口內(nèi)，即使沒有收到確認(rèn)應(yīng)答也可以把請求發(fā)送出去。不過，在整個(gè)窗口的確認(rèn)應(yīng)答沒有到達(dá)之前，如果部分報(bào)文段丟失，那么主機(jī) A 將仍會重傳。為此，主機(jī) A 需要設(shè)置緩存來保留這些需要重傳的報(bào)文段，直到收到他們的確認(rèn)應(yīng)答。
在滑動(dòng)窗口以外的部分是尚未發(fā)送的報(bào)文段和已經(jīng)接受到的報(bào)文段，如果報(bào)文段已經(jīng)收到確認(rèn)則不可進(jìn)行重發(fā)，此時(shí)報(bào)文段就可以從緩沖區(qū)中清除。
在收到確認(rèn)的情況下，會將窗口滑動(dòng)到確認(rèn)應(yīng)答中確認(rèn)號的位置，如上圖所示，這樣可以順序的將多個(gè)段同時(shí)發(fā)送，用以提高通信性能，這種窗口也叫做?滑動(dòng)窗口(Sliding window)。
窗口控制和重發(fā)
報(bào)文段的發(fā)送和接收，必然伴隨著報(bào)文段的丟失和重發(fā)，窗口也是同樣如此，如果在窗口中報(bào)文段發(fā)送過程中出現(xiàn)丟失怎么辦？
首先我們先考慮確認(rèn)應(yīng)答沒有返回的情況。在這種情況下，主機(jī) A 發(fā)送的報(bào)文段到達(dá)主機(jī) B，是不需要再進(jìn)行重發(fā)的。這和單個(gè)報(bào)文段的發(fā)送不一樣，如果發(fā)送單個(gè)報(bào)文段，即使確認(rèn)應(yīng)答沒有返回，也要進(jìn)行重發(fā)。
窗口在一定程度上比較大時(shí)，即使有少部分確認(rèn)應(yīng)答的丟失，也不會重新發(fā)送報(bào)文段。
我們知道，如果在某個(gè)情況下由于發(fā)送的報(bào)文段丟失，導(dǎo)致接受主機(jī)未收到請求，或者主機(jī)返回的響應(yīng)未到達(dá)客戶端的話，會經(jīng)過一段時(shí)間重傳報(bào)文。那么在使用窗口的情況下，報(bào)文段丟失會怎么樣呢？
如下圖所示，報(bào)文段 0 - 999 丟失后，但是主機(jī) A 并不會等待，主機(jī) A 會繼續(xù)發(fā)送余下的報(bào)文段，主機(jī) B 發(fā)送的確認(rèn)應(yīng)答卻一直是 1000，同一個(gè)確認(rèn)號的應(yīng)答報(bào)文會被持續(xù)不斷的返回，如果發(fā)送端主機(jī)在連續(xù) 3 次收到同一個(gè)確認(rèn)應(yīng)答后，就會將其所對應(yīng)的數(shù)據(jù)重發(fā)，這種機(jī)制要比之前提到的超時(shí)重發(fā)更加高效，這種機(jī)制也被稱為?高速重發(fā)控制。這種重發(fā)的確認(rèn)應(yīng)答也被稱為?冗余 ACK(響應(yīng))。
主機(jī) B 在沒有接收到自己期望序列號的報(bào)文段時(shí)，會對之前收到的數(shù)據(jù)進(jìn)行確認(rèn)應(yīng)答。發(fā)送端則一旦收到某個(gè)確認(rèn)應(yīng)答后，又連續(xù)三次收到同樣的確認(rèn)應(yīng)答，那么就會認(rèn)為報(bào)文段已經(jīng)丟失。需要進(jìn)行重發(fā)。使用這種機(jī)制可以提供更為快速的重發(fā)服務(wù)。
流量控制
前面聊的是傳輸控制，下面 cxuan 再和你聊一下?流量控制。我們知道，在每個(gè) TCP 連接的一側(cè)主機(jī)都會有一個(gè) socket 緩沖區(qū)，緩沖區(qū)會為每個(gè)連接設(shè)置接收緩存和發(fā)送緩存，當(dāng) TCP 建立連接后，從應(yīng)用程序產(chǎn)生的數(shù)據(jù)就會到達(dá)接收方的接收緩沖區(qū)中，接收方的應(yīng)用程序并不一定會馬上讀取緩沖區(qū)的數(shù)據(jù)，它需要等待操作系統(tǒng)分配時(shí)間片。如果此時(shí)發(fā)送方的應(yīng)用程序產(chǎn)生數(shù)據(jù)過快，而接收方讀取接受緩沖區(qū)的數(shù)據(jù)相對較慢的話，那么接收方中緩沖區(qū)的數(shù)據(jù)將會溢出。
但是還好，TCP 有?流量控制服務(wù)(flow-control service)?用于消除緩沖區(qū)溢出的情況。流量控制是一個(gè)速度匹配服務(wù)，即發(fā)送方的發(fā)送速率與接受方應(yīng)用程序的讀取速率相匹配。
TCP 通過使用一個(gè)?接收窗口(receive window)?的變量來提供流量控制。接受窗口會給發(fā)送方一個(gè)指示到底還有多少可用的緩存空間。發(fā)送端會根據(jù)接收端的實(shí)際接受能力來控制發(fā)送的數(shù)據(jù)量。
接收端主機(jī)向發(fā)送端主機(jī)通知自己可以接收數(shù)據(jù)的大小，發(fā)送端會發(fā)送不超過這個(gè)限度的數(shù)據(jù)，這個(gè)大小限度就是窗口大小，還記得 TCP 的首部么，有一個(gè)接收窗口，我們上面聊的時(shí)候說這個(gè)字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量。
那么只知道這個(gè)字段用于流量控制，那么如何控制呢？
發(fā)送端主機(jī)會定期發(fā)送一個(gè)窗口探測包，這個(gè)包用于探測接收端主機(jī)是否還能夠接受數(shù)據(jù)，當(dāng)接收端的緩沖區(qū)一旦面臨數(shù)據(jù)溢出的風(fēng)險(xiǎn)時(shí)，窗口大小的值也隨之被設(shè)置為一個(gè)更小的值通知發(fā)送端，從而控制數(shù)據(jù)發(fā)送量。
下面是一個(gè)流量控制示意圖
發(fā)送端主機(jī)根據(jù)接收端主機(jī)的窗口大小進(jìn)行流量控制。由此也可以防止發(fā)送端主機(jī)一次發(fā)送過大數(shù)據(jù)導(dǎo)致接收端主機(jī)無法處理。
如上圖所示，當(dāng)主機(jī) B 收到報(bào)文段 2000 - 2999 之后緩沖區(qū)已滿，不得不暫時(shí)停止接收數(shù)據(jù)。然后主機(jī) A 發(fā)送窗口探測包，窗口探測包非常小僅僅一個(gè)字節(jié)。然后主機(jī) B 更新緩沖區(qū)接收窗口大小并發(fā)送窗口更新通知給主機(jī) A，然后主機(jī) A 再繼續(xù)發(fā)送報(bào)文段。
在上面的發(fā)送過程中，窗口更新通知可能會丟失，一旦丟失發(fā)送端就不會發(fā)送數(shù)據(jù)，所以窗口探測包會隨機(jī)發(fā)送，以避免這種情況發(fā)生。
連接管理
在繼續(xù)介紹下面有意思的特性之前，我們先來把關(guān)注點(diǎn)放在 TCP 的連接管理上，因?yàn)闆]有 TCP 連接，也就沒有后續(xù)的一系列 TCP 特性什么事兒了。假設(shè)運(yùn)行在一臺主機(jī)上的進(jìn)程想要和另一臺主機(jī)上的進(jìn)程建立一條 TCP 連接，那么客戶中的 TCP 會使用下面這些步驟與服務(wù)器中的 TCP 建立連接。
首先，客戶端首先向服務(wù)器發(fā)送一個(gè)特殊的 TCP 報(bào)文段。這個(gè)報(bào)文段首部不包含應(yīng)用層數(shù)據(jù)，但是在報(bào)文段的首部中有一個(gè)?
SYN 標(biāo)志位?被置為 1。因此，這個(gè)特殊的報(bào)文段也可以叫做 SYN 報(bào)文段。然后，客戶端隨機(jī)選擇一個(gè)初始序列號(client_isn)?，并將此數(shù)字放入初始 TCP SYN 段的序列號字段中，SYN 段又被封裝在 IP 數(shù)據(jù)段中發(fā)送給服務(wù)器。一旦包含 IP 數(shù)據(jù)段到達(dá)服務(wù)器后，服務(wù)端會從 IP 數(shù)據(jù)段中提取 TCP SYN 段，將 TCP 緩沖區(qū)和變量分配給連接，然后給客戶端發(fā)送一個(gè)連接所允許的報(bào)文段。這個(gè)連接所允許的報(bào)文段也不包括任何應(yīng)用層數(shù)據(jù)。然而，它卻包含了三個(gè)非常重要的信息。
這些緩沖區(qū)和變量的分配使 TCP 容易受到稱為 SYN 泛洪的拒絕服務(wù)攻擊。
首先，SYN 比特被置為 1 。
然后，TCP 報(bào)文段的首部確認(rèn)號被設(shè)置為?
client_isn + 1。最后，服務(wù)器選擇自己的
初始序號(server_isn)，并將其放置到 TCP 報(bào)文段首部的序號字段中。如果用大白話解釋下就是，我收到了你發(fā)起建立連接的 SYN 報(bào)文段，這個(gè)報(bào)文段具有首部字段 client_isn。我同意建立該連接，我自己的初始序號是 server_isn。這個(gè)允許連接的報(bào)文段被稱為?
SYNACK 報(bào)文段第三步，在收到 SYNACK 報(bào)文段后，客戶端也要為該連接分配緩沖區(qū)和變量?？蛻舳酥鳈C(jī)向服務(wù)器發(fā)送另外一個(gè)報(bào)文段，最后一個(gè)報(bào)文段對服務(wù)器發(fā)送的響應(yīng)報(bào)文做了確認(rèn)，確認(rèn)的標(biāo)準(zhǔn)是客戶端發(fā)送的數(shù)據(jù)段中確認(rèn)號為 server_isn + 1，因?yàn)檫B接已經(jīng)建立，所以 SYN 比特被置為 0 。以上就是 TCP 建立連接的三次數(shù)據(jù)段發(fā)送過程，也被稱為?
三次握手。
一旦完成這三個(gè)步驟，客戶和服務(wù)器主機(jī)就可以相互發(fā)送報(bào)文段了，在以后的每一個(gè)報(bào)文段中，SYN 比特都被置為 0 ，整個(gè)過程描述如下圖所示
在客戶端主機(jī)和服務(wù)端主機(jī)建立連接后，參與一條 TCP 連接的兩個(gè)進(jìn)程中的任何一個(gè)都能終止 TCP 連接。連接結(jié)束后，主機(jī)中的緩存和變量將會被釋放。假設(shè)客戶端主機(jī)想要終止 TCP 連接，它會經(jīng)歷如下過程
客戶應(yīng)用進(jìn)程發(fā)出一個(gè)關(guān)閉命令，客戶 TCP 向服務(wù)器進(jìn)程發(fā)送一個(gè)特殊的 TCP 報(bào)文段，這個(gè)特殊的報(bào)文段的首部標(biāo)志 FIN 被設(shè)置為 1 。當(dāng)服務(wù)器收到這個(gè)報(bào)文段后，就會向發(fā)送方發(fā)送一個(gè)確認(rèn)報(bào)文段。然后，服務(wù)器發(fā)送它自己的終止報(bào)文段，F(xiàn)IN 位被設(shè)置為 1 ?？蛻舳藢@個(gè)終止報(bào)文段進(jìn)行確認(rèn)。此時(shí)，在兩臺主機(jī)上用于該連接的所有資源都被釋放了，如下圖所示
在一個(gè) TCP 連接的生命周期內(nèi)，運(yùn)行在每臺主機(jī)中的 TCP 協(xié)議都會在各種?TCP 狀態(tài)(TCP State)?之間進(jìn)行變化，TCP 的狀態(tài)主要有?LISTEN、SYN-SEND、SYN-RECEIVED、ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT 和 CLOSED?。這些狀態(tài)的解釋如下
LISTEN: 表示等待任何來自遠(yuǎn)程 TCP 和端口的連接請求。SYN-SEND: 表示發(fā)送連接請求后等待匹配的連接請求。SYN-RECEIVED: 表示已接收并發(fā)送連接請求后等待連接確認(rèn)，也就是 TCP 三次握手中第二步后服務(wù)端的狀態(tài)ESTABLISHED: 表示已經(jīng)連接已經(jīng)建立，可以將應(yīng)用數(shù)據(jù)發(fā)送給其他主機(jī)
上面這四種狀態(tài)是 TCP 三次握手所涉及的。
FIN-WAIT-1: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求，或者等待先前發(fā)送的連接終止請求的確認(rèn)。FIN-WAIT-2: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求。CLOSE-WAIT: 表示等待本地用戶的連接終止請求。CLOSING: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求確認(rèn)。LAST-ACK: 表示等待先前發(fā)送給遠(yuǎn)程 TCP 的連接終止請求的確認(rèn)（包括對它的連接終止請求的確認(rèn)）。TIME-WAIT: 表示等待足夠的時(shí)間以確保遠(yuǎn)程 TCP 收到其連接終止請求的確認(rèn)。CLOSED: 表示連接已經(jīng)關(guān)閉，無連接狀態(tài)。
上面 7 種狀態(tài)是 TCP 四次揮手，也就是斷開鏈接所設(shè)計(jì)的。
TCP 的連接狀態(tài)會進(jìn)行各種切換，這些 TCP 連接的切換是根據(jù)事件進(jìn)行的，這些事件由用戶調(diào)用：OPEN、SEND、RECEIVE、CLOSE、ABORT 和 STATUS。涉及到 TCP 報(bào)文段的標(biāo)志有?SYN、ACK、RST 和 FIN?，當(dāng)然，還有超時(shí)。
我們下面加上 TCP 連接狀態(tài)后，再來看一下三次握手和四次揮手的過程。
三次握手建立連接
下圖畫出了 TCP 連接建立的過程。假設(shè)圖中左端是客戶端主機(jī)，右端是服務(wù)端主機(jī)，一開始，兩端都處于CLOSED（關(guān)閉）狀態(tài)。
服務(wù)端進(jìn)程準(zhǔn)備好接收來自外部的 TCP 連接，一般情況下是調(diào)用 bind、listen、socket 三個(gè)函數(shù)完成。這種打開方式被認(rèn)為是?
被動(dòng)打開(passive open)。然后服務(wù)端進(jìn)程處于?LISTEN?狀態(tài)，等待客戶端連接請求。客戶端通過?
connect?發(fā)起主動(dòng)打開(active open)，向服務(wù)器發(fā)出連接請求，請求中首部同步位 SYN = 1，同時(shí)選擇一個(gè)初始序號 sequence ，簡寫 seq = x。SYN 報(bào)文段不允許攜帶數(shù)據(jù)，只消耗一個(gè)序號。此時(shí)，客戶端進(jìn)入?SYN-SEND?狀態(tài)。服務(wù)器收到客戶端連接后，，需要確認(rèn)客戶端的報(bào)文段。在確認(rèn)報(bào)文段中，把 SYN 和 ACK 位都置為 1 。確認(rèn)號是 ack = x + 1，同時(shí)也為自己選擇一個(gè)初始序號 seq = y。請注意，這個(gè)報(bào)文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個(gè)序號。此時(shí)，TCP 服務(wù)器進(jìn)入?
SYN-RECEIVED(同步收到)?狀態(tài)。客戶端在收到服務(wù)器發(fā)出的響應(yīng)后，還需要給出確認(rèn)連接。確認(rèn)連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認(rèn)號為 ack = y + 1。TCP 規(guī)定，這個(gè)報(bào)文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個(gè)數(shù)據(jù)報(bào)文段的序號仍是 seq = x + 1。這時(shí)，客戶端進(jìn)入?
ESTABLISHED (已連接)?狀態(tài)服務(wù)器收到客戶的確認(rèn)后，也進(jìn)入?
ESTABLISHED?狀態(tài)。
TCP 建立一個(gè)連接需要三個(gè)報(bào)文段，釋放一個(gè)連接卻需要四個(gè)報(bào)文段。
四次揮手
數(shù)據(jù)傳輸結(jié)束后，通信的雙方可以釋放連接。數(shù)據(jù)傳輸結(jié)束后的客戶端主機(jī)和服務(wù)端主機(jī)都處于 ESTABLISHED 狀態(tài)，然后進(jìn)入釋放連接的過程。
TCP 斷開連接需要?dú)v經(jīng)的過程如下
客戶端應(yīng)用程序發(fā)出釋放連接的報(bào)文段，并停止發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP 連接?？蛻舳酥鳈C(jī)發(fā)送釋放連接的報(bào)文段，報(bào)文段中首部 FIN 位置為 1 ，不包含數(shù)據(jù)，序列號位 seq = u，此時(shí)客戶端主機(jī)進(jìn)入?
FIN-WAIT-1(終止等待 1)?階段。服務(wù)器主機(jī)接受到客戶端發(fā)出的報(bào)文段后，即發(fā)出確認(rèn)應(yīng)答報(bào)文，確認(rèn)應(yīng)答報(bào)文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然后服務(wù)器主機(jī)就進(jìn)入?
CLOSE-WAIT(關(guān)閉等待)?狀態(tài)，這個(gè)時(shí)候客戶端主機(jī) -> 服務(wù)器主機(jī)這條方向的連接就釋放了，客戶端主機(jī)沒有數(shù)據(jù)需要發(fā)送，此時(shí)服務(wù)器主機(jī)是一種半連接的狀態(tài)，但是服務(wù)器主機(jī)仍然可以發(fā)送數(shù)據(jù)。客戶端主機(jī)收到服務(wù)端主機(jī)的確認(rèn)應(yīng)答后，即進(jìn)入?
FIN-WAIT-2(終止等待2)?的狀態(tài)。等待客戶端發(fā)出連接釋放的報(bào)文段。當(dāng)服務(wù)器主機(jī)沒有數(shù)據(jù)發(fā)送后，應(yīng)用進(jìn)程就會通知 TCP 釋放連接。這時(shí)服務(wù)端主機(jī)會發(fā)出斷開連接的報(bào)文段，報(bào)文段中 ACK = 1，序列號 seq = w，因?yàn)樵谶@之間可能已經(jīng)發(fā)送了一些數(shù)據(jù)，所以 seq 不一定等于 v + 1。ack = u + 1，在發(fā)送完斷開請求的報(bào)文后，服務(wù)端主機(jī)就進(jìn)入了?
LAST-ACK(最后確認(rèn))的階段。客戶端收到服務(wù)端的斷開連接請求后，客戶端需要作出響應(yīng)，客戶端發(fā)出斷開連接的報(bào)文段，在報(bào)文段中，ACK = 1, 序列號 seq = u + 1，因?yàn)榭蛻舳藦倪B接開始斷開后就沒有再發(fā)送數(shù)據(jù)，ack = w + 1，然后進(jìn)入到?
TIME-WAIT(時(shí)間等待)?狀態(tài)，請注意，這個(gè)時(shí)候 TCP 連接還沒有釋放。必須經(jīng)過時(shí)間等待的設(shè)置，也就是?2MSL?后，客戶端才會進(jìn)入?CLOSED?狀態(tài)，時(shí)間 MSL 叫做最長報(bào)文段壽命（Maximum Segment Lifetime）。服務(wù)端主要收到了客戶端的斷開連接確認(rèn)后，就會進(jìn)入 CLOSED 狀態(tài)。因?yàn)榉?wù)端結(jié)束 TCP 連接時(shí)間要比客戶端早，而整個(gè)連接斷開過程需要發(fā)送四個(gè)報(bào)文段，因此釋放連接的過程也被稱為四次揮手。
什么是 TIME-WAIT
我上面只是簡單提到了一下 TIME-WAIT 狀態(tài)和 2MSL 是啥，下面來聊一下這兩個(gè)概念。
MSL?是 TCP 報(bào)文段可以存活或者駐留在網(wǎng)絡(luò)中的最長時(shí)間。RFC 793 定義了 MSL 的時(shí)間是兩分鐘，但是具體的實(shí)現(xiàn)還要根據(jù)程序員來指定，一些實(shí)現(xiàn)采用了 30 秒的這個(gè)最大存活時(shí)間。
那么為什么要等待?2MSL?呢？
主要是因?yàn)閮蓚€(gè)理由
為了保證最后一個(gè)響應(yīng)能夠到達(dá)服務(wù)器，因?yàn)樵谟?jì)算機(jī)網(wǎng)絡(luò)中，最后一個(gè) ACK 報(bào)文段可能會丟失，從而致使客戶端一直處于?
LAST-ACK?狀態(tài)等待客戶端響應(yīng)。這時(shí)候服務(wù)器會重傳一次?FINACK?斷開連接報(bào)文，客戶端接收后再重新確認(rèn)，重啟定時(shí)器。如果客戶端不是 2MSL ，在客戶端發(fā)送 ACK 后直接關(guān)閉的話，如果報(bào)文丟失，那么雙方主機(jī)會無法進(jìn)入 CLOSED 狀態(tài)。還可以防止
已失效的報(bào)文段?？蛻舳嗽诎l(fā)送最后一個(gè) ACK 之后，再經(jīng)過經(jīng)過 2MSL，就可以使本鏈接持續(xù)時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。從而保證在關(guān)閉連接后不會有還在網(wǎng)絡(luò)中滯留的報(bào)文段去騷擾服務(wù)器。
這里注意一點(diǎn)：在服務(wù)器發(fā)送了 FIN-ACK 之后，會立即啟動(dòng)超時(shí)重傳計(jì)時(shí)器。客戶端在發(fā)送最后一個(gè) ACK 之后會立即啟動(dòng)時(shí)間等待計(jì)時(shí)器。
說好的 RST 呢
說好的?RST、SYN、FIN?標(biāo)志用于連接的建立和關(guān)閉，那么 SYN 和 FIN 都現(xiàn)身了，那 RST 呢？也是啊，我們上面探討的都是一種理想的情況，就是客戶端服務(wù)器雙方都會接受傳輸報(bào)文段的情況，還有一種情況是當(dāng)主機(jī)收到 TCP 報(bào)文段后，其 IP 和端口號不匹配的情況。假設(shè)客戶端主機(jī)發(fā)送一個(gè)請求，而服務(wù)器主機(jī)經(jīng)過 IP 和端口號的判斷后發(fā)現(xiàn)不是給這個(gè)服務(wù)器的，那么服務(wù)器就會發(fā)出一個(gè)?RST?特殊報(bào)文段給客戶端。
因此，當(dāng)服務(wù)端發(fā)送一個(gè) RST 特殊報(bào)文段給客戶端的時(shí)候，它就會告訴客戶端沒有匹配的套接字連接，請不要再繼續(xù)發(fā)送了。
上面探討的是 TCP 的情況，那么 UDP 呢？
使用 UDP 作為傳輸協(xié)議后，如果套接字不匹配的話，UDP 主機(jī)就會發(fā)送一個(gè)特殊的 ICMP 數(shù)據(jù)報(bào)。
SYN 洪泛攻擊
下面我們來討論一下什么是?SYN 洪泛攻擊。
我們在 TCP 的三次握手中已經(jīng)看到，服務(wù)器為了響應(yīng)一個(gè)收到的 SYN，分配并初始化變量連接和緩存，然后服務(wù)器發(fā)送一個(gè) SYNACK 作為響應(yīng)，然后等待來自于客戶端的 ACK 報(bào)文。如果客戶端不發(fā)送 ACK 來完成最后一步的話，那么這個(gè)連接就處在一個(gè)掛起的狀態(tài)，也就是半連接狀態(tài)。
攻擊者通常在這種情況下發(fā)送大量的 TCP SYN 報(bào)文段，服務(wù)端繼續(xù)響應(yīng)，但是每個(gè)連接都完不成三次握手的步驟。隨著 SYN 的不斷增加，服務(wù)器會不斷的為這些半開連接分配資源，導(dǎo)致服務(wù)器的連接最終被消耗殆盡。這種攻擊也是屬于?Dos?攻擊的一種。
抵御這種攻擊的方式是使用?SYN cookie?，下面是它的工作流程介紹
當(dāng)服務(wù)器收到一個(gè) SYN 報(bào)文段時(shí)，它并不知道這個(gè)報(bào)文段是來自哪里，是來自攻擊者主機(jī)還是客戶端主機(jī)(雖然攻擊者也是客戶端，不過這么說更便于區(qū)分) 。因此服務(wù)器不會為報(bào)文段生成一個(gè)半開連接。與此相反，服務(wù)器生成一個(gè)初始的 TCP 序列號，這個(gè)序列號是 SYN 報(bào)文段的源和目的 IP 地址與端口號這個(gè)四元組構(gòu)造的一個(gè)復(fù)雜的散列函數(shù)，這個(gè)散列函數(shù)生成的 TCP 序列號就是?
SYN Cookie，用于緩存 SYN 請求。然后，服務(wù)器會發(fā)送帶著 SYN Cookie 的 SYNACK 分組。有一點(diǎn)需要注意的是，服務(wù)器不會記憶這個(gè) Cookie 或 SYN 的其他狀態(tài)信息。如果客戶端不是攻擊者的話，它就會返回一個(gè) ACK 報(bào)文段。當(dāng)服務(wù)器收到這個(gè) ACK 后，需要驗(yàn)證這個(gè) ACK 與 SYN 發(fā)送的是否相同，驗(yàn)證的標(biāo)準(zhǔn)就是確認(rèn)字段中的確認(rèn)號和序列號，源和目的 IP 地址與端口號以及和散列函數(shù)的是否一致，散列函數(shù)的結(jié)果 + 1 是否和 SYNACK 中的確認(rèn)值相同。(大致是這樣，說的不對還請讀者糾正) 。如果有興趣讀者可以自行深入了解。如果是合法的，服務(wù)器就會生成一個(gè)具有套接字的全開連接。
如果客戶端沒有返回 ACK，即認(rèn)為是攻擊者，那么這樣也沒關(guān)系，服務(wù)器沒有收到 ACK，不會分配變量和緩存資源，不會對服務(wù)器產(chǎn)生危害。
擁塞控制
有了 TCP 的窗口控制后，使計(jì)算機(jī)網(wǎng)絡(luò)中兩個(gè)主機(jī)之間不再是以單個(gè)數(shù)據(jù)段的形式發(fā)送了，而是能夠連續(xù)發(fā)送大量的數(shù)據(jù)包。然而，大量數(shù)據(jù)包同時(shí)也伴隨著其他問題，比如網(wǎng)絡(luò)負(fù)載、網(wǎng)絡(luò)擁堵等問題。TCP 為了防止這類問題的出現(xiàn)，使用了?擁塞控制?機(jī)制，擁塞控制機(jī)制會在面臨網(wǎng)絡(luò)擁塞時(shí)遏制發(fā)送方的數(shù)據(jù)發(fā)送。
擁塞控制主要有兩種方法
端到端的擁塞控制: 因?yàn)榫W(wǎng)絡(luò)層沒有為運(yùn)輸層擁塞控制提供顯示支持。所以即使網(wǎng)絡(luò)中存在擁塞情況，端系統(tǒng)也要通過對網(wǎng)絡(luò)行為的觀察來推斷。TCP 就是使用了端到端的擁塞控制方式。IP 層不會向端系統(tǒng)提供有關(guān)網(wǎng)絡(luò)擁塞的反饋信息。那么 TCP 如何推斷網(wǎng)絡(luò)擁塞呢？如果超時(shí)或者三次冗余確認(rèn)就被認(rèn)為是網(wǎng)絡(luò)擁塞，TCP 會減小窗口的大小，或者增加往返時(shí)延來避免。網(wǎng)絡(luò)輔助的擁塞控制: 在網(wǎng)絡(luò)輔助的擁塞控制中，路由器會向發(fā)送方提供關(guān)于網(wǎng)絡(luò)中擁塞狀態(tài)的反饋。這種反饋信息就是一個(gè)比特信息，它指示鏈路中的擁塞情況。
下圖描述了這兩種擁塞控制方式
TCP 擁塞控制
如果你看到這里，那我就暫定認(rèn)為你了解了 TCP 實(shí)現(xiàn)可靠性的基礎(chǔ)了，那就是使用序號和確認(rèn)號。除此之外，另外一個(gè)實(shí)現(xiàn) TCP 可靠性基礎(chǔ)的就是 TCP 的擁塞控制。如果說
TCP 所采用的方法是讓每一個(gè)發(fā)送方根據(jù)所感知到的網(wǎng)絡(luò)的擁塞程度來限制發(fā)出報(bào)文段的速率，如果 TCP 發(fā)送方感知到?jīng)]有什么擁塞，則 TCP 發(fā)送方會增加發(fā)送速率；如果發(fā)送方感知沿著路徑有阻塞，那么發(fā)送方就會降低發(fā)送速率。
但是這種方法有三個(gè)問題
TCP 發(fā)送方如何限制它向其他連接發(fā)送報(bào)文段的速率呢？
一個(gè) TCP 發(fā)送方是如何感知到網(wǎng)絡(luò)擁塞的呢？
當(dāng)發(fā)送方感知到端到端的擁塞時(shí)，采用何種算法來改變其發(fā)送速率呢？
我們先來探討一下第一個(gè)問題，TCP 發(fā)送方如何限制它向其他連接發(fā)送報(bào)文段的速率呢？
我們知道 TCP 是由接收緩存、發(fā)送緩存和變量(LastByteRead, rwnd，等)組成。發(fā)送方的 TCP 擁塞控制機(jī)制會跟蹤一個(gè)變量，即?擁塞窗口(congestion window)?的變量，擁塞窗口表示為?cwnd，用于限制 TCP 在接收到 ACK 之前可以發(fā)送到網(wǎng)絡(luò)的數(shù)據(jù)量。而接收窗口(rwnd)?是一個(gè)用于告訴接收方能夠接受的數(shù)據(jù)量。
一般來說，發(fā)送方未確認(rèn)的數(shù)據(jù)量不得超過 cwnd 和 rwnd 的最小值，也就是
LastByteSent - LastByteAcked <= min(cwnd,rwnd)
由于每個(gè)數(shù)據(jù)包的往返時(shí)間是 RTT，我們假設(shè)接收端有足夠的緩存空間用于接收數(shù)據(jù)，我們就不用考慮 rwnd 了，只專注于 cwnd，那么，該發(fā)送方的發(fā)送速率大概是?cwnd/RTT 字節(jié)/秒?。通過調(diào)節(jié) cwnd，發(fā)送方因此能調(diào)整它向連接發(fā)送數(shù)據(jù)的速率。
一個(gè) TCP 發(fā)送方是如何感知到網(wǎng)絡(luò)擁塞的呢？
這個(gè)我們上面討論過，是 TCP 根據(jù)超時(shí)或者 3 個(gè)冗余 ACK 來感知的。
當(dāng)發(fā)送方感知到端到端的擁塞時(shí)，采用何種算法來改變其發(fā)送速率呢??
這個(gè)問題比較復(fù)雜，且容我娓娓道來，一般來說，TCP 會遵循下面這幾種指導(dǎo)性原則
如果在報(bào)文段發(fā)送過程中丟失，那就意味著網(wǎng)絡(luò)擁堵，此時(shí)需要適當(dāng)降低 TCP 發(fā)送方的速率。
一個(gè)確認(rèn)報(bào)文段指示發(fā)送方正在向接收方傳遞報(bào)文段，因此，當(dāng)對先前未確認(rèn)報(bào)文段的確認(rèn)到達(dá)時(shí)，能夠增加發(fā)送方的速率。為啥呢？因?yàn)槲创_認(rèn)的報(bào)文段到達(dá)接收方也就表示著網(wǎng)絡(luò)不擁堵，能夠順利到達(dá)，因此發(fā)送方擁塞窗口長度會變大，所以發(fā)送速率會變快
帶寬探測，帶寬探測說的是 TCP 可以通過調(diào)節(jié)傳輸速率來增加/減小 ACK 到達(dá)的次數(shù)，如果出現(xiàn)丟包事件，就會減小傳輸速率。因此，為了探測擁塞開始出現(xiàn)的頻率， TCP 發(fā)送方應(yīng)該增加它的傳輸速率。然后慢慢使傳輸速率降低，進(jìn)而再次開始探測，看看擁塞開始速率是否發(fā)生了變化。
在了解完 TCP 擁塞控制后，下面我們就該聊一下 TCP 的?擁塞控制算法(TCP congestion control algorithm)?了。TCP 擁塞控制算法主要包含三個(gè)部分：慢啟動(dòng)、擁塞避免、快速恢復(fù)，下面我們依次來看一下
慢啟動(dòng)
當(dāng)一條 TCP 開始建立連接時(shí)，cwnd 的值就會初始化為一個(gè) MSS 的較小值。這就使得初始發(fā)送速率大概是?MSS/RTT 字節(jié)/秒?，比如要傳輸 1000 字節(jié)的數(shù)據(jù)，RTT 為 200 ms ，那么得到的初始發(fā)送速率大概是 40 kb/s 。實(shí)際情況下可用帶寬要比這個(gè) MSS/RTT 大得多，因此 TCP 想要找到最佳的發(fā)送速率，可以通過?慢啟動(dòng)(slow-start)?的方式，在慢啟動(dòng)的方式中，cwnd 的值會初始化為 1 個(gè) MSS，并且每次傳輸報(bào)文確認(rèn)后就會增加一個(gè) MSS，cwnd 的值會變?yōu)?2 個(gè) MSS，這兩個(gè)報(bào)文段都傳輸成功后每個(gè)報(bào)文段 + 1，會變?yōu)?4 個(gè) MSS，依此類推，每成功一次 cwnd 的值就會翻倍。如下圖所示
發(fā)送速率不可能會一直增長，增長總有結(jié)束的時(shí)候，那么何時(shí)結(jié)束呢？慢啟動(dòng)通常會使用下面這幾種方式結(jié)束發(fā)送速率的增長。
如果在慢啟動(dòng)的發(fā)送過程出現(xiàn)丟包的情況，那么 TCP 會將發(fā)送方的 cwnd 設(shè)置為 1 并重新開始慢啟動(dòng)的過程，此時(shí)會引入一個(gè)?
ssthresh(慢啟動(dòng)閾值)?的概念，它的初始值就是產(chǎn)生丟包的 cwnd 的值 / 2，即當(dāng)檢測到擁塞時(shí)，ssthresh 的值就是窗口值的一半。第二種方式是直接和 ssthresh 的值相關(guān)聯(lián)，因?yàn)楫?dāng)檢測到擁塞時(shí)，ssthresh 的值就是窗口值的一半，那么當(dāng) cwnd > ssthresh 時(shí)，每次翻番都可能會出現(xiàn)丟包，所以最好的方式就是 cwnd 的值 = ssthresh ，這樣 TCP 就會轉(zhuǎn)為擁塞控制模式，結(jié)束慢啟動(dòng)。
慢啟動(dòng)結(jié)束的最后一種方式就是如果檢測到 3 個(gè)冗余 ACK，TCP 就會執(zhí)行一種快速重傳并進(jìn)入恢復(fù)狀態(tài)。
擁塞避免
當(dāng) TCP 進(jìn)入擁塞控制狀態(tài)后，cwnd 的值就等于擁塞時(shí)值的一半，也就是 ssthresh 的值。所以，無法每次報(bào)文段到達(dá)后都將 cwnd 的值再翻倍。而是采用了一種相對保守的方式，每次傳輸完成后只將 cwnd 的值增加一個(gè) MSS，比如收到了 10 個(gè)報(bào)文段的確認(rèn)，但是 cwnd 的值只增加一個(gè) MSS。這是一種線性增長模式，它也會有增長逾值，它的增長逾值和慢啟動(dòng)一樣，如果出現(xiàn)丟包，那么 cwnd 的值就是一個(gè) MSS，ssthresh 的值就等于 cwnd 的一半；或者是收到 3 個(gè)冗余的 ACK 響應(yīng)也能停止 MSS 增長。如果 TCP 將 cwnd 的值減半后，仍然會收到 3 個(gè)冗余 ACK，那么就會將 ssthresh 的值記錄為 cwnd 值的一半，進(jìn)入?快速恢復(fù)?狀態(tài)。
快速恢復(fù)
在快速恢復(fù)中，對于使 TCP 進(jìn)入快速恢復(fù)狀態(tài)缺失的報(bào)文段，對于每個(gè)收到的冗余 ACK，cwnd 的值都會增加一個(gè) MSS 。當(dāng)對丟失報(bào)文段的一個(gè) ACK 到達(dá)時(shí)，TCP 在降低 cwnd 后進(jìn)入擁塞避免狀態(tài)。如果在擁塞控制狀態(tài)后出現(xiàn)超時(shí)，那么就會遷移到慢啟動(dòng)狀態(tài)，cwnd 的值被設(shè)置為 1 個(gè) MSS，ssthresh 的值設(shè)置為 cwnd 的一半。
如果你能用心看到這里，我相信你定會有所收獲。
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
