會話保持是負載均衡的一個基本功能，也是我們在很多負載均衡項目實施中經常遇到的一個功能。爲了確保與某個客戶相關的所有應用請求能夠由同一臺服務器進行處理，我們需要在負載均衡上啓用會話保持（Session Persistence）功能，以確保負載均衡的部署不會影響到正常的業務處理。
有關會話保持功能的細節，大家可以參考我以前的文章：
我們知道，常見的會話保持有兩種：Cookie會話保持和源地址會話保持，對A10來說還可以用aFleX腳本來實現會話保持功能。但是，我在最近碰到的一個案例中卻發現，這三種會話保持功能都失靈了。最終，我通過仔細的分析，發現了這幾種會話保持功能失效的原因，並幫助用戶實現了會話保持功能。讓我們還是像偵探一樣，看看到底發生了什麼問題。
事情的由來
話說某一天上午，銷售說有個用戶那邊需要上負載均衡產品，但是部署了某知名負載均衡品牌的設備後，發現客戶端登錄之後，切回到主頁面發現客戶端仍然顯示爲未登錄狀態。各位看官應該明白，這是典型的沒有啓用會話保持或者會話保持機制沒有生效的原因。銷售說代理商那邊折騰了兩天沒解決問題，問我們是否有解決方案。
我想，我們的機會來了。
說實話，會話保持無外乎那幾種解決方式，正在測試的這個知名品牌在這方面的功能也比較完善，但爲啥這個功能運行起來就一直有問題呢？我也不太瞭解。廢話少說，大家隨我一起去探查一番吧。
抽絲剝繭
帶着設備到現場之後，發現某知名廠商的工程師還在現場調試。打開應用頁面測試了一下，發現果然會話保持有問題。與現場的工程師聊了一下，發現常見的幾種會話保持功能都已經試過了，但是結果都一樣：用戶登錄後，切換回主頁面，仍然顯示未登錄狀態。
看起來情況的確比較詭異，先了解一下整個應用場景的拓撲吧。
客戶端要訪問應用服務器，中間需要經過兩個重要的環節：
1） 用戶購買了專業的CDN服務，用來緩解應用服務器壓力。客戶端的所有請求，都會發送到CDN，CDN會根據請求的類型來決定是從本地緩存中直接返回還是送往源站點。
2） CDN送往源站點的請求，實際是送給負載均衡設備，由負載均衡設備分發至多臺應用服務器。
最爲重要的是，在這兩個環節中，都啓用了源地址轉換（Source NAT），也就是說：應用服務器看到的源地址是負載均衡的，而負載均衡看到的源地址是CDN的。
瞭解到這個信息，我已經基本確定，源地址會話保持在這種場景下是無效的。原因很簡單：
1） CDN的緩存服務器肯定不止1臺
2） CDN的緩存服務器前端也會部署負載均衡
3） 同一客戶端的請求會分發到不同的緩存服務器
基於以上三個原因，在負載均衡上開啓源地址會話保持根本無法保證同一客戶端的請求都轉發至後端相同的應用服務器。
好吧，在沒有進行配置，只是紙上推演，就已經斃掉了源地址會話保持，我們還有Cookie會話保持，以及aFleX腳本會話保持。
窮途末路
接下來，便是與應用開發的人員討論A10負載均衡部署的問題。但討論的結果卻讓我也陷入了絕境，我終於體會到爲什麼“著名負載均衡廠商”也搞不定的原因了。
好吧，不難爲大家了，直接說明應用開發人員的要求：
1） 在客戶端與服務器的交互過程中，需要使用兩種協議：商品的瀏覽挑選使用HTTP，而用戶登錄以及下單需要使用加密的HTTPS。
2） 由於這兩個應用協議之間是有交互的，因此需要將同一客戶端的所有HTTP和HTTPS請求，都轉發到同一臺服務器進行處理
3） 由於後端服務器的開發組件的限制，後端服務器不接受HTTP請求類型，也就是說，如果客戶端請求的是加密的HTTPS類型，那麼負載均衡向後端服務器轉發的也必須是加密的HTTPS請求。
如果不考慮CDN進行了源地址轉換的問題，對於第1）和2）兩點要求，無論是Cookie會話保持還是源地址會話保持，在AX上只要在會話保持模板中設置match-type爲Server，即可保證客戶端發往同一VIP，但是在不同端口的應用，都會會話保持到同一臺服務器。
因此，我們決定採用SSL卸載並啓用Cookie會話保持功能來實現用戶的要求。但是，當完成配置進行測試時，我們發現客戶端的HTTPS請求會發生302重定向環路問題，訪問仍然是不正常的。經過分析並且與應用開發人員進行溝通，我們最終發現在本項目部署中還隱藏了上面的要求3）。
在發現這種情況時，“某著名廠商”的工程師提出，應用有問題，讓應用開發人員去檢查應用是否有問題。但我沒有這麼武斷，而是和應用開發人員進行了一些溝通，然後，就發現了產生環路的原因。其實很簡單：
1） 當用戶需要進行登錄認證時，點擊登錄，會發送一個HTTPS的URL到服務器；
2） 當客戶端的請求到達負載均衡後，進行SSL卸載，請求被轉換成HTTP，然後轉發至服務器；
3） 服務器檢測到請求是HTTP的，而不是HTTPS，就會對當前請求的URL做重定向，由HTTP重定向到HTTPS；
4） 客戶端收到重定向請求，發送HTTPS請求至服務器；
5） 然後回到上面的第2）步，產生環路。
好吧，我們彙總一下：
1） 由於CDN的存在，導致源地址會話保持無法使用；
2） 通常情況下，當後端服務器上採用HTTPS加密，而不需要負載均衡做SSL卸載時，我們把這些應用直接作爲TCP協議類型進行處理，但在這種情況下，Cookie會話保持也會失效；
3） 當然，aFleX腳本也需要檢測到實際的HTTP/HTTPS請求，所以，在這裏腳本也無法使用。
柳暗花明
測試到這裏，已經是臨晨3點多了，大家都是疲憊不堪。我又開始調整部署方案。最終的解決方案則是在前面的方案中又增加了服務器端SSL加密。
如上圖所示：
1） 客戶端仍然是發送經過SSL加密的HTTPS請求，當請求到達AX時，由AX進行SSL卸載；
2） 經過SSL卸載後請求，由AX進行處理，AX可以檢查HTTP頭部的cookie，來判斷請求是否需要進行Cookie會話保持處理；
3） 當HTTP請求離開AX之間，由AX對請求再次進行加密，並轉發至應用服務器。
由於應用服務器收到的請求仍然是經過SSL加密的，因此，302重定向環路的問題解決了，會話保持的問題也解決了。
到此，故事講完了。其實，
產品並不重要，重要的是你如何去使用。
配置也不重要，重要的是你要了解其中的原理。
E.S.