LVS 負載均衡器理論基礎及抓包分析

LVS 是 Linux Virtual Server 的簡寫，即 Linux 虛擬服務器，是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。（百科）

kube-proxy 的ipvs模式是 2015年由k8s社區大佬thockin提出的（https://github.com/kubernetes/kubernetes/issues/17470），在2017年由華爲雲團隊實現的（https://github.com/kubernetes/kubernetes/issues/44063），在kubernetes v1.8中已經引入了ipvs模式。
ipvs模式的實現也是實現了ipvsadm這個核心組件，由於我們都使用LVS，對這個組件都有所瞭解，這裏簡單做下總結。

LVS 基礎

LVS 核心組件

ipvsadm：用戶空間的命令行工具，用於管理集羣服務及集羣服務上的RS等；（管理工具）
ipvs：工作於內核上的程序，可根據用戶定義的集羣實現請求轉發；（內核模塊）

LVS 專業術語

VS：Virtual Server （虛擬服務）
DS：Director Server（負載均衡器）
RS：Real Server （後端真實處理請求的服務器）
CIP: Client IP （用戶端IP）
VIP：Director Virtual IP （負載均衡器虛擬 IP）
DIP：Director IP （負載均衡器 IP）
RIP：Real Server IP （後端請求處理服務器 IP）

工作原理

IPVS 是工作在 INPUT 鏈上的，當用戶請求到達 INPUT 鏈時，IPVS 會將用戶請求與自己已定義好規則進行比對，如果用戶請求的就是定義的集羣服務，那麼此時 IPVS 會強行修改數據包裏的目標 IP 地址及端口，並將新的數據包發往 POSTROUTING 鏈；
ipvs (IP Virtual Server) 實現了4層負載均衡，ipvs 運行在主機上，在Real Server 集羣前充當LB（負載均衡器），ipvs 將基於 TCP 和 UDP 的服務請求轉發到真實服務器上，並使真實服務器上面的服務，能夠在前面 Director Server上、通過提供的 VIP 對外提供服務。

LVS 常用算法

RR（Round Robin）：輪詢調度，在不考慮每臺服務器處理能力的情況下，輪詢調度算法是把來自用戶的請求輪流分配給內部中的服務器，從1開始，直到N(內部服務器個數)，然後重新開始循環；
WRR（Weight Round Robin）：加權輪詢，由於每臺服務器的配置、跑業務類型不同，其處理能力也會不同，所以我們根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數據的服務請求；
DH（Destination hashing）：目標地址散列，根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空；
SH（Source Hashing）：源地址散列，主要實現會話綁定，能夠將此前建立的session信息保留了，根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空；
LC（Least Connections）：最少鏈接，將網絡請求調度到已建立的鏈接數最少的服務器上。如果集羣系統的真實服務器具有相近的系統性能，採用“最小連接”調度算法可以較好地均衡負載；
WLC（Weighted Least Connections）：加權最少鏈接，在集羣系統中的服務器性能差異較大的情況下，調度器採用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載，調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值；
除上面一些常用調度算法外，還有一些幾個，如下：LBLC（Locality-Based Least Connections）基於局部性的最少鏈接、LBLCR（Locality-Based Least Connections with Replication）帶複製的基於局部性最少鏈接、SED（Shortest Expected Delay Scheduling）最短的期望的延遲、NQ（Never Queue Scheduling NQ）最少隊列調度；

LVS 模式

DR、NAT、隧道模式；（後面重點講解）

LVS 組件安裝

yum -y install ipvsadm

ipvsadm 常用配置參數
-A 添加虛擬服務VIP
-D 刪除虛擬服務VIP
-L 查看虛擬服務VIP
-C 清除所有虛擬服務VIP
-t 指定虛擬服務及端口 VIP:Port
-r 指定真實服務及端口 RS:Port
-s 指定算法，rr（輪詢）、wrr（加權輪詢）、lc（最少連接）、sh（源地址散列）、dh(目標地址散列) 等等
-w 指定權重
-m 指定轉發模式爲NAT
-g 指定轉發模式爲DR
-i 指定轉發模式爲IPIP隧道

NAT 模式

報文請求過程圖

報文請求過程分析

當用戶請求到達 DS 時，請求報文會先經過內核空間中的 PREROUTING 鏈，此時源 IP 爲CIP，目的 IP 爲 VIP；
在 PREROUTING 規則鏈上進行檢查目的IP是否爲本機，如果是的話將數據包送至 INPUT 鏈；
數據包到達INPUT鏈後，IPVS 會比對數據包請求的服務是否爲集羣服務，若是，修改數據包的目標 IP 地址爲後端服務器 IP（這裏需要根據各種算法計算，哪臺 RS 更合適），再將數據包發至 POSTROUTING 鏈，此時報文的源 IP 爲 CIP，目標 IP 爲 RIP；
POSTROUTING 鏈的作用就是選路，根據 INPUT 鏈中目標 IP，將數據包發送給 RS；
RS 發現數據包中的目標 IP 是自己的 IP，此時它會開始構建響應報文發並回給 DS，此時報文的源IP爲RIP，目標IP爲 CIP；
DS 收到 RS 響應後，但在響應客戶端，會將源 IP 地址修改爲自己的 VIP 地址，然後發送給客戶端，此時報文的源 IP 爲 VIP，目標 IP 爲 CIP；

NAT 實驗

NAT 模式時，LB 節點IP與RS節點IP可以不在同一個網絡內，現爲了模擬我們在 LB 節點添加一虛擬IP 如下，並測試連通性。

[root@master02 ~]# ip addr add 100.222.111.1/24 dev ens32
[root@master02 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:56:8e:53:c1 brd ff:ff:ff:ff:ff:ff
    inet 1.65.15.141/24 brd 1.65.15.255 scope global ens32
       valid_lft forever preferred_lft forever
    inet 100.222.111.1/24 scope global ens32
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:46:24:ae:8c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
[root@master02 ~]# ping -c 1 100.222.111.1
PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.
64 bytes from 100.222.111.1: icmp_seq=1 ttl=64 time=0.033 ms

--- 100.222.111.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
[root@master02 ~]#

創建負載均衡service

[root@master02 ~]# ipvsadm -A -t 100.222.111.1:8000 -s rr
[root@master02 ~]#

添加 RS 到指定的負載均衡器下

[root@master02 ~]# ipvsadm -a -t 100.222.111.1:8000 -r 1.65.15.143:80 -m
[root@master02 ~]# ipvsadm -a -t 100.222.111.1:8000 -r 1.65.15.144:80 -m
[root@master02 ~]#

在client上面訪問VIP

[root@master01 ~]# ping -c 1 100.222.111.1
PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.

--- 100.222.111.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

[root@master01 ~]#

我們發現並不通，由於這個VIP是虛擬的，需要添加路由，添加靜態路由如下。

[root@master01 ~]# ip route add 100.222.111.1 via 1.65.15.141 dev ens32
[root@master01 ~]#

繼續測試連通性

[root@master01 ~]# ping -c 1 100.222.111.1
PING 100.222.111.1 (100.222.111.1) 56(84) bytes of data.
64 bytes from 100.222.111.1: icmp_seq=1 ttl=64 time=0.088 ms

--- 100.222.111.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.088/0.088/0.088/0.000 ms
[root@master01 ~]#

發現可以ping通了，我們接下來驗證service

[root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
curl: (28) Connection timed out after 15001 milliseconds
[root@master01 ~]#

LB抓包

RS 抓包如下

數據包的源IP爲CIP，目標IP爲RIP，LB節點 IPVS 只做了 DNAT，只是把目標IP改成RS IP了，而沒有修改源IP。此時雖然RS和CIP（client）在同一個子網，鏈路連通性沒有問題，但是由於 CIP 節點發出去的包的目標IP和收到的包源IP不一致，因此會被直接丟棄，所以需要在iptables 上做地址僞裝。

[root@master02 ~]# iptables -t nat -A POSTROUTING -m ipvs --vaddr 100.222.111.1 --vport 8000 -j MASQUERADE
[root@master02 ~]# iptables -t mangle -A POSTROUTING -m ipvs --vaddr 100.222.111.1 --vport 8000 -j LOG --log-prefix '[k8svip ipvs]'
[root@master02 ~]#

上面我們在LB節點做地址僞裝，並且把經過iptables的轉發日誌記錄下來，這裏需要注意，只能在mangle表才能記錄，在nat表時，無法記錄轉發日誌，再次測試，發現依然不通；

[root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
curl: (28) Connection timed out after 15001 milliseconds
[root@master01 ~]#

哪問題出在什麼地方呢？由於PROC文件系統的/proc/sys/net/ipv4/vs/conntrack可控制IPVS是否對其連接啓用Netfilter系統的conntrack功能，默認情況下是關閉狀態，這裏需要打開，如下。

[root@master02 ~]# sysctl net.ipv4.vs.conntrack=1
net.ipv4.vs.conntrack = 1
[root@master02 ~]#

下面這個圖是是否開啓conntrack功能的iptables日誌對比，上面只是SYN，根本無法完成三次握手，缺少鏈路追蹤，這裏需要再開啓conntrack功能。

再次測試，成功。

[root@master01 ~]# curl -m 15 --retry 1 -sSL 100.222.111.1:8000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
。。。。。
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master01 ~]#

RS 抓包

LB抓包

到這裏nat實驗就完成了，可以看下數據包，源IP已經變成了LB的IP。

NAT 特性總結

RS 的 RIP 與 DS 的 DIP 必須使用相同網段的私網地址，並且 RS 的網關要指向 DS 的 DIP；
客戶端的請求和響應報文都要經由 DS 轉發，在大併發、大流量的場景中，DS有可能會成爲系統瓶頸；
支持端口映射；

DR 模式

報文請求過程圖

報文請求過程分析

當用戶請求到達 DS 時，請求報文會先經過內核空間中的 PREROUTING 鏈，此時源IP爲CIP，目的 IP 爲 VIP；
在 PREROUTING 規則鏈上進行檢查目的IP是否爲本機，如果是的話將數據包送至 INPUT 鏈；
數據包到達INPUT鏈後，IPVS 會比對數據包請求的服務是否爲集羣服務，若是，將請求報文中的源 MAC 地址修改爲 DIP 的 MAC 地址，將目標 MAC 地址修改 RIP 的 MAC 地址（這裏需要IPVS根據策略算法選擇一臺合適的 RS 的 MAC 地址），然後再將數據包發至 POSTROUTING 鏈，此時的源 IP 和目標 IP 均未修改，僅修改了源和目的的MAC地址（DR 模式要求 DS 與 RS 也必須是同一個物理網絡中，可公、可私）；
POSTROUTING鏈檢查目標 MAC 地址爲哪一個 RIP 的 MAC 地址，選擇後，再把數據包將會發給 RS；
RS 發現請求報文的 MAC 地址是自己的 MAC 地址，就接收此報文並處理，將響應報文通過 lo 接口傳送給 eth0 網卡然後向外發出，此時的源IP地址爲VIP，目標IP爲CIP；
響應報文最終到客戶端；

DR 實驗

從DR模式原理可知，調度器只是修改請求報文的目的mac（二層轉發），這就要求調度器和RS需要在同一個網段，並且也無需要開啓ip_forward，所以需要分配一個同網段的IP 做爲VIP；

[root@master02 ~]# ping -c 1 1.65.15.145
PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
From 1.65.15.141 icmp_seq=1 Destination Host Unreachable

--- 1.65.15.145 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

[root@master02 ~]#

添加 VIP 網卡信息

[root@master02 ~]# ifconfig ens32:0 1.65.15.145/24 up
[root@master02 ~]#

創建 service 負載均衡

[root@master02 ~]# ipvsadm -A -t 1.65.15.145:80 -s rr
[root@master02 ~]#

把 RS 添加到負載均衡

[root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.143:80 -g
[root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.144:80 -g
[root@master02 ~]#

客戶端連通性測試

[root@master01 ~]# ping -c 1 1.65.15.145
PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
64 bytes from 1.65.15.145: icmp_seq=1 ttl=64 time=0.078 ms

--- 1.65.15.145 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.078/0.078/0.078/0.000 ms
[root@master01 ~]#

負載測試

[root@master01 ~]# curl -m 15 --retry 1 -sSL 1.65.15.145:80
curl: (7) Failed connect to 1.65.15.145:80; 沒有到主機的路由
[root@master01 ~]#

發現負載服務不通，進行抓包分析
dr模式LB抓包

dr模式RS抓包

根據 DR 模式路由轉發原理，LB上面源MAC地址修改爲LB的MAC地址，而目標MAC地址修改爲RS MAC地址，上圖中已經發現MAC正常修改了，但爲什麼不通呢？在RS數據包中發現源IP和目標IP也都未修改，那麼問題來了，我們Client期望訪問的是RS（通過 mac 二次互訪），但RS收到的目標IP卻是LB上面的VIP，發現這個目標IP並不是自己的IP，因此不會通過 INPUT 鏈轉發到用戶空間，這時要不直接丟棄這個包，要不根據路由再次轉發到其他地方，總之兩種情況都不是我們期望的結果。那怎麼辦呢？如果想讓RS接收這個包，必須得讓RS有這個目標IP纔行，不妨在lo上添加個虛擬IP，IP地址僞裝成LB IP 1.65.15.145。所以需要在RS上面添加虛擬IP，並且添加一條路由如下。

[root@master03 ~]# ifconfig lo:0 1.65.15.145/32 up
[root@master03 ~]# route add -host 1.65.15.145 dev lo
[root@master03 ~]#

此時問題又來了，這就相當於在一個局域網內有兩個相同的IP，IP重複了怎麼辦？辦法就是隱藏這個虛擬網卡，不讓它回覆ARP，其他主機的neigh也就不可能知道有這麼個網卡的存在了。

[root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
[root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
[root@node01 ~]#

arp_ignore=1，只響應目的IP地址爲接收網卡上的本地地址的arp請求。
因爲我們在RS上都配置了VIP，因此此時是存在IP衝突的，當外部客戶端向VIP發起請求時，會先發送arp請求，此時調度器和RS都會響應這個請求。如果某個RS響應了這個請求，則之後該客戶端的請求就都發往該RS，並沒有經過LVS，因此也就沒有真正的負載均衡，LVS也就沒有存在的意義。因此我們需要設置RS不響應對VIP的arp請求，這樣外部客戶端的所有對VIP的arp請求才會都解析到調度器上，然後經由LVS的調度器發往各個RS。
系統默認arp_ignore=0，表示響應任意網卡上接收到的對本機IP地址的arp請求(包括環回網卡上的地址)，而不管該目的IP是否在接收網卡上。也就是說，如果機器上有兩個網卡設備A和B，即使在A網卡上收到對B IP的arp請求，也會迴應。而arp_ignore設置成1，則不會對B IP的arp請求進行迴應。由於lo肯定不會對外通信，所以如果只有一個對外網口，其實只要設置這個對外網口即可，不過爲了保險，很多時候都對all也進行設置。
arp_announce=2，網卡在發送arp請求時使用出口網卡IP作爲源IP。
當RS處理完請求，想要將響應發回給客戶端，此時想要獲取目的IP對應的目的MAC地址，那麼就要發送arp請求。arp請求的目的IP就是想要獲取MAC地址的IP，那arp請求的源IP呢？自然而然想到的是響應報文的源IP地址，但也不是一定是這樣，arp請求的源IP是可以選擇的，而arp_announce的作用正是控制這個地址如何選擇。系統默認arp_announce=0，也就是源ip可以隨意選擇。這就會導致一個問題，如果發送arp請求時使用的是其他網口的IP，達到網絡後，其他機器接收到這個請求就會更新這個IP的mac地址，而實際上並不該更新，因此爲了避免arp表的混亂，我們需要將arp請求的源ip限制爲出口網卡ip，因此需要設置arp_announce=2。（解釋來源於網絡）
測試連通性

[root@master01 ~]# curl 1.65.15.145:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
 
。。。。
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master01 ~]#

RS抓包如下

LB抓包如下

通過數據包分析可以發現MAC地址的轉換，及源目標IP的轉換關係，到此這個DR實驗完成。

DR 模式特性總結

前端路由器將目標 IP 爲 VIP 時的請求報文，發往DS，需要在前端網關做靜態綁定，RS上使用 arptables，並且在RS上修改內核參數以限制 arp 通告及應答級別；
修改 RS 上內核參數（arp_ignore和arp_announce）將 RS 上的 VIP 配置在 lo 接口的別名上，並限制其不能響應對 VIP 地址解析請求；
RS 的 RIP 可以使用私網地址，也可以是公網地址，但 RIP 與 DIP 必須在同網絡內，RIP 的網關不需要也不能指向 DIP，以確保響應報文不會經由 DS；
請求報文要經由 DS，但響應時不經過 DS，而是由 RS 直接發往客戶端；
DR 模式不支持端口映射；

IPIP 模式

報文請求過程圖

報文請求過程分析

當用戶請求到達 DS 時，請求報文會先經過內核空間中的 PREROUTING 鏈，此時源IP爲CIP，目的 IP 爲 VIP；
在 PREROUTING 規則鏈上進行檢查目的IP是否爲本機，如果是的話將數據包送至 INPUT 鏈；
數據包到達INPUT鏈後，IPVS 會比對數據包請求的服務是否爲集羣服務，若是，在請求報文的首部再次封裝一層 IP 報文，封裝源 IP 爲 DIP，目標 IP 爲 RIP，然後發至POSTROUTING鏈，此時源 IP 爲 DIP，目標 IP 爲 RIP；
POSTROUTING 鏈根據最新封裝的 IP 報文，將數據包發至 RS（因爲在外層封裝多了一層IP首部，所以可以理解爲此時通過隧道傳輸）；此時源 IP 爲 DIP，目標 IP 爲 RIP；
RS 接收到報文後發現是自己的 IP 地址，就將報文接收下來，拆除掉最外層的 IP 後，會發現裏面還有一層 IP 首部，而且目標是自己的 lo 接口 VIP，那麼此時 RS 開始處理此請求，處理完成之後，通過 lo 接口送給 eth0 網卡，然後向外傳遞，此時的源 IP 地址爲 VIP，目標 IP 爲 CIP；
響應報文最終送達至客戶端；

IPIP 實驗

DR 模式是通過MAC地址進行交換，只能限制在一個局域網內，而TUN隧道方式，是通過給數據包加上新的IP頭部來實現，這個可以跨機房（可以實現異地容災）、跨公網、主要是解決不能跨網的問題；
添加 VIP 網卡信息

# 配置 VIP
[root@master02 ~]# ifconfig ens32:1 1.65.15.145 netmask 255.255.255.0 up

# 測試連通性
[root@master02 ~]# ping -c 1 1.65.15.145
PING 1.65.15.145 (1.65.15.145) 56(84) bytes of data.
64 bytes from 1.65.15.145: icmp_seq=1 ttl=64 time=0.026 ms

--- 1.65.15.145 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
[root@master02 ~]#

創建負載均衡

[root@master02 ~]# ipvsadm -A -t 1.65.15.145:80 -s rr
[root@master02 ~]#

添加RS到LB

# 添加 RealServer 作爲 VIP 的後端
[root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.143:80 -i
[root@master02 ~]# ipvsadm -a -t 1.65.15.145:80 -r 1.65.15.144:80 -i
[root@master02 ~]#

負載均衡器（LB）要開啓轉發功能

[root@master02 ~]# echo 1 >/proc/sys/net/ipv4/ip_forward
[root@master02 ~]#

查看負載情況

[root@master02 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 1.65.15.145:80 rr
  -> 1.65.15.143:80 Tunnel 1 0 0
  -> 1.65.15.144:80 Tunnel 1 0 0
[root@master02 ~]#

RealServer 配置tunl0 （所有RS服務器）

# 加載下 tunl 模式
[root@node01 ~]# modprobe ipip

# 爲 tunl0 網口配置 IP（即VIP）
[root@node01 ~]# ifconfig tunl0 1.65.15.145 netmask 255.255.255.255 up
[root@node01 ~]#

修改內核參數（所有RS服務器）

[root@node01 ~]# echo 0 > /proc/sys/net/ipv4/ip_forward
[root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore
[root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce
[root@node01 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
[root@node01 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
[root@node01 ~]# echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
[root@node01 ~]# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

arp_ignore 與 arp_announce上面已經有詳細說明，這裏說下rp_filter，官方說明 https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
rp_filter 參數主要是用於控制系統是否開啓對數據包源地址的校驗，它有3個值，0、1、2。
0：不開啓源地址檢驗；
1：開啓嚴格的反向路徑校驗，對每個入訪的數據包，通過指定網卡，校驗其出訪路徑是否爲最佳路徑，如果不是最佳路徑，則直接丟棄；(Linux 服務器默認是1)
2：開啓鬆散的反向路徑校驗，對每個進來的數據包，通過任意網口，校驗其源地址是否可達，即反向路徑是否能通，如果不通，則丟棄；
其實這個參數和安全也息息相關：

Distribute Deny of Service 即分佈式拒絕服務攻擊，原理就是通過構造大量的無用數據包向目標服務發起請求，佔用目標服務主機大量的資源，還可能造成鏈路上面網絡擁塞，進而影響到正常用戶的訪問，我們把這個參數設爲1，嚴格校驗數據包的反向路徑，如果出訪路徑不合適，就直接丟棄數據包，這樣避免過多的無效連接消耗Linux系統資源；
IP Spoofing 即 IP 欺騙，是指客戶端通過僞造源IP，冒充另外一個客戶端與目標服務進行通信，從而達到劫持的目的，如果我們把參數設爲1，嚴格校驗數據包的反向路徑，如果客戶端僞造的源IP地址對應的反向路徑不在路由表中，或者反向路徑不是最佳路徑，則直接丟棄數據包，不會向僞造IP的客戶端回覆響應。
測試訪問

[root@master01 ~]# curl -m 15 --retry 1 -sSL http://1.65.15.145
<!DOCTYPE html>
<html>
<head>
。。。
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master01 ~]#

RS 抓包

通過RS抓包，可以清楚看出IPIP隧道數據包封裝的格式，但回包的時候，直接就回了；
DS抓包（轉發server）

這個數據包，感覺有問題，後面我再查下，分析下原因，如果有人知道，也可交流；

IPIP 特性總結

DIP, VIP, RIP 都應該是公網地址；
RS 的網關不能、也不可能指向DIP；
請求報文要經由 DS，但響應不經過 DS；
不支持端口映射；
RS 的 OS 得支持隧道功能；

總結

由於各個公司實際情況不同、業務類型不同、容災策略、基礎架構不同，需要結合自己公司的情況進行分析，然後選擇合適的解決方案。
本文摘自Linux雲計算網絡

8小時Python零基礎輕鬆入門

LVS 負載均衡器理論基礎及抓包分析

LVS 基礎

LVS 核心組件

LVS 專業術語

工作原理

LVS 常用算法

LVS 模式

LVS 組件安裝

NAT 模式

報文請求過程圖

報文請求過程分析

NAT 實驗

NAT 特性總結

DR 模式

報文請求過程圖

報文請求過程分析

DR 實驗

DR 模式特性總結

IPIP 模式

報文請求過程圖

報文請求過程分析

IPIP 實驗

IPIP 特性總結

總結

PDManer [元數建模]-v4.9.0 發佈：一款簡單好用的數據庫建模平臺

使用neovim打造go ide(支持代碼跳轉, 代碼補全, 實時語法檢查)

挑戰程序設計競賽 2.3章習題 poj 3046 Ant Counting

[MASM拾遺]Offset僞指令

h30 HTML Layout Elements

瞭解顯卡

Shell/Python中的用戶名獲取

Linux+Nginx+Php+MariaDB+Redis部署

Python內置函數列表

製作網頁黑白背景

Linux命令總結大全，包含所有linux命令

vi指令總結

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結