計算機網路：面向初學者的 TCP

傳輸控制協議（Transmission Control Protocol，TCP）基本認識

TCP 所扮演的角色

• 基於連接的傳輸協議：通信雙方要相互通信前，首先必須先建立連接（三次握手），連接建立完後才能進行資料傳輸，最後沒有資料要進行傳輸了就要斷開連接（四次揮手）。
• 全雙工（full duplex）：即在一個通信中進行資料傳輸是雙向的。
• 可靠性傳輸服務：通過檢驗和、序列號、確認應答、重發控制、連接管理以及流量控制等等機制實現。

• 位於傳輸層，為點對點（只能單播，不能廣播、多播）服務，即在單個發送方與對應的單個接收方之間建立邏輯通信。

TCP 報文段首部格式

• ACK：當 ACK＝1 時，表示確認號欄位有效，反之 ACK = 0 時，表示確認號欄位無效。
• RST：重置連接欄位，當 RST＝1 時，表示 TCP 連接出現異常，必須強制斷開連接。
• SYN：同步欄位，用於雙方建立 TCP 連接時。當 SYN＝1 時，表示希望建立連接。
• FIN：用於釋放連接，當 FIN＝1 時，表示希望斷開連接。

可靠性傳輸的一些原理

序列號與確認號

三種類型序列號

• 位元組序列號
• 報文段序列號
• 初始化序列號

1. seq = 1 的報文段在傳輸過程中延遲了，接收方先收到 seq = 101 的報文段，將其記錄起來然後向發送方發送確認報文段（ack = 1）。
2. 接收方又再接收到一個 seq = 201 的報文段，一樣把其記錄下來然後向發送方發送確認報文段（ack = 1）。
3. 此時接收方終於收到延遲的報文段（seq = 1）了，接收方會根據其報文段的序列號進行排序，也正因為是序列號，所以才能正確地將資料傳送給應用層讀取。

1. 一開始 seq = 1 的報文段被發送至接收方，然後超時計時器計時。
2. 接收方收到 seq = 1 的報文段後，將其記錄，然後向發送方傳送一個 ACK 確認報文段，並期望下次收到 seq = 101 的報文段。
3. 由於確認報文段在傳輸過程中丟失了，經過一段時間後，超時重傳時間到了，對 seq = 1 的報文段進行重傳。
4. 接收方收到 seq = 1 的報文段後，發現該報文段已經接收過了，於是丟棄，然後向發送方發出一個 ACK 確認報文段。

超時重傳

首先我們先來了解往返時間（Round Trip Time，RTT）

超時重傳時間的長短所引發的情形

• 過短引起不必要的重傳
• 過長引起空閒時間增大

• 其中 0 ≦ α＜1，推薦的 α 值為 0.125

• 其中 0 ≦ β＜1，推薦的 β 值為 0.25

快速重傳（fast retransmit）

• 主機 A：發送方；主機 B：接收方
• 現在發送方傳給接收方 seq = 1 的報文段抵達了，接收方收到了回傳 ack 101 給發送方。
• 發送方傳給接收方 seq = 101 的報文段中途丟失了。
• 發送方後面傳給接收方 seq = 201、seq = 301、seq = 401 的報文段都到了，它們都會回傳 ack 101。
• 當發送方接收到了三個重複確認 ack 101 ，就知道 seq = 101 的報文段還沒被接收方收到，將會在超時之前重傳丟失的報文段

選擇確認（Selective ACK, SACK）

• 發送方一開時同時發送資料為 1 ~ 100、101 ~ 200、201 ~ 300、301 ~ 400 及401 ~ 500的報文段，達到發送窗口上限，不能再發送資料。其中報文段資料為 101 ~ 200、301 ~ 400 的報文段丟失了。
• 接收方收到資料為 1 ~ 100 的報文段後，向發送方響應了一個 ack = 101 的確認報文段，然後發送方收到了後，1 ~ 100 的報文段從緩存中丟棄，發送窗口向前移動，此時 cwnd 的值加 1 維持在 6（假定的值，方便討論），然後可以發送資料為 501 ~ 600 及 601 ~ 700 的報文段。
• 接收方陸續收到其他報文段，唯獨資料為101 ~ 200 及 301 ~ 400 的報文段沒有收到，所有接收方在回傳確認報文段時，會將已經收到的資料記錄在確認報文段當中，可以從上圖發現。
• 當發送方收到三個相同的 ack = 101 的確認報文段後，觸發快速重傳機制，發送方會根據 SACK 信息進行丟失的報文段重傳，如上圖所示， 101 ~ 200 及 301 ~ 400 的報文段被重傳了。

累積確認

一個累積確認的通俗解釋

連接管理

TCP 建立連接（三次握手）

1. 一開始客戶端與伺服端都處於 CLOSED 狀態。伺服端會先進入 LISTEN 狀態，等待來自客戶端的連接請求。
2. 客戶端向伺服端發起連接請求，此時客戶端向伺服端發出 SYN 報文段（TCP 連接請求報文段），該報文段首部的 SYN 欄位被設置為 1，同時選擇一個初始序列號 seq = x（SYN 報文段是不能攜帶資料的，但是要消耗一個序列號），發送完後，客戶端進入 SYN - SENT 狀態。
3. 伺服端收到客戶端的連接請求報文段後，如果同意連接就會向客戶端發出 TCP 連接請求確認報文段，並且伺服端進入 SYN - RCVD 狀態。這個連接請求確認報文段首部中的 SYN、ACK 欄位被設置為 1，確認號 ack = x + 1，同時選擇一個初始序列號 seq = y（伺服端所選的初始序號），一樣的這個 TCP 連接請求確認報文段是不能攜帶資料的，但是要消耗一個序列號，因為其 SYN 欄位也是被設置為 1。
4. 客戶端收到伺服端的連接請求確認報文段後，還要向伺服端發送一個普通的確認報文段（可以攜帶資料），然後進入 ESTABLISHED 狀態。
5. 伺服端收到客戶端的確認報文段後，也進入 ESTABLISHED 狀態。

三個原因

• 三次握手才能防止歷史連接（主因）
• 三次握手才能同步雙方的初始序列號
• 三次握手可以避免資源的浪費

1. 舊的 SYN 連接請求報文段在網路傳輸中延遲了，計時器到時後觸發超時重傳，此時發送一個新的 SYN 連接請求報文段。
2. 舊的 SYN 連接請求報文段比新的 SYN 連接請求報文段還要早抵達伺服端，此時伺服端收到舊的 SYN 連接請求報文段後，向客戶端發出 SYN 連接請求確認報文段，然後進入 SYN - RCVD 狀態，此時伺服端還不能發送資料，客戶端收到的不是期望的 ack，所以客戶端發起 RST 報文段終止連接。
3. 新的 SYN 連接請求報文段抵達伺服端被接收後，此時伺服端向客戶端發出 SYN 連接請求確認報文段，然後進入 SYN - RCVD 狀態，客戶端收到期望的 ack 後，向伺服端發出普通的確認報文段然後進入 ESTABLISHED 狀態。
4. 伺服端收到普通的確認報文段後，進入 ESTABLISHED 狀態。
5. 這裡點出重點來，發送 SYN 連接請求報文段的客戶端會進入 SYN - SENT 狀態而發送 SYN 連接請求確認報文段的伺服端會進入 SYN -RCVD 狀態，也就是還沒進入 ESTABLISHED 狀態，所以還不能進行資料傳輸，自然而然就能防止歷史連接。

1. 舊的 SYN 連接請求報文段在網路傳輸中延遲了，計時器到時後觸發超時重傳，此時發送一個新的 SYN 連接請求報文段。
2. 舊的 SYN 連接請求報文段比新的 SYN 連接請求報文段還要早抵達伺服端，此時伺服端收到舊的 SYN 連接請求報文段後，向客戶端發出 SYN 連接請求確認報文段，然後進入 ESTABLISHED 狀態，此時伺服端可以發送資料。
3. 客戶端接收到 SYN 連接請求確認報文段後，發現 ack 不是期望的，所以向伺服端發起 RST 報文段終止連接。
4. 伺服端收到 RST 報文段後將此歷史連接終止。
5. 此時伺服端收到新的 SYN 連接請求報文段，然後向客戶端發送 SYN 連接請求確認報文段後，進入 ESTABLISHED 狀態。
6. 客戶端收到 SYN 連接請求確認報文段後，也進入 ESTABLISHED 狀態。

• 使接收方可以明確地知道自己已經接收哪些資料了，並且如果有資料的丟失也可以告知發送方我缺哪些資料。
• 使接收方可以知道哪些是重複的資料，並且將其丟棄。

1. 一開始客戶端發送一個 SYN 連接請求報文段，但它可能在網路中滯留了，於是觸發超時重傳，重新發送一個新的 SYN 連接請求報文段。
2. 客戶端與伺服端經歷了一個完整的建立連接及釋放連接週期後，在網路當中滯留的 SYN 連接請求報文段抵達伺服端，伺服端接收後向客戶端發起 SYN 確認請求連接報文段，然後進入 ESTABLISHED 狀態。
3. SYN 確認請求連接報文段抵達客戶端後，客戶端對其不理睬，此時的伺服端就一直等待客戶端發送資料過來，造成了伺服端的資源浪費。

TCP 斷開連接

1. 現在客戶端打算關閉連接，此時會向伺服端發送一個連接釋放報文段，並且進入 FIN - WAIT - 1 狀態。此報文段首部 FIN、ACK 欄位皆被設置為 1（表示此報文段是連接釋放報文段，同時也是對之前收到的報文段進行確認的報文段），序列號 seq = u（為客戶端之前已經傳送的報文段資料的最後一個位元組序列號 + 1），確認號 ack = v（客戶端之前已收到的報文段資料的最後一個位元組序列號 + 1）。FIN = 1 的報文段不攜帶資料，但是要消耗一個序列號。
2. 伺服端收到連接釋放報文段之後，會向客戶端發送一個普通的確認報文段，並且進入 CLOSE - WAIT 狀態。
3. 客戶端收到確認報文段後，就進入 FIN - WAIT - 2 狀態，然後等待伺服端發出的 TCP 連接釋放報文段。
4. 伺服端剩餘資料傳輸完畢之後，就會向客戶端發送一個連接釋放報文段後，就進入 LAST - ACK 狀態。
5. 客戶端收到連接釋放報文段之後，會向伺服端發送一個普通的確認報文段，並且進入 TIME - WAIT 狀態。
6. 伺服端收到確認報文段後，就會進入 CLOSE 狀態，至此伺服端已經完成連接關閉。
7. 然客戶端在經過 2MSL 一段時間後，就會進入 CLOSE 狀態，至此客戶端也完成連接關閉。

滑動窗口（Sliding - Window）

為什麼要引入滑動窗口呢？

• 發送窗口：僅有在窗口裡面的資料皆可以被發送，同時可以連續發送，無需等待確認應答。
• 可用窗口：可以被發送的資料數量，但是還未被發送。

引入滑動窗口與沒有引入的差別

流量控制（flow-control）

TCP 流量控制原因及概念

1. 為什麼要進行流量控制呢？
2. 流量控制是如何運作的？

• A：發送方，B：接收方。

發送窗口與接收窗口的關係

• 發送窗口：swnd，接收窗口：rwnd
• 不考慮擁塞控制

流量控制方法

• 基於滑動窗口機制，可以方便地使 TCP 連接實現對發送方的流量控制。
• 不考慮擁塞控制，僅以流量控制分析

1. 發送方送出 1 ~ 300 的資料，其中 201 ~ 300 丟失了，接收方收到了 1 ~ 200 的資料，並且回傳確認報文段（ACK = 1，ack = 201，rwnd = 300），這個確認報文段通知了發送方，我（接收方）目前的接收窗口是 rwnd = 300，並且確認已經收到 201 以前的資料了，此時發送窗口向前移，並調整發送窗口為 300，把已經確認的資料從緩存中清除。
2. 接著發送方傳送 301 ~ 500 的資料，此時已經達發送窗口的上限了，所以不再繼續發送資料，並且超時重傳計時器的時間到了，所以重新發送剛剛丟失的報文段資料 201 ~ 300，接收方一樣在預定的累積確認時間內對發送方發出一個確認報文段（ACK = 1，ack = 501，rwnd = 0），這個確認報文段通知了發送方，我（接收方）目前的接收窗口是 rwnd = 0，並且確認已經收到 501 前的資料了，此時因為接收方告知接收窗口是 rwnd = 0，所以發送方要調整其發送窗口將其調整為零，所以發送方不能再發送資料了。
3. 發送方收到接收方發送的零窗口報文段不久後，接收方的接收緩存此時又有空間了，於是通知發送方我的接收窗口為何，但這個報文段卻在傳輸過程中丟失了，於是雙方彼此互相等待，造成死鎖局面，所以必須有個機制來處理這樣的情況，以下將會介紹這個處理機制。

1. 發送方收到零窗口通知，就會啟動持續計時器，此時的發送方無法再發送任何資料了，於是只能等待來自接收方的非零窗口通知。
2. 接收方處理完資料後，接收方有空閒的儲存空間了，此時向發送方發送一個非零窗口通知，但是在途中丟失了。
3. 由於前面有啟動持續計時器，所以當持續計時器超時的時候，發送方會發送一個攜帶 1 位元組的零窗口探測報文段，這麼做主要是為了要避免死鎖局面。
4. 接收方收到零窗口探測報文段後進行確認，然後向發送方通告自己當前的窗口大小。

擁塞控制（congestion control）

TCP 擁塞控制原因及概念

1. 說明擁塞原因及 TCP 為何要進行擁塞控制。
2. 採用的是哪種模式來得知網路的擁塞。
3. 流量控制與擁塞控制有什麼不同呢？

發送窗口與擁塞及接收窗口的關係

• 發送窗口：swnd，擁塞窗口：cwnd，接收窗口：rwnd

擁塞控制算法基本概念

特性

• 慢啟動指的是一開始啟動時，被發送至網路的報文段是以少量為主，並非是慢慢啟動，其被發送至網路的報文段隨後呈倍數增加（每個輪次的報文段數量）。
• 發送方每收到一個 ACK，擁塞窗口 cwnd 就會加 1。

1. TCP 連接建立完成後，擁塞窗口 cwnd 的值被設置為 1，表示一開始只可以傳送一個 MSS 大小的資料。
2. 現在發送方收到一個 ACK 確認報文段後，擁塞窗口 cwnd 的值加 1，此時的擁塞窗口 cwnd = 2。
3. 因為擁塞窗口 cwnd = 2，所以現在發送方可以發送兩個報文段，接收方收到這兩個報文段後，會傳回各自的 ACK 確認報文段，當發送方收到這兩個 ACK 確認報文段，擁塞窗口 cwnd 的值加 2（此時 cwnd = 4），於是現在發送方可以發送 4 個報文段了。
4. 發送方現在可以向接收方發送 4 個報文段，接收方收到 4 個報文段後，緊接著回傳各自的 ACK 確認報文段給發送方，發送方收到這 4 個 ACK 確認報文段後，擁塞窗口 cwnd 的值加 4（此時 cwnd = 8），於是現在發送方可以發送 8 個報文段了。
5. 當然擁塞窗口 cwnd 不是一直呈指數增加的，當超過慢啟動門限 ssthresh 後，就會進入到擁塞避免算法，以下小節將會討論。

特性

• 每當收到一個 ACK 確認報文段，擁塞窗口 cwnd 就會增加 1／cwnd。
• 每個輪次僅增加一個報文段的傳輸數量。

1. 前面有說到慢啟動門限 ssthresh = 8，所以現在擁塞窗口 cwnd = 8，就會停止慢啟動算法，轉而執行擁塞避免算法。
2. 發送方現在可以向接收方發送 8 個報文段了，此時發送方每收到接收方傳來的確認報文段都僅僅增加 1／cwnd，也就是說每個輪次 cwnd 只加 1。

特性

• 慢啟動門限 ssthresh＝cwnd／2
• 擁塞窗口 cwnd＝ssthresh＋3（3 表示有收到 3 個確認報文段）

• 擁塞窗口 cwnd＝ssthresh

1. 收到三個重複的 ACK 然後進入快速恢復狀態，此時的慢啟動門限 ssthresh＝cwnd／2，擁塞窗口 cwnd＝ssthresh＋3。
2. 在此期間如果發送方有收到重複的 ACK 確認報文段，其擁塞窗口 cwnd 都要加 1，直到收到新的 ACK 確認報文段。
3. 發送方收到新的 ACK 確認報文段後，擁塞窗口 cwnd 被設置為 ssthresh，然後進入擁塞避免算法。

• 慢啟動門限 ssthresh 被設置為 cwnd／2。
• 擁塞窗口 cwnd 被設置為 1（假定的，正確來說是恢復成初始化值）。

參考來源

1. B站，深入淺出計算機網路微課堂
2. James F. Kurose, Keith W.Ross。《計算機網路：自頂向下方法》。陳鳴譯。機械工業出版社。
3. 《深入淺出計算機網路》。高軍、陳君、唐秀明及張劍。清華大學出版社。
4. 《圖解TCP／IP》