F5會話保持技術原理白皮書(摘取)
F5負載均衡會話保持技術及原理技術白皮書
1.什麼是會話保持?
在大多數電子商務的應用系統或者需要進行使用者身份認證的線上系統中,一個客戶與伺服器經常經過好幾次的互動過程才能完成一筆交易或者是一個請求完成。由於這幾次互動過程是密切相關的,伺服器在進行這些互動過程的某一個互動步驟時,往往需要了解上一次互動過程的處理結果,或者上幾步的互動過程結果,伺服器進行下一步操作時需要這就要求所有這些相關的互動過程都由一臺伺服器完成,
而不能被負載均衡器分散到不同的伺服器上。而這一系列的相關的互動過程可能是由客戶到伺服器的一個連線的多次會話完成,也可能是在客戶與伺服器之間的多個不同連線裡的多次會話完成。不同連線的多次會話,最典型的例子就是基於http的訪問,一個客戶完成一筆交易可能需多次點選,而一個新的點選產生的請求,可能會重用上一次點選建立起來的連線,也可能是一個新建的連線。
會話保持就是指在負載均衡器上有這麼一種機制,可以識別做客戶與伺服器之間互動過程的關連性,在作負載均衡的同時,還保證一系列相關連的訪問請求會保持分配到一臺伺服器上。
2.F5支援什麼樣的會話保持方法
F5 BigIP支援多種的會話保持方法,其中包括:簡單會話保持(源地址會話保持)、HTTP Header的會話保持,基於SSL Session ID的會話保持,I-Rules會話保持以及基於HTTP Cookie的會話保持,此外還有基於SIP ID以及Cache裝置的會話保持等,但常用的是簡單會話保持,HTTP Header的會話保持以及HTTP Cookie會話保持以及基於I-Rules的會話保持。
2.1 簡單會話保持
簡單會話保持也被稱為基於源地址的會話保持,是指負載均衡器在作負載均衡時是根據訪問請求的源地址作為判斷關連會話的依據。對來自同一IP地址的所有訪問請求在作負載均時都會被保持到一臺伺服器上去。在BIGIP裝置上可以為“同一IP地址”透過網路掩碼進行區分,比如可以透過對IP地址192.168.1.1進行255.255.255.0的網路掩碼,這樣只要是來自於192.168.1.0/24這個網段的流量BIGIP都可以認為他們是來自於同一個使用者,這樣就將把來自於192.168.1.0/24網段的流量會話保持到特定的一臺伺服器上。簡單會話保持裡另外一個很重要的引數就是連線超時值,BIGIP會為每一個進行會話保持的會話設定一個時間值,當一個會話上一次完成到這個會話下次再來之前的間隔如果小於這個超時值,BIGIP將會將新的連線進行會話保持,但如果這個間隔大於該超時值,BIGIP將會將新來的連線認為是新的會話然後進行負載平衡。
基於原地址的會話保持實現起來簡單,只需要根據資料包三、四層的資訊就可以實現,效率也比較高。存在的問題就在於當多個客戶是透過代理或地址轉換的方式來訪問伺服器時,由於都分配到同一臺伺服器上,會導致伺服器之間的負載嚴重失衡。另外一種情況上客戶機數量很少,但每個客戶機都會產生多個併發訪問,對這些必發訪問也要求透過負均均衡器分配到多個服器上,這時基於客戶端源地址的會話保持方法也會導致負載均衡失效。
2.2 基於Cookie的會話保持
2.2.1 cookie
插入模式:在Cookie插入模式下,BigIP將負責插入cookie,後端伺服器無需作出任何修改.當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆(不帶cookie)被髮回BIGIP,然後BIGIP
插入cookie,將HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP插入的cookie)進入BIGIP,然後BIGIP讀出cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,由於伺服器並不寫入cookie,HTTP回覆將不帶有cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新後的會話保持cookie。
2.2.2 Cookie 重寫模式
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP, BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個空白的cookie併發回BIGIP,然後 BIGIP重新在cookie裡寫入會話保持數值,將HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP重寫的cookie)進入BIGIP,然後BIGIP讀出cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有空的cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新後會話保持數值到該cookie。
2.2.3 Passive Cookie 模式,伺服器使用特定資訊來設定cookie。
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個cookie併發回BIGIP,然後BIGIP將帶有伺服器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次伺服器寫的cookie)進入 BIGIP,然後BIGIP根據cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有更新的會話保持cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回覆給客戶端。
2.2.4 Cookie Hash模式:
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個cookie併發回BIGIP,然後BIGIP將帶有伺服器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次伺服器寫的cookie)進入BIGIP,然後BIGIP根據cookie裡的一定的某個位元組的位元組數來決定後臺伺服器接受請求,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有更新後的cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回覆給客戶端。
2.3 SSL Session ID會話保持
在使用者的SSL訪問系統的環境裡,當SSL對話首次建立時,使用者與伺服器進行首次資訊交換以: 1)交換安全證書,2)商議加密和壓縮方法,3)為每條對話建立Session ID。由於該Session ID在系統中是一個唯一數值,由此,BIGIP可以應用該數值來進行會話保持。當使用者想與該伺服器再次建立連線時,BIGIP可以透過會話中的SSL Session ID識別該使用者並進行會話保持。基於SSL Session ID的會話保持就需要客戶瀏覽器在進行會話的過程中始終保持其SSL Session ID不變,但實際上,微軟Internet Explorer被發現在經過特定一段時間後將主動改變SSL Session ID,這就使基於SSL Session ID的會話保持實際應用範圍大大縮小。
1.什麼是會話保持?
在大多數電子商務的應用系統或者需要進行使用者身份認證的線上系統中,一個客戶與伺服器經常經過好幾次的互動過程才能完成一筆交易或者是一個請求完成。由於這幾次互動過程是密切相關的,伺服器在進行這些互動過程的某一個互動步驟時,往往需要了解上一次互動過程的處理結果,或者上幾步的互動過程結果,伺服器進行下一步操作時需要這就要求所有這些相關的互動過程都由一臺伺服器完成,
而不能被負載均衡器分散到不同的伺服器上。而這一系列的相關的互動過程可能是由客戶到伺服器的一個連線的多次會話完成,也可能是在客戶與伺服器之間的多個不同連線裡的多次會話完成。不同連線的多次會話,最典型的例子就是基於http的訪問,一個客戶完成一筆交易可能需多次點選,而一個新的點選產生的請求,可能會重用上一次點選建立起來的連線,也可能是一個新建的連線。
會話保持就是指在負載均衡器上有這麼一種機制,可以識別做客戶與伺服器之間互動過程的關連性,在作負載均衡的同時,還保證一系列相關連的訪問請求會保持分配到一臺伺服器上。
2.F5支援什麼樣的會話保持方法
F5 BigIP支援多種的會話保持方法,其中包括:簡單會話保持(源地址會話保持)、HTTP Header的會話保持,基於SSL Session ID的會話保持,I-Rules會話保持以及基於HTTP Cookie的會話保持,此外還有基於SIP ID以及Cache裝置的會話保持等,但常用的是簡單會話保持,HTTP Header的會話保持以及HTTP Cookie會話保持以及基於I-Rules的會話保持。
2.1 簡單會話保持
簡單會話保持也被稱為基於源地址的會話保持,是指負載均衡器在作負載均衡時是根據訪問請求的源地址作為判斷關連會話的依據。對來自同一IP地址的所有訪問請求在作負載均時都會被保持到一臺伺服器上去。在BIGIP裝置上可以為“同一IP地址”透過網路掩碼進行區分,比如可以透過對IP地址192.168.1.1進行255.255.255.0的網路掩碼,這樣只要是來自於192.168.1.0/24這個網段的流量BIGIP都可以認為他們是來自於同一個使用者,這樣就將把來自於192.168.1.0/24網段的流量會話保持到特定的一臺伺服器上。簡單會話保持裡另外一個很重要的引數就是連線超時值,BIGIP會為每一個進行會話保持的會話設定一個時間值,當一個會話上一次完成到這個會話下次再來之前的間隔如果小於這個超時值,BIGIP將會將新的連線進行會話保持,但如果這個間隔大於該超時值,BIGIP將會將新來的連線認為是新的會話然後進行負載平衡。
基於原地址的會話保持實現起來簡單,只需要根據資料包三、四層的資訊就可以實現,效率也比較高。存在的問題就在於當多個客戶是透過代理或地址轉換的方式來訪問伺服器時,由於都分配到同一臺伺服器上,會導致伺服器之間的負載嚴重失衡。另外一種情況上客戶機數量很少,但每個客戶機都會產生多個併發訪問,對這些必發訪問也要求透過負均均衡器分配到多個服器上,這時基於客戶端源地址的會話保持方法也會導致負載均衡失效。
2.2 基於Cookie的會話保持
2.2.1 cookie
插入模式:在Cookie插入模式下,BigIP將負責插入cookie,後端伺服器無需作出任何修改.當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆(不帶cookie)被髮回BIGIP,然後BIGIP
插入cookie,將HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP插入的cookie)進入BIGIP,然後BIGIP讀出cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,由於伺服器並不寫入cookie,HTTP回覆將不帶有cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新後的會話保持cookie。
2.2.2 Cookie 重寫模式
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP, BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個空白的cookie併發回BIGIP,然後 BIGIP重新在cookie裡寫入會話保持數值,將HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP重寫的cookie)進入BIGIP,然後BIGIP讀出cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有空的cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新後會話保持數值到該cookie。
2.2.3 Passive Cookie 模式,伺服器使用特定資訊來設定cookie。
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個cookie併發回BIGIP,然後BIGIP將帶有伺服器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次伺服器寫的cookie)進入 BIGIP,然後BIGIP根據cookie裡的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有更新的會話保持cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回覆給客戶端。
2.2.4 Cookie Hash模式:
當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP,BIGIP根據負載平衡演算法策略選擇後端一臺伺服器,並將請求傳送至該伺服器,後端伺服器進行HTTP回覆一個cookie併發回BIGIP,然後BIGIP將帶有伺服器寫的cookie值的HTTP回覆返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次伺服器寫的cookie)進入BIGIP,然後BIGIP根據cookie裡的一定的某個位元組的位元組數來決定後臺伺服器接受請求,將HTTP請求(帶有與上面同樣的cookie)發到指定的伺服器,然後後端伺服器進行請求回覆,HTTP回覆裡又將帶有更新後的cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回覆給客戶端。
2.3 SSL Session ID會話保持
在使用者的SSL訪問系統的環境裡,當SSL對話首次建立時,使用者與伺服器進行首次資訊交換以: 1)交換安全證書,2)商議加密和壓縮方法,3)為每條對話建立Session ID。由於該Session ID在系統中是一個唯一數值,由此,BIGIP可以應用該數值來進行會話保持。當使用者想與該伺服器再次建立連線時,BIGIP可以透過會話中的SSL Session ID識別該使用者並進行會話保持。基於SSL Session ID的會話保持就需要客戶瀏覽器在進行會話的過程中始終保持其SSL Session ID不變,但實際上,微軟Internet Explorer被發現在經過特定一段時間後將主動改變SSL Session ID,這就使基於SSL Session ID的會話保持實際應用範圍大大縮小。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15711267/viewspace-1068889/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- QtumX技術白皮書QT
- SSLO如何實現會話保持?技術乾貨線上分享會話
- 會話技術之Cookie會話Cookie
- 會話技術之 Session會話Session
- 會話跟蹤技術會話
- 會話層技術-cookie會話Cookie
- 會話層技術-session會話Session
- securecrt保持會話不會斷掉Securecrt會話
- IP 防護等級技術白皮書
- 四種會話追蹤技術會話
- Java Web 會話技術總結JavaWeb會話
- LVS高階應用-會話保持會話
- 中國通訊協會:2022年自智網路前沿技術白皮書
- 基於token的會話保持機制會話
- 未來網路白皮書:2021年白盒交換機技術白皮書(附下載)
- 技術重構社會供應鏈:未來科技趨勢白皮書(附下載)
- 《區塊鏈安全白皮書-技術應用篇(2018年)》區塊鏈
- GSMA:2020年5G毫米波技術白皮書
- 數字孿生體技術白皮書 附下載地址
- JAP 1.0.1 以及 《JAP產品技術白皮書》正式釋出
- AISecOps白皮書精華解讀之技術體系篇AI
- 對話式互動技術原理及流程揭祕
- 大話儲存——磁碟原理與技術筆記(一)筆記
- day21-web開發會話技術03Web會話
- 圖說丨京東《技術重構社會供應鏈——未來科技趨勢白皮書》
- 清華大學《人工智慧晶片技術白皮書(2018)》分享!人工智慧晶片
- 如何看懂白皮書 別讓ICO毀了區塊鏈技術區塊鏈
- 看了400多份白皮書,迴歸本質談區塊鏈技術(附全部白皮書下載連結)區塊鏈
- web前端學習教程:Cookie會話跟蹤技術Web前端Cookie會話
- python+pytest介面自動化(10)-session會話保持PythonSession會話
- 業界 | 清華髮布《人工智慧晶片技術白皮書(2018)》人工智慧晶片
- 華為:算力網際網路技術白皮書(附下載)
- 中國移動:5G無線技術演進白皮書
- 華為:5G前傳3.0技術白皮書(附下載)
- HTML5入門教程 :Cookie會話跟蹤技術HTMLCookie會話
- 聊聊如何在K8S中實現會話保持K8S會話
- 深入探索Android熱修復技術原理讀書筆記 —— 程式碼熱修復技術Android筆記
- 深入探索Android熱修復技術原理讀書筆記 —— 資源熱修復技術Android筆記
- 深入探索Android熱修復技術原理讀書筆記 —— 熱修復技術介紹Android筆記