抓不住三次握手的過程？那跟我一塊來抓個包吧！
前段時間在忙一個機器人通信的項目，其中用到一個重要的協議族就是TCP/IP (Transmission Control Protocol/Internet Protocol，傳輸控制協議/國際互聯協議），我一直覺得TCP/IP協議設計的真的是太巧妙了，可以說是這個星球上最偉大的通信協議，小到微信的即時通訊，大到航空航天等自動控制工業領域，它的身影無處不在，正是有了TCP/IP，我們發送的每一條互聯網信息才能安全無損地到達對方（比如你有沒有想過你身在北京，打開微信給身在上海的朋友發個祝福短語這期間你的信息究竟經歷了什么，為什么能準確無誤地到達），一個TCP/IP協議，半部計算機網絡史，所以我覺得每一位計算機從業者或者計算機相關從業者都應該花點時間研究一下TCP/IP協議。
大道至簡，今天我們使用一個抓包工具Wireshark來抓個數據包，然后對其抽絲剝繭，逐步來揭開TCP/IP的神秘面紗吧！
1997年12月，美國總統布什為TCP/IP之父羅伯特·卡恩（中間）頒發的美國國家技術勛章。
因特網起因于美蘇爭霸期間美國國防部準備研究的一種分散的指揮系統，由無數節點構成，當若干節點被摧毀后，仍然能夠通過其他節點互相通信。它是一種拓撲結構，你從北京發送的信息到上海可以走多種路徑，TCP/IP的神奇之處就在于它能夠讓你的信息準確無誤地到達。
何為「協議」(protocol)？「協」的本意是指多人合作，而后面的那個「議」在古漢語中的意思是一種文體，那么合起來就是多人合作共同遵守的一種文體，后來引申為雙方共同約定遵守的一種規則。生活中的協議有很多，比如你剛畢業的時候簽訂的三方協議，還有租房的時候有租賃協議，再說遠一點，秦始皇統一中國后為了方便全國的交流，制定了「車同軌，書同文」的規則，這應該是中國歷史上最早的國家標準了吧，這也是一種協議，還有，你看諜戰片，雙方傳遞信息的時候都有口號，這都是事先約定好的，都是一種協議，雙方必須遵守。
有了協議，就大大方便了我們的交流，比如我們在打電話的時候一般都會說聲“喂，你好”，等對方確認應答后才說明雙方確實都通了，然后開始正式通話，而對于TCP來說也是這樣的，TCP在建立連接的過程中要進行三次握手，雙方完全確認無誤后才會互相通信：
三次握手示意圖
帶著這張圖片的信息，讓我們展開抓包之旅吧！
抓包前的準備工作
第一步，首先我們下載一個抓包軟件Wireshark，這個軟件百度一下，網上很多，直接下載即可；
第二步，然后我們在自己的電腦上ping一下百度的域名：www.baidu.com，這樣就能知道百度服務器的IP地址，當然百度在全國肯定不止一臺服務器，所以每個人ping出的地址可能不一樣，比如我ping出的是180.101.49.12 。
第三步，我們打開抓包軟件，在選項里面選擇你的網絡接口，然后點擊開始，Wireshark就開始幫你抓包了；
第四步，我們打開瀏覽器，輸入剛才ping到的百度服務器的IP地址，輸入地址欄按回車，這樣就打開百度首頁了，其實我們平常輸入的網址也是經過DNS服務器解析后轉化成IP進行訪問的。沒錯，我們就是通過訪問一個百度網址來抓取在鍵入回車后雙方的報文信息的。
第五步，我們在抓包軟件搜索框內輸入 ip.addr == 180.101.49.12 and tcp 指令來幫助我們過濾掉多余的信息：
好了，可見我們抓取了很多條信息，但是我們只需要前三條即可，因為前三條就是雙方建立連接（三次握手）過程中互相傳遞的報文信息。
在分析這三條報文前，我們回憶一下TCP/IP每層網絡模型中的報文結構：
每層模型對自己的數據加包頭后發給下一層：
這是微信發送消息的模型（所有TCP/IP協議都是這樣），當然微信肯定不是端對端直接傳送到另一個手機，而是先傳送到騰訊服務器，再轉推給對方，不過原理是一樣的。
可見每層都是膠囊化的數據，經過加工后(一般都是加上報頭)然后傳送給下一層，最終由物理層的傳送介質（比如光纖）傳送給對方電腦，對方收到后再反過來解析，剝開每一層的報頭，最終露出數據部分，這才是我們真實要的數據。所以，我們抓到的包都是在最下面的以太網幀，包含幀頭、幀尾、IP頭部、TCP頭部的數據包，所以我們必須先從最后一層分析。
數據鏈路層
在數據鏈路層我們收到的以太網幀頭部結構如下（下面這張圖片為了描述方便，寬度我與位長度我沒有按照比例來畫）：
簡要解釋一下幾個字段的含義：
- 前導同步碼
提醒接收系統即將有幀到來，七次寫入 10101010 ;
- 幀開始分界符
表示幀的發送從下一個數據報正式開始，二進制數序列為 10101011 ;
- 幀的長度 / 類型
內容為幀長度（單位為字節）或者交給上層協議的信息。具體是哪種內容，取決于以太網的種類。
我們先來看第一次握手的數據
第一個紅框 b0 95 8e 0b 15 38 代表目標MAC地址，也就是百度服務器的網卡地址；
第二個紅框 10 63 c8 ff ff ff 代表源MAC地址，也就是我自己電腦的網卡地址，后三個字節 ff ff ff 是我虛擬的，包括上面圖片中我也打了馬賽克，為什么，因我怕黑客知道我的網卡地址后攻擊我的電腦；
第三個紅框 08 00 代表的是 IPv4 協議。
等等，你可能會問，幀頭的前導同步碼與幀開始分界符怎么沒有顯示呢？
這是因為在物理層上網卡要先去掉前導同步碼和幀開始定界符，然后對幀進行CRC檢驗，如果幀校驗和錯，就丟棄此幀。如果校驗和正確，就判斷幀的目的硬件地址是否符合自己的接收條件（目的地址是自己的物理硬件地址、廣播地址、可接收的多播硬件地址等），如果符合，就將幀交“設備驅動程序”做進一步處理。這時我們的抓包軟件才能抓到數據，因此，抓包軟件抓到的是去掉前導同步碼、幀開始分界符、FCS之外的數據。
網絡層
我們先來看網絡層，也就是 IP 層的頭部結構：
先來大致解釋一下每個字段的含義：
- 版本（version）
如果是 IPv4 則填入 4 ，如果是 IPv6（當然報頭結構跟 IPv4 結構不一樣）則填入6。
- 頭長度（Header Length）
IP 報頭的大小 ,頭部長度是指IP報頭的總長度，因為有Option可選部分，通常為20字節，范圍在20--60字節，注意，該字段單位為32位字(1個32位字為4字節)，因此當ip報頭長度為1111(15)時是最大60(15*4)字節，一定要注意，這個字段的單位比較特殊，容易弄錯。
- 服務類型（Differentiated Services Field）
顯示發送信息時的優先情況。
- 數據包總長度（Total Length）
IP 報頭與數據的整體大小，表示此IP報頭和數據的之和的總長度。總長度16位，一個數據最大長度65535字節；鏈路只允許1500字節，超過的話需要進行MTU分片。一個數據包由IP報頭和數據兩部分組成，而IP報頭為20---60字節，所以不會有一個數據包里純數據超過1480字節。
- 標識符（Identification）
將分割后的 IP 數據包復原時使用的值，與標記字段和偏移字段用于IP報文分片。原始報文大小超過MTU（<1480B）就必須將原始數據進行分片，每個分片小于MTU，對同一原始文件被分片的報文打上相同的標記，也用來判斷流量是否來于同一主機。IP軟件在存儲器中維持一個計數器沒生產一個數據包，計數器就加1，并賦予標識字段。數據報文進行分片處理后每個分片的標識值都與原數據包的標識值相同，接收端具有同標識值的分片就能最終正確重組為原數據。
- 旗標（Flags）
關于數據包分割的信息：
第一位沒有被使用；
第二位不分片（DF），當DF位置為1時表示路由器不能對報文進行分片處理；第三位多分片（MF），當路由器對報文進行分片時，除了最后一個分片的MF位設置為0外，其他所有分片MF位置為1，以便接收者直到收到MF位為0的分片為止。
例如，如果數據包被分成兩段，那么第一個flags就是101，第二個flags就是100.
- 分片偏移（Fragmentation offset）
被分割的數據的順序，標識分片在分組中的位置。
- 生存時間（Time to live, TTL）
允許經過最大的路由器數量，即數據包能傳多少跳。不同操作系統TTL的默認最大值會有所不同，目的是防止路由成環時IP數據被無限轉發，每經過一個路由器TTL值減1，TTL為0時丟棄該分組。
- 協議（Protocol）
上一級協議，標識數據攜帶的數據是何種協議，標識傳輸層地址或協議號，如1代表ICMP，6代表TCP，17代表UDP.
- 包頭校驗和（Header checksum）
確認 IP 包頭是否損壞的數值，用于校驗檢查IP報頭是否有出入。
- 選項（Option）
可選字段（0--40B）Option字段很少使用，用于控制，轉發要求，測試等。
網絡層的信息比較多，我們只撿幾個重要的信息來說一下：
第二行的 c0 a8 00 65 轉化成十進制就是 192.168.0.101 這是我電腦的 IP ,注意這里是局域網 IP , 后面的 b4 65 31 0c 轉化成十進制就是180.101.49.12，是目標 IP ,也就是百度服務器的 IP。
傳輸層
傳輸層的功能是保證數據可靠地從發送結點發送到目標結點，我們看一下它的頭部結構，已經能夠看到攜帶的握手信息了。
- 序列號（Sequence Number）
表示在所有的數據中，此數據是第幾個
- 確認應答號（Acknowledgment Number）
表示即將接收的下一個數據是第幾個
我們再看抓到的包數據，再剝一層，把 IP 頭去掉，先看第一次握手：
我們可以看到：第一次握手的過程中，客戶端隨機生成了一個序列號，數值挺大的，然后將狀態控制碼中的 SYN 置為1，發送給服務端。
第二次握手：
在服務端收到客戶端的報文后，服務端再給客戶端一個應答，由于是服務端給客戶端打招呼，因此端口號互換一下，這邊服務端也隨機生成一個序列號，同時將第一次握手收到客戶端的序列號加1，作為確認序列號發送過去，同時將狀態控制碼的ACK與SYN置為1，發送給客戶端。
第三次握手：
第三次握手是客戶端在收到服務端的回應后，客戶端再一次回應。可以看到，序列號就是第二次握手服務端發來的確認應答序列號，而第三次握手客戶端的確認序列號就是第二次握手服務端發來的確認序列號加1。
這樣，三次握手就完成，雙方建立連接，可以互相通信了。
好了，以上就是今天的全部內容了，其實三次握手只是TCP里面的冰山一角，真正傳輸過程中還涉及到非常多的知識，比如超時重傳、校驗、窗口機制等等，不過今天先說到這里吧，基礎薄弱的同學可以先消化一下，后面的知識等有時間再給大家說。
