想要弄清TCP三次握手,四次揮手的過程,最好的辦法當然是抓包啦~
QQ作爲人均必備軟件是很好的對象~
值得注意的是,我們的QQ聊天並不是TCP建立點對點連接的,想想好友列表裏的在線好友,一人一個TCP端口號,網卡該冒煙了。。。因此從網絡資源考慮,想要實現多人在線“交友”(>.<),只能使用UDP多對多,同時應用層保證可靠傳輸!!
下面正式開始實驗,首先是三次握手,思路步走:
步驟 | 任務 |
---|---|
1 | 打開QQ應用程序(當然不能是自動登陸的啦),還有我們的抓包工具Wireshark |
2 | 輸入QQ密碼,準備發車~ |
3 | 選擇當前使用的網絡(一般是有線以太網或WiFi),點擊Wireshark開始抓包按鈕後立刻點擊QQ登錄… |
4 | 登錄成功後立刻推退出(就是這麼腦殘(<.<)) |
5 | 點擊Wireshark停止抓包,驗貨,終止交(jian)易(ting) |
就這麼簡單,附圖如下:
這麼多包,哪個纔是QQTCP建立和斷開呢?我們可以使用過濾器噠,輸入"tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.port == 80",懂我意思吧(<.<)
點擊右邊的回車鍵,我不做人啦!JOJO!
可以看到QQ在登陸時貌似一口氣開了三個線程,用了三個端口,建了三個連接
但我們主要關注一個吧,就那個14942的那個,你放學別走!“tcp.port ==14942”
確認過眼神,讓我康康!
三次握手
1.連接請求:
客戶端
相對序列號=0,跟蹤正常
相對確認序列號=0,跟蹤正常
SYN=1,ACK=0,向服務端連接請求正常
窗口大小,隨意…
最大報文段長度MMS=1460,跟蹤正常
窗口擴大因子,隨意…
2.連接請求應答:
服務端
相對序列號=0,跟蹤正常
相對確認序列號=1,跟蹤正常
SYN=1,向客戶端請求連接正常
ACK=1,向服務端請求連接應答正常
窗口大小,隨意…
最大報文段長度MMS=1460,跟蹤正常
窗口擴大因子,隨意…
3.第三次握手
服務端
相對序列號=1,跟蹤正常
相對確認序列號=1,跟蹤正常
ACK=1,向客戶端請求連接應答正常
窗口大小,隨意…
沒有選項…正常?
窗口擴大因子,隨意…
四次揮手
你看這個包包,超遜的啦!
1.客戶端斷開請求FIN
相對序列號=810,FIN一個包,跟蹤正常
相對確認序列號=408,跟蹤正常
ACK=1,確認服務端最後傳來的包
FIN=1,向服務端請求斷開
2.客戶端斷開請求確認FIN_ACK + 服務器斷開請求 FIN
相對序列號=408,FIN一個包,跟蹤正常
相對確認序列號=810,不再請求新包?
ACK=1,客戶端斷開請求確認
FIN=1,服務器端斷開請求
3服務端斷開請求確認 FIN_ACK
相對序列號=811?跟蹤正常?
相對確認序列號=409?跟蹤正常?
ACK=1,服務端斷開請求確認
FIN=0,成功斷開
4.???
相對序列號=409?
相對確認序列號=811?
ACK=1,FIN=0?
這TM就很尷尬了,和我看到過的四次揮手不一樣啊。。。
在@cbdog94的幫助下,瞭解到,原來還有三次揮手這玩意
雖然和今天提取的4個包揮手原理依舊不一樣,但這說明還有其他揮手的可能性~
所以是不是覺得被標題騙了呢?
沒事,我們換一個應用,http總可以吧!!!
目標大B站!!!
過程你們也不會看的,我直接放結果了
標準的三次揮手
至於四次揮手嘛,我真的找不到呀…
個人感覺,對客戶而言,通過FIN斷開請求表達了明確的斷開意願後,服務器端馬上就可以做出切斷傳輸的決定,停止文件傳輸,因此3次揮手足夠切斷連結,爲節約各種資源,能三次的服務都三次了
等我找着工作了,再來抓你,四次揮手!!!