会话保持常见问题 -

会话保持的作用是什么？

将同一客户端的会话请求转发给指定的一个后端服务器处理。

在您进行传统型负载均衡CLB监听配置时就可以选择是否开启会话保持。您可以针对不同的监听配置不同的会话保持策略。会话保持的最长时间是86400秒（24小时）。

HTTP/HTTPS监听可使用植入Cookie和重写Cookie来进行会话保持。

植入Cookie: 此种方法下，您只需要指定Cookie的过期时间。客户端第一次访问时，CLB在返回请求中植入Cookie（即在HTTP/HTTPS响应报文中插入SERVERID字串），下次客户端携带此Cookie访问，CLB会将请求定向转发给之前记录到的ECS实例上。
重写Cookie：此种方式下，您可以根据需要指定HTTPS/HTTP响应中插入的Cookie。您需要在后端ECS上维护该Cookie的过期时间和生存时间。CLB发现用户自定义了Cookie，将会对原来的Cookie进行重写，下次客户端携带新的Cookie访问，CLB会将请求定向转发给之前记录到的ECS实例上。服务器配置参考配置会话保持规则。

支持。

您可以通过CLB提供的重写Cookie的会话保持方式来实现这一需求。

可以在浏览器中用F12查看回应报文中是否含有SERVERID字符串或用户指定的关键字，或者运行curl www.example.com -c /tmp/cookie123 保存一下Cookie，再用 curl www.example.com -b /tmp/cookie123访问。

查看是否在监听配置中已经开启了会话保持功能。
HTTP或HTTPS监听在后端服务器返回4xx响应码的报文中无法插入会话保持所需Cookie。
解决方案：改用TCP监听，因为TCP监听是以源客户端的IP来做会话保持的，另外后端ECS上也可以插入Cookie，并增加Cookie的判断来多重保障。
302重定向会改变会话保持中的SERVERID字串。
负载均衡植入Cookie时，如果后端ECS中有回复302重定向的报文，将改变会话保持中的SERVERID字串，导致会话保持失效。

排查方法：在浏览器端捕抓请求与响应的回复，或用抓包软件抓包后分析是否存在302的响应报文，对比前后报文的Cookie中的SERVERID字串是否不同了。

解决方案：改用TCP监听，因为TCP监听是以源客户端的IP来做会话保持的，另外后端ECS上也可以插入Cookie，并增加Cookie的判断来多重保障。
会话保持时间设置过小，会话保持时间过小也会导致会话保持失败。

创建测试页面。
在负载均衡所有后端ECS中创建测试页面，如下图所示页面中能显示本机内网IP。内网IP用于判断相应请求被指派到的物理服务器。通过观察该IP的一致性，来判断负载均衡会话保持的有效性。
Linux系统内执行curl命令。
假设负载均衡服务IP地址是 10.170.XX.XX，创建的测试页面URL为： http://10.170.XX.XX/check.jsp。
1. 登录用来测试的Linux服务器。
2. 执行以下命令查询负载均衡服务器Cookie值。
```
curl -c test.cookie http://10.170.XX.XX/check.jsp
```
  说明阿里云负载均衡会话保持默认模式是植入Cookie，而curl测试默认不会保存和发送Cookie，所以必须先保存相应的Cookie，用于Cookie测试。否则，curl测试结果是随机的，会误认为负载均衡会话保持无效。
3. 执行以下命令持续测试。
```
for ((a=1;a<=30;a++));
    do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
    sleep 1;
done
```
  说明 a≤30是重复测试次数，可以按需修改。grep '10.170.XX.XX' 是筛选显示的IP信息，根据后端ECS内网IP情况进行相应修改。
4. 观察上述测试返回的IP，如果是同一台ECS内网IP，则证明负载均衡会话保持有效；反之则证明负载均衡会话保持有问题。