HTTP协议分析——状态与会话

会话与会话状态简介

WEB应用中的会话是指一个客户端浏览器与WEB服务器之间连续发生的一系列请求和响应的过程。
WEB应用的会话状态是指WEB服务器与浏览器在会话过程中产生的状态信息，借助会话状态，WEB服务器能把属于同一会话中的一系列请求和响应过程关联起来。

如何实现有状态的会话

HTTP协议是一种无状态的协议，WEB服务器本身不能识别哪些请求是同一个浏览器发出的，浏览器的每一次请求都是完全孤立的。
浏览器对自身发出的每一个请求消息进行标识，属于同一会话的请求消息附带相同的标识号，属于不同会话的请求消息附带不同的标识号，我们将这种标识号称为会话ID（Session ID）。WEB服务器端程序通过会话ID来识别来自同一个浏览器的访问请求。
会话ID可以通过Cookie技术在请求消息中进行传递，也可作为请求URL的附加参数进行传递。由于会话ID是WEB服务器为客户端浏览器分配的唯一代号，通常在WEB服务器接收到某个浏览器的第一次访问时产生，并随着响应消息一同发送给浏览器。
会话过程由服务器端的程序开启，当开启会话后，服务器端程序需要为这个会话创建一个独立的存储结构来保存该会话的状态信息，属于同一个会话的访问请求均可且只能访问属于该会话的存储结构中的状态信息。

Cookie

Cookie是一种在客户端保持HTTP状态信息的技术。
Cookie是当浏览器访问WEB服务器的某个资源时，由服务器在HTTP响应消息头中附带传送给浏览器的一片数据，WEB服务器传送给各个客户端浏览器的数据可以是各不相同的。
当WEB浏览器保存了某个Cookie，在以后的每次访问该WEB服务器时，都应在HTTP请求头中将这个Cookie回传给WEB服务器。
WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器；浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。
一个Cookie只能表示一种信息，其中至少包含一个标识该信息的名称（NAME）和设置值（VALUE）。
一个WEB站点可给一个WEB浏览器发送多个Cookie，一个WEB浏览器可以存储多个WEB站点提供的Cookie。
浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie.
每个Cookie的大小不超过4KB。

Cookie的传送过程示意图

在这里插入图片描述

Cookie的功能特点

存储于浏览器头部 / 传输于HTTP头部
写时带属性，读时无属性
HTTP头中Cookie:user=bob;cat=books;
由三元组[name,domain,path]唯一确定Cookie
唯一确定不等于Cookie唯一

Set-Cookie2响应头字段

Set-Cookie2头字段用于指定WEB服务器向客户端传送的Cookie内容，但按照Netscape规范实现Cookie功能的WEB浏览器，使用的时Set-Cookie头字段，两者的语法和作用类似。
Set-Cookie2头字段中设置的Cookie内容是具有一定格式的字符串，必须以Cookie的名称和设置值开头，格式为“名称=值”，后面可以加上0个或多个分号和空格隔开的其他可选属性，属性格式一般为“属性名=值”。
举例：Set-Cookie2:user=hello;Version=1;Path=/
除“名称=值”必须位于最前面外，其他的可选属性的先后顺序任意。
Cookie的名称只能由普通的英文ASCII字符组成，浏览器不需要理解Cookie的值部分的意义和格式，仅需要WEB服务器能理解即可。
大多数现有的WEB服务器都采用某种编码方式将值部分的内容编码成可打印的ASCII字符，RFC 2965规范中没有明确限定编码的方式。

Cookie请求头字段

Cookie请求头字段中的每个Cookie之间使用逗号或分号间隔
在Cookie请求头字段中除了必须的“名称=值”的设置外，还可以有Version、Path、Domain、Port等属性
在Version、Path、Domain、Port等属性名之前，需要增加“$”字符作为前缀
Version属性只能出现一次，且需要位于Cookie请求头字段设置值得最前面，但设置Path、Domain、Port等属性时，需要位于“名称=值”设置之后
浏览器使用Cookie请求头字段将Cookie信息回传给WEB服务器
多个Cookie信息可以通过一个Cookie请求头字段回传给WEB服务器
浏览器根据如下的规则决定是否发送某个Cookie信息：
> 请求的主机名是否与某个存储的Cookie的Domain属性匹配
> 请求的端口号是否在该Cookie的Port属性列表中
> 请求的资源路径是否在该Cookie的Path属性指定的目录及子目录
> 该Cookie的有效期是否已过
Path属性指向子目录的Cookie排在Path属性指向父目录的Cookie之前
举例：Cookie: $V e r s i o n = 1; C o u r s e = J a v a;$ Path=/hello/lesson;Course=vc;$Path=/hello

Cookie的安全属性

1、secure属性
当设置为true时，表示创建的Cookie会被以安全的形式传输到服务器，即只能在HTTPS连接中被浏览器传递到服务器端进行会话验证，若是HTTP连接则不会传递该信息，所以不会被窃取到Cookie的具体内容。
2、Http Only属性
若设置了“Http Only”属性，那么通过程序（JS脚本、Applet等）将无法读取到Cookie信息，能有效地防止XSS攻击

secure属性可以防止信息在传递的过程中被监听捕获后信息泄漏，Http Only属性可以防止程序获取Cookie后进行攻击
这两个属性并不能解决Cookie在本机出现的信息泄漏问题（Fire Fox的插件Fire Bug能直接看到Cookie的相关信息）

什么是Session

使用Cookie和附加URL参数都可将上一次请求的状态信息传递到下一次请求中，但若传递的状态信息较多，将降低网络传输效率、增大服务器端程序处理的难度
Session是一种将会话状态保存到服务器端的技术
客户端需要接收、记忆和回传Session的会话标识号，Session通常借助Cookie来传递会话标识号

Session的跟踪机制

Session API规范中定义了一个Http Session接口，通过此接口定义了各种管理和操作会话状态的方法
Http Session对象是保持会话状态信息的存储结构，一个客户端在WEB服务器端对应一个各自的Http Session对象
当客户端访问某个能与客户端开启会话的Servlet程序时，WEB应用程序才会创建一个与该客户端对应的Http Session对象
WEB服务器为Http Session对象分配一个独一无二的会话标识号，然后在响应消息中将会话标识号传递给客户端。客户端需要记住此会话标识号，并在后面的每次访问请求中将此会话标识号传送给WEB服务器，WEB服务器端程序通过回传的会话标识号来识别请求是从哪个客户端发出的，从而选择对应的Http Session对象
WEB应用程序创建了与客户端对应的Http Session对象后，只要未超出限定的空闲时间段，Http Session对象就驻留在WEB服务器内存中，该客户端后面访问任意的Servlet程序时，均使用与客户端对应的已存在的Http Session对象
Http Session接口中，使用setAttribute方法来将对象存储到Http Session对象中；使用getAttribute方法来检索存储在Http Session对象中的对象。存储进Http Session对象中的对象可以被属于同一个会话的各个请求的处理程序共享

Session的超时管理

WEB服务器无法判断当前的客户端浏览器是否会继续访问或是否已经关闭，所以即使客户端已经离开或关闭，WEB服务器仍要保留对应的Http session对象
随着不断增加的新的访问客户端，WEB服务器内存将会积累大量的不再被使用的Http Session对象，最终将导致服务器内存耗尽
WEB服务器采用“超时限制”的办法来判断客户端是否继续访问，若客户端在一定时间范围内未发出后续请求，WEB服务器将认为客户端已经停止活动，将结束与客户端的会话并将对应的Http Session对象变成垃圾
若客户端在超时之后再次发出访问请求，WEB服务器则认为这是一个新的会话的开始，将为其建立新的Http Session对象和分配新的会话标识号
会话的超时间隔可以在web.html文件中设置，其默认值由Servlet容器定义

利用Cookie实现Session跟踪

若WEB服务器处理某个访问请求时创建了新的Http Session对象，将会把会话标识号作为一个Cookie项加入到响应消息中，通常情况狂下，浏览器在随后发出的访问请求中又会将会话标识号以Cookie的形式回传给WEB服务器
WEN服务器依据回传的会话标识号得知以前已经为该客户端创建了Http Session对象，直接使用与该会话标识号匹配的Http Session对象，通过这种方式就是实现了对同一个客户端的会话状态的跟踪

利用URL重写实现Session跟踪

Servlet规范中加入了一种补充的会话管理机制，允许不支持Cookie的浏览器也可与WEB服务器保持连续的会话。这种补充机制要求在响应消息的实体内容中必须包含下一次请求的超链接，并将会话标识号作为超链接的URL地址的一个特殊参数
URL重写：将会话标识号以参数形式附加在超链接的URL地址后面。若浏览器不支持Cookie或者关闭了Cookie功能的情况下，WEB服务器还要能与浏览器实现有状态的会话，就需要对所有可能被客户端访问的请求路径（包括超链接、form表单的action属性设置和重定向的URL）进行URL重写
Http Servlet Response接口中定义了两个用于完成URL重写的方法
1 > encondeURL方法
2 > encodeRedirectURL方法

Cookie和Session的不同

Cookie和Session两者都是针对单独用户额变量，不同用户在访问网站时都会拥有各自的cookies或session，不同用户之间互不干扰。
不同点：

存储位置不同
> session在服务器端产生，比较安全，但session过多则会影响性能
> cookies在客户端产生，安全性较弱
生命周期不同
> session生命周期在指定的时间到了后会结束，不到指定的时间也会随着浏览器进程的结束而结束
> cookies默认情况下也随着浏览器进程的结束而结束，但若手动指定时间，则不受浏览器进程结束的影响。