TCP-三次握手(轉)

文章大部分描述來自 : https://coolshell.cn/articles/11564.html , 非原創

TCP頭格式

接下來，我們來看一下TCP頭的格式

你需要注意這麼幾點：

• TCP的包是沒有IP地址的，那是IP層上的事。但是有源端口和目標端口。
  一個TCP連接需要四個元組來表示是同一個連接（src_ip, src_port, dst_ip, dst_port）準確說是五元組，還有一個是協議。但因爲這裏只是說TCP協議，所以，這裏我只說四元組。
  注意上圖中的四個非常重要的東西：
• Sequence Number是包的序號，用來解決網絡包亂序（reordering）問題。
• Acknowledgement Number就是ACK——用於確認收到，用來解決不丟包的問題。
  Window又叫Advertised-Window，也就是著名的滑動窗口（Sliding Window），用於解決流控的。
• TCP Flag ，也就是包的類型，主要是用於操控TCP的狀態機的。
  關於其它的東西，可以參看下面的圖示

TCP的狀態機

其實，網絡上的傳輸是沒有連接的，包括TCP也是一樣的。而TCP所謂的“連接”，其實只不過是在通訊的雙方維護一個“連接狀態”，讓它看上去好像有連接一樣。所以，TCP的狀態變換是非常重要的。

下面是：“TCP協議的狀態機”（圖片來源） 和 “TCP建鏈接”、“TCP斷鏈接”、“傳數據” 的對照圖，我把兩個圖並排放在一起，這樣方便在你對照着看。另外，下面這兩個圖非常非常的重要，你一定要記牢。（吐個槽：看到這樣複雜的狀態機，就知道這個協議有多複雜，複雜的東西總是有很多坑爹的事情，所以TCP協議其實也挺坑爹的）

這有點像我們做訂單系統一樣 ,根據單據的狀態進行流程的處理一樣 .

很多人會問，爲什麼建鏈接要3次握手，斷鏈接需要4次揮手？
對於建鏈接的3次握手，主要是要初始化Sequence Number 的初始值。通信的雙方要互相通知對方自己的初始化的Sequence Number（縮寫爲ISN：Inital Sequence Number）——所以叫SYN，全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。這個號要作爲以後的數據通信的序號，以保證應用層接收到的數據不會因爲網絡上的傳輸的問題而亂序（TCP會用這個序號來拼接數據）。
對於4次揮手，其實你仔細看是2次，因爲TCP是全雙工的，所以，發送方和接收方都需要Fin和Ack。只不過，有一方是被動的，所以看上去就成了所謂的4次揮手。如果兩邊同時斷連接，那就會就進入到CLOSING狀態，然後到達TIME_WAIT狀態。下圖是雙方同時斷連接的示意圖（你同樣可以對照着TCP狀態機看）：

另外，有幾個事情需要注意一下：

• 關於建連接時SYN超時。試想一下，如果server端接到了clien發的SYN後回了SYN-ACK後client掉線了，server端沒有收到client回來的ACK，那麼，這個連接處於一箇中間狀態，即沒成功，也沒失敗。於是，server端如果在一定時間內沒有收到的TCP會重發SYN-ACK。在Linux下，默認重試次數爲5次，重試的間隔時間從1s開始每次都翻售，5次的重試時間間隔爲1s, 2s, 4s, 8s, 16s，總共31s，第5次發出後還要等32s都知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP纔會把斷開這個連接。

• 關於SYN Flood攻擊。一些惡意的人就爲此製造了SYN Flood攻擊——給服務器發了一個SYN後，就下線了，於是服務器需要默認等63s纔會斷開連接，這樣，攻擊者就可以把服務器的syn連接的隊列耗盡，讓正常的連接請求不能處理。於是，Linux下給了一個叫tcp_syncookies的參數來應對這個事——當SYN隊列滿了後，TCP會通過源地址端口、目標地址端口和時間戳打造出一個特別的Sequence Number發回去（又叫cookie），如果是攻擊者則不會有響應，如果是正常連接，則會把這個 SYN Cookie發回來，然後服務端可以通過cookie建連接（即使你不在SYN隊列中）。請注意，請先千萬別用tcp_syncookies來處理正常的大負載的連接的情況。因爲，synccookies是妥協版的TCP協議，並不嚴謹。對於正常的請求，你應該調整三個TCP參數可供你選擇，第一個是：tcp_synack_retries 可以用他來減少重試次數；第二個是：tcp_max_syn_backlog，可以增大SYN連接數；第三個是：tcp_abort_on_overflow 處理不過來乾脆就直接拒絕連接了。

• 關於ISN的初始化。ISN是不能hard code的，不然會出問題的——比如：如果連接建好後始終用1來做ISN，如果client發了30個segment過去，但是網絡斷了，於是 client重連，又用了1做ISN，但是之前連接的那些包到了，於是就被當成了新連接的包，此時，client的Sequence Number 可能是3，而Server端認爲client端的這個號是30了。全亂了。RFC793中說，ISN會和一個假的時鐘綁在一起，這個時鐘會在每4微秒對ISN做加一操作，直到超過2^32，又從0開始。這樣，一個ISN的週期大約是4.55個小時。因爲，我們假設我們的TCP Segment在網絡上的存活時間不會超過Maximum Segment Lifetime（縮寫爲MSL – Wikipedia語條），所以，只要MSL的值小於4.55小時，那麼，我們就不會重用到ISN。

• 關於 MSL 和 TIME_WAIT。通過上面的ISN的描述，相信你也知道MSL是怎麼來的了。我們注意到，在TCP的狀態圖中，從TIME_WAIT狀態到CLOSED狀態，有一個超時設置，這個超時設置是 2*MSL（RFC793定義了MSL爲2分鐘，Linux設置成了30s）爲什麼要這有TIME_WAIT？爲什麼不直接給轉成CLOSED狀態呢？主要有兩個原因：
  1）TIME_WAIT確保有足夠的時間讓對端收到了ACK，如果被動關閉的那方沒有收到Ack，就會觸發被動端重發Fin，一來一去正好2個MSL
  2）有足夠的時間讓這個連接不會跟後面的連接混在一起（你要知道，有些自做主張的路由器會緩存IP數據包，如果連接被重用了，那麼這些延遲收到的包就有可能會跟新連接混在一起）。你可以看看這篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》

• 關於TIME_WAIT數量太多。從上面的描述我們可以知道，TIME_WAIT是個很重要的狀態，但是如果在大併發的短鏈接下，TIME_WAIT 就會太多，這也會消耗很多系統資源。只要搜一下，你就會發現，十有八九的處理方式都是教你設置兩個參數，一個叫tcp_tw_reuse，另一個叫tcp_tw_recycle的參數，這兩個參數默認值都是被關閉的，後者recyle比前者resue更爲激進，resue要溫柔一些。另外，如果使用tcp_tw_reuse，必需設置tcp_timestamps=1，否則無效。這裏，你一定要注意，打開這兩個參數會有比較大的坑——可能會讓TCP連接出一些詭異的問題（因爲如上述一樣，如果不等待超時重用連接的話，新的連接可能會建不上。正如官方文檔上說的一樣“It should not be changed without advice/request of technical experts”）。

• 關於tcp_tw_reuse。官方文檔上說tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保證協議的角度上的安全，但是你需要tcp_timestamps在兩邊都被打開（你可以讀一下tcp_twsk_unique的源碼 ）。我個人估計還是有一些場景會有問題。

• 關於tcp_tw_recycle。如果是tcp_tw_recycle被打開了話，會假設對端開啓了tcp_timestamps，然後會去比較時間戳，如果時間戳變大了，就可以重用。但是，如果對端是一個NAT網絡的話（如：一個公司只用一個IP出公網）或是對端的IP被另一臺重用了，這個事就複雜了。建鏈接的SYN可能就被直接丟掉了（你可能會看到connection time out的錯誤）（如果你想觀摩一下Linux的內核代碼，請參看源碼 tcp_timewait_state_process）。

• 關於tcp_max_tw_buckets。這個是控制併發的TIME_WAIT的數量，默認值是180000，如果超限，那麼，系統會把多的給destory掉，然後在日誌裏打一個警告（如：time wait bucket table overflow），官網文檔說這個參數是用來對抗DDoS攻擊的。也說的默認值180000並不小。這個還是需要根據實際情況考慮。

Again，使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險的，因爲這兩個參數違反了TCP協議（RFC 1122）

其實，TIME_WAIT表示的是你主動斷連接，所以，這就是所謂的“不作死不會死”。試想，如果讓對端斷連接，那麼這個破問題就是對方的了，呵呵。另外，如果你的服務器是於HTTP服務器，那麼設置一個HTTP的KeepAlive有多重要（瀏覽器會重用一個TCP連接來處理多個HTTP請求），然後讓客戶端去斷鏈接（你要小心，瀏覽器可能會非常貪婪，他們不到萬不得已不會主動斷連接）。

問題

爲什麼建鏈接要3次握手 , 2次握手不行嗎 ?

接下來以三個方面分析三次握手的原因：

• 三次握手纔可以阻止歷史重複連接的初始化（主要原因）
• 三次握手纔可以同步雙方的初始序列號
• 三次握手纔可以避免資源浪費

歷史重複連接的初始化 這個場景可以見下面這張圖 :

就是說 SN 是遞增的.

參考資料

• https://coolshell.cn/articles/11564.html
• https://blog.csdn.net/lianshaohua/article/details/105549767 (重要,推薦一看)
• https://www.cnblogs.com/dgutfly/p/11558953.html
• https://www.cnblogs.com/xrq730/p/6910719.html(三次握手四次揮手).
• https://www.cnblogs.com/dgutfly/p/11558953.html
• https://www.bilibili.com/video/BV1kV411j7hA (必看)
• https://draveness.me/whys-the-design-tcp-three-way-handshake/
• https://www.zhihu.com/question/49794331(好問題)
• https://datatracker.ietf.org/doc/html/rfc793 (RFC 文檔)