摘要：在網絡中，真實的綁定在負載均衡器上，用來接收客戶端的真實請求數據包。突破模式中真實服務器的默認網關必須是負載均衡器的限制。

上篇從計算機間的通信說起，知道通信必要的六要素是 源 IP 地址、端口號、源 MAC 地址，目標 IP 地址、端口號、目標 MAC 地址。其中，端口號標志了在應用層的兩個具體應用信息，即快遞的具體發送人和接收人，IP 地址表示在網絡層上兩個端點的地址，即快遞的發出地址和收貨地址，MAC 地址表示在數據鏈路層上節點間的地址，即快遞傳送中的各個驛站的地址。

在了解 LVS 的 NAT、FULLNAT 模型對數據包的修改方式以及它們的缺點之后，站在 NAT 模型的肩膀上，怎樣才能更好地優化負載均衡器？

在 NAT 和 FULLNAT 模式中，不管是請求數據包還是響應數據包，都要經過負載均衡器。但是響應數據包一般要比請求數據包大很多，這可能會成為系統的瓶頸。如果能夠將請求數據包轉發到真實服務器之后，響應數據包由真實服務器直接返回，這樣對負載均衡器的壓力就小很多。這種模式又應該如何實現呢？

DR 模式

如果真的能夠由真實服務器直接響應客戶端，而不經過負載均衡器。那么這個由負載均衡器直接響應回客戶端的數據包需要滿足什么條件，才能被客戶端正常接收？

真實服務器發出的數據包，在客戶端接收到的時候，一定要匹配得上從客戶端發出的數據包。如果不匹配的話，客戶端收到響應數據包后會直接將數據包丟棄。

????客戶端發出的請求數據包：CIP ?? VIP，則收到的響應數據包一定是 VIP ?? CIP。
????做個小思考，為什么沒有帶上 MAC 地址？后文有解釋～

但是 VIP 已經綁定在負載均衡器上，真實服務器也有多個，在連通的網絡里，如何能讓多個真實服務器和負載均衡器的 VIP 地址相同？并且真實服務器的 VIP 不能被其他設備訪問的到。也就是說在每臺真實服務器上的 VIP 地址，只能它們自己知道“我悄悄藏著 VIP”，別的設備壓根不知道。

這里不得不提另一個非常神奇的 IP 地址 127.0.0.1/0.0.0.0。仔細想一下，127.0.0.1 不就是每臺設備上都相同，“悄悄藏著”的 IP 地址嗎，除了自己的其他設備都沒辦法訪問。這個神奇的 IP 地址，叫做 Loopback 接口。它是一種純軟件性質的虛擬接口，當有請求數據包送達到 lo 接口，那么 lo 接口會將這個數據包直接 “掉頭”，返回給這個設備本身，這就是“環回”接口的由來。所以，如果將 VIP 綁定在 lo 接口上，是不是就可以完成“只有自己知道這個 VIP，別的設備不知道”呢？

將 VIP 綁定在 lo 接口上，其實只完成了一半，只是做到了在多臺真實服務器上綁定相同的 VIP 地址。還記得上篇文章中所講的 ARP 協議嗎，ARP 協議會采集在當前局域網中，除了自己之外的其他主機的 MAC 地址和 IP 地址的映射關系。而 VIP 是一個不能被別的設備采集到的地址，所以我們要對真實服務器的 ARP 協議做一些修改，讓 VIP 不會被其他設備采集到。很顯然，這不但要修改設備收到 ARP 請求之后的響應（arp_ignore 參數)，也要修改設備向外通告 ARP 的請求 （arp_announce 參數）。

????arp_ignore：定義接收 ARP 請求時的響應級別 0：響應任意網卡上接收到的對本機 IP 地址的 ARP 請求（包括環回網卡），不論目的 IP 地址是否在接收網卡上 1：只響應目的 IP 地址為接收網卡地址的 ARP 請求 2：只響應目的 IP 地址為接收網卡地址的 ARP 請求，且 ARP 請求的源 IP 地址必須和接收網卡的地址在同網段

????arp_announce：定義將自己地址向外通告時的通告級別 0：允許任意網卡上的任意地址向外通告 1：盡量僅向目標網絡通告與其網絡匹配的地址 2：僅向與本地接口上地址匹配的網絡進行通告

可以看到，arp_ignore 為 1 并且 arp_announce 為 1 時，lo 接口上綁定的 VIP 可以被藏在本機上，只有自己知道。

（如圖：紅色表示發出的數據包；綠色表示返回的數據包；黃色表示負載均衡器修改的內容；虛線表示經過 N 個下一跳，即可以不在同一局域網內；實線表示只能 “跳躍一次”，即必須在同一局域網內）

1.當計算機發出一個請求的數據包到達負載均衡器后，負載均衡器修改請求數據包的 { 目標MAC 地址 } 為 真實服務器的 MAC 地址，其余信息不變。負載均衡器和真實服務器必須在同一局域網內，否則負載均衡器無法替換請求數據包的 { 目標MAC 地址 } 為 真實服務器的 MAC 地址

2.真實服務器收到請求的數據包，發現自己有一個 “隱藏“ 的 VIP，于是接收這個數據包，并交由對應的上層應用處理

3.處理完成后，將響應數據包直接返回給客戶端。此時在真實服務器上查看 TCP 連接為：VIP ?? CIP

?總結一下 DR 模式的特點：
1.僅修改請求數據包的「目標 MAC 地址」，作用在數據鏈路層。因此負載均衡器必須和真實服務器在同一局域網內，且不能對端口進行轉發
2.真實服務器中的 VIP，只能被自己 “看見”，其他設備不可知。因此 VIP 必須綁定在真實服務器的 lo 網卡上，并且不允許將此網卡信息經過 ARP 協議對外通告
3.請求的數據包經過負載均衡器后，直接由真實服務器返回給客戶端，響應數據包不需要再經過負載均衡器

TUN 模式

除了直接修改請求數據包的目標 MAC 地址，做一次 MAC 地址欺騙之外，還有沒有其他方式能夠將響應數據包由真實服務器直接返回給客戶端呢？看看 VPN 是怎么能夠支持你遠程辦公的吧～

我們已經討論過，如果真實服務器直接將響應數據包返回給客戶端，那么真實服務器必須有一個 “隱藏” 的 VIP，即配置在 lo 網卡上并且不允許此 VIP 通過 ARP 協議對外通告。

（如圖：紅色表示發出的數據包；綠色表示返回的數據包；黃色表示負載均衡器修改的內容；虛線表示經過 N 個下一跳，即可以不在同一局域網內；實線表示只能 “跳躍一次”，即必須在同一局域網內）

1.當計算機發出一個請求的數據包到達負載均衡器后，負載均衡器不改變源數據包，而是在源數據包上新增一層 IP 首部 { 分發 IP、端口號、MAC 地址 } ?? { 真實服務器 IP、端口號、MAC 地址 }

2.真實服務器收到請求的數據包后，將最外層封裝的 IP 首部去掉，發現還有一層 IP 首部，并且目標 IP 地址能夠和 lo 上的地址匹配，于是收下請求數據包，并交由對應的上層應用處理

3.處理完成后，將響應數據包直接返回給客戶端。此時在真實服務器上查看 TCP 連接為：VIP ?? CIP

?總結一下 TUN 模式的特點：
1.不改變請求數據包，而是在請求數據包上新增一層 IP 首部信息。因此負載均衡器不能對端口進行轉發，但可以和真實服務器不在同一局域網內，且真實服務器需要支持能夠解析兩層 IP 首部信息，即需要支持“IP Tunneling”或“IP Encapsulation”協議
2.真實服務器中的 VIP，只能被自己 “看見”，其他設備不可知。因此 VIP 必須綁定在真實服務器的 lo 網卡上，并且不允許將此網卡信息經過 ARP 協議對外通告
3.請求的數據包經過負載均衡器后，直接由真實服務器返回給客戶端，響應數據包不需要再經過負載均衡器

NAT、FULLNAT、DR、TUN模式總結

在 DR 和 TUN 模式中，負載均衡器只轉發了請求數據包，響應數據包不經過負載均衡器，而是直接返回給客戶端。解決了在通常情況下響應數據包比請求數據包大，如果請求和響應數據包都經過負載均衡器，在高并發下可能成為系統瓶頸的問題。

根據我們的推導過程，可以輕易地得出各種模式的特點和它們要解決的問題。
NAT 模式，通過修改數據包的「目標 IP 地址」和 「源 IP 地址」，將請求負載到多臺真實服務器，是四層負載均衡模式中最基礎的負載方式。因為它是對 IP 地址層面的修改，作用在網絡層，所以可以對端口進行映射。真實服務器返回的響應數據包必須經過負載均衡器，所以要求真實服務器的默認網關是負載均衡器。

FULLNAT 模式，是對 NAT 模式的一種演進。通過同時修改「源 IP 地址」和「目標 IP 地址」，突破 NAT 模式中真實服務器的默認網關必須是負載均衡器的限制。但是由于同時修改了「源 IP 地址」和「目標 IP 地址」，真實服務器建立的真實連接和客戶端毫無關系，所以會丟失客戶端的信息。

DR 模式，是對 NAT 模式的另一種演進。由于真實請求中響應數據包比請求數據包大很多的特點，在高并發下會成為系統的瓶頸，于是將響應數據包直接由真實服務器返回給客戶端。使用 MAC 地址欺騙來達到此目的，作用于數據鏈路層，所以不能對端口映射。并且在真實服務器上，必須有一個僅自己可見的 “隱藏” VIP。在網絡中，真實的 VIP 綁定在負載均衡器上，用來接收客戶端的真實請求數據包。而 “隱藏” 的 VIP 綁定在真實服務器的 lo 接口上，用來欺騙自己可以正常接收目標地址是 VIP 的數據包。所以真實服務器的默認網關也必須是負載均衡器。

TUN 模式，是對 DR 模式的一種演進。突破 DR 模式中真實服務器的默認網關必須是負載均衡器的限制。TUN 模式不會對源數據包進行修改，而是在源數據包上額外新增一條 IP 首部信息，所以不能對端口映射，且要求真實服務器必須能夠卸載掉兩層 IP 首部信息。

???? 回顧之前的小思考題：為什么在說真實服務器能夠正常接收負載均衡器轉發的數據包的必要條件時，沒有帶上 MAC 地址？

在網絡通信部分介紹 ARP 協議和下一跳機制時，我們提到數據包在網絡中的轉發和快遞傳送中的驛站類似，每一次數據包的發送，會不斷地找到 “下一個目的地” 的 MAC 地址。所以，但凡涉及到物理端口的變遷，都涉及到源 MAC 地址的變化，這個變化是 IP 通信的特性，而并不是負載均衡的特點。

在對負載均衡的各個模式有一定的了解之后，下一篇我們來看看具體實踐和配置???? ～

關于UCloud負載均衡服務ULB

UCloud負載均衡服務ULB支持內網和外網兩種場景，支持請求代理和報文轉發兩種轉發模式。ULB4是基于DPDK技術自研的，采用了類似于DR的轉發模式，單臺服務器可以提供超過3000萬并發連接，1000萬 pps，10G線速轉發能力。采用集群部署，單個集群至少4臺服務器。利用ECMP+ BGP實現高可用。ULB7基于Haproxy開發，也就是Fullnat模式，單個實例可以支持超過40w pps，2Gbps，以及至少40萬并發連接。

相對于ULB7，ULB4轉發能力更強，適合與追求轉發性能的場景。而ULB7則可以對七層數據進行處理，可以進行SSL的卸載，執行域名轉發、路徑轉發等功能，并且后端節點不需要額外配置VIP（虛擬IP）。

                              文章來源：U-Star技術創作者