这样，客户所看到的只是在Virtual IPAddress上提供的服务，而服务器集群的结构对用户是透明的。对改写后的报文，应用增量调整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 WeightTCP 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处理的。
Virtual Server via Direct Routing(VS/DR)VS/DR利用大多数Internet服务的非对称特点，Director中只负责调度请求，而后台real_server服务器直接将响应返回给客户，不再通过Director进行转发。
DR方式是通过改写请求报文中的MAC地址部分来实现的。Director和RealServer必需在物理上有一个网卡通过不间断的局域网相连,如通过高速的交换机或者HUB相连。
VIP地址为Director和RealServer组共享，RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如eth0或lo),Director的VIP地址对外可见，而RealServer的VIP对外是不可见的,只是用于处理目标地址为VIP的网络请求,RealServer的地址即可以是内部地址，也可以是真实地址。
VS/DR的体系结构如图所示:
图4：VS/DR的体系结构
VS/DR 的工作流程如图5所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。在VS/DR中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。
图5：VS/DR的工作流程