為什么TCP建連接要3次，斷連接卻要4次

本篇內容介紹了“為什么TCP建連接要3次，斷連接卻要4次”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

大家好，今天聊聊傳輸層通信協議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數量太多。從上面的描述我們可以知道，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建連接要3次，斷連接卻要4次”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！