1.在學習tcp協議的時候，總是在強調三次握手，那麼為什麼是三次？而不是兩次或者四次？（強迫症表示黑人問號？？？？）
今天我們就來分析一下為什麼是三次，下圖是一次tcp通訊的時序
在這個例子中,首先客戶端主動發起連線、傳送請求,然後伺服器端響應請求,然後客戶端主動關閉連線。兩條豎線表示通訊的兩端,從上到下表⽰示時間的先後順序,注意：資料從一端傳到網路的 另一端也需要時間,所以圖中的箭頭都是斜的。雙方傳送的段按時間順序編號為1-10, 各段中的主要資訊在箭頭上標出,例如段2的箭頭上標著syn, 8000(0), ack 1001, , 表⽰示該段中的syn位置1,32位序號是8000,該段不攜帶有效載荷(資料位元組數為0),ack位置 1,32位確認 序號是1001,帶有乙個mss選項值為1024。
好吧，我知道大部分的你們和我一樣，看了上面這段話依然是雲裡霧裡的，所以咱們還是通俗的解釋一下吧：
首先我們知道，tcp協議是面向位元組流的全雙工通訊，也就是兩方可以同時進行收發訊息，是一種面向連線的，根據請求、應答來保證傳輸可靠性的一種通訊協議。
第一次a->b：b確認a的發信機和自己的收信機是沒有問題的，可以正常傳送和接受訊息
第二次b->a：b回應，a收到了。這時a可以確認的是，自己和b的收發信機都是好的。此時b並不知道a是否收到回應，即不確定a的收信機以及自己的發信機是否完好
第三次a->b：a對b的回應進行回應。這時a很清楚，雙方收發信機都是好的，自己的這次回應b肯定能收到(正常情況下)，這個回應的目的只是消除b對a的收信機和b自己的發信機的擔心。然後，a不必等b的再次回應就可以正式發信了。
第三次 ack 丟了沒有太大問題。只要b後面接收到a的資料報過來，就可以確認連線已建好。如果a不傳送別的資料報，那麼b會超時重傳第二次的握手資訊。
讓我們想一想，如果是兩次的話，a傳送請求，b應答並分配資源若b的應答沒有到達a端，a認為連線未建立，而b認為建立了a會在一段時間內保留分配的資源如果大量a這樣請求，b會崩潰。
至於為啥不是四次？既然三次已經足夠了，為啥還要再來一次？簡單而粗暴的理由~
2. 現在是關於四次揮手，在連線完成之後呢，需要關閉連線。
關閉連線的過程：
1）客戶端發出段7，fin位表示關閉連線的請求
2）伺服器發出段8，應答客戶端的關閉連線請求。
3）伺服器發出段9，其中也包含fin 位，向客戶端傳送關閉連線請求。
4）客戶端發出段10，應答伺服器的關閉請求
注意：伺服器的應答和關閉連線請求通常不合 並在⼀乙個段中,因為有連線半關閉的情況,這種情況下客戶端關閉連線之後就不能再傳送 資料給服 務器了,但是伺服器還可以傳送資料給客戶端,直到伺服器也關閉連線為⽌。
好了，這就是我對三次握手和四次揮手的理解，如果還有小夥伴有不同的理解，歡迎補充！
三次握手和四次揮手
三次握手和四次揮手如圖所示 為什麼是三次握手而不是兩次 因為當客戶端第傳送syn到服務端的時候，如果有幾次請求是因為網路等原因延時等情況的時候，如果沒有第三次握手的確定。服務端就會認為客戶端重寫傳送請求了，就會去開啟連線相應。為什麼關閉連線的時候是四次握手而不是三次？當客戶端傳送請求關閉連線的時候，...
三次握手和四次揮手
tcp三次握手和四次揮手的全過程 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線 位碼即tcp標誌位,有6種表示 syn synchronous建立連線 ack acknowledgement 表示響應 確認 psh push表示有data資料傳輸 fin fi...
三次握手和四次揮手
1.三次握手 1 目的 連線伺服器指定埠，建立tcp連線，並同步連線雙方的序列號和確認號，並交換tcp視窗大小資訊 2 過程 在socket程式設計中，客戶端執行connect 時進行三次握手 如上圖所示，第一握手進行後，客戶端處於syn sent狀態，客戶端的syn報文伺服器收到後，伺服器處於li...