nginx作反向代理url重寫,如何實現會話保持?

l23456125847530


Nginx作為一款專業的反向代理服務器,由於其性能突出,現在一般中大型網站架構模式中,都會將它作為前置的反向代理服務器。但在部署反向代理之後,有個問題就來了,那就是如何實現會話保持?

什麼是會話保持?

我們知道,HTTP協議本身是無狀態的。什麼意思呢?就是用戶向瀏覽器發出請求後,服務器默認是無法直接識別用戶的,無法將用戶進行區分,這就會存在很多問題,於是就有了會話機制。

具體如何實現會話的呢?主要有兩種會話:Cookie會話、Session會話。Session會話是保存在服務器端的,然後將SessionID存入Cookie中,用戶下次請求服務器時,服務器能夠識別Cookie中的SessionID然後找到對應的Session,這樣服務器就能識別用戶了。

反向代理為什麼會導致會話丟失?

上面說到了,Session是存儲在服務器端的,當使用了反向代理後,同一用戶的多次請求不能保證都落在同一臺後端服務器上,這樣用戶瀏覽器中的Cookie即使傳遞到後端服務器,服務器也未必能找到對應的Session,於是,會話丟失了!

使用了反向代理後如何保持會話?

其實會話保持有很多種解決方案,下面結合我的實際經驗總結一下供大家參考:

1、Nginx會話保持機制

Nginx自帶有會話保持機制,常見的有:

  • ip_hash:使用源地址哈希算法,這樣同一客戶端的請求都會到達同一個後端服務器;

  • sticky_cookie_insert:此算法基於Cookie來實現的,此模塊需要編譯安裝。

2、會話共享機制

如果我們讓多個後端節點服務器的Session保持一致,不就可以解決落地服務器的會話保持了麼?說得通俗點,我們把Session集中管理,然後各個節點服務器從這裡取Session,就能保持會話了。

實現方案很多,比如說:

  • Session入庫;

  • Session存入NoSQL(Memcache、Redis)中。


以上就是我的觀點,對於這個問題大家是怎麼看待的呢?歡迎在下方評論區交流 ~ 我是科技領域創作者,十年互聯網從業經驗,歡迎關注我瞭解更多科技知識!

網絡圈


常用的方法有兩種:

1, IP hash, 根據請求的ip不同固定的轉發到指定的服務器上實現保持

2, cookie, 服務器給客戶端下發一個cookie, 根據cookie決定轉發的服務器.


分享到:


相關文章: