想要弄清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次揮手足夠切斷連結，爲節約各種資源，能三次的服務都三次了
等我找着工作了，再來抓你，四次揮手！！！
