計算機網絡（七）——傳輸層協議

傳輸層定義了主機應用程序之間端到端的連通性。

傳輸層中最為常見的兩個協議分別：

• 傳輸控制協議TCP（Transmission Control Protocol）
• 用戶數據包協議UDP（User Datagram Protocol）

1.傳輸控制協議TCP

TCP位於TCP/IP模型的傳輸層，它是一種面向連接的端到端協議。可以為主機提供可靠的數據傳輸。

特點：

1. TCP協議是面向連接的運輸層協議。在數據傳輸前必須建立連接，數據傳輸之后釋放連接。
2. TCP提供可靠的交互服務。所謂可靠是指在傳輸過程中無重復，無丟失，無錯誤。但是同時會增加開銷。
3. 每一條連接都是點對點連接（一對一）
4. 面向字節流。所謂字節流指的是以傳輸過程中流入進程和流出進程的字節序列，雖然傳輸過程中是一個一個數據報，但這只是為了方便傳輸，之后在目的端重新裝配。
5. TCP提供全雙工通信。所謂全雙工是指一端既可以是客戶端，也可以是服務器。

1.1 TCP端口號

端口號用來區分不同的網絡服務。

TCP允許一個主機同時運行多個應用進程。每台主機可以擁有多個應用端口，每對端口號、源和目標IP地址的組合唯一地標識了一個會話。

端口分為知名端口和動態端口。

• 有些網絡服務會使用固定的端口，這類端口稱為知名端口，端口號范圍為0-1023。如FTP、HTTP、Telnet、SNMP服務均使用知名端口。
• 動態端口號范圍從1024到65535，這些端口號可以自定義分配，也就是說許多服務都可以使用這些端口。只要運行的程序向系統提出訪問網絡的申請，那么系統就可以從這些端口號中分配一個供該程序使用。

1.2 TCP頭部報文結構

TCP頭部有20個固定字節，選項部分長度不定，最多40個字節。

• 源端口(Source Port)：占2個字節。端口是指傳輸層和應用層的服務端口。
• 目的端口(Destination Port)：占2個字節。端口是指傳輸層和應用層的服務端口。
• TCP序列號(Sequence Number)：占4個字節。范圍是0—2^32-1。因為TCP是面向字節流，所以它為每一個字節進行編號。在網絡中傳輸時，它們的順序可能會發生變化；接收端依據此序列號，便可按照正確的順序重組數據。
• 確認號(Acknowledge Number)：占4個字節，是期望收到下一個報文段的數據部分的第一個序號。用於標識接收端確認收到的數據段。確認序列號為成功收到的數據序列號加1。
• 數據偏移：占4個字節。是指TCP報文段的數據開始的部分距TCP報文段起始部分的偏移量，也就是TCP頭部報文的長度。
• 保留字段：占6個字節。
• 標識符：
  • URG：當URG置1時，表示緊急指針有效，它告訴系統此報文段有緊急數據，應盡快傳送。
  • ACK：ACK置1，表示確認號字段才有效。此外，TCP規定，建立連接后，傳輸的所有報文段的ACK都需要被置1.
  • PSH：當接收者收到PSH=1時，會立即把數據傳輸給應用程序，而不會等到緩沖區滿了，再做提交。
  • RST：RST=1，表示TCP連接出現了嚴重的問題，必須釋放重連。
  • SYN：建立連接的時候使用。當SYN=1，ACK=0時，表示為請求連接；當SYN=1，ACK=1時，表示為同意連接的請求應答。
  • FIN：FIN=1，表示請求釋放連接。
• 窗口(Window)：占2個字節，表示接受端的接收窗口的大小。用於實現流量控制。將接收端發送過去的窗口大小設置成發送端的發送窗口大小，從而控制了發送端的發送效率。
• 校驗和(Checksum)：用於檢測發送過程中是否出現錯誤。校驗整個TCP報文段，包括TCP頭部和TCP數據。該值由發送端計算和記錄並由接收端進行驗證。
• 緊急指針(Urgent Pointer)：用於標識緊急數據的尾部。
• 選項字段：（需要掌握的幾個選項）MMS—最大報文長度，實際是報文段的最大數據長度。窗口擴大因子。時間戳選項。

1.3 TCP建立連接——三次握手

TCP連接的建立是一個三次握手的過程。如圖所示：

1. 主機A（通常也稱為客戶端）發送一個標識了SYN的數據段，表示期望與服務器A建立連接，此數據段的序列號（seq）為a。
2. 服務器A回復標識了SYN+ACK的數據段，此數據段的序列號（seq）為b，確認序列號為主機A的序列號加1（a+1），以此作為對主機A的SYN報文的確認。
3. 主機A發送一個標識了ACK的數據段，此數據段的序列號（seq）為a+1，確認序列號為服務器A的序列號加1（b+1），以此作為對服務器A的SYN報文的確認。

1.4 TCP數據傳輸過程

1. 數據傳輸過程中，應用數據被分割成TCP認為最適合發送的數據塊。應用程序產生的數據報長度將保持不變。 (將數據截斷為合理的長度)
2. 當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。 (超時重發)
3. 當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒 。 (做出響應，推遲發送是要做完整校驗）
4. TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段並且不會確認收到此報文段。 (校驗出包有錯，丟棄報文段，不給出響應，TCP發送數據端，超時時會重發數據)
5. TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。 (對失序數據進行重新排序，然后才交給應用層)
6. 既然IP數據報會發生重復，TCP的接收端必須丟棄重復的數據。(對於重復數據，能夠丟棄重復數據)
7. TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。(TCP可以進行流量控制，防止較快主機致使較慢主機的緩沖區溢出)TCP使用的流量控制協議是可變大小的滑動窗口協議。

1.5 TCP傳輸過程通過確認技術保證數據正確

TCP的可靠傳輸還體現在TCP使用了確認技術來確保目的設備收到了從源設備發來的數據，並且是准確無誤的。

確認技術的工作原理如下：

目的設備接收到源設備發送的數據段時，會向源端發送確認報文，源設備收到確認報文后，繼續發送數據段，如此重復。

如圖所示，

1. 主機A向服務器A發送TCP數據段，為描述方便假定每個數據段的長度都是500個字節。
2. 當服務器A成功收到序列號是M+1499的字節以及之前的所有字節時，會以序列號M+1499+1=M+1500進行確認。
3. 另外，由於數據段N+3傳輸失敗，所以服務器A未能收到序列號為M+1500的字節，因此服務器A還會再次以序列號M+1500進行確認。

1.6 TCP流量控制

TCP滑動窗口技術通過動態改變窗口大小來實現對端到端設備之間的數據傳輸進行流量控制。

如圖所示，

• 主機A和服務器A之間通過滑動窗口來實現流量控制。為方便理解，此例中只考慮主機A發送數據給服務器A時，服務器A通過滑動窗口進行流量控制。
• 主機A向服務器發送4個長度為1024字節的數據段，其中主機的窗口大小為4096個字節。服務器A收到第3個數據段后，緩存區滿，第4個數據段被丟棄。服務器以ACK 3073響應，窗口大小調整為3072，表明服務器的緩沖區只能處理3072個字節的數據段。於是主機A改變其發送速率，發送窗口大小為3072的數據段。

1.7 TCP斷開連接——四次揮手

TCP支持全雙工模式傳輸數據，這意味着同一時刻兩個方向都可以進行數據的傳輸。在傳輸數據之前，TCP通過三次握手建立的實際上是兩個方向的連接，因此在傳輸完畢后，兩個方向的連接必須都關閉（主機在關閉連接之前，要確認收到來自對方的ACK）。

TCP連接的建立是一個三次握手的過程，而TCP連接的終止則要經過四次握手。

如圖所示：

• 主機A想終止連接，於是發送一個標識了FIN，ACK的數據段，序列號為a，確認序列號為b。
• 服務器A回應一個標識了ACK的數據段，序列號為b，確認序號為a+1，作為對主機A的FIN報文的確認。
• 服務器A想終止連接，於是向主機A發送一個標識了FIN，ACK的數據段，序列號為b，確認序列號為a+1。
• 主機A回應一個標識了ACK的數據段，序列號為a+1，確認序號為b+1，作為對服務器A的FIN報文的確認。

以上四次交互便完成了兩個方向連接的關閉。

TCP頭部中的確認標識位有什么作用？

TCP報文頭中的ACK標志位用於目的端對已收到數據的確認。目的端成功收到序列號為x的字節及之前的所有字節后，會以序列號x+1進行確認。

TCP頭部中有哪些標識位參與TCP三次握手？

在TCP的三次握手過程中，要使用SYN和ACK標志位來請求建立連接和確認建立連接。

2.用戶數據包協議UDP

UDP是一種面向無連接的傳輸層協議，傳輸可靠性沒有保證。

當應用程序對傳輸的可靠性要求不高，但是對傳輸速度和延遲要求較高時，可以用UDP協議來替代TCP協議在傳輸層控制數據的轉發。

UDP將數據從源端發送到目的端時，無需事先建立連接。UDP采用了簡單、易操作的機制在應用程序間傳輸數據，沒有使用TCP中的確認技術或滑動窗口機制，因此UDP不能保證數據傳輸的可靠性，也無法避免接收到重復數據的情況。UDP適合於實時數據傳輸，如語音和視頻通信。相比於TCP，UDP的傳輸效率更高、開銷更小，但是無法保障數據傳輸的可靠性。

2.1 UDP報文頭部結構

UDP頭部僅占8字節，傳輸數據時沒有確認機制。UDP報文分為UDP報文頭和UDP數據區域兩部分。報頭由源端口、目的端口、報文長度以及校驗和組成。

UDP頭部的標識如下：

• 16位源端口號：源主機的應用程序使用的端口號。
• 16位目的端口號：目的主機的應用程序使用的端口號。
• 16位UDP長度：是指UDP頭部和UDP數據的字節長度。因為UDP頭部長度為8字節，所以該字段的最小值為8。
• 16位UDP校驗和：該字段提供了與TCP校驗字段同樣的功能；該字段是可選的。

2.2 UDP傳輸過程

使用UDP傳輸數據時，由應用程序根據需要提供報文到達確認、排序、流量控制等功能。

主機A發送數據包時，這些數據包是以有序的方式發送到網絡中的，每個數據包獨立地在網絡中被發送，所以不同的數據包可能會通過不同的網絡路徑到達主機B。

這樣的情況下，先發送的數據包不一定先到達主機B。因為UDP數據包沒有序號，主機B將無法通過UDP協議將數據包按照原來的順序重新組合，所以此時需要應用程序提供報文的到達確認、排序和流量控制等功能。

通常情況下，UDP采用實時傳輸機制和時間戳來傳輸語音和視頻數據。

一些時延敏感的流量，如語音、視頻等，通常使用UDP作為傳輸層協議。

在使用TCP協議傳輸數據時，如果一個數據段丟失或者接收端對某個數據段沒有確認，發送端會重新發送該數據段。

TCP重新發送數據會帶來傳輸延遲和重復數據，降低了用戶的體驗。對於時延敏感的應用，少量的數據丟失一般可以被忽略，這時使用UDP傳輸將能夠提升用戶的體驗。（UDP不提供重傳機制，占用資源小，處理效率高。）