本文在分析服務器集群實現虛擬網絡服務的相關技術上，詳細描述了LVS集群中實現的三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它們的優缺點。1.前言 在前面文章中，講述了可伸縮網絡服務的幾種結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。我們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，我們提出了通過IP隧道實現虛擬服務器的方法VS/TUN （Virtual Server via IP Tunneling），和通過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集群中實現的三種IP負載均衡技術，我們將在文章中詳細描述它們的工作原理和各自的優缺點。在以下描述中，我們稱客戶的socket和服務器的socket之間的數據通訊為連接，無論它們是使用TCP還是UDP協議。下面簡述當前用服務器集群實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有代表性的研究項目。2.實現虛擬服務的相關方法在網絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可以在不同的層次上實現多台服務器的負載均衡。用集群解決網絡服務性能問題的現有方法主要分為以下四類。 2.1. 基於RR-DNS的解決方法NCSA的可伸縮的WEB服務器系統就是最早基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工作流程如下圖所示： 圖1：基於RR-DNS的可伸縮WEB服務器
(注：本圖來自文獻【9】)有一組WEB服務器，他們通過分布式文件系統AFS(Andrew File System)來共享所有的Html文檔。這組服務器擁有相同的域名（如www.ncsa.uiUC.edu），當用戶按照這個域名訪問時, RR-DNS服務器會把域名輪流解析到這組服務器的不同IP地址，從而將訪問負載分到各台服務器上。這種方法帶來幾個問題。第一，域名服務器是一個分布式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一台服務器的IP地址。可見，從用戶到RR-DNS間存在多台域名服器，而它們都會緩沖已解析的名字到IP地址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB服務器，出現不同WEB服務器間嚴重的負載不平衡。為了保證在域名服務器中域名到IP地址的映射不被長久緩沖，RR-DNS在域名到IP地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩沖中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設置這個 TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一台WEB服務器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS服務器成為系統中一個新的瓶頸。第二，用戶機器會緩沖從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一台WEB服務器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各台服務器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每個會話中平均請求數為20，負載最大的服務器獲得的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL值為0時，因為用戶訪問的突發性也會存在著較嚴重的負載不平衡。第三，系統的可靠性和可維護性差。若一台服務器失效，會導致將域名解析到該服務器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一台服務器切出服務進行系統維護，如進行操作系統和應用軟件升級，這需要修改RR- DNS服務器中的IP地址列表，把該服務器的IP地址從中劃掉，然後等上幾天或者更長的時間，等所有域名服器將該域名到這台服務器的映射淘汰，和所有映射到這台服務器的客戶機不再使用該站點為止。2.2. 基於客戶端的解決方法基於客戶端的解決方法需要每個客戶程序都有一定的服務器集群的知識，進而把以負載均衡的方式將請求發到不同的服務器。例如，Netscape Navigator浏覽器訪問Netscape的主頁時，它會隨機地從一百多台服務器中挑選第N台，最後將請求送往wwwN.netscape.com。然而，這不是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其他浏覽器不可避免的要進行 RR-DNS解析。Smart Client[3]是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方浏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也在Applet中實現，當服務器沒有響應時，Applet向另一個服務器轉發請求。這種方法的透明性不好，Applet向各服務器查詢來收集信息會增加額外的網絡流量，不具有普遍的適用性。2.3. 基於應用層負載均衡調度的解決方法多台服務器通過高速的互聯網絡連接成一個集群系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程序，分析請求，根據各個服務器的負載情況，選出一台服務器，重寫請求並向選出的服務器訪問，取得結果後，再返回給用戶。應用層負載均衡調度的典型代表有Zeus負載調度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus負載調度器是Zeus公司的商業產品，它是在Zeus Web服務器程序改寫而成的，采用單進程事件驅動的服務器結構。pWeb就是一個基於Apache 1.1服務器程序改寫而成的並行WEB調度程序，當一個HTTP請求到達時，pWeb會選出一個服務器，重寫請求並向這個服務器發出改寫後的請求，等結果返回後，再將結果轉發給客戶。Reverse-Proxy利用Apache 1.3.1中的Proxy模塊和Rewrite模塊實現一個可伸縮WEB服務器，它與pWeb的不同之處在於它要先從Proxy的cache中查找後，若沒有這個副本，再選一台服務器，向服務器發送請求，再將服務器返回的結果轉發給客戶。SWEB是利用HTTP中的redirect錯誤代碼，將客戶請求到達一台WEB服務器後，這個WEB服務器根據自己的負載情況，自己處理請求，或者通過redirect錯誤代碼將客戶引到另一台WEB服務器，以實現一個可伸縮的WEB服務器。
基於應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統處理開銷特別大，致使系統的伸縮性有限。當請求到達負載均衡調度器至處理結束時，調度器需要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內存復制；需要進行二次TCP連接，一次是從用戶到調度器，另一次是從調度器到真實服務器；需要對請求進行分析和重寫。這些處理都需要不小的ＣＰＵ、內存和網絡等資源開銷，且處理時間長。所構成系統的性能不能接近線性增加的，一般服務器組增至3或4台時，調度器本身可能會成為新的瓶頸。所以，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第二，基於應用層的負載均衡調度器對於不同的應用，需要寫不同的調度器。以上幾個系統都是基於HTTP協議，若對於FTP、Mail、POP3等應用，都需要重寫調度器。2.4. 基於IP層負載均衡調度的解決方法用戶通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將報文發送給選定的服務器。真實服務器的回應報文經過負載調度器時，將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。Berkeley的MagicRouter[8]、Cisco的LocalDirector、 Alteon的ACEDirector和F5的Big/IP等都是使用網絡地址轉換方法。MagicRouter是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備接近核心空間的速度，降低了上下文切換的處理開銷，但並不徹底，它只是研究的原型系統，沒有成為有用的系統存活下來。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂貴的商品化系統，它們支持部分TCP/UDP協議，有些在ICMP處理上存在問題。IBM的TCP Router[9]使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的WEB服務器。TCP Router修改請求報文的目標地址並把它轉發給選出的服務器，服務器能把響應報文的源地址置為TCP Router地址而非自己的地址。這種方法的好處是響應報文可以直接返回給客戶，壞處是每台服務器的操作系統內核都需要修改。IBM的 NetDispatcher[10]是TCP Router的後繼者，它將報文轉發給服務器，而服務器在non-ARP的設備配置路由器的地址。這種方法與LVS集群中的VS/DR類似，它具有很高的可伸縮性，但一套在IBM SP/2和NetDispatcher需要上百萬美金。總的來說，IBM的技術還挺不錯的。 在貝爾實驗室的ONE-IP[11]中，每台服務器都獨立的IP地址，但都用IP Alias配置上同一VIP地址，采用路由和廣播兩種方法分發請求，服務器收到請求後按VIP地址處理請求，並以VIP為源地址返回結果。這種方法也是為了避免回應報文的重寫，但是每台服務器用IP Alias配置上同一VIP地址，會導致地址沖突，有些操作系統會出現網絡失效。通過廣播分發請求，同樣需要修改服務器操作系統的源碼來過濾報文，使得只有一台服務器處理廣播來的請求。 微軟的Windows NT負載均衡服務（Windows NT Load Balancing Service，WLBS）[12]是1998年底收購Valence Research公司獲得的，它與ONE-IP中的基於本地過濾方法一樣。WLBS作為過濾器運行在網卡驅動程序和TCP/IP協議棧之間，獲得目標地址為VIP的報文，它的過濾算法檢查報文的源IP地址和端口號，保證只有一台服務器將報文交給上一層處理。但是，當有新結點加入和有結點失效時，所有服務器需要協商一個新的過濾算法，這會導致所有有Session的連接中斷。同時，WLBS需要所有的服務器有相同的配置，如網卡速度和處理能力。 3. 通過NAT實現虛擬服務器（VS/NAT）由於IPv4中IP地址空間的日益緊張和安全方面的原因，很多網絡使用保留IP地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。這些地址不在Internet上使用，而是專門為內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就需要采用網絡地址轉換（Network Address Translation, 以下簡稱NAT），將內部地址轉化為Internets上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們連接一個IP地址，而不同IP地址的服務器組也認為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。VS/NAT的體系結構如圖2所示。在一組服務器前有一個調度器，它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被發送到哪一台服務器，執行結果是一樣的。服務的內容可以復制到每台服務器的本地硬盤上，可以通過網絡文件系統（如NFS）共享，也可以通過一個分布式文件系統來提供。
圖2：VS/NAT的體系結構客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一台服務器，將報文的目標地址 Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在連接Hash 表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，並將報文傳給原選定的服務器。當來自真實服務器的響應報文經過調度器時，調度器將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。我們在連接上引入一個狀態機，不同的報文會使得連接處於不同的狀態，不同的狀態有不同的超時值。在TCP 連接中，根據標准的TCP有限狀態機進行狀態遷移，這裡我們不一一敘述，請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設置的，在缺省情況下，SYN狀態的超時為1分鐘，ESTABLISHED狀態的超時為15分鐘，FIN狀態的超時為1分鐘；UDP狀態的超時為5分鐘。當連接終止或超時，調度器將這個連接從連接Hash表中刪除。這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集群的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若我們只對報文頭的IP地址和端口號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。我們所知道有這個問題的網絡服務有FTP、IRC、 H.323、CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。下面，舉個例子來進一步說明VS/NAT，如圖3所示：
圖3：VS/NAT的例子VS/NAT的配置如下表所示，所有到IP地址為202.103.106.5和端口為80的流量都被負載均衡地調度的真實服務器172.16.0.2: 80和172.16.0.3:8000上。目標地址為202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其他端口的報文將被拒絕。Protocol Virtual IP Address Port Real IP Address Port Weight TCP 202.103.106.5 80 172.16.0.2 80 1 172.16.0.3 8000 2 TCP 202.103.106.5 21 172.16.0.3 21 1 從以下的例子中，我們可以更詳細地了解報文改寫的流程。訪問Web服務的報文可能有以下的源地址和目標地址：SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80 調度器從調度列表中選出一台服務器，例如是172.16.0.3:8000。該報文會被改寫為如下地址，並將它發送給選出的服務器。SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000 從服務器返回到調度器的響應報文如下：SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456 響應報文的源地址會被改寫為虛擬服務的地址，再將報文發送給客戶：SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456 這樣，客戶認為是從202.103.106.5:80服務得到正確的響應，而不會知道該請求是服務器172.16.0.2還是服務器172.16.0.3處理的。
本文在分析服務器集群實現虛擬網絡服務的相關技術上，詳細描述了LVS集群中實現的三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它們的優缺點。1.前言 在前面文章中，講述了可伸縮網絡服務的幾種結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。我們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，我們提出了通過IP隧道實現虛擬服務器的方法VS/TUN （Virtual Server via IP Tunneling），和通過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集群中實現的三種IP負載均衡技術，我們將在文章中詳細描述它們的工作原理和各自的優缺點。在以下描述中，我們稱客戶的socket和服務器的socket之間的數據通訊為連接，無論它們是使用TCP還是UDP協議。下面簡述當前用服務器集群實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有代表性的研究項目。2.實現虛擬服務的相關方法在網絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可以在不同的層次上實現多台服務器的負載均衡。用集群解決網絡服務性能問題的現有方法主要分為以下四類。 2.1. 基於RR-DNS的解決方法NCSA的可伸縮的WEB服務器系統就是最早基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工作流程如下圖所示： 圖1：基於RR-DNS的可伸縮WEB服務器
(注：本圖來自文獻【9】)有一組WEB服務器，他們通過分布式文件系統AFS(Andrew File System)來共享所有的HTML文檔。這組服務器擁有相同的域名（如www.ncsa.uiuc.edu），當用戶按照這個域名訪問時, RR-DNS服務器會把域名輪流解析到這組服務器的不同IP地址，從而將訪問負載分到各台服務器上。這種方法帶來幾個問題。第一，域名服務器是一個分布式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一台服務器的IP地址。可見，從用戶到RR-DNS間存在多台域名服器，而它們都會緩沖已解析的名字到IP地址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB服務器，出現不同WEB服務器間嚴重的負載不平衡。為了保證在域名服務器中域名到IP地址的映射不被長久緩沖，RR-DNS在域名到IP地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩沖中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設置這個 TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一台WEB服務器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS服務器成為系統中一個新的瓶頸。第二，用戶機器會緩沖從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一台WEB服務器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各台服務器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每個會話中平均請求數為20，負載最大的服務器獲得的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL值為0時，因為用戶訪問的突發性也會存在著較嚴重的負載不平衡。第三，系統的可靠性和可維護性差。若一台服務器失效，會導致將域名解析到該服務器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一台服務器切出服務進行系統維護，如進行操作系統和應用軟件升級，這需要修改RR- DNS服務器中的IP地址列表，把該服務器的IP地址從中劃掉，然後等上幾天或者更長的時間，等所有域名服器將該域名到這台服務器的映射淘汰，和所有映射到這台服務器的客戶機不再使用該站點為止。2.2. 基於客戶端的解決方法基於客戶端的解決方法需要每個客戶程序都有一定的服務器集群的知識，進而把以負載均衡的方式將請求發到不同的服務器。例如，Netscape Navigator浏覽器訪問Netscape的主頁時，它會隨機地從一百多台服務器中挑選第N台，最後將請求送往wwwN.netscape.com。然而，這不是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其他浏覽器不可避免的要進行 RR-DNS解析。Smart Client[3]是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方浏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也在Applet中實現，當服務器沒有響應時，Applet向另一個服務器轉發請求。這種方法的透明性不好，Applet向各服務器查詢來收集信息會增加額外的網絡流量，不具有普遍的適用性。2.3. 基於應用層負載均衡調度的解決方法多台服務器通過高速的互聯網絡連接成一個集群系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程序，分析請求，根據各個服務器的負載情況，選出一台服務器，重寫請求並向選出的服務器訪問，取得結果後，再返回給用戶。應用層負載均衡調度的典型代表有Zeus負載調度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus負載調度器是Zeus公司的商業產品，它是在Zeus Web服務器程序改寫而成的，采用單進程事件驅動的服務器結構。pWeb就是一個基於Apache 1.1服務器程序改寫而成的並行WEB調度程序，當一個HTTP請求到達時，pWeb會選出一個服務器，重寫請求並向這個服務器發出改寫後的請求，等結果返回後，再將結果轉發給客戶。Reverse-Proxy利用Apache 1.3.1中的Proxy模塊和Rewrite模塊實現一個可伸縮WEB服務器，它與pWeb的不同之處在於它要先從Proxy的cache中查找後，若沒有這個副本，再選一台服務器，向服務器發送請求，再將服務器返回的結果轉發給客戶。SWEB是利用HTTP中的redirect錯誤代碼，將客戶請求到達一台WEB服務器後，這個WEB服務器根據自己的負載情況，自己處理請求，或者通過redirect錯誤代碼將客戶引到另一台WEB服務器，以實現一個可伸縮的WEB服務器。
基於應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統處理開銷特別大，致使系統的伸縮性有限。當請求到達負載均衡調度器至處理結束時，調度器需要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內存復制；需要進行二次TCP連接，一次是從用戶到調度器，另一次是從調度器到真實服務器；需要對請求進行分析和重寫。這些處理都需要不小的ＣＰＵ、內存和網絡等資源開銷，且處理時間長。所構成系統的性能不能接近線性增加的，一般服務器組增至3或4台時，調度器本身可能會成為新的瓶頸。所以，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第二，基於應用層的負載均衡調度器對於不同的應用，需要寫不同的調度器。以上幾個系統都是基於HTTP協議，若對於FTP、Mail、POP3等應用，都需要重寫調度器。2.4. 基於IP層負載均衡調度的解決方法用戶通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將報文發送給選定的服務器。真實服務器的回應報文經過負載調度器時，將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。Berkeley的MagicRouter[8]、Cisco的LocalDirector、 Alteon的ACEDirector和F5的Big/IP等都是使用網絡地址轉換方法。MagicRouter是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備接近核心空間的速度，降低了上下文切換的處理開銷，但並不徹底，它只是研究的原型系統，沒有成為有用的系統存活下來。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂貴的商品化系統，它們支持部分TCP/UDP協議，有些在ICMP處理上存在問題。IBM的TCP Router[9]使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的WEB服務器。TCP Router修改請求報文的目標地址並把它轉發給選出的服務器，服務器能把響應報文的源地址置為TCP Router地址而非自己的地址。這種方法的好處是響應報文可以直接返回給客戶，壞處是每台服務器的操作系統內核都需要修改。IBM的 NetDispatcher[10]是TCP Router的後繼者，它將報文轉發給服務器，而服務器在non-ARP的設備配置路由器的地址。這種方法與LVS集群中的VS/DR類似，它具有很高的可伸縮性，但一套在IBM SP/2和NetDispatcher需要上百萬美金。總的來說，IBM的技術還挺不錯的。 在貝爾實驗室的ONE-IP[11]中，每台服務器都獨立的IP地址，但都用IP Alias配置上同一VIP地址，采用路由和廣播兩種方法分發請求，服務器收到請求後按VIP地址處理請求，並以VIP為源地址返回結果。這種方法也是為了避免回應報文的重寫，但是每台服務器用IP Alias配置上同一VIP地址，會導致地址沖突，有些操作系統會出現網絡失效。通過廣播分發請求，同樣需要修改服務器操作系統的源碼來過濾報文，使得只有一台服務器處理廣播來的請求。 微軟的Windows NT負載均衡服務（Windows NT Load Balancing Service，WLBS）[12]是1998年底收購Valence Research公司獲得的，它與ONE-IP中的基於本地過濾方法一樣。WLBS作為過濾器運行在網卡驅動程序和TCP/IP協議棧之間，獲得目標地址為VIP的報文，它的過濾算法檢查報文的源IP地址和端口號，保證只有一台服務器將報文交給上一層處理。但是，當有新結點加入和有結點失效時，所有服務器需要協商一個新的過濾算法，這會導致所有有Session的連接中斷。同時，WLBS需要所有的服務器有相同的配置，如網卡速度和處理能力。 3. 通過NAT實現虛擬服務器（VS/NAT）由於IPv4中IP地址空間的日益緊張和安全方面的原因，很多網絡使用保留IP地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。這些地址不在Internet上使用，而是專門為內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就需要采用網絡地址轉換（Network Address Translation, 以下簡稱NAT），將內部地址轉化為Internets上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們連接一個IP地址，而不同IP地址的服務器組也認為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。VS/NAT的體系結構如圖2所示。在一組服務器前有一個調度器，它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被發送到哪一台服務器，執行結果是一樣的。服務的內容可以復制到每台服務器的本地硬盤上，可以通過網絡文件系統（如NFS）共享，也可以通過一個分布式文件系統來提供。
圖2：VS/NAT的體系結構客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一台服務器，將報文的目標地址 Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在連接Hash 表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，並將報文傳給原選定的服務器。當來自真實服務器的響應報文經過調度器時，調度器將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。我們在連接上引入一個狀態機，不同的報文會使得連接處於不同的狀態，不同的狀態有不同的超時值。在TCP 連接中，根據標准的TCP有限狀態機進行狀態遷移，這裡我們不一一敘述，請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設置的，在缺省情況下，SYN狀態的超時為1分鐘，ESTABLISHED狀態的超時為15分鐘，FIN狀態的超時為1分鐘；UDP狀態的超時為5分鐘。當連接終止或超時，調度器將這個連接從連接Hash表中刪除。這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集群的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若我們只對報文頭的IP地址和端口號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。我們所知道有這個問題的網絡服務有FTP、IRC、 H.323、CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。下面，舉個例子來進一步說明VS/NAT，如圖3所示：
圖3：VS/NAT的例子VS/NAT的配置如下表所示，所有到IP地址為202.103.106.5和端口為80的流量都被負載均衡地調度的真實服務器172.16.0.2: 80和172.16.0.3:8000上。目標地址為202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其他端口的報文將被拒絕。Protocol Virtual IP Address Port Real IP Address Port Weight TCP 202.103.106.5 80 172.16.0.2 80 1 172.16.0.3 8000 2 TCP 202.103.106.5 21 172.16.0.3 21 1 從以下的例子中，我們可以更詳細地了解報文改寫的流程。訪問Web服務的報文可能有以下的源地址和目標地址：SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80 調度器從調度列表中選出一台服務器，例如是172.16.0.3:8000。該報文會被改寫為如下地址，並將它發送給選出的服務器。SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000 從服務器返回到調度器的響應報文如下：SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456 響應報文的源地址會被改寫為虛擬服務的地址，再將報文發送給客戶：SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456 這樣，客戶認為是從202.103.106.5:80服務得到正確的響應，而不會知道該請求是服務器172.16.0.2還是服務器172.16.0.3處理的。
