Webを実行するステートフルなプロトコルを使用できないのはなぜですか？

Question

私はHTTPのセッションはステートレスなので、状態を維持するためにクッキー、URLの書き換えなどのメソッドがあることを理解しています。

私の質問は、状態が非常に重要なので、なぜデザイナーはHTTPプロトコルを設計している間にそれを放棄したのですか？特別な理由はありますか？

プロトコルをステートフルにするためにプロトコルを再設計する価値はありますか？

Answer 1

ステートレスは安いです。良い読書について：

http://www.tonymarston.net/php-mysql/stateless-protocol.html

Answer 2

HTTPが発明された時点で誰もが、HTTPが今のように使用されるという予見があったとは思いません。

Answer 3

HTTPはGopher protocolの次のステップでした。 Geocitiesが存在する場所であり、CGI形式がインタラクティブセッションの高さだったのは1990年代のことでした。

これはそのままですが、状態はHTTPよりも高いレベルで維持されていますが、それはうまく機能しているようです（クッキー、セッションIDなど）。なぜあなたはプロトコルを書き換えますか？

Answer 4

の主な理由は、拡張性と、Webアプリケーションの高可用性で、なぜ我々はウェブを実行しているステートフルプロトコルを持つことはできません。ステートレスプロトコルは、状態そのものをサーバーに格納する必要がないため、レプリケーションとスケーラビリティに関する懸念を緩和します。 WebアプリケーションのステートレスプロトコルとしてのHTTPとHTTPSステートレスなHTTPリクエストはいつでも任意のノードに送信できますが、ステートレスの場合はそうではありません。ステートレスHTTPプロトコルの利点は、アクティブなWebクライアントの数がはるかに多くなり、同じ瞬間にすべてが送信されるのではなく、通常は互い違いになることです。

接続が失われても、失われた状態はありません。各要求は新しい要求として扱われ、後続の要求として処理されるわけではないので、単純な要求再送信によって問題は解決します。前のリクエスト。

ステートレスは、Webセキュリティにとって本当に悪いことです。 HTTPの裏側は、Webサーバーが任意のWebクライアントのアクティビティのメモリ（状態）を維持しないことです。厄介なウェブセキュリティの脆弱性は、その創作以来存在しており、時間とともにますます危険にさらされています。 Douglas CrockfordはSeif projectでWebセキュリティの脆弱性を修正しました。