HTTPはステートレスプロトコルであるため、クライアントがサーバーに対して多数の要求を行う場合、サーバーは、t1、t2、t3などの期間にわたって特定のクライアントの要求をどのように一意に識別しますか。
Webを閲覧したところ、セッションID、URL書き換え、Cookieなどの用語に出くわしました。しかし、誰かがそれをより良い方法で説明するなら、それは素晴らしいことです。具体的には、HTTP要求と応答のどの部分がセッション追跡に使用されますか?
HTTPはステートレスプロトコルであるため、クライアントがサーバーに対して多数の要求を行う場合、サーバーは、t1、t2、t3などの期間にわたって特定のクライアントの要求をどのように一意に識別しますか。
Webを閲覧したところ、セッションID、URL書き換え、Cookieなどの用語に出くわしました。しかし、誰かがそれをより良い方法で説明するなら、それは素晴らしいことです。具体的には、HTTP要求と応答のどの部分がセッション追跡に使用されますか?
前述のように、HTTPセッショントラッキングを実装する一般的な方法には、URLの書き換えとCookieが含まれます。セッショントラッキングでは、基本的に、サーバーへの複数のリクエストにわたってセッションIDが維持されている必要があります。これは、特定のクライアントがサーバーに要求を行うたびに、同じセッションIDを渡すことを意味します。サーバーはこのIDを使用して、維持しているセッション情報を検索できます。
Set-Cookie
Cookieを使用する場合、サーバーはHTTP応答ヘッダーを設定してCookieを保存するようにクライアントに要求します。このCookieには、そのクライアントに割り当てられた一意のセッションIDが含まれています。この例では文字列「ABAD1D」です。
Set-Cookie: JSESSIONID=ABAD1D;path=/
次に、Cookieは、各要求でHTTP要求ヘッダーを使用してクライアントによってサーバーに送り返されますCookie
。したがって、サーバーは、各要求で、現在クライアントに割り当てられているセッションIDを通知されます。
Cookie: JSESSIONID=ABAD1D
URL書き換えを使用する場合、この同じセッションIDが代わりにURLのどこかに送信されます。この場合も、サーバーはURLからセッションIDを抽出して、特定のクライアントのセッションを検索できるようにします。
http://my.app.com/index.jsp;JSESSIONID=ABAD1D
ただし、サーバーは、クライアントに返送されるWebページのURLも、その特定のクライアントのセッションIDを含むように書き換えられることを確認する必要があります。セッションIDはURLにエンコードされているため、このセッション追跡方法はブラウザに対して透過的です。多くの場合、サーバーは、クライアントにセッションCookieを設定できないことがわかった場合、URLの書き換えに頼ります。これは、クライアントがCookieをサポート/許可していないことを意味します。
セッションは期限切れになる可能性があることに注意してください。これは、サーバーが特定のセッションIDを一定期間「認識」しない場合、リソースを保持するためにセッションデータを削除する可能性があることを意味します。
具体的には、HTTP要求と応答のどの部分がセッション追跡に使用されますか?
HTTP応答では、サーバーはCookieを設定できます。これは、Set-Cookieヘッダーを使用して行われます。例えば:
Set-Cookie: session=12345; path=/
次に、クライアントは、Cookieとともに設定されたプロパティに一致するすべてのCookieの値を返します。これには、パス(上記のように)とドメインを含めることができ、まだ有効期限が切れていません。
Cookieは、HTTPヘッダーの一部としてサーバーに返送されます。例えば:
Cookie: session=12345
元のプロパティ情報はいずれもCookieとともに返送されません。
一意のCookieを使用すると、サーバーは一意のキーを特定のブラウザインスタンスに関連付けることができます。サーバーは、そのキーをハッシュテーブルまたはユーザーごとの一意の状態情報を保持するデータベーステーブルへのインデックスとして使用できます。
セッション追跡はサーバー側のものです。
Webサーバーは、ブラウザに返されるセッション識別子を発行します。ブラウザは、このセッション識別子を各リクエストとともに送信します。
これはおそらく、ユーザーに対して透過的にCookieを使用して行われます。
セッション処理は、ほとんどの場合、クライアントにCookieを送信することによって処理されます。そのCookieは、その特定のクライアントからのすべての要求でサーバーに送り返されます。
はsession id
サーバー側のいくつかのリソース(ファイル、RAMスペース)に関連付けられるため、サーバーsession id
はCookieを読み取ることでこのリソースを見つけ、それがどのクライアントであったかを知ることができます。
ここで十分な詳細を見つけてください
HTTP セッションは、推奨されるアプローチです。セッションは、会話中に同じブラウザから発信されたリクエストを識別します。すべてのサーブレットが同じセッションを共有できます。JSESSIONID はサーバーによって生成され、Cookie、URL の書き換え (Cookie がオフの場合)、または組み込みの SSL メカニズムを介してクライアントに渡すことができます。セッションに保存されるオブジェクトのサイズを最小限に抑えるように注意する必要があり、セッションに保存されるオブジェクトはシリアライズ可能である必要があります。Java サーブレットでは、セッションは次のように取得できます。
HttpSession セッション = request.getSession(); //現在のセッションまたは新しいセッションを返します
セッションはタイムアウト (web.xml で構成) するか、手動で無効にすることができます。