TCP 是一種面向連線的單播協議，在 TCP 中，並不存在多播、廣播的這種行為，因為 TCP 報文段中能明確傳送方和接受方的 IP 地址。
在傳送資料前，相互通訊的雙方（即傳送方和接受方）需要建立一條連線，在傳送資料後，通訊雙方需要斷開連線，這就是 TCP 連線的建立和終止。
TCP 連線的建立和終止
如果你看過我之前寫的關於網路層的一篇文章，你應該知道 TCP 的基本元素有四個：即傳送方的 IP 地址、傳送方的埠號、接收方的 IP 地址、接收方的埠號。而每一方的 IP + 埠號都可以看作是一個套接字，套接字能夠被唯一標示。套接字就相當於是門，出了這個門，就要進行資料傳輸了。
TCP 的連線建立 -> 終止總共分為三個階段
下面我們所討論的重點也是集中在這三個層面。
下圖是一個非常典型的 TCP 連線的建立和關閉過程，其中不包括資料傳輸的部分。
TCP 建立連線 - 三次握手
- 服務端程式準備好接收來自外部的 TCP 連線，一般情況下是呼叫 bind、listen、socket 三個函式完成。這種開啟方式被認為是
被動開啟(passive open)。然後服務端程式處於LISTEN狀態，等待客戶端連線請求。 - 客戶端通過
connect發起主動開啟(active open)，向伺服器發出連線請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶資料，只消耗一個序號。此時，客戶端進入SYN-SEND狀態。 - 伺服器收到客戶端連線後，，需要確認客戶端的報文段。在確認報文段中，把 SYN 和 ACK 位都置為 1 。確認號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。這個報文段也不能攜帶資料，但同樣要消耗掉一個序號。此時，TCP 伺服器進入
SYN-RECEIVED(同步收到)狀態。 - 客戶端在收到伺服器發出的響應後，還需要給出確認連線。確認連線中的 ACK 置為 1 ，序號為 seq = x + 1，確認號為 ack = y + 1。TCP 規定，這個報文段可以攜帶資料也可以不攜帶資料，如果不攜帶資料，那麼下一個資料包文段的序號仍是 seq = x + 1。這時，客戶端進入
ESTABLISHED (已連線)狀態 - 伺服器收到客戶的確認後，也進入
ESTABLISHED狀態。
這是一個典型的三次握手過程，通過上面 3 個報文段就能夠完成一個 TCP 連線的建立。三次握手的的目的不僅僅在於讓通訊雙方知曉正在建立一個連線，也在於利用資料包中的選項欄位來交換一些特殊資訊，交換初始序列號。
一般首個傳送 SYN 報文的一方被認為是主動開啟一個連線，而這一方通常也被稱為
客戶端。而 SYN 的接收方通常被稱為服務端，它用於接收這個 SYN，併傳送下面的 SYN，因此這種開啟方式是被動開啟。
TCP 建立一個連線需要三個報文段，釋放一個連線卻需要四個報文段。
TCP 斷開連線 - 四次揮手
資料傳輸結束後，通訊的雙方可以釋放連線。資料傳輸結束後的客戶端主機和服務端主機都處於 ESTABLISHED 狀態，然後進入釋放連線的過程。
TCP 斷開連線需要歷經的過程如下
-
客戶端應用程式發出釋放連線的報文段，並停止傳送資料，主動關閉 TCP 連線。客戶端主機傳送釋放連線的報文段，報文段中首部 FIN 位置為 1 ，不包含資料，序列號位 seq = u，此時客戶端主機進入
FIN-WAIT-1(終止等待 1)階段。 -
伺服器主機接受到客戶端發出的報文段後，即發出確認應答報文，確認應答報文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然後伺服器主機就進入
CLOSE-WAIT(關閉等待)狀態。 -
客戶端主機收到服務端主機的確認應答後，即進入
FIN-WAIT-2(終止等待2)的狀態。等待客戶端發出連線釋放的報文段。 -
這時服務端主機會發出斷開連線的報文段，報文段中 ACK = 1，序列號 seq = v，ack = u + 1，在傳送完斷開請求的報文後，服務端主機就進入了
LAST-ACK(最後確認)的階段。 -
客戶端收到服務端的斷開連線請求後，客戶端需要作出響應，客戶端發出斷開連線的報文段，在報文段中，ACK = 1, 序列號 seq = u + 1，因為客戶端從連線開始斷開後就沒有再傳送資料，ack = v + 1，然後進入到
TIME-WAIT(時間等待)狀態，請注意，這個時候 TCP 連線還沒有釋放。必須經過時間等待的設定，也就是2MSL後，客戶端才會進入CLOSED狀態，時間 MSL 叫做最長報文段壽命（Maximum Segment Lifetime）。 -
服務端主要收到了客戶端的斷開連線確認後，就會進入 CLOSED 狀態。因為服務端結束 TCP 連線時間要比客戶端早，而整個連線斷開過程需要傳送四個報文段，因此釋放連線的過程也被稱為四次揮手。
TCP 連線的任意一方都可以發起關閉操作，只不過通常情況下發起關閉連線操作一般都是客戶端。然而，一些伺服器比如 Web 伺服器在對請求作出相應後也會發起關閉連線的操作。TCP 協議規定通過傳送一個 FIN 報文來發起關閉操作。
所以綜上所述，建立一個 TCP 連線需要三個報文段，而關閉一個 TCP 連線需要四個報文段。TCP 協議還支援一種半開啟(half-open) 狀態，雖然這種情況並不多見。
TCP 半開啟
TCP 連線處於半開啟的這種狀態是因為連線的一方關閉或者終止了這個 TCP 連線卻沒有通知另一方，也就是說兩個人正在微信聊天，cxuan 你下線了你不告訴我，我還在跟你侃八卦呢。此時就認為這條連線處於半開啟狀態。這種情況發生在通訊中的一方處於主機崩潰的情況下，你 xxx 的，我電腦當機了我咋告訴你？只要處於半連線狀態的一方不傳輸資料的話，那麼是無法檢測出來對方主機已經下線的。
另外一種處於半開啟狀態的原因是通訊的一方關閉了主機電源 而不是正常關機。這種情況下會導致伺服器上有很多半開啟的 TCP 連線。
TCP 半關閉
既然 TCP 支援半開啟操作，那麼我們可以設想 TCP 也支援半關閉操作。同樣的，TCP 半關閉也並不常見。TCP 的半關閉操作是指僅僅關閉資料流的一個傳輸方向。兩個半關閉操作合在一起就能夠關閉整個連線。在一般情況下，通訊雙方會通過應用程式互相傳送 FIN 報文段來結束連線，但是在 TCP 半關閉的情況下，應用程式會表明自己的想法："我已經完成了資料的傳送傳送，併傳送了一個 FIN 報文段給對方，但是我依然希望接收來自對方的資料直到它傳送一個 FIN 報文段給我"。 下面是一個 TCP 半關閉的示意圖。
解釋一下這個過程：
首先客戶端主機和伺服器主機一直在進行資料傳輸，一段時間後，客戶端發起了 FIN 報文，要求主動斷開連線，伺服器收到 FIN 後，回應 ACK ，由於此時發起半關閉的一方也就是客戶端仍然希望伺服器傳送資料，所以伺服器會繼續傳送資料，一段時間後伺服器傳送另外一條 FIN 報文，在客戶端收到 FIN 報文回應 ACK 給伺服器後，斷開連線。
TCP 的半關閉操作中，連線的一個方向被關閉，而另一個方向仍在傳輸資料直到它被關閉為止。只不過很少有應用程式使用這一特性。
同時開啟和同時關閉
還有一種比較非常規的操作，這就是兩個應用程式同時主動開啟連線。雖然這種情況看起來不太可能，但是在特定的安排下卻是有可能發生的。我們主要講述這個過程。
通訊雙方在接收到來自對方的 SYN 之前會首先傳送一個 SYN，這個場景還要求通訊雙方都知道對方的 IP 地址 + 埠號。
下面是同時開啟的例子
如上圖所示，通訊雙方都在收到對方報文前主動傳送了 SYN 報文，都在收到彼此的報文後回覆了一個 ACK 報文。
一個同時開啟過程需要交換四個報文段，比普通的三次握手增加了一個，由於同時開啟沒有客戶端和伺服器一說，所以這裡我用了通訊雙方來稱呼。
像同時開啟一樣，同時關閉也是通訊雙方同時提出主動關閉請求，傳送 FIN 報文，下圖顯示了一個同時關閉的過程。
同時關閉過程中需要交換和正常關閉相同數量的報文段，只不過同時關閉不像四次揮手那樣順序進行，而是交叉進行的。
聊一聊初始序列號
也許是我上面圖示或者文字描述的不專業，初始序列號它是有專業術語表示的，初始序列號的英文名稱是Initial sequence numbers (ISN)，所以我們上面表示的 seq = v，其實就表示的 ISN。
在傳送 SYN 之前，通訊雙方會選擇一個初始序列號。初始序列號是隨機生成的，每一個 TCP 連線都會有一個不同的初始序列號。RFC 文件指出初始序列號是一個 32 位的計數器，每 4 us（微秒） + 1。因為每個 TCP 連線都是一個不同的例項，這麼安排的目的就是為了防止出現序列號重疊的情況。
當一個 TCP 連線建立的過程中，只有正確的 TCP 四元組和正確的序列號才會被對方接收。這也反應了 TCP 報文段容易被偽造 的脆弱性，因為只要我偽造了一個相同的四元組和初始序列號就能夠偽造 TCP 連線，從而打斷 TCP 的正常連線，所以抵禦這種攻擊的一種方式就是使用初始序列號，另外一種方法就是加密序列號。
TCP 狀態轉換
我們上面聊到了三次握手和四次揮手，提到了一些關於 TCP 連線之間的狀態轉換，那麼下面我就從頭開始和你好好梳理一下這些狀態之間的轉換。
首先第一步，剛開始時伺服器和客戶端都處於 CLOSED 狀態，這時需要判斷是主動開啟還是被動開啟，如果是主動開啟，那麼客戶端向伺服器傳送 SYN 報文，此時客戶端處於 SYN-SEND 狀態，SYN-SEND 表示傳送連線請求後等待匹配的連線請求，伺服器被動開啟會處於 LISTEN 狀態，用於監聽 SYN 報文。如果客戶端呼叫了 close 方法或者經過一段時間沒有操作，就會重新變為 CLOSED 狀態，這一步轉換圖如下
這裡有個疑問，為什麼處於 LISTEN 狀態下的客戶端還會傳送 SYN 變為 SYN_SENT 狀態呢？
知乎看到了車小胖大佬的回答，這種情況可能出現在 FTP 中，LISTEN -> SYN_SENT 是因為這個連線可能是由於伺服器端的應用有資料傳送給客戶端所觸發的，客戶端被動接受連線，連線建立後，開始傳輸檔案。也就是說，處於 LISTEN 狀態的伺服器也是有可能傳送 SYN 報文的，只不過這種情況非常少見。
處於 SYN_SEND 狀態的伺服器會接收 SYN 併傳送 SYN 和 ACK 轉換成為 SYN_RCVD 狀態，同樣的，處於 LISTEN 狀態的客戶端也會接收 SYN 併傳送 SYN 和 ACK 轉換為 SYN_RCVD 狀態。如果處於 SYN_RCVD 狀態的客戶端收到 RST 就會變為 LISTEN 狀態。
這兩張圖一起看會比較好一些。
這裡需要解釋下什麼是 RST
這裡有一種情況是當主機收到 TCP 報文段後，其 IP 和埠號不匹配的情況。假設客戶端主機傳送一個請求，而伺服器主機經過 IP 和埠號的判斷後發現不是給這個伺服器的，那麼伺服器就會發出一個 RST 特殊報文段給客戶端。
因此，當服務端傳送一個 RST 特殊報文段給客戶端的時候，它就會告訴客戶端沒有匹配的套接字連線，請不要再繼續傳送了。
RST：（Reset the connection）用於復位因某種原因引起出現的錯誤連線，也用來拒絕非法資料和請求。如果接收到 RST 位時候，通常發生了某些錯誤。
上面沒有識別正確的 IP 埠是一種導致 RST 出現的情況，除此之外，RST 還可能由於請求超時、取消一個已存在的連線等出現。
位於 SYN_RCVD 的伺服器會接收 ACK 報文，SYN_SEND 的客戶端會接收 SYN 和 ACK 報文，併傳送 ACK 報文，由此，客戶端和伺服器之間的連線就建立了。
這裡還要注意一點，同時開啟的狀態我在上面沒有刻意表示出來，實際上，在同時開啟的情況下，它的狀態變化是這樣的。
為什麼會是這樣呢？因為你想，在同時開啟的情況下，兩端主機都發起 SYN 報文，而主動發起 SYN 的主機會處於 SYN-SEND 狀態，傳送完成後，會等待接收 SYN 和 ACK ， 在雙方主機都傳送了 SYN + ACK 後，雙方都處於 SYN-RECEIVED(SYN-RCVD) 狀態，然後等待 SYN + ACK 的報文到達後，雙方就會處於 ESTABLISHED 狀態，開始傳輸資料。
好了，到現在為止，我給你敘述了一下 TCP 連線建立過程中的狀態轉換，現在你可以泡一壺茶喝點水，等著資料傳輸了。
好了，現在水喝夠了，這時候資料也傳輸完成了，資料傳輸完成後，這條 TCP 連線就可以斷開了。
現在我們把時鐘往前撥一下，調整到服務端處於 SYN_RCVD 狀態的時刻，因為剛收到了 SYN 包併傳送了 SYN + ACK 包，此時服務端很開心，但是這時，服務端應用程式關閉了，然後應用程式發了一個 FIN 包，就會讓伺服器從 SYN_RCVD -> FIN_WAIT_1 狀態。
然後把時鐘調到現在，客戶端和伺服器現在已經傳輸完資料了 ，此時客戶端傳送了一條 FIN 報文希望斷開連線，此時客戶端也會變為 FIN_WAIT_1 狀態，對於伺服器來說，它接收到了 FIN 報文段並回復了 ACK 報文，就會從 ESTABLISHED -> CLOSE_WAIT 狀態。
位於 CLOSE_WAIT 狀態的服務端會傳送 FIN 報文，然後把自己置於 LAST_ACK 狀態。處於 FIN_WAIT_1 的客戶端接收 ACK 訊息就會變為 FIN_WAIT_2 狀態。
這裡需要先解釋一下 CLOSING 這個狀態，FIN_WAIT_1 -> CLOSING 的轉換比較特殊
CLOSING 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN 報文後，按理來說是應該先收到（或同時收到）對方的 ACK 報文，再收到對方的 FIN 報文。但是 CLOSING 狀態表示你傳送 FIN 報文後，並沒有收到對方的 ACK 報文，反而卻也收到了對方的 FIN 報文。
什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方在同時關閉一個連結的話，那麼就出現了同時傳送 FIN 報文的情況，也即會出現 CLOSING 狀態，表示雙方都正在關閉連線。
FIN_WAIT_2 狀態的客戶端接收服務端主機傳送的 FIN + ACK 訊息，併傳送 ACK 響應後，會變為 TIME_WAIT 狀態。處於 CLOSE_WAIT 的客戶端傳送 FIN 會處於 LAST_ACK 狀態。
這裡不少圖和部落格雖然在圖上畫的是 FIN + ACK 報文後才會處於 LAST_ACK 狀態，但是描述的時候，一般通常只對於 FIN 進行描述。也就是說 CLOSE_WAIT 傳送 FIN 才會處於 LAST_ACK 狀態。
所以這裡 FIN_WAIT_1 -> TIME_WAIT 的狀態也就是接收 FIN 和 ACK 併傳送 ACK 之後，客戶端處於的狀態。
然後位於 CLOSINIG 狀態的客戶端這時候還有 ACK 接收的話，會繼續處於 TIME_WAIT 狀態，可以看到，TIME_WAIT 狀態相當於是客戶端在關閉前的最後一個狀態，它是一種主動關閉的狀態；而 LAST_ACK 是服務端在關閉前的最後一個狀態，它是一種被動開啟的狀態。
上面有幾個狀態比較特殊，這裡我們向西解釋下。
TIME_WAIT 狀態
通訊雙方建立 TCP 連線後，主動關閉連線的一方就會進入 TIME_WAIT 狀態。TIME_WAIT 狀態也稱為 2MSL 的等待狀態。在這個狀態下，TCP 將會等待最大段生存期(Maximum Segment Lifetime, MSL) 時間的兩倍。
這裡需要解釋下 MSL
MSL 是 TCP 段期望的最大生存時間，也就是在網路中存在的最長時間。這個時間是有限制的，因為我們知道 TCP 是依靠 IP 資料段來進行傳輸的，IP 資料包中有 TTL 和跳數的欄位，這兩個欄位決定了 IP 的生存時間，一般情況下，TCP 的最大生存時間是 2 分鐘，不過這個數值是可以修改的，根據不同作業系統可以修改此值。
基於此，我們來探討 TIME_WAIT 的狀態。
當 TCP 執行一個主動關閉併傳送最終的 ACK 時，TIME_WAIT 應該以 2 * 最大生存時間存在，這樣就能夠讓 TCP 重新傳送最終的 ACK 以避免出現丟失的情況。重新傳送最終的 ACK 並不是因為 TCP 重傳了 ACK，而是因為通訊另一方重傳了 FIN，客戶端經常回傳送 FIN，因為它需要 ACK 的響應才能夠關閉連線，如果生存時間超過了 2MSL 的話，客戶端就會傳送 RST，使服務端出錯。
TCP 超時和重傳
沒有永遠不出錯誤的通訊，這句話表明著不管外部條件多麼完備，永遠都會有出錯的可能。所以，在 TCP 的正常通訊過程中，也會出現錯誤，這種錯誤可能是由於資料包丟失引起的，也可能是由於資料包重複引起的，甚至可能是由於資料包失序 引起的。
TCP 的通訊過程中，會由 TCP 的接收端返回一系列的確認資訊來判斷是否出現錯誤，一旦出現丟包等情況，TCP 就會啟動重傳操作，重傳尚未確認的資料。
TCP 的重傳有兩種方式，一種是基於時間，一種是基於確認資訊，一般通過確認資訊要比通過時間更加高效。
所以從這點就可以看出，TCP 的確認和重傳，都是基於資料包是否被確認為前提的。
TCP 在傳送資料時會設定一個定時器，如果在定時器指定的時間內未收到確認資訊，那麼就會觸發相應的超時或者基於計時器的重傳操作，計時器超時通常被稱為重傳超時(RTO)。
但是有另外一種不會引起延遲的方式，這就是快速重傳。
TCP 在每次重傳一次報文後，其重傳時間都會加倍，這種"間隔時間加倍"被稱為二進位制指數補償(binary exponential backoff) 。等到間隔時間加倍到 15.5 min 後，客戶端會顯示
Connection closed by foreign host.
TCP 擁有兩個閾值來決定如何重傳一個報文段，這兩個閾值被定義在 RFC[RCF1122] 中，第一個閾值是 R1，它表示願意嘗試重傳的次數，閾值 R2 表示 TCP 應該放棄連線的時間。R1 和 R2 應至少設為三次重傳和 100 秒放棄 TCP 連線。
這裡需要注意下，對連線建立報文 SYN 來說，它的 R2 至少應該設定為 3 分鐘，但是在不同的系統中，R1 和 R2 值的設定方式也不同。
在 Linux 系統中，R1 和 R2 的值可以通過應用程式來設定，或者是修改 net.ipv4.tcp_retries1 和 net.ipv4.tcp_retries2 的值來設定。變數值就是重傳次數。
tcp_retries2 的預設值是 15，這個充實次數的耗時大約是 13 - 30 分鐘，這只是一個大概值，最終耗時時間還要取決於 RTO ，也就是重傳超時時間。tcp_retries1 的預設值是 3 。
對於 SYN 段來說，net.ipv4.tcp_syn_retries 和 net.ipv4.tcp_synack_retries 這兩個值限制了 SYN 的重傳次數，預設是 5，大約是 180 秒。
Windows 作業系統下也有 R1 和 R2 變數，它們的值被定義在下方的登錄檔中
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters
其中有一個非常重要的變數就是 TcpMaxDataRetransmissions，這個 TcpMaxDataRetransmissions 對應 Linux 中的 tcp_retries2 變數，預設值是 5。這個值的意思表示的是 TCP 在現有連線上未確認資料段的次數。
快速重傳
我們上面提到了快速重傳，實際上快速重傳機制是基於接收端的反饋資訊來觸發的，它並不受重傳計時器的影響。所以與超時重傳相比，快速重傳能夠有效的修復丟包情況。當 TCP 連線的過程中接收端出現亂序的報文（比如 2 - 4 - 3）到達時，TCP 需要立刻生成確認訊息，這種確認訊息也被稱為重複 ACK。
當失序報文到達時，重複 ACK 要做到立刻返回，不允許延遲傳送，此舉的目的是要告訴傳送方某段報文失序到達了，希望傳送方指出失序報文段的序列號。
還有一種情況也會導致重複 ACK 發給傳送方，那就是當前報文段的後續報文傳送至接收端，由此可以判斷當前傳送方的報文段丟失或者延遲到達。因為這兩種情況導致的後果都是接收方沒有收到報文，但是我們卻無法判斷到底是報文段丟失還是報文段沒有送達。因此 TCP 傳送端會等待一定數目的重複 ACK 被接受來決定資料是否丟失並觸發快速重傳。一般這個判斷的數量是 3，這段文字表述可能無法清晰理解，我們舉個例子。
如上圖所示，報文段 1 成功接收並被確認為 ACK 2，接收端的期待序號為 2，當報文段 2 丟失後，報文段 3。失序到達，但是與接收端的期望不匹配，所以接收端會重複傳送冗餘 ACK 2。
這樣，在超時重傳定時器到期之前，接收收到連續三個相同的 ACK 後，傳送端就知道哪個報文段丟失了，於是傳送方會重發這個丟失的報文段，這樣就不用等待重傳定時器的到期，大大提高了效率。
SACK
在標準的 TCP 確認機制中，如果傳送方傳送了 0 - 10000 序號之間的資料，但是接收方只接收到了 0 -1000, 3000 - 10000 之間的資料，而 1000 - 3000 之間的資料沒有到達接收端，此時傳送方會重傳 1000 - 10000 之間的資料，實際上這是沒有必要的，因為 3000 後面的資料已經被接收了。但是傳送方無法感知這種情況的存在。
如何避免或者說解決這種問題呢？
為了優化這種情況，我們有必要讓客戶端知道更多的訊息，在 TCP 報文段中，有一個 SACK 選項欄位，這個欄位是一種選擇性確認(selective acknowledgment)機制，這個機制能告訴 TCP 客戶端，用我們的俗語來解釋就是：“我這裡最多允許接收 1000 之後的報文段，但是我卻收到了 3000 - 10000 的報文段，請給我 1000 - 3000 之間的報文段”。
但是，這個選擇性確認機制的是否開啟還受一個欄位的影響，這個欄位就是 SACK 允許選項欄位，通訊雙方在 SYN 段或者 SYN + ACK 段中新增 SACK 允許選項欄位來通知對端主機是否支援 SACK，如果雙方都支援的話，後續在 SYN 段中就可以使用 SACK 選項了。
這裡需要注意下：SACK 選項欄位只能出現在 SYN 段中。
偽超時和重傳
在某些情況下，即使沒有出現報文段的丟失也可能會引發報文重傳。這種重傳行為被稱為 偽重傳(spurious retransmission) ，這種重傳是沒有必要的，造成這種情況的因素可能是由於偽超時(spurious timeout)，偽超時的意思就是過早的判定超時發生。造成偽超時的因素有很多，比如報文段失序到達，報文段重複，ACK 丟失等情況。
檢測和處理偽超時的方法有很多，這些方法統稱為檢測演算法和響應演算法。檢測演算法用於判斷是否出現了超時現象或出現了計時器的重傳現象。一旦出現了超時或者重傳的情況，就會執行響應演算法撤銷或者減輕超時帶來的影響，下面是幾種演算法，此篇文章暫不深入這些實現細節
- 重複 SACK 擴充套件- DSACK
- Eifel 檢測演算法
- 前移 RTO 恢復 - F-RTO
- Eifel 響應演算法
包失序和包重複
上面我們討論的都是 TCP 如何處理丟包的問題，我們下面來討論一下包失序和包重複的問題。
包失序
資料包的失序到達是網際網路中極其容易出現的一種情況，由於 IP 層並不能保證資料包的有序性，每個資料包的傳送都可能會選擇當前情況傳輸速度最快的鏈路，所以很有可能出現傳送了 A - > B -> C 的三個資料包，到達接收端的資料包順序是 C -> A -> B 或者 B -> C -> A 等等。這就是包失序的一種現象。
在包傳輸中，主要分為兩種鏈路：正向鏈路（SYN）和反向鏈路（ACK）
如果失序發生在正向鏈路，TCP 是無法正確判斷資料包是否丟失的，資料的丟失和失序都會導致接收端收到無序的資料包，造成資料之間的空缺。如果這種空缺不夠大的話，這種情況影響不大；但是如果空缺比較大的話，可能會導致偽重傳。
如果失序發生在反向鏈路，就會使 TCP 的視窗前移，然後收到重複而應該被丟棄的 ACK，導致傳送端出現不必要的流量突發，影響可用網路頻寬。
回到我們上面討論的快速重傳，由於快速重傳是根據重複 ACK 推斷出現丟包而啟動的，它不用等到重傳計時器超時。由於 TCP 接收端會對接收到的失序報文立刻返回 ACK，所以網路中任何一個失序到達的報文都可能會造成重複 ACK。假設一旦收到 ACK，就會啟動快速重傳機制，當 ACK 數量激增，就會導致大量不必要的重傳發生，所以快速重傳應該達到重複閾值(dupthresh) 再觸發。但是在網際網路中，嚴重的失序並不常見，因此 dupthresh 的值可以設定的儘量小，一般來說 3 就能處理絕大部分情況。
包重複
包重複也是網際網路中出現很少的一種情況，它指的是在網路傳輸過程中，包可能會出現傳輸多次的情況，當重傳生成時，TCP 可能會出現混淆。
包的重複可以使接收端生成一系列的重複 ACK，這種情況可以使用 SACK 協商來解決。
TCP 資料流和視窗管理
我們在 40 張圖帶你搞懂 TCP 和 UDP 這篇文章中知道了可以使用滑動視窗來實現流量控制，也就是說，客戶端和伺服器可以相互提供資料流資訊的交換，資料流的相關資訊主要包括報文段序列號、ACK 號和視窗大小。
圖中的兩個箭頭表示資料流方向，資料流方向也就是 TCP 報文段的傳輸方向。可以看到，每個 TCP 報文段中都包括了序列號、ACK 和視窗資訊，可能還會有使用者資料。TCP 報文段中的視窗大小表示接收端還能夠接收的快取空間的大小，以位元組為單位。這個視窗大小是一種動態的，因為無時無刻都會有報文段的接收和消失，這種動態調整的視窗大小我們稱之為滑動視窗，下面我們就來具體認識一下滑動視窗。
滑動視窗
TCP 連線的每一端都可以傳送資料，但是資料的傳送不是沒有限制的，實際上，TCP 連線的兩端都各自維護了一個傳送視窗結構 (send window structure) 和 接收視窗結構 (receive window structure)，這兩個視窗結構就是資料傳送的限制。
傳送方視窗
下圖是一個傳送方視窗的示例。
在這幅圖中，涉及滑動視窗的四種概念：
- 已經傳送並確認的報文段：傳送給接收方後，接收方回回復 ACK 來對報文段進行響應，圖中標註綠色的報文段就是已經經過接收方確認的報文段。
- 已經傳送但是還沒確認的報文段：圖中綠色區域是經過接收方確認的報文段，而淺藍色這段區域指的是已經傳送但是還未經過接收方確認的報文段。
- 等待傳送的報文段：圖中深藍色區域是等待傳送的報文段，它屬於傳送視窗結構的一部分，也就是說，傳送視窗結構其實是由已傳送未確認 + 等待傳送的報文段構成。
- 視窗滑動時才能傳送的報文段：如果圖中的 [4,9] 這個集合內的報文段傳送完畢後，整個滑動視窗會向右移動，圖中橙色區域就是視窗右移時才能傳送的報文段。
滑動視窗也是有邊界的，這個邊界是 Left edge 和 Right edge，Left edge 是視窗的左邊界，Right edge 是視窗的右邊界。
當 Left edge 向右移動而 Right edge 不變時，這個視窗可能處於 close 關閉狀態。隨著已傳送的資料逐漸被確認從而導致視窗變小時，就會發生這種情況。
當 Right edge 向右移動時，視窗會處於 open 開啟狀態，允許傳送更多的資料。當接收端程式讀取緩衝區資料，從而使緩衝區接收更多資料時，就會處於這種狀態。
還可能會發生 Right edge 向左移動的情況，會導致傳送並確認的報文段變小，這種情況被稱為糊塗視窗綜合症，這種情況是我們不願意看到的。出現糊塗視窗綜合症時，通訊雙方用於交換的資料段大小會變小，而網路固定的開銷卻沒有變化，每個報文段中有用資料相對於頭部資訊的比例較小，導致傳輸效率非常低。
這就相當於之前你明明有能力花一天時間寫完一個複雜的頁面，現在你花了一天的時間卻改了一個標題的 bug，大材小用。
每個 TCP 報文段都包含ACK 號和視窗通告資訊，所以每當收到響應時，TCP 接收方都會根據這兩個引數調整視窗結構。
TCP 滑動視窗的 Left edge 永遠不可能向左移動，因為傳送並確認的報文段永遠不可能被取消，就像這世界上沒有後悔藥一樣。這條邊緣是由另一段傳送的 ACK 號控制的。當 ACK 標號使視窗向右移動但是視窗大小沒有改變時，則稱該視窗向前滑動。
如果 ACK 的編號增加但是視窗通告資訊隨著其他 ACK 的到達卻變小了，此時 Left edge 會接近 Right edge。當 Left edge 和 Right edge 重合時，此時傳送方不會再傳輸任何資料，這種情況被稱為零視窗。此時 TCP 傳送方會發起視窗探測，等待合適的時機再傳送資料。
接收方視窗
接收方也維護了一個視窗結構，這個視窗要比傳送方的簡單很多。這個視窗記錄了已經接收並確認的資料，以及它能夠接收的最大序列號。接收方的視窗結構不會儲存重複的報文段和 ACK，同時接收方的視窗也不會記錄不應該收到的報文段和 ACK。下面是 TCP 接收方的視窗結構。
與傳送端的視窗一樣，接收方視窗結構也維護了一個 Left edge 和 Right edge。位於 Left edge 左邊的被稱為已經接收並確認的報文段，位於 Right edge 右邊的被稱為不能接收的報文段。
對於接收端來說，到達序列號小於 Left efge 的被認為是已經重複的資料，需要丟棄。超過 Right edge 的被認為超出處理範圍。只有當到達的報文段等於 Left edge 時，資料才不會被丟棄，視窗才能夠向前滑動。
接收方視窗結構也會存在零視窗的情況，如果某個應用程式消耗資料很慢，而 TCP 傳送方卻傳送了大量的資料給接收方，會造成 TCP 緩衝區溢位，通告傳送方不要再傳送資料了，但是應用程式卻以非常慢的速度消耗緩衝區的資料（比如 1 位元組），就會告訴接收端只能傳送一個位元組的資料，這個過程慢慢持續，造成網路開銷大，效率很低。
我們上面提到了視窗存在 Left edge = Right edge 的情況，此時被稱為零視窗，下面我們就來具體研究一下零視窗。
零視窗
TCP 是通過接收端的視窗通告資訊來實現流量控制的。通告視窗告訴了 TCP ，接收端能夠接收的資料量。當接收方的視窗變為 0 時，可以有效的阻止傳送端繼續傳送資料。當接收端重新獲得可用空間時，它會給傳送端傳輸一個 視窗更新 告知自己能夠接收資料了。視窗更新一般是純 ACK ，即不帶任何資料。但是純 ACK 不能保證一定會到達傳送端，於是需要有相關的措施能夠處理這種丟包。
如果純 ACK 丟失的話，通訊雙方就會一直處於等待狀態，傳送方心想拉垮的接收端怎麼還讓我傳送資料！接收端心想天殺的傳送方怎麼還不發資料！為了防止這種情況，傳送方會採用一個持續計時器來間歇性的查詢接收方，看看其視窗是否已經增長。持續計時器會觸發視窗探測，強制要求接收方返回帶有更新視窗的 ACK。
視窗探測包含一個位元組的資料，採用的是 TCP 丟失重傳的方式。當 TCP 持續計時器超時後，就會觸發視窗探測的傳送。一個位元組的資料能否被接收端接收，還要取決於其緩衝區的大小。
擁塞控制
有了 TCP 的視窗控制後，使計算機網路中兩個主機之間不再是以單個資料段的形式傳送了，而是能夠連續傳送大量的資料包。然而，大量資料包同時也伴隨著其他問題，比如網路負載、網路擁堵等問題。TCP 為了防止這類問題的出現，使用了 擁塞控制 機制，擁塞控制機制會在面臨網路擁塞時遏制傳送方的資料傳送。
擁塞控制主要有兩種方法
端到端的擁塞控制: 因為網路層沒有為運輸層擁塞控制提供顯示支援。所以即使網路中存在擁塞情況，端系統也要通過對網路行為的觀察來推斷。TCP 就是使用了端到端的擁塞控制方式。IP 層不會向端系統提供有關網路擁塞的反饋資訊。那麼 TCP 如何推斷網路擁塞呢？如果超時或者三次冗餘確認就被認為是網路擁塞，TCP 會減小視窗的大小，或者增加往返時延來避免。網路輔助的擁塞控制: 在網路輔助的擁塞控制中，路由器會向傳送方提供關於網路中擁塞狀態的反饋。這種反饋資訊就是一個位元資訊，它指示鏈路中的擁塞情況。
下圖描述了這兩種擁塞控制方式
TCP 擁塞控制
如果你看到這裡，那我就暫定認為你瞭解了 TCP 實現可靠性的基礎了，那就是使用序號和確認號。除此之外，另外一個實現 TCP 可靠性基礎的就是 TCP 的擁塞控制。如果說
TCP 所採用的方法是讓每一個傳送方根據所感知到的網路的擁塞程度來限制發出報文段的速率，如果 TCP 傳送方感知到沒有什麼擁塞，則 TCP 傳送方會增加傳送速率；如果傳送方感知沿著路徑有阻塞，那麼傳送方就會降低傳送速率。
但是這種方法有三個問題
- TCP 傳送方如何限制它向其他連線傳送報文段的速率呢？
- 一個 TCP 傳送方是如何感知到網路擁塞的呢？
- 當傳送方感知到端到端的擁塞時，採用何種演算法來改變其傳送速率呢？
我們先來探討一下第一個問題，TCP 傳送方如何限制它向其他連線傳送報文段的速率呢？
我們知道 TCP 是由接收快取、傳送快取和變數(LastByteRead, rwnd，等)組成。傳送方的 TCP 擁塞控制機制會跟蹤一個變數，即 擁塞視窗(congestion window) 的變數，擁塞視窗表示為 cwnd，用於限制 TCP 在接收到 ACK 之前可以傳送到網路的資料量。而接收視窗(rwnd) 是一個用於告訴接收方能夠接受的資料量。
一般來說，傳送方未確認的資料量不得超過 cwnd 和 rwnd 的最小值，也就是
LastByteSent - LastByteAcked <= min(cwnd,rwnd)
由於每個資料包的往返時間是 RTT，我們假設接收端有足夠的快取空間用於接收資料，我們就不用考慮 rwnd 了，只專注於 cwnd，那麼，該傳送方的傳送速率大概是 cwnd/RTT 位元組/秒 。通過調節 cwnd，傳送方因此能調整它向連線傳送資料的速率。
一個 TCP 傳送方是如何感知到網路擁塞的呢？
這個我們上面討論過，是 TCP 根據超時或者 3 個冗餘 ACK 來感知的。
當傳送方感知到端到端的擁塞時，採用何種演算法來改變其傳送速率呢 ?
這個問題比較複雜，且容我娓娓道來，一般來說，TCP 會遵循下面這幾種指導性原則
- 如果在報文段傳送過程中丟失，那就意味著網路擁堵，此時需要適當降低 TCP 傳送方的速率。
- 一個確認報文段指示傳送方正在向接收方傳遞報文段，因此，當對先前未確認報文段的確認到達時，能夠增加傳送方的速率。為啥呢？因為未確認的報文段到達接收方也就表示著網路不擁堵，能夠順利到達，因此傳送方擁塞視窗長度會變大，所以傳送速率會變快
頻寬探測，頻寬探測說的是 TCP 可以通過調節傳輸速率來增加/減小 ACK 到達的次數，如果出現丟包事件，就會減小傳輸速率。因此，為了探測擁塞開始出現的頻率， TCP 傳送方應該增加它的傳輸速率。然後慢慢使傳輸速率降低，進而再次開始探測，看看擁塞開始速率是否發生了變化。
在瞭解完 TCP 擁塞控制後，下面我們就該聊一下 TCP 的 擁塞控制演算法(TCP congestion control algorithm) 了。TCP 擁塞控制演算法主要包含三個部分：慢啟動、擁塞避免、快速恢復，下面我們依次來看一下
慢啟動
當一條 TCP 開始建立連線時，cwnd 的值就會初始化為一個 MSS 的較小值。這就使得初始傳送速率大概是 MSS/RTT 位元組/秒 ，比如要傳輸 1000 位元組的資料，RTT 為 200 ms ，那麼得到的初始傳送速率大概是 40 kb/s 。實際情況下可用頻寬要比這個 MSS/RTT 大得多，因此 TCP 想要找到最佳的傳送速率，可以通過 慢啟動(slow-start) 的方式，在慢啟動的方式中，cwnd 的值會初始化為 1 個 MSS，並且每次傳輸報文確認後就會增加一個 MSS，cwnd 的值會變為 2 個 MSS，這兩個報文段都傳輸成功後每個報文段 + 1，會變為 4 個 MSS，依此類推，每成功一次 cwnd 的值就會翻倍。如下圖所示
傳送速率不可能會一直增長，增長總有結束的時候，那麼何時結束呢？慢啟動通常會使用下面這幾種方式結束髮送速率的增長。
- 如果在慢啟動的傳送過程出現丟包的情況，那麼 TCP 會將傳送方的 cwnd 設定為 1 並重新開始慢啟動的過程，此時會引入一個
ssthresh(慢啟動閾值)的概念，它的初始值就是產生丟包的 cwnd 的值 / 2，即當檢測到擁塞時，ssthresh 的值就是視窗值的一半。 - 第二種方式是直接和 ssthresh 的值相關聯，因為當檢測到擁塞時，ssthresh 的值就是視窗值的一半，那麼當 cwnd > ssthresh 時，每次翻番都可能會出現丟包，所以最好的方式就是 cwnd 的值 = ssthresh ，這樣 TCP 就會轉為擁塞控制模式，結束慢啟動。
- 慢啟動結束的最後一種方式就是如果檢測到 3 個冗餘 ACK，TCP 就會執行一種快速重傳並進入恢復狀態。
擁塞避免
當 TCP 進入擁塞控制狀態後，cwnd 的值就等於擁塞時值的一半，也就是 ssthresh 的值。所以，無法每次報文段到達後都將 cwnd 的值再翻倍。而是採用了一種相對保守的方式，每次傳輸完成後只將 cwnd 的值增加一個 MSS，比如收到了 10 個報文段的確認，但是 cwnd 的值只增加一個 MSS。這是一種線性增長模式，它也會有增長逾值，它的增長逾值和慢啟動一樣，如果出現丟包，那麼 cwnd 的值就是一個 MSS，ssthresh 的值就等於 cwnd 的一半；或者是收到 3 個冗餘的 ACK 響應也能停止 MSS 增長。如果 TCP 將 cwnd 的值減半後，仍然會收到 3 個冗餘 ACK，那麼就會將 ssthresh 的值記錄為 cwnd 值的一半，進入 快速恢復 狀態。
快速恢復
在快速恢復中，對於使 TCP 進入快速恢復狀態缺失的報文段，對於每個收到的冗餘 ACK，cwnd 的值都會增加一個 MSS 。當對丟失報文段的一個 ACK 到達時，TCP 在降低 cwnd 後進入擁塞避免狀態。如果在擁塞控制狀態後出現超時，那麼就會遷移到慢啟動狀態，cwnd 的值被設定為 1 個 MSS，ssthresh 的值設定為 cwnd 的一半。
我自己肝了六本 PDF，全網傳播超過10w+ ，微信搜尋「程式設計師cxuan」關注公眾號後，在後臺回覆 cxuan ，領取全部 PDF，這些 PDF 如下