今天恰好看了看tcp協議中的三次握手和四次揮手,將一些理解記下來供以後參考吧!
發現有這樣乙個觀點，認為三次握手的翻譯並不準確，原因是英文原檔裡的表述為"three way(three message) handshake"，請注意，handshake是單數，因此作者認為僅僅進行了一次握手，只是交換了三次報文而已，故將其譯為三報文握手而不是三次握手。但由於後者更容易理解，且更流行，故本文依舊採用三次握手。
先上圖
具體內容就不說了，網上很多，在此只談談自己的理解。
流程如下:
1. a要向b傳送東西(資料)，首先得a告訴b：b啊，我有東西要給你，你做好準備，此為1；
2. 然後b給a回話，說：嗯，我知道了，也準備好了，此為2；
3. a收到b的確認訊息後，告訴b：那我開始傳送資料了，你注意接收，此為3。
疑惑點：
1）為什麼要有3。
原因：情況一：確認訊息(2)由於各種原因丟失了，而此時b已經開始接收資料，a由於沒有收到b的確認(2)一直等待直到a的等待時間截止重寫傳送請求(1)，從而造成了b資源的浪費(因為b一直處於接收狀態)；
情況二：1出現了問題，1的資料由於某種原因被阻塞在了某個路由器上，並且超過了a的等待時間，故a要再次傳送請求給b(重寫傳送1)，此請求成功的完成了資料傳送，a、b斷開連線，這個時候，第一次傳送的請求此時到達b，b傳送確認訊息(2)，開始接收資料，但a認為它並沒有傳送請求而不出來b的確認訊息，不會傳送資料,也造成了b的資源浪費。
還是先上圖：
流程如下：
a資料傳送完畢，想要斷開連線，向b傳送連線請求，此為1；
b收到a的請求後，向a傳送確認訊息，此為2；
之後，b關閉與a有關各個連線程序，關閉完畢，給a傳送資訊，此為3；
a收到訊息後，給b傳送確認訊息，此為4。
b收到確認後，立即關閉，而a還要等待2msl時間，然後關閉。
疑惑點：
1）為什麼要有2，為什麼b收到1的訊息後，關閉程序了在向a傳送確認（跳過2，直接3）。
原因：a會有等待時間，超過等待時間後，a會認為b沒有收到它的訊息，從而重發1。就像兩個人之間，我正在學習，你叫我吃飯（對應上面的1），我回應了：你等我把這道題做完（2），做完後，我叫你去吃飯（3），你說：行，那走（4）。
若沒有2，你叫我，我視而不見，不做任何回應，你心裡作何感想，還會繼續等我去吃飯嗎，我想你的內心是這樣的：滾犢子吧，愛吃不吃。
2）為什麼還要有4，做完題叫我吃飯直接走就行了啊，那這麼多廢話啊。
原因：與上面三次握手的原因相同，3過程的資料丟失怎麼辦，不要4，b傳送完3後就關閉，3資料還丟失了，重發不了，那a怎麼關閉啊，關閉不了了，只能繼續占用資源了。
3）為什麼a傳送確認（4）後還要等待2msl的時間。
原因：同樣的，若a傳送4後立即關閉，但是4過程的資料又丟失了，b沒有收到，b關閉不了，浪費資源的，等待的時間就是為了資料丟失進行重發資料的。
tcp三次握手和四次握手
建立tcp需要三次握手才能建立，而斷開連線則需要四次握手。整個過程如下圖所示 先來看看如何建立連線的。首先client端傳送連線請求報文，server段接受連線後回覆ack報文，並為這次連線分配資源。client端接收到ack報文後也向server段發生ack報文，並分配資源，這樣tcp連線就建立了...
TCP三次握手和四次握手
ip 網路層 不穩定性。硬體聯絡緊密 傳輸層 1.完全不彌補 udp 無連線不可靠報文傳輸 2.完全彌補 tcp 面向連線的可靠資料報傳遞 tcp傳送資料就包含了tcp三次握手建立連線和關閉連線的四次握手 建立連線用syn傳送，用ack應答 所謂三次握手就是客戶端與伺服器之間的三次應答。伺服器是一直...
TCP協議 TCP三次握手四次揮手
tcp連線管理機制 在正常情況下，tcp要經過三次握手建立連線，四次揮手斷開連線 完整過程 三次握手建立連線 服務端狀態變化 客戶端狀態轉化 為什麼是三次握手，兩次為什麼不可以 如果只有兩次握手，那麼可能會導致客戶端傳送給服務端的失效請求被服務端接收，從而導致錯誤。失效的請求 客戶端向服務端傳送連線...