TCP協(xié)議是TCP/IP體系中核心一個協(xié)議，該協(xié)議比起IP協(xié)議，ICMP協(xié)議，UDP協(xié)議都更復雜，因此這篇文章主要分析TCP協(xié)議在建立連接和斷開連接的時候，狀態(tài)轉(zhuǎn)移以及報文段的內(nèi)容。
下面，先放一張TCP的狀態(tài)轉(zhuǎn)移圖：

平面設計培訓,網(wǎng)頁設計培訓,美工培訓,游戲開發(fā),動畫培訓

TCP協(xié)議之三次握手

三次握手的過程是TCP在客戶端和服務端建立連接的過程。簡單的來說三次握手過程，就是客戶端先發(fā)送一個連接請求給服務端，這是第一次握手。服務端接收到客戶端發(fā)來的鏈接請求，然后在將確認的消息發(fā)給客戶端，這是第二次握手。客戶端對服務端發(fā)來的確認消息進行確認，然后將確認的消息發(fā)給服務端，這就是三次握手。三次握手之后，鏈接建立。
為什么一定是三次握手才能建立一個可靠地鏈接？如果不是三次握手，那么在客戶端發(fā)送了鏈接請求之后，服務端對這個請求進行確認，就認定這次的鏈接已經(jīng)成功建立，俗稱的二次握手。這樣的方式的弊端在哪里？
考慮這么一種情況，當客戶端進行第一次握手時，發(fā)送了一個報文段，但是這個報文段因為網(wǎng)絡的問題，遲遲沒有到，這時，客戶端又會再一次發(fā)送一個連接請求的報文段給服務端，這次成功接收，兩者建立連接，并通信結(jié)束，關閉連接。這之后，因為網(wǎng)絡延遲的那個報文段傳到了服務端那里，服務端又以為客戶端要建立新的連接，于是就同意了，向客戶端發(fā)送確認。因為是二次握手，所以服務端后續(xù)要做的事情，就是等待客戶端發(fā)送的消息，但是客戶端是不會理會服務端傳來的確認，所以服務端就會一直在等待客戶端的數(shù)據(jù)，白白浪費了資源。

抓包分析TCP三次握手的報文段

現(xiàn)在，詳細說一下三次握手具體是做了什么。
第一次握手，客戶端發(fā)送一個報文段給服務端，該報文段中標志有SYN標志，該標志表示建立連接，以及一個初始的序列號。
第二次握手時，服務端發(fā)送一個報文段給客戶端，該報文段中標志有SYN標志，和ACK標志。ACK標志的值是客戶端發(fā)來的初始序號值+ 1，表示對客戶端進行確認，報文段中還有服務端自己的初始序號。
第三次握手時，客戶端發(fā)送一個報文段給服務端，該報文段中標志只有ACK標志，該ACK值是服務端的初始序列化的值 + 1，表示對服務端進行確認，以及還有一個序號值，該序號值為客戶端第一次握手時的序號值 + 1。
三次握手建立連接結(jié)束。
平面設計培訓,網(wǎng)頁設計培訓,美工培訓,游戲開發(fā),動畫培訓
圖片上共有三行，每一行代表一次握手。我們先看第一行
平面設計培訓,網(wǎng)頁設計培訓,美工培訓,游戲開發(fā),動畫培訓
可以看出，第一次握手時55732端口的程序主動發(fā)送一個建立鏈接的報文段給8888端口。這個55732端