论文总结：Harp – Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud
之前整理MRC时，MRC依靠NIC、传输层多路径和SRv6，把故障切换做到微秒级；Harp走的是完全不同的一条路：不修改VM协议栈，不要求交换机识别Harp或新增专用转发功能，而是在Host Overlay层预先准备一组可控路径，再利用真实业务流量持续确认这些路径是否健康。故障发生后，Harp不等物理网络完成定位和收敛，而是先把受影响Flow切到另一条已知健康的路径。需要注意，“无需新增功能”不等于与交换机实现无关：Source Port分组的确定性仍依赖现有ECMP流水线满足并经过验证的线性和稳定性条件。
这篇论文真正值得看的，不是“修改UDP Source Port可以改变ECMP路径”这个大家都知道的事实，而是腾讯如何把以下几个并不可靠的能力拼成一个生产系统：
- 如何让一个UDP Source Port尽可能稳定地代表一条物理路径；
- 如何在Host端保存一组候选路径，而不是故障后随机换Hash；
- 如何借用真实VM流量，以很低开销持续维护路径健康状态；
- 如何容忍探测报文丢失、乱序、低流量以及ECMP配置变化；
- 在不改交换机、不改VM协议栈的前提下，快速恢复能做到什么程度，又牺牲了什么；
注：以下是我根据论文、公开资料以及实际报文结构做的理解。论文明确给出的机制会直接引用；协议未公开但可以根据其他信息相互印证的部分会标为推测；论文没有给出答案的地方不会强行补全。理解难免有偏差，若有错漏之处，恳请指正。
论文原文：
结论
Harp可以浓缩成一句话：
在Host端预先计算并保存一组由
NIC + Outer UDP Source Port表示的候选路径，使用采样的VM业务报文持续确认每个Path ID是否可达；故障后，只把受影响Flow切换到另一个已知健康的候选项。
它不是新的路由协议，也不是Transport Protocol，更不会在线发现完整物理拓扑。Harp把工作拆成两个时间尺度：
| 时间尺度 | 负责的事情 |
| 离线、月度 | 根据拓扑和交换机ECMP行为计算UDP Source Port -> rPath，建立Path Pool |
| 在线、数毫秒Cycle | 判断Path Pool中的各个Path ID当前是否可达，失败后立即换候选路径 |
这一区分非常重要：
- 离线工具维持的是“这个Source Port代表哪条物理路径”；
- 在线探测维持的是“这个Path Pool槽位现在是否能到达对端”
根据个人的解读，一旦中间网络Hash结果变化，在线探测仍能判断可达性，但未必还知道它实际经过哪条物理路径。这是Harp最核心的Trade-off，网络上可以通过一些方法减少trade-off的影响，具体看下面：“动态ECMP是Harp最重要的Trade-off” 章节；
Harp的五块重要拼图
| 拼图 | 要解决的问题 | Harp的做法 |
| 1.路径控制 | 如何让Host选择不同物理路径 | 改变外层UDP Source Port，并在双NIC之间选择出口 |
| 2.确定性Path Pool | 如何避免故障后随机换一个Source Port仍撞上原故障 | 离线计算每层ECMP结果的Source Port交集，为不同rPath选择代表端口 |
| 3.在线路径检查 | 如何知道哪条候选路径当前健康 | 每个Cycle在采样VM报文中插入Inspection，反向返回Path Bitmap |
| 4.快速切换 | 如何在路由收敛前恢复业务 | Path失败后，下一个出向报文改用另一健康Path ID |
| 5.过期容忍 | 动态路由改变ECMP后怎么办 | 在线探测继续判断当前可达性，Offline Tool周期性重算映射 |
下面会逐一展开。
拼图一：用UDP Source Port控制物理路径
Harp所在的位置
腾讯原有VPC Host上已经部署：
- VPC Agent：从集中式SDN Controller取得路由和ACL配置；
- 软件Virtual Switch：转发VM流量并完成VXLAN-GPE封装；
- NSH：携带VPC ID，实现租户隔离；
Harp作为动态库运行在Host基础设施层，与Virtual Switch协同工作。它看到VM原始报文，也能控制外层封装，因此对VM和应用透明。原有报文大致是：
Outer Ethernet / IPv4 / UDP / VXLAN-GPE / NSH / VM Packet启用Harp探测信息后变成：
Outer Ethernet / IPv4 / UDP / VXLAN-GPE / NSH / NSH-Harp / VM Packet腾讯DCN中，同一Host Pair的外层五元组基本固定，Harp主要改变Outer UDP Source Port。交换机仍执行普通ECMP，不需要理解Harp Header。改变Source Port会改变每一层交换机的Hash结果，最终得到另一条物理路径。Host的两块NIC分别连接到两台Leaf，Harp还会在NIC之间Round-Robin，使第一跳Leaf也成为路径选择的一部分。
UDP Source Port本身不等于物理路径
Source Port只是输入值。真正路径由以下因素共同决定：
- 外层Source/Destination IP；
- UDP Source/Destination Port；
- 每层交换机参与Hash的字段；
- Hash算法和Seed；
- ECMP宽度；
- ECMP Member/Bucket顺序；
- 每个Member实际指向的下一跳；
- Host NIC连接到哪台Leaf；
- 路由和物理拓扑；
因此，Harp不是直接告诉交换机“走端口3”，而是离线找到一个输入Source Port，使各层交换机按照既有Hash逻辑自然选中预期下一跳。
拼图二：离线建立Path Pool
从单跳ECMP结果到端到端路径
在第(i)个ECMP决策点，Harp把Source Port按Hash结果分组：
其中：
- (Ps)是候选UDP Source Port；
- (k)是该交换机的ECMP结果/下一跳编号；
- (hdr_0)表示其余固定的外层Header字段；
如果一条端到端路径要在多个ECMP点分别选中，那么能代表这条路径的Source Port集合是：
例如如下场景，1000和1004属于同一个rPath集合：
| Source Port | L0 的 ECMP Member | L1 的 ECMP Member | 形成的结果向量 |
| 1000 | 0 | 2 | (0,2) |
| 1001 | 1 | 2 | (1,2) |
| 1002 | 0 | 3 | (0,3) |
| 1003 | 1 | 3 | (1,3) |
| 1004 | 0 | 2 | (0,2) |
从这个交集中选择一个Source Port，理论上就能让报文在各层都得到预期的ECMP结果。这里也回答了一个容易产生误解的问题：Harp并不只计算Host到第一层Leaf之间的ECMP。论文Equation 2明确对路径上从第1跳到第(M-1)跳的交换机结果求交集。只是在论文所用拓扑中，部分跳对给定目的端没有独立ECMP选择，所以一条路径主要由“上行Leaf”和“下行Spine”等少数决策点决定。
但这点我是持怀疑态度的，因为这跟我自己了解的dcn架构是有差别的。如果真实三层网络在Leaf到Spine、Spine到Core等位置都有独立ECMP，那么这些决策都必须进入交集计算。独立ECMP层数越多、设备越异构，交集为空的概率越高，离线计算也越难。若只控制第一层也可以形成一个简化方案，但此时Path ID只代表第一跳路径类别，不能再声称它对应完整的端到端物理路径。
当然为了解决交集为空的问题，也可以减少ECMP的数量，比如传统架构leaf到spine是8个uplink，这里则是4个。
离线工具必须知道什么
为了把Hash结果(k)翻译成真实物理路径，Offline Tool至少需要：
| 信息 | 作用 |
| 每层物理拓扑 | 知道每个下一跳对应哪台交换机/链路 |
| Route与ECMP Group | 确定目的前缀实际引用哪个Group |
| Hash字段、算法、CRC Polynomial和Seed | 复现ASIC的Hash结果 |
| Pre-process/Post-process | 确认字段折叠、Mask、Shift等操作是否保持可预测关系 |
| ECMP宽度、Bucket数量和Modulo方式 | 确定结果空间，并验证是否满足路径线性条件 |
| Bucket-to-Member映射和Member顺序 | 把Hash结果翻译成实际下一跳 |
| NIC到Leaf关系 | 把Host物理出口纳入路径 |
| 每层设备差异 | 对不同Vendor、型号、Seed分别建模 |
论文明确提到同一数据中心、同一层交换机通常具有相同的Hash算法、Seed和交换机数量，因此某一台交换机计算出的(G_{i,k})可以复用于同层其他交换机。这是它能够规模化的关键假设。
但论文没有公开：拓扑和ASIC ECMP结果通过什么接口采集、Member顺序如何获得、不同厂商设备如何归一化。论文还明确承认，一小部分交换机上的Source Port交集可能为空；实现上会把Path Pool按64个端口的倍数扩展，以提高找到可用交集的概率。
rPath究竟复用了什么
这是Harp最关键、也最容易被论文一句“Hash Linearity”带过的部分。这里有三种复用
同一个Host Pair内部
对固定Host Pair，Outer Source/Destination IP等字段不变，只有UDP Source Port可控。论文通过Equation 1把端口分为(G_{i,k})，再通过Equation 2求多层交集。此时：
- 同一个rPath中的Source Port，应当把该Host Pair送到同一条物理路径；
- 不同rPath中的Source Port，应当把该Host Pair送到不同物理路径；
这是Harp确定性最强的范围，因为计算和实际报文使用的是同一组固定Outer Header条件。
跨Host Pair复用
换Host Pair后，Outer Source/Destination IP发生变化，因此即使UDP Source Port相同，绝对Hash结果和实际物理路径也会变化。论文对此有明确说明：同一rPath中的Source Port用于不同Host Pair时，可能把它们送到不同物理路径，因为IP地址不同。因此，Harp跨Host Pair复用的不是：Source Port 1000永远对应某个固定Member或固定物理路径；而是试图复用：哪些Source Port彼此属于同一ECMP结果组，哪些Source Port分组彼此代表不同的路径选择。
但这个“分组关系换了Hash Key仍不被拆散”并非普通ECMP的普遍性质。它依赖Harp引用的ECMP/Path Linearity：当其他Header字段改变时，最终ECMP结果必须对所有候选Source Port施加一致的结果置换。只有这样，原来同组的端口换Host Pair后才仍然同组，不同组也不会合并。例如，在参考Host Pair下：
SP1000、SP1004 -> Member 0 SP1001、SP1005 -> Member 1
换了Host Pair后，允许整体变成：
SP1000、SP1004 -> Member 2 SP1001、SP1005 -> Member 3
但不能变成：
SP1000 -> Member 2 SP1004 -> Member 3
后者会拆散原分组，使复用失效。仅仅知道交换机使用CRC并不足以排除这种情况，因为CRC只是ECMP处理流水线中的Hash环节，后面的Modulo、Bucket和Member映射也会影响最终结果。Harp正文没有重新证明这套线性关系，而是在§3.2直接引用RePaC的研究结果 [59]，再说明已经在腾讯数据中心交换机上进行验证。后面有时间需要深入研究下repac，在阿里的hpn7.0中，也提到了repac。
对Harp复用能力最准确的评价是：
Harp不需要交换机识别新协议，但需要运营者充分掌握、统一并实测现有ECMP行为。跨Host Pair和跨交换机复用是经过特定生产网络验证后的工程优化，不是CRC/ECMP网络天然提供的通用保证。
Path Pool和Offset Table
Path Pool保存候选路径，每个槽位用以下二元组表示：
(NIC Interface, Outer UDP Source Port)论文示例使用64个Path Table槽位，相邻槽位在两块NIC之间Round-Robin。Flow Mapping用VM内层五元组把Flow分布到这些候选项上。这里的“64个槽位”不等于64条不同物理路径。在上面的图中，从一台起始Leaf出发只有8个rPath；同一个rPath集合可以选择更多Source Port填充Path Table。再配合两块NIC/两台起始Leaf，示例覆盖16条物理路径。因此需要区分：
- rPath：一组会得到相同逐跳ECMP结果的Source Port集合；
- Path Pool/PT槽位：实际选入Host表中的
NIC + Source Port候选项； - Physical Path：报文在当前网络配置下真正经过的设备和链路；
在ECMP配置稳定时，同一Host Pair使用同一rPath中的端口会走相同物理路径，不同rPath会走不同物理路径；配置变化后，这个关系可能失效。Offset Table只是故障后跳过不可用槽位的一种实现：当前Path失败就选择后续健康候选项，恢复后重新启用。理解Harp时没有必要陷入Offset加一、冲突和回绕的细节，因为核心是：
Host维护一组预计算候选路径，故障后只把受影响Flow切换到另一个健康候选项
注：论文没有给出多重故障下完整的跳过、冲突和回绕算法。
拼图三：带内探测
离线Path Pool只说明“Source Port预期走哪条路径”，不能说明路径现在是否健康。Harp的Failure Detection Module在两个Host之间维护一个双向探测闭环。
Cycle是什么
可以把Cycle理解为Harp的一轮“路径检查”：每隔数毫秒，当前正在使用的每条路径最多选择一个VM业务报文携带Inspection；目的Host汇总最近若干轮收到的Path ID，再通过反向报文返回Bitmap。连续多轮没有被点名成功的路径才会被判定失败。
| 机制 | 简单理解 | 论文给出的时间 |
| Cycle (C) | 一轮路径检查周期 | 数毫秒量级，且应大于RTT |
| Active Path Inspection | 每轮为每条正在使用的路径选择一个业务报文 | 每Path每Cycle最多一次 |
| Reply Summary | Destination汇总收到的Path ID并返回Bitmap | 按Cycle产生 |
| 连续确认 (M) | 避免单个Probe丢失或延迟就误判 | 至少连续(M)个Cycle |
| 故障检测窗口 | 多轮持续未收到才判Failed | (M\times C)，目标低于典型200 ms TCP RTO |
| 低利用率路径 | 临时把少量带Probe的VM报文重定向到未使用路径 | 阈值和周期未公开 |
| Failed Path恢复检查 | 对已失败、已无业务的路径发送独立Probe | 分钟级，具体间隔未公开 |
| Offline映射更新 | 重新获取ECMP结果、计算rPath和UDP Port | 月度 |
Inspection携带什么
Inspection至少有如下两个关键字段：
path_id：本次报文使用的Path Table索引；inspection_period：从Source最后一次收到Reply，到发送本次Inspection之间的时间；
Destination收到Inspection后，记录Path ID和接收时间。
低流量是Harp的天然弱点
Harp依赖真实VM流量完成高覆盖探测。高流量Path每个Cycle很容易找到一个报文，但低流量Host Pair可能长时间没有可采样报文：
- 故障发现推迟；
- 未使用Path健康状态未知；
- 切换时可能先撞到另一个未探测故障路径；
- 需要连续切换多次才能恢复；
论文的补偿方法是临时将少量携带Probe的VM报文重定向到未使用Path，并限制数量以减少乱序。但它没有公开利用率阈值、选包算法和周期。
NSH-Harp报文格式
论文只给出逻辑结构，没有公开完整Wire Format和Wireshark Dissector。按照理解可以把报文归纳成三类；其中字段语义来自论文，具体TLV编码属于结合报文结构的推测。
| 报文类型 | VM业务数据 | NSH/Metadata特征 | 作用和时间 |
| 普通VM业务报文 | 有 | 只有NSH，无Harp Probe | 未被采样的正常业务报文 |
| 带内采样业务报文 | 有 | NSH 携带28B 的harp probe | Active Path每Cycle最多一个，承载Inspection及反向Reply |
| 独立探测/应答报文 | 无 | NSH 携带28B 的harp probe | 与论文所述Failed Path分钟级Out-of-band恢复探测一致；独立Inspection/Reply的精确格式未公开 |
NSH-Harp 为什么需要28字节
28字节等于224 bit，它承载的不只是一个Path ID。根据论文可以确认或推测其中需要容纳：
- NSH-Harp Base信息；
path_id；inspection_period；- Reply Active Path Bitmap；
- Reply覆盖的时间范围；
- NIC Packet Loss Count；
- 校验、长度和对齐信息
仅64条Path的Bitmap就需要8字节。28字节换来的是一次正向路径确认和一批反向路径确认，避免每条Inspection单独发送ACK。论文没有公开逐字节字段布局，因此无法确认每个字段的精确宽度。
拼图四：故障切换
Source收到Reply后，如果某个使用中的Path在连续观察窗口内都没有出现在Active Bitmap中，就将其标记为Failed。使用该Path的Flow在下一个出向报文切换到另一健康Path Pool槽位。它有两个直接收益：
- 切换目标来自已监控的Path Pool，比随机修改Source Port更可能一次成功；
- 只切换故障Path上的Flow，减少健康Flow被打乱和TCP乱序；
但“只影响故障Path上的Flow”成立有一个隐藏前提：底层ECMP映射在这段时间基本稳定。动态路由改变ECMP Group以后，这个保证会变弱。
拼图五：动态ECMP和Trade-off
Path Pool过期以后，在线探测还能做什么
假设Path Pool原有10个条目：
Path ID 0: SP100 -> Physical Path A
Path ID 1: SP101 -> Physical Path B
...
Path ID 9: SP109 -> Physical Path J中间交换机Hash Seed、Member顺序、ECMP宽度或Topology变化后，可能变成：
Path ID 0: SP100 -> Physical Path D
Path ID 1: SP101 -> Physical Path D
Path ID 2: SP102 -> Physical Path F
...这些Source Port不一定不能转发，真正失效的是“Path ID对应原物理路径”的身份。在线Inspection继续携带Path ID。Destination只知道Path ID 0的报文到达了，并不知道它实际经过Physical Path D。因此在线探测能够重新学习：当前这个Path Pool槽位能不能到达对端。它不能重新学习：
- 当前实际经过哪些交换机和链路；
- 不同Path ID是否已经收敛到同一条物理路径；
- 新路径是否仍与原故障路径共享组件；
- 候选路径是否仍属于不同故障域；
如果10个条目变化后仍有几个可达，Harp可以在它们之间尝试并恢复业务；如果10个条目都收敛到同一条健康路径，Harp会把它们全部标成Healthy，却无法发现路径多样性已经消失；如果全部不可达，在线机制无法生成新的Source Port，只能等待底层恢复或Offline Tool重算。所以：在线探测维护可达性，离线计算维护确定性和路径独立性。
论文如何面对这个问题
论文§5.2明确说明：BGP会因维护、链路或设备故障更新ECMP Group，导致使用中的UDP Port失效。腾讯采取两项措施：
- 固定ECMP配置，避免交换机重启后Hash结果变化；论文明确举出Hash算法和Seed；
- 部署Offline Tool周期性获取ECMP结果，发现变化后重算rPath并更新Path Pool；
但Offline Tool不是每次故障后实时运行，而是月度更新。作者的依据是全数据中心每日故障链路比例低于0.0002%，且故障设备通常会快速修复，使过期UDP Port重新恢复有效。这等于接受一个短暂窗口：Path Pool还能凭在线探测找到可达候选项，但不再严格保证这些候选项代表原来的物理路径。
Ordered ECMP只能解决一半问题
Ordered ECMP配合固定Hash Seed、算法和Member顺序，可以让交换机重启后同一五元组仍命中相同Member。但Link Down后，如果ECMP从4个Member缩为3个，普通ECMP可能重新映射大量健康Flow。这不仅使Path Pool大范围过期，也破坏“只有故障路径上的Flow变化”的目标。论文没有说明Member安装顺序如何保持，也没有提到Resilient Hash。
Resilient Hash能显著改善，但不能彻底解决
Resilient Hash通过稳定Bucket Table，只重新分配原来属于故障Member的Bucket，这样：
- 未经过故障Member的大多数Source Port仍对应原rPath；
- 只有受影响Bucket的路径身份改变；
- Harp仍可以信任大部分Path Pool；
- Offline Tool只需最终修复少量过期映射；
但它要求保持同一个逻辑ECMP域及Bucket状态。若NOS在Link Flap时删除整个Group并按普通ECMP重新创建，ASIC内部Flowset也随之消失，单纯打开硬件Resilient Hash并不够。即使SAI Object ID改变，只要NOS保存并恢复原Bucket映射，也可以保持稳定。
SONiC社区的Fine-Grained ECMP提供了一种更可控的实现：固定较大的Bucket表，由FgNhgOrch在Next Hop Down时只改受影响Bucket，并为Warm Boot保存Bucket -> Next Hop映射。相关设计可参考：
不过它并非默认对所有动态BGP Route开启，且消耗更大的ECMP Member/Bucket资源。如果普通RouteOrch删除Group，就必须由NOS显式恢复Bucket映射。Harp论文没有说明腾讯是否使用Resilient ECMP。它不依赖RH很可能与以下工程现实有关，但这些属于合理推断，不是论文结论：
- Legacy和多厂商设备无法统一提供相同行为；
- NOS重建Group可能丢失硬件RH状态；
- Gray Failure时Member仍在Group中，RH根本不会触发；
- Harp的目标正是无需修改现有物理网络即可部署；
哪些架构可以复用Harp
不是必须叫VPC，但必须有Host侧封装控制点
论文实现明确依赖腾讯VPC基础设施，但Harp的核心思想不要求业务概念上必须是VPC。真正的必要条件是：
- 通信两端都由同一基础设施控制；
- Host、Hypervisor、DPU或SmartNIC能够插入和解析Probe Metadata；
- 能改变一个被中间交换机用于ECMP的Entropy字段；
- 能把Inner Flow稳定映射到某个候选路径；
- 能获得每层ECMP和拓扑信息，或者通过实测建立路径映射；
- 中间网络在足够长时间内保持Hash行为稳定；
- 路径之间确实存在足够的物理多样性；
如果裸金属L3网络没有Overlay、vSwitch或SmartNIC插入点，就不能直接复用论文实现；需要引入隧道、Host Agent或NIC Firmware能力。论文还指出，Failure Detection机制可以与IPv6 Segment Routing或Flow Label等其他路径控制方式结合，所以UDP Source Port不是唯一可能的执行器。
适用性判断
| 架构/场景 | 适用性 | 原因 |
| 云VPC、VXLAN-GPE/NSH Overlay | 最适合 | 与论文部署环境一致，Host两端可控，已有封装和Metadata通道 |
| Kubernetes/Container Overlay | 可以改造 | 需要在vSwitch/eBPF/DPU层建立Host Pair Path Pool和双向Metadata |
| 普通三层Clos DCN | 有条件可用 | 必须能控制Entropy并获得各层Hash、Member和Topology，还要验证完整ECMP流水线满足分组复用条件；层数越多交集越难 |
| 跨数据中心DCI | 降级可用，但不具备确定性保证 | 论文明确指出Inter-DC不满足ECMP Hash Linearity；可依靠扩大的Path Pool和在线可达性探测进行多次换路，生产案例证明有效但恢复尾部可达秒级 |
| Cloud Gateway流量 | 当前不支持 | 论文明确说明Gateway集群ECMP配置不统一 |
| Internet/WAN | 不适合直接复用 | 无法掌握沿途Hash和拓扑，也无法控制双端基础设施 |
| Gray Failure、Silent Drop | 很适合 | 路由协议和Resilient Hash可能不动作，但端到端报文丢失能被Harp看到 |
| 报文损坏/CRC错误定位 | 不覆盖 | 论文明确不覆盖Packet Corruption |
| AI推理Frontend/服务网络（具有普通VPC/Overlay特征） | 有条件适用 | HTTP/RPC、调度和普通存储访问可能经过Host Overlay/vSwitch，网络形态接近论文中的VPC，具体case by case 确认 |
| AI推理Accelerator Backend | 不适合直接复用 | Decode、PD/KVCache、TP和EP通常使用SR-IOV/RDMA并绕过vSwitch，对线速、乱序和恢复时延的要求接近训练网络 |
| AI训练Backend（RoCE/IB） | 不适合直接复用 | Collective要求线速和微秒级恢复；Packet Spray、ARS和RoCE状态使软件Flow级切换难以适用 |
Harp与MRC的本质区别
两者最本质的不同是：
Harp是“先为Flow准备几条候选路，再用低频检测确认哪条路还能走”；MRC是“一个可靠连接持续把Packet喷洒到大量路径上，NIC根据传输反馈实时淘汰坏路径”。
Harp故意不碰Transport，所以兼容现有VM和任何上层协议，代价是只能做到Flow级切换和毫秒级探测；MRC把多路径、重传、乱序和故障反馈全部纳入Transport，代价是需要新的NIC和协议能力。
另一个关键差异是路径稳定性：Harp依赖中间每层ECMP的隐式Hash结果，动态路由会让离线映射过期；MRC推荐使用静态SRv6，把路径直接编码进地址，正是为了避免ECMP Group变化与微秒级EV切换冲突。
| 维度 | Harp | MRC + SRv6 |
| 目标网络 | 通用Cloud VPC/DCN | 大规模AI训练RDMA Backend |
| 所在层次 | Host Overlay/Virtual Switch | NIC Transport和Firmware |
| 对应用 | 对VM协议透明，可承载TCP/UDP等任意流量 | 提供接近verbs的MRC接口，面向RDMA应用 |
| 选路粒度 | Flow级，一个Flow正常固定在一个Path | Packet级Spraying，一个QP同时使用大量EV |
| 路径标识 | NIC + UDP Source Port对应Path ID | EV对应路径；SRv6方案中EV映射到显式uSID路径 |
| 路径确定性来源 | 预测各层ECMP Hash结果并求Source Port交集 | SRv6显式Source Route，或ECMP EV集合 |
| 故障检测 | 每Path每Cycle采样业务报文，Bitmap Reply | 数据面PSN Gap/SACK/NACK反馈，外加Clustermapper Probe |
| 反应时间 | 数十到数百毫秒为主，尾部可到秒 | NIC内微秒级EV替换 |
| 故障动作 | 将受影响Flow整体切换到另一个Path | 从Active EV Set中移除坏EV，后续Packet继续Spray |
| 可靠性/乱序 | 不修改Transport，尽量只切受影响Flow | Transport本身处理乱序、SACK和Selective Retransmission |
| 对交换机要求 | 不要求识别Harp，但ECMP算法、Seed、Bucket/Member映射和同层一致性必须可掌握并经过验证 | SRv6静态转发；方案还使用Packet Trimming等能力 |
| 对动态路由态度 | 与BGP共存，接受Path Pool短期过期 | 推荐静态SRv6，主动避免路由收敛扰动EV映射 |
| 主要Trade-off | 兼容性强，但路径映射会过期、低流量检测慢 | 恢复快、吞吐高，但依赖新NIC/Transport且应用范围受限 |
生产效果
论文在腾讯生产环境中评估了Harp，覆盖数十万服务器和多种VM工作负载。几个关键结果：
| 指标 | 结果 |
| 相比原物理网络故障处理 | 原方案10～180 s；Harp大部分在亚秒级绕过 |
| 8次广泛影响的Switch故障 | P25不超过65.5 ms，P50不超过97.2 ms，P75不超过206.5 ms |
| P95 | 不超过1.28 s |
| P99 | 0.78～3.54 s |
| 平均恢复时间 | 295 ms |
| VPC Downtime下降 | 78.71%～99.97%，整体约99.9% |
| Host资源开销 | 80K+服务器15天样本中，CPU低于1.2%，内存低于13.5 MB |
这些数据也揭示了它的真实定位：Harp不是稳定的“几十毫秒必恢复”。流量活跃、Path覆盖率高时，大量Flow能一次切换成功；低流量或大面积故障导致许多Path同时不可用时，需要2～4次切换，P99会进入秒级。
最终评价
Harp最有价值的地方，是它没有假设网络已经具备完美的Telemetry、统一的可编程交换机或新Transport。它利用现有VPC Overlay已经拥有的三个控制点：
- Host能修改外层Entropy；
- 双端Host能交换Metadata；
- DCN存在大量ECMP路径；
然后用离线确定性计算和在线健康检查，把“随机换Source Port”提升成“从已知健康候选路径中换一个”。这套设计很适合大规模存量云网络：部署门槛低，对VM透明，能在物理网络定位和BGP收敛之前先恢复业务。
但它并没有消除底层ECMP的不确定性，而是把不确定性分成两个时间尺度处理：在线探测负责当前可达，离线工具负责长期准确。动态ECMP、Member重建、异构设备、低流量以及路径交集为空都会削弱其确定性。Resilient Hash可以显著改善Link Down后的映射稳定性，但论文没有依赖它。
如果要复用Harp，最重要的不是照搬Offset Table或NSH格式，而是确认以下条件：
- 是否掌握每层Hash字段、算法、Seed、Pre/Post-process、Bucket/Member顺序和物理拓扑；
- 是否实际验证换Host Pair后Source Port等价类仍保持，而不是只验证单个参考五元组；
- 同层不同Vendor/型号是否可以共享模板；不能共享时，分别计算后是否仍有足够非空rPath交集；
- 是否有稳定的Host/DPU封装与Metadata插入点；
- 是否能保证双端Agent协同；
- Path Pool在动态路由后如何更新；
- 是否采用Ordered/Fine-Grained/Resilient ECMP减少映射扰动；
- 业务流量是否足够支撑带内探测；
- 数十到数百毫秒恢复是否满足SLA；
- 完整Wire Overhead、MTU和Host处理成本是否可接受。
从架构定位看，Harp是面向通用VPC的Overlay快速避障层，MRC则是面向AI Backend的Transport级多路径可靠传输。前者胜在兼容和部署，后者胜在速度和性能；它们都把故障处理前移到端侧，但解决的是两类不同网络。
版权声明：
本文链接：论文总结：Harp – Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud
版权声明：本文为原创文章，仅代表个人观点，版权归 Frank Zhao 所有，转载时请注明本文出处及文章链接