摘要：本系列按照負載均衡器對數據包的處理方式分類，從計算機間通信的角度出發，淺談模型的實現原理。將請求分攤給多臺服務器的行為，就稱之為負載均衡。真實服務器返回的數據包的下一個目的地必須是負載均衡器。

LVS（Linux Virtual Server）是一個虛擬服務器集群系統。工作在 OSI 模型的傳輸層，即四層負載均衡。LVS 本身實現了 NAT、DR、TUN 模型，這些模型僅做數據包的轉發，而不會與客戶端建立連接，成本低效率高。FULLNAT 基于 NAT 實現，LVS 本身不支持，需要額外對內核打補丁后才能使用。

本系列按照負載均衡器對數據包的處理方式分類，從計算機間通信的角度出發，淺談 NAT、FULLNAT、DR、TUN 模型的實現原理。

兩臺計算機如何在互聯網中通信

在了解 LVS 負載均衡之前，先要搞清楚兩臺計算機如何在互聯網中通信。茫茫互聯網中，兩臺計算機如何才能找到對方？

我們先來看看，快遞是如何被快遞小哥完美地送到你手上的。根據你填寫的地址，快遞先送到你所在的省市區，接著在當前省市區找到你的門牌號，最后根據門牌號和姓名，再親手把快遞交給你。

兩臺計算機在互聯網中的通信也是如此。首先需要知道雙方的 IP 地址，即省市區，其次需要知道雙方的 MAC 地址，即門牌號。MAC 地址標志著唯一的計算機。在同一臺計算機上，可能有多個不同的服務，如何能像快遞小哥按照姓名找到你一樣，在計算機上找到對應的服務呢？沒錯，就是按照端口號。

這樣，通信中每臺計算機需要提供的信息就很清晰了，即 IP 地址、MAC 地址、端口號。總結一下，計算機之間通信必需的六個要素就是，源 IP 地址、端口號、源 MAC 地址，目標 IP 地址、端口號、目標 MAC 地址。

假設計算機 A 和計算機 B 在上述的網絡拓撲圖（不在同一局域網）中。可以很清晰地看到 計算機 A 和 計算機 B 通信需要五個步驟，其中 ①② 和 ④⑤ 的原理相同。現在我們來看看具體的每個步驟在計算機的世界中是如何實現的。

首先 A 和 B 的 IP 地址和端口號是已知的，即一個數據包從哪來要發往哪去。所以現在的問題是：A 如何能知道 B 的 MAC 地址？

最簡單的方式就是 A 保存網絡中全部設備的 MAC 地址，在發送時查詢一下，這樣就能得到 B 的 MAC 地址。但是網絡中的設備有幾十億個，還在不斷地增長，顯然這種方式是不可取的。如果按照快遞發送過程中，在每個驛站之間進行轉移，這樣只需要知道該發往的下一目的地在哪里，最終也能將快遞成功地交到你的手上。在實際網絡中發送數據包也是這樣，現在的目標就是確定 “下一個目的地” 的 MAC 地址。

步驟 ①②：發送數據包至網關
A 不知道 B 的 MAC 地址，且 A 和 B 也不在同一個局域網中。這時 A 會根據 ARP 協議先發出一個廣播包，即目標 MAC 地址是 FF:FF:FF:FF:FF:FF 的數據包。當 交換機1 收到這個廣播包之后，會將這個數據包轉發給其他端口，并且記錄 A 的 MAC 地址和交換機端口之間的映射關系，后續再看到這個 MAC 地址，就知道該從哪個端口轉發出去。當 路由器1 收到廣播包后，會將自己的 MAC 地址返回。A 接收到返回后，就知道 “下一個目的地” 的 MAC 地址了。A 重新發送數據包，將目標 MAC 地址填寫為 路由器1 的 MAC 地址，并在本地的緩存表中記錄返回的 MAC 地址。

查看當前設備緩存表里已存的 MAC 地址：arp -a
ARP 協議的目的就是找到“下一個目的地”的 MAC 地址，即 IP 地址和 MAC 地址之間的映射關系。當兩臺設備同處于一個局域網時，“下一個目的地” 就是目標設備的 MAC 地址，當兩臺設備不處于同一個局域網時，“下一個目的地” 就是網關的 MAC 地址。

步驟 ③：網關間跳轉
經過步驟 ①②，此時 路由器1 收到的數據包為 { A_IP、PORT、A_MAC } ? { B_IP、PORT、路由器1_MAC } 。收到數據包后，路由器1 查看自己的路由表，如下圖所示。

查看當前設備設置的路由表：route -n

路由器1 會將 B_IP 與 路由表中每條記錄的子網掩碼（Genmask）做按位與運算。如果得到的結果和目的網絡（Destination）相同，那么 “下一個目的地“ 的 MAC 地址，就是配置的網關（Gateway）的 MAC 地址，這種找到相鄰網絡的方式叫做 “下一跳機制”。如果網關的地址為 0.0.0.0，說明可以在局域網中直接通信，不需要 “下一跳”。至此，再次找到了 “下一個目的地” 的 MAC 地址，即 路由器2 的 MAC 地址。此時 路由器2 收到的數據包為 { A_IP、PORT、路由器1_MAC } ? { B_IP、PORT、路由器2_MAC } 。步驟 ④⑤ 和 ①② 的原理相同，在這里就不贅述了。

下一跳的目的就是找到“下一個目的地”，即下一步該到達哪里，側重 “路線” 的選擇，并由此獲取到對應的 MAC 地址，繼續傳送數據包。

?總結一下：
1.使用 ARP 協議找到網關出口或同一局域網內設備的 MAC 地址
2.按照路由表的每條規則和 目標 IP 地址做按位與運算，找到相鄰網關入口的 MAC 地址
3.“下一個目的地” 和當前地址都僅僅相鄰一步，且每次 “跳躍” 后的源 MAC 地址 和 目標 MAC 地址都會發生對應的替換
4.數據包中，IP 地址指明起點終點，MAC 地址指明跳躍的節點，端口號指明對應的應用服務
當然，光是找到對方還不夠，還需要一個約定的交流方式，平時我們所熟知的各種協議，都是計算機「約定的交流方式」。

LVS 負載均衡

隨著使用互聯網的設備不斷增長，服務端對應接收到的 HTTP 請求更是呈指數型的增長。當一臺服務器無法承載非常大的請求量時，使用多臺服務器來分攤請求。將請求分攤給多臺服務器的行為，就稱之為負載均衡。

ULB（UCloud Load Balancer）是UCloud提供的負載均衡服務，能夠為多個主機或其它服務實例提供基于網絡報文或代理方式的流量分發功能。在高并發服務環境下，通過ULB構建由多個服務節點組成的服務集群。服務集群能夠擴展服務的處理及容錯能力，并自動消除由于單一服務節點故障對服務整體的影響，提高服務的可用性。ULB針對七層協議支持HTTP、HTTPS協議（類Nginx或HAPproxy）；四層協議支持TCP協議及UDP協議（類LVS）。

從網絡中計算機通信的角度，而非使用更上層的應用（如 Nginx）出發，搭建四層負載均衡器后，數據包的發送鏈路為：CIP ? VIP ? DIP ? RIP，即 客戶端 IP ? 虛擬 IP ? 分發 IP ? 真實服務器 IP。對于客戶端來說，只需要知道請求到達的地址是 VIP，不需要考慮負載，即 CIP ? VIP 是固定的。

所以負載均衡器要做的事情，就是將 CIP 發送到 VIP 的數據包，經由 DIP 轉發給 RIP，服務響應后再將響應的數據包返回給 CIP。

NAT 模式

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

1.當計算機發出一個請求的數據包到達負載均衡器后，負載均衡器將發送數據包的 { 目標 IP 地址、端口號、目標 MAC 地址 } 轉換為 { 某臺真實服務器的 IP 地址、真實服務的端口號、真實服務器的 MAC 地址 } ，其余信息不變。這種只轉換數據包的目標設備信息，而不修改數據包的源設備信息，稱之為 DNAT，即目標網絡地址轉換。

2.真實服務器收到請求的數據包，返回響應的數據包：{ 某臺真實服務器的 IP 地址、真實服務的端口號、真實服務器的 MAC 地址 } ?? { 原始請求的 IP 地址、端口號、跳躍的 MAC 地址 } 。所以此時在服務器上查看 TCP 連接為：CIP ?? RIP。

3.真實服務器返回的數據包的 “下一個目的地” 必須是負載均衡器。如果返回數據包直接返回給客戶端，客戶端發現返回數據包的源設備信息和發出數據包的目標設備信息不一致，將會丟棄返回數據包。所以真實服務器的默認網關必須是 DIP，保證返回數據包的 “下一個目的地” 是負載均衡器。

4.當返回的數據包到達負載均衡器后，負載均衡器將返回數據包的 { 原始請求的 IP 地址、端口號、跳躍的 MAC 地址 } 轉換為原始請求的 { 目標 IP 地址、端口號、目標 MAC 地址 } 。這種只轉換數據包的源設備信息，而不修改數據包的目標設備信息，稱之為 SNAT，即源網絡地址轉換。

5.負載均衡器返回數據包給客戶端。

?總結一下 NAT 模式的特點：
1.修改數據包的「源 IP 地址」或 「目標 IP 地址」，可以對端口進行轉發
2.真實服務器的默認網關必須是負載均衡器，所以真實服務器和負載均衡器必須在同一個局域網內
3.所有的請求數據包、響應數據包都要經過負載均衡器

FULLNAT 模式

NAT 模式中，負載均衡器和真實服務器必須在同一局域網內，但在實際的開發過程中，真實服務器可能分布在不同的網段，甚至不同的城市。如何能將 NAT 模式應用在真實服務器分布在不同網段的場景下？

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

1.當計算機發出一個請求的數據包到達負載均衡器后，負載均衡器會對請求數據包同時做 SNAT 和 DNAT，將請求數據包修改為：{ 均衡出口 IP 地址、端口號、負載均衡器的 MAC 地址 } ?? { 某臺真實服務器的 IP 地址、真實服務的端口號、真實服務器的 MAC 地址 }。
2.這樣負載均衡器就可以獨立的和真實服務器進行數據包的傳送。
3.真實服務器收到請求的數據包，返回響應的數據包：{ 某臺真實服務器的 IP 地址、真實服務的端口號、真實服務器的 MAC 地址 } ?? { 負載均衡器的 IP 地址、端口號、負載均衡器的 MAC 地址 } 。此時在真實服務器上查看 TCP 連接為：DIP ?? RIP。
4.當返回的數據包到達負載均衡器后，負載均衡器將返回數據包再次同時做 DNAT 和 SNAT。
5.負載均衡器返回數據包給客戶端。

?總結一下FULL NAT 模式的特點：
1.同時修改數據包的「源 IP 地址」和「目標 IP 地址」，可以對端口進行轉發
2.負載均衡器不需要以網關的形式存在，即負載均衡器可以和真實服務器在不同的網絡中
3.真實服務器最終建立的連接是 DIP ?? RIP，無法獲取真實客戶端的 IP 地址
4.所有的請求數據包、響應數據包都要經過負載均衡器

LVS 本身不支持 FULLNAT 模式，需要額外對內核打補丁后才能使用。

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

                            文章來源：U-Star技術創作者![4.png](https://uclub-file.ucloud.cn/uploads/20211217/bfa93859b9b319baf73df979e12db6e6.png)