計算機網路總結之運輸層

一、運輸層

網路層只是把分組傳送到目的主機，但是真正通訊的並不是主機而是主機中的程序。運輸層提供了程序間的邏輯通訊，運輸層向高層使用者遮蔽了下面網路層的核心細節，是應用程式看見的好像是在兩個運輸層實體之間有一條端到端的邏輯通訊通道。

1.1、UDP和TCP的特點

使用者資料報協議UDP（User Datagram Protocol）是無連線的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程式傳下來的報文不合並也不拆分，只新增UDP首部）。
傳輸控制協議TCP（Transmission Control Protocol）是面向連線的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通訊，面向位元組流（把應用層傳下來的報文看成位元組流，把位元組流組織成大小不等的資料塊）

1.2、UDP首部

首部欄位只有8個位元組，包含源埠、目的埠、長度、校驗和。12個位元組的偽首部是為了計算校驗和而臨時新增的。

1.3、TCP首部格式

• 序號：用於對位元組流進行編號，例如序號為 301，表示第一個位元組的編號為 301，如果攜帶的資料長度為 100 位元組，那麼下一個報文段的序號應為 401。
• 確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 傳送來的一個報文段，序號為 501，攜帶的資料長度為 200 位元組，因此 B 期望下一個報文段的序號為 701，B 傳送給 A 的確認報文段中確認號就為 701。
• 資料偏移 ：指的是資料部分距離報文段起始處的偏移量，實際上指的是首部的長度。
• 確認 ACK ：當 ACK=1 時確認號欄位有效，否則無效。TCP 規定，在連線建立後所有傳送的報文段都必須把 ACK 置 1。
• 同步 SYN ：在連線建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連線請求報文段。若對方同意建立連線，則響應報文中 SYN=1，ACK=1。
• 終止 FIN ：用來釋放一個連線，當 FIN=1 時，表示此報文段的傳送方的資料已傳送完畢，並要求釋放運輸連線。
• 視窗 ：視窗值作為接收方讓傳送方設定其傳送視窗的依據。之所以要有這個限制，是因為接收方的資料快取空間是有限的。

1.4、TCP三次握手

假設A為客戶端，B為伺服器端

• 首先B處於LISTEN（監聽）狀態，等待客戶的連線請求。
• A 向 B傳送連線請求報文段，SYN=1，ACK=0，選擇一個初始的序號x。
• B 收到連線請求報文段，如果同意建立連線，則向 A 傳送連線確認報文段，SYN=1，ACK=1，確認號為x+1，同時也選擇一個初始序號y。
• A收到B的確認報文欄位後，還要向B發出去人，確認號為y+1,序號為x+1。
• B收到A的確認後，連線建立。

三次握手的原因

第三次握手是為了防止失效的連線請求到達伺服器，讓伺服器錯誤的開啟連線。

失效的連線請求是指，客戶端傳送的連線請求在網路中滯留，客戶端因為沒有及時收到伺服器端傳送的連線確認，因此就重新發送了連線請求，伺服器向客戶端傳送確認報文段，同意建立連線，假設不採用三次握手，那麼只要伺服器發出確認，新的連線就建立了。但是滯留的連線請求並沒有丟失，之後還是會到達伺服器。如果不進行第三次握手，那麼伺服器會誤認為客戶端重新請求連線，然後打開了連線。但是並不是客戶端真正開啟這個連線，因此客戶端不會給伺服器傳送資料，這個連線就白白浪費了。

1.5 TCP四次揮手

以下描述不討論序號和確認號，因為序號和確認號的規則比較簡單。並且不討論 ACK，因為 ACK 在連線建立之後都為 1。

• A 傳送連線釋放報文段，FIN=1。
• B 收到之後發出確認，此時 TCP 屬於半關閉狀態，B 能向 A 傳送資料但是 A 不能向 B 傳送資料，因此 B 還會向 A 傳送一些資料。
• 當 B 要不再需要連線時，傳送連線釋放請求報文段，FIN=1。
• A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2MSL 時間後釋放連線。
• B 收到 A 的確認後釋放連線。

四次揮手的原因

客戶端傳送了FIN連線釋放報文之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端傳送還未傳送完畢的資料，傳送完畢之後，伺服器會發送 FIN 連線釋放報文。

TIME_WAIT

客戶端接收到伺服器段的FIN報文後進入此狀態，此時並不是直接進入CLOSE狀態，還需要等待一個時間計時器設定的時間2MSL，這麼做有兩個理由：

• 確保最後一個確認報文段能夠到達。如果 B 沒收到 A 傳送來的確認報文段，那麼就會重新發送連線釋放請求報文段，A 等待一段時間就是為了處理這種情況的發生。
• 等待一段時間是為了讓本連線持續時間內所產生的所有報文段都從網路中消失，使得下一個新的連線不會出現舊的連線請求報文段。

1.6、TCP滑動視窗

• 視窗是快取的一部分，用來暫時存放位元組流。傳送方和接收方各有一個視窗，接收方通過 TCP 報文段中的視窗欄位告訴傳送方自己的視窗大小，傳送方根據這個值和其它資訊設定自己的視窗大小。

• 傳送視窗內的位元組都允許被髮送，接收視窗內的位元組都允許被接收。如果傳送視窗左部的位元組已經發送並且收到了確認，那麼就將傳送視窗向右滑動一定距離，直到左部第一個位元組不是已傳送並且已確認的狀態；接收視窗的滑動類似，接收視窗左部位元組已經發送確認並交付主機，就向右滑動接收視窗。

• 接收視窗只會對視窗內最後一個按序到達的位元組進行確認，例如接收視窗已經收到的位元組為 {31, 32, 34, 35}，其中 {31, 32} 按序到達，而 {34, 35} 就不是，因此只對位元組 32 進行確認。傳送方得到一個位元組的確認之後，就知道這個位元組之前的所有位元組都已經被接收。

1.7、TCP可靠傳輸

TCP 使用超時重傳來實現可靠傳輸：如果一個已經發送的報文段在超時時間內沒有收到確認，那麼就重傳這個報文段。一個報文段從傳送再到接收到確認所經過的時間稱為往返時間 RTT，加權平均往返時間 RTTs 計算如下：

超時時間 RTO 應該略大於 RTTs，TCP 使用的超時時間計算如下：

其中 RTTd 為偏差。

1.8、TCP流量控制

流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。

接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。

1.9、TCP擁塞控制

如果網路出現擁塞，分組將會丟失，此時傳送方會繼續重傳，從而導致網路擁塞程度更高。因此當出現擁塞時，應當控制傳送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是為了讓接收方能來得及接受，而擁塞控制是為了降低整個網路的擁塞程度。

TCP 主要通過四種演算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。傳送方需要維護一個叫做擁塞視窗（cwnd）的狀態變數。注意擁塞視窗與傳送方視窗的區別，擁塞視窗只是一個狀態變數，實際決定傳送方能傳送多少資料的是傳送方視窗。

為了便於討論，做如下假設：

• 接收方有足夠大的接收快取，因此不會發生流量控制；
• 雖然 TCP 的視窗基於位元組，但是這裡設視窗的大小單位為報文段。
  

慢開始與擁塞避免

傳送的最初執行慢開始，令 cwnd=1，傳送方只能傳送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後傳送方能夠傳送的報文段數量為：2、4、8 …

注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得傳送方傳送的速度增長速度過快，網路擁塞的可能也就更高。設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現了超時，則令 ssthresh = cwnd/2，然後重新執行慢開始。

快重傳與快恢復

在接收方，要求每次接收到報文段都應該傳送對已收到有序報文段的確認，例如已經接收到 M1 和 M2，此時收到 M4，應當傳送對 M2 的確認。

在傳送方，如果收到三個重複確認，那麼可以確認下一個報文段丟失，例如收到三個 M2 ，則 M3 丟失。此時執行快重傳，立即重傳下一個報文段。

在這種情況下，只是丟失個別報文段，而不是網路擁塞，因此執行快恢復，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。

參考資料：