抓包分析TCP的三次握手和四次握手
問題描述:
在上一篇《如何對Android裝置進行抓包》中提到了,伺服器的開發人員需要我bug重現然後提供抓包給他們分析,所以抓好包自己也試著分析了一下。發現裡面全是一些TCP協議和HTTP協議。所以要想進行抓包分析,必須先了解TCP的原理。這裡介紹了TCP的建立連線的三次握手和斷開連線的四次握手。
問題分析:
1、TCP建立連線的三次握手
1、1前言:介紹三次握手之前,先介紹TCP層的幾個FLAGS欄位,這個欄位有如下的幾種標示
SYN表示建立連線,
FIN表示關閉連線,
ACK表示響應,
PSH表示有 DATA資料傳輸,
RST表示連線重置。
1、2 三次握手的步驟
第一次握手:主機A傳送位碼為syn=1,隨機產生seq number=1234567的資料包到伺服器,主機B由SYN=1知道,A要求建立聯機;
第二次握手:主機B收到請求後要確認聯機資訊,向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包;
第三次握手:主機A收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,主機A會再發送ack number=(主機B的seq+1),ack=1,主機B收到後確認seq值與ack=1則連線建立成功。
完成三次握手,主機A與主機B開始傳送資料。
2、tcp斷開連線的四次握手
tcp斷開連線有兩種方式,第一種是正常的四次握手斷開的,第二種是RST異常斷開的
2、1 正常斷開的四次握手:
下圖來自網路
假設Client端發起中斷連線請求,也就是傳送FIN報文。Server端接到FIN報文後,意思是說"我Client端沒有資料要發給你了",但是如果你還有資料沒有傳送完成,則不必急著關閉Socket,可以繼續傳送資料。所以你先發送ACK,"告訴Client端,你的請求我收到了,但是我還沒準備好,請繼續你等我的訊息"。這個時候Client端就進入FIN_WAIT狀態,繼續等待Server端的FIN報文。當Server端確定資料已傳送完成,則向Client端傳送FIN報文,"告訴Client端,好了,我這邊資料發完了,準備好關閉連線了
2、2 用抓包來看斷開連線的四次握手
下圖中的四個箭頭就是標準的四次握手了。
首先伺服器80埠想41826埠發出FIN的斷開連線請求
然後第二個箭頭41826收到請求之後想伺服器80埠回覆了一個ACK
接著第三個箭頭41826向伺服器80埠傳送斷開請求FIN
最後第四個箭頭,伺服器80向客戶端傳送斷開的回覆ACK
這樣四次握手之後,伺服器和客戶端都確認了斷開連線,可以看到斷開連線是雙向的。
2、3 RST異常關閉連線
有時候也會出現異常斷開連線的情況,也就是RST,比如說下圖,伺服器80向客戶端32875傳送斷開請求FIN,客戶端也通過這條鏈路回覆了ACK,但是此時還有資料需要傳送,所以沒有急著回覆FIN,而是先將get請求傳送出去,傳送了get請求之後再發送的斷開請求FIN,但是此時伺服器不知道什麼原因在沒有確認客戶端的確認前就斷開了,所以在接到get請求之後,返回了一個RST,異常斷開了這條鏈路。
結論:
TCP的三次握手和四次握手平時看書本看起來很生澀難懂,但是通過一次http的抓包分析之後,對於tcp的七次握手有了新的瞭解和認識。
這些理論知識我還是瞭解的不夠深入,只是學以致用,用來分析網路抓包。不過要想做好網路應用,還是很有必要對tcp,http做深入一點的瞭解