① 什麼是Http無狀態Session、Cookie、Token三者之間的區別
HTTP無狀態協議，是指協議對於交互性場景沒有記憶能力。
在點擊一個純的html網頁，請求獲取伺服器的html文件資源時，每次http請求都會返回同樣的信息，因為這個是沒有交互的，每一次的請求都是相互獨立的。第一個請求和第二個請求也沒有先後順序，返回處理哪個，結果都是同樣的資源頁面，因為這種場景是無交互的，無論是什麼人請求這個地址，伺服器都是返回那個相同的響應。
在無交互場景中上面那樣，當然也不會有太大的問題。但是對於涉及到動態交互的場景，就顯得很尷尬了，何為交互？有來又有往，對於一模一樣的兩個介面，不同的人在請求第二個介面時可能會基於請求第一個介面的結果而有所不同。
現在我們來想一個復雜的場景，如在購物網站上買一個書包，流程如下：
所謂的登錄只是驗證你是否是一個合法用戶，若是合法則跳轉到信息的頁面，不合法則告知用戶名密碼錯誤。
但是我們在第一步給伺服器發完/login介面後，伺服器就忘記了。。。忘記了你這個人，到底有沒有經過認證。
所以在添加商品時/cart 你還是需要將你的賬號密碼和商品信息一起提交給 addCart介面，再讓伺服器做驗證。
第三步同理。
所以當我們說涉及到交互時，情形就完全不一樣了，因為這三步是有依賴關系的，第一步驗證登錄者是一個合法用戶，驗證通過給你返回200/OK，但是只要伺服器給返回了響應，那麼一個http的請求和響應就結束了。伺服器怎麼知道10秒鍾之前你剛剛登錄過呢？不好意思，伺服器不知道你有沒有登陸過，他只是對外提供一個登錄介面，要想證明你是合法用戶必須調/login介面。
第二步，將商品加入到購物車中時，你會調用/cart介面，但是注意，這個行為是和第一步是有關聯關系的，是誰將什麼物品加入到購物車中了？這個誰，有沒有在網站上注冊賬號呢，是不是一個合法用戶呢？所以說在添加購物車的時候，我們還需要將賬號密碼再次加入到請求參數中，每做一次操作購物車操作時，都需要再把之前已經傳輸過的賬號密碼，再反反復復的傳輸一遍又一遍，這是因為伺服器不知道你是不是在20秒之前剛登陸過。
上面的無狀態是指的，無登錄狀態，即伺服器不知道某個用戶是否已登錄過了。因為愚蠢的伺服器不知道客戶端是否已登錄過了,所以每次都要在交互場景(會話)中請求中帶上上一次的請求信息，如賬號、密碼。明明只需要在/login介面中，才需要對比資料庫中的賬號密碼和客戶端傳的是否一致來確定合法性。這下在添加購物車中也需要再一次地進行同樣的重復且沒有必要的操作，即降低了響應速度，又對用戶不友好(因為每次都需要填賬號，密碼)。
缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另外人們常說的「會話」概念則是上面的交互行為的另一種表述方式。
通過上面我們知道了Http中無狀態是一個什麼概念，以及在無狀態情況下，要進行添加購物車功能，所帶來的困難。
客戶端與伺服器進行動態交互的Web應用程序出現之後，HTTP無狀態的特性嚴重阻礙了這些應用程序的實現，畢竟交互是需要承前啟後的，簡單的購物車程序也要知道用戶到底在之前選擇了什麼商品。於是，兩種用於保持HTTP連接狀態的技術就應運而生了，一個是Cookie，而另一個則是Session。HTTP本身是一個無狀態的連接協議，為了支持客戶端與伺服器之間的交互，我們就需要通過不同的技術為交互存儲狀態，而這些不同的技術就是Cookie和Session了。
由於HTTP是一種無狀態的協議，伺服器 單純從網路連接上 無從知道客戶身份。怎麼辦呢？就給客戶端們頒發一個通行證吧，每人一個，無論誰訪問都必須攜帶自己的通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是Cookie的工作原理。
Cookie實際上是一小段的文本信息。客戶端請求伺服器，如果伺服器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時， 瀏覽器把請求的網址連同該Cookie一同提交給伺服器 。伺服器檢查該Cookie，以此來辨認用戶狀態。伺服器還可以根據需要修改Cookie的內容。
很多網站都會使用Cookie。例如，Google會向客戶端頒發Cookie，Bai也會向客戶端頒發Cookie。那瀏覽器訪問Google會不會也攜帶上Bai頒發的Cookie呢？或者Google能不能修改Bai頒發的Cookie呢？
答案是否定的。Cookie具有不可跨域名性。根據Cookie規范，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Bai的Cookie。Google也只能操作Google的Cookie，而不能操作Bai的Cookie。
Cookie在客戶端是由瀏覽器來管理的。瀏覽器能夠保證Google只會操作Google的Cookie而不會操作Bai的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網站是否能操作另一個網站Cookie的依據是域名。Google與Bai的域名不一樣，因此Google不能操作Bai的Cookie。
1.在登錄網站的時候選擇記住密碼
2.點擊之後觀察伺服器上的相應內容
3.查看Chrome中的Cookie設置
4.觀察伺服器返回的Cookie內容
5.再次訪問時，發現不需要輸入密碼即可直接登錄，觀察請求頭信息
cookie並不是單純為了實現 session機制而生的。而是1993 年，網景公司雇員 Lou Montulli 為了讓用戶在訪問某網站時，進一步提高訪問速度，同時也為了進一步實現個人化網路，發明了今天廣泛使用的 Cookie。cookie還有一個很廣泛的用途就是記住用戶的登錄賬號和密碼，這樣當用戶以後再次需要登錄同一個網站或系統的時候就不需要再次填寫這兩個欄位而是直接點擊「登錄」按鈕就好。這就相當於給了一些「甜頭」給用戶，這就回應了「cookie」這個詞語的字面意思了。
實現方法是把登錄信息如賬號、密碼等保存在Cookie中，並控制Cookie的有效期，下次訪問時再驗證Cookie中的登錄信息即可。
我是 「翎野君」 ，感謝各位朋友的： 點贊 、 收藏 和 評論 ，我們下期見。
② web應用包括什麼
常見的計數器、留言版、聊天室和論壇BBS等，都是Web應用程序，不過這些應用相對比較簡單，而Web應用程序的真正核心主要是對資料庫進行處理，管理信息系統（Management Information System,簡稱MIS）就是這種架構最典型的應用。
一個Web應用程序是由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序是由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。
(2)無狀態類應用web擴展閱讀
web應用缺點
1、網路應用程序強調瀏覽器的適用性。如果瀏覽器方沒有提供特定的功能，或者棄用特定的平台或操作系統版本（導致不適用），就會影響大量用戶；
2、網路應用依靠互聯網遠程伺服器端的應用文件。因此，當連接出問題時，應用將不能正常使用。但是，如果使用HTML5 API，這些應用就可以被下載安裝而可離線使用。
3、許多網路應用程序不是開源的，只能依賴第三方提供的服務，因此不能針對用戶定製化、個性化，而且大多數情況下用戶不能離線使用，因而損失了很多靈活性；
4、它們完全依賴應用服務商的可及性。如果公司倒閉，伺服器停止使用，用戶也無法追索以前的資料。對比而看，即使軟體製造商倒閉了，傳統的安裝軟體也可以繼續運行，盡管不能再更新或有其他用戶服務。
③ http是一種無狀態的協議，在web應用中，採用什麼手段，知道兩次請求是同一用戶
因為HTTP是一種無狀態協議，所以引進了cookie和session.
要判斷兩次請求是否為同一用戶，可以在剛開始就將用戶名或id存入cookie或session
然後將兩次的請求用戶進行比較
④ web網頁是無狀態類應用
Web應用=http協議+session、cookies等狀態機制+其他輔助的機制。
直觀的說，「每次的請求都是獨立的，它的執行情況和結果與前面的請求和之後的請求是無直接關系的，它不會受前面的請求應答情況直接影響，也不會直接影響後面的請求應答情況」
要明白，這句話的含義是指在說明，http協議作為技術背景的web應用程序請求——應答模式是無狀態的，這個事實基本不會發生改變，也不會因為加入cookies、session機制而變成有狀態的。要明白，這種前後因果關系：「我們要實現的是一種web應用，實現這種應用的協議我們選擇了http這種本質上是無狀態的通信協議。但是事實上，我們需要我們的web應用是有狀態的。所以我們加入了cookies、session等機制去實現由狀態的web應用，