在通訊系統中，最基本的資訊的傳遞都需要兩步，傳送方傳送的訊息和對方的回覆確認：a->b send, b->a reply(ack)。如果多接觸一下其他行業的通訊流程和規範，例如航空、鐵路排程，就會明白這一點。
tcp 建聯，本質上需要傳遞兩條資訊：a->b 的初始 syn 號，b->a 的初始 syn 號，那麼理論上需要四步通訊（ a->b 的初始 syn 號，b->a 的 ack ； b->a 的初始 syn 號，a->b 的 ack ）；只不過為了效率和效能，中間兩條訊息可以合併為一條，這便是現在的三路握手的**。後續的所有報文的傳遞機制，依然是send/ack兩步 + 訊息合併。
僅有send沒有reply，屬於不可靠傳遞；send有單條reply，可以實現99%的容錯。只有傳送方才有責任確保訊息傳遞完整性，而且因為兩軍問題，任何通道不可能實現100%的有效性。所以折衷考慮，一般一條send只需有乙個reply.
通訊技術，關心的是通訊的基本單元(單條訊息、乙個獨立的資料報...)，如何盡可能可靠地傳遞的流程，適用於所有領域，屬於通用的泛化的規則。例如上述send/reply模型。
而協議，描述的則是訊息的內容、格式，以及多條訊息之間如何互動，是和應用領域相關的。例如：沒有reply意味著什麼，reply可以是什麼樣的資訊格式，不同的格式代表什麼含義，不同的格式下採用什麼行為...
例如在航空通訊，塔台向客機傳送指令的協議：
上海管制區pvg進近塔台：東方三兩么拐，航向187度上3000保持！指令格式可以自定義，但塔台發出的指令，必須有reply。mu3217機長：航向187度上3000保持，東方三兩么拐！
tcp協議還可以定義狀態機、定義新的型別字段、新的語義，但是任何一方主動發出的訊息，必須有reply(ack).
所以，目前中文網際網路的所謂「原因分析」都是皮肉之象，比如「防止包亂序及可能的重連」、「確認對方有收和發的能力」.....都不是三路握手的問題的本質。因為混淆了通訊技術和tcp協議，甚至對通訊基本原理沒有任何感知。
TCP連線的三路握手
本文內容參考 unix網路程式設計 大概描述了tcp連線的三次握手過程，這是我看到的最清楚的描述，記錄在這裡，希望能幫助到大家對於tcp連線過程的理解。傳輸控制協議 tcp 是tcp ip協議簇裡非常重要的乙個協議。它提供客戶與伺服器之間的連線，並且提供可靠的資料傳輸功能。關於這個協議的具體規定，請...
3 4併發 時間是乙個本質問題
這一節說的是併發，出現在程式性語言中的多程序多執行緒問題 這裡說一下程序 執行緒 協程的區別吧 它們之間區別可以檢視這裡一篇部落格 3.4.1 併發系統中時間的本質 這裡說的是併發程式，cpu時間片爭奪資源造成的不可知危害，在資料庫課上也有說，例如常見的幻讀等 這節說的是併發程式的正確行為的許多方法...
SOA的本質是組織設計的乙個模式乙個方法
本文中的5s 是指麥肯錫企業管理的 7s方 中，除了 願景和戰略之外的5個s 包括 系統systems 組織structure 能力skills 人力staff 文化style 麥肯錫7s模型 很多人都在說soa 但是真正能夠把 soa說清楚的沒幾個。要不就是太概念化，要不就是太意識化。我希望我這次...