tcp是在osi模型傳輸層中的可靠傳輸協議，通過三次握手建立連線，傳送端對資料進行分組，然後通過套接字傳送到快取中，進行傳送。接收端將報文段接收到接收快取中，然後再讀取資料。接收方通過滑動視窗通知傳送方控制吞吐量。遇到資料報丟失了就會通過選擇重傳來重新獲得資料報，資料傳輸完後進行四次揮手關閉連線。
首先握手為什麼需要三次？3次握手的作用是讓「收發雙方都明確自己和對方的收發能力是正常的」。 第一次握手，客戶端向伺服器傳送請求，伺服器正確接收，那麼伺服器就知道了客戶端的傳送功能正常，自己的接收功能正常。 第二次握手，伺服器向客戶端傳送請求，客戶端正確接收，此時客戶端知道了自己的收發功能都是正常的，伺服器的收發功能也是正常的。但此時伺服器還不知道自己的傳送功能和客戶端的接收功能如何。 第三次握手，客戶端返回訊息，伺服器就知道了自己的收發和客戶端的收發功能都是完好的了。 關於為什麼要傳送第三次，書上是這麼說的：防止已經失效的連線請求報文段突然傳送到伺服器產生錯誤。(客戶端傳送了兩次連線請求，第一次在路上耽誤了，結果第二次的連線請求成功，傳送完資料結束了。第乙個連線到達，伺服器又開啟連線。有了第三次握手，伺服器收到失效連線後再也收不到第三次握手就知道這是失效連線了)
補充：知乎上的大神說，防止失效連線只是表象，真正的原因是tcp建立連線需要同步通訊雙方資料原點的序列號，也就是雙方開始傳送位元組的起始編號，客戶端第三次握手是為了讓伺服器知道客戶端已經接受了同步訊號。具體分析搜尋知乎問題：tcp 為什麼是三次握手，而不是兩次或四次？
個人見解，上述原因可能都是三次握手的原因，三次握手滿足了多個需求，就是這麼妙的設計?為什麼分手需要4次呢？客戶端向伺服器傳送乙個fin段，伺服器返回乙個ack段，此時客戶端->伺服器方向上的連線關閉了，但是伺服器還能向客戶端傳送資料，傳送結束後伺服器傳送乙個fin段，客戶端返回乙個ack，等待2個msl(最長報文段壽命)後關閉。 為什麼客戶端要等待2msl再關閉，主要有兩個原因：第一是確保客戶端最後乙個ack可以到達服務端，如果在途中丟失了，伺服器會重發fin，這最大需要2msl；第二是防止三次握手所說的「失效連線請求報文」，等待2個msl後，本連線所有的請求都會消失。
筆記 k8s通訊相關
高效檢測變化，resourceversion機制 get list的resourceversion語義 watch的resourceversion語義 從文件推測，list和watch的resourceversion語義的暗示都是一樣的 如果不指定，則從etcd quorum read 的獲取最新版...
k8s 相關的基本操作
動態獲取 lcmapi 所有 pod 的日誌，不同 pod 輸出按顏色區分 bash c curl fssl kubetail lcmapi n storage system mysql as p 4000 u root password umstor fancy 2019 dumstorlcm h...
K8s入門 相關名詞
pod是所有業務型別的基礎，也是k8s管理的最小單位級，它是乙個或多個容器的組合。pod 的context可以理解成多個linux命名空間的聯合 pid 命名空間 同乙個pod中應用可以看到其它程序 網路 命名空間 同乙個pod的中的應用對相同的ip位址和埠有許可權 ipc 命名空間 同乙個pod中...