会话持久性连接简介：
会话保持是负载均衡器设备的一种机制，用于识别客户端与服务器之间交互过程的关连性，在进行负载均衡的同时还保证一系列相关连的访问请求会保持分配到同一台服务器上｡针对不同的业务场景需要不同的会话保持配置，并且并不是所有业务系统都需要会话保持配置。以最典型的 HTTP 应用为例，在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上,此时就需要相应的会话保持策略来保证相关的请求始终被负载到后端的一台服务器。
常用会话保持技术介绍：
1.源地址会话持久性 (Source Address Affinity)：
源地址会话持久性（也称为简单持久性）仅基于源IP地址跟踪会话。当客户端请求连接发送到配置源地址持久性的虚拟服务器时，负载均衡会检查该客户端之前是否已连接，如果负载均衡设备已存在当前客户端的会话保持连接条目，负载均衡设备会将请求发送至后端相同服务器。源地址会话保持里另外一个很重要的参数就是连接超时值，会为每一个进行会话保持的会话设定一个超时时间，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，负载均衡将会将新的连接进行会话保持，并且重置超时时间，但如果这个时间间隔大于该超时值，负载均衡将会将新来的连接认为是新的会话会通过负载均衡算法重新选择后端服务器。
基于源地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些并发访问也要求通过负载均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。
- Cookie 会话保持 ：
Cookie会话持久性是使用存储在客户端计算机上的HTTP cookie，负载均衡设备将客户端请求始终发送至后端相同服务器。此功能需要负载均衡设备在七层负载模式下运行，通常cookie 会话保持设置为 HTTP Cookie插入方法，后端服务器无需任何修改，在基于浏览器访问的web 应用，中一般建议使用cookie 会话保持选项，能够后使用户在交互中，登录和和访问信息始终负载至后端相同服务器，此功能只能针对负载均衡七层模式下的http 协议的应用有效。
针对不同的场景有四种cookie持久性方法可供使用：
HTTP Cookie插入方法 (HTTP Cookie Insert)
HTTP Cookie重写方法 (HTTP Cookie Passive)
HTTP Cookie被动方法 (HTTP Cookie Rewrite)
Cookie哈希方法 (Cookie Hash)
HTTP Cookie插入方法:
客户端请求负载均衡设备，在负载均衡将请求返回客户端时，在HTTP 响应
标头的cookie 字插入负载均衡自定义的cookie 信息。在客户端再次访问时负载均衡设备通过HTTP 请求报文头部的cookie 信息将客户端请求始终发送至后端相同服务器。
HTTP Cookie重写方法：
HTTP Cookie重写方法，是指负载均衡器会截取从服务器发送到客户端的名为的 Cookie标头，并覆盖cookie的名称和值。新cookie名为负载均衡设备自定义的cookie 名称，一般包含处理连接的服务器的地址和端口。
HTTP Cookie被动方法 ：
负载均衡将请求发送至该服务器，后端服务器进行HTTP响应一个cookie并发回负载均衡设备，然后负载均衡设备将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入负载，然后负载根据cookie头里的cookie 信息，将HTTP请求发送至指定服务器，简单理解就是负载均衡设备通过服务器的定义的cookie 数据来定义会话保持条目。
Cookie哈希方法：
Cookie hash 方法是指负载均衡设备将服务器响应的客户端的cookie 信息与后端服务器IP地址和端口进行hash 。在客户端再次请求时根据包头里包含的cookie信息进行hash 将请求发送至后端指定服务器。
- 哈希会话保持(Hash persistence)：
哈希会话保持的一个基本概念就是将一个连接中的源 IP 和目的 IP 地址进行 Hash 计算，根据计算得到的结果并根据后台存在多少台服务器来选择将请求分配到某台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的源 IP地址被分配到的服务器是固定的。并且，哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定一个源 IP 被分配到那台服务器。哈希会话保持通常被用于一些特定场合，如要求客户端按照IP地址被固定分配的场合，或者在一些会话保持表查询的开销已经远远大于 Hash 计算开销的情况下，采用 hash 会话保持可以提高系统的处理能力和响应速度。在实际的应用场景中，针对后台采用 Cache 服务器的情况，还有对 URL 进行 Hash 的处理方式，将同一个 URL 的请求分配到同一台 Cache 服务器，这样，对后台的 Cache 服务器群组来说，每台 Cache 服务器上存放的内容都是不一样的，提高 Cache 服务器的利用率。
- 可编程控制的会话保持
在实际的使用过程中，我们往往可能遇到更加复杂的一些情况，一个最典型的情况就是会话的特征并不在一些通常的位置，或者通用的名称。而是一个自定义的名称在一个特定的位置，例如 weblogic，AAA 协议的应用......因此在支持编程自定义的负载均衡设备中，可以采用可编程控制方式来实现灵活的会话保持策略。
在可编程控制的会话保持中，会话保持主要由两个部分组成：
1. 会话保持的特征的获取
2. 将特征与后台服务器相对应
如下所示：
| rule WeblogicJSessionPersist { when HTTP_RESPONSE { //在服务器返回的时候触发事件 if { [HTTP::cookie exists "JSESSIONID"] } { //在返回内容的 Cookie 中查找 JESSIONID persist add uie [HTTP::cookie "JSESSIONID"] //将服务器与找到的 Cookie 内 容进行对应 } } when HTTP_REQUEST { //在客户端发起请求的时候触发事件 set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"] //在请求的 URI 中查找 jessionid 字符串，方法是获取从 URI 中找到 jsessionid 字符串，在该字符串之后开始获取内容直 到遇到分号结束（具体语法请参考 BIG-IP LTM-LTM 配置手册） if { $jsess != "" } { persist uie $jsess //如果找到，则查询会话保持表，根据匹配结果将请求发送到 对应的服务器上 } } } |
- 目的地址会话保持(Destination Address Affinity)：
顾名思义目的地址会话保持通过目的地址进行会话保持的技术，通常在负载均衡设备作为正向代理服务器时，将客户端发送的请求始终发送到相同网关时会选择目的地址会话保持，此功能不常用。
总结：
在大多数后台应用系统的设计中，没有实际考虑到将被应用于负载均衡的环境中，为了保持在用户访问时与单机运行环境的一致，因此，在负载均衡设备上必须采用会话保持功能。在基于http 协议访问的应用系统中，强烈建议采用 HTTP Cookie插入方法的会话保持，不需要后端服务器进行任何修改，真正基于会话的会话保持技术。还有大部分应用是基于接口的业务，其中并不是所有业务系统都需要会话保持，在需要会话保持的系统中，建议采用源地址会话保持，其中的超时时间的设置需要业务部门根据实际的业务需求评估出一个合理的值，长时间维护无效的会话保持条目会对负载均衡设备造成较大压力。针对其他的应用场景需要和业务部门进行详细沟通提出针对的会话保持方式才能够合理的进行配置。
