2012-07-20 94 views
3

我掃描了RFC 6265,但未找到以下答案。具有負載平衡的會話cookie(非粘性會話)

我想在單個webapp的多臺服務器前放一個天真的round-robbin負載平衡器。負載均衡器不是提供粘性會話。所以客戶通常會在連續的請求中從一臺應用服務器跳到另一臺。

在第一個連接上,客戶端沒有SID並隨機路由到服務器A.
服務器A以會話cookie(即一個隨機數)響應。

在下一個連接上,客戶端在HTTP標頭中包含來自服務器A的SID。 這次客戶端被隨機地路由到服務器B. 服務器B看到哪個(希望!)不匹配它發佈的任何SID。 會發生什麼?服務器B是否忽略了「糟糕的」SID,或抱怨或忽略了請求,或者是什麼?

這個想法是,我根本不想使用會話cookie。我想避免所有粘性的複雜性。但是我也知道我的服務器可能會生成 - 更重要的是會尋找會話cookie。

如何確保服務器只是忽略(或更好的沒有設置)會話cookie?

+0

好的,沒有答案。也許我的問題是愚蠢的。如果是這樣,請讓我重新回到路上。謝謝! – Carlos 2012-07-24 08:30:59

回答

3

我認爲對此的答案會有很大的不同,這取決於服務器上運行的應用程序。儘管任何值得使用的負載平衡器都有粘性會話,但只要池中的所有服務器都可以通過集中式數據庫訪問相同的會話狀態,就可以在沒有它們的情況下進行操作。

由於您在談論會話ID,我猜測應用程序確實依賴會話狀態才能正常工作。在這種情況下,如果請求帶有「壞」會話ID,它很可能會被丟棄並且用戶提示登錄 - 同樣,確切的行爲取決於應用程序。如果您完全禁用會話cookie,問題可能會變得更糟,因爲即使缺少ID也可能導致登錄提示。

如果您真的想避免負載平衡器的複雜性,您需要引入一些機制,通過這種機制,所有服務器都可以處理來自所有會話的請求。通常採用集中式數據庫或其他共享存儲的形式。這允許會話狀態保持不變,而不管處理該特定請求的服務器。

維護會話狀態是負載平衡的關鍵點之一(雙關意圖),但只是忽略或避免會話cookie不是解決方案。

相關問題