會話保持常見問題 -

會話保持的作用是什嗎？

將同一用戶端的會話請求轉寄給指定的一個後端伺服器處理。

在您進行傳統型負載平衡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，則證明負載平衡會話保持有效；反之則證明負載平衡會話保持有問題。