HTTP 無狀態中的 "狀態" 到底指的是什么？
引子：
最近在好好了解http，發現對介紹http的第一句話【http協議是無狀態的，無連接的】就無法理解了：無狀態的【狀態】到底指的是什么?!
找了很多資料不僅沒有發現有一針見血正面回答這個問題的，而且有些解釋還充斥了各種錯誤，看著看著就覺得心里憋著一股濁氣吐不出來
于是在看了很多資料之后，我一口吐出濁氣，大聲正面提出這個問題：http協議無狀態中的【狀態】到底指的是什么?!
然后開始不斷探索解決這個問題。。。
最終很高興的是我找到了讓人滿意的答案，先賣個關子，各位如果著急可以直接拉到最下查看
正文：
http協議無狀態中的【狀態】到底指的是什么?!
先來看這句話的另外兩個概念：(標準的http協議是無狀態的，無連接的)
- 標準的http協議指的是不包括cookies, session，application的http協議，他們都不屬于標準協議，雖然各種網絡應用提供商，實現語言、web容器等，都默認支持它
- 無連接指的是什么 每一個訪問都是無連接，服務器挨個處理訪問隊列里的訪問，處理完一個就關閉連接，這事兒就完了，然后處理下一個新的 無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接
對于【無狀態】，我看到很多隔著一層磨砂玻璃一樣的模糊說法(官方或者教程里的說法)，看著非常難受(但其實算是對的)
后來我發現我為什么覺得它看著難受了，因為他們引入了很多新的，而且明顯是一個可能用在很多地方的廣義名詞，這些詞最大的作用就是，混淆概念，下面我標注了
- 協議對于事務處理沒有記憶能力【事物處理】【記憶能力】
- 對同一個url請求沒有上下文關系【上下文關系】
- 每次的請求都是獨立的，它的執行情況和結果與前面的請求和之后的請求是無直接關系的，它不會受前面的請求應答情況直接影響，也不會直接影響后面的請求應答情況【無直接聯系】【受直接影響】
- 服務器中沒有保存客戶端的狀態，客戶端必須每次帶上自己的狀態去請求服務器【狀態】
我必須得到確切而具體的解釋!
這幾點給了我下一步思考的方向：
【服務器中沒有保存客戶端的狀態，客戶端必須每次帶上自己的狀態去請求服務器 】這里的客戶端的狀態是不是確切地指服務器沒有保存客戶的信息呢?但顯然不是啊
【HTTP無狀態的特性嚴重阻礙了這些應用程序的實現，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在之前選擇了什么商品】我對此質疑為什么無狀態就不能實現購物車呢?服務器就不能存儲東西了么?
【 每次的請求都是獨立的，<它的執行情況和結果>與<前面的請求>和<之后的請求>是無直接關系的】我覺得這個說法比較靠譜，但是所謂的不同請求間的沒有關系，是指的請求內容沒有關系，還是只是指請求本身沒有關系? 請求內容沒有關系只可能是服務器上不存有用戶數據才可能啊，但是顯然是存有的啊 請求本身沒有關系，這又有什么意義呢，每一次的請求有什么價值?
根據這個方向我做了一個模擬訪問實驗：假如沒有cookie沒有session，只有http的時候，那當一個注冊用戶訪問這個購物網站的時候，會發生這些事情：
前提情況：
服務器肯定為每個注冊用戶建立了數據表，記錄用戶的數據 http是無連接的
第一步需要登錄 用戶通過http把用戶的用戶名和密碼發送給服務器，服務器把他們跟自己存有的用戶資料對比，如果一致，則返回信息登錄成功
然后用戶點擊某一商品頁
- 這個動作相當于輸入一個商品頁的網址
- 假如商品頁比較機密不對外公開，需要是用戶才能訪問
- 而雖然http能傳送用戶名和密碼，而且剛才也輸入了，還驗證成功了，但是因為服務器既不會記得你登錄的狀態，你的客戶端也不會存儲你剛才輸入的用戶名和密碼
- 所以因為這一次訪問因為無法確定你的身份，只能訪問失敗 這時候如果要解決這個問題，而且沒有cookie沒有session，那就只能你在訪問網址的同時繼續帶上你的用戶名和密碼(繼續輸入咯)其實就像我現在的APP一樣
假設上一步的問題解決了，就是每次訪問的時候都會手動輸入用戶名和密碼，然后現在的情況是：你已經選了幾件商品在你的購物車中，你想再添加一件商品，于是你點擊某個商品旁邊的加號
這個動作也相當于輸入一個網址，網址的內容是發送一個請求，往你的購物車中加入這個商品
系統首先用你傳來的用戶名和密碼驗證你的身份，然后訪問你的數據庫，在其中的購物車屬性下加一條數據，就是這個商品的數據
操作結束后，返回操作成功，并結束訪問
OK，實驗結束，看似沒有cookie沒有session也能湊合解決問題，其實兩個操作都有很大的問題
- 你每訪問一次需要權限的內容都需要在客戶端輸入用戶名和密碼，這一項的繁瑣就不必贅述了
- 你的每一次操作都要與系統底層的數據庫進行交互 多次少量的訪問存在非常大的性能浪費。非常容易就能想到肯定是一次大量的操作更加有效率，于是就想到了緩存區
- 你的非重要瑣碎數據也被寫進數據庫中，跟你的主要數據放在一起 一次次添加和刪除購物車其實只是跟你這次瀏覽，或者叫這次會話有關，是臨時的數據，跟用戶的主要信息無關，它們沒什么價值，純粹的冗余數據(不排除現在有的公司覺得這種數據也有非常大的價值可以讓它們巧妙的利用)，用什么存放這些臨時的數據，我們也很容易想到緩存區
經過這個模擬訪問實驗，結合前面的思考方向，我們知道了三點：
服務器上肯定存有用戶的數據，你提交的增刪改查它也能夠處理，所以這句話中【服務器中沒有保存客戶端的狀態】的狀態并不是指用戶的數據，我們的猜測不對
我們的質疑對了，無狀態能實現購物車，可以通過服務器上存有的用戶數據來實現
但是，使用上面這種方式實現購物車，存在三個比較大的問題。由此，我們不禁會想，這三個問題的解決是不是跟我們不確切了解的【狀態】一詞有關?于是，接下來我們來通過解決這三個問題來把【狀態】的意義探尋下去
由上所述，我們可以在http的基礎上增加一些機制來解決上面出現的三個問題
- 在用戶端增加一個記錄本是非常有必要的，正好官方加入的cookie機制跟這個一樣，它的用處也確實是上面討論的那樣，一般就是用來標識訪問者的身份
- 在服務器增加一個緩存區能同時解決后兩個問題 有了這個緩存區作為一個數據緩沖，就不用一次次地訪問數據庫，浪費大量計算機資源，而是在最后統一歸入數據庫 有了這個緩存區，你就不用把臨時的數據放到數據庫中了，只需要在你們交流告一段落之后，再把數據整理，把有用的數據歸入數據庫
- 這里就自然引申出了一個重要的概念：會話，它作為一個緩沖存儲區被從數據庫中分離出來，理由并不生硬，它有其獨特的重要且不可替代的作用。這個東西恰好跟官方加入的session機制一樣
另外說一個非常具有迷惑性的容易讓人對session的主要作用產生偏離的理解：認為session存在的價值就是給訪問者分配一個sessionID代替用戶名和密碼
為什么非常具有迷惑性，因為session確實做了這件事，而且也起到了很大的作用，所以它是對的，但是只對一半，而且沒有涉及問題的本質，這種情況是最危險的(看似很有說服力，把你說服了，所以你很難有動力繼續找下去，但是真實情況跟它有偏差，但是偏差不大，所以又很難把你說服回來，只有隱隱的不對勁，這個時候你離真實最近，也離真實最遠)
那就順便說說它為什么是對的，也就是用session做的另一件有用的事：
給每個session一個ID，一方面用來方便自己查詢，另一方面把這個ID給用戶，用戶下一次訪問的時候就可以不用用戶名和密碼，而是直接使用這個ID來表明自己的身份
首先，這個ID安全嗎?這個ID比直接傳用戶名和密碼安全嗎?
你很容易會想到，本來用戶名和密碼的組合還特地設置地比較復雜，你這換一組數字就代替了，是不是太不安全了? 我們知道http協議本身是完全不加密的，如果使用用戶名和密碼，第一次訪問是放在http頭中，后邊自動保存了密碼就會放在cookie中，這些都完全沒有加密，它的安全性基本為0，就是裸奔了，只要被竊取，那就丟失了 所以，就這個意義來講，sessionID的安全性跟使用用戶名和密碼沒什么區別 但是其實，雖然http本身不能加密，但是有些軟件什么的，能在應用層面手動給你加密，比如QQ就會使用戶名密碼加臨時驗證碼聯合哈希，sessionID加一個時間戳簡單加密也是非常常用的方法 而且因為sessionID本身有有效期，即使丟了，也可能很快失效，造成的損失可能沒那么大，而用戶名跟密碼丟了，那就大了 所以總結就是：不嚴格加密的sessionID和用戶名和密碼一樣，都不太安全;但是相比較來說，sessionID要安全一些;而使用https是完全安全的
然后，使用sessionID有哪些好處? 方便直接根據ID查詢用戶對應的session 加密的時候計算量小 安全性不會降低，甚至還更高一些
OK，通過獨立地解決純http機制會產生的問題，我們探討了cookie和session機制的本質。
而且想到：【使用http協議，服務器中不會保存客戶端的狀態】所產生的問題通過增加cookie和session機制解決了，是不是就意味著這個【狀態】跟cookie和session的關系非常緊密?
所以這個無狀態指的是【沒有對 本次會話 設置一個緩存區，記錄這次會話的狀態，緩存區包括服務器端和用戶端】但好像還是沒有點破關鍵(主要是覺得跟前面那些官方對狀態的說法不太吻合，甚至沒有對應關系)
忽然我想到一個問題：一個有狀態的http是什么樣的?
很難直接想象有狀態的http是什么樣，因為http這種機制是天然無狀態的
那就類比一下吧，另一個天然有狀態的機制叫TCP
如果有狀態的意思是它的每次請求是有聯系的，那么有狀態的TCP的樣子是：假如一份數據分了三份TCP包發送，那這個包上面會標明這是第幾個包，會標明這個包跟那幾個包是有聯系的，有什么聯系
但好像這個有狀態的TCP跟我們想要的有狀態的HTTP沒有關系，因為即使每次http請求之間互相有聯系，它也不能解決上面提到的http無狀態的問題
誒，等等，好像能類比：
假如每個http連接都有一個簽名，于是第一次登陸成功之后，服務器就知道了這個簽名是允許登陸的，于是之后所有同樣簽名的http連接都能登陸，這里利用了同一個用戶發出的http連接之間的同主人關系，這里解決了一個保持登錄狀態的問題
同樣，來嘗試利用這個【每次http請求之間互相有聯系】來解決上面碰到的那個問題【每一次操作都要與系統底層的數據庫進行交互】，但想了半天確實無法進行下去
不過我靈機一動，從另一個角度來想，好像解決了這個問題：
- 只有【每次http請求之間互相有聯系】這個條件，無法解決【每一次操作都要與系統底層的數據庫進行交互】
- 因為很明顯，要解決【每一次操作都要與系統底層的數據庫進行交互】就必須在服務器端開辟一塊緩存區
- 不過如果你思考一下如何實現【每次http請求之間互相有聯系】，你就會發現，它也需要在服務器端開辟一塊緩存區
- 所以【在服務器端開辟一塊緩存區】才是真正的條件，也就是說，它確實等價于【有狀態】
- 而且我也找到了這個【在服務器端開辟一塊緩存區】的條件跟前面那些官方對狀態的說法對應的點，那就是：
- 通過在服務器端開辟一塊緩存區，存儲、記憶、共享一些臨時數據，你就可以：
協議對于事務處理有記憶能力【事物處理】【記憶能力】
對同一個url請求有上下文關系【上下文關系】
每次的請求都是不獨立的，它的執行情況和結果與前面的請求和之后的請求是直接關系的【不獨立】【直接關系】
服務器中保存客戶端的狀態【狀態】
所以，這個狀態，加上前面說的客戶端也有cookie，就是指，客戶端和服務器在臨時會話中產生的數據!而前面也說道了，使用緩存區保存臨時會話中的數據是多么重要
所以狀態不僅包括不同URL訪問之間的關系，還有對其他URL訪問的數據記錄，還有一些其他的東西，所以更確切地說，狀態應該是【實現了這些東西所憑借的后面的緩存空間】中的客戶的臨時數據
cookie和session應該是完全實現了有狀態這個功能
一種常見的對狀態的誤解：
- 有人在解釋HTTP的無狀態時，把它跟有連接對立，說是兩種方式，也就是如果想不無狀態，就必須有連接，但其實不然
- 有連接和無連接以及之后的Keep-Alive都是指TCP連接
- 有狀態和無狀態可以指TCP也可以指HTTP
- TCP一直有狀態，HTTP一直無狀態，但是應用為了有狀態，就給HTTP加了cookie和session機制，讓使用http的應用也能有狀態，但http還是無狀態
- 開始TCP是有連接，后來TCP無連接，再后來也就是現在TCP是Keep-Alive，有點像有連接
