摘要：在兩次握手的情況下，「被動發起方」沒有中間狀態給「主動發起方」來阻止歷史連線，導致「被動發起方」可能建立一個歷史連線，造成資源浪費。
本文分享自華為雲社群《TCP 兩次握手為什麼無法阻止歷史連線？》，作者：小林coding 。
兩次握手的情況下，「被動發起方」在收到 SYN 報文後，就進入 ESTABLISHED 狀態，意味著這時可以給對方傳送資料給，但是「主動發」起方此時還沒有進入 ESTABLISHED 狀態，假設這次是歷史連線，主動發起方判斷到此次連線為歷史連線，那麼就會回 RST 報文來斷開連線，而「被動發起方」在第一次握手的時候就進入 ESTABLISHED 狀態，所以它可以傳送資料的，但是它並不知道這個是歷史連線，它只有在收到 RST 報文後，才會斷開連線。
可以看到，上面這種場景下，「被動發起方」在向「主動發起方」傳送資料前，並沒有阻止掉歷史連線，導致「被動發起方」建立了一個歷史連線，又白白髮送了資料，妥妥地浪費了「被動發起方」的資源。
因此，要解決這種現象，最好就是在「被動發起方」傳送資料前，也就是建立連線之前，要阻止掉歷史連線，這樣就不會造成資源浪費，而要實現這個功能，就需要三次握手。
三次握手阻止歷史連線的過程如下圖，注意圖中的兩個連線的序列號是不一樣的，因此新舊 SYN 報文並不是發生了超時重傳，兩個都是獨立的連線。
客戶端連續傳送多次 SYN 建立連線的報文，在網路擁堵情況下:
- 一個「舊 SYN 報文」比「最新的 SYN 」 報文早到達了服務端;
- 那麼此時服務端就會回一個 SYN + ACK 報文給客戶端;
- 客戶端收到後可以根據自身的上下文，判斷這是一個歷史連線（序列號過期），那麼客戶端就會傳送 RST 報文給服務端，表示中止這一次連線。
可以看到，在三次握手的情況下， 可以在服務端建立連線之前，可以阻止掉了歷史連線，從而保證建立的連線不是歷史連線。