鸿蒙Network Kit实战：MPTCP弱网切换与DNS优选

鸿蒙专家

问题场景：电梯口与高铁上的断网重连
用户在家里连着 WiFi 开视频会议，出门进电梯后 WiFi 衰减直至断开，手机切到蜂窝数据。传统 TCP 连接因源 IP 改变而断开，视频卡死，需应用层重新三次握手，恢复过程短则两三秒，长则十几秒。高铁在线对战游戏在基站间高速穿梭，4G/5G 频繁重选，隧道中信号短暂清零，只靠应用层断线重连会频繁出现重新连接中，体验很差。过去开发者监听系统网络广播、维护重连队列、引入 QUIC，但应用层无法调度底层网卡物理资源，也无法做到 TCP 级无缝迁移，方案往往治标不治本，频繁探测还会耗电。

HarmonyOS 7.0 Network Kit 的关键升级
HarmonyOS 7.0（API 26）中系统底层网络架构升级。Network Kit 提供全链路网络状态感知 netConnection，开放基于 MPTCP（Multipath TCP，多路径 TCP，RFC 8684）的应用级多网卡并发访问能力，以及 DNS 优选策略。应用不再被动接受网络断开通知，而是可以主动感知 WiFi 和蜂窝网络质量变化，在底层实现双网协同并发与无缝切换。

用 netConnection 做全链路状态感知与弱网预警
@kit.NetworkKit 的 connection 模块增强了精细化感知能力。传统监听通常只有已连接或未连接，企业级应用需要知道当前是 WiFi 还是蜂窝、信号强度、RTT、底层可用带宽，才能做路由决策。工程中可封装 NetConnectionManager 单例，在 EntryAbility 生命周期初始化，集中处理网络监听。

核心做法是用 connection.createNetConnection() 创建默认网络连接监听对象，再注册事件。netAvailable 在网络从无到有或切换到新可用网络时触发，可读取 netHandle.netId，用于恢复暂停的下载任务或重新发起长连接。netCapabilitiesChange 在网络类型变化、带宽或延迟显著变化时触发，可解析 bearerTypes，读取 linkUpBandwidthKbps 和 linkDownBandwidthKbps，判断当前承载是 Wi-Fi、蜂窝还是以太网。

netBlockStatusChange 是 7.0 的重要特性，用于弱网预警。它在网络物理断开前提前感知严重拥塞或链路受阻，data.blocked 为 true 时可触发视频流自动降级，例如把 1080P 切到 480P。netLost 表示网络彻底断开，应展示无网络提示 UI，并暂停后台静默任务。注册完回调后必须调用 register，底层事件才会真正生效；页面销毁或应用退出时调用 unregister，释放系统底层句柄资源，并处理 BusinessError 的错误码与描述。

MPTCP 如何解决切网断连
标准 TCP 连接由四元组标识：源 IP、源端口、目标 IP、目标端口。手机从 WiFi 切到 5G 时，源 IP 改变，原四元组不存在，服务器会丢弃来自新 IP 的报文或返回 RST 重置连接，应用层只能新建 Socket。MPTCP 允许在同一个 TCP 连接内部建立多个并行底层物理子流，手机可同时利用 WiFi 网卡和蜂窝网卡与服务器建立连接。当其中一条路径断开，数据无缝转移到另一条路径，应用层无感，四元组改变被 MPTCP 协议栈屏蔽。

其底层流转时序可概括为：主路径建立时，应用发起连接，MPTCP 使用默认网络如 WiFi 建立初始 TCP，并在握手包中携带 MP_CAPABLE 选项；副路径探索时，系统检测到蜂窝网络可用，自动发起第二条子流，携带 MP_JOIN 选项加入原连接；动态调度时，WiFi 信号好则流量优先走 WiFi，检测到丢包或延迟激增时，MPTCP 调度器在底层把数据包分发到蜂窝子流；无缝切换时，WiFi 彻底断开，但蜂窝子流早已建立并就绪，数据传输不受影响，应用层下载进度条继续前进。

双网并发与耗电、流量的博弈
多网卡并发带来稳定性，也带来耗电剧增和用户流量消耗。若一直让 WiFi 和蜂窝双开满负荷运转，射频芯片耗电翻倍，还可能消耗大量 5G 计费流量，企业级应用不可接受。Network Kit 提供精细化策略控制枚举。rcp.MultipathPolicy.HANDOVER 是平滑切换策略，只有当主网络如 WiFi 变差时才平滑过渡到蜂窝，兼顾耗电和稳定性。rcp.MultipathPolicy.INTERACTIVE 追求极致延迟，会在 WiFi 和蜂窝上同时发送一模一样的数据包，只让最快链路到达。

因此 INTERACTIVE 不能全局使用。它只适合极其核心且数据量极小的场景，例如电竞类游戏对局内、抢红包界面瞬间、高频低数据量金融交易按钮。图文浏览、文件上传下载、视频点播等绝大多数场景必须使用 HANDOVER。封装基础库时，可把 HANDOVER 设为默认底层策略，只有传入特定高级权限令牌才解锁其他模式。

用 rcp 封装智能路由 HTTP 客户端
HarmonyOS 中标准 HTTP 客户端默认不开启 MPTCP，需要通过 @kit.RemoteCommunicationKit 的 rcp 模块接管连接配置。可封装 MultipathHttpClient，在 SessionConfiguration 中配置三部分：connectionConfiguration.dns.dnsRules 接管域名解析；requestConfiguration.transfer.timeout 设置 connectMs 和 transferMs，例如 15000 毫秒，避免死等；multipathConfiguration 中设置 multipathServiceEnabled 为 true，并选择 multipathPolicy。示例选择 rcp.MultipathPolicy.HANDOVER，以兼顾耗电和稳定性。

配置完成后用 rcp.createSession(sessionConfig) 创建 Session。发起请求时调用 Session.get，底层自动处理 MPTCP 多网协同、证书校验、DNS 优选。请求完成后检查 statusCode 和 body，异常时记录 BusinessError 的 code 与 message。最后调用 Session.close 释放底层物理连接资源。这样应用层的请求接口不变，但传输层具备了多路径切换能力。

DNS 优选与防劫持
企业应用中常遇到 LocalDNS 被恶意劫持，把域名解析到无效 IP，或跨网解析导致高延迟，例如联通用户解析到电信服务器。HarmonyOS 7.0 允许在 rcp.Session 级别通过 dnsRules 接管解析流程。企业级做法是：App 启动时异步请求服务端 HttpDNS 接口，拉取核心域名对应的优质 IP 列表；将 IP 缓存在内存；业务发起请求时，customDnsResolver 直接从内存返回 IP，跳过系统默认 DNS 查询。这样既防范非法篡改 DNS 记录，也把 DNS 解析耗时从几百毫秒缩短到 0 毫秒。

可以封装 DnsOptimizer，用内存 Map 维护 dnsCache，通过 resolveIpByHost 返回 IP 列表。当 customDnsResolver 收到域名和端口后，调用 DnsOptimizer 获取最优 IP，命中则返回地址列表，未命中则返回空对象，让底层回退到系统原生 DNS，异常时也要降级默认解析。

避坑指南：弱网与多网协同的暗礁
第一，服务端不支持 MPTCP 导致连接退化。客户端即使开启 multipathServiceEnabled，抓包可能仍只有一条 TCP 链路，电梯口依然断网重连。原因是 MPTCP 需要客户端和服务器双方在内核层面支持。如果服务器部署在旧版本 Linux 内核，或经过不支持 MPTCP 选项的四层负载均衡器，握手包中的 MP_CAPABLE 会被丢弃或抹除，底层握手失败后静默退化为普通单路径 TCP。解法是确保接入层网关支持 MPTCP，例如 Nginx 升级到支持 MPTCP 的版本且内核版本不低于 Linux 5.6，或使用专门的 MPTCP 代理内核；联调时用 Wireshark 抓包，确认 SYN 携带 Multipath Capable 且 SYN-ACK 也携带该选项。

第二，INTERACTIVE 模式带来发烫客诉。全局启用后，用户反馈手机发烫、流量消耗离谱。原因是该模式在 WiFi 和蜂窝同时发送相同数据包。解法是严格限制使用场景，绝大多数场景强制 HANDOVER。

第三，DNS 优选配置的泛化灾难。拦截所有 dnsRules 进行接管后，内嵌 Web 页面加载第三方图片域、CDN 域或追踪域时可能大面积崩溃或访问极慢。原因是 customDnsResolver 接管了 Session 全局解析，本地 DNS 策略库没有第三方域名映射，且 fallback 回退逻辑耗时过长甚至抛错，阻塞了正常 LocalDNS 解析。解法是白名单制，绝不可全量接管。拦截解析请求时先精确匹配 host 是否属于核心业务域名清单；不属于就立即降级，让系统原生逻辑接管第三方域名查询。

总结
HarmonyOS 7.0 的 Network Kit 把应用层网络架构从被动响应推向主动规划、底层协同。netConnection 提供多维状态与质量感知；接管 rcp.Session 并开启 MPTCP 后，流量可在 WiFi 与蜂窝之间无缝转移；通过 dnsRules 注入，域名解析的安全与性能可由应用掌握。落地时能应对电梯口断连、高铁弱网、DNS 劫持等场景，但调度双网卡时必须克制电量、流量与发热，在传输可靠性和系统资源消耗之间找到平衡。