HTTP協議為什麼連線的時候是三次握手，關閉的時候卻是四次握手？

準確說是tcp協議的三次握手和四次揮手。

1。建立tcp連線，三個階段：

1。1。A端傳送一個序列號seq=x的包給B端

1。2。B端回覆一個包頭包含seq=y， ack=x+1的包給A端

1。3。A端回覆確認一個包含seq=x+1， ack=y+1的包頭的包給B端，此刻雙方已建立連線。

為什麼一定是三次握手呢？為什麼不選擇4，5，6等次握手呢？這裡我理解是一個最低限度確認機制。三次傳送可以理解為，客戶端說，我想傳送資料，服務端請你準備一下。服務端說，我準備好了，你也準備一下發送吧。客戶端又說，好的我知道你準備好了，我也準備好要發生了。到此為止，三次握手成功則連線建立成功，接下來就是傳送資料。那麼三次握手之間某一階段失敗了會出現什麼結果呢，很明顯，無論是哪一階段失敗都將導致連線建立失敗。我只要知道三次握手成功，則就可以建立起tcp連線準備傳輸資料了。

2。那斷開連線為什麼要四次揮手呢？一次，三次或五次不行嗎？

首先，考慮一下如果客戶端或服務端單方面終止接受服務端或客戶端發來的資料會怎麼樣？會導致傳送的包永遠無法得到確認，甚至導致傳送重複包浪費頻寬。可能會猜想只要我重複傳送幾次包都沒有得到ack確認就表示對方已經斷開連線，此時我也斷開連線就行了，但是這種工作方式是低效的，浪費頻寬和時間。

那麼，如何客戶端（或服務端）向服務端（或客戶端）傳送一個埠連線請求，然後再收到對方的斷開確認包，此時雙方就可以斷開連線，很高效的方式，只要一來一回兩次揮手成功就可以保證雙方均已斷開連線。這裡就引出另一深層次的問題，斷開連線由一方發起請求，另一方傳送確認斷開連線的包。這種單方面請求斷開連接合理嗎？另一方如果還有資料要傳送怎麼辦？為了解決這個問題，這裡引入了一個半連線的概念，即A端向B端請求斷開連線並得到確認，此時僅僅是終止了，A端主動向B端傳送資料，但B端仍然可以主動傳送資料給A端，一段時間內，若B端沒有可傳資料，則B端向A端發起斷開連線請求，A端發起確認給B端，此刻，雙方均無資料傳送，連線完全斷開。即發生了四次揮手，保證雙方公平斷開連線。

以上是個人見見，如有錯誤，歡迎指正。