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

https://blog.csdn.net/qzcsu/article/details/72861891

https://www.cnblogs.com/Andya/p/7272462.html

https://blog.csdn.net/hacker00011000/article/details/52319111

• • 為什麽客戶端還要發送一次確認呢？可以二次握手嗎？
  • 解釋四次揮手？
  • 為什麽建立連接是三次，關閉連接是四次
  • 為什麽客戶端最後還要等待2MSL(最大報文段生存時間)
  • 如果已經建立了連接，但是客戶端突然出現故障了怎麽辦？
  • Server端易受到SYN攻擊？
  • SYN Flood 防護措施

為什麽客戶端還要發送一次確認呢？可以二次握手嗎？

1. 主要為了防止已經失效的鏈接請求報文突然又傳送到了服務端
2. 假設A是客戶端，B是服務端，如果A發出請求，但是因鏈接請求報文丟失而未收到確認，於是A會再重傳一次請求；
3. A在整個過程中，一共發了兩次鏈接請求，其中第一個可能因為網絡等其他因素導致當時B端未收到請求；但是再A,B端均釋放鏈接以後，此時那個我們認為已經丟失的A鏈接請求達到了B端，那麽B可能會誤認為A發出的是一個新的請求，於是向A發出確認報文段，同意鏈接
4. 此時因為A已經關閉，A對於B的統一鏈接請求不予響應，導致B一直等待響應，浪費資源

解釋四次揮手？

1. 假設A是客戶端，B是服務端
2. A發送中斷請求，即FIN報文，即A告訴B：我這邊沒有數據要發送給你了，但是如果你還有沒有發送完的數據，可以不必關閉SOCKET,可以繼續發送數據
3. B在收到A的請求後，ACK告訴A，你的請求我收到了，但是我還沒準備好，請你繼續等待我的消息
4. 此時A進入FIN_WAIT狀態，等待B的FIN報文
5. 當B數據確認發送完成，向A發送FIN報文，告訴A，我這邊數據發送完了，準備關閉連接；
6. A在收到FIN報文後，知道可以關閉連接了，但是A不相信網絡，怕server段不知道要關閉，所以發送ACK後進入TIME_WAIT階段
7. 如果B端沒有收到ACK則可以重傳
8. B端收到ACK後，知道可以關閉連接了
9. A端等待2MSL後依然沒收到回復，則證明B端已正常關閉，進而A端關閉連接

為什麽建立連接是三次，關閉連接是四次

假設A是客戶端，B是服務端

1. 當B收到SYN鏈接請求時，可以直接發送SYN+ACK報文給A，其中ACK是應答，Syn報文是用來同步的
2. 當關閉鏈接時，當B收到FIN請求時，很可能不立即關閉SOCKET，所以只能先回復ACK，告訴A，中斷鏈接請求已收到；
3. 只有當B端的數據發送完畢後，B才能發送FIN+ACK給A端；
4. A端收到響應，發送ACK至B端，響應中斷，2MSL後，A端關閉

為什麽客戶端最後還要等待2MSL(最大報文段生存時間)

假設A是客戶端，B是服務端，A等待2MSL有如下原因，一般2-4分鐘

1. 保證客戶端發送的最後一個ACK報文能到到服務器

• 針對B端，已經發送了FIN+ACK報文給A端，但是A可能因為網絡等其他原因沒有未收到請求，未能及時回復B
• 此時，B可能會再發一段FIN+ACK報文給A端，
• 此時如果A在2msl時間段內收到這個重傳的FIN+ACK報文段，接著A重傳一段確認，重新啟動2MSL計時器，最終A，B進入close狀態
• 如果A不等待，即發送完ACK報文立即釋放，則無法收到B重傳的FIN+ACK報文，所以A也就不會重發一段ACK報文，則B無法正常進入close狀態

2. 防止“已失效的連接請求報文段”出現在本連接中

• A在發送完最後一個ACK報文段後，再經過2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失，使下一個新的連接中不會出現這種舊的連接請求報文段
• 當某個連接的一端處於TIME_WAIT狀態時，該連接將不能再被使用

如果已經建立了連接，但是客戶端突然出現故障了怎麽辦？

1. TCP設有一個保活計時器；服務器每收到一個客戶端的請求，都會重新復位這個計時器；通常設置是2小時；
2. 若2小時內，還沒有收到客戶端的回復，服務器會發送一個探測報文段，以後每隔75分鐘發送一次；
3. 若一連發送10個探測報文仍然無反應，則終止鏈接

Server端易受到SYN攻擊？

1. 服務端的資源分配是在二次握手時分配的，而客戶端的資源是在三次握手時分配的；
2. SYN攻擊，即客戶端在短時間內偽造大量不存在的IP地址，並向SERVER端不斷的發送SYN包，SERVER收到請求即回復確認，並等待客戶端的確認，由於源地址不存在，因此SERVER需要不斷的重發直到超時；
3. 這些偽造的SYN包長時間占用未連接隊列，導致正常的SYN請求因為隊列滿而丟棄，因為網絡擁塞
4. 一般服務端會重試5次

SYN Flood 防護措施

1. 無效鏈接釋放，監視系統中的半開鏈接和不活動的鏈接，達到閾值，釋放資源，但是這樣可能也會將正常的鏈接釋放掉；
2. 延緩TCB分配

• 正常情況下，當SYN報文收到的時候，系統即分批資源，那麽可以在收到SYN時，不著急分配TCB，而是先回應一個ACK報文，並在一個專用的HASH表中，保存這種半開鏈接，等收到ACK再分配
• Syn Cookie：將第一次收到請求的IP 端口等信息加密生成一字符串，在收到ACK的時候，判斷是否一致，一致則分配

• ======================================================================================
  越努力，越幸運，加油

TCP三次握手，四次揮手