無狀態協議和有狀態協議

Question

如何理解無狀態協議和有狀態協議？ HTTP是一種無狀態協議，FTP是一種有狀態協議。對於需要大量交互的Web應用程序，基礎協議應該是有狀態的。我的理解是正確的嗎？

Answer 1

由於您在詢問Web應用程序，因此該協議將始終爲無狀態 - Web協議爲http（或https），這就是她寫的全部內容。

我想你在想什麼是在你的Web應用程序本身提供一個狀態機制。典型的方法是在Web應用程序中爲用戶的會話創建一個唯一的標識符（一種或另一種形式的會話ID是常用的），它在瀏覽器和服務器之間來回切換。這通常是在一個cookie中完成的，儘管它可以完成，根據你的平臺/框架，在URL上也有一些麻煩。

您的服務器端代碼存儲有狀態信息（再次，通常稱爲用戶的會話），但它希望使用sessionID來查找它。 http流量只是回傳sessionID。只要該標識符存在，每個http事務就完全獨立於所有其他事務，因此協議流量本身是無狀態的。

Answer 2

基本上可以，但是你別無選擇，只能使用HTTP服務於其中的網站。因此，你必須處理妥協以實現HTTP有狀態，即會話管理。可能性基本上是通過URL中的每個呼叫傳遞一個會話ID，以便您知道何時與您之前討論過的人聊天，或通過實現相同目標而不會混亂網址的Cookie。但是，大多數現代Web開發語言都會爲您提供幫助;如果你的谷歌選擇的語言+「會話管理」，你應該瞭解它是如何完成的。

Answer 3

HTTP是一種無狀態協議，換句話說，服務器將會忘記與客戶端/瀏覽器狀態相關的所有內容。儘管Web應用程序使它看起來像有狀態。

可以強制無狀態協議表現得好像它是有狀態的一樣。如果服務器將狀態發送給客戶端，並且客戶端每次都將其發送回服務器，則可以完成此操作。

有三種方法，這可能在HTTP來完成：

a）一個是Cookie，在這種情況下，狀態發送和HTTP標頭中返回。

b）第二個是URL擴展，在這種情況下，狀態作爲URL的一部分作爲響應發送。

c）第三個是「隱藏的表單字段」，其中狀態被髮送到客戶端作爲響應的一部分，並且返回到服務器高可用性表單的隱藏數據的一部分

可擴展性和

HTTP變得如此之好的主要原因之一是其無狀態。無狀態協議簡化了複製問題，因爲狀態本身不需要存儲在服務器上。

有狀態協議在邏輯上很重，可以可靠地在Internet中實現。無狀態服務器也很容易擴展，而對於有狀態服務器來說，可伸縮性是有問題的。無狀態請求可以隨時發送到任何節點，而Stateful則不是這種情況。

HTTP作爲無狀態協議增加了無狀態Web應用程序的可用性，否則這些應用程序很難或不可能實現。如果有連接丟失，沒有丟失的狀態，簡單的請求重新發送將解決問題。無狀態請求也是可緩存的。

see more here

Answer 4

HTTP是一個無protocol.all基於Web的應用程序是無狀態的。當向服務器發送請求時，客戶端和服務器之間建立連接時，服務器將收到請求，處理該請求並返回響應，並關閉連接。如果發送了另一個請求，那麼它將被視爲新的請求，並建立新的連接。 爲了使http有狀態。我們使用會話管理技術。 ，以便它在處理當前request.i.e時使用來自先前請求的數據，例如，它爲一系列客戶端服務器交互使用相同的連接。 會話管理技術爲： 1.隱式表單域 2.cookie 3.session 4.url-rewriting;

Answer 5

你的問題是現貨，是的，如果你的銀行網絡交易是通過有狀態連接完成的，那將是非常好的。唉，由於FTP中存在一個奇怪的錯誤，並且在BSD的部分套接字表中有12個套接字的限制，所以HTTP是無狀態的。Marcus Ranum解釋了這一切。here。

因此，HTTP拋棄了它從TCP繼承的狀態，並且必須以cookie的形式在應用程序層重新創建狀態。結果是糟糕的互聯網安全。

該Seif project建議修復所有使用「安全的JSON over TCP」。 DNS和證書頒發機構不是必需的。該協議和seifnode.js已完成，並在Github上獲得了MIT許可證。

Answer 6

HTTP不會從TCP「繼承」，而是將其用於傳輸。 HTTP使用TCP進行有狀態連接，但會斷開連接。稍後，如果需要，它將再次連接。所以，當你瀏覽一個網站時，你創建了許多不同的連接。這些連接中的每一個都是有狀態的，但整個對話不是，因爲你正在放棄與每個對話的連接。

From this link