本節書摘來自異步社群《wireshark網絡分析的藝術》一書中的三次握手的小知識，作者林沛滿,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
三次握手的小知識
wireshark網絡分析的藝術
我原本以為tcp三次握手不值得寫，沒想到在某技術社群上被提問好幾次了。看來感興趣的人還真不少，還是寫一篇吧。
我們知道tcp需要通過三次握手來建立連接配接，過程如圖1所示。
從wireshark上看到的握手過程就是圖2這樣的，你可以把seq号和ack号代入圖1中，看看是否符合規律。
當x和y的值太大時，看起來就不太友好，尤其是需要對這些号碼做加減運算時。于是wireshark提供了一個功能——把seq和ack的初始值都置成0，即用“相對值”來代替“真實值”。我們可以在edit→preferences→protocols→tcp菜單中勾上relative sequence numbers來啟用它。啟用之後，圖2的包就變成圖3這樣，是不是清爽了很多？
成功的握手都是一樣的，失敗的握手卻各有不同，是以解決起來還是需要一些技巧的。當我們遭遇tcp連接配接建立失敗時，最穩當的排查方式就是用wireshark來分析。網絡包不多的時候很容易入手，用肉眼觀察就行，但如果抓到的包特别大就需要過濾技巧了。根據我的經驗，握手失敗一般分兩種類型，要麼被拒絕，要麼是丢包了。是以用兩道過濾表達式就可以定位出大多數失敗的握手。
表達式1：(tcp.flags.reset == 1) && (tcp.seq == 1)
從表面上看，它隻是過濾出seq号為1，且含有reset标志的包，似乎與握手無關。但在啟用relative sequence numbers的情況下，這往往表示握手請求被對方拒絕了，結果如圖4所示。接下來隻需右鍵選中過濾出的包，再點選follow tcp stream就可以把失敗的全過程顯示出來，見圖5。此次握手失敗的原因是伺服器沒有在監聽80端口，是以拒絕了用戶端的握手請求。
表達式2：(tcp.flags.syn == 1) && (tcp.analysis.retransmission)
這道表達式可以過濾出重傳的握手請求。一個握手請求之是以要重傳，往往是因為對方沒收到，或者對方回複的确認包丢失了。這個重傳特征正好用來過濾，結果如圖6所示。接下來右鍵點選過濾出的包，再用follow tcp stream就可以把失敗過程顯示出來，見圖7。此次握手失敗的原因是丢包，是以伺服器收不到握手請求。
這兩個表達式很好用，不過要最快排查出根本原因還需要另一個技巧，即在兩端同時抓包來分析。為什麼要兩端同時抓呢？請考慮圖8所示的兩種狀況。
同樣是握手失敗，左圖是用戶端發出的包丢了，右圖則是伺服器回複的包丢了。不同的丢包往往意味着不同的問題根源，解決方式也不一樣。如果隻在用戶端抓包，那這兩種丢包的症狀看起來就像是一樣的，排查起來也會慢一些。
說完握手失敗的排查技巧，我們再來講講和握手有關的安全問題。做運維的工程師們都知道，大規模ddos（distributed denial of service，分布式拒絕服務攻擊）來臨的時候最驚心動魄。ddos的形式有很多種，其中最流行的就是基于三次握手的syn flood，其原理是從大量主機發送syn請求給伺服器，假裝要建立tcp連接配接。這些syn請求可能含有假的源位址，是以伺服器響應後永遠收不到ack，就會留下half-open狀态的tcp連接配接。由于每個tcp連接配接都會消耗一定的系統資源，如果攻擊足夠猛烈，此類連接配接越建越多，伺服器的資源就會被耗光，真正的使用者通路也會被拒絕。
wireshark可以輕易地發現syn flood。有時一打開包就很顯眼了，如圖9所示，密密麻麻都是syn。假如幹擾包太多，那就點選analyzeexpert infochats菜單，可以看到syn的總數量統計。
我們可以把syn flood看作tcp協定的設計缺陷，有辦法可以防禦，卻無法根除。想知道大公司都是怎樣防禦的嗎？手段有很多，其中有一些還可以在wireshark中看出端倪。我假裝攻擊了全球最大的假藥銷售網站，然後把全過程的包抓下來。從圖10可見，對方很快就識别了我的不良意圖，是以reset（rst）了大多數握手請求。如果有興趣去研究rst包裡的細節，比如網絡層的ttl和identification，也許還能判斷出究竟是流量清洗還是tcp握手代理之類的。本書不是網絡安全專著，是以就不展開分析了。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。