（接续）  上一部分的文章我们简单描述了一下会话保持的应用场景和作用，以及最常用的基于源IP地址的会话保持原理和AX设备上的相关配置，本次就其它几种常用的会话保持方式，我们继续做个简单的介绍。

2. 基于Cookie的会话保持

        Cookie是一种在HTTP应用中普遍采用的一种技术，Cooike 有效的改进了HTTP协议的无状态性，它就好像我们在日常生活中经常使用的会员卡、信用卡等此类标识使用者身份的卡片，通过该卡片的个人信息和有效期来判断使用者的身份和有效性。Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中插入并附带传送给客户端浏览器的一个数据字段，WEB服务器传送给各个客户端的数据可以各不相同。一旦WEB浏览器保存了Cookie数据，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这个Cookie数据回传给WEB服务器。显然，Cookie最先是由服务器端发出的，Cookie值也由服务器端根据不同用户有所区别，某种程度上来说，其具有唯一性，因此能够作为标识不同客户端的一种手段。例如，当用户使用浏览器访问某个网站的登录程序进行登录后，无论这个浏览器再访问该网站的哪个应用或者程序，该系统都能知道访问者的身份信息。

        当采用基于源地址的会话保持无法做到负载均分时，例如客户端发起连接请求的源IP地址相对固定，发生此类问题通常可采用基于应用层的会话保持方式，Cookie通常是存在于HTTP头中，现如今基于HTTP的应用被广泛使用，因此基于Cookie的会话保持越来越多的出现在ADC解决方案中。

        根据Cookie的这一特性，ADC产品可以通过两种方式实现基于Cookie的会话保持：

第一种，ADC设备在客户端和服务器的会话过程中，主动生成和插入一个Cookie，并根据此Cookie值实现会话保持。

        在这种模式下，往往服务器端在应答请求时，是不需要主动生成和插入Cookie的。在客户端第一次向ADC设备上的虚拟服务器（VIP）发起请求时，按照负载均衡算法，ADC选择后端某一台服务器，并将请求发送至该服务器，后端服务器对该请求进行回复（不带cookie）并将回复发回ADC设备，之后ADC设备插入一个cookie，将回复发送给客户端。当客户端再次发起请求时，客户HTTP请求带着此前ADC设备主动插入的Cookie值到达ADC设备，ADC设备在HTTP头中读出cookie里的数值，将带有相同Cookie值的HTTP请求发到指定的相同服务器，后端服务器进行请求回复。

      在AX设备上启用这种方式的Cookie会话保持功能配置非常简单，只需按照下图所示，两个步骤即可完成。

第一步，创建Cookie会话保持模板：

该模板参数中：

总是插入：－－是指无论客户端请求中是否已经带着AX插入的Cookie，每次应答时总是插入一个新的会话保持Cookie；

第二步，在虚拟服务器VIP下，启用该Cookie 保持模板（该模板仅应用于HTTP或Fast HTTP端口类型）：

第二种，ADC设备在客户端和服务器的会话过程中，提取服务器生成和插入的Cookie，并根据该Cookie值实现会话保持。

        在这种模式下，服务器端在应答客户端的请求时，会主动生成和插入Cookie。当客户端第一次向ADC设备上的虚拟服务器（VIP）发起请求时，按照负载均衡算法，ADC选择后端某一台服务器，并将请求发送至该服务器，该服务器对该请求生成和插入一个cookie，并将此次回复发回ADC设备，ADC设备读取服务器端插入的cookie值，生成一条包含该Cookie值的会话保持条目，之后将回复发送给客户端。当客户端带着同一个Cookie再次发起请求时，ADC设备在该请求数据包的HTTP头中读出cookie里的数值，在会话保持表中进行匹配，将带有相同Cookie值的HTTP请求发到相同服务器，后端服务器进行请求回复时，可更新插入一个新的Cookie或者维持原有Cookie不变。

        在AX设备上启用这种方式的Cookie会话保持功能配置需编译一个aFleX脚本，类似下图所示，也是两个步骤即可完成。

第一步，创建基于服务器端插入Cookie的会话保持脚本（以服务器端插入名为Session-id的Cookie为例）：

第二步，在虚拟服务器VIP下，启用该aFleX脚本：

3. 基于URL哈希（Hash）会话保持

        哈希会话保持的一个基本概念就是按照某个Hash因子，根据此因子以及后台存在多少台服务器计算得到的结果来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的Hash因子被分配到的服务器是固定的。其最大的优势是哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定被分配到那台服务器，尤其在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用Hash会话保持可以提高系统的处理能力和响应速度。 
        URL哈希会话保持通常针对后台采用Cache服务器的应用场景，针对URL进行Hash计算，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。

        在AX设备上启用URL哈希会话保持功能配置非常简单，只需按照下图所示，两个步骤即可完成。

第一步，在HTTP模板中，创建URL哈希会话保持模板：

在该模板参数中勾选【URL Hash 】：

选择”第一个“或者”最后一个“－－是指计算URL哈希是从URI的第一个字节开始，还是从最后一个字节开始；

填写框中的数字“16”－－是指提取URI的长度，单位为字节，可在4～128字节间根据业务需要确定一个合适的长度；

第二步，在虚拟服务器VIP下，启用该URL哈希保持模板（该模板仅应用于HTTP或Fast HTTP端口类型）：

本文两部分阐述了几种在A10 AX部署方案中较常用的几种会话保持方式，在个别场景还有AX设备还能够基于SSL Session ID，或者基于目的IP地址进行会话保持，也能够利用aFleX脚本功能，通过编程按照特定的标识段，进行会话保持。本文就暂时不继续论述了，如果观者想了解，再择机继续叙述。

 

S.G

本文转自 virtualadc 51CTO博客，原文链接:http://blog.51cto.com/virtualadc/585301