会話型テクノロジー
1. Cookieは、クライアントのブラウザに送信され、クライアントのハードディスクに保存されるテキスト文字列ハンドルです。特定のWEBサイトセッション間でデータを永続化するために使用できます。
2.セッションとは、実際には、訪問者が特定のホームページに到着してから離れるまでの期間を指します。セッションは実際には情報処理にCookieを使用します。ユーザーが最初にリクエストを行うと、サーバーはユーザーのブラウザにCookieを作成します。セッションが終了すると、実際にはCookieの有効期限が切れていることを意味します。
注：このユーザー用に作成されたCookieの名前はaspsessionidです。このCookieの唯一の目的は、ユーザーごとに異なるID認証を提供することです。
3. Cookieとセッションに共通しているのは、Cookieとセッションの両方がブラウザユーザーのIDを追跡するために使用されるセッションメソッドであるということです。
4. Cookieとセッションの違いは、Cookieデータはクライアント側に保存され、セッションデータはサーバー側に保存されることです。
簡単に言えば、Webサイトにログインすると、
・Webサーバーがセッションを使用する場合、すべてのデータがサーバーに保存され、クライアントはサーバーを要求するたびに現在のセッションのセッションIDを送信し、サーバーは現在のセッションIDに従って対応するユーザーデータフラグを判断します。ユーザーがログインしているか、特定の権限を持っているかを判断します。データはサーバーに保存されているため、偽造することはできませんが、ログインしているユーザーのセッションIDを取得できれば、特別なブラウザーを使用してユーザーの要求を正常に偽造できます。サーバーとクライアントが接続されている場合、セッションIDはランダムに割り当てられます。一般的には重複はありませんが、同時リクエストが多い場合は重複の可能性はありません。
如果浏览器使用的是cookie，那么所有的数据都保存在浏览器端，比如你登录以后，服务器设置了cookie用户名，那么当你再次请求服务器的时候，浏览器会将用户名一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量，所以只要不关闭浏览器，那么cookie变量一直是有效的，所以能够保证长时间不掉线。如果你能够截获某个用户的 cookie变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用 cookie被攻击的可能性比较大。如果设置了的有效时间，那么它会将 cookie保存在客户端的硬盘上，下次再访问该网站的时候，浏览器先检查有没有 cookie，如果有的话，就读取该 cookie，然后发送给服务器。如果你在机器上面保存了某个论坛 cookie，有效期是一年，如果有人入侵你的机器，将你的 cookie拷走，然后放在他的浏览器的目录下面，那么他登录该网站的时候就是用你的的身份登录的。所以 cookie是可以伪造的。当然，伪造的时候需要主意，直接copy cookie文件到 cookie目录，浏览器是不认的，他有一个index.dat文件，存储了 cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的 cookie文件，并且要从保证时间上骗过浏览器
5.どちらもプライベートなものを保存するために使用でき、有効期間もあります。違いは、セッションがサーバーに配置されることです。セッションが期限切れになるかどうかは、サービス期間の設定によって異なります。Cookieはクライアントに存在します。サイドクッキー生成時に設定できますか？
（1）Cookieデータはクライアントのブラウザに保存され、セッションデータはサーバーに保存されます
（2）Cookieはあまり安全ではありません。他のユーザーはローカルに保存されたCookieを分析し、Cookieの欺瞞を実行できます。セキュリティが主な懸念事項である場合、セッション
（3））セッションは一定期間サーバーに保存されます。訪問数が増えると、サーバーのパフォーマンスが低下します。サーバーのパフォーマンスを低下させることが主な考慮事項である場合は、Cookieを使用する必要があります。
（4）クライアントでの1つのCookieの制限は3Kです。つまり、サイトによってクライアントに保存されるCookieを3Kにすることはできません。
（5）つまり、ログイン情報などの重要な情報をSESSIONとして保存します。他の情報を保持する必要がある場合は、COOKIEに入れることができます。
クッキー
ここでは、いくつかの重要なプロパティについて説明します。
maxAge：クライアントでのこのCookieの有効期間を秒単位で示します。デフォルト値は-1で、ブラウザ全体を閉じるとCookieは無効になります。maxAge値が正の場合、つまりCookieの有効期間の残り秒数です。値が0の場合、Cookieは無効になります。無効であると、ブラウザはそれを削除します；
path：このCookieがパスの下のディレクトリとサブディレクトリに有効であることを示します。たとえば、pathが/ restに設定されている場合、クライアントが/ rest / aaaServletリクエストを開始すると、このCookieが送信されます。このCookieが必要な場合サイトが所有するディレクトリが有効な場合は、/に設定できます。
domain：このCookieにアクセスできるドメイン名を示します。設定されていない場合は、現在のリクエストURLに従って設定されます。手動で設定すると、「。」を使用して、より広いドメイン名のアクセス範囲を定義できます。ドメイン「.Csdn.net」の設定など、このCookieは、「https://lizishudd.blog.csdn.net/」にアクセスすると、「。csdn.net」の下のCookieを使用することもできます（もちろん、クレームを満たすには、Cookieのパスも必要です。
セッション
1.セッションはいつ作成されましたか
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。
由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。
2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）
3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。
4、有个HttpSessionListener是怎么回事
你可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。
5、存放在session中的对象必须是可序列化的吗
不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化的对象，在session销毁时会有一个Exception，很奇怪。
6、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。
8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改操作，这样就可以不用设置。
9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。
10、为什么session不见了
排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题。
この問題のほとんどの理由はプログラムエラーです。最も一般的なのは、1つのアプリケーションで別のアプリケーションにアクセスすることです。この問題については、次のセクションで説明します。
ドメインオブジェクトの定義
異なるサーブレットでデータを転送できるオブジェクトは、ドメインオブジェクトと呼ばれます。
ドメインオブジェクトのメソッドが必要です
setAttribute（name、value）;データを格納する方法
getAttribute（name）;名前に従って対応するデータ値を取得します
removeAttribute（name）;データを削除します
4種類のドメインオブジェクトとその使用範囲
page（jsp valid）-> page domainはpageContextを参照します（基本的にフロントエンドとバックエンドの分離モードでは使用されないため、この記事では説明しません）
request（1つのリクエスト）-> requestdomainはto HttpServletContext（マスターが必要）
session（1セッション）->セッションドメインはHttpSession
アプリケーション（現在のWebアプリケーション）を指します->アプリケーションドメインはアプリケーションServletContextを指します;
それらがドメインオブジェクトである理由は、それらすべてに組み込みのマップコレクションがあるためです、および両方にsetAttributeメソッドとgetAttributeメソッドがあります。
ドメインをリクエストする
リクエストドメインオブジェクトのデータ転送
リクエストオブジェクトは、RequestDispatcherオブジェクトを返すgetRequestDispatcherメソッドを提供します。このオブジェクトのforwardメソッドを呼び出すと、リクエストの転送を実現し、リクエスト内のデータを共有できます。
リクエストのライフサイクルは、リクエストが
来るとリクエストオブジェクトを作成します。リクエストが終了すると、リクエストは破棄されます。
各リクエストは新しいリクエストオブジェクトです。
リクエストドメインオブジェクトは、ライフサイクルが比較的短いため、推奨され、頻繁に使用されるドメインオブジェクトです。これは、より効率的で、リソースをタイムリーに解放することを意味します。
セッションドメインオブジェクト
セッションのライフサイクル
request.getSession（）メソッドが初めて呼び出されると、サーバーは対応するセッションがあるかどうかを確認し、ない場合はメモリ内にセッションを作成して戻ります。
（1）セッションが一定期間使用されない場合（デフォルトは30分）、サーバーはセッションを破棄します。
（2）サーバーが異常終了した場合、有効期限が切れていないセッションも破棄されます。
（3）セッションによって提供されたinvalidate（）が呼び出された場合、セッションはすぐに破棄できます。
ユーザーがブラウザを開いてアクセスし、セッションを作成（開始）すると、セッションがタイムアウトするか無効と宣言され、オブジェクトのライフサイクルが終了します。
セッションの範囲：1つのセッション、
HttpSessionに対する複数の要求サーバーで、ブラウザー用の一意のメモリースペースを作成し、セッション関連の情報をその中に保存します。
注：サーバーは通常、シャットダウンおよび再起動され、Sessionオブジェクト不動態化され、アクティブ化されます。同時に、サーバーのパッシベーション時間がセッションのデフォルトの破棄時間内にある場合、セッションはアクティブ化後も存在し続けます。それ以外の場合、セッションは存在しません。セッションがパッシベーションされたときにJavaBeanデータがSerializableを実装していない場合、セッションがアクティブ化されるとデータは消えます。
同じサーバー上の異なるリクエストリクエストは、一意のセッション
セッション生成タイミングを取得します。リクエストオブジェクトがgetSessionメソッドを呼び出すと、サーバーはSessionオブジェクトの一意のIDを生成します。
サーバーがクライアント要求に応答すると、メッセージのヘッダーにSet-Cookie属性が設定されます。属性コンテンツにはSessionオブジェクトの識別子であるJSESSIONIDがあり、その後ブラウザーによって処理されます。が返されます。クライアントが再度リクエストを送信すると、ブラウザは自動的にCookie属性をメッセージヘッダーに追加します。これにより、JSESSIONIDがサーバーに渡されます。サーバー側でrequest.getSessionを使用すると、Sessionを再生成せずにSessionIdに対応するオブジェクトが取得されます。
セッションを監視するための強力なツールであるHttpSessionListenerは、
新しいセッションが作成されるたびにセッション作成イベントが発生します。同様に、セッションが失敗するたびにセッション無効化イベントが発生します。セッションが作成または破棄されると、SessionCounterクラスに通知されます。たとえば、Webサイトでオンラインになっている人の数を数えるシナリオでは、HttpSessionListennerを使用して監視できます。
セッションがセッションを作成するとき、Webページが開かれるとすぐにセッションオブジェクトは作成されません。サーブレットリクエストの場合、セッションは、サーブレット内で次のコードが呼び出されたときにのみ生成されます。
HttpSessionセッション= request.getSession（）;
//または
HttpSessionsession = request.getSession（true）;
次のように記述した場合、セッションは作成されません
HttpSession session = request.getSession（false）;
Jspページにはセッションを呼び出すコードをカプセル化する組み込みのセッションオブジェクトがあるため、JSPページにアクセスしてください。JSPページがオープン
ServletContextドメインオブジェクト
ServletContextのライフサイクル
は、WEBアプリケーションの作成時に作成され、WEBアプリケーションが閉じられると破棄されます。
WEBアプリケーション全体の範囲
役割
1.異なるサーブレット間で調整します。
this.getServletContext（）。getRequestDispatcher（ "/ servlet1"）。forward（request、response）;
ファイルの読み取り
1.Webアプリケーションのルートディレクトリ
InputStream stream = this.getServletContext().getResourceAsStream("conf.properties");
Properties properties = new Properties();
properties.load(stream);
String name = properties.getProperty("name");
String password = properties.getProperty("password");
2.Srcの下
InputStream stream = MyServlet.class.getClassLoader().getResourceAsStream("conf.properties")
3. Srcの下のパッケージの下、次に
InputStream stream = MyServlet.class.getClassLoader().getResourceAsStream("com/haoeasy/conf.properties")
4.絶対パスを取得します
MyServlet.class.getClassLoader().getResourceAsStream("com/haoeasy/conf.properties").getPath()