故事发生背景：客户业务系统是在公网提供WEB服务的网站，在客户的网络结构中，经过SSL安全网关后经过F5 BIGIP-LTM进行负载均衡。客户之前是由SSL安全网关进行业务负载，后来由于其他考量决定采用F5负载均衡的产品。但是上线F5后出现一个问题，流量经过F5后负载一直不均衡，流量主要集中在一台服务器节点上。SSL安全网关为信安世纪TLS/SSL卸载设备。

到达客户现象后，开始排查问题，很简单的思路，负载不均衡的主要影响因素之一就是F5上面的会话保持策略，进过查看配置后发现果然是源地址会话保持，询问客户的网络工程师后发现所有的客户端经过SSl安全网关后都会被转换成SSL安全网关的地址。这样流量经过F5后，对于F5来说都是从一个客户端来的，F5上又是采用的源地址会话保持的策略，所以经所谓的“同一个”客户端的请求始终保持在一台服务器节点上；

找到问题后的处理步骤：跟信安世纪厂家沟通是够可以不做地址转换，但是信安世纪厂家不愿意更改源地址透传，觉得改动太大，后来沟通的结果是让SSL网关将客户端源地址像F5一样将源地址插入到HTTP X-Forword-For字段中，F5通过irule的策略将流量请求中XFF中的源地址取出来做会话保持，irules策略：

但是通过irules打出log后看到XFF中的源地址也是同一个，醉了。客户最前面的NAT设备也会将地址映射为同一个IP，唉，，只能换种方法了。

第二阶段排查，将会话保持策略更换为cookie的方式。（可能有人会质疑，为什么不在一开始就使用cookie的保持方式，通过地址区分不开就要通过用户的cookie的方式，是因为我同事之前给这个客户远程过说换成cookie策略后负载依然不均衡，同时会带来另一个问题，就是应用系统访问慢。）

此时更换为cookie的会话保持策略就需要找到问题根源解决问题，这个时候就需要把策略更换别cookie的方式，同时抓包查找问题。

经过抓包分析后发下一个问题，客户的同一个TCP流中，存在多个用户的请求数据。造成F5在区分连接的负载均衡时无法发挥它的强大威力，变成了睁眼瞎。

数据包分析如下：

根据现象分析猜测是由于SSL安全网关采用了类似F5LTM的oneconnect（连接复用）功能，让用户与SSL安全网关的人沟通确认后，确实采用了此功能，由于之前用户没有F5设备，服务器负载是由SSL来做，所以默认的情况下采用了此配置，最后将此功能去掉后发现F5负载就变得均衡了。

oneconnect（也叫TCP连接复用TCP连接复用（TCP Connection Reuse））功能介绍：

TCP连接复用技术通过将前端多个客户的HTTP请求复用到后端与服务器建立的一个TCP连接上。这种技术能够大大减小服务器的性能负载，减少与服务器之间新建TCP连接所带来的延时，并最大限度的降低客户端对后端服务器的并发连接数请求，减少服务器的资源占用。

　　一般情况下，客户端在发送HTTP请求之前需要先与服务器进行TCP三次握手，建立TCP连接，然后发送HTTP请求。服务器收到HTTP请求后进行处理，并将处理的结果发送回客户端，然后客户端和服务器互相发送FIN并在收到FIN的ACK确认后关闭连接。在这种方式下，一个简单的HTTP请求需要十几个TCP数据包才能处理完成。

　　采用TCP连接复用技术后，客户端（如：ClientA）与负载均衡设备之间进行三次握手并发送HTTP请求。负载均衡设备收到请求后，会检测服务器是否存在空闲的长连接，如果不存在，服务器将建立一个新连接。当HTTP请求响应完成后，客户端则与负载均衡设备协商关闭连接，而负载均衡则保持与服务器之间的这个连接。当有其它客户端（如：ClientB）需要发送HTTP请求时，负载均衡设备会直接向与服务器之间保持的这个空闲连接发送HTTP请求，避免了由于新建TCP连接造成的延时和服务器资源耗费。

　　在HTTP 1.0中，客户端的每一个HTTP请求都必须通过独立的TCP连接进行处理，而在HTTP 1.1中，对这种方式进行了改进。客户端可以在一个TCP连接中发送多个HTTP请求，这种技术叫做HTTP复用（HTTP Multiplexing）。它与TCP连接复用最根本的区别在于，TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。

更多F5技术支持欢迎联系Q：1247951665