TCP的概述

TCP 把連線作為最基本的物件，每一條 TCP 連線都有兩個端點，這種斷點我們叫作套接字（socket），它的定義為埠號拼接到 IP 地址即構成了套接字，例如，若 IP 地址為 192.3.4.16  而埠號為 80，那麼得到的套接字為 192.3.4.16:80 。

但凡是基於 TCP 協議通訊的，在通訊之前，客戶端與服務端之間都會在邏輯層面上建立一個雙向通路。注意這裡是邏輯層面上，在物理層面上僅僅只是一條通訊的介質。

假設在 A、B 之間修路，我現在在 A 點，我要告訴 B，“我要修一條到你那的路了”，B 同意了，於是路修好了。但這隻能是 A 到 B，你不能逆向行駛，所以還要修一條從 B 到 A 的，這時就是 B 告訴 A，“我也要修一條到你那的路”，A 同意了，這才修好了一個雙向通路。

上面就是四次請求或應答建立的連線，但是在網路中，B的同意和請求是作為一條路線的。因為一個軟體的效率的高低取決於最慢的點，A 和 B 構成的軟體如果基於 TCP 通訊，衡量這個軟體的執行效率是A和B以及網路總體的效率，而網路恰恰是最慢的點。網路延遲的時間受限於現有的物理水平無法解決，而在程式開發中，網路的傳輸次數一定是越少越好，次數越少，網路延遲的總時間就越少。

其實 TCP 三次握手的目的就是為了建立雙向通路從而傳輸資料，然而此時沒有真正的資料在傳輸，TCP 三次握手是在為傳輸資料做準備，所以要快速建立一個雙向通路，因而中間的兩次可以作為一次（因為這時沒有傳輸資料），這才是真正的三次握手，之所以這樣引入是為四次揮手斷連線做理解。

TCP報文首部

1）源埠和目的埠，各佔 2 個位元組，分別寫入源埠和目的埠；

2）序號，佔 4 個位元組，TCP連線中傳送的位元組流中的每個位元組都按順序編號。例如，一段報文的序號欄位值是 301 ，而攜帶的資料共有 100 欄位，顯然下一個報文段（如果還有的話）的資料序號應該從 401 開始；

3）確認號，佔 4 個位元組，是期望收到對方下一個報文的第一個資料位元組的序號。例如，B 收到了 A 傳送過來的報文，其序列號欄位是 501，而資料長度是 200 位元組，這表明B正確的收到了A傳送的到序號 700 為止的資料。因此，B 期望收到A的下一個資料序號是 701，於是 B 在傳送給 A 的確認報文段中把確認號置為 701 ；

4）資料偏移，佔 4 位，它指出 TCP 報文的資料距離 TCP 報文段的起始處有多遠；

5）保留，佔 6 位，保留今後使用，但目前應都位 0；

6）緊急 URG，當 URG=1，表明緊急指標欄位有效。告訴系統此報文段中有緊急資料；

7）確認 ACK，僅當 ACK=1 時，確認號欄位才有效。TCP 規定，在連線建立後所有報文的傳輸都必須把 ACK 置 1；

8）推送 PSH，當兩個應用程序進行互動式通訊時，有時在一端的應用程序希望在鍵入一個命令後立即就能收到對方的響應，這時候就將 PSH=1 ；

9）復位 RST，當 RST=1 ，表明 TCP 連線中出現嚴重差錯，必須釋放連線，然後再重新建立連線；

10）同步 SYN，在連線建立時用來同步序號。當 SYN=1，ACK=0，表明是連線請求報文，若同意連線，則響應報文中應該使 SYN=1，ACK=1；

11）終止 FIN，用來釋放連線。當 FIN=1，表明此報文的傳送方的資料已經發送完畢，並且要求釋放；

12）視窗，佔 2 位元組，指的是通知接收方，傳送本報文你需要有多大的空間來接受；

13）檢驗和，佔 2 位元組，校驗首部和資料這兩部分；

14）緊急指標，佔 2 位元組，指出本報文段中的緊急資料的位元組數；

15）選項，長度可變，定義一些其他的可選的引數。

TCP建立連線的三次握手

最開始的時候客戶端和伺服器都是處於 CLOSED 狀態。主動開啟連線的為客戶端，被動開啟連線的是伺服器。

1）TCP 伺服器程序先建立傳輸控制塊 TCB，時刻準備接受客戶程序的連線請求，此時伺服器就進入了 LISTEN（監聽）狀態；

2）TCP 客戶程序也是先建立傳輸控制塊 TCB，然後向伺服器發出連線請求報文，這是報文首部中的同步位 SYN=1，同時選擇一個初始序列號 seq=x 。TCP規定，SYN 報文段（SYN=1 的報文段）不能攜帶資料，但需要消耗掉一個序號。此時，TCP 客戶端程序進入了 SYN-SENT（同步已傳送狀態）狀態。

3）TCP 伺服器收到請求報文後，如果同意連線，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP伺服器程序進入了 SYN-RCVD（同步收到）狀態。這個報文也不能攜帶資料，但是同樣要消耗一個序號。

4）TCP 客戶程序收到確認後，還要向伺服器給出確認。確認報文的 ACK=1，ack=y+1，自己的序列號 seq=x+1，此時，TCP 連線建立，客戶端進入 ESTABLISHED（已建立連線）狀態。TCP規定，ACK報文段可以攜帶資料，但是如果不攜帶資料則不消耗序號。

5）當伺服器收到客戶端的確認後也進入 ESTABLISHED 狀態，此後雙方就可以開始通訊了。 

為什麼TCP客戶端最後還要傳送一次確認呢？

這主要是為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。

假定客戶端發出的某一個連線請求報文段在傳輸的過程中並沒有丟失，而是在某個網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才到達服務端。本來這是一個早已失效的報文段。但服務端收到此失效的連線請求報文段後，就誤以為客戶端又發了一次新的連線請求，於是向客戶端發出確認報文段，同意建立連線。假如不採用三次握手，那麼只要服務端發出確認，新的連線就建立了。

由於客戶端並未發出建立連線的請求，因此不會理睬服務端的確認，也不會向服務端傳送資料。但服務端卻以為新的運輸連線已經建立了，並一直等待客戶端發來資料，因此白白浪費了許多資源。

採用TCP三次握手的方法可以防止上述現象發生。例如在剛才的情況下，由於客戶端不會向服務端的確認發出確認，服務端由於收不到確認，就知道客戶端並沒有要求建立連線。

TCP釋放連線的四次揮手

TCP 三次握手的目的是為了建立雙向通路從而傳輸資料，當資料傳輸完畢後，雙方都可釋放連線。最開始的時候，客戶端和伺服器都是處於 ESTABLISHED 狀態，然後客戶端主動關閉，伺服器被動關閉。

1）客戶端程序發出連線釋放報文，並且停止傳送資料。釋放資料報文首部，FIN=1，其序列號為 seq=u（等於前面已經傳送過來的資料的最後一個位元組的序號加1），此時，客戶端進入 FIN-WAIT-1（終止等待1）狀態，等待服務端的確認。

2）伺服器收到連線釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號 seq=v，此時，服務端就進入了 CLOSE-WAIT（關閉等待）狀態。TCP伺服器通知高層的應用程序，客戶端向伺服器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有資料要傳送了，但是伺服器若傳送資料，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個 CLOSE-WAIT 狀態持續的時間。

3）客戶端收到伺服器的確認請求後，此時，客戶端就進入 FIN-WAIT-2（終止等待2）狀態，等待伺服器傳送連線釋放報文（在這之前還需要接受伺服器傳送的最後的資料）。

4）伺服器將最後的資料傳送完畢後，就向客戶端傳送連線釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，伺服器很可能又傳送了一些資料，假定此時的序列號為 seq=w，此時，伺服器就進入了 LAST-ACK（最後確認）狀態，等待客戶端的確認。

5）客戶端收到伺服器的連線釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是 seq=u+1，此時，客戶端就進入了 TIME-WAIT（時間等待）狀態。注意此時 TCP 連線還沒有釋放，必須經過 2MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的 TCB 後，才進入 CLOSED 狀態。

6）伺服器只要收到了客戶端發出的確認，立即進入 CLOSED 狀態。同樣，撤銷 TCB 後，就結束了這次的 TCP 連線。至此完成了 TCP 四次揮手斷開連線全過程。可以看到，伺服器結束 TCP 連線的時間要比客戶端早一些。

 為什麼客戶端最後還要等待 2MSL ？

MSL（Maximum Segment Lifetime），TCP 允許不同的實現可以設定不同的MSL值。

第一，保證客戶端傳送的最後一個 ACK 報文能夠到達伺服器，因為這個 ACK 報文可能丟失，站在伺服器的角度看來，我已經發送了 FIN+ACK 報文請求斷開了，客戶端還沒有給我回應，應該是我傳送的請求斷開報文它沒有收到，於是伺服器又會重新發送一次，而客戶端就能在這個 2MSL 時間段內收到這個重傳的報文，接著給出迴應報文，並且會重啟2MSL計時器。

第二，防止類似與 “三次握手” 中提到了的 “已經失效的連線請求報文段” 出現在本連線中。客戶端傳送完最後一個確認報文後，在這個 2MSL 時間中，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣新的連線中不會出現舊連線的請求報文。

為什麼建立連線是三次握手，關閉連線確是四次揮手呢？

建立連線的時候，伺服器在 LISTEN 狀態下，收到建立連線請求的 SYN 報文後，把 ACK 和 SYN 放在一個報文裡傳送給客戶端。
而關閉連線時，伺服器收到對方的 FIN 報文時，僅僅表示對方不再發送資料了但是還能接收資料，而自己也未必全部資料都發送給對方了，所以己方可以立即關閉，也可以傳送一些資料給對方後，再發送 FIN 報文給對方來表示同意現在關閉連線，因此，己方 ACK 和 FIN 一般都會分開發送，從而導致多了一次。

如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？

TCP 還設有一個保活計時器，顯然，客戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設定為 2 小時，若兩小時還沒有收到客戶端的任何資料，伺服器就會發送一個探測報文段，以後每隔 75 分鐘傳送一次。若一連發送 10 個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連線。