抓包分析TCP的三次握手和四次握手

問題描寫敘述：

       在上一篇《怎樣對Android設備進行抓包》中提到了，server的開發者需要我bug重現而後提供抓包給他們分析。因此抓好包本身也試着分析了一下。發現裏面全是一些TCP協議和HTTP協議。因此要想進行抓包分析，必須先了解TCP的原理。這裏介紹了TCP的創建鏈接的三次握手和斷開鏈接的四次握手。

問題分析：

一、TCP創建鏈接的三次握手

一、1前言：介紹三次握手以前，先介紹TCP層的幾個FLAGS字段，這個字段有例如如下的幾種標示

SYN表示創建鏈接，

FIN表示關閉鏈接。

ACK表示響應，

PSH表示有 DATA傳輸數據，

RST表示鏈接重置。

一、2 三次握手的步驟

第一次握手：主機A發送位碼爲syn＝1，隨機產生seq number=1234567的數據包到server，主機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開始傳送數據。

從抓包分析中可以很是清晰的看到TCP三次握手。下圖就是完整的三次握手。client41826port和server的80port創建了鏈接

二、tcp斷開鏈接的四次握手

tcp斷開鏈接有兩種方式，第一種是正常的四次握手斷開的，另一種是RST異常斷開的

二、1 正常斷開的四次握手：

下圖來自網絡

假設Client端發起中斷鏈接請求，也就是發送FIN報文。

Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"。但是假設你還有數據沒有發送完畢。則沒必要急着關閉Socket，可以繼續發送數據。因此你先發送ACK。"告訴Client端，你的請求我收到了，但是我還沒準備好。請繼續你等個人消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端肯定數據已發送完畢，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉鏈接了"。Client端收到FIN報文後，"就知道可以關閉鏈接了。但是他仍是不相信網絡。怕Server端不知道要關閉。因此發送ACK後進入TIME_WAIT狀態。假設Server端沒有收到ACK則可以重傳。

「。Server端收到ACK後，"就知道可以斷開鏈接了"。Client端等待了2MSL後依舊沒有收到回覆。則證實Server端已正常關閉，那好。我Client端也可以關閉鏈接了。

Ok，TCP鏈接就這樣關閉了！

二、2 用抓包來看斷開鏈接的四次握手

下圖中的四個箭頭就是標準的四次握手了。

首先server80port想41826port發出FIN的斷開鏈接請求

而後第二個箭頭41826收到請求以後想server80port回覆了一個ACK

接着第三個箭頭41826向server80port發送斷開請求FIN

最後第四個箭頭，server80向client發送斷開的回覆ACK

這樣四次握手以後，server和client都確認了斷開鏈接，可以看到斷開鏈接是雙向的。

二、3 RST異常關閉鏈接

有時候也會出現異常斷開鏈接的狀況，也就是RST。比方說下圖，server80向client32875發送斷開請求FIN，client也經過這條鏈路回覆了ACK，但是此時還有數據需要發送。因此沒有急着回覆FIN，而是先將get請求發送出去，發送了get請求以後再發送的斷開請求FIN。但是此時server不知道什麼緣由在沒有確認client的確認前就斷開了，因此在接到get請求以後，返回了一個RST，異常斷開了這條鏈路。

結論：

TCP的三次握手和四次握手平時看書本看起來很是生澀難懂，但是經過一次http的抓包分析以後，對於tcp的七次握手有了新的瞭解和認識。

這些理論知識我仍是瞭解的不夠深刻，僅僅是學以至用，用來分析網絡抓包。只是要想作好網絡應用，仍是很是有必要對tcp，http作深刻一點的瞭解