1. cookie
a. cookie的属性项（version1）
i. NAME=VALUE
ii. version
iii. comment——注释项
iv. commentURL——服务器为此cookie提供的URI注释
v. discard——是否会话结束后丢弃该cookie
vi. domain——生成cookie的域名
vii. max-age——最大失效时间
viii. path——生成cookie的路径
ix. port——cookie在什么端口下可以回传服务端
x. secure——若设置该属性，只在SSH连接时才回传该cookie
b. cookie如何工作
i. tomcat服务器中cookie的真正构建实在response类中
ii. cookie的name不能和属性项值一样
iii. cookie的name和value不能设置为非assic字符，若用中文，通过URLEncoder编码
2. session
a. 客户端与服务器交互，不需要每次传回所有cookie，只要传回一个客户端第一次访问服务器时候生成的ID，通常是name为JSESSIONID的一个cookie
b. session工作方式
i. Session ID
1. 基于URL Path Parameter——当浏览器不支持cookie，便将SessionCookieName重写到用户请求的URL参数中
2. 基于cookie
3. 基于SSL
ii. Session如何工作
1. Session ID若没有对应的HttpSession对象，则创建一个新的
2. org.apache.catalina.Manager中有sessions容器，管理session的生命周期
3. 当servlet容器重启或者关闭时，StandardManager负责持久化没有过期的StandardSession对象
4. 要持久化保存Servlet中的session对象，必须调用servlet容器的stop和start命令，而不能直接kill
5. 每个Session对象有一个有效时间
3. 分布式session框架
a. 可以解决的问题
i. session配置的统一管理
ii. cookie使用的监控和同意规范管理
iii. session存储的多元化
iv. session配置的动态修改
v. session加密key的定期修改
vi. 充分的容灾机制，保持框架的使用稳定性
vii. session各种存储的监控和报警支持
viii. session框架的可扩展性，兼容更多的session机制
ix. 跨域名session与cookie共享问题
b. 总体实现思路
i. 配置和存储
1. 通过服务订阅服务器精确控制哪些应用可以操作哪些session与cookie
2. 统一通过订阅服务器推送配置可以有效集中管理资源
3. 每个应用都使用的全局cookie，由订阅服务器统一推送，不需每个应用中单独手动添加
4. 开源的配置服务器如zookeeper集群管理服务，可以统一管理所有服务器的配置文件
5. 服务器集群共享需要session，必须将它们存储到一个分布式缓存中
ii. Session与Cookie的存取
1. SessionFilter在用户请求到达MVC之前，封装HttpServletRequest和HttpServletResponse
2. 应用创建的所有session对象都保存在InnerHttpSession对象中，用户请求完成时，更新到分布式缓存
3. 为保证一些应用对session稳定性的特殊需求，将一些关键的session再存储到Cookie中
iii. 跨域名同步session
1. 要实现session同步，需要另外一个跳转应用，从一个域名下去的sessionID，同步到另一个域名下
2. 要实现两个域名下的session同步，要将同一个sessionID作为cookie写到两个域名下
4. Cookie压缩
a. cookie在http的头部
b. 若cookie量很大，可以考虑将cookie的多个k/v看成普通文本作文本压缩
c. 根据cookie 的规范，其中不能包含控制字符，仅能包含ASCII为34~126的可见字符
5. 表单重复提交问题
a. 标识用户的每一次访问请求，似的每一次访问对服务端来说都是唯一确定的
b. 标识方法：在用户请求一个表单域时增加一个隐藏的表单项，其值每次都是唯一的token
c. 用户提交表单时会带上token，和session中保存的token做对比，确认这次表单验证是否合法
6. 多终端session统一
a. 应用场景
i. 无线端通过手机访问无线服务端系统，同时访问PC端服务系统，若登录不统一，出现二次登录情况
ii. 手机上登录后，再在PC上同样访问服务端数据，session能否共享决定客户端是否需要再次登录
b. 解决方案
i. 多端共享session
1. 无论无线还是PC，后端服务系统统一会话架构，基于会员数据结构、Cookie与Session的统一
ii. 多终端登录
1. 手机端扫码前必须是已登录状态，二维码上有已登录的标识
2. PC客户端通过将心跳请求发送到服务端，验证是否已经登录
7. 总结
a. cookie与session都是为了保持用户访问的连续状态
b. 连续状态一方面为了方便业务实现，一方面简化服务端程序设计
