会话（session）是一种持久网络协议，在用户（或用户代理）端和服务器端之间创建关联，从而起到交换数据包的作用机制
一、查看session id
可利用相关工具，比如firebug,httpwatch等查看会话id
以下是访问某个网站页面(记为页面1)的http请求头信息
从上图可看到，访问页面1时的session id为 abcmiPGuZcZTqaNNnLUHu
以下是访问另一个网站的页面(记为页面2)的http请求头信息
从上图可看到，访问页面2时的session id为:b035123e4066ec2b270c5fc07260b08f
说明：
1. 可通过Cookie中的会话标记：session name=session id，来查找session id，其中，session name,即会话名称，称默认为JSSESSIONID(jsp, weblogic)，PHPSESSID(PHP)，可通过函数自定义
2. session name，只能包含字幕，数字，且至少包含一个字母
3. 访问不同网站的页面，生成的会话id不一样
二、会话机制
会话机制是一种服务器端的机制，服务器使某种数据结构(可能是散列表)来保存信息
会话过程如下：
1、客户端-----发送请求----->服务器
2、服务器检查请求是否含有session id，根据不同情况采取不同的操作
分两种情况
a) 情形一：请求中含有session id
根据session id检索对应的会话信息，如果检索不到(会话信息因超时被删除)，则创建用于保存会话信息的文件或某种数据结构变量，并生成与文件或数据结构变量关联的session id
注：请求中含有session id，说明服务器已经为客户端保存过会话信息；
b) 情形二：请求中不含session id
创建用于保存会话信息的文件或某种数据结构变量，并生成与文件或数据结构变量关
联的session id
3、把session id以响应报文的方式发送给客户端，如果客户端的请求中不含session id，那么服务器还会给出指令，指示客户端保存session id,如下图，客户端首次向服务器发起请求时，可看到，客户端收到的请求头包含Set-Cookie
说明：从图上可看出，cookie是由服务器下发的
4、客户端再次发起访问其它或相同页面请求时，会自动在请求中发送cookie中保存的session id。如下图，再次发送请求时发送的请求头(注：前提是存在session id且还有效，比如未关闭浏览器的情况下)
说明：
1.客户端通常是浏览器
2.session id唯一，一个session id 代表着一次会话
测试(IE8下)
步骤1、禁用浏览器cookie
步骤2、重复访问某网站后查看Cookies，查看请求头
结果：禁用浏览器cookie,可看到Cookies的状态为Received，收到请求头信息一直是Set-Cookie
步骤3、启用浏览器cookie，重复两次访问网站后查看Cookies
结果：开启cookie，第二次访问网站后，Cookies状态，状态为Sent
URL重写
由于cookie可以被人为的禁止，必须有其他机制确保cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写：把session id直接附加在URL路径的后面：一种是作为URL路径的附加信息，表现形式为：
http://...../xxx;jsessionid=ByOK ... 99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式：http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
三、会话生存期
先进行以下测试：
1. 删除本地cookie，同一浏览器，不同标签中打开相同站点的相同页面，查看session id是否变化
结果：每个标签中访问页面时看到的session id一样
2. 删除本地cookie，同一浏览器，不同标签中打开相同站点的不同页面，查看session id是否变化
结果：站点相同，访问不同页面时看到的session id一样
3. 删除本地cookie，不同浏览器(类型相同，比如都为ie)，打开相同网站的相同页面，查看，查看session id是否变化
结果：访问同一页面时，session id都保持不变
4. 记录当前session id，删除cookie，关闭标签页面，再次打开相同站点的相同页面，查看session id是否变化
结果：未关闭浏览器的情况下，session id保持不变
5. 记录当前session id，关闭所有浏览器，再次打开相同站点的相同页面，查看session id是否变化
结果：session id改变了
6. 不同类型的浏览器中，打开相同站点的相同页面，查看session id是否变化
结果：session id改变了
7. 第二天再次访问相同站点的相同页面，查看session id是否变化
结果：session id改变了
到此可以得出结论：
1. 通常,会话生存期为：
开始：客户端(通常是浏览器)--发送第一个请求-->服务器，彼此成功建立连接
结束：关闭客户端(通常是浏览器)或者会话超时
2. 不同浏览器访问相同站点时页面时，会生成不同的会话
3. 这里的cookie，保存在浏览器内存中不是写到硬盘上，我们称之为session cookie,session cookie针对某一次会话而言，会话结束,session cookie也就随着消失
注意：
1. 之所以说“通常”，是因为客户端发送页面请求不一定会创建会话，当server端程序调用了类似HttpServletRequest.getSession(true)这样的语句时，会话才真正被创建。
2. 访问本地xx.html页面，不会创建会话
关于“会话超时”
http协议中，客户机不再活跃时没有明确的终止信号.所 以借助超时来标识规定时间内不活跃的客户机，当不活跃时间超过规定时间时，自动结束会话，这样有助于节省资源。举个例子，当你登录一个网站，但是有事情， 离开电脑，老半天没进行网页浏览等与服务器交互的操作，当你回来时，点击某个超链接，它自动提示你要重新登录。这就是个典型的例子。
四、会话信息生存期
1. 当距离客户端上一次使用会话信息的时间超过了规定的“超时”时间，服务器就认为客户端已经停止了活动，自动删除保存的会话信息
2. 服务器程序调用HttpSession.invalidate()时，删除会话信息
3. 服务器关闭或服务停止(对非持久会话而言)，会删除会话信息
注意：除非客户端通知服务器删除会话变量，否则服务器不会主动删除。一般都是在用户做log off的时候发个指令去删除会话信息，浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，所以大部分会话机制都使用session cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的会话信息。所以，服务器为每个会话设置了一个失效时间，当距离客户端上一次使用会话信息的时间超过这个失效时间时，则把会话信息删除以节省存储空间。
但是如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。
测试验证：
访问某网站，获取请求头，方法，请求页面(可用firebug)
关闭浏览器，然后重新打开，手动编辑请求，发送请求，发现确实可以获取。
五、会话和cookie
采用网络上一个经典的比拟
某咖啡店对顾客推出促销活动：连续购买5杯咖啡，可赠送一杯，而通常消费者不会一次性买5杯的，所以不管任何时候，店家必须知道每位顾客的消费数量，才有办法判断是否满足赠送条件
有以下二种比较可行的处理方式：
1、给每位顾客一张卡片，上面记录着顾客消费的数量（一般还有个有效期限），每次消费时，如果顾客出示这张卡片，则此次消费就会与之前或以后的消费相联系起来--这种做法就是在客户端保持状态。
2、给每位顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息--这种做法就是在服务器端保持状态。
由于HTTP协议是无状态的，浏览器每次访问不同的web页面时，服务器都会去打开新的会话，而且服务器也不会自动维护客户的上下文信息(就是说你在这个页面存储的变量的值不会带到下一个页面去) ， 客户端只需要简单的向服务器请求获取资源，无论是客户端还是服务器都不纪录彼此过去的行为，每一次请求之间都是独立的，拿上述咖啡点的例子来说，也就是顾 客不记得之前什么时候去过咖啡店，购买了多少杯咖啡，店家也不记得顾客是否去过自家店，是否买过，买了多少杯咖啡等信息。
但是我们有时候，我们需要有状态，比如上面的咖啡店例子，再比如购物车机制，在某个页面把某物品放入购物车，当访问在其它页面时，依然可见该购物车中的物品，这就需要会话(session)这样一种保存上下文信息的机制，session是针对每一个用户的，通过session id来区分不同的用户
拿上述例子来说，
cookie采用的是在客户端保持状态的方案，而session采用的是在服务器端保持状态的方案，从咖啡店的例子来看，在服务器端保持状态会比较好。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识(session id)，所以session可能需要借助于cookie来达到保存标识的目的，之所以说可能，是因为还有其它途径，比如url重写