Ⅰ http協議無狀態是什麼意思讓web應用有狀態的機制
http協議無狀態的意思如下：
1、協議對於事務處理沒有記憶能力【事物處理】【記憶能力】
2、對同一個url請求沒有上下文關系【上下文關系】
3、每次的請求都是獨立的，它的執行情況和結果與前面的請求和之後的請求是無直接關系的，它不會受前面的請求應答情況直接影響，也不會直接影響後面的請求應答情況【無直接聯系】【受直接影響】
4、伺服器中沒有保存客戶端的狀態，客戶端必須每次帶上自己的狀態去請求伺服器【狀態】
Web應用=http協議+session、cookies等狀態機制+其他輔助的機制。
其實，應用程序(軟體通信)的有狀態與否是一個非常通用的概念。我們可知，在網路協議中，我們稱TCP為一個有狀態的傳輸層通信協議，而UDP則不是；IP是無狀態的。
要明白這種有狀態與否的判定，是指你這一協議棧層次所要實現的功能——是否由上下文決定——來判定的（是否受之前的通信過程直接影響、是否直接影響之後的通信過程）。
(1)web的無狀態擴展閱讀
關於網路應用層次中的各層次的有無狀態情況。可以知道，支持協議（下層）的有無狀態，消費協議（上層）的有無狀態，沒有直接的關系。每層協議的有無狀態與它的本身功能執行的時候的有無狀態的特點有關。
（1）IP是無狀態的，它只負責將一個IP包發送到指定的IP地址上去。它不會考慮這個包與前面已經發送的包和後面的包的聯系。（可能是重發包、可能是不連續包，它不管）。
（2）TCP是有狀態的，它通過包頭中的一些控制欄位（序列編碼等）來表明各個包之間的關系（前後關系，重包與否等等）。所以，通過這個協議你可以做到一個可靠的傳輸。其實這里的面向連接其實就是「三次握手」。
三次握手，首先可以保證對方的存在，其次握手的所交換的內容是為將來進行有狀態的傳輸做准備。
（3）UDP是無狀態的，它僅僅是在IP上加了Port，其他的事情什麼也不幹。這樣它不可能做到可靠的傳輸，同樣也不需要連接。
（4）HTTP是無狀態的，它的底層協議是由狀態的TCP，但是HTTP的一次完整協議動作，裡面是使用有狀態的TCP協議來完成的。
而每次協議動作之間沒有任何關系。例如：第7次請求HTTP協議包，它或許是因為上次沒有請求成功而重傳，或許是上次的後續請求，或許是其他的，這些HTTP自身都不知道。
（5）www應用，很多時候，www應用是需要每個HTTP請求或應答動作之間是有關聯的，那就是使應用有狀態。這樣才能提供給用戶最好的用戶體驗。
Ⅱ http是一種無狀態的協議，在web應用中，採用什麼手段，知道兩次請求是同一用戶
因為HTTP是一種無狀態協議，所以引進了cookie和session.
要判斷兩次請求是否為同一用戶，可以在剛開始就將用戶名或id存入cookie或session
然後將兩次的請求用戶進行比較
Ⅲ Web窗體的Web 窗體頁幫助您完成哪些任務
Web 應用程序編程帶來了一些特殊的難題，在對傳統的基於客戶端的應用程序進行編程時，通常不會遇到這些難題。這些難題包括： 實現多樣式的 Web 用戶界面。對於布局復雜且包含大量動態內容和功能齊全的用戶交互對象的用戶界面而言，使用基本的 HTML 功能來進行設計和實現將會既困難又費事。其中尤為困難的是為可能在多個不同的瀏覽器和客戶端設備平台上運行的應用程序創建多樣式的用戶界面。 客戶端與伺服器的分離。在 Web 應用程序中，客戶端（瀏覽器）和伺服器是不同的程序，它們通常在不同的計算機上運行（甚至在不同的操作系統上運行）。因此，共同組成應用程序的這兩個部分僅共享很少的信息；它們可以進行通信，但通常只交換很小塊的簡單信息。 無狀態執行。當 Web 伺服器接收到對某頁的請求時，它會查找該頁，對其進行處理，將其發送到瀏覽器，然後丟棄所有頁信息。如果用戶再次請求同一頁，伺服器則會重復整個過程：從頭開始對該頁進行重新處理。換言之，伺服器不會記憶它已處理的頁。因此，如果應用程序需要維護有關某頁的信息，這就成為一個必須在應用程序代碼中解決的問題。 未知的客戶端功能。在許多情況下，Web 應用程序可由多個使用不同瀏覽器的用戶進行訪問。瀏覽器具有不同的功能，因此很難創建將在所有瀏覽器上都同樣正常運行的應用程序。 數據訪問方面的復雜性。對位於傳統 Web 應用程序的數據源進行讀取和寫入可能比較復雜，並且會消耗大量資源。 可縮放性方面的復雜性。在許多情況下，由於應用程序的不同組件之間缺乏兼容性，用現有方法設計的 Web 應用程序未能實現可縮放性的目標。對於發展周期較短的應用程序，這往往是唯一會導致失敗的地方。 若要解決這些 Web 應用程序的難題，可能需要大量的時間和精力。Web 窗體頁和 ASP.NET 頁框架通過以下幾個方面來處理這些難題： 直觀、一致的對象模型。ASP.NET 頁框架提供了一種對象模型，它使您能夠將窗體當作一個整體，而不是分離的客戶端和伺服器模塊。在此模型中，您可以通過比在傳統 Web 應用程序中更為直觀的方式來對窗體進行編程，其中包括能夠設置窗體元素的屬性和響應事件。此外，ASP.NET 伺服器控制項是基於 HTML 頁的物理內容以及瀏覽器與伺服器之間的直接交互的一種抽象模型。通常，您可以按照在客戶端應用程序中使用控制項的方式使用伺服器控制項，而不必考慮如何創建 HTML 來顯示和處理控制項及其內容。 事件驅動的編程模型。Web 窗體頁給 Web 應用程序帶來了一種您熟悉的事件處理程序編寫模型，用於為客戶端或伺服器上發生的事件編寫事件處理程序。ASP.NET 頁框架對此模型進行了抽象，使捕獲客戶端上的事件、將其傳輸到伺服器並調用適當方法等操作的基礎機制都是自動的，並對於實施者都是不可見的。這樣就得到了一個清晰的、易於編寫的、支持事件驅動開發的代碼結構。 直觀的狀態管理。ASP.NET 頁框架自動處理窗體及其控制項的狀態維護任務，它使您能夠以顯式方式維護應用程序特定信息的狀態。這種狀態管理無需使用大量伺服器資源即可實現，而且可以通過向瀏覽器發送 Cookie 來實現，也可以不通過向瀏覽器發送 Cookie 來實現。 獨立於瀏覽器的應用程序。ASP.NET 頁框架支持在伺服器上創建所有應用程序邏輯，使您無需為瀏覽器中的差異而進行顯式編碼。但是，它仍允許您自動利用瀏覽器特定的功能，方法是通過編寫客戶端代碼來提供增強的性能和更豐富的客戶端體驗。 .NET Framework 公共語言運行庫支持。ASP.NET 頁框架是 ASP.NET 的一項技術。ASP.NET 是基於 .NET Framework 生成的，因此整個框架都可用於任何 ASP.NET 應用程序。您可以使用任何與運行庫兼容的語言（包括 Microsoft Visual Basic、Visual C# 和 JScript .NET）來創作應用程序。此外，數據訪問通過 .NET Framework 提供的數據訪問基礎結構（包括 ADO.NET）得到了簡化。 .NET Framework 可縮放伺服器性能。ASP.NET 頁框架使您能夠將 Web 應用程序從一台只裝有一個處理器的計算機有效地縮放到多計算機「網路場」(Web farm)，而無需對應用程序的邏輯進行復雜的更改。
Ⅳ 什麼是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中的登錄信息即可。
我是 「翎野君」 ，感謝各位朋友的： 點贊 、 收藏 和 評論 ，我們下期見。
Ⅳ java web,由於Http協議是無狀態，採用如下的哪個方法保存客戶狀態的數據，沒有大小限制，而且性能表現最好
A.Session
session是通過操作瀏覽器cookie，生成隨機的cookie值（JSESSIONID）,然後回傳給服務端，服務端根據該cookie值找到對應保存在服務端的數據。
session的方式是結合cookie為一體的，如果客戶端不支持Cookie(客戶端禁用)，那就必須在訪問的URL後面傳遞SessionID來獲取保存在服務端的session值。
cookie不能說不安全，cookie如果保存在客戶端時，用可逆演算法加密後再保存在客戶端的話，也挺安全。但是，數據過多的話，導致每次都要把cookie回傳給伺服器，會影響效率。
urlrewrite只適合傳遞簡單的參數，而且有長度限制，更會引起安全問題（瀏覽器歷史記錄會完整的記錄訪問的URL）。
隱藏表單，同樣的，每次訪問需回傳給伺服器，造成速度緩慢（asp.net就喜歡這種方式）
4個選項當中安全性最高的是session，速度最快的也是session ,因為他要客戶端回傳的數據少