forward proxy / reverse proxy / load balancing

有大大可以說明一下 forward proxy / reverse proxy / load balancing 的差異
以及他們各自的使用情境嗎?~

結果忘記回你這篇…

forward & reverse proxy 基本上是方向的不同而已

forward 一般給公司用,類似管控或 cache,而 VPN 概念也很像這個鬼,不過架構有點不一樣
reverse 是 server 系列用的,類似用 nginx / apache 弄個 proxy 到不同的 ip / port,大都這類

而 proxy 也有很多做多層次的架構,不過通常都一向,也就是 forward / reverse 選其一

load balancing 是 reverse proxy 的高級版本,主要功能是做平衡負載,而其他功能有類似管控頻寬,使用量,甚至 IP 阻擋甚至 SSL 加密( 高級產品很多都支援整票的鬼 X"D 甚至還包 cookie 過濾勒 )

anyway 其實 proxy 因為使用率很高,後來比較少人談,因為都直接 deploy 就結束了,而網站大了就會需要 LB,這倒是必要的架構就是

而在這之前,你有聽過 DNS 的 load balance 嗎?

使用者進到一個網站前,會先和 DNS 要 IP,而自建 DNS 可以設一個很小的 cache timer 來去做更改 server IP 的動作,而到 IP 後才會是 load balance 的問題,所以真的量大時 load balance 是沒有用的,還要靠 DNS 才行,因為入口端的那台 load balance 還是有其極限在,類似該機房也會有最大承載量有的沒的

感謝JC大還記得回這篇XD

這樣感覺 一台LB的機器要做很多事,而且根本就當成防火牆來用了,一般來說LB server應該也是service唯一暴露的public IP吧?

另外,會提到reverse proxy是因為最近剛好有去了解CDN是啥鬼,感覺CDN應該就是一個超大的LB??CDN跟LB一般應該只會選一個做吧?

最後,DNS的這部分不是很懂,如果LB server是唯一暴露的public IP,那應該就不用去更改server IP? 這邊再請JC大開示下XD

LB 通常不會是防火牆,防火牆會掛在 LB 前,因為其任務簡單且一台通常可以撐整個 zone,但 LB 任務繁重,所以單獨的事件由單獨的機器負責之類的

至於 LB 也有多層架構,所以不一定是暴露的 IP 就是,而 LB 的管理 port 應該也不是對外的,所以不用太怕攻擊的發生

CDN 其實只是內容的提供者,類似任何一種 server 一樣可能是個叢集,所以所有架構都一樣,用不用防火牆 / LB 都是管理者的選擇而已,LB / 防火牆 / proxy 之類的都是單一叢集的架構方式

DNS 平衡負載的想法其實很簡單瞭解,類似你在全球有 15 個機房,你會希望不同國家的 client 用的是最靠近的機房,而每個機房裡面有五個叢集,你會希望這五個叢集平均分散,而不是集中在同一個,這就是 DNS 的用法了

client 在問類似 example.com 的 IP 時, DNS server 可以研判該 IP 所在的國家而給不同的答案,這不同的答案內可以考慮叢集的效能,把最不忙的丟出去,而如果 client 已經取得對象 DN 的 IP 時基本上都已經為時已晚,因為之後所有的溝通都是和該 IP 溝通,除非用其他方式轉介到其他台,或是用 CDN 那種非常平均的 DN 來做灑的動作

所以最厲害最完美的負載平衡系統是從 DNS 就開始,而非 LB 或防火牆之類的

以下,不知道我理解對不對:

LB 通常不會是防火牆,防火牆會掛在 LB 前,因為其任務簡單且一台通常可以撐整個 zone,但 LB 任務繁重,所以單獨的事件由單獨的機器負責之類的

至於 LB 也有多層架構,所以不一定是暴露的 IP 就是,而 LB 的管理 port 應該也不是對外的,所以不用太怕攻擊的發生

FW:任務為擋掉可疑封包,通常作為對外service的第一線,是唯一暴露的public IP
LB:任務為分攤每台server的負擔,通常部署於LAN,不會暴露IP,攻擊情況罕見

CDN 其實只是內容的提供者,類似任何一種 server 一樣可能是個叢集,所以所有架構都一樣,用不用防火牆 / LB 都是管理者的選擇而已,LB / 防火牆 / proxy 之類的都是單一叢集的架構方式

CDN的作用只是要就近提供service的靜態檔案cache,碰到ajax request就還是要將封包送到service的第一線FW來做後續的事情,所以CDN或許能夠分擔service在處理靜態檔案的負擔,但是卻不會減少service處理ajax的負擔。

DNS 平衡負載的想法其實很簡單瞭解,類似你在全球有 15 個機房,你會希望不同國家的 client 用的是最靠近的機房,而每個機房裡面有五個叢集,你會希望這五個叢集平均分散,而不是集中在同一個,這就是 DNS 的用法了

request的所經歷程:

client ====> DNS ==( A )==> service FW ==( B )==> server farm

(A)/(B) 都能做LB,在(A)做就是DNS LB。
而DNS LB的依據應該是按照區域(就近服務原則),將request送到離發送者最近的server farm,而非單純輪詢。

client 在問類似 example.com 的 IP 時, DNS server 可以研判該 IP 所在的國家而給不同的答案,這不同的答案內可以考慮叢集的效能,把最不忙的丟出去,而如果 client 已經取得對象 DN 的 IP 時基本上都已經為時已晚,因為之後所有的溝通都是和該 IP 溝通,除非用其他方式轉介到其他台,或是用 CDN 那種非常平均的 DN 來做灑的動作

在取得server IP後,request便不再連到DNS server,轉而直接連到server IP,而CDN其實在將request往後送到service FW之前,也可以直接擔任LB的角色,輪詢地將request送到不同的FW。

所以最厲害最完美的負載平衡系統是從 DNS 就開始,而非 LB 或防火牆之類的

client ====> DNS ==( A )==> service FW ==( B )==> server farm
LB最好從(A)就開始做,而非到(B)才做,減輕FW負擔。

yep~ 基本上是

不過 『任務為分攤每台server的負擔,通常部署於LAN,不會暴露IP,攻擊情況罕見』

所謂的攻擊從來都不是那麼理想的,一直都是通透式的,且任何一個地方都是打點,被打到都會被挖成大洞|||,FW只過濾到 IP / port,LB其實一般來說沒做任何過濾,而其餘 Application 層的過濾都還是要靠 Web 本身的機制才行,so~

瞭解~感謝回覆