HTTP為什麼要設計成無狀態的，這樣比有狀態有什麼好處，有哪些協議是典型的有狀態，好處又在哪裡？

01-23

總是看到說http是無狀態的，所以需要session和cookie之類的，但是為什麼要設計成無狀態，而不是一開始就設計為有狀態呢，每次請求頭裡面加東西，感覺也是有狀態啊，如果這不算是有狀態，那麼真正的有狀態又是指什麼呢

首先，要定義一下什麼叫【無狀態】。假設用戶A向服務B發了一個請求1，再次發送一個請求2。服務端本身完全不知道兩個請求來自同一個用戶，這在協議層次就是【無狀態】的。

【無狀態】設計不是因為 @方正所說的歷史原因，而是故意為之。無狀態就意味著服務端可以根據需要將請求分發到集群的任何一個節點，對緩存、負載均衡有明顯的好處，這一點很容易找到相關文獻。

很多人對【無狀態】感到不理解，大部分情況是誤解了【無狀態】的含義。http【無狀態】僅僅是在*協議層*，當業務需要狀態的時候，可以通過request中數據攜帶所需狀態的id來實現。例如，為了讓伺服器知道是同一個用戶的請求，請求1和請求2中必須攜帶一個相同的id，讓服務端可以根據這個id，最終找到用戶數據（【狀態】）。

實現1：這個狀態如果放在處理請求的伺服器進程中（例如session），那伺服器進程就是有狀態的，該用戶下一個請求如果沒分發到這個進程，就會拿不到上一次請求留下的狀態，這樣會影響負載均衡和緩存的實現。

實現2：這個狀態如果放在處理請求的伺服器進程之外的集中式存儲，那伺服器進程仍然是無狀態的，可以集群、負載均衡。無狀態服務一般都用這種方案。

最後我的觀點是：無狀態和有狀態服務適合不同的場景，並沒有絕對的優劣。

可參考

https://www.zhihu.com/question/23202402/answer/107746695

無狀態協議有兩個顯著的好處，第一是容易實現高並發；第二是實現諸如代理/轉發/過濾等機制非常簡單而且不容易出錯。

打個比方，郵件就是典型的無狀態協議——無論中間經過多少人，只要看一眼信封上的地址就可以投遞了，不需要來回溝通，並且郵件的分揀可以設計得極其高效。

而電話則屬於有狀態協議，不管你有沒有說話，只要還沒掛，這條線路就一直佔用著，無法服務其他人，這是性能上的問題；如果聽到一半發現需要轉接到B，那麼你要麼指望A把所有內容完整無誤的傳遞到 B，要麼只好自己再重述一遍。這樣，你自己、A、B 的工作都會變得相當複雜，而且容易出錯。你要是打過客服電話的話應該有切身體會。

服務端有狀態的話，伺服器的內存開銷會大很多很多，開發複雜度也難很多。此外也和4層的長短連接的選擇，產生一定耦合。

所以，還是讓客戶端去負責保存狀態吧（持有cookie這些）。

這個問題嘛，你要考慮的是歷史原因。

首先 http這個玩意兒，我們現在用的是http是19xx年搞出來的產物。我靠，大哥我跟你說，1999年那個時代是怎麼樣的：

馬雲創立黃網...不是，黃頁有了點成績，開始搞阿里巴巴
馬化騰在玩泥巴...不是，在玩代碼
中國，乃至世界互聯網都是蠻荒地區

問題就來了，科學家們想：http協議需要狀態嗎？

需要：需要來幹嘛呢？當時可能連用戶的概念都沒有，沒有存在什麼登陸不登陸，所有的頁面也就是一個簡單的圖片+文字而已。
不需要：早點下班可以回家和老婆玩了。

於是，不要懷疑，科學家也是人，也是需要玩老婆的，玩兒子的，所以考慮當時的互聯網那副鬼樣子，乾脆就為了早點下班回家，不設計有狀態就好了。

大部分人沒想到的是，互聯網幾年之內，爆發性的增長，那怎麼辦吶，把http重新設計？全世界都要炸了，你這改動會導致全世界都加班加點....，解決辦法就是Hack唄，沒狀態是吧，給你加個cookie之類的，行了吧？

所以啊，很多時候編程上的這類問題，明明這樣好，但是為什麼不這麼設計的原因就是：

用戶量太小
應用太簡單
用戶量太小應用太簡單，又設計那麼複雜，工作人員就不用下班了
只有弄得搓一點，下個版本升級的時候才好寫：「這個版本迎來全面的性能升級，殺了個程序員祭天..."

因為早期Web很簡單，都是一些簡單的靜態HTML的頁面，主要是瀏覽的功能。因此根本不需要狀態，反正都是瀏覽頁面而已，誰瀏覽不是瀏覽，何必去記住是誰來訪問的。但是隨著互聯網的發展，web網站越來越複雜，出現了像電商這種網站的需求，簡單的無狀態無法滿足，於是才出現了cookie來補充http協議，滿足記錄用戶狀態的需求。最後，你明白了web的發展歷史你就明白為什麼http最開始是無狀態的。