您好,登錄后才能下訂單哦!
這篇文章主要介紹“http協(xié)議無狀態(tài)中的 "狀態(tài)" 指的是什么”,在日常操作中,相信很多人在http協(xié)議無狀態(tài)中的 "狀態(tài)" 指的是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”http協(xié)議無狀態(tài)中的 "狀態(tài)" 指的是什么”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
http協(xié)議無狀態(tài)中的【狀態(tài)】到底指的是什么?!
1.先來看這句話的另外兩個概念:(標準的http協(xié)議是無狀態(tài)的,無連接的) 標準的http協(xié)議指的是不包括cookies, session,application的http協(xié)議,他們都不屬于標準協(xié)議,雖然各種網絡應用提供商,實現(xiàn)語言、web容器等,都默認支持它
無連接指的是什么
每一個訪問都是無連接,服務器挨個處理訪問隊列里的訪問,處理完一個就關閉連接,這事兒就完了,然后處理下一個新的
無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求,并收到客戶的應答后,即斷開連接
對于【無狀態(tài)】,我看到很多隔著一層磨砂玻璃一樣的模糊說法(官方或者教程里的說法),看著非常難受(但其實算是對的)(后來我發(fā)現(xiàn)我為什么覺得它看著難受了,因為他們引入了很多新的,而且明顯是一個可能用在很多地方的廣義名詞,這些詞最大的作用就是,混淆概念,下面我標注了)
協(xié)議對于事務處理沒有記憶能力【事物處理】【記憶能力】
對同一個url請求沒有上下文關系【上下文關系】
每次的請求都是獨立的,它的執(zhí)行情況和結果與前面的請求和之后的請求是無直接關系的,它不會受前面的請求應答情況直接影響,也不會直接影響后面的請求應答情況【無直接聯(lián)系】【受直接影響】
服務器中沒有保存客戶端的狀態(tài),客戶端必須每次帶上自己的狀態(tài)去請求服務器【狀態(tài)】
我必須得到確切而具體的解釋!
這幾點給了我下一步思考的方向:
1.【服務器中沒有保存客戶端的狀態(tài),客戶端必須每次帶上自己的狀態(tài)去請求服務器 】這里的客戶端的狀態(tài)是不是確切地指服務器沒有保存客戶的信息呢?但顯然不是啊
2.【HTTP無狀態(tài)的特性嚴重阻礙了這些應用程序的實現(xiàn),畢竟交互是需要承前啟后的,簡單的購物車程序也要知道用戶到底在之前選擇了什么商品】我對此質疑為什么無狀態(tài)就不能實現(xiàn)購物車呢?服務器就不能存儲東西了么?
3.【 每次的請求都是獨立的,<它的執(zhí)行情況和結果>與<前面的請求>和<之后的請求>是無直接關系的】我覺得這個說法比較靠譜,但是所謂的不同請求間的沒有關系,是指的請求內容沒有關系,還是只是指請求本身沒有關系?
請求內容沒有關系只可能是服務器上不存有用戶數(shù)據(jù)才可能啊,但是顯然是存有的啊
請求本身沒有關系,這又有什么意義呢,每一次的請求有什么價值?
根據(jù)這個方向我做了一個模擬訪問實驗:假如沒有cookie沒有session,只有http的時候,那當一個注冊用戶訪問這個購物網站的時候,會發(fā)生這些事情:
1.前提情況:
服務器肯定為每個注冊用戶建立了數(shù)據(jù)表,記錄用戶的數(shù)據(jù)
http是無連接的
2.第一步需要登錄
用戶通過http把用戶的用戶名和密碼發(fā)送給服務器,服務器把他們跟自己存有的用戶資料對比,如果一致,則返回信息登錄成功
3.然后用戶點擊某一商品頁
這個動作相當于輸入一個商品頁的網址
假如商品頁比較機密不對外公開,需要是用戶才能訪問
而雖然http能傳送用戶名和密碼,而且剛才也輸入了,還驗證成功了,但是因為服務器既不會記得你登錄的狀態(tài),你的客戶端也不會存儲你剛才輸入的用戶名和密碼
所以因為這一次訪問因為無法確定你的身份,只能訪問失敗
這時候如果要解決這個問題,而且沒有cookie沒有session,那就只能你在訪問網址的同時繼續(xù)帶上你的用戶名和密碼(繼續(xù)輸入咯)其實就像我現(xiàn)在的APP一樣
4.假設上一步的問題解決了,就是每次訪問的時候都會手動輸入用戶名和密碼,然后現(xiàn)在的情況是:你已經選了幾件商品在你的購物車中,你想再添加一件商品,于是你點擊某個商品旁邊的加號
這個動作也相當于輸入一個網址,網址的內容是發(fā)送一個請求,往你的購物車中加入這個商品
系統(tǒng)首先用你傳來的用戶名和密碼驗證你的身份,然后訪問你的數(shù)據(jù)庫,在其中的購物車屬性下加一條數(shù)據(jù),就是這個商品的數(shù)據(jù)
操作結束后,返回操作成功,并結束訪問
5.OK,實驗結束,看似沒有cookie沒有session也能湊合解決問題,其實兩個操作都有很大的問題
你每訪問一次需要權限的內容都需要在客戶端輸入用戶名和密碼,這一項的繁瑣就不必贅述了
你的每一次操作都要與系統(tǒng)底層的數(shù)據(jù)庫進行交互
多次少量的訪問存在非常大的性能浪費。非常容易就能想到肯定是一次大量的操作更加有效率,于是就想到了緩存區(qū)
你的非重要瑣碎數(shù)據(jù)也被寫進數(shù)據(jù)庫中,跟你的主要數(shù)據(jù)放在一起
一次次添加和刪除購物車其實只是跟你這次瀏覽,或者叫這次會話有關,是臨時的數(shù)據(jù),跟用戶的主要信息無關,它們沒什么價值,純粹的冗余數(shù)據(jù)(不排除現(xiàn)在有的公司覺得這種數(shù)據(jù)也有非常大的價值可以讓它們巧妙的利用),用什么存放這些臨時的數(shù)據(jù),我們也很容易想到緩存區(qū)
搜索Java知音公眾號,回復“后端面試”,送你一份Java面試題寶典
經過這個模擬訪問實驗,結合前面的思考方向,我們知道了三點:
服務器上肯定存有用戶的數(shù)據(jù),你提交的增刪改查它也能夠處理,所以這句話中【服務器中沒有保存客戶端的狀態(tài)】的狀態(tài)并不是指用戶的數(shù)據(jù),我們的猜測不對
我們的質疑對了,無狀態(tài)能實現(xiàn)購物車,可以通過服務器上存有的用戶數(shù)據(jù)來實現(xiàn)
但是,使用上面這種方式實現(xiàn)購物車,存在三個比較大的問題。由此,我們不禁會想,這三個問題的解決是不是跟我們不確切了解的【狀態(tài)】一詞有關?于是,接下來我們來通過解決這三個問題來把【狀態(tài)】的意義探尋下去
由上所述,我們可以在http的基礎上增加一些機制來解決上面出現(xiàn)的三個問題
1.在用戶端增加一個記錄本是非常有必要的,正好官方加入的cookie機制跟這個一樣,它的用處也確實是上面討論的那樣,一般就是用來標識訪問者的身份
2.在服務器增加一個緩存區(qū)能同時解決后兩個問題
有了這個緩存區(qū)作為一個數(shù)據(jù)緩沖,就不用一次次地訪問數(shù)據(jù)庫,浪費大量計算機資源,而是在最后統(tǒng)一歸入數(shù)據(jù)庫
有了這個緩存區(qū),你就不用把臨時的數(shù)據(jù)放到數(shù)據(jù)庫中了,只需要在你們交流告一段落之后,再把數(shù)據(jù)整理,把有用的數(shù)據(jù)歸入數(shù)據(jù)庫
3.這里就自然引申出了一個重要的概念:會話,它作為一個緩沖存儲區(qū)被從數(shù)據(jù)庫中分離出來,理由并不生硬,它有其獨特的重要且不可替代的作用。這個東西恰好跟官方加入的session機制一樣
3.1.另外說一個非常具有迷惑性的容易讓人對session的主要作用產生偏離的理解:認為session存在的價值就是給訪問者分配一個sessionID代替用戶名和密碼,
3.2.為什么非常具有迷惑性,因為session確實做了這件事,而且也起到了很大的作用,所以它是對的,但是只對一半,而且沒有涉及問題的本質,這種情況是最危險的(看似很有說服力,把你說服了,所以你很難有動力繼續(xù)找下去,但是真實情況跟它有偏差,但是偏差不大,所以又很難把你說服回來,只有隱隱的不對勁,這個時候你離真實最近,也離真實最遠)
3.3.那就順便說說它為什么是對的,也就是用session做的另一件有用的事:
給每個session一個ID,一方面用來方便自己查詢,另一方面把這個ID給用戶,用戶下一次訪問的時候就可以不用用戶名和密碼,而是直接使用這個ID來表明自己的身份
首先,這個ID安全嗎?這個ID比直接傳用戶名和密碼安全嗎?
不嚴格加密的sessionID和用戶名和密碼一樣,都不太安全
但是相比較來說,sessionID要安全一些
而使用https是完全安全的
1. 你很容易會想到,本來用戶名和密碼的組合還特地設置地比較復雜,你這換一組數(shù)字就代替了,是不是太不安全了?
2. 我們知道http協(xié)議本身是完全不加密的,如果使用用戶名和密碼,第一次訪問是放在http頭中,后邊自動保存了密碼就會放在cookie中,這些都完全沒有加密,它的安全性基本為0,就是裸奔了,只要被竊取,那就丟失了
3. 所以,就這個意義來講,sessionID的安全性跟使用用戶名和密碼沒什么區(qū)別
4. 但是其實,雖然http本身不能加密,但是有些軟件什么的,能在應用層面手動給你加密,比如QQ就會使用戶名密碼加臨時驗證碼聯(lián)合哈希,sessionID加一個時間戳簡單加密也是非常常用的方法
5. 而且因為sessionID本身有有效期,即使丟了,也可能很快失效,造成的損失可能沒那么大,而用戶名跟密碼丟了,那就大了
6. 所以總結就是:
然后,使用sessionID有哪些好處
1. 方便直接根據(jù)ID查詢用戶對應的session
2. 加密的時候計算量小
3. 安全性不會降低,甚至還更高一些
OK,通過獨立地解決純http機制會產生的問題,我們探討了cookie和session機制的本質。而且想到:【使用http協(xié)議,服務器中不會保存客戶端的狀態(tài)】所產生的問題通過增加cookie和session機制解決了,是不是就意味著這個【狀態(tài)】跟cookie和session的關系非常緊密?
所以這個無狀態(tài)指的是【沒有對 本次會話 設置一個緩存區(qū),記錄這次會話的狀態(tài),緩存區(qū)包括服務器端和用戶端】但好像還是沒有點破關鍵(主要是覺得跟前面那些官方對狀態(tài)的說法不太吻合,甚至沒有對應關系)
搜索Java知音公眾號,回復“后端面試”,送你一份Java面試題寶典
忽然我想到一個問題:一個有狀態(tài)的http是什么樣的?
1.很難直接想象有狀態(tài)的http是什么樣,因為http這種機制是天然無狀態(tài)的
2.那就類比一下吧,另一個天然有狀態(tài)的機制叫TCP
如果有狀態(tài)的意思是它的每次請求是有聯(lián)系的,那么有狀態(tài)的TCP的樣子是:假如一份數(shù)據(jù)分了三份TCP包發(fā)送,那這個包上面會標明這是第幾個包,會標明這個包跟那幾個包是有聯(lián)系的,有什么聯(lián)系
3.但好像這個有狀態(tài)的TCP跟我們想要的有狀態(tài)的HTTP沒有關系,因為即使每次http請求之間互相有聯(lián)系,它也不能解決上面提到的http無狀態(tài)的問題
4.誒,等等,好像能類比:
4.1.假如每個http連接都有一個簽名,于是第一次登陸成功之后,服務器就知道了這個簽名是允許登陸的,于是之后所有同樣簽名的http連接都能登陸,這里利用了同一個用戶發(fā)出的http連接之間的同主人關系,這里解決了一個保持登錄狀態(tài)的問題
4.2.同樣,來嘗試利用這個【每次http請求之間互相有聯(lián)系】來解決上面碰到的那個問題【每一次操作都要與系統(tǒng)底層的數(shù)據(jù)庫進行交互】,但想了半天確實無法進行下去。往期:一百期面試題匯總
4.3.不過我靈機一動,從另一個角度來想,好像解決了這個問題:
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)
只有【每次http請求之間互相有聯(lián)系】這個條件,無法解決【每一次操作都要與系統(tǒng)底層的數(shù)據(jù)庫進行交互】
因為很明顯,要解決【每一次操作都要與系統(tǒng)底層的數(shù)據(jù)庫進行交互】就必須在服務器端開辟一塊緩存區(qū)
不過如果你思考一下如何實現(xiàn)【每次http請求之間互相有聯(lián)系】,你就會發(fā)現(xiàn),它也需要在服務器端開辟一塊緩存區(qū)
所以【在服務器端開辟一塊緩存區(qū)】才是真正的條件,也就是說,它確實等價于【有狀態(tài)】
而且我也找到了這個【在服務器端開辟一塊緩存區(qū)】的條件跟前面那些官方對狀態(tài)的說法對應的點,那就是:
通過在服務器端開辟一塊緩存區(qū),存儲、記憶、共享一些臨時數(shù)據(jù),你就可以:
協(xié)議對于事務處理有記憶能力【事物處理】【記憶能力】
對同一個url請求有上下文關系【上下文關系】
每次的請求都是不獨立的,它的執(zhí)行情況和結果與前面的請求和之后的請求是直接關系的【不獨立】【直接關系】
服務器中保存客戶端的狀態(tài)【狀態(tài)】
6. 所以,這個狀態(tài),加上前面說的客戶端也有cookie,就是指,客戶端和服務器在臨時會話中產生的數(shù)據(jù)!而前面也說道了,使用緩存區(qū)保存臨時會話中的數(shù)據(jù)是多么重要
所以狀態(tài)不僅包括不同URL訪問之間的關系,還有對其他URL訪問的數(shù)據(jù)記錄,還有一些其他的東西,所以更確切地說,狀態(tài)應該是【實現(xiàn)了這些東西所憑借的后面的緩存空間】中的客戶的臨時數(shù)據(jù)
cookie和session應該是完全實現(xiàn)了有狀態(tài)這個功能
一種常見的對狀態(tài)的誤解:
有人在解釋HTTP的無狀態(tài)時,把它跟有連接對立,說是兩種方式,也就是如果想不無狀態(tài),就必須有連接,但其實不然
有連接和無連接以及之后的Keep-Alive都是指TCP連接
有狀態(tài)和無狀態(tài)可以指TCP也可以指HTTP
TCP一直有狀態(tài),HTTP一直無狀態(tài),但是應用為了有狀態(tài),就給HTTP加了cookie和session機制,讓使用http的應用也能有狀態(tài),但http還是無狀態(tài)
開始TCP是有連接,后來TCP無連接,再后來也就是現(xiàn)在TCP是Keep-Alive,有點像有連接
到此,關于“http協(xié)議無狀態(tài)中的 "狀態(tài)" 指的是什么”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續(xù)學習更多相關知識,請繼續(xù)關注億速云網站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經查實,將立刻刪除涉嫌侵權內容。