重提cookie和session的学习
客户端session与服务端session
关于HttpSession的误解实在是太多了，本来是一个很简单的问题，怎会搞的如此的复杂呢？下面说说我的理解吧：
1、HTTP协议本身是“连接-请求-应答-关闭连接”模式的，是一种无状态协议（HTTP只是一个传输协议）；
2、Cookie规范是为了给HTTP增加状态跟踪用的（如果要精确把握，建议仔细阅读一下相关的RFC），但不是唯一的手段；
3、所谓Session，指的是客户端和服务端之间的一段交互过程的状态信息（数据）；这个状态如何界定，生命期有多长，这是应用本身的事情；
4、由于B/S计算模型中计算是在服务器端完成的，客户端只有简单的显示逻辑，所以，Session数据对客户端应该是透明的不可理解的并且应该受控于服务端；Session数据要么保存到服务端（HttpSession），要么在客户端和服务端之间传递（Cookie或url rewritting或Hidden input）；
5、由于HTTP本身的无状态性，服务端无法知道客户端相继发来的请求是来自一个客户的，所以，当使用服务端HttpSession存储会话数据的时候客户端的每个请求都应该包含一个session的标识(sid, jsessionid 等等)来告诉服务端；
6、会话数据保存在服务端（如HttpSession）的好处是减少了HTTP请求的长度，提高了网络传输效率；客户端session信息存储则相反；
7、客户端Session存储只有一个办法：cookie(url rewritting和hidden input因为无法做到持久化，不算，只能作为交换session id的方式，即a method of session tracking)，而服务端做法大致也是一个道理：容器有个session管理器（如tomcat的org.apache.catalina.session包里面的类），提供session的生命周期和持久化管理并提供访问session数据的api；
8、使用服务端还是客户端session存储要看应用的实际情况的。一般来说不要求用户注册登录的公共服务系统（如google）采用cookie做客户端session存储（如google的用户偏好设置），而有用户管理的系统则使用服务端存储。原因很显然：无需用户登录的系统唯一能够标识用户的就是用户的电脑，换一台机器就不知道谁是谁了，服务端session存储根本不管用；而有用户管理的系统则可以通过用户id来管理用户个人数据，从而提供任意复杂的个性化服务；
9、客户端和服务端的session存储在性能、安全性、跨站能力、编程方便性等方面都有一定的区别，而且优劣并非绝对（譬如TheServerSide号称不使用HttpSession，所以性能好，这很显然：一个具有上亿的访问用户的系统，要在服务端数据库中检索出用户的偏好信息显然是低效的，Session管理器不管用什么数据结构和算法都要耗费大量内存和CPU时间；而用cookie，则根本不用检索和维护session数据，服务器可以做成无状态的，当然高效）；
另外，经常在论坛看到或听到同事说ie关掉了，session就没了，而且还争论的唾沫横飞，偶就感到很好玩，只能不置可否地笑笑。这里只提示一下：以Ctrl+N或Shit+点击链接方式打开的IE窗口是运行在同一个进程空间的，cookie数据在进程空间中是共享的，而双击桌面上的ie图标打开的是一个新的进程，会话级的cookie（未明确指定生存期的cookie）在新的IE窗口里面是无法访问到的。
=============================
以前遇到一个问题，在服务端通过Page.Request.Params["Language"]得到的字符串为“English,English”，而我在客户端传递时千真万确是：
xhttp.open("POST", "RYXZ.aspx?Language=English", false);
最后我是通过加一个子程序来修补好。
今天又遇到服务端Page.Request.Params["GH"]得到的字符串为“10335,10335”，实在是欺负人。但今天刚好在调整cookie，才发现GH的一部分是通过QueryString传过来的，另一部分则是保存在客户端的cookie传过来。而我设的cookie名称刚好是GH，与QueryString的相同：
xhttp.open("POST", "Login.aspx?GH=10335", false);
……
SaveCookie("GH", "10335", 30);
知道原因了，以后Cookie的名称要特别指定，前面都要加一个ce。
关于HttpSession的误解实在是太多了，本来是一个很简单的问题，怎会搞的如此的复杂呢？下面说说我的理解吧：
1、HTTP协议本身是“连接-请求-应答-关闭连接”模式的，是一种无状态协议（HTTP只是一个传输协议）；
2、Cookie规范是为了给HTTP增加状态跟踪用的（如果要精确把握，建议仔细阅读一下相关的RFC），但不是唯一的手段；
3、所谓Session，指的是客户端和服务端之间的一段交互过程的状态信息（数据）；这个状态如何界定，生命期有多长，这是应用本身的事情；
4、由于B/S计算模型中计算是在服务器端完成的，客户端只有简单的显示逻辑，所以，Session数据对客户端应该是透明的不可理解的并且应该受控于服务端；Session数据要么保存到服务端（HttpSession），要么在客户端和服务端之间传递（Cookie或url rewritting或Hidden input）；
5、由于HTTP本身的无状态性，服务端无法知道客户端相继发来的请求是来自一个客户的，所以，当使用服务端HttpSession存储会话数据的时候客户端的每个请求都应该包含一个session的标识(sid, jsessionid 等等)来告诉服务端；
6、会话数据保存在服务端（如HttpSession）的好处是减少了HTTP请求的长度，提高了网络传输效率；客户端session信息存储则相反；
7、客户端Session存储只有一个办法：cookie(url rewritting和hidden input因为无法做到持久化，不算，只能作为交换session id的方式，即a method of session tracking)，而服务端做法大致也是一个道理：容器有个session管理器（如tomcat的org.apache.catalina.session包里面的类），提供session的生命周期和持久化管理并提供访问session数据的api；
8、使用服务端还是客户端session存储要看应用的实际情况的。一般来说不要求用户注册登录的公共服务系统（如google）采用cookie做客户端session存储（如google的用户偏好设置），而有用户管理的系统则使用服务端存储。原因很显然：无需用户登录的系统唯一能够标识用户的就是用户的电脑，换一台机器就不知道谁是谁了，服务端session存储根本不管用；而有用户管理的系统则可以通过用户id来管理用户个人数据，从而提供任意复杂的个性化服务；
9、客户端和服务端的session存储在性能、安全性、跨站能力、编程方便性等方面都有一定的区别，而且优劣并非绝对（譬如TheServerSide号称不使用HttpSession，所以性能好，这很显然：一个具有上亿的访问用户的系统，要在服务端数据库中检索出用户的偏好信息显然是低效的，Session管理器不管用什么数据结构和算法都要耗费大量内存和CPU时间；而用cookie，则根本不用检索和维护session数据，服务器可以做成无状态的，当然高效）；
另外，经常在论坛看到或听到同事说ie关掉了，session就没了，而且还争论的唾沫横飞，偶就感到很好玩，只能不置可否地笑笑。这里只提示一下：以Ctrl+N或Shit+点击链接方式打开的IE窗口是运行在同一个进程空间的，cookie数据在进程空间中是共享的，而双击桌面上的ie图标打开的是一个新的进程，会话级的cookie（未明确指定生存期的cookie）在新的IE窗口里面是无法访问到的。
=============================
以前遇到一个问题，在服务端通过Page.Request.Params["Language"]得到的字符串为“English,English”，而我在客户端传递时千真万确是：
xhttp.open("POST", "RYXZ.aspx?Language=English", false);
最后我是通过加一个子程序来修补好。
今天又遇到服务端Page.Request.Params["GH"]得到的字符串为“10335,10335”，实在是欺负人。但今天刚好在调整cookie，才发现GH的一部分是通过QueryString传过来的，另一部分则是保存在客户端的cookie传过来。而我设的cookie名称刚好是GH，与QueryString的相同：
xhttp.open("POST", "Login.aspx?GH=10335", false);
……
SaveCookie("GH", "10335", 30);
知道原因了，以后Cookie的名称要特别指定，前面都要加一个ce。
