PC机运行迅雷软件，迅雷发起包括plugin.x17.xunlei.com会员登陆域名在内的与迅雷相关的域名解析请求超过30个，而返回的域名解析IP地址则与用户所配置DNS的运营商保持一致。当开启下载任务时，表现更为明显，在提供P2P下载数据量最多的20个IP地址中，几乎看不到其他运营商的IP地址。这就导致了在多运营商链路的环境中，P2P流量几乎完全从用户使用的DNS运营商链路转发，造成链路流量分配不均，可见用户选择的DNS服务器对于出向链路的流量负载影响极大。
既然DNS解析能够影响链路流量的分配，我们也可以利用这点来实现链路流量的均衡分配。在ISP地址精确匹配基础之上，我们通过A10的负载均衡设备针对用户的DNS服务配置服务器负载均衡，将用户的DNS请求以加权轮询的方式分配到各链路对应的DNS服务器，通过权值比例来控制各链路的流量分配。这样可以通过ISP地址精确匹配来提高用户的上网感受，也避免了链路探测所面临时间周期内流量分配不均衡的问题。
这样的解决方案对于用户来说也是十分方便，用户可以继续使用原有的DNS配置，不需要做任何配置更改；如果在DHCP环境下，甚至可以为用户分配一个像100.100.100.100这样的虚拟DNS服务器地址。
下面为大家提供一个测试实例，介绍一下方案中AX系列设备DNS解析加权轮询的配置，以及在实际环境中所达到的效果。先介绍一下测试环境：测试网络有100M联通链路和200M电信链路两条出口，高峰期在线用户1500人左右。
用户采用ISP地址精确匹配，由于电信链路带宽大一些，用户最早将电信DNS通过DHCP分配给网内用户，发现流量分配不均衡后将电信DNS替换成联通的DNS，问题依然存在。
下图是AX设备上线后用户配置联通DNS，AX没做DNS请求轮询分配时的抓图。
截图期间用户网络有近300人使用电信DNS，但电信链路在高峰期依然存在大量空闲，而联通的链路在21点后完全被占满。
我们在AX设备上配置DNS轮询查询：
配置电信与联通的真实DNS服务器，使用默认的udp端口健康监测。
slb server ctc_dns 1.1.1.1
port 53 udp
slb server cuc_dns 2.2.2.2
port 53 udp
配置DNS服务器组，选择加权轮询方法。
slb service-group dns_group udp
method weighted-rr
member ctc_dns:53
member cuc_dns:53
配置到100.100.100.100的UDP 53端口请求分配给dns_group处理，并作源地址转换，snat_group内包括电信和联通的nat地址池。
slb virtual-server to_dns 100.100.100.100
port 53 udp
source-nat pool snat_group
service-group dns_group
no-dest-nat
这里加两条精确的静态路由,目的地址为运营商dns服务器，下一跳为dns对应链路的网关，我们这样配置的目的是让dns请求本身能够快速访问。
ip route 1.1.1.1/32 a1.b1.c1.d1
ip route 2.2.2.2/32 a2.b2.c2.d2
完成以上配置，我们将用户网络的dhcp服务器中dns地址改为100.100.100.100后，观察用户网络流量分配，基本实现链路负载均衡，当天截图如下：
上图可以看到在高峰期两条链路基本都被占满，联通链路负载稍重的原因是由于配置当天有少部分用户dns没有更新，且没有做细致的权重比例调整。
通过将dns解析请求轮询分配给不同运营商dns服务器来控制链路流量分配，虽然不是完美的解决方案，但却可以称得上是当前最适合国内的网络环境的出向链路负载解决方案，具有原理简单、配置容易、设备本身资源消耗低的特点，且能够全面满足开篇提到的链路负载解决方案的3个要求。
；QQ联络：1360095750。