反向代理和負載均衡有何區別？

作者：由 dozen 發表于攝影時間：2012-10-25

匿名使用者2015-09-06 12:19:42

做了反向代理才能實現負載均衡。負載均衡是做反向代理的目的之一。

張鉦2015-10-09 19:51:44

反向代理，是有把命令轉發的能力，這個是必須基礎

負載均衡，是把命令轉發到不同的伺服器上，均衡各個伺服器

好像是很奇怪的回答，呵呵

知乎使用者2016-11-10 14:16:28

目前正在做負載均衡測試相關工作，有幸寫過一篇相關問題的文章，為了隱去公司隱私，做了一些刪減，望理解。

一、SLB產生背景：

SLB（伺服器負載均衡）：在多個提供相同服務的伺服器的情況下，負載均衡裝置存在虛擬服務地址，當大量客戶端從外部訪問虛擬服務IP地址時，負載均衡裝置將這些報文請求根據負載均衡演算法，將流量均衡的分配給後臺伺服器以平衡各個伺服器的負載壓力，避免在還有伺服器壓力較小情況下其他服務達到效能臨界點出現執行緩慢甚至宕機情況，從而提高服務效率和質量，因此對客戶端而言，RS（real server 實際伺服器）的IP地址即是負載均衡裝置VIP（虛擬服務地址IP）地址，真正的RS伺服器IP地址對於客戶端是不可見的。

二、SLB的三種傳輸模式：

七層SLB和四層SLB的區別：

四層SLB：配置負載均衡裝置上服務型別為tcp/udp，負載均衡裝置將只解析到4層，負載均衡裝置與client三次握手之後就會和RS建立連線；

七層SLB：配置負載均衡裝置服務型別為http/ftp/https等，負載均衡裝置將解析報文到7層，在負載均衡裝置與client三次握手之後，只有收到對應七層報文，才會跟RS建立連線。

在負載均衡裝置中，SLB主要工作在以下的三種傳輸模式中：

反向代理模式

透傳模式

三角模式

根據不同的模式，負載均衡裝置的工作方式也不盡相同，但無論在哪種模式下，客戶端發起的請求報文總是需要先到達負載均衡裝置進行處理，這是負載均衡裝置正常工作的前提。模擬網路拓撲環境：

Client：10。8。21。40

負載均衡裝置：172。16。75。83

VIP：172。16。75。84

RS1IP：172。16。75。82

RS2IP：172。16。75。85

在整個報文互動過程中，採用Tcpdump和Wireshark分別在RS和Client處抓包，然後使用Wireshark進行報文解析。

三、反向代理模式：

反向

代理：普通的代理裝置是內網使用者透過代理裝置出外網進行訪問，而工作在這種模式下的負載均衡裝置，則是外網使用者透過代理裝置訪問內網，因此稱之為反向代理。

在反向代理模式下：

當負載均衡裝置收到客戶端請求後，會記錄下此報文（源IP地址、目的IP地址、協議號、源埠、目的埠，服務型別以及介面索引），將報文目的地址更改為優選後的RS裝置的IP地址，目的埠號不變，源地址修改為負載均衡裝置下行與對應RS裝置介面的IP地址，源埠號隨機發送給RS；

當RS收到報文後，會以源為RS介面IP地址，目的IP裝置地址回覆給負載均衡裝置，負載均衡裝置將源修改為VIP，目的埠號修改為客戶端的源埠號，目的IP修改為Client的源IP回覆報文。

檢視報文解析結果：

配置完成後，Client訪問RS伺服器，返回成功，整個報文互動過程如下

：

Client和負載均衡裝置之間的報文互動過程

RS和負載均衡裝置之間報文互動過程

結果分析

分析整個報文互動過程：

TCP握手過程：

首先Client向負載均衡裝置傳送TCP SYN報文請求建立連線，源IP為Client的IP 10。8。21。40，源埠號50894，目的IP為VIP地址172。16。75。84，目的埠號80；

收到請求報文後，負載均衡裝置會以源IP為VIP地址172。16。75。84，埠號80，目的IP 10。8。21。40，目的埠號50894迴應SYN ACK報文；

Client收到報文後回覆ACK報文，TCP三次握手成功。

HTTP報文互動過程：

當負載均衡裝置與client完成三次握手後，因為配置的七層SLB，如果收到HTTP請求，就會根據負載均衡演算法和伺服器健康狀態優選出對應的RS（在這次過程中選擇的RS裝置為172。16。75。82），然後與RS建立TCP連線：

負載均衡裝置傳送TCP SYN報文請求連線，源IP為負載均衡裝置與RS相連線口IP 172。16。75。83，源埠號隨機4574，目的IP為RS的IP 172。16。75。82，目的埠號80；

RS收到報文後，以源IP 172。16。75。82，埠號80，目的IP 172。16。75。83，目的埠號4574回覆SYN ACK報文，負載均衡裝置回覆ACK報文建立三次握手；

之後，負載均衡裝置再將收到的HTTP報文源IP修改為與RS相連下行介面IP地址172。16。75。83，源埠號為隨機埠號，將報文傳送給RS；

當RS收到報文後，使用源為本地IP 172。16。75。82，目的IP為172。16。75。83進行回覆，所以報文直接回復給負載均衡裝置；

當負載均衡裝置收到RS的迴應報文後，將報文的源修改為VIP地址172。16。75。84，目的IP為10。8。21。40傳送回Client，再將目的埠號修改為HTTP請求報文中的源埠號，伺服器訪問成功。

由上述的過程可以看出，在RS端上，client的真實IP地址被負載裝置修改成與RS相連線口的IP地址，所以RS無法記錄到Client的訪問記錄，為了解決這個問題，可以採用在HTTP報文頭中新增X-Forwarded-For欄位，本文不做贅述，可以自行查詢。

四、透傳模式：

當負載均衡裝置工作在透傳模式中時，RS無法感知到負載均衡裝置的存在，對於Client來說，RS的IP地址就是負載均衡裝置的VIP地址。

在這種模式下，當負載均衡裝置收到源為Client的IP，目的IP為本地VIP地址的報文時，會將報文根據負載均衡策略和健康狀況傳送給最優的RS裝置上，繼而RS裝置會收到目的為本地IP，源為Client實際IP的請求報文；

然後RS將會直接回應此請求，報文的目的IP地址為Client的IP地址，當負載均衡裝置收到此報文後，將源IP地址修改為VIP地址，然後將報文傳送給Client。

報文解析結果：

同樣在RS端和Client端抓取互動報文：

Client和負載均衡裝置之間的報文互動過程

RS和負載均衡裝置之間的報文互動過程

結果分析：

TCP握手過程：

同反向代理模式互動過程

HTTP報文互動過程：

Client向負載均衡裝置的VIP地址172。16。75。84以源IP 10。8。21。40傳送HTTP請求，當負載均衡裝置收到報文後，與優選後的RS進行TCP三次握手，過程同反向代理模式，然後將收到的HTTP報文，不改變報文的源IP地址和源/目的埠號，只修改目的IP修改為優選後的RS地址172。16。75。82；

當RS收到源來自IP 10。8。21。40的報文後，回覆報文給IP地址10。8。21。40，此時要注意，必須在RS上配置回覆報文經過負載均衡裝置，負載均衡裝置會將源IP修改為VIP地址172。16。75。84，然後轉發給Client，否則Client將會收到源IP為172。16。75。82的HTTP報文，伺服器訪問失敗。

五、三角模式：

在三角模式下，當客戶端傳送請求到負載裝置上時，負載均衡裝置會計算出最優RS，然後直接根據MAC地址將報文轉發給RS，在RS上配置報文的源IP為VIP地址（一般配置在loopback口上），因此在這種情況下，RS會直接將報文傳送給Client，即使回覆報文經過負載均衡裝置，此裝置不做任何處理。由於報文在整個過程中傳輸途徑類似於三角形，因此稱之為三角模式。

報文解析結果：

分別在Client端和RS端抓包，內容如下：

Client和負載均衡裝置之間的報文互動過程

RS 和負載均衡裝置之間的報文互動過程

結果分析：

TCP握手過程：

由於採用了4層SLB，所以在TCP握手過程中與上述的7層SLB有些不同，當Client和RS完成三次握手之後，此時負載均衡裝置會直接選擇RS，然後跟RS建立TCP三次握手；

在三角模式環境中，由於RS的Loopback口和負載均衡裝置上都存在著VIP地址172。16。75。84，當負載均衡裝置經過負載均衡演算法選擇出對應的RS後，會根據實際配置的RS的IP地址對應的mac地址，將報文以目的mac為RS，目的IP為VIP的方式建立TCP連線。

HTTP報文互動過程：

首先Client向負載均衡裝置的VIP傳送HTTP請求，源為10。8。21。40，當負載均衡裝置收到報文後，將報文直接轉發給RS，當RS收到源IP為10。8。21。40，目的IP為本地Loopback口IP地址172。16。75。84的報文後，直接將報文回覆給10。8。21。40，同樣源為IP地址172。16。75。84，由此訪問伺服器成功。

在三角模式中，由於回覆報文負載均衡裝置不做任何處理，所以非常適合於RS到Client方向流量較大或者連線數目較多的組網環境。

採用三角模式時，必須注意RS有路由可以到達Client，並且在RS的Loopback介面上必須有負載均衡裝置的VIP地址，否則即使RS裝置收到Client的請求報文也會直接丟棄報文，不作迴應。

六、總結

由於反向代理模式中在RS側只能收到源為負載均衡裝置IP的報文，因此可以使用防火牆增加安全性，只允許源IP為負載均衡裝置的IP地址的報文透過，同時增加X-Forwarded-For欄位也可以讓RS只允許有此欄位的報文進行訪問，因此安全性相對較高。

知乎使用者OylHC32017-06-27 08:29:52

反向代理是實現負載均衡的一種方法。

先談反向代理。使用者在請求時，先把請求傳送給代理的伺服器，然後由代理伺服器根據演算法去請求真實的伺服器，最後返回給使用者。這種做法，其一是提高了安全性；其二是透過多臺的real server分擔了使用者的請求，實現了負載均衡。

再談負載均衡。負載均衡的出現，是透過橫向的擴充套件，儘可能地降低單臺伺服器的壓力。常見WEB層面的負載均衡的方案有硬體F5、Nginx代理、LVS、各個雲商的負載均衡服務（如AWS的ELB服務）等。負載均衡後面連的一般是實際提供服務的伺服器，如透過ELB服務，可以做到流量的均勻分擔，從而減少單機伺服器的壓力。

由於增加了負載均衡這層，所以單純地使用某個方案還是要考慮單點的問題。負責由於負載均衡這個伺服器未能承受住壓力，宕機了，服務也是不可用的。所以Nginx、LVS儘量配置多臺代理，可以故障轉移和故障報警，從而及時去處理代理層伺服器的問題。ELB是亞馬遜提供的服務，它本身的實現底層就有數百甚至上千的機器，所以把它想象成一個代理叢集就好。

以上是大致的說了下區別，具體的實現還需要結合實際的業務情況。