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

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

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

在 NAT 和 FULLNAT 模式中，不管是請求數(shù)據(jù)包還是響應數(shù)據(jù)包，都要經(jīng)過負載均衡器。但是響應數(shù)據(jù)包一般要比請求數(shù)據(jù)包大很多，這可能會成為系統(tǒng)的瓶頸。如果能夠?qū)⒄埱髷?shù)據(jù)包轉(zhuǎn)發(fā)到真實服務器之后，響應數(shù)據(jù)包由真實服務器直接返回，這樣對負載均衡器的壓力就小很多。這種模式又應該如何實現(xiàn)呢？

DR 模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TUN 模式

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

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

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

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

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

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

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

NAT、FULLNAT、DR、TUN模式總結(jié)

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

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

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

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

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

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

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

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

關(guān)于UCloud負載均衡服務ULB

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

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

                              文章來源：U-Star技術(shù)創(chuàng)作者