一 TCP狀態機

CLOSED:初始狀態。

LISTEN:伺服器端的某個SOCKET處於監聽狀態，可以接受連線了。

SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三次握手會話過程中的一箇中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連線時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN報文。

ESTABLISHED：表示連線已經建立了。

FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。

FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。

TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。

CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時傳送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。

CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。

LAST_ACK: 它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了

狀態過程詳解：

伺服器端首先執行LISTEN 原語進入被動開啟狀態（ LISTEN ），等待客戶端連線；

當客戶端的一個應用程式發出CONNECT 命令後，本地的 TCP 實體為其建立一個連線記錄並標記為 SYN SENT 狀態，然後給伺服器傳送一個 SYN 報文段；

伺服器收到一個 SYN 報文段，其 TCP 實體給客戶端傳送確認 ACK 報文段同時傳送一個 SYN 訊號，進入 SYN RCVD 狀態；

客戶端收到 SYN +ACK 報文段，其 TCP 實體給伺服器端傳送出三次握手的最後一個 ACK 報文段，並轉換為 ESTABLISHED 狀態；

伺服器端收到確認的 ACK 報文段，完成了三次握手，於是也進入 ESTABLISHED 狀態。在此狀態下，雙方可以自由傳輸資料。

當一個應用程式完成資料傳輸任務後，它需要關閉 TCP 連線。假設仍由客戶端發起主動關閉連線。 

客戶端執行 CLOSE ，本地的 TCP 實體傳送一個 FIN 報文段並等待響應的確認（進入狀態 FIN WAIT 1 ）；

伺服器收到一個 FIN 報文段，它確認客戶端的請求發回一個 ACK 報文段，進入 CLOSE WAIT 狀態；

客戶端收到確認 ACK 報文段，就轉移到 FIN WAIT 2 狀態，此時連線在一個方向上就斷開了；

伺服器端應用得到通告後，也執行 CLOSE 原語關閉另一個方向的連線，其本地 TCP 實體向客戶端傳送一個 FIN 報文段，並進入 LAST ACK 狀態，等待最後一個 ACK 確認報文段；

客戶端收到 FIN 報文段並確認，進入 TIMED WAIT 狀態，此時雙方連線均已經斷開，但 TCP 要等待一個 2 倍報文段最大生存時間 MSL （Maximum Segment Lifetime ），確保該連線的所有分組全部消失，以防止出現確認丟失的情況。當定時器超時後， TCP 刪除該連線記錄，返回到初始狀態（ CLOSED ）。

伺服器收到最後一個確認ACK 報文段，其 TCP 實體便釋放該連線，並刪除連線記錄，返回到初始狀態（ CLOSED ）。

二 TCP建立連線的三次握手和釋放連線的四次揮手

建立連線三次握手

1）  主機A傳送一個SYN段到主機B告訴B想要連線的主機埠，以及初始的序列號（ISN：x）(報文段1)

2） 主機B應答，伺服器發回包含B的初始序號的SYN報文段(報文段2)作為應答。同時，將確認序號ACK設定為客戶的ISN加1以對A的SYN報文段進行確認。

3) 主機A必須將確認序號ACK設定為B的ISN加1以對B的SYN報文段進行確認(報文段3)

四次揮手斷開連線

1）現在的網路通訊都是基於socket實現的，當客戶端將自己的socket進行關閉時，核心協議棧會向伺服器自動傳送一個FIN置位的包，請求斷開連線。

2）伺服器端B收到請客端的FIN斷開請求後，核心協議棧會立即傳送一個ACK包作為應答，表示已經收到客戶端的請求

3）伺服器執行一段時間後，關閉了自己的socket。這個時候核心協議棧會向客戶端A傳送一個FIN置位的包，請求斷開連線

4）客戶端A收到服務端B發來的FIN斷開請求後，會發送一個ACK做出應答，表示已經收到服務端的請求

為什麼建立連線協議是三次握手，而關閉連線卻是四次握手呢？

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發送。但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。

三 TCP資料封裝與解封

解封時，在主機B上，驅動程式從乙太網上接收到資料，然後將資料去除頭部和尾部並行CRC校驗後，將正確的資料傳遞給IP層，IP層剝去IP頭，進行校驗，將資料傳送給TCP層。TCP層將TCP的頭部剝去，根據應用程式的識別符號判斷是否傳送給應用程式

UDP資料封裝與解封與TCP類似