TCP三次握手，四次揮手

參考文章，感謝原博主的分享與總結；

主要為了防止已經失效的鏈結請求報文突然又傳送到了服務端

假設a是客戶端，b是服務端，如果a發出請求，但是因鏈結請求報文丟失而未收到確認，於是a會再重傳一次請求；

a在整個過程中，一共發了兩次鏈結請求，其中第乙個可能因為網路等其他因素導致當時b端未收到請求；但是再a,b端均釋放鏈結以後，此時那個我們認為已經丟失的a鏈結請求達到了b端，那麼b可能會誤認為a發出的是乙個新的請求，於是向a發出確認報文段，同意鏈結

此時因為a已經關閉，a對於b的統一鏈結請求不予響應，導致b一直等待響應，浪費資源

假設a是客戶端，b是服務端

a傳送中斷請求，即fin報文，即a告訴b：我這邊沒有資料要傳送給你了，但是如果你還有沒有傳送完的資料，可以不必關閉socket,可以繼續傳送資料

b在收到a的請求後，ack告訴a，你的請求我收到了，但是我還沒準備好，請你繼續等待我的訊息

此時a進入fin_wait狀態，等待b的fin報文

當b資料確認傳送完成，向a傳送fin報文，告訴a，我這邊資料傳送完了，準備關閉連線；

a在收到fin報文後，知道可以關閉連線了，但是a不相信網路，怕server段不知道要關閉，所以傳送ack後進入time_wait階段

如果b端沒有收到ack則可以重傳

b端收到ack後，知道可以關閉連線了

a端等待2msl後依然沒收到回覆，則證明b端已正常關閉，進而a端關閉連線

假設a是客戶端，b是服務端

當b收到syn鏈結請求時，可以直接傳送syn+ack報文給a，其中ack是應答，syn報文是用來同步的

當關閉鏈結時，當b收到fin請求時，很可能不立即關閉socket，所以只能先回覆ack，告訴a，中斷鏈結請求已收到；

只有當b端的資料傳送完畢後，b才能傳送fin+ack給a端；

a端收到響應，傳送ack至b端，響應中斷，2msl後，a端關閉

假設a是客戶端，b是服務端，a等待2msl有如下原因，一般2-4分鐘

保證客戶端傳送的最後乙個ack報文能到到伺服器

防止「已失效的連線請求報文段」出現在本連線中

tcp設有乙個保活計時器；伺服器每收到乙個客戶端的請求，都會重新復位這個計時器；通常設定是2小時；

若2小時內，還沒有收到客戶端的回覆，伺服器會傳送乙個探測報文段，以後每隔75分鐘傳送一次；

若一連傳送10個探測報文仍然無反應，則終止鏈結

服務端的資源分配是在二次握手時分配的，而客戶端的資源是在三次握手時分配的；

syn攻擊，即客戶端在短時間內偽造大量不存在的ip位址，並向server端不斷的傳送syn包，server收到請求即回覆確認，並等待客戶端的確認，由於源位址不存在，因此server需要不斷的重發直到超時；

這些偽造的syn包長時間占用未連線佇列，導致正常的syn請求因為佇列滿而丟棄，因為網路擁塞

一般服務端會重試5次

無效鏈結釋放，監視系統中的半開鏈結和不活動的鏈結，達到閾值，釋放資源，但是這樣可能也會將正常的鏈結釋放掉；

延緩tcb分配