從好上開始，到現在，一年多也算堅持下來了。
中間雙方可能就要不斷的確認網路是否恢復，但是有時候會：
她：「你可以聽到了嗎？」
我：「可以了，你呢？」、
她：「喂喂，你可以聽到了嗎？」
我：「可以了，我可以聽到了，你呢？」
她：「你可以聽到了嗎？」
這種情況就很難受，那麼怎樣才能找乙個簡單的辦法，讓兩個人都確認自己可以聽到對方的聲音，對方也可以聽到自己的聲音呢？
ps：以上情節純屬虛構。
tcp建立連線為什麼是三次握手，而不是兩次或四次？
tcp，名為傳輸控制協議，是一種可靠的傳輸層協議，ip協議號為6。
順便說一句，原則上任何資料傳輸都無法確保絕對可靠，三次握手只是確保可靠的基本需要。
舉個日常例子，打**時我們對話如下：
對應為客戶端與伺服器之間的通訊：
縮寫：於是有了如下對話：
我：1+1等於幾？
她：2,2+2等於幾？
我：4首先兩個人約定協議
1.感覺網路情況不對的時候，任何一方都可以發起詢問
2.任何情況下，若發起詢問後5秒還沒收到回覆，則認為網路不通
3.網路不通的情況下等1min路由器之後再發起詢問
對於我而言，發起 「1+1等於幾」的詢問後
1. 若5s內沒有收到回覆，則認為網路不通
2. 若收到回覆，則我確認①我能聽到她的訊息 ②她能聽到我的訊息，然後回覆她的問題的答案
對於她而言，當感覺網路情況不對的時候
1. 若沒有收到我的詢問，則她發起詢問
2. 若收到「1+1等於幾」，則她確認 ①她可以聽到我的訊息，然後回覆我的問題的答案和她的問題「2，2+2等於幾」
3. 若5s內沒有收到我的回覆「4」，則她確認 ②我聽不見她的訊息
4. 若5s內收到了我的回覆「4」，則她確認 ②我可以聽見她的訊息
這樣，如果上面的對話得以完成，就證明雙方都可以確認自己可以聽到對方的聲音，對方也可以聽到自己的聲音！
這個故事可以解釋tcp為什麼要三次握手嗎 ... 囧
先由客戶端向伺服器端傳送乙個fin，請求關閉資料傳輸。
當伺服器接收到客戶端的fin時，向客戶端傳送乙個ack，其中ack的值等於fin+seq
然後伺服器向客戶端傳送乙個fin，告訴客戶端應用程式關閉。
當客戶端收到伺服器端的fin是，回覆乙個ack給伺服器端。其中ack的值等於fin+seq
確保資料能夠完整傳輸。
當被動方收到主動方的fin報文通知時，它僅僅表示主動方沒有資料再傳送給被動方了。
但未必被動方所有的資料都完整的傳送給了主動方，所以被動方不會馬上關閉socket,它可能還需要傳送一些資料給主動方後，
再傳送fin報文給主動方，告訴主動方同意關閉連線，所以這裡的ack報文和fin報文多數情況下都是分開傳送的。
tcp連線佇列：
接收佇列（receive queue）：
三次握手和四次揮手 TCP三次握手和四次揮手的理解
相比較於udp傳輸協議，tcp傳輸協議被認為是安全可靠的，這是由於tcp協議的三次握手和四次揮手保證了資料傳輸的安全性。tcp報文格式簡介 要了解tcp協議的三次握手和四次揮手，需要先了解在tcp協議中請求和響應的資料報報文格式。在報文中有幾個值得注意的字段 1 序號 seq序號，佔32位，用來標識...
TCP三次握手和四次揮
一 tcp報文格式 在了解三次握手和四次揮手之前，首先要知道tcp報文內部包含了哪些東西。報文主要段的含義 序號 seq 用來標記資料段的順序，確保tcp傳輸有序。ack 確認 確認序號標誌，ack 1表示確認號字段有效，ack 0表示確認序號無效。syn 同步 連線請求序號標誌，用於建立連線。sy...
tcp ip三次握手與四次揮手
原文 所謂三次握手 three way handshake 即建立tcp連線，就是指建立乙個tcp連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中，這一過程由客戶端執行connect來觸發。1 第一次握手 client將標誌位syn置為1，隨機產生乙個值seq j，...