终端网络技术与长连接演进

如果无法正常显示，请先停止浏览器的去广告插件。

1. 终端网络技术与长连架构演进讲师：若明 & 暁陽

3. 端云交互模式升级 Client Server 1、建连 Client Server 1、建连 2、req req 3、resp resp 4、断连 5、建连 6、req … … 请求响应式短连 … … … 长连接

4. ACCS (Ali-Cloud-Channel-Service)是淘宝无线自研全双工、安全和开放的云通道服务，阿里移动技术三驾马车之一，双11高峰承载近亿级长连接同时在线淘宝APP 业务多样性互动游戏消息聊天直播云派对通知推送购物车订单 …… 衍生技术技术开放性 AGOO 实时推送 DingTalk IM聊天 PowerMsg 厂商辅助通道自研设备ID 多容器及多平台接入订阅扩散实时语音 ARTC HMS Mi PUSH H5 WEEX 轻应用 NextRPC Orange OPPO VIVO Android iOS Windows 多段式返回动态配置长连接技术移动通信技术底座 ACCS 友盟、阿里云移动推送集团APP 智能心跳冲突率0.004% 前后台动态调整消息保序消息重传自研中间件 APP全生命周期运维 XQUIC 自研传输协议可靠消息冗余+推拉+幂等链路追踪日志抓取埋点采集热修复网络库原生网络能力 ADaemon 进程管理 TNET S-SSL ASP 跨进程SP ARanger 面向对象IPC ……

5. 长连接技术通道传输效率&稳定性短轮询自研原生 ACCS 高频请求，服务器压力大长轮询保持连接不断开，收到数据断开 Web Socket SSE 保持连接不断开，可重复收数据，单向 SSE 长轮询 WebSocket 保持连接不断开，可重复收数据，双向，长时在线能力弱短轮询技术优雅性自研原生ACCS 保持连接不断开，可重复收数据，双向，长时在线能力强（智能心跳、低时延、TCP&UDP等）

6. 斗地主业务由WebSocket切换至Native ACCS 95% 83% 游戏开局建连失败数下降 1. 加载游戏淘宝斗地主清零牌局推送失败数用户反馈建连失败舆情下降基本消失 2. 游戏开局 3. 网络抖动 4. 退出游戏 H5 WS 开始建连等待建连，建连率94% 业务手动尝试建连断开长连接 ACCS APP启动已建连直接开局原生网络技术提升稳定性 &自动重连保持长连接结论：端内优先使用原生基础能力

7. ACCS终端三代技术架构 2014 ~ 至今

8. ACCS单体架构(2014年) ——满足业务诉求的初代架构。业务关注多进程多连接主进程(手淘业务) 中间件-动态配置 channel进程不限于传统请求响应模式，能够与用户实时交互中间件-动态配置 SDK API SDK API SDK Service ACCS ACCS 应用内推送静默推送上/下行下行【低感知】核心功能及全量业务仍保留在主进程【全双工】由双连接实现，保留后台低功耗进程接收消息统一接入网关应用集群静默集群 Android架构架构设计【升降级】push进程嵌入动态配置模块控制放量

9. ACCS单体架构(2014年) 代表性业务 ——满足业务诉求的初代架构。多进程多连接主进程(手淘业务) 中间件-动态配置 channel进程中间件-动态配置 SDK API SDK API SDK Service ACCS ACCS 应用内推送静默推送上/下行下行统一接入网关应用集群静默集群 Android架构淘宝消息淘宝直播

10. ACCS连接合并架构(2018年) ——主要是技术升级，增效、降本和解耦。 v1 单体架构（多进程多连接） v2 连接合并（单进程单连接）主进程(手淘业务) 主进程(手淘业务) 中间件-动态配置 channel进程中间件-动态配置 SDK API 中间件-动态配置 SDK API 1. 业务上需要关注2条连接 2. 3. 多连接技术冗余，不贴合原生系统特性复杂且不对等的后端双集群架构 SDK Service ACCS 应用内推送 ACCS 静默推送上/下行下行 ACCS 自研轻量级存储自研轻量级存储自研进程管理自研进程管理 SDK API 接口代理进程安全执行策略统一接入网关应用集群 channel进程 SDK API SDK API SDK Service ACCS 中间件-动态配置业务关注(v1) 静默集群进程安全管理策略合并连接自研IPC-ARanger 上/下行动态心跳统一接入网关静默集群应用集群架构设计(v2) 【绿色低碳】合并连接，每年节省百万服务器费用【架构迁移】孵化面向接口低侵入IPC ARanger 【模块解耦】推进ACCS向进程分离演进【能力沉淀】实现进程安全轻量级存储SDK以及参考Linux Cgroup的进程管理模块

11. ACCS连接服务化架构(2022年) ——支撑业务全天候可用，首次落地终端连接服务化清晰架构。 v2 连接合并（单进程单连接） v3 连接服务化（进程调度单连接）主进程(手淘业务) 主进程(手淘业务) 中间件-动态配置 channel进程中间件-动态配置 SDK API 中间件-动态配置 SDK API SDK API SDK Service ACCS 中间件-动态配置 channel进程 SDK API 1. 低端机进程拉起耗时，导致APP启动建连慢 2. 3. 服务化不彻底，会降级到v1架构，静默无法下架技术开发上，需要关注进程环境 SDK Service ACCS ACCS ACCS 自研轻量级存储自研轻量级存储自研轻量级存储自研轻量级存储自研进程管理自研进程管理自研进程管理自研进程管理接口代理 SDK API SDK API 合并连接自研IPC-ARanger 上/下行动态心跳统一接入网关静默集群业务关注(v2) 应用集群自研IPC-ARanger 接口代理 Sidecar Sidecar Case 1 独立模式轻连接服务静默集群 Case 2 非独立模式连接服务合并连接服务统一网关应用集群订单交易成功

12. ACCS连接服务化架构(2022年) ——支撑业务全天候可用，首次落地终端连接服务化清晰架构。 v2 连接合并（单进程单连接） v3 连接服务化（进程调度单连接）主进程(手淘业务) 主进程(手淘业务) 中间件-动态配置 channel进程中间件-动态配置 SDK API 中间件-动态配置 SDK API SDK API SDK Service ACCS 中间件-动态配置 channel进程 SDK API 1. 低端机进程拉起耗时，导致APP启动建连慢 2. 3. 服务化不彻底，会降级到v1架构，静默无法下架技术开发上，需要关注进程环境 SDK Service ACCS ACCS ACCS 自研轻量级存储自研轻量级存储自研轻量级存储自研轻量级存储自研进程管理自研进程管理自研进程管理自研进程管理接口代理 SDK API SDK API 合并连接自研IPC-ARanger 上/下行动态心跳统一接入网关静默集群业务关注(v2) 应用集群【灵活架构】奠定架构演进方式，连接层解耦自研IPC-ARanger 接口代理 Sidecar Sidecar Case 1 独立模式轻连接服务静默集群架构设计(v3)-引入微服务Sidecar模式 Case 2 非独立模式连接服务合并连接服务统一网关应用集群【低端机体验】新增轻连接服务，轻量级快速建连【架构归一】支撑v1单体架构可彻底下线

13. HTTP(s)/TCP 网络标准协议发展： HTTP2.0/TCP 1980-2010 PC互联网时代 HTTP3.0/QUIC 2018-？ 5G/万物互联时代 2010-2018 移动互联网时代淘宝自研协议XQUIC：主进程(手淘业务) 中间件-动态配置 SDK API channel进程中间件-动态配置 SDK API SDK Service ACCS ACCS 自研轻量级存储自研轻量级存储自研进程管理自研进程管理 IETF QUIC Google Google 开始研究规模化部署工作组成立 GQUIC GQUIC 2013 2015 2016 手淘 XQUIC 经手淘使用开始自研正式使用历双十一 GQUIC XQUIC XQUIC 考验 2017 2018 2020 2021 XQUIC 开源 2022 SDK API 自研IPC-ARanger 接口代理 Sidecar Sidecar 轻连接服务连接服务合并连接服务传输层：自研XQUIC 应用集群统一网关应用集群 RPC 请求耗时降低 15%+ 短视频点播图片/视频上传卡顿率下降速度提升 22%+ 10%+

14. QUIC解决了什么？ APP HTTP TLS OS TCP IP 应用层传输层 APP HTTP2 TLS OS 网络层短连 Pipelining TCP IP 应用层 APP 传输层网络层 OS 长连多路复用 Server Push 应用层协议的问题传输层协议的问题 HTTP3 QUIC/TLS UDP IP 长连/多路复用 Server Push 解决HoL 0RTT建连连接迁移协议扩展性丢包导致其它请求阻塞多个TCP连接单个TCP连接 QUIC连接应用层传输层网络层

15. 图片库播放器 MtopSDK quic策略下发 Network SDK Tnet • XQUIC 端云 AMDC LVS / SLB Tengine Tengine Tengine • Tengine 标准化协议库 XQUIC • 用户态协议栈 • C库/跨平台模块化拥塞控制算法 • Cubic / BBRv1&v2 / Copa / …… 类型特点 Cubic Loss-based 丢包容忍度低，时延高，时延抖动容忍度高 BBR Model-based 丢包容忍好，低时延，速率定期陡变 Copa Delay-based 丢包容忍好，低时延，不存在发送速率陡变，带宽竞争能力相对不如BBR与Cubic 丢包率、RTT、有效带宽等状态感知 • 支撑算法选择 / 决策协议功能模块 ngx_xquic_module XQUIC 关于XQUIC的详细介绍《阿里XQUIC：标准QUIC实现自研之路》 XQUIC开源地址：https://github.com/alibaba/xquic Application Layer Transport Layer 公共模块 H3 Frame封装 QPACK Request管理优先级管理日志管理握手信息交换密钥生成证书校验对称加解密配置参数管理 Frame封装 Stream管理 MTU探测流控基础数据结构 Packet封装连接管理丢包检测拥塞控制内存管理 UDP socket

16. 弱网破障仍然存在挑战提升物理接入链路的质量多路径接入技术无线质量波动、噪声丢包/接入点切换/…… 公网传输段接入侧基站/WiFi 拥塞/故障/…... 隧道技术减少公网传输段问题的影响 IDC内部

17. 弱网破障仍然存在挑战提升物理接入链路的质量多路径接入技术无线质量波动、噪声丢包/接入点切换/…… 公网传输段接入侧基站/WiFi IDC内部

18. QUIC vs Multipath QUIC（MPQUIC） Application Application HTTP/3.0 HTTP/3.0 TLS1.3 Others TLS1.3 QUIC Transport UDP socket Others QUIC Transport + MP Extension Path management Packet Scheduler UDP socket UDP socket WiFi Interface 4G/5G Interface WiFi Interface

19. Multipath QUIC（MPQUIC） Application HTTP/3.0 .html/.css/.js/图片/视频分片/…… HTTP/3 Streams Others TLS1.3 QUIC Streams QUIC Transport + MP Extension Path management Packet Scheduler 连接级别发送队列（包）最小RTT调度（MinRTT）路径级别发送队列（包） UDP socket UDP socket UDP socket UDP socket WiFi Interface 4G/5G Interface WiFi Interface 4G/5G Interface

20. Multipath QUIC（MPQUIC） Application HTTP/3.0 .html/.css/.js/图片/视频分片/…… HTTP/3 Streams Others TLS1.3 QUIC Transport + MP Extension Path management Packet Scheduler QUIC Streams Stream重组不同路径收包 UDP socket UDP socket UDP socket UDP socket WiFi Interface 4G/5G Interface WiFi Interface 4G/5G Interface 更多细节参考我们的IETF标准草案：https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/

21. 关于Multipath的认知误区 “1 + 1 = 2” Head-of-Line Blocking（HOL）无法交付应用层快路径慢路径 1 2 3 4

22. 重注入（Reinjection）如何缓解HoL 交付应用层快路径慢路径问题：冗余流量开销 1 2 3 4

23. 通用HoL优化 • Deadline-aware重注入策略 • 对每一个未确认的数据包 • 按照公式计算重注入deadline • 对于超过deadline的包p ! ，按照MinRTT选择未传输过p ! 且还有空闲发送窗口的路径𝑃 " ，将p ! 进行冗余发送 𝐷 = max(𝑙𝑜𝑤𝑒𝑟𝑏𝑜𝑢𝑛𝑑, min 𝛼 ∗ 𝑚𝑖𝑛𝑅𝑇𝑇, 𝑢𝑝𝑝𝑒𝑟𝑏𝑜𝑢𝑛𝑑 ) 控制冗余数据量 e.g. 大盘请求耗时p50分位自适应网络环境 p99耗时降低比例保障性能 e.g. 大盘请求耗时p90分位冗余数据比例 40.00% 30.00% 20.00% 寻找合适参数：可接受的冗余数据比例+尽量提升性能 10.00% 0.00% (0, 0.01, +∞) X1 X2 X3 X4 …… Xn (0, 1.1, +∞)

24. 短视频体验优化视频传输/卡顿模型网络传输有效带宽不够时引发卡顿/启动慢

25. 短视频体验优化业务诉求：利用多路径增加秒开、减少卡顿，冗余流量尽可能低应用多路径的难点：HoL问题可能导致有效带宽反而下降核心思想：只重注入影响秒开和卡顿的关键数据！三个关键问题 P1. 什么是关键数据？无法及时送达时，会造成卡顿的数据（无法秒开也是某种意义上的“卡顿”） P2. 发送方（视频服务器）如何鉴别关键数据？如果播放器缓存水位过低 P3.发送方如何获取播放器缓存信息？播放器将缓存信息通过API传给 MPQUIC，MPQUIC将信息反馈给发送端

26. 多路径优化方案 - XLINK 播放器通过MPQUIC将缓存水位信息实时反馈给发送方发送方正常情况下，在双路分配不同的数据发送，最大化利用带宽；缓存水位过低时，利用重注入双路冗余发送，避免短时间内由于 HoL问题导致有效带宽下降，引发卡顿

27. 发送方如何判断缓存水位是否过低？按照大盘数据将缓存水位划分为三个区间[0, TH1), [TH1, TH2], (TH2, +∞) CDF P80 调整TH1/TH2来控制重注入比例 🤬 😄 🧐 P10 TH1 区间1: 水位过低，必须重注入 TH2 区间2:根据网络情况判断是否重注入缓存水位区间3：缓存充足，无需重注入剩余可播放时长（T）= 缓存水位/码率当前传输中数据的预计送达时间（D）= max(路径RTT+时延抖动) T<D 新数据到达前，缓存消耗完，需要重注入 T>=D 缓存消耗完之前有新数据到达，无需重注入

28. XLINK如何工作 1. 双路径接入，但是 Path1链路质量波动 2. MPQUIC因为HoL问题，导致播放器缓存数据水位下降，最终卡顿 3. XLINK感知播放器缓存数据水位过低，开启重注入提升缓存水位以2%冗余数据量的代价，p99首帧加载时间优化19%-50%，平均卡顿时长降低23%-67% 更多细节参见论文：XLINK: QoE-driven multi-path QUIC transport in large-scale video services， SIGCOMM 2021

29. XLINK在手淘短视频中的应用效果左边 : 手淘集成 XLINK ，同时使用 Wi-Fi & LTE 右边 : 手淘集成 QUICv1 的版本，只使用 Wi-Fi 当 Wi-Fi 出现带宽波动 , 在右边播放的短视频会出现卡顿 , 与此同时左边能够流畅播放

30. 弱网破障仍然存在挑战公网传输段接入侧基站/WiFi 拥塞/故障/…... 隧道技术减少公网传输段问题的影响 IDC内部

31. 隧道技术 && Why QUIC 公网传输段接入侧 IDC内部基站/WiFi （边缘）隧道接入点企业专线/骨干网边缘点离客户端较近，更快感知无线丢包，进行重传恢复企业专线/骨干网提供更可靠的物理传输保障 SOCKS/HTTP-Connect IPSec/L2TP等VPN方案安全性问题支持协议受限系统级方案需要特殊权限灵活性有限 QUIC Tunnel QUIC安全/性能灵活性强无需特殊权限

32. QUIC Tunnel（IETF-MASQUE-UDP Proxy） https://datatracker.ietf.org/doc/rfc9298/ HTTP3 MASQUE QUIC/TLS UDP IP Stream模式 - 可靠/保序/存在HoL阻塞 Datagram模式 - 非可靠/可乱序/无HoL阻塞两种模式各有优劣

33. Stream模式的问题存在阻塞问题一个丢包导致后续所有应用连接的数据包阻塞在隧道服务器，等待该包重传，即使这些数据包与丢包无依赖关系（不同的stream，ACK等） 1. 应用连接中的请求传输耗时增加 2. 应用连接错误认为出现Burst丢包，影响拥塞算法的带宽估计 3. 应用连接RTT采样造成较大干扰，影响拥塞算法/丢包检测

34. Datagram模式的问题无法快速恢复丢包 >110ms 后应用重传如果Tunnel段重传，丢包恢复时间理论上可以下降到10ms

35. 重传策略管理 𝑅𝑇𝑇1 + 𝑅𝑇𝑇2 𝑟𝑒𝑡𝑥_𝑛𝑢𝑚 = −1 𝑅𝑇𝑇1

36. 更多的QoS（Quality of Service）分级策略？隧道优先级管理、重传策略管理、etc 根据应用的需求，为不同类型的隧道提供差异化的网络QoS保障

37. 扫码回复「D2」获取第十七届 D2 演讲 PDF 材料后续也将推送 D2 会后技术文章，敬请关注！！

38. 感谢大家观看