lvs-dr模式原理
為了更清晰的表述lvs-dr原理，我們用tcpdump工具列印出tcp資料，檢視mac位址的更改情況，繪製出如下的時序圖；
圖1表示201收到**訊息，圖2表示200收到**請求(
下面兩張為錯誤的圖，錯誤的理由下面會詳細解釋
上面的資訊全部用tcpdump命令取得(tcpdump -e -x-a -n -s 10000 port 80;具體含義這裡就不詳細講解了)，用上述命令分別在149、200、201上執行。
圖只是輔助理解，剛開始不用研究太深入。可以根據下面的講解慢慢體會。
首先，從兩幅圖中我們都能看到這樣的流程：
tcp建立(
三次握手
)->
交換機傳送請求
->
伺服器響應請求
->tcp
連線斷開
(四次揮手)
下面解答和分享下我所遇到的問題： 問題
1:按照我之前對負載均衡的理解，應該是
149收到交換機發來的訊息，然後**給
201或者
200，為什麼是
201先收到交換機發來的資料，然後**到
149呢？
這個問題也困擾了我好久，後來我把201網線斷掉之後，重新嘗試，發現149和200都沒有收到交換機發過來的訊息，心想應該是被交換機快取了(猜測)。之後把服務全停掉，重新設定lvs配置，然後重啟。之後看到的tcp流，就和預想中的一樣。
當200接收到訊息時，只有149和200會收到tcp流資訊。同理201；
有人會說我這是多此一舉，花了這麼久的圖，最後還是錯的。其實不是這樣。起碼以後我知道如何檢視tcp是否正常，表面上看
lvs**訊息時正常的，其實
tcp流多走了幾步。表面上是負載均衡
,其實一台
realserver
負載非常高。。。。這裡可能會導致很多問題。
有人想要正常的tcp流圖，這裡本人不想再多畫了，如果有時間再補上吧。可以按照上面的圖，把交換機接受的資料移植到149上，就是正常的圖啦。
下面補上正確的lvs-er模式的tcp流圖，201收到訊息時同理：
有了正確的圖理解原理更加方便了。 問題
2：vs-dr
如何**訊息的？
由上圖3中第二步驟可以看出，director接受到交換機的請求，然後根據演算法選取一台realserver，並且把包**過去，realserver接收到包後，直接把結果返回給交換機，而沒有走director。
具體步驟：
1. 接收到源mac位址為38:22:d6:6c:07:5d
，目的位址為00:1a:4d:8c:fa:d5
。源ip為192.168.0.237、目的ip為192.168.30.149
2.vs根據負載均衡，把源mac位址改為00:1a:4d:8c:fa:d5
，目的位址改為00:26:18:45:d7:88
。源ip和目的ip都不變 3.
realserver(00:26:18:45:d7:88)接收到請求,做出響應。源ip改為192.168.30.149，目的ip改為192.168.0.237
4.realserver的訊息源mac為00:26:18:45:d7:88
，目的mac位址為38:22:d6:6c:07:5d
。所以跳過了149，直接返回客戶端請求的資訊。
今天畫圖畫累了，明天有空再講下具體配置問題。。。
LVS DR模式原理剖析
faq 1.lvs dr如何處理請求報文的，會修改ip包內容嗎?1.1 vs dr本身不會關心ip層以上的資訊，即使是埠號也是tcp ip協議棧去判斷是否正確，vs dr本身主要做這麼幾個事 1 接收client的請求，根據你設定的負載均衡演算法選取一台realserver的ip 2 以選取的這個i...
linux lvs的DR模式原理詳解
lvs linux virtual server 通過直接路由實現虛擬伺服器 vs dr vs dr利用大多數internet服務的非對稱特點，負載排程器中只負責排程請求，而伺服器直接將響應返回給客戶，可以極大地提高整個集群 系統的吞吐量。該方法與ibm的netdispatcher產品中使用的方法類...
iOS self 和super原理詳解
self 和 super 1.self呼叫自己方法，super呼叫父類方法 2.self是類，super是預編譯指令 3.self class 和 super class 輸出是一樣的 self和super底層實現原理 1 當使用 self 呼叫方法時，會從當前類的方法列表中開始找，如果沒有，就從父...