Stateless/Stateful理解心得

https://www.colocationamerica.com/blog/tcp-ip-vs-udp

偶然認識到這兩個名詞，根據Wiki解釋加上自己根據領域工作經驗腦補的心得，嘗試拓展，整理深究對於交握/互動的抽象概念:

• 無狀態協議(Stateless Protocol)
• 定義
• 發送端(sender)/接收端(receiver)不需儲存過程資訊也能完成的會談(session)，也表示彼此互相不須知道對方所在的會談狀態

• 延伸
• 隱喻了每次會談僅需單向給予一個需求(Request)或回應(Response) ，且接收者無須回傳確認(Acknowledgement)，因為既然是無狀態，發送端也無須知道接收者狀態，某種射後不理的概念
• 會談所消耗的資源較少，需要較少的儲存區也不用額外執行緒處理個別連線需要

• 比喻
• 長官單向傳達旨意給部屬，部屬收到旨意後展開行動，旨意中要具備充分的資訊足以讓部屬展開完整行動
• 轉載Kenming鮮思維
• Stateless物件就像計程車，並不是專為某位顧客服務，只要少數的計程車就可為極多數的客人服務。 
• 當您呼叫計程車時，並不會指明要上次所搭那一輛計程車。
• 設計推論
• 設計上必須不假設對方所在的狀態
• 發送端/接收端應用層仍可以是狀態機，根據當前內部狀態加上收到的需求/回應決定下個狀態(必須總是有出口)，在狀態轉移的過程(state exit)產生回應
• 會談層無狀態，但應用層有狀態
• 會談層不用具備逾時(Timeout)處理
• 缺點
• 由於一次傳遞即要展開功能，在會談封包裡相對要帶入較多額外資訊 ，一次傳遞的單體資訊量可能較多
• 安全性可能較低?因為展開會談前並不需要有既定的預備動作確認連線身分
• 範例
• UDP(User Datagram protocal) connectionless session

• 有狀態協議(Stateful Protocol)
• 定義
• 會談過程雙方都必須記住對方狀態的會談模式，即稱為有狀態協議
• 延伸
• 發送端(sender)/接收端(receiver)需要多次需求(Request)或回應(Response)才能完成一次會談
• 需求或回應推動會談狀態變化(State Transition)，狀態變化後需要回應進行對口端，彼此滾轉自身狀態機並同時回應，在若干步驟後完成一次會談
• 會談所消耗的資源較多，因為需要額外配置儲存區存放會談資訊，還需要額外執行緒處理會談逾時等例外狀況
• 跟對方問了問題，但一直不回應我，等到一段時間過去我只好去做別的事，下次重啟對話看是要從頭開始，還是期待對方回應上次問的問題，此時假設了對方有記住你之前問了什麼
• 比喻
• 辯論雙方交叉攻訐後才能判定結論，辯論程序本身是固定的，但根據辯論內容會產生不同結論(結論送給應用層看是要作何用)
• 轉載Kenming鮮思維
• 像自用轎車，每部只服務特定的顧客，常需要較多的停車場
• 設計推論
• 設計上必須假設對方所在的可能狀態，又或是就所有可能的雙方所在狀態列舉交握情境並設計交握規格；若有交握規則裡有情境未被涵蓋，則可能發生會談卡住或雙方會談不同步的情況
• 由於不可抗造成的通訊中斷情形存在(非會談層造成)，會談層內必須有逾時處理，讓會談狀態機在會談例外時能跳脫，使狀態歸零或額外送出能讓會談繼續的資訊

• 範例
• TCP(Transmission Control Protocal) connection-oriented session，著名的三向交握

後記1: 無狀態/有狀態溝通的概念不僅用在系統間，內部物件間的溝通也可用套此概念分析特性，乃至人際溝通?

後記2: 一個會談完成產出一次有效且完整的資訊