写在开头的话:文档仅作抛砖引玉之用,请各抒己见,分享各自的真知灼见。
Cookie会话保持的理解
由于Web使用HTTP协议传输数据的,但是HTTP协议是无状态的协议,一旦数据交换完毕,客户端与服务器端的连接就会关闭,再次交换数据需要建立新的连接,这就意味着服务器无法从连接上跟踪会话。而理论上,一个用户的所有请求操作都应该属于同一个会话。
在此需求下,利用Cookie记录客户端信息确定用户身份,客户端在访问服务器的时候必须都带上Cookie,从而便于服务器确认客户端身份。
Cookie会话保持常用为三类: 1. Cookie插入 在Cookie插入模式下,由我司AD设备负责插入Cookie,后端服务器无需作出任何修改,在服务器的HTTP应答的头部中插入一个Cookie,记录被调度的服务器。
客户进行第一次请求时,客户HTTP请求(不带Cookie)进入AD应用交付设备,AD应用交付设备根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器,后端服务器进行HTTP回复(不带Cookie)被发回AD应用交付设备,然后AD应用交付设备插入Cookie,将HTTP回复返回到客户端。其中Cookie的名称为AD_RS_COOKIE,值为类似20080913的随机数字。
当客户请求再次发生时,客户HTTP请求(带有上次AD应用交付设备插入的Cookie)进入AD应用交付设备,然后AD应用交付设备读出Cookie里的会话保持数值,将HTTP请求(带有与上面同样的Cookie)发到指定的服务器,然后后端服务器进行请求回复,由于服务器并不写入Cookie,HTTP回复将不带有Cookie,恢复流量再次经过进入AD应用交付设备时,AD应用交付设备再次写入更新后的会话保持Cookie。
2. Cookie改写 服务器自己本身会插入Cookie,我们收到应答方向的服务器的Cookie后,会Cookie值改成某公司_RSID_AA(假设服务器本身插入的Cookie值为AA);下一次浏览器会带上这个Cookie值访问同样的作用域,当AD收到这个Cookie后,转发给服务器时会剥离掉某公司_RSID_,只剩下服务器本身插入的AA,从而实现透明的Cookie会话保持。
当客户进行第一次请求时,客户HTTP请求(不带Cookie)进入AD应用交付设备,AD应用交付设备根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器,后端服务器进行HTTP回复一个空白的Cookie并发回AD应用交付设备,然后AD应用交付设备重新在Cookie里写入会话保持数值,将HTTP回复返回到客户端。当客户请求再次发生时,客户HTTP请求(带有上次AD应用交付设备重写的Cookie)进入AD应用交付设备,然后AD应用交付设备读出Cookie里的会话保持数值,将HTTP请求(带有与上面同样的Cookie)发到指定的服务器,然后后端服务器进行请求回复,HTTP回复里又将带有空的Cookie,恢复流量再次经过进入AD应用交付设备时,AD应用交付设备再次写入更新后会话保持数值到该Cookie。
3. Cookie被动 通过服务器回复的SET-COOKIE,做一个会话表,下次调度,带相同Cookie的请求直接调度到原来的节点。 当客户进行第一次请求时,客户HTTP请求(不带Cookie)进入AD应用交付设备,AD应用交付设备根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器,后端服务器进行HTTP回复一个Cookie并发回AD应用交付设备,然后AD应用交付设备将带有服务器写的Cookie值的HTTP回复返回到客户端。当客户请求再次发生时,客户HTTP请求(带有上次服务器写的Cookie)进入AD应用交付设备,然后AD应用交付设备根据Cookie里的会话保持数值,将HTTP请求(带有与上面同样的Cookie)发到指定的服务器,然后后端服务器进行请求回复,HTTP回复里又将带有更新的会话保持Cookie,恢复流量再次经过进入AD应用交付设备时,AD应用交付设备将带有该Cookie的请求回复给客户端。
我的分享先到这,欢迎小伙伴们继续补充! |