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)匀辉谡5臄?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ù)器。文章來源:http://www.zghlxwxcb.cn/news/detail-809835.html
????????簡而言之,用戶通過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)!