HTTPにはHTTPCookieがあります。Cookieを使用すると、サーバーはユーザーの状態、接続数、最後の接続などを追跡できます。
HTTPには永続的な接続(キープアライブ)があり、同じTCP接続から複数の要求を送信できます。
同じHTTP接続を介して複数の要求を送信できますが、サーバーは、同じソケットを介して到着する要求に特別な意味を付加しません。これは単にパフォーマンス上の問題であり、リクエストごとに接続を再確立するために費やされる時間/帯域幅を最小限に抑えることを目的としています。
HTTPに関する限り、これらはすべて個別のリクエストであり、リクエストを満たすために十分な情報が含まれている必要があります。それが「無国籍」の本質です。サーバーが認識している共有情報(ほとんどの場合、CookieのセッションID)がないと、リクエストは相互に関連付けられません。
ウィキペディアから:
HTTPはステートレスプロトコルです。ステートレスプロトコルでは、サーバーが複数のリクエストの期間中、各ユーザーに関する情報やステータスを保持する必要はありません。
ただし、一部のWebアプリケーションでは、ユーザーの進行状況をページごとに追跡する必要がある場合があります。たとえば、WebサーバーがユーザーのWebページのコンテンツをカスタマイズする必要がある場合などです。これらの場合の解決策は次のとおりです。
- HTTPクッキーの使用。
- サーバーサイドセッション、
- 非表示の変数(現在のページにフォームが含まれている場合)、および
- URIエンコードされたパラメータを使用したURL書き換え(例:/index.php?session_id=some_unique_session_code)。
プロトコルをステートレスにするのは、サーバーが複数の要求にわたって状態を追跡する必要がないことであり、必要に応じて追跡できないことではありません。これにより、クライアントとサーバー間の契約が簡素化され、多くの場合(たとえば、CDNを介して静的データを提供する)、転送する必要のあるデータの量が最小限に抑えられます。サーバーがクライアントの訪問の状態を維持する必要がある場合、要求の発行と応答の構造はより複雑になります。現状では、モデルのシンプルさが最大の特徴の1つです。
ステートレスプロトコルでは、サーバーが複数の要求の期間中、各通信パートナーに関するセッション情報またはステータスを保持する必要がないためです。
HTTPはステートレスプロトコルです。つまり、トランザクションが終了すると、ブラウザとサーバー間の接続が失われます。
HTTPは、stateless protocol
各リクエストが独立して実行され、その前に実行されたリクエストを認識しないため、と呼ばれます。つまり、トランザクションが終了すると、ブラウザとサーバー間の接続も失われます。
プロトコルstateless
を作成するのは、元の設計では、HTTPが比較的単純であるということfile transfer protocol
です。
同じクライアントからであっても、ある接続と別の接続の間に関係は維持されませんでした。これにより、クライアントとサーバー間の契約が簡素化され、多くの場合、転送する必要のあるデータの量が最小限に抑えられます。
Netscapeが1994年にCookieとHTTPSを発明する前は、HTTPはステートレスと見なすことができました。時間の経過とともに、パフォーマンスやセキュリティなど、さまざまな理由で多くのステートフルコンポーネントが追加されました。しかし、ステートフルな追加はまさにその追加であり、コアが明示的にステートレスであることを求めていたため、HTTPはステートレスであると口語的に言われていました。
HTTP / 1はもともとステートレスであることが求められていましたが、多くのHTTP/2コンポーネントはまさにステートフルの定義です。 HTTP/2はステートレスゴールを放棄しました。ステートフルコンポーネントは「追加」ではなくなり、代わりにステートフルコンポーネントがHTTP/2標準のコアで定義されます。
ステートフルHTTP/1およびHTTP/2コンポーネントの限定された、完全ではないリストを次に示します。
HTTP / 2 RFCのセクション5.1「ストリーム状態」は、HTTP/2標準で定義されたステートフルメカニズムの優れた例です。セクション5.3.4は、「優先順位付け状態管理」とさえ題されています。
WebアプリケーションがHTTP/2をステートレスプロトコルと見なすのは安全ですか?
HTTP / 2はステートフルプロトコルですが、それはHTTP/2アプリケーションがステートレスになれないという意味ではありません。ステートレスHTTP/2アプリケーションにステートフル機能を使用しないことを選択できます。
ステートを必要とする既存のHTTP/1およびHTTP/2アプリケーションは、ステートレスで使用しようとすると壊れます。たとえば、Cookieが無効になっていると、一部のHTTP / 1.1 Webサイトにログインできなくなり、アプリケーションが破損する可能性があります。特定のHTTP/1またはHTTP/2アプリケーションがステートレスであると想定するのは安全ではない場合があります。
ステートフルメカニズムは、後に元のステートレス標準にHTTPが追加されました。HTTP / 1は口語的にステートレスと言われていますが、実際にはCookie、TLS、キャッシングなどの標準化されたステートフルメカニズムを使用しています。HTTP / 1とは異なり、HTTP/2は最初から標準でステートフルコンポーネントを定義します。特定のHTTP/2アプリケーションは、HTTP / 2機能のサブセットを使用してステートレス性を維持できますが、プロトコル自体は、例外ではなく、状態が標準であると想定しています。
誤った「HTTPはステートレス」は、HTTPの現代のステートフルな現実からはほど遠い、昔の教義です。
プロトコルHTTPがStatefullprotocolとして指定されている場合、ブラウザーウィンドウは単一の接続を使用してWebサーバーと通信し、Webアプリケーションに複数の要求を送信します。これにより、ブラウザーウィンドウは、ブラウザーウィンドウとWebサーバー間の接続を長時間使用し、維持することができます。クライアントのほとんどの接続がアイドル状態であっても、Webサーバーの最大接続数に達する状況が発生する可能性があります。
HTTPはコネクションレス型であり、これはHTTPがステートレスプロトコルであるという直接的な結果です。サーバーとクライアントは、現在の要求の間のみ相互に認識します。その後、二人はお互いを忘れます。プロトコルのこの性質により、クライアントもブラウザも、Webページ全体の異なる要求間で情報を保持できません。
HTTP
ステートレスです。TCP
ステートフルです。いわゆる、はありませんが、とHTTP connection
だけです。別のものを作るために維持する必要はありません。「キープアライブ」である接続ヘッダーは、接続を常に切断して再確立するのではなく、後続の要求と応答によって再利用されることを意味します。HTTP request
HTTP response
HTTP request
TCP
HTTP
TCP
ステートレスとは何ですか?
要求が行われ、応答がクライアントに返されると、接続は切断または終了されます。サーバーはリクエスターのことをすべて忘れます。
なぜステートレス??
Webは、ステートレスプロトコルを選択します。Webの本来の目的は、ドキュメント(Webページ)を非常に多くの人に提供できるようにすることだったので、それは天才的な選択でした。サーバーに非常に基本的なハードウェアを使用している人の割合。
長時間実行される接続を維持することは、非常に多くのリソースを消費します。
Webがステートフルプロトコルを選択した場合、訪問者の接続を維持するためにサーバーの負荷が増加します。
誰かがSTATELESSのコンセプトに非常に不幸な名前を選んだと思うので、それが全体の誤解を引き起こしているのです。それは、あらゆる種類のリソースを格納することではなく、クライアントとサーバーの間の関係についてです。
クライアント:私はすべてのリソースを自分の側に置いており、処理する必要のあるすべての重要なアイテムの「リスト」を送信します。あなたの仕事をする。
サーバー:わかりました。適切な応答を提供するために重要なものをフィルタリングする責任を負わせてください。
これは、サーバーがクライアントの「スレーブ」であり、各要求の後にサーバーの「マスター」を忘れる必要があることを意味します。実際には、STATELESSはサーバーの状態のみを指します。
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3