Chuanzhi ポッドキャスト セッション管理チュートリアル

コースの紹介:

1 Web アプリケーションのリソース ファイルの読み込み

2 Cookie の概要

3 Cookie の詳細

4 Cookie ケース - ユーザーの最終訪問時間 1

5 Cookie ケース - ユーザーの最終訪問時間 2

6 Cookie ケース- 閲覧した商品

7つのセッション技術を詳しく解説

再生アドレス: http://www.php.cn/course/564.html

講師の特徴: 思考力が高く、真剣で、要点を押さえるいつ記憶に集中し、簡単かつ迅速に学習できるかを生徒に知らせます。 O 難しい点の分析: Cookie の原則のポイント

Cookie とセッションの同じ点と相違点、いつ Cookie とセッションを使用するか。

コースウェアのダウンロードアドレス:

http://www.php.cn/xiazai/code/2083

HTTP プロトコルはステートレス プロトコルであるため、WEB サーバーはユーザーからのすべてのリクエストを新しいリクエストとして扱います。ただし、多くの WEB アプリケーションでは、最後のリクエストから特定の情報を保存する必要があります。この問題を解決するには、セッションと状態の管理の問題が発生します。このビデオでは、関連する知識ポイントとして、WEB アプリケーションのセッションとセッション状態、Cookie、サーブレット プログラムでの Cookie の使用、セッション、セッションの典型的なケース、およびセッションの永続管理が含まれます。

いわゆるセッションとは、クライアントブラウザとWEBサーバー間で継続的に発生する一連のリクエストとレスポンスを指します。 WEB アプリケーションのセッション状態

は、セッション中に WEB サーバーとブラウザによって生成された状態情報を指し、WEB サーバーはセッション状態を利用して、それに属する一連のリクエストおよび応答プロセスを関連付けることができます

。同じセッション。 たとえば、ユーザーが Web サイトのログイン ページからログインし、ショッピング ページに入って購入する場合、ショッピング リクエストの処理を担当するサーバー プログラムは、前のリクエストを処理したプログラムによって取得されたユーザーの

情報を知っている必要があります。 HTTP プロトコルはステートレス プロトコルであるため、WEB サーバー自体は同じブラウザーからどのリクエストが発行されたかを識別できません。ブラウザーの各リクエストは完全に分離されます。そのため、WEBサーバー側のプログラムは、多数のリクエストメッセージの中からどのリクエストメッセージが同じセッションに属するのか、つまり同じブラウザからのアクセスリクエストを識別できる必要があります。そのためには、送信されるすべてのリクエストが必要となります。それぞれのリクエストメッセージはブラウザによって識別され、同じセッションに属するリクエストメッセージにはすべて同じ識別番号が付きますが、異なるセッションに属するリクエストメッセージには必ず異なる識別番号が付きます。 （セッションID ）。 SessionID はサーバーによって生成され、ブラウザーに渡されます。クライアントがそれを受信して​​検証のためにサーバーに送り返すには、一時的に受信して保存するだけではない対応するメカニズムが必要です。対応するセッション情報をクライアントのハード ドライブに長期間記録することもできます。

SessionID は、Cookie テクノロジーを通じてリクエスト メッセージで渡すだけでなく、リクエスト URL

の追加パラメーターとして渡すこともできます。 SessionID は、WEB サーバーによって各クライアント ブラウザーに割り当てられる固有のコードであり、通常、WEB サーバーがブラウザーの最初のアクセスを受信したときに生成され、応答メッセージとともにブラウザーに送信されます。セッションプロセスは、WEB サーバー上の

プログラムによって開始され、セッションが開かれると、サーバー側プログラムはこのセッション用に独立したストレージ構造を作成し、同じセッション内のアクセス要求のステータス情報を保存します。このセッションに属するストレージ構造内の状態情報にのみアクセスできます。

CookieはHTTPステータス情報をクライアントに保持する技術で、ショッピングモールが発行する割引カードのようなものです。 Cookie とは、ブラウザが WEB サーバーの特定のリソースにアクセスしたときに、HTTP 応答ヘッダーで WEB サーバーからブラウザに送信されるデータです。Web サーバーからクライアントのブラウザごとに送信されるデータは異なります。同じ。 WEB ブラウザが Cookie を保存したら、

、今後 WEB サーバーにアクセスするたびに、この Cookie を HTTP リクエスト ヘッダーで WEB サーバーに送り返す必要があります。 WEB サーバーは、Set-Cookie 応答ヘッダー フィールドを HTTP 応答メッセージに追加することによって Cookie 情報をブラウザーに送信し、ブラウザーは Cookie 要求ヘッダー フィールドを HTTP 要求メッセージに追加することによって Cookie を WEB サーバーに送り返します。 Cookieは1種類の情報のみを識別

し、少なくともその情報を識別する名前(NAME)と設定値(VALUE)が含まれています。 WEB サイトは WEB ブラウザに複数の Cookie を送信でき、WEB ブラウザは複数の WEB サイトから提供された Cookie を保存することもできます。

Set-Cookie および Set-Cookie2 ヘッダー フィールドは、WEB サーバーからクライアントに送信される Cookie の内容を指定するためにプログラムで使用できます。この 2 つは使用する仕様が異なるだけで、構文と機能は似ています。ブラウザのサポートに基づいて適切な応答を選択できます

ヘッダーフィールド。 Set-Cookie2 ヘッダー フィールドに設定される Cookie の内容は、Cookie の名前

で始まり、その後に 0 以上が続く形式の文字列です。 (;) とその他のオプションの属性をスペースで区切ります。属性の形式は通常、「属性名 = 値」です。

最後に、ブラウザから返されるCookieのリクエストヘッダフィールドについて説明します。ブラウザは、Cookie リクエスト ヘッダー フィールドを使用して、Cookie 情報を WEB サーバーに送り返します。複数の Cookie 情報が、Cookie リクエスト ヘッダー フィールドを通じて WEB サーバーに送信されます。ブラウザが特定の

Cookie 情報を送信するかどうかは、次のルールに従って決定されます:

1. 要求されたホスト名が保存されている Cookie のドメイン属性と一致するかどうか

2. 要求されたポート番号が Cookie に含まれているかどうかポート属性リスト

3. 要求されたリソース パスが Cookie の Path 属性で指定されたディレクトリおよびサブディレクトリにあるかどうか

4. Cookie の有効期限が切れているかどうか Cookie リクエスト内の各 Cookie の間にカンマを使用します。ヘッダーフィールド (,) またはセミコロン (;) を

で区切ります。 「名前 = 値」設定に加えて、Cookie リクエスト ヘッダー フィールドには、バージョン、パス、ドメイン、ポート

などのいくつかの属性も含めることができます。ただし、バージョン、パス、ドメイン、ポートなどの属性を設定する場合は、属性名の前にプレフィックスとして

「$」文字を追加する必要があります。また、バージョン属性は 1 回だけ使用できます。以前は、

特定の Cookie 情報のパス、ドメイン、ポート、その他の属性を設定する必要がある場合は、「name=

」の後に配置する必要がありました。 Cookie情報の「値」の設定。 Path 属性で注意する必要があるのは、この属性がサブディレクトリを指す Cookie は、Path 属性が親ディレクトリを指す

Cookie よりも前にランク付けされる必要があるということです。例: Cookie: $Version=1; $Path=/it315/lesson;

$Path=/it315この Cookie は上記の制約に従います。具体的な例は、ビデオ チュートリアルで説明されています。

代码一：
      Cookie ckName = new Cookie("name",name); 
      Cookie ckNickname = new Cookie("nickname",nickname); 
      ckNickname.setMaxAge(365*24*3600); 
      Cookie ckEmail = new Cookie("email","test1@it315.org"); 
      Cookie ckPhone = new Cookie("phone","1111111"); 
      response.addCookie(ckName); 
      response.addCookie(ckNickname); 
      response.addCookie(ckEmail); 
      response.addCookie(ckPhone);

代码二：
      String lastNickname = null; 
      Cookie [] cks = request.getCookies(); 
      for(int i=0; cks!=null && i<cks.length; i++) {
          if("nickname".equals(cks[i].getName())) {
              lastNickname = cks[i].getValue();
              break;  
          } 
      }  
      if(lastNickname != null) {
      out.println("欢迎您，" + lastNickname );
      }

上記のコード スニペットは、最初に、名前、ニックネーム、電子メール、電話番号という名前の 4 つの Cookie 情報を生成します。 2 つの Cookie の名前と

ニックネームの値はリクエスト パラメーターを通じて設定され、ニックネーム Cookie は 1

年間有効です。2 つの Cookie の電子メールと電話の値はハードコーディングされています。プログラムで。 2 番目のコード スニペットは、Cookie 情報

を生成し、リクエスト メッセージからニックネームという名前の Cookie 情報を検索し、返された結果に基づいて対応する挨拶を出力します。また、

スニペットは Cookie ヘッダー フィールドも出力します。リクエストメッセージの値。

セッションと Cookie テクノロジーの概念を理解し、セッションの詳細な紹介とサンプル デモンストレーションを行います。このビデオでは主に、

セッションとは、セッション追跡メカニズム、セッションタイムアウト管理、HttpSessionインターフェイスのメソッド、HttpServletRequestインターフェイスの

Sessionメソッド、アプリケーションとセッションドメインスコープ間の属性の比較、

Cookie実装の使用について説明します。セッション トラッキングと URL 書き換えを使用してセッション トラッキングを実装します。これらの技術は将来的に頻繁に使用されるでしょう。

Cookie と追加の URL パラメーターを使用すると、前のリクエストのステータス情報を次のリクエストに渡すことができますが、より多くのステータス情報を渡すと、ネットワーク送信効率が大幅に低下し、サーバー側プログラムの処理時間が増加します。困難、この問題を解決するために、

セッション技術が作成されました。セッション技術とは、セッションの状態をサーバー側に保存する技術です。セッション中、クライアントはセッションのセッション ID 番号を受信、記憶し、送り返す必要があります。セッションはセッション ID 番号を渡すために Cookie を使用できます。ご覧のとおり、Cookie とセッションは連携して動作することが多く、これにより HTTP プロトコルのステートレスな性質を解決できます

。セッションの概念では、それを実装し、サーバーが特定のセッションを正常に追跡できるようにするプログラムが必要です。

サーブレット API 仕様では、HttpSession インターフェイスが定義されており、セッションのステータスを管理および操作するためのさまざまなメソッドが定義されています。 WEB サーバーによって生成される HttpSession オブジェクトは、クライアントが WEB サーバー上の各 HttpSession オブジェクトに対応するセッション状態情報を保持する記憶構造です。 WEB サーバーは、クライアントがアクセスを開始するときに

HttpSession オブジェクトを作成しません。クライアントがクライアントとのセッションを開くことができるサーブレット プログラムにアクセスする場合にのみ、WEB アプリケーションはクライアントと

オブジェクトを作成します。対応する HttpSession オブジェクト。 WEB サーバーは、各 HttpSession オブジェクトに一意の

セッション識別番号を割り当て、このセッション識別番号を応答メッセージでクライアントに渡します。クライアントはセッション識別番号を記憶し、後続のアクセス要求ごとにこのセッション識別番号を WEB サーバーに送信する必要があります。WEB サーバー プログラムは、返されたセッション識別番号に基づいてこの要求が発行されたものであることを認識し、それによって選択します。対応する HttpSession オブジェクト。サーバー側のリソースには制限があり、HttpSession オブジェクトを無制限に保存できないため、WEB アプリケーションは特定のクライアントに対応する

を作成します。

HttpSession对象后，只要没有超出一个限定的空闲时间段，HttpSession对象就驻留在WEB服务器内

存之中，该客户端此后访问任意的Servlet程序时，它们都使用与客户端对应的那个已存在的

HttpSession对象。HttpSession接口中专门定义了一个setAttribute方法来将对象存储到

HttpSession对象中，还定义了一个getAttribute方法来检索存储在HttpSession对象中的对象，存

储进HttpSession对象中的对象可以被属于同一个会话的各个请求的处理程序共享。

前面提到的服务器资源有限，WEB服务器无法判断当前的客户端浏览器是否还会继续访问，也无

法检测客户端浏览器是否关闭，所以，即使客户已经离开或关闭了浏览器，WEB服务器还要保留与之

对应的HttpSession对象。但是随着时间的推移而不断增加新的访问客户端，WEB服务器内存中将会

因此积累起大量的不再被使用的HttpSession对象，并将最终导致服务器内存耗尽。因此WEB服务器

采用“超时限制”的办法来判断客户端是否还在继续访问，如果某个客户端在一定的时间之内没有发

出后续请求，WEB服务器则认为客户端已经停止了活动，结束与该客户端的会话并将与之对应的

HttpSession对象变成垃圾。如果客户端浏览器超时后再次发出访问请求，WEB服务器则认为这是一

个新的会话的开始，将为之创建新的HttpSession对象和分配新的会话标识号。虽然会有少数出现事

实上的同一会话，却产生两次HttpSession对象，但是相对于大量正常的访问请求，这种情况基本上

可以忽略了。在Servlet API中，会话的超时间隔可以在web.xml文件中设置，其默认值由Servlet容

器定义。

    例如：<session-config>
              <session-timeout>30</session-timeout>
          </session-config>

下面拿出视频中的一个小例子来说明一下使用Session实现购物车：

      String courseSelect = request.getParameter("course");
      if(courseSelect != null){
          Vector vCourses = (Vector)session.getAttribute("courses");
          if(vCourses == null){
              vCourses = new Vector();
              vCourses.add(courseSelect);
              session.setAttribute("courses",vCourses);
          }
          else{
              if(vCourses.contains(courseSelect)){
                  out.println(sessionName + "，你以前选择过了" + 
                             courseSelect + "<hr>");
              }
              else{
                  vCourses.add(courseSelect);
              }
          }
      }

上面的代码首先判断访问请求是否来自一个已登录用户，如果不是，则将请求重定向到logon.html页

面。接着判断当前访问请求是否是用户选择课程时发出的，如果是，则将用户选择的课程加入购物车

。最后显示出所有供选择的课程列表和已放入购物车中的课程列表。

以上がChuanzhi ポッドキャスト セッション管理チュートリアルの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。