tcp三次握手three-way handshake
乙個虛擬連線的建立是通過三次握手來實現的
1. (b) --> [syn] --> (a)
假如伺服器a和客戶機b通訊. 當a要和b通訊時，b首先向a發乙個syn (synchronize) 標記的包，告訴a請求建立連線.
注意: 乙個 syn包就是僅syn標記設為1的tcp包(參見tcp包頭resources). 認識到這點很重要，只有當a受到b發來的syn包，才可建立連線，除此之外別無他法。因此，如果你的防火牆丟棄所有的發往外網介面的syn包，那麼你將不 能讓外部任何主機主動建立連線。
在wireshark抓包分析中，seq表示資料段的序號，乙個seq號的大小是根據上乙個資料段的seq號和長度len相加而來的。根據seq序號和len，可以判斷哪些包丟失。
2. (b) <-- [syn/ack] <--(a)
接著，a收到後會發乙個對syn包的確認包(syn/ack)回去，表示對第乙個syn包的確認，並繼續握手操作.
注意: syn/ack包是僅syn 和 ack 標記為1的包.
3. (b) --> [ack] --> (a)
b收到syn/ack 包,b發乙個確認包(ack)，通知a連線已建立。至此，三次握手完成，乙個tcp連線完成
note: ack包就是僅ack 標記設為1的tcp包. 需要注意的是當三此握手完成、連線建立以後，tcp連線的每個包都會設定ack位
這就是為何連線跟蹤很重要的原因了. 沒有連線跟蹤,防火牆將無法判斷收到的ack包是否屬於乙個已經建立的連線.一般的包過濾(ipchains)收到ack包時,會讓它通過(這絕對不是個 好主意). 而當狀態型防火牆收到此種包時，它會先在連線表中查詢是否屬於哪個已建連線，否則丟棄該包
在tcp層，有個flags欄位，這個欄位有以下幾個標識：syn, fin, ack, psh, rst, urg.
其中，對於我們日常的分析有用的就是前面的五個字段。
它們的含義是：
urg:urget pointer is valid (緊急指標字段值有效)
syn: 表示建立連線，攜帶此標誌位的包表示正在發起連線請求
fin: 表示關閉連線，攜帶此標誌位的包表示正在請求終止連線
ack: 表示響應，確認號
psh: 表示有 data資料傳輸
rst: 表示連線重置，或者拒絕乙個無效的請求
其中，ack是可能與syn，fin等同時使用的，比如syn和ack可能同時為1，它表示的就是建立連線之後的響應，如果只是單個的乙個syn，它表示的只是建立連線。tcp的幾次握手就是通過這樣的ack表現出來的。但syn與fin是不會同時為1的，因為前者表示的是建立連線，而後者表示的是斷開連線。rst一般是在fin之後才會出現為1的情況，表示的是連線重置。一般地，當出現fin包或rst包時，我們便認為客戶端與伺服器端斷開了連線；而當出現syn和syn＋ack包時，我們認為客戶端與伺服器建立了乙個連線。psh為1的情況，一般只出現在 data內容不為0的包中，也就是說psh為1表示的是有真正的tcp資料報內容被傳遞。
三次握手（總結）
client --> 置syn標誌 序列號 = j，確認號 = 0 ----> server
client <-- 置syn標誌 置ack標誌 序列號 = k, 確認號 = j + 1 <-- server
clinet --> 置ack標誌 序列號 = j + 1，確認號 = k + 1 --> server
鏈結建立後，接下來client端傳送的資料報將從j + 1開始，server端傳送的資料報將從k + 1開始，這裡要說明的是：建立鏈結時，client端宣稱自己的初始序列號是j，server端宣稱自己的初始序列號是k，但是建立連線後的資料報卻各自中初始序列號+1開始，這是因為syn請求本身需要占用乙個序列號
資料傳輸（總結）
client --> 置psh標誌，置ack標誌 序列號 = 55555, 確認號 = 22222，資料報長度 = 11 ---> server
client <-- 置ack標誌，序列號 = 22222, 確認號 = 55566 (=55555 + 11)，資料報長度 = 0 <--- server
client <-- 置psh標誌，置ack標誌 序列號 = 22223, 確認號 = 55566，資料報長度 = 22 <--- server
client --> 置ack標誌，序列號 = 55566, 確認號 = 22244(=22222+22)，資料報長度 = 0 ---> server
為什麼要三次握，要四次分手
既然總結了tcp的三次握手，那為什麼非要三次呢？怎麼覺得兩次就可以完成了。那tcp為什麼非要進行三次連線呢？在謝希仁的 計算機網路 中是這樣說的 為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。在書中同時舉了乙個例子，如下 已失效的連線請求報文段 的產生在這樣一種情況下 clien...
MPTCP 原始碼分析 一 MPTCP的三次握手
簡述 mptcp依然按照正常的tcp進行三次握手，只是在握手過程中增加了mptcp特有的資訊。建立過程 三次握手過程如下圖所示 左邊客戶端傳送的第乙個syn包攜帶有客戶端自身的key，右邊傳送syn ack的時候攜帶了自身的key，而最後左邊的客戶端傳送最後乙個ack的時候攜帶著雙方的key。mpt...
socket連線伺服器立即返回，不用三次握手
因為預設用socket的connect去連線需要三次握手，時間比較長，所以為了提高效率，有一種方法可以解決 unsigned long imode 1 fd set write,err ioctlsocket sock,fionbio,imode 先將socket設定為非阻塞的，connect so...