节省大家时间，首先说主旨：
　　
　　包级别的 TCP/UDP 负载均衡和NAT(Network Address Translate)不能并存。
　　
　　 这是什么意思呢？简单来说，如果你有动态IP的连接，一个使用私有IP地址的局域网，通过NAT(Network Address Translate)上网，现在觉得速度不够，想再加一条使到某一Internet主机的速度加倍（现在中国大陆的典型情况），对不起，你就死了这条心吧，这是不可能的。
　　
　　
　　 这里所说的连接包括 Ethernet，PPPoE,PPPoA，PPP，以及SLIP等等。并且，这是TCP/UDP 协议的内在机制造成的，和软/硬件无关。任何架构在 TCP/UDP 之上的应用，不论硬件还是软件，皆不能绕过此限制。
　　
　　 注意，如果你的局域网使用公用IP（public IP）而不需要NAT，则不在此列。
　　
　　 如果你想知道原因或者质疑我的结论:），请继续往下读。
　　
　　本文假设
　　
　　1.你已经阅读过 Linux Advanced Routing & Traffic Control HOWTO，特别是 4.2 小节的 Routing for multiple uplinks/providers，4.2.1小节Split access 和4.2.2小节 Load balancing。此文（以下按惯例简称lartc）非常清楚的说明了连接级别的TCP/UDP 负载均衡。
　　
　　
　　
　　 ________
　　
　　 +------------+ /
　　
　　 | | |
　　
　　 +--- NATed ---+ Provider 1 +-------
　　
　　 __ IP1 | 100.0.0.1 | | / remote host 1
　　
　　 ___/ \__ +------+-------+ +------------+ |
　　
　　 _/ \_ | if1 | /
　　
　　 / local host 1\ | | |
　　
　　| Local network -----+ Linux router | | Internet
　　
　　 \_local host 2/ | | |
　　
　　 \__ __/ | if2 |
　　 \___/ +------+-------+ +------------+ |
　　
　　 IP2 | 150.0.0.1 | | \ remote host 2
　　
　　 +--- NATed ---+ Provider 2 +-------
　　
　　 | | |
　　
　　 +------------+ \________
　　
　　
　　
　　上面这幅示意图即摘自 lartc，官方站点是 http://lartc.org/。为行文方便，列在这里并做轻微改动，特此说明。
　　2.为便于理解，以下以常见的Linux 下 ADSL PPPoE 拨号上网为例，但如前所述，讨论适用于其它各种情况。用数对(IP address, port)来表示一个连结的端点。假定
　　
　　
　　
　　 Host IP Port
　　
　　
　　 local host 1 192.168.0.1 5000
　　
　　 Linux route if1 100.0.0.1 6000
　　
　　 Linux route if2 150.0.0.1 7000
　　
　　 remote host 1 200.0.0.1 80
　　
　　那么连接级别和包级别的负载均衡究竟有何不同？
　　
　　1、连结级别的负载均衡
　　
　　 Linux 2.4内核支持连结级别的负载均衡。为理解这个问题，这里首先简述 Linux 的静态路由机制。当一部 Linux 主机收到一个需要转发的IP包时，它首先检查Cache中是否有相关的路由信息：如果有的话，会直接使用；否则再查找路由表。Cache中一段时间不使用的路由信息会被丢弃。如果设置了 MultiPath 路由，则选择哪一个路由是随机的，但随后的IP包都会走这条路由，直到Cache中的路由信息被丢弃。
　　
　　 比如，当LAN上的主机 local host 1 向 remote host 1 发起一次连结的时候，Linux router 在Cache中找不到有关remote host 1 的路由信息，因此转去查找路由表，当它发现有一个 MultiPath 路由的时候，会随机选择一个路由，比方说 if1，并把此路由加入Cache；下一个从 local hsot 1到 remote host 1 的 IP 包到达时，Linux router 直接在Cache 中找到路由信息然后直接转发，也就是说，所有目的地为 remote host 1 的 IP 包都会经由 if1 转发直到 Cache 中相关路由信息失效并被丢弃为止而不会经过if2，即使if2完全空闲也是如此。
　　
　　 因此，和 remote host 1 之间的通信并不会从附加的第二条连接中获益。其实际效果就是你用 Realplay 看网络电影时效果没有改善，当然心理作用除外:)
　　
　　 如果与此同时 local host 1 有发起一条到 remote host 2 的连接，则有可能这一次会使用 if2。其实际效果就是你用 Realplay 看网络电影时用 flashget开8个并发线程到一个FTP站下载一个 600M Redhat ISO 文件，两者不会互相影响。
　　
　　 那么，下载 ISO 文件的同时 localhost 2 发起一条到 remote host 2 的连接，会出现怎样的情况？是简单地走if1？又或别有蹊径？请读者思考。
　　
　　2、包级别的负载均衡
　　
　　 现实中这种一边忙一边无所事事的情况在所多有，毋庸赘述:)。那么如何改善呢？很自然的想到，我们可以把同一条TCP/IP连接中的IP包同时从两条上行连接中发出，左右开弓，不就可以了吗？实际上，我们在 PPP Multilink 就是这么干的，不过现在没有服务器的支持，要靠自己。这是Internet，因此已经有人想到这一点并且编写了内核补丁供下载，请搜索 equalize_2.4.18.patch。
　　
　　 需要特别提醒你的是，请确保该补丁的日期是 Fri Mar 22 2002，而不是有问题的 Thu Mar 21 2002 版本。另外，根据我的经验，这个 patch 也可以用于 2.4.19 内核。
　　
　　 重新编译了内核以后，你可以使用 equalize 关键字了。如果你的 LAN 使用公有 IP 地址，那么恭喜你，你现在可以在双倍速度下用 Realplay 看网络电影了。但是正所谓人生不如意事常八九，如果你使用的是私有 IP 地址配合以NAT上网，让我们来看看当 local host 1 对 remote host 1 发起一次连结时会发生什么。
　　
　　 local host 1 第一次从（192.168.0.1，5000）向 remote host 1 (200.0.0.1, 80) 发起一条连接，现在第一个 IP 包 （SYN 包）已经到达 Linux router。既然是第一次，Cache 中当然没有有关路由信息，Linux router 查找路由表，发现带 equalize 标记的 MultiPath 路由，因此随机决定如何转发此IP 包 -- 好，这次茫茫中命里注定从 if2 走:) 并且雁过留声，在 Cache 中添加一条到 remote host 1 的路由信息-- 既然 local host 1 的 IP 是私有的，NAT 起作用，转换源地址为 (150.0.0.1,7000)后发出，没问题，remote host 1 收到并向 (150.0.0.1,7000) 发回SYN+ACK 包表示接受连结。Linux router if2 收到返回的 SYN+ACK 包，早有准备，NAT 再次转换目的地址为 (192.168.0.1, 5000)。
　　
　　 第一回合。到目前为止一切 OK。
　　
　　 紧接着 local host 1 (192.168.0.1, 5000) 按规矩再向 (200.0.0.1, 80) 发送 ACK 包表示确认。此 ACK 包又来到Linux router 这个岔路口，它将走向何方呢？既然设定了 equalize，Linux 不会根据先前生成的路由表 Cache 中的记录（就是由 SYN 包生成的）来决定走法，相反，它从 Cache 中删除该记录，然后重新查找路由表。这导致又一次重新选择路由，可能是 if1，也可能是 if2。
　　
　　 如果又是 if2，很好，remote host 1 收到，握手完成，连接建立。
　　
　　 若是 if1，又当如何呢？很不幸，if1 将该包源地址经 NAT 转换为 (100.0.0.1,6000)，然后丢上 Internet，一路平安到达 remote host 1。remote host 1 正在苦等从 if2 (也就是 150.0.0.1,7000) 来的 ACK 包，没想却收到一个从(100.0.0.1,6000) 来的 ACK 包，它作何打算呢？难道说，反正是 ACK 包，马马虎虎将就着用用吗？很明显，这不是个好主意。其次，即便意欲如此，remote host 1 如何判断这个 ACK 包和哪一个 SYN 包关联呢？因此，
　　
　　 唯一合理的措施就是：忽略它，当没看见好了。