1. 傳輸層的協(xié)議

1.1 TCP (傳輸控制協(xié)議) - rfc793

????????連接模式的傳輸。

????????保證按順序傳送數(shù)據(jù)包。

????????流量控制、錯(cuò)誤檢測和在數(shù)據(jù)包丟失時(shí)的重傳。

????????用于需要可靠傳輸?shù)膽?yīng)用，如網(wǎng)絡(luò)（HTTP/HTTPS）、電子郵件（SMTP, IMAP, POP3）和文件傳輸（FTP）。

1.2 UDP (用戶數(shù)據(jù)報(bào)協(xié)議) - rfc768

????????數(shù)據(jù)報(bào)模式。

????????沒有交付、順序或錯(cuò)誤檢測的保證。

????????用于速度比可靠性更重要的應(yīng)用，如視頻流或在線游戲。

1.3?DCCP (數(shù)據(jù)報(bào)擁塞控制協(xié)議) - rfc4340

????????為流媒體和需要擁塞控制但不一定需要可靠交付的應(yīng)用而設(shè)計(jì)。

????????結(jié)合了TCP和UDP的特點(diǎn)。

1.4?SCTP (流控制傳輸協(xié)議) - rfc4960

????????支持傳輸多個(gè)消息流。

????????可以抵抗網(wǎng)絡(luò)錯(cuò)誤，如從一個(gè)路徑切換到另一個(gè)路徑。

????????主要用于電信網(wǎng)絡(luò)中的信令傳輸。

1.5?MPTCP (多路徑TCP) - rfc6824

????????是TCP的一個(gè)擴(kuò)展，允許使用多個(gè)路徑在兩個(gè)端點(diǎn)之間傳輸數(shù)據(jù)。

????????提高了彈性和帶寬利用率。

1.6?QUIC

????????基于UDP。

????????與TCP+TLS相比，設(shè)計(jì)目的是減少延遲。

????????集成的多路復(fù)用和快速的加密協(xié)商。

????????最初由Google開發(fā)，目前正在由IETF進(jìn)行標(biāo)準(zhǔn)化。具體的RFC引用將取決于這一標(biāo)準(zhǔn)化完成的日期。

2.?TCP（傳輸控制協(xié)議）

2.1 TCP報(bào)文段的結(jié)構(gòu)

????????TCP報(bào)文段是TCP連接中傳輸?shù)臄?shù)據(jù)單元，包含以下主要部分：

2.1.1?源端口（Source Port）和目的端口（Destination Port）

????????這兩個(gè)字段指定了發(fā)送和接收數(shù)據(jù)的端口號，用于標(biāo)識發(fā)送和接收的應(yīng)用程序。

2.1.2?序列號（Numéro de séquence）

????????用于確保數(shù)據(jù)傳輸?shù)捻樞蛐?，并為可靠傳輸提供必要的信息?/span>

2.1.3?確認(rèn)應(yīng)答號（Acquittement）

????????一個(gè)序列號，確認(rèn)收到的數(shù)據(jù)，用于實(shí)現(xiàn)TCP的可靠性。

2.1.4?數(shù)據(jù)偏移（Header Length）????????

????????指示TCP報(bào)頭的長度，因?yàn)門CP報(bào)頭可以包含一個(gè)可變數(shù)量的選項(xiàng)。

2.1.5?保留（Resv）

????????保留字段，用于未來的使用，目前應(yīng)該設(shè)置為0。

2.1.6?控制位（Bits de contr?le）

????????一組標(biāo)志位，包括URG（緊急指針有效）, ACK（確認(rèn)字段有效）, PSH（提示接收方盡快將這個(gè)報(bào)文段交給應(yīng)用層）, RST（重置連接）, SYN（同步序列編號，用于建立連接）, FIN（釋放連接）。這些位用于控制發(fā)送者和接收者之間的TCP連接的行為。以下是每個(gè)位的詳細(xì)解釋：

2.1.6.1 ECE (顯式擁塞通知回顯) - rfc 3168

????????當(dāng)TCP實(shí)體接收到帶有此位為1的段時(shí)，它應(yīng)該減少其傳輸速率。這是網(wǎng)絡(luò)擁塞的指示。

2.1.6.2 CWR (擁塞窗口已減少) - rfc 3168

????????這是對接收到ECE位的響應(yīng)。它表示已經(jīng)考慮到了降低速率的請求。

2.1.6.3 URG

????????表示TCP頭中的“緊急指針”字段是有意義的。這意味著段中的某些數(shù)據(jù)被視為緊急。

2.1.6.4 ACK

????????表示TCP頭中的“確認(rèn)號”字段是有意義的。這是確認(rèn)數(shù)據(jù)已被接收的標(biāo)志。

2.1.6.5 PSH (推送)

????????表示數(shù)據(jù)應(yīng)立即傳遞給上層，而不等待緩沖區(qū)滿。

2.1.6.6?RST (重置)

????????表示連接應(yīng)被重置。這通常是對連接中的錯(cuò)誤或問題的響應(yīng)。這是一個(gè)重要的控制位，用于處理異常情況：

2.1.6.6.1 RST控制位的用途

????????當(dāng)一個(gè)TCP實(shí)體與另一個(gè)遠(yuǎn)程TCP實(shí)體連接時(shí)，RST位用于警告存在問題。

2.1.6.6.2 正常的應(yīng)用程序終止

????????正常結(jié)束的應(yīng)用程序會在使用的TCP端口上進(jìn)行關(guān)閉（通常是一個(gè)套接字）。這通過交換設(shè)置了FIN位的段來實(shí)現(xiàn)，從而斷開連接。

2.1.6.6.3?異常的應(yīng)用程序終止

????????如果應(yīng)用程序突然終止而沒有關(guān)閉連接，與其關(guān)聯(lián)的TCP實(shí)體會向另一端發(fā)送設(shè)置了RST位的段。這樣，另一端就被通知連接已經(jīng)終止。

????????簡而言之，RST位是TCP協(xié)議中的一個(gè)機(jī)制，用于在發(fā)生異常或錯(cuò)誤時(shí)快速終止連接。當(dāng)一個(gè)端點(diǎn)收到設(shè)置了RST位的段時(shí)，它知道遠(yuǎn)程端點(diǎn)已經(jīng)重置連接，因此它也應(yīng)該立即終止連接。

2.1.6.7?SYN (同步)

????????用于建立TCP連接。它在發(fā)送者和接收者之間同步序列號。

2.1.6.8?FIN (完成)

????????表示發(fā)送者已完成數(shù)據(jù)發(fā)送并希望終止連接。

????????這些控制位對于TCP的正確和高效運(yùn)作至關(guān)重要。它們允許網(wǎng)絡(luò)上的兩個(gè)實(shí)體進(jìn)行可靠和有序的通信。

2.1.7 窗口大小

????????用于流量控制，它指定了發(fā)送方能發(fā)送的、開始于確認(rèn)字段中指明的序列號的、不需要接收方確認(rèn)的數(shù)據(jù)量。????????

2.1.8?校驗(yàn)和????????

????????用于檢測報(bào)文段在傳輸過程中的任何變化，以確保數(shù)據(jù)的完整性。

2.1.9?緊急指針

????????僅在URG控制位被設(shè)置時(shí)有效，它指出了報(bào)文段中緊急數(shù)據(jù)的結(jié)束位置。

2.1.10?選項(xiàng)

????????如果有的話，可以有多個(gè)選項(xiàng)，每個(gè)選項(xiàng)都是32位的倍數(shù)。

2.1.11?數(shù)據(jù)

????????這部分是傳輸?shù)膽?yīng)用數(shù)據(jù)。

????????TCP通過這種復(fù)雜的報(bào)文段結(jié)構(gòu)，實(shí)現(xiàn)了一種可靠的、面向連接的、流控制的傳輸層協(xié)議，它確保了數(shù)據(jù)可靠傳輸和正確順序到達(dá)目的地。

2.2 例子

0: 0800 2074 ef05 0800 0914 18e7 0800 4500
16: 0028 8954 0000 4006 db07 c02c 4b13 c02c
32: 4b08 1770 fdbe 0162 6e86 8e21 a873 5010 /* 0001 0000 */
48: 2210 bba3 0000 023a b3a1 1829

????????您提供了一個(gè)數(shù)據(jù)包的十六進(jìn)制表示，并指出了其中的TCP ACK位為1。

????????讓我們分析這個(gè)數(shù)據(jù)包：

????????首先，我們可以看到這是一個(gè)IP數(shù)據(jù)包，因?yàn)樵谄屏繛?的位置（第二行的第三個(gè)字節(jié)）的值為0x06，這表示該數(shù)據(jù)包使用的是TCP協(xié)議（在IP頭部中，協(xié)議字段的值為6表示TCP）。

????????TCP頭部開始于偏移量為20的位置，因?yàn)闃?biāo)準(zhǔn)的IPv4頭部長度為20字節(jié)。在TCP頭部中，控制位位于偏移量為13的位置（從TCP頭部開始計(jì)算）。在您提供的數(shù)據(jù)中，這個(gè)位置的值為0x50，它的二進(jìn)制表示為`0101 0000`。

????????從這個(gè)二進(jìn)制值中，我們可以看到ACK位確實(shí)為1（從右數(shù)第五位），而其他的控制位（CWR, ECE, URG, PSH, RST, SYN, FIN）都為0。

????????因此，您的描述是正確的：這個(gè)TCP段的ACK位為1。

2.3 緊急指針

????????“緊急數(shù)據(jù)”或稱為“帶外數(shù)據(jù)”（Out of Band，OOB）的概念

????????這是TCP協(xié)議中的一個(gè)特性，允許發(fā)送方標(biāo)記某些數(shù)據(jù)為“緊急”，以便接收方可以優(yōu)先處理它們

2.3.1 緊急數(shù)據(jù)

????????有時(shí)被稱為“帶外數(shù)據(jù)”或Out of Band (OOB)。

2.3.2?優(yōu)先處理

????????這些數(shù)據(jù)需要被接收層優(yōu)先處理。

2.3.3 正常傳輸

????????盡管這些數(shù)據(jù)被標(biāo)記為“緊急”，但它們?nèi)匀辉谡５臄?shù)據(jù)流中傳輸并遵循正常的路徑。IP層對這些數(shù)據(jù)不敏感，只有在兩端（發(fā)送端和接收端）這些數(shù)據(jù)的“緊急”性質(zhì)才有意義。

2.3.4?隨機(jī)性

????????對于目標(biāo)應(yīng)用程序，這些數(shù)據(jù)的到達(dá)具有隨機(jī)性。

2.3.5 數(shù)據(jù)流中的讀取

????????應(yīng)用程序不會在正常的數(shù)據(jù)流中讀取這些數(shù)據(jù)。

2.3.6?處理緊急數(shù)據(jù)

????????任何希望接受此類數(shù)據(jù)的應(yīng)用程序都必須通知系統(tǒng)，以便系統(tǒng)可以發(fā)送一個(gè)中斷（或稱為軟件信號）給它，這樣應(yīng)用程序就可以優(yōu)先處理這些數(shù)據(jù)。應(yīng)用程序必須預(yù)先設(shè)定一個(gè)特殊的處理程序來讀取這些數(shù)據(jù)。

2.3.7?語義不明確

????????RFC6093建議新的應(yīng)用程序不再使用這一特性，因?yàn)樗恼Z義定義不明確。

????????總的來說，盡管TCP提供了“緊急數(shù)據(jù)”或“帶外數(shù)據(jù)”的功能，但由于其語義不明確和其他問題，它在現(xiàn)代應(yīng)用中的使用已經(jīng)變得不那么普遍。

2.4?TCP（傳輸控制協(xié)議）的“面向連接”的特性

2.4.1?TCP連接

????????TCP是一個(gè)面向連接的協(xié)議。

2.4.2?點(diǎn)對點(diǎn)的關(guān)系

????????TCP連接是在兩個(gè)端點(diǎn)之間建立的點(diǎn)對點(diǎn)關(guān)系。

2.4.3?對路由器的透明性

????????TCP連接對路由器通常是透明的，除非路由器實(shí)施了過濾或QoS（服務(wù)質(zhì)量）機(jī)制。

2.4.4?端點(diǎn)上的上下文特征

????????TCP連接在端點(diǎn)機(jī)器上由一個(gè)上下文特征，該上下文包括本地和遠(yuǎn)程的IP地址以及本地和遠(yuǎn)程的端口號。

????????簡而言之，TCP是一個(gè)面向連接的協(xié)議，這意味著在數(shù)據(jù)傳輸之前，兩個(gè)通信實(shí)體必須首先建立一個(gè)連接。這個(gè)連接是由端點(diǎn)上的上下文（如IP地址和端口號）定義的，并且對大多數(shù)中間設(shè)備（如路由器）是透明的。

2.5?TCP（傳輸控制協(xié)議）的“連接”概念以及相關(guān)特性

2.5.1?建立連接

????????連接是通過初始數(shù)據(jù)包交換建立的，這個(gè)過程稱為“三次握手”（three way handshake）。

這個(gè)過程包含以下步驟：

2.5.1.1 SYN（同步）

????????客戶端發(fā)送一個(gè)帶有序列號X的SYN包到服務(wù)器以請求建立連接。

2.5.1.2 SYN-ACK（同步確認(rèn)）

????????服務(wù)器收到SYN包后，發(fā)送一個(gè)帶有自己序列號Y和確認(rèn)號X+1的SYN-ACK包作為響應(yīng)，確認(rèn)號X+1表示服務(wù)器已經(jīng)收到客戶端的SYN包，并期望收到序列號為X+1的下一個(gè)數(shù)據(jù)包。

2.5.1.3?ACK（確認(rèn)）

????????客戶端收到SYN-ACK包后，發(fā)送一個(gè)帶有確認(rèn)號Y+1的ACK包到服務(wù)器，表示客戶端已經(jīng)收到服務(wù)器的SYN-ACK包，并期望收到序列號為Y+1的下一個(gè)數(shù)據(jù)包。

????????完成這三步后，TCP連接建立，客戶端和服務(wù)器開始數(shù)據(jù)傳輸。這個(gè)三次握手過程確保了雙方都知道彼此已經(jīng)準(zhǔn)備好進(jìn)行通信，并且同步了序列號，這對于TCP提供的可靠連接至關(guān)重要。

2.5.2?連接的定義

????????這并不是“連接”這個(gè)詞的嚴(yán)格意義上的連接，因?yàn)樵诰W(wǎng)絡(luò)中沒有建立虛擬路徑。TCP段是通過IP傳輸?shù)?，而IP是一個(gè)面向數(shù)據(jù)報(bào)的協(xié)議。

2.5.3?TCP連接的表示

????????TCP連接在端點(diǎn)機(jī)器（客戶端和服務(wù)器）上表示為一個(gè)保存在內(nèi)存中的上下文。這個(gè)上下文是一個(gè)五元組，包括：[協(xié)議, 本地端口, 遠(yuǎn)程端口, 本地IP地址, 遠(yuǎn)程IP地址]。

????????簡而言之，盡管TCP是一個(gè)“面向連接”的協(xié)議，但這并不意味著在網(wǎng)絡(luò)中有一個(gè)物理或虛擬的持續(xù)連接。相反，這個(gè)“連接”是通過在通信的兩端維護(hù)上下文信息來實(shí)現(xiàn)的，這些上下文信息包括端口號和IP地址等。

2.5.4 無數(shù)據(jù)交換

????????如果連接的應(yīng)用程序沒有數(shù)據(jù)要交換，相應(yīng)的TCP實(shí)體不會發(fā)送任何段，因此不會有任何流量。

2.5.5 警告段

????????可以設(shè)置TCP的一個(gè)選項(xiàng)，使得TCP實(shí)體每兩小時(shí)發(fā)送一個(gè)警告段（這些段不包含實(shí)際的數(shù)據(jù)，因?yàn)闆]有數(shù)據(jù)要發(fā)送）。

2.5.6 無響應(yīng)的遠(yuǎn)程TCP實(shí)體

????????如果遠(yuǎn)程TCP實(shí)體沒有響應(yīng)警告段，這可能意味著關(guān)聯(lián)的應(yīng)用程序已經(jīng)在沒有通知的情況下終止，或者機(jī)器已經(jīng)停止運(yùn)行。當(dāng)本地應(yīng)用程序下次從TCP端口讀取時(shí)，它會被通知。

????????這些特性突顯了TCP的可靠性和健壯性。即使在長時(shí)間沒有數(shù)據(jù)交換的情況下，TCP仍然提供了機(jī)制來檢測連接的狀態(tài)，并確保應(yīng)用程序在連接中斷時(shí)得到通知。

2.5.7 TCP中的“主動(dòng)連接”和“被動(dòng)連接”的概念

2.5.7.1?被動(dòng)連接

????????這不是一個(gè)真正的連接，而是一個(gè)由服務(wù)器應(yīng)用程序打開的TCP訪問點(diǎn)。創(chuàng)建的TCP上下文等待來自客戶端的連接請求。

2.5.7.2?主動(dòng)連接

????????這是一個(gè)真正的連接，由客戶端模式的應(yīng)用程序初始化。

????????在TCP的上下文中，當(dāng)我們談?wù)摗氨粍?dòng)連接”時(shí)，我們通常指的是服務(wù)器正在監(jiān)聽并等待來自客戶端的連接請求。而“主動(dòng)連接”則是指客戶端主動(dòng)發(fā)起的連接請求。

????????例如，當(dāng)您在瀏覽器中輸入一個(gè)網(wǎng)址并按下Enter鍵時(shí)，您的瀏覽器（作為客戶端）會主動(dòng)發(fā)起一個(gè)TCP連接到該網(wǎng)站的服務(wù)器。而該服務(wù)器在其端會有一個(gè)被動(dòng)連接，等待這樣的請求。

2.6 TCP（傳輸控制協(xié)議）的狀態(tài)機(jī)

????????TCP狀態(tài)機(jī)描述了一個(gè)TCP連接在其生命周期內(nèi)可能經(jīng)歷的不同狀態(tài)以及在收到不同類型的TCP報(bào)文時(shí)會發(fā)生的狀態(tài)轉(zhuǎn)換。這些狀態(tài)包括：

????????Closed：沒有活躍的連接，也沒有正在等待建立的連接。

????????Listen：服務(wù)器端的TCP正在等待來自客戶端的連接請求。

????????SYN Sent：客戶端已發(fā)送連接請求（SYN報(bào)文），等待服務(wù)器確認(rèn)。

????????SYN Received：服務(wù)器已收到連接請求并響應(yīng)了連接請求，等待客戶端確認(rèn)。

????????Established：連接已建立，數(shù)據(jù)可以開始傳輸。

????????Fin Wait 1：發(fā)起連接終止的一方等待對方的連接終止請求的確認(rèn)。

????????Fin Wait 2：發(fā)起連接終止的一方已收到對方的確認(rèn)，并等待對方的連接終止請求。

????????Close Wait：一方已收到對方的連接終止請求，等待本地用戶的連接終止請求。

????????Closing：雙方都等待對方確認(rèn)其連接終止請求。

????????Last Ack：一方等待對方對其連接終止請求的最終確認(rèn)。

????????Time Wait：確保對方已經(jīng)接收到連接終止請求的確認(rèn)后，等待足夠的時(shí)間以確保對方接收到最終的ACK。

????????Closed：連接完全終止，兩邊都不再有連接。

????????TCP的狀態(tài)機(jī)確保了TCP連接的可靠地建立和終止，是TCP協(xié)議可靠性和順序性保證的關(guān)鍵部分。每一個(gè)狀態(tài)的轉(zhuǎn)換都是根據(jù)接收到的特定TCP報(bào)文來觸發(fā)的。

2.7 計(jì)算機(jī)網(wǎng)絡(luò)中端口的概念

????????在網(wǎng)絡(luò)通信中，端口是數(shù)字標(biāo)識符，它使得計(jì)算機(jī)上運(yùn)行的不同應(yīng)用程序能夠通過網(wǎng)絡(luò)進(jìn)行通信。每個(gè)使用TCP/IP協(xié)議的應(yīng)用程序都將其通信關(guān)聯(lián)到一個(gè)或多個(gè)端口。

????????有兩臺機(jī)器（機(jī)器M和機(jī)器N），每臺機(jī)器都運(yùn)行著兩個(gè)應(yīng)用程序（例如，文件傳輸和郵件應(yīng)用）。每個(gè)應(yīng)用程序通過其特定的端口與TCP協(xié)議層進(jìn)行通信。TCP協(xié)議層再與IP協(xié)議層通信，IP協(xié)議層負(fù)責(zé)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)。

????????端口可以被視為計(jì)算機(jī)上的虛擬通信終點(diǎn)，它們通常由操作系統(tǒng)管理。端口號范圍從0到65535，其中特定的端口號被指定為“知名端口”，用于特定的服務(wù)（例如，HTTP通常使用端口80，而電子郵件的SMTP服務(wù)通常使用端口25）。當(dāng)數(shù)據(jù)包到達(dá)一個(gè)機(jī)器時(shí)，IP協(xié)議層將其傳遞給TCP協(xié)議層，TCP協(xié)議層再根據(jù)數(shù)據(jù)包頭部的端口信息將數(shù)據(jù)包送到正確的應(yīng)用程序。

2.8 在計(jì)算機(jī)網(wǎng)絡(luò)中連接的識別方法

????????在TCP/IP網(wǎng)絡(luò)中，一個(gè)“連接”是由多個(gè)元素唯一確定的，包括：

????????協(xié)議類型（TCP或UDP）

????????源IP地址和源端口號

????????目的IP地址和目的端口號

????????兩個(gè)客戶端機(jī)器（機(jī)器A和機(jī)器B）以及它們連接到的服務(wù)器機(jī)器S，服務(wù)器上有兩個(gè)服務(wù)（服務(wù)1和服務(wù)2）。每個(gè)客戶端通過其源端口（端口Px）和服務(wù)器的目的端口（端口S1或S2）建立連接。圖中說明了如何使用這些參數(shù)來確保網(wǎng)絡(luò)中的連接是唯一可識別的，即使是在多個(gè)連接共享相同的服務(wù)端端口的情況下。

????????這種連接的唯一性是通過四元組來實(shí)現(xiàn)的，四元組包括源IP地址、源端口、目的IP地址和目的端口。使用這些信息，網(wǎng)絡(luò)中的每個(gè)連接都可以被精確識別，從而允許數(shù)據(jù)準(zhǔn)確地發(fā)送和接收。

2.9 TCP頭部中的選項(xiàng)字段及其特性

2.9.1 TCP選項(xiàng)的特性

????????在TCP/IP協(xié)議中，TCP頭部的"偏移量"字段用來指示TCP頭部有多大。這里的一些關(guān)鍵點(diǎn)解釋如下：

2.9.1.1 偏移量字段

????????TCP頭部中有一個(gè)4位的"偏移量"字段，它表明了頭部有多少個(gè)32位的字。由于這個(gè)字段是4位的，所以它的最大值是1111二進(jìn)制，即15十進(jìn)制。這意味著TCP頭部最長可以是15個(gè)32位字，即60字節(jié)。

????????頭部最小長度：TCP協(xié)議規(guī)定，TCP頭部的最小長度是5個(gè)32位的字，即20字節(jié)。這是因?yàn)門CP頭部必須至少包含基礎(chǔ)的控制信息，如源端口、目的端口、序列號、確認(rèn)號等。

2.9.1.2 選項(xiàng)字段長度

????????既然TCP頭部的最大長度是60字節(jié)（15個(gè)32位字），而基礎(chǔ)頭部是20字節(jié)（5個(gè)32位字），那么選項(xiàng)字段的最大長度就是60 - 20 = 40字節(jié)，即10個(gè)32位字。

????????這個(gè)選項(xiàng)字段允許TCP頭部被擴(kuò)展以包含額外的信息，如最大報(bào)文段大?。∕SS）、窗口縮放因子、選擇性確認(rèn)（SACK）等，這些都是TCP協(xié)議高級特性的一部分。簡單來說，偏移量字段告訴我們TCP頭部除了固定的20字節(jié)基礎(chǔ)部分外，還可以有多少額外的空間用于包含這些選項(xiàng)。

2.9.1.3?標(biāo)準(zhǔn)選項(xiàng)

2.9.1.3.1 mss（最大段大?。?/span>

????????該選項(xiàng)允許協(xié)商TCP段的最大大小，以避免昂貴的分段操作。此選項(xiàng)在連接時(shí)使用。長度為4個(gè)字節(jié)。

2.9.1.3.2 無操作（NOP）

????????這是一個(gè)空選項(xiàng)，用于確保下一個(gè)選項(xiàng)從32位字的開始位置對齊。如果需要，可以連續(xù)使用多個(gè)NOP。長度為1個(gè)字節(jié)。

2.9.1.3.3 選項(xiàng)列表結(jié)束

????????該選項(xiàng)確保選項(xiàng)的結(jié)束位置與32位字對齊。長度為1個(gè)字節(jié)。

????????這些選項(xiàng)提供了TCP頭部的靈活性和擴(kuò)展性，允許在連接建立時(shí)進(jìn)行各種參數(shù)的協(xié)商和調(diào)整。

????????兩種高級功能的選項(xiàng)，窗口縮放因子和時(shí)間戳，它們都是為了提高網(wǎng)絡(luò)通信效率而設(shè)計(jì)的。

2.9.1.3.4.窗口縮放因子（Window Scale）

????????在TCP連接中，窗口大小（Window Size）字段通常用于控制發(fā)送方可以發(fā)送的數(shù)據(jù)量，而不需要等待接收方的確認(rèn)，這是為了實(shí)現(xiàn)流量控制。在原始的TCP協(xié)議中，這個(gè)字段是16位的，因此最大可以表示的窗口大小是 2^{16}-1 字節(jié)。

????????但是對于高速網(wǎng)絡(luò)或者延遲較高的網(wǎng)絡(luò)（如衛(wèi)星通信），這個(gè)大小可能不足以有效利用可用的帶寬。為了解決這個(gè)限制，RFC 1323 引入了窗口縮放選項(xiàng)，它允許窗口大小字段的值乘以2^n（其中n是窗口縮放因子，最高可到14），從而允許更大范圍內(nèi)的窗口大小，增加了流量控制的靈活性。

2.9.1.3.5 數(shù)據(jù)時(shí)間戳（Timestamps）

????????時(shí)間戳選項(xiàng)用于記錄發(fā)送和確認(rèn)數(shù)據(jù)包的時(shí)間。這個(gè)選項(xiàng)包括兩個(gè)值：一個(gè)是發(fā)送時(shí)間戳，另一個(gè)是最近一次收到的確認(rèn)消息的時(shí)間戳。

????????當(dāng)數(shù)據(jù)發(fā)送者發(fā)送數(shù)據(jù)時(shí)，它會在時(shí)間戳選項(xiàng)的第一個(gè)字段中放入當(dāng)前的時(shí)間戳。當(dāng)接收者回復(fù)確認(rèn)時(shí)，它會在確認(rèn)包的時(shí)間戳選項(xiàng)的第二個(gè)字段中包含它最后一次收到數(shù)據(jù)包時(shí)的時(shí)間戳。

????????這樣，發(fā)送者收到確認(rèn)時(shí)，就可以通過比較自己的當(dāng)前時(shí)間戳和確認(rèn)包中的時(shí)間戳來計(jì)算往返時(shí)間（RTT）。這個(gè)計(jì)算對于動(dòng)態(tài)調(diào)整數(shù)據(jù)發(fā)送速率和檢測網(wǎng)絡(luò)擁堵非常有用。

????????簡單來說，窗口縮放因子用來增加TCP流量控制的窗口大小，而時(shí)間戳用來計(jì)算數(shù)據(jù)包的往返時(shí)間，這兩個(gè)功能都是為了提升在不同網(wǎng)絡(luò)條件下TCP協(xié)議的性能。

2.9.1.3.6 選擇性確認(rèn)的協(xié)商（rfc 2018）

????????TCP選項(xiàng)中的"選擇性確認(rèn)"（Selective Acknowledgment，簡稱SACK），是由RFC 2018定義的一種機(jī)制，它允許在數(shù)據(jù)傳輸過程中更有效地處理丟包情況。

????????選擇性確認(rèn)的協(xié)商：當(dāng)建立TCP連接時(shí)，通信雙方可以通過TCP頭部中的選項(xiàng)字段來協(xié)商是否使用SACK。如果雙方都支持并同意使用SACK，那么它們可以在傳輸過程中使用此功能。

????????選擇性確認(rèn)的工作原理：在標(biāo)準(zhǔn)的TCP確認(rèn)中，如果數(shù)據(jù)包丟失，接收方只能確認(rèn)它順序接收的最后一個(gè)數(shù)據(jù)包。發(fā)送方必須從那個(gè)點(diǎn)開始重傳丟失的數(shù)據(jù)包及其后的所有數(shù)據(jù)包，即使有些數(shù)據(jù)包可能已經(jīng)被接收方正確接收。

????????SACK則允許接收方明確告知發(fā)送方哪些數(shù)據(jù)已經(jīng)被成功接收。這是通過在確認(rèn)（ACK）報(bào)文中包含已成功接收的數(shù)據(jù)塊的信息來實(shí)現(xiàn)的。因此，發(fā)送方只需要重傳那些實(shí)際上丟失的數(shù)據(jù)段，而不是所有后續(xù)的數(shù)據(jù)。

????????選擇性確認(rèn)優(yōu)化了TCP的錯(cuò)誤恢復(fù)過程，特別是在網(wǎng)絡(luò)條件不佳或丟包率較高的環(huán)境中，它可以顯著提高數(shù)據(jù)傳輸?shù)男?。通過只重傳丟失的數(shù)據(jù)，而不是連續(xù)的數(shù)據(jù)序列，它減少了不必要的網(wǎng)絡(luò)流量和可能的擁塞，從而提高了TCP連接的整體性能。

2.10 TCP數(shù)據(jù)包序列的捕獲示例

????????這是在Web請求的開始時(shí)使用`tcpdump`工具捕獲的。這個(gè)序列顯示了TCP三次握手的過程，以及隨后的數(shù)據(jù)傳輸。以下是對這個(gè)捕獲的簡要解釋：

rfc-1323 et rfc 2018 (relevé avec tcpdump lors d’un début de requête web)
linux1.1082 > 206.132.41.203.www: S 2047350264:2047350264(0) win 16060 <mss
1460,sackOK,timestamp 43244276>
206.132.41.203.www > linux1.1082: S 2319802134:2319802134(0) ack 2047350265 win
32120 <mss 1460, sackOK, timestamp 190973015>
linux1.1082 > 206.132.41.203.www: . ack 2319802135 win 16060 <nop,nop,timestamp
43244311 190973015>
linux1.1082 > 206.132.41.203.www: P 2047350265:2047350896(631) ack 2319802135 win
16060 <nop, nop, timestamp 43244311 190973015>
206.132.41.203.www > linux1.1082: . ack 2047350896 win 31856 <nop, nop, timestamp
190973051 43244311>)
206.132.41.203.www > linux1.1082: P 2319802135:2319803583(1448) ack 2047350896 win
31856 <nop, nop, timestamp 190973063 43244311>
linux1.1082 > 206.132.41.203.www: . ack 2319803583 win 14612 <nop,nop,timestamp
43244367 190973063>
206.132.41.203.www > linux1.1082: P 2319803583:2319805031(1448) ack 2047350896 win
31856 <nop, nop, timestamp 190973063 43244311>

2.10.1 三次握手

????????`linux1.1082 > 206.132.41.203.www: S ...`: 這是三次握手的第一步，其中`linux1`發(fā)送一個(gè)SYN段到`206.132.41.203`的www端口。它還提供了一些TCP選項(xiàng)，如MSS（最大段大小）、SACK（選擇性確認(rèn)）和時(shí)間戳。

????????`206.132.41.203.www > linux1.1082: S ...`: 這是三次握手的第二步，`206.132.41.203`回應(yīng)了一個(gè)SYN-ACK段。

???????? `linux1.1082 > 206.132.41.203.www: . ...`: 這是三次握手的第三步，`linux1`發(fā)送了一個(gè)ACK段。

2.10.2?數(shù)據(jù)傳輸

?????????`linux1.1082 > 206.132.41.203.www: P ...`: `linux1`發(fā)送了一個(gè)包含數(shù)據(jù)的段（由P標(biāo)志表示）。

????????`206.132.41.203.www > linux1.1082: . ...`: `206.132.41.203`確認(rèn)了收到的數(shù)據(jù)。

????????`206.132.41.203.www > linux1.1082: P ...`: `206.132.41.203`發(fā)送了一個(gè)包含數(shù)據(jù)的段。

????????`linux1.1082 > 206.132.41.203.www: . ...`: `linux1`確認(rèn)了收到的數(shù)據(jù)。

????????`206.132.41.203.www > linux1.1082: P ...`: `206.132.41.203`再次發(fā)送了一個(gè)包含數(shù)據(jù)的段。

????????這個(gè)捕獲顯示了TCP連接的建立、數(shù)據(jù)的交換以及數(shù)據(jù)的確認(rèn)。從中，我們可以看到TCP選項(xiàng)如MSS、SACK和時(shí)間戳在連接建立過程中的使用，這些選項(xiàng)幫助優(yōu)化和提高TCP連接的性能。

2.11 如何使用`netstat`命令來查看和控制TCP連接

????????連接控制：`netstat`命令

2.11.1?使用`netstat`命令

????????在Unix/Linux系統(tǒng)上，使用`-a`選項(xiàng)；在Windows系統(tǒng)上，使用`-p tcp`選項(xiàng)。

2.11.2 示例輸出

[linux30]$ netstat -atn
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale      Adresse distante         Etat
tcp     0     0     0.0.0.0:32768         0.0.0.0:*             LISTEN
tcp     0     0     127.0.0.1:32769       0.0.0.0:*             LISTEN
tcp     0     0     0.0.0.0:111           0.0.0.0:*             LISTEN
tcp     0     0     0.0.0.0:6000          0.0.0.0:*             LISTEN
tcp     0     0     0.0.0.0:22            0.0.0.0:*             LISTEN
tcp     0     0     0.0.0.0:631           0.0.0.0:*             LISTEN
tcp     0     272   192.168.100.30:22 192.168.100.18:1994     ESTABLISHED

?2.11.3?解釋

????????Proto`：協(xié)議類型，這里是TCP。

????????Recv-Q`和`Send-Q`：接收和發(fā)送隊(duì)列中的數(shù)據(jù)量。

????????Adresse locale`：本地地址和端口。

????????Adresse distante`：遠(yuǎn)程地址和端口。

????????Etat`：連接狀態(tài)。例如，`LISTEN`表示正在監(jiān)聽連接請求，`ESTABLISHED`表示已建立的連接。

????????通過`netstat`命令，用戶可以查看系統(tǒng)上的所有活動(dòng)TCP連接和監(jiān)聽的端口，這對于網(wǎng)絡(luò)故障排查和系統(tǒng)監(jiān)控非常有用。

2.12?TCP如何與應(yīng)用程序交互以及數(shù)據(jù)如何在TCP和應(yīng)用程序之間流動(dòng)

????????TCP與應(yīng)用程序

????????數(shù)據(jù)緩沖：應(yīng)用程序?qū)?shù)據(jù)發(fā)送到其發(fā)送緩沖區(qū)（Buffer émission），而TCP從其接收緩沖區(qū)（Buffer réception）讀取數(shù)據(jù)發(fā)送給應(yīng)用程序。

????????TCP的工作方式：TCP將數(shù)據(jù)從發(fā)送緩沖區(qū)取出并按照其自己的流控制規(guī)則進(jìn)行發(fā)送。同樣，它將接收到的數(shù)據(jù)放入接收緩沖區(qū)，供應(yīng)用程序讀取。

????????應(yīng)用程序的控制：應(yīng)用程序沒有直接控制TCP如何發(fā)送或接收數(shù)據(jù)。TCP根據(jù)其內(nèi)部的流控制、擁塞控制和可靠性機(jī)制來決定何時(shí)發(fā)送數(shù)據(jù)。

????????這種設(shè)計(jì)允許TCP為應(yīng)用程序提供一個(gè)可靠的、面向字節(jié)流的通信服務(wù)，而應(yīng)用程序不需要關(guān)心底層的網(wǎng)絡(luò)細(xì)節(jié)。

2.13 TCP流量控制是TCP協(xié)議提供的一種機(jī)制

????????確保發(fā)送方不會溢出接收方的緩沖區(qū)。這是一個(gè)端到端的控制，意味著只有發(fā)送方和接收方參與此過程，中間的路由器不存儲有關(guān)TCP連接的狀態(tài)信息，因此不參與流量控制。流量控制的細(xì)節(jié)如下：

2.13.1?窗口字段（Window）

????????TCP頭部中的窗口字段用于流量控制。它告訴發(fā)送方接收方的緩沖區(qū)還能接受多少字節(jié)的數(shù)據(jù)，也就是接收窗口的大小。

2.13.2?接收緩沖區(qū)

????????接收方有一個(gè)固定大小的緩沖區(qū)（例如8KB、16KB、32KB等），用來暫存接收到的數(shù)據(jù)，直到應(yīng)用程序讀取它。

2.13.3?緩沖區(qū)溢出的防范

????????如果接收應(yīng)用程序沒有足夠快地讀取數(shù)據(jù)，接收緩沖區(qū)可能會被填滿。為了防止溢出，接收方通過減小窗口字段的值來通知發(fā)送方減慢發(fā)送速度，甚至可以將窗口大小減到0，暫停數(shù)據(jù)發(fā)送。

2.13.4?窗口關(guān)閉（Win=0）情況

????????如果接收方將窗口大小設(shè)為0，發(fā)送方會定期（初始間隔為5秒，之后會翻倍，但通常不超過1分鐘的上限）發(fā)送一個(gè)探測數(shù)據(jù)段來檢測接收方的窗口大小是否有變化。這樣做是為了在接收方應(yīng)用程序開始讀取數(shù)據(jù)，清空緩沖區(qū)后，能夠恢復(fù)數(shù)據(jù)傳輸。

2.13.5?窗口重新打開

????????當(dāng)接收應(yīng)用程序處理了足夠的數(shù)據(jù)，釋放了緩沖區(qū)空間后，接收方會發(fā)送一個(gè)更新的窗口大小給發(fā)送方，從而可以繼續(xù)數(shù)據(jù)傳輸。

????????這個(gè)機(jī)制確保了在網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)姆€(wěn)定性和效率，防止因?yàn)榻邮辗教幚聿患皶r(shí)而導(dǎo)致的數(shù)據(jù)丟失或重傳。

2.14 TCP擁塞控制

????????TCP協(xié)議中用來解決網(wǎng)絡(luò)擁塞問題的一套機(jī)制。盡管TCP的流量控制機(jī)制可以防止接收方被溢出，但它不足以應(yīng)對整個(gè)網(wǎng)絡(luò)中的擁塞問題。網(wǎng)絡(luò)擁塞通常是由于網(wǎng)絡(luò)中的一部分（如某個(gè)路由器或鏈路）負(fù)載過重，無法處理通過的所有數(shù)據(jù)包。以下是TCP協(xié)議如何應(yīng)對這一問題：

2.14.1?擁塞的表現(xiàn)

????????當(dāng)網(wǎng)絡(luò)中的某個(gè)部分過載時(shí)，數(shù)據(jù)包可能會在路由器的隊(duì)列中排隊(duì)等待傳輸，導(dǎo)致延遲增加。

????????在嚴(yán)重?fù)砣那闆r下，路由器可能會丟棄數(shù)據(jù)包，這會導(dǎo)致發(fā)送方必須重傳這些數(shù)據(jù)包，從而進(jìn)一步加劇網(wǎng)絡(luò)擁塞。

2.14.2 擁塞控制機(jī)制

????????慢啟動(dòng)（Slow Start）：當(dāng)一個(gè)新的TCP連接建立時(shí)，發(fā)送方開始以較小的擁塞窗口發(fā)送數(shù)據(jù)，隨著每次成功的數(shù)據(jù)傳輸，窗口大小指數(shù)增長，直到達(dá)到一個(gè)閾值。

????????擁塞避免（Congestion Avoidance）：達(dá)到閾值后，窗口大小增長速度變?yōu)榫€性，以避免引起網(wǎng)絡(luò)擁塞。

????????快重傳（Fast Retransmit）：如果發(fā)送方接收到三個(gè)重復(fù)的ACK，它會立即重傳丟失的數(shù)據(jù)包，而不是等待重傳計(jì)時(shí)器超時(shí)。

????????快恢復(fù)（Fast Recovery）：在快重傳之后，TCP減少其擁塞窗口大小而不是重新開始慢啟動(dòng)，以更快地從丟包情況中恢復(fù)。

2.14.3 適應(yīng)網(wǎng)絡(luò)變化

????????TCP使用這些機(jī)制來動(dòng)態(tài)調(diào)整其發(fā)送速率，以響應(yīng)網(wǎng)絡(luò)條件的變化。例如，如果檢測到數(shù)據(jù)包丟失（可能是由于網(wǎng)絡(luò)擁塞），TCP會減少其發(fā)送速率。

2.14.4 不同網(wǎng)絡(luò)段的速率差異

????????當(dāng)TCP流經(jīng)不同速率的網(wǎng)絡(luò)段時(shí)（比如從100Mb/s降到2Mb/s），擁塞控制機(jī)制會幫助減少數(shù)據(jù)發(fā)送速率，以適應(yīng)較慢鏈路的容量，從而防止在這些鏈路上發(fā)生擁塞。

????????總的來說，TCP的擁塞控制機(jī)制是為了在整個(gè)網(wǎng)絡(luò)中平衡負(fù)載，避免擁塞，同時(shí)確保數(shù)據(jù)傳輸?shù)男屎涂煽啃浴?/span>

????????用來適應(yīng)和緩解網(wǎng)絡(luò)擁塞。這個(gè)機(jī)制包括多個(gè)部分，如往返時(shí)間（RTT）的測量，慢啟動(dòng)，以及快速恢復(fù)等：

2.14.4.1?往返時(shí)間（RTT）的確定

????????RTT是指數(shù)據(jù)包從發(fā)送方發(fā)送到接收方，再由接收方發(fā)送確認(rèn)回到發(fā)送方所需的時(shí)間。

????????TCP使用特定的選項(xiàng)（如時(shí)間戳）來測量RTT，并據(jù)此調(diào)整重傳計(jì)時(shí)器。正確的重傳計(jì)時(shí)器設(shè)置對于有效地檢測丟包和避免不必要的重傳至關(guān)重要。

2.14.4.2?慢啟動(dòng)（Slow Start）機(jī)制

????????TCP使用一個(gè)稱為擁塞窗口（cwnd，congestion window）的變量來限制在確認(rèn)收到數(shù)據(jù)之前可以發(fā)送的最大數(shù)據(jù)量。

????????連接開始時(shí)，擁塞窗口被設(shè)置為一個(gè)最大報(bào)文段大?。∕SS）。隨著每個(gè)RTT，擁塞窗口的大小翻倍，直到達(dá)到一個(gè)預(yù)設(shè)的閾值。

????????當(dāng)發(fā)生擁塞（比如丟包事件）時(shí)，擁塞窗口大小被大幅降低（通常是當(dāng)前大小的一半），并且慢啟動(dòng)過程重新開始。

2.14.4.3?擁塞避免和快速恢復(fù)

????????當(dāng)擁塞窗口的大小超過閾值時(shí)，其增長方式從指數(shù)增長變?yōu)榫€性增長，這是為了避免引起網(wǎng)絡(luò)擁塞。

????????快速恢復(fù)機(jī)制用于處理丟包情況。如果發(fā)送方收到了重復(fù)的ACK，它意味著網(wǎng)絡(luò)中存在丟包。此時(shí)，TCP會立即重傳丟失的數(shù)據(jù)段，而不是等待重傳計(jì)時(shí)器超時(shí)。

????????在多個(gè)連續(xù)的丟包情況下，選擇性確認(rèn)（SACK）可以用來僅重傳丟失的數(shù)據(jù)段，而不是整個(gè)數(shù)據(jù)序列。

????????這些機(jī)制共同工作，使得TCP能夠適應(yīng)網(wǎng)絡(luò)中的擁塞狀況，通過動(dòng)態(tài)調(diào)整數(shù)據(jù)傳輸速率來優(yōu)化性能，同時(shí)減少因網(wǎng)絡(luò)擁塞造成的數(shù)據(jù)丟失。

2.15?TCP的Path MTU Discovery機(jī)制

????????（由RFC 1191定義）是為了避免在TCP層發(fā)生分段而設(shè)計(jì)的。這個(gè)機(jī)制的目的是發(fā)現(xiàn)并使用最佳的最大傳輸單元（MTU）大小，以避免在網(wǎng)絡(luò)路徑上發(fā)生分段。以下是該機(jī)制的詳細(xì)說明：

2.15.1?問題

????????在發(fā)送TCP數(shù)據(jù)包時(shí)，發(fā)送方的TCP層通常假定使用出口IP接口的MTU大小。例如，在以太網(wǎng)上，默認(rèn)MTU通常是1500字節(jié)。

????????但是，在數(shù)據(jù)包到達(dá)接收方的路徑上，可能存在MTU更小的鏈路（比如700字節(jié)）。如果TCP數(shù)據(jù)包的大小超過這個(gè)鏈路的MTU，那么該鏈路上的路由器需要對數(shù)據(jù)包進(jìn)行分段處理，這可能導(dǎo)致效率降低和其他問題。

2.15.2?解決方案（Path MTU Discovery）

????????在發(fā)送TCP數(shù)據(jù)包時(shí)，設(shè)置IP頭部的“不分段”（DF，Don't Fragment）位。這告訴路由器不要對這些數(shù)據(jù)包進(jìn)行分段。

????????如果一個(gè)數(shù)據(jù)包的大小超過路徑上某個(gè)鏈路的MTU，攜帶DF位的數(shù)據(jù)包不會被分段，而是被路由器丟棄。同時(shí)，路由器會向發(fā)送方發(fā)送一個(gè)ICMP（Internet Control Message Protocol）消息，告知數(shù)據(jù)包因?yàn)樘蠖粊G棄，并通常提供可以通過該鏈路傳輸?shù)淖畲驧TU大小。

????????接收到ICMP消息后，發(fā)送方知道了路徑上的最大MTU大小，并將后續(xù)數(shù)據(jù)包的大小調(diào)整到這個(gè)MTU值以下，以避免分段。

????????這個(gè)機(jī)制確保了TCP數(shù)據(jù)包在整個(gè)傳輸路徑上不會被分段，從而提高了網(wǎng)絡(luò)效率和可靠性。通過動(dòng)態(tài)發(fā)現(xiàn)并適應(yīng)路徑上的最小MTU，TCP可以優(yōu)化數(shù)據(jù)包的大小，確保在網(wǎng)絡(luò)中的順暢傳輸。

這里是具體步驟：

2.15.2.1?發(fā)射第一個(gè)數(shù)據(jù)包????????

????????發(fā)送方（Em）向接收方（Rec）發(fā)送一個(gè)TCP數(shù)據(jù)包，其中序列號（seq）為1，數(shù)據(jù)包的大小為1448字節(jié)。這個(gè)尺寸是根據(jù)最大傳輸單元（MTU）計(jì)算得出的（1500字節(jié)的以太網(wǎng)MTU減去20字節(jié)的IP頭部、12字節(jié)的TCP選項(xiàng)和20字節(jié)的TCP頭部）。

????????使用tcpdump工具可以捕獲到這個(gè)數(shù)據(jù)包的信息，例如序列號、大小、確認(rèn)號（ack），以及TCP窗口大?。╳in）等。

2.15.2.2 接收到ICMP消息

????????當(dāng)這個(gè)TCP數(shù)據(jù)包到達(dá)一個(gè)MTU只有700字節(jié)的中間路由器時(shí)，由于數(shù)據(jù)包大小超過了這個(gè)路由器的MTU，并且數(shù)據(jù)包設(shè)置了DF位，路由器將該數(shù)據(jù)包丟棄。

????????同時(shí)，路由器向發(fā)送方（Em）發(fā)送了一個(gè)ICMP消息，表明需要進(jìn)行分段（need to frag），并提供了能夠處理的最大MTU大小（700字節(jié)）。

2.15.2.3 調(diào)整數(shù)據(jù)包大小

????????發(fā)送方（Em）收到ICMP消息后，理解需要減小數(shù)據(jù)包的大小。新的數(shù)據(jù)包大小被調(diào)整為648字節(jié)（700字節(jié)的MTU減去12字節(jié)的TCP選項(xiàng)、20字節(jié)的TCP頭部和20字節(jié)的IP頭部）。

????????隨后，發(fā)送方開始發(fā)送新的大小為648字節(jié)的TCP數(shù)據(jù)包。

????????這個(gè)過程展示了Path MTU Discovery如何在實(shí)際網(wǎng)絡(luò)環(huán)境中工作，它使得發(fā)送方能夠動(dòng)態(tài)地調(diào)整TCP數(shù)據(jù)包的大小，以適應(yīng)網(wǎng)絡(luò)路徑中的最小MTU，從而避免在路由器處的分段，提高數(shù)據(jù)傳輸?shù)男省?/span>

3. UDP協(xié)議

3.1?UDP（用戶數(shù)據(jù)報(bào)協(xié)議）數(shù)據(jù)報(bào)的結(jié)構(gòu)

????????UDP頭部由以下幾部分組成：

????????源端口（Port Source）：這個(gè)字段標(biāo)識了發(fā)送數(shù)據(jù)報(bào)的應(yīng)用程序。

????????目的端口（Port Destination）：這個(gè)字段標(biāo)識了數(shù)據(jù)報(bào)的目的地應(yīng)用程序。

????????長度（Longueur）：這個(gè)字段表示整個(gè)UDP數(shù)據(jù)報(bào)的長度，包括UDP頭部和數(shù)據(jù)。

????????校驗(yàn)和（Somme de contr?le）：這個(gè)字段用于檢查數(shù)據(jù)報(bào)在傳輸過程中是否出現(xiàn)錯(cuò)誤。

????????數(shù)據(jù)（Données utiles）：這部分包含了實(shí)際傳輸?shù)男畔⒒驊?yīng)用數(shù)據(jù)。

????????UDP是一個(gè)無連接的協(xié)議，它不提供TCP所提供的各種保證，如數(shù)據(jù)到達(dá)確認(rèn)、有序傳輸和重傳機(jī)制。因此，UDP頭部比TCP頭部簡單得多，使其在某些需要快速傳輸且可以容忍數(shù)據(jù)丟失的應(yīng)用場景中更為有效，如實(shí)時(shí)視頻或音頻傳輸。

3.2?特點(diǎn)

????????UDP（用戶數(shù)據(jù)報(bào)協(xié)議）是一種簡單的網(wǎng)絡(luò)通信協(xié)議：

????????a. 無連接：UDP不建立持久的連接，發(fā)送數(shù)據(jù)之前不需要在兩端建立連接。這意味著發(fā)送方和接收方之間不會有握手過程。

????????b.無流量控制：UDP不進(jìn)行流量控制，它不調(diào)整發(fā)送數(shù)據(jù)的速度以匹配接收方的處理速度。

????????c. 無確保數(shù)據(jù)送達(dá)：UDP不保證數(shù)據(jù)包的送達(dá)，也就是說，發(fā)送方不會得到是否成功送達(dá)接收方的確認(rèn)。如果數(shù)據(jù)包丟失，UDP不會嘗試重發(fā)。

????????d. 面向消息：UDP是一個(gè)面向消息的協(xié)議，它保留了消息的邊界。這意味著每個(gè)UDP數(shù)據(jù)包是獨(dú)立的，接收方得到的消息將保持發(fā)送時(shí)的數(shù)據(jù)邊界，不會像TCP那樣進(jìn)行流式傳輸。

????????UDP是基于數(shù)據(jù)報(bào)的通信協(xié)議，它發(fā)送的數(shù)據(jù)單位是消息（或稱數(shù)據(jù)報(bào)）。在UDP中，每個(gè)發(fā)送的消息都是獨(dú)立的，并且消息在網(wǎng)絡(luò)中的傳輸也是獨(dú)立的，不像TCP那樣是一個(gè)連續(xù)的數(shù)據(jù)流。

????????接收方收到的數(shù)據(jù)將保持發(fā)送方發(fā)送時(shí)的數(shù)據(jù)結(jié)構(gòu)，即數(shù)據(jù)的邊界是對齊的。這就是所謂的“模式消息”特性。例如，如果發(fā)送方發(fā)送了兩個(gè)消息，每個(gè)消息包含100字節(jié)的數(shù)據(jù)，那么接收方也將分別接收到兩個(gè)100字節(jié)的消息。這與TCP不同，TCP會將所有發(fā)送的數(shù)據(jù)作為一個(gè)連續(xù)流處理，接收方可能會在一個(gè)單獨(dú)的數(shù)據(jù)塊中接收到部分或全部數(shù)據(jù)，而不一定保持原始消息的邊界。簡單來說，UDP保留了發(fā)送時(shí)每個(gè)消息的完整性和邊界，而不會將多個(gè)消息合并或拆分。

????????由于這些特性，UDP通常用于那些對實(shí)時(shí)性要求較高的應(yīng)用，如實(shí)時(shí)視頻會議、在線游戲或域名系統(tǒng)（DNS）查詢，這些應(yīng)用可以容忍一些數(shù)據(jù)包的丟失，但要求低延遲和低開銷。

3.3?TCP和UDP在數(shù)據(jù)傳輸中對數(shù)據(jù)對齊方式的不同處理

3.3.1 TCP（傳輸控制協(xié)議）

????????它被描述為面向“字節(jié)流”的，意味著數(shù)據(jù)被視為一個(gè)連續(xù)的流，沒有固定的邊界。因此，發(fā)送方發(fā)送的數(shù)據(jù)可以在接收方那里被分割成不同大小的片段。例如，即使發(fā)送方將數(shù)據(jù)作為一個(gè)單獨(dú)的大塊發(fā)送，接收方也可能通過幾個(gè)小塊接收到全部數(shù)據(jù)，這就是所謂的不保證“數(shù)據(jù)幀”的對齊。

3.3.2 UDP（用戶數(shù)據(jù)報(bào)協(xié)議）

????????它是面向“消息”的，這意味著數(shù)據(jù)在發(fā)送和接收時(shí)保持其邊界。發(fā)送方發(fā)送的每個(gè)消息作為一個(gè)單獨(dú)的單位在網(wǎng)絡(luò)中傳輸，并且作為同樣大小的一個(gè)單位被接收方接收。這保證了數(shù)據(jù)的對齊，接收方獲取的數(shù)據(jù)結(jié)構(gòu)和發(fā)送時(shí)完全一致。

????????圖中的黑線代表數(shù)據(jù)的發(fā)送和接收，可以看到TCP的數(shù)據(jù)在接收時(shí)可能會與發(fā)送時(shí)不一致，而UDP保持了數(shù)據(jù)的一致性。這種特性使得UDP適用于那些需要維護(hù)數(shù)據(jù)邊界的應(yīng)用場景，如視頻流或VoIP通話。

4. 應(yīng)用層協(xié)議的實(shí)現(xiàn)和它們與數(shù)據(jù)編碼及會話概念的關(guān)系

4.1?應(yīng)用層協(xié)議的實(shí)

????????應(yīng)用層協(xié)議由應(yīng)用程序?qū)崿F(xiàn)，有專門的應(yīng)用程序接口（API）來支持網(wǎng)絡(luò)通信。

????????Sockets（BSD）：在Berkeley Software Distribution（BSD）版本的UNIX操作系統(tǒng)中引入，把網(wǎng)絡(luò)通信視為文件操作。開發(fā)者需要自己實(shí)現(xiàn)通信協(xié)議的邏輯。

????????Transport Services API：IETF的草案中提出了一種通用API，目的是提供一個(gè)標(biāo)準(zhǔn)的接口以支持不同的傳輸協(xié)議。

????????RPC（遠(yuǎn)程過程調(diào)用）：隱藏了網(wǎng)絡(luò)通信的復(fù)雜性，允許開發(fā)者像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)程服務(wù)器上的過程。

????????CORBA（公共請求代理架構(gòu)：是面向?qū)ο缶幊痰囊粋€(gè)擴(kuò)展，用于分布式應(yīng)用程序的開發(fā)。

????????還提到了存在許多特定用途的中間件。

4.2?數(shù)據(jù)的編碼

????????文本協(xié)議：如SMTP、HTTP（1.x）、SIP、SDP等，這些協(xié)議使用簡單的文本格式，易于讀取和調(diào)試。

????????編碼協(xié)議：

????????ASN.1/BER/PER：用于如H.323和SNMP等協(xié)議，提供了一種結(jié)構(gòu)化數(shù)據(jù)的描述和編碼方法。

????????XDR（外部數(shù)據(jù)表示）：用于NFS和NIS等協(xié)議，提供了一種在不同系統(tǒng)之間轉(zhuǎn)換和編碼數(shù)據(jù)的標(biāo)準(zhǔn)方法。

????????會話概念：某些協(xié)議，如SIP、SDP、BEEP，以及Web上的cookies，都包含了會話的概念。在這些協(xié)議中，會話用于在一系列的交換信息中保持狀態(tài)和上下文信息。

????????總體來說，應(yīng)用層協(xié)議是網(wǎng)絡(luò)通信的高層實(shí)現(xiàn)，它們依賴于傳輸層協(xié)議（如TCP和UDP）來實(shí)現(xiàn)端到端的數(shù)據(jù)傳輸。這些協(xié)議為不同類型的網(wǎng)絡(luò)交互提供了必要的規(guī)則和結(jié)構(gòu)，從而使得網(wǎng)絡(luò)服務(wù)能夠進(jìn)行。

4.3 HTTP請求的典型格式

????????它展示了一個(gè)客戶端（如Web瀏覽器）如何向服務(wù)器請求一個(gè)網(wǎng)頁。這個(gè)過程包含以下幾個(gè)部分：

GET /index.fr.php HTTP/1.1
Host: www.enst-bretagne.fr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
Accept: text/xml,application/xml,.....
Accept-Language: fr,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.enst-bretagne.fr/

4.3.1?請求行

????????GET /index.fr.php HTTP/1.1：這是請求行，它指示使用GET方法請求名為`/index.fr.php`的資源，使用的HTTP版本是1.1。

4.3.2 請求頭部

????????Host: www.enst-bretagne.fr`：指定請求的服務(wù)器。

????????User-Agent: Mozilla/5.0...`：告知服務(wù)器客戶端使用的瀏覽器類型和版本。

????????Accept: text/xml,application/xml,...`：告知服務(wù)器客戶端能夠處理的內(nèi)容類型。

????????Accept-Language: fr,en;q=0.5`：告知服務(wù)器客戶端首選的語言。

????????Accept-Encoding: gzip,deflate`：告知服務(wù)器客戶端可以接受的編碼類型，通常用于壓縮。

????????Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7`：指明客戶端可以接受的字符集。

????????Keep-Alive: 300`：請求服務(wù)器保持連接一段時(shí)間，而不是請求后立即關(guān)閉。

????????Connection: keep-alive`：指示連接應(yīng)保持活躍狀態(tài)。

????????Referer: http://www.enst-bretagne.fr/`：告知服務(wù)器用戶是從哪個(gè)頁面鏈接過來的。

????????請求頭部包含了很多關(guān)鍵信息，使得服務(wù)器可以根據(jù)客戶端的能力和偏好返回適當(dāng)?shù)捻憫?yīng)。例如，服務(wù)器可以根據(jù)`Accept-Language`頭部返回不同語言的網(wǎng)頁版本，也可以根據(jù)`User-Agent`提供特定瀏覽器兼容的內(nèi)容。

4.4?HTTP響應(yīng)的組成部分

????????服務(wù)器在成功處理客戶端的GET請求后返回了一個(gè)網(wǎng)頁。

HTTP/1.1 200 OK
Date: Fri, 09 Jul 2004 09:20:06 GMT
Server: Apache/1.3.22 (Unix) PHP/4.0.4pl1 mod_fastcgi/2.2.10 PHP/3.0.....
X-Powered-By: PHP/4.0.4pl1
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
Content-Language: fr
<HTML>
<HEAD>
<TITLE>[ENST Bretagne] école formation ingénieur</TITLE>
<!-L’école nationale supérieure des télécommunications de Bretagne offre
un large choix de formation: ingénieur, mastères, télécom, thèse, DEA...->
<meta name="robots" content="noindex,nofollow">
<meta name="description" content="L’école nationale supérieure des télécommunications de Bretagne offre un
large choix de formation: ingénieur, mastères, télécom, thèse, DEA...">
<meta name="keywords" content="école ingénieur, formation ingénieur, école nationale supérieure
télécommunications, Bretagne, mastères, télécom, thèse, DEA, ENST, GET, étude télécommunication,
enseignement supérieur, technologie information, communication, TIC, concours, mines-ponts, alternance,
projets européens, recherche, laboratoire, grandes écoles, formation continue, dipl?me, Brest, Rennes,
ECOLE INGENIEUR, FORMATION INGENIEUR">
<LINK rel="stylesheet" href="css/style.css">

4.4.1?狀態(tài)行

????????`HTTP/1.1 200 OK`：狀態(tài)行顯示了HTTP版本（1.1），狀態(tài)碼（200）和狀態(tài)消息（OK），表示請求已成功處理。

4.4.2?響應(yīng)頭部

????????Date: Fri, 09 Jul 2004 09:20:06 GMT`：響應(yīng)生成的日期和時(shí)間。

????????Server: Apache/1.3.22...`：服務(wù)器軟件的信息。

????????X-Powered-By: PHP/4.0.4pl1`：服務(wù)器上運(yùn)行的腳本引擎的版本。

????????Keep-Alive: timeout=15, max=100`：Keep-Alive頭部指示連接保持活動(dòng)的時(shí)間和最大請求數(shù)。

????????Connection: Keep-Alive`：連接將保持打開狀態(tài)，以便客戶端可以繼續(xù)通過同一連接發(fā)送請求。

????????Transfer-Encoding: chunked`：數(shù)據(jù)以一系列塊的形式發(fā)送，不是一次性發(fā)送。

????????Content-Type: text/html`：響應(yīng)內(nèi)容的MIME類型。

????????Content-Language: fr`：響應(yīng)內(nèi)容的語言。

4.4.3?響應(yīng)正文

????????<HTML>`...：實(shí)際的HTML文檔開始，包括頭部（HEAD）和標(biāo)題（TITLE）等。

????????HTML注釋和meta標(biāo)簽提供了頁面內(nèi)容的附加信息，如頁面描述、關(guān)鍵詞、機(jī)器人指令（如不被搜索引擎索引或跟蹤）等。

????????LINK標(biāo)簽指向CSS文件，用于定義頁面的樣式。

????????狀態(tài)碼200表示請求已被成功處理，并且服務(wù)器提供了請求的資源作為響應(yīng)正文。這個(gè)HTML文檔可能包含了文本、圖片鏈接、CSS樣式鏈接、JavaScript腳本鏈接等，瀏覽器會解析這個(gè)HTML文檔并顯示成網(wǎng)頁。

4.5?SMTP（簡單郵件傳輸協(xié)議）交換的例子

????????它展示了電子郵件發(fā)送過程中客戶端（發(fā)送方S）和服務(wù)器（接收方R）之間的通信。SMTP是用于發(fā)送和接收電子郵件的互聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議。以下是交換過程的步驟：

S: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
S: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
S: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
S: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK

4.5.1?MAIL FROM

????????客戶端開始一個(gè)郵件事務(wù)，通過指定發(fā)件人地址：`MAIL FROM:<Smith@Alpha.ARPA>`。

????????服務(wù)器回應(yīng)`250 OK`表示接受了發(fā)件人地址。

4.5.2?RCPT TO

????????客戶端指定收件人地址：`RCPT TO:<Jones@Beta.ARPA>`。

????????服務(wù)器再次回應(yīng)`250 OK`表示接受了收件人地址。

4.5.3 第二個(gè)收件人

????????客戶端嘗試添加另一個(gè)收件人：`RCPT TO:<Green@Beta.ARPA>`。

????????服務(wù)器回應(yīng)`550 No such user here`表示指定的用戶在服務(wù)器上不存在。

4.5.4 第三個(gè)收件人

????????客戶端繼續(xù)添加另一個(gè)收件人：`RCPT TO:<Brown@Beta.ARPA>`。

????????服務(wù)器回應(yīng)`250 OK`表示接受了這個(gè)收件人地址。

4.5.5 DATA

????????客戶端請求開始發(fā)送郵件正文：`DATA`。

????????服務(wù)器回應(yīng)`354 Start mail input; end with <CRLF>.<CRLF>`，指示客戶端可以開始發(fā)送郵件內(nèi)容，并應(yīng)該以一個(gè)點(diǎn)（`.`）在新的一行結(jié)束郵件內(nèi)容。

4.5.6?郵件正文

????????客戶端發(fā)送郵件正文，可能包含多行：`Blah blah blah...`和`...etc. etc. etc.`。

????????客戶端以一個(gè)點(diǎn)（`.`）在新的一行結(jié)束郵件內(nèi)容，符合服務(wù)器的指示。

4.5.7 郵件發(fā)送完成

????????服務(wù)器確認(rèn)郵件已被接收并處理，回應(yīng)`250 OK`。

????????這個(gè)過程遵循RFC 821（SMTP的原始規(guī)范，現(xiàn)在已被RFC 5321更新），顯示了SMTP的基本交互模式，其中客戶端和服務(wù)器之間的每個(gè)步驟都有明確的請求和響應(yīng)。

????????電子郵件的工作原理包括用戶地址的標(biāo)準(zhǔn)格式、客戶端和服務(wù)器工具的使用，以及DNS在電子郵件傳輸中的作用。

4.5.7.1?電子郵件地址格式

????????電子郵件地址通常遵循`用戶名@服務(wù)器名稱.域`的格式。例如，`john.doe@example.com`，其中`john.doe`是用戶名，`example.com`是郵件服務(wù)器所在的域。

4.5.7.2 客戶端工具（MUA：Mail User Agent）

????????MUA是指用戶直接用來處理電子郵件的客戶端應(yīng)用，如Netscape、Outlook、Lotus Notes等。

????????當(dāng)發(fā)送電子郵件時(shí)，客戶端應(yīng)用使用SMTP（簡單郵件傳輸協(xié)議）與郵件服務(wù)器通信。

????????接收郵件時(shí)，客戶端可能使用POP（郵局協(xié)議）或IMAP（互聯(lián)網(wǎng)消息訪問協(xié)議），它們可以是加密的或非加密的。

4.5.7.3?服務(wù)器工具（MTA：Message Transfer Agent）

????????MTA是在后臺處理郵件傳輸?shù)姆?wù)器應(yīng)用，如Microsoft IIS、Sendmail、Postfix等。

????????它們負(fù)責(zé)接收、轉(zhuǎn)發(fā)、傳遞和發(fā)送電子郵件。服務(wù)器之間的通信也使用SMTP。

4.5.7.4?域名系統(tǒng)（DNS）

????????DNS在郵件傳輸中扮演著關(guān)鍵角色，特別是在處理MX（郵件交換）記錄時(shí)。

????????當(dāng)電子郵件被發(fā)送時(shí)，發(fā)送方的郵件服務(wù)器會查詢收件方域名的MX記錄來確定郵件應(yīng)該被送往哪個(gè)郵件服務(wù)器。

????????簡而言之，用戶通過MUA撰寫并發(fā)送郵件，郵件通過SMTP發(fā)送到MTA。MTA可能會查詢DNS來確定下一步如何路由郵件，最終將郵件遞送到收件人的MUA，收件人可以通過POP或IMAP協(xié)議接收郵件。文章來源地址http://www.zghlxwxcb.cn/news/detail-809835.html

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)——第四層：傳輸層以及TCP UDP的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！