為什麼沒有水平可擴展軟體負載平衡器平衡 ssl 的範例？
我有一堆關於 ssl、本地會話和負載平衡的問題，這些問題似乎是相互關聯的，所以我提前為這個問題的長度道歉。
我有一個使用基於文件的會話的網站。該網站的性質是大部分是http，但有些部分是ssl。目前，由於基於文件的會話，任何 ssl 請求都必須與之前的任何 http 請求訪問同一台伺服器。
由於時間限制，我想做最簡單的事情來負載平衡增加的 http 和 ssl 流量。
粘性負載平衡算法似乎有兩種選擇：
- 基於IP
- 基於 cookie
基於 ip 的解決方案可能會起作用，但是當伺服器關閉或添加時，散列算法可能會改變使用者訪問的伺服器，這對於目前基於文件的會話設置來說是不可取的。我還假設使用者在瀏覽網站時合法地更改 ips 在技術上是可能的。
基於 cookie 的算法似乎更好，但在 ssl 加密時無法檢查 cookie 似乎存在其自身的問題。
我一直在搜尋有關如何負載平衡 ssl 的範例，但我似乎找不到任何明確的設置範例，這些設置可以進行基於 cookie 的負載平衡，並且可以通過添加另一個 ssl 解碼器來處理增加的 ssl 負載。
我見過的大多數顯式範例都有位於瀏覽器客戶端和負載平衡器之間的 ssl 解碼器（通常是硬體、apache_mod_ssl 或 nginx）。這些範例通常看起來像這樣（修改自http://haproxy.1wt.eu/download/1.3/doc/architecture.txt）：
192.168.1.1 192.168.1.11-192.168.1.14 -------+-----------+-----+-----+-----+ | | | | | +--+--+ +-+-+ +-+-+ +-+-+ +-+-+ | LB1 | | 一個 | | 乙| | C | | D | +-----+ +---+ +---+ +---+ +---+ apache 4 便宜的網路伺服器 mod_ssl 代理伺服器上面範例中的 ssl 解碼部分似乎是一個潛在的瓶頸，無法橫向擴展。
我看過 haproxy，它似乎有一個 ‘mode tcp’ 選項可以允許這樣的事情，這將允許您擁有多個 ssl 解碼器：
代理伺服器 | ------------- | | ssl-decoder-1 ssl-decoder2 | | ------------------- | | | 網路1網路2網路3但是，在這樣的設置中，您似乎會失去客戶端 IP，因為 haproxy 沒有解碼 ssl： https ://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -為了
我也看過 nginx，也沒有看到任何水平可擴展的 ssl 解碼器的明確範例。似乎有很多人將 nginx 作為潛在瓶頸的例子。至少這個連結似乎表明 nginx 甚至沒有類似 haproxy 的設置選項，你會說 nginx“不支持透明地將 TCP 連接傳遞到後端”而失去 ip如何通過 Apache通過 nginx 代理的 SSL 流量？.
問題：
- 為什麼似乎沒有更多的設置範例添加更多的 ssl 解碼器來處理增加的流量？
- 是不是因為 ssl 解碼步驟只是理論上的瓶頸，而實際上，一個解碼器基本上就足夠了，除了流量荒謬的網站？
- 想到的另一個可能的解決方案可能是任何對 ssl 需求增加的人也有一個集中的會話儲存，因此客戶端在順序請求上點擊哪個 Web 伺服器並不重要。然後您可以在每個網路伺服器上啟用 mod_ssl 或等效項。
- 上面引用的 haproxy 解決方案似乎有效（除了客戶端 IP 問題），但有沒有人遇到過基於粘性 cookie 的軟體負載平衡器解決方案，該解決方案可以通過增加解碼器數量同時保持客戶端 IP 來工作，或者在技術上可能不是可能（因為您必須對請求進行解碼才能獲取客戶端 IP，在這種情況下，我們遇到了解碼器瓶頸）。
假設我所說的一切都是真的，這些似乎是我的選擇：
- 使用 ip 雜湊（對可能合法更改 ips 的使用者以及伺服器添加和刪除場景不利）
- 使用 nginx 或 mod_ssl 作為第一個接觸 ssl 請求的程序，這將是一個潛在的 ssl 解碼瓶頸
- 使用 haproxy 作為第一個接觸 ssl 請求的程序，獲得水平 ssl 可擴展性，但沒有在網路伺服器級別記錄 ssl 請求的 ips（可能暫時可以）
- 從長遠來看，轉向移動或集中式會話儲存，無需粘性會話
嚴肅地說，“最簡單的事情”是轉移到集中式會話儲存。您必須使用負載平衡器、haproxy、SSL 和其他部分來設置所有這些管道，而我所見過的每一點會話處理程式碼都使得插入不同的儲存引擎變得幾乎是微不足道的，所以一點程式碼和非常非常少的額外複雜性可以解決您所有的問題。
womble 是正確的，共享會話儲存使事情變得更加容易。除了他的回答之外，我還可以對問題的負載平衡部分進行一些擴展：
為什麼似乎沒有更多的設置範例添加更多的 ssl 解碼器來處理增加的流量？
現代多核 PC每秒可以進行數千次 SSL 事務。如果這成為瓶頸，那麼來自F5、Citrix、Cisco 等的專用設備可能會更快。所以大多數網站永遠不會超越一個好的單設備 SSL 和負載平衡解決方案。
假設我所說的一切都是真的，這些似乎是我的選擇：
如果您需要，可以選擇水平擴展 SSL 解密。
常見的方法是使用DNS Round Robin 來獲得高可用的SSL 加速器對，即為域發布多個IP 地址，每個IP 地址指向一對SSL 加速器。
在這種情況下，您可能會擔心 DNS TTL 在使用者會話中間超時，從而將使用者撞到另一個應用程序伺服器。這不應該是一種常見的情況，但它可能會發生。共享會話儲存是常見的解決方案，但可以通過其他方式進行處理。
作為一個範例，您可以將 SSL 解密與應用伺服器平衡分開。SSL 處理比基本負載平衡更佔用 CPU，因此單個負載平衡器應該能夠使幾個 SSL 加速器飽和。像這樣：
Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers如開頭所述，共享會話儲存簡化了許多事情，並且幾乎可以肯定比在 SSL / 負載平衡層中添加大量複雜性更好的長期解決方案。