ステートレスプロトコルとステートフルプロトコル
ステートレスプロトコルとステートフルプロトコルを理解する方法HTTPはステートレスプロトコルであり、FTPはステートフルプロトコルです。多くの相互作用を必要とするWebアプリケーションの場合、基礎となるプロトコルはステートフルなものでなければなりません。私の理解は正しいですか？
Webアプリケーションについて尋ねているので、プロトコルは常にステートレスです。Webのプロトコルはhttp（またはhttps）であり、彼女が書いたのはそれだけです。
あなたが考えているのは、Webアプリケーション自体に状態メカニズムを提供することだと思います。これに対する典型的なアプローチは、Webアプリケーションでユーザーのセッションの一意の識別子を作成することです（何らかの形式のセッションIDが一般的です）。これはブラウザとサーバー間でやり取りされます。これは通常、Cookieで行われますが、プラットフォーム/フレームワークやURLにもよりますが、もう少し面倒です。
サーバー側のコードはステートフル情報（通常はユーザーのセッションと呼ばれます）を保存しますが、sessionIDを使用して検索します。 httpトラフィックは、単にsessionIDを返します。その識別子が存在する限り、各httpトランザクションは他のすべてのトランザクションから完全に独立しているため、プロトコルトラフィック自体はステートレスです。
HTTPはステートレスプロトコルです。つまり、サーバーはクライアント/ブラウザーの状態に関連するすべてを忘れます。 Webアプリケーションは事実上、ステートフルのように見えますが。
ステートレスプロトコルは、強制的にステートフルであるかのように動作させることができます。これは、サーバーがクライアントに状態を送信し、クライアントがサーバーに状態を毎回送り返す場合に実現できます。
HTTPでこれを実現するには、次の3つの方法があります。
a）1つはCookieです。この場合、状態が送信され、HTTPヘッダーで返されます。
b）2番目はURL拡張子です。この場合、状態は応答としてURLの一部として送信されます。
c）3番目は「非表示フォームフィールド」であり、応答の一部として状態がクライアントに送信され、フォームの非表示データの一部としてサーバーに返されます。
スケーラビリティと高可用性
HTTPが非常にうまくスケールする主な理由の1つは、そのステートレス性です。ステートレスプロトコルは、状態自体をサーバーに保存する必要がないため、レプリケーションの懸念を緩和します。
ステートフルプロトコルは、インターネットに確実に実装するには論理的に重いです。ステートレスサーバーはスケーラブルでも簡単ですが、ステートフルサーバーではスケーラビリティが問題になります。ステートレス要求はいつでもどのノードにも送信できますが、ステートフルではこれは当てはまりません。
ステートレスプロトコルとしてのHTTPは、そうでなければ実装が困難または不可能なステートレスWebアプリケーションの可用性を向上させます。接続が失われた場合、失われた状態はなく、単純な要求の再送により問題が解決されます。ステートレスリクエストもキャッシュ可能です。
httpはステートレスプロトコルです。すべてのWebベースのアプリケーションはステートレスです。要求がサーバーに送信されると、クライアントとサーバーの間に接続が確立され、サーバーは要求を受信し、要求を処理して応答を送り返します。接続は閉じられます。別のリクエストが送信されると、それは新しいリクエストとして扱われ、新しい接続が確立されます。 HTTPをステートフルにするため。セッション管理手法を使用します。つまり、現在のリクエストの処理中に以前のリクエストからのデータを使用するようになります。つまり、一連のクライアントサーバーインタラクションに同じ接続を使用します。セッション管理テクニックは次のとおりです。1.hiddenform field 2.cookie 3.session 4.url-rewriting;
あなたの質問にスポットが当てられています。はい、あなたの銀行とのウェブ取引がステートフルな接続を介して行われたら素晴らしいでしょう。残念ながら、HTTPはFTPの風変わりなバグと1989年のBSDの部分ソケットテーブルの12ソケット制限のためにステートレスです。MarcusRanumがすべてを説明しました here 。
したがって、HTTPはTCPから継承した状態を破棄し、Cookieの形式でアプリケーション層で状態を再作成する必要があります。
Seifプロジェクト では、「secure JSON over TCP」を使用してすべてを修正することを提案しています。 DNSおよび認証局は必要ありません。プロトコルとseifnode.jsが完成し、githubでMITライセンス。
HTTPはTCPから「継承」するのではなく、トランスポートに使用します。 HTTPは、ステートフル接続にTCPを使用しますが、その後切断します。後で必要に応じて接続し直します。ステートフルですが、すべての会話との接続を切断しているため、会話全体はそうではありません。
基本的にはありますが、Webサイトが提供される場所であるHTTPを使用する以外に選択肢はありません。そのため、セッション管理とも呼ばれるHTTPステートフルにするために妥協に対処する必要があります。基本的には、URLの各呼び出しを通じてセッションIDを渡すため、以前に話したことのある人と話しているとき、またはURLを乱雑にすることなく同じ目標を達成するCookieを介して話しているときにわかります。ただし、最新のWeb開発言語のほとんどはそれを処理します。選択した言語と「セッション管理」をグーグルで検索する場合、どのように行われるかのアイデアを得る必要があります。