两条上行链路，一条隧道：故障切换、负载均衡还是链路聚合
故障切换、按流均衡和单流聚合是三种不同的承诺。两条默认路由给你第一种，而不是后两种。
两条互联网线路可以让 VPN 更可用，也可以让某些工作负载更快，但究竟发生哪一种，取决于机制。有两个默认路由的路由器并不是聚合链路，而承载数千条内部连接的隧道仍然只是一条外部流。先给承诺命名，就是设计与昂贵失望之间的区别。下表按每种方案在远端需要什么、以及链路中断对一次传输意味着什么，把选项分开。
三种承诺，只有一种需要合作方
故障切换在首选链路消失时让路径保持可用。按流哈希的均衡把相互独立的流分散到两条上行链路。单流聚合让一次传输同时使用两条链路。它们是需求不同的不同产品，只有最后一种需要路由器之外的某个东西配合。
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
那张表里没有任何一条是购买第二条线路的理由。它做的是防止把故障切换方案当成链路聚合来评估。
为什么隧道在路由器眼里像一条流
做负载均衡的路由器把源地址、目的地址和端口一起做哈希，然后把整条流发往哈希指向的位置。从路由器的角度看，VPN 隧道就是这样的一条流，无论里面跑的是什么。内部连接永远到不了哈希决策，因为外层报头已经决定了路径。这就是为什么第二条上行链路可以让许多用户的总容量翻倍，却对单个用户的大传输毫无改变。
两条独立的隧道可以给你两个候选，但它们仍然需要一套有意的策略来分配流量，并让回包沿着承载请求的那条路径返回。跳过这一步的常见结果是非对称路由。最低限度是策略要写明流、首选链路和备用链路。
以太网链路聚合无法跨越不相关的运营商，因为远端必须参与聚合协议。除非存在愿意配合的端点，跨两家 ISP 的聚合只是研究项目。
多路径 TCP 在两端需要什么
Linux 的 Multipath TCP 文档描述了属于同一条连接的多个子流。只有一端的内核支持本身改变不了什么，因为对端也必须接受这些子流。远端代理是另一种常见做法，它就成了一个需要为其容量和可用性做规划的组件。同样的逻辑排除了 WireGuard 的简单答案，因为它的传输是 UDP：MPTCP 生长的是 TCP 子流，设计里没有别的东西就无法聚合那条隧道。
在围绕内核特性做设计之前，先确认它是否已启用，因为许多发行版默认是关闭的。这三条命令一分钟就能回答。
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show按工作负载选，而不是按宣传册选
如果工作负载是大量独立会话，按流哈希的均衡可以在远端不配合的情况下增加容量。如果是一次大传输，只有聚合方案才有帮助，而那种方案需要愿意配合的对端。如果要求是链路死掉时工作继续，答案就是故障切换，单次传输的吞吐量无关紧要。
用一个带动词的句子写下需求：一次备份快一倍完成，或者断掉的链路不会终止会话。含糊的目标会产生谁也无法接受或否定的方案。然后决定远端允许是什么，因为最便宜的选项往往是在那里不需要任何新东西的那一个。这条约束在第一次会议之前就能删掉宣传册上的大部分说法。
在需求文档里把三种承诺分开写。声称三者兼得的方案通常只交付一种，并默默假设其余两种。下一节检验真正交付的是哪一种。
测一次传输和多次传输，然后拔掉一条链路
把一次持续传输与到同一目的地的多条并行传输做比较，并记录每次的丢包、时延和每条链路的利用率。只有在并行会话下才有收益，说明的是流分散，而不是单流聚合。单独测试一条上行链路中断，因为两条链路都工作时的容量，对已建立会话的故障切换毫无说明。每次测试前后都记录路由、套接字和重传计数。
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5当单次传输仍然只走一条上行链路时，方案做的正是流哈希所暗示的事。当并行传输分散到两条链路上时，均衡有效而聚合无效。记录方案真正守住了三种承诺中的哪一种，下一次关于容量的讨论就会从证据开始，而不是从厂商的说法开始。