容器怎么知道客户是谁
Http协议是无状态连接，客户浏览器与服务器建立连接、发出请求、得到响应，然后关闭连接。即，连接只针对一个请求/响应。
对容器而言，每个请求都来自于一个新的客户。客户需要一个唯一的会话ID
IP不能唯一标示Internet上特定的用户
比如公司网络内的用户为一个IP；而IP地址也只是路由的地址；用户换了一台设备的情况；
- 客户和容器如何交互会话ID信息 容器必须以某种方式吧会话ID作为响应的一部分交给客户，而客户必须把会话ID作为请求的一部分发回； 最简单而且最常用的方式是通过cookie交换这个会话ID信息。 容器会做cookie所有的工作！ 在响应中发送一个会话cookie：
HttpSession session=request.geteSession();余下的所有事情都会自动发生： 你不用自己建立新的HttpSession对象； 你不必生成唯一的会话ID； 你不用自己建立新的Cookie对象； 你不用把会话ID与cookie关联； 你不用在响应中设置Cookie； cookie的所有工作都在后台运行；从请求得到会话ID：
HttpSession session=request.geteSession();与为响应生成会话ID和cookie时所用的方法完全一样！ 即：
if(请求包含一个会话ID cookie){找到与该ID匹配的会话；}else if(没有会话ID cookie OR 没有与此会话ID匹配的当前会话){创建一个新会话；}
若不想新建会话
HttpSession session= request.getSession(false);若只想要一个已经有的会话，若没有会话则返回null，若有会话存在则返回HttpSession。若用户不接受cookie
若用户没有启用cookie，则需要使用URL重写。在Tomcat中表现为URL+;jsessionid=1234567。 如果不能用cookie，而且只要告诉响应要对URL编码，URL重写才能奏效。容器怎么知道cookie不能正常工作？
容器并不知道cookie是否工作，所以向客户返回第一个响应时，它会同时尝试cookie和URL重写这两种方式； 当用户发出下一个请求，它把会话ID追加到请求URL，若用户接受cookie，这个请求也会有一个会话ID cookie； 当servlet调用request.getSession()时，容器若从请求读取会话ID，则认为这个客户接受cookie，所以可以忽略response.encodeURL()调用。另一种URL重写
response.encodeRedirectURL("/BeerTest.do");用于想把请求重定向到另一个URL，但是还是想使用一个会话。注意，若依赖会话，就要把URL重写作为一条后路；
另外，因为需要URL重写，就必须在响应HTML中动态生成URL，这意味着必须在运行时处理HTML。（当然，可以在JSP中完成URL重写。） encodeURL()方法是HttpServletResponse对象上调用的方法，不能再请求上调用这个方法；URL编码只与响应有关。
关键的HttpSession方法
设置会话超时
- 会话有3中死法：
超时在会话对象上调用invalidate()应用结束（崩溃或取消部署）
- 在DD中配置会话超时
这与在会话上调用setMaxInactiveInterval()一样的效果。 设置一个特定会话的会话超时
cookie
cookie实际上就是用户和服务器之间交换的一小段数据（一个名/值String对）； 服务器把cookie发送给客户，客户做出下一个请求时再把cookie返回给服务器。 与cookie相关的方法封装在3个类中：HttpServletRequest、HttpServletResponse和Cookie。- cookie和首部
HttpSession对象的生命周期中的重要时刻：
注意，实现了HttpSessionBindingListener的属性类（如Dog类），不在DD中配置，因为它只与会话中的某个属性有关；
而HttpSessionListener和HttpSessionAttributeListener必须在DD中注册，因为它们会会话本身有关。
会话迁移【分布式Web应用的范畴】
分布式Web应用中，每次同一个客户做请求时，最后这个请求都有可能达到同一个servlet的不同实例；
即指向servlet A的请求A可能在一个VM中，而指向servlet A的请求B可能在另一个不同的VM中。 那么，ServletContext、ServletConfig和HttpSession对象如何表现？ 答案：只有HttpSession对象（及其属性）会从一个VM中迁移到另一个VM中（即所有VM只有一个同样ID的HttpSession），其他对象复制（不同VM可能有多个这类对象）。- 属性迁移 若属性是直接的Serializable对象，则该属性会自动在迁移时序列化，不用额外关心它。 若属性类型不是Serializable呢？那么为了迁移，需要让属性对象类实现HttpSessionActivationListener，并使用激活/钝化回调方法解决这个问题。
Listener示例
会话计数器
这个监听者允许你跟踪这个Web应用中活动会话的个数： 在DD中配置监听者：
注意： 
属性监听者
这个监听者，当每一次向会话增加属性、删除属性或者替换属性时，都能被跟踪到。 在DD中配置监听者：
注意，System.out标准输出在Tomcat中默认输出到tomcat/logs/catalina.log中。
属性类（监听对它有影响的事件）
在DD中配置：
与会话相关的监听者