會話持久性連接簡介： 會話保持是負載均衡器設備的一種機制，用於識別客戶端與伺服器之間交互過程的關連性，在進行負載均衡的同時還保證一系列相關連的訪問請求會保持分配到同一臺伺服器上｡針對不同的業務場景需要不同的會話保持配置，並且並不是所有業務系統都需要會話保持配置。以最典型的 HTTP 應用為例，在大多 ...
會話持久性連接簡介：
會話保持是負載均衡器設備的一種機制，用於識別客戶端與伺服器之間交互過程的關連性，在進行負載均衡的同時還保證一系列相關連的訪問請求會保持分配到同一臺伺服器上｡針對不同的業務場景需要不同的會話保持配置，並且並不是所有業務系統都需要會話保持配置。以最典型的 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插入方法的會話保持，不需要後端伺服器進行任何修改，真正基於會話的會話保持技術。還有大部分應用是基於介面的業務，其中並不是所有業務系統都需要會話保持，在需要會話保持的系統中，建議採用源地址會話保持，其中的超時時間的設置需要業務部門根據實際的業務需求評估出一個合理的值，長時間維護無效的會話保持條目會對負載均衡設備造成較大壓力。針對其他的應用場景需要和業務部門進行詳細溝通提出針對的會話保持方式才能夠合理的進行配置。
