在文中，京东余珽介绍了京东移动网络优化方面的实践和收益，开发者可以通过阅读本文了解HTTP2.0、HTTPDNS、图片压缩聚合等传统的移动网络优化手段并应用到业务中。同时本文也详细讲解了在国家推行IPv6的情况下获得IPv6/IPv4双栈网络下的经验和踩坑经历，以及如何构建立体化的异常监控、性能监控体系来提升移动互联网络优化，带来更好的用户体验和业务可用性。
一
移动网络优化思路
从上世纪80年代诞生第一代移动通讯系统，到今年5G开始商用，带宽不断增大，展示的数据愈加丰富。时延不断降低，游戏、直播都能Hold住。移动网络朝着带宽、时延、安全性的方向发展。从下面的截图看出，随之而来的是飞速增长的移动网络用户，安卓和iPhone端来自移动网络用户的占比已达到45%左右，并且还在不断增长中。从单量上来说，App端的用户占比占到了绝大多数，因此针对App端用户，要根据其特点采取有别于PC端的优化措施。
总体而言，优化思路是集中在速度、安全、稳定性、监控4个方面，结合完善的监控系统，进行持续优化。速度是针对之前发现的一些瓶颈点，通过协议升级的方式来解决和提升，或是针对图片和文本的数据进行压缩，减少传输的数据量，提高加载速度。稳定性是针对发现长连接异常还有异常情况下的多重降级，包括IPv6及IPv4双栈自动切换等问题进行改善。安全是通过全站HTTPS，自建HTTPDNS以及配置VIP的方式去提升。监控是通过客户端、服务端的监控埋点及时发现线上问题，对优化措施进行有效的监测和持续的反馈。
二
移动网络优化实践
1.自建HTTPDNS服务
从最基础的LocalDNS服务说起，LocalDNS常见的问题有解析劫持、配置错误问题、缓存过长。基于以上问题，自建HTTPDNS，HTTPDNS有如下优势：
- 全面覆盖：Android和iOS客户端的原生网络及图片请求都已接入，避免了解析劫持，也提高了解析成功率。
- 快速生效：服务端TTL灵活配置，域名切换生效时间从之前平均10-15分钟减小到目前的5分钟，避免LocalDNS缓存时间过长，影响故障切换的问题。
- 异步拉取：不阻塞App网络主进程，拉取到HTTPDNS结果之后在启用相应的解析结果。
- 精细化调控：可以针对用户的具体设备进行调度，方便用户反馈时的快速排障，对小运营商跨网导致的连接异常问题也能有效解决。
2.多重降级，预热及定时更新
采用的策略是多重降级，预热及定时更新。先使用HTTPDNS自身服务，我们使用的是多线的BGP，保证各个运营商都有较好的流动性，可以降级到正常的LocalDNS。在最后会有一组内置的长期稳定的多个运营商的VIP，这个功能发挥了重要作用。
3.HTTP2.0-安全与速度的平衡
HTTP下各类劫持攻击层出不穷，下图是2016年用户反馈的核心收银台页面遇到劫持的情况，此情况既损失金钱又影响商誉，HTTPDNS是大势所趋，为了提升HTTP的性能，升级到2.0也是顺势而为的操作。
4.HTTP2.0-客户端及服务端改造
2016年8月开始，京东针对客户端和服务端都做了升级以适配HTTPDNS，2017年至今历经多次大促考验。需要注意以下3点：
- 域名收敛：网关域名、图片域名都收敛到1个域名，充分发挥H2的优势。
- 多域名情况：尽量保证多个域名解析到相同IP，并且使用相同的证书，方便客户端复用相同的连接。
- HTTPDNS适配：IP直连时证书校验要做适配，取出域名字段与原先请求的Host做比对，不能直接信任所有证书。
5.TLS session resumption
session cache主要是IOS端在使用，它实际上是属于标准协议，技术原理是把加密的绘画信息存在了服务端，然后通过集群，给负载均衡的各个节点都能做共享，客户端不管访问到哪一个节点都能够复用到原先的绘画信息，但是对内存的消耗会比较大一些。session ticket是属于扩展协议，现在主要是安卓端支持，把加密的绘画信息存在了客户端，但是加解密所用到的Key信息也是存储在服务端。Key信息24小时要轮换一次，这样才能够保证安全性。
6.HTTP2.0-ping帧优化
在实践中遇到的坑：DPDK和NGINX的空闲超时时间不一致导致连接异常。客户端在连接不可用以及长时间空闲时主动关闭连接，避免卡顿也减少服务端维持长连接的开销。用了HTTP2.0之后，各端各个模块性能的整体提升在15%到30%左右，还是比较理想的。
7.图片优化-WebP和DPG
图片和文本的压缩，也是提升速度的重要因素。现在DPG格式，是基于H.265原理的兼容JPEG格式，压缩比高，渲染快，兼容好。针对移动端下发这个图片，做了统一分辨率和统一降质量参数的操作，通过屏幕的尺寸划分为720、1080和1080以上这3档。根据WIFI，4G，弱网下发不同的降质参数，权衡加载速度与图片体积。优化之后，CDN缓存命中率，整体提升了10%左右，图片体积减少约25%，加载速度提升约27%。
8.Gzip与Brotli压缩
文本这一块用的是Gzip，目前大部分用的是Brotli压缩。相同情况下，Br压缩率更高，CPU占用更少，但是TP99会略微增高。Br选择中低等压缩级别取得压缩率、CPU消耗和处理时间的平衡，高压缩级别得不偿失。如图所示：
9.IPv6网络-Happy Eyeballs
2017年底，中共中央办公厅和国务院办公厅发文之后，Ipv6全面开始推广。京东App完成改造，IPv6流量占比26%左右。“HappyEyeballs”算法用于优化ipv4与ipv6双栈下的网络连接，避免IPv6或IPv4故障时带来的等待和延迟。实现上的差别是：
- Chrome/firefox实现上IP6优先250-300ms左右，然后再尝试IPv4连接
- Apple的实现则是同时发起IPv6和IPv4连接，哪个更快就用哪个
- 京东Android端OKHTTP和两端HTTPDNS都实现了类似功能，IPv6优先250ms
10.网络-地址库问题
IPv6地址库不如IPv4完善，表现在流量调度问题、安全和风控判断、个性化推荐业务。启用移动、联通、电信和教育网IPv6 BGP vip来缓解动态接口的流量调度问题，但是CDN节点的压力仍然比较大。利用IPv6/IPv4双栈上报的地址，以IPv4地址信息反推IPv6地址，但是IPv6地址本身空间巨大，并且启用隐私地址后更加多变。
另外还有一个关键点是通信行业的行业标准规范——《YD/T 2682-2014 IPv6接入地址编址编码技术要求》。CC 是区/县编码，长度为 8 位。文件附录里，明确了全国各省份各区县的具体8位编码。
现在基本确认联通和移动大部分省份都是在前缀的33-40bit位置对应区县编码，目前发现上海联通和广东联通还不符合这个规则；从工信部渠道了解，今年底各运营商应该都会完成改造。根据上报数据，LTE移动网络还是跟IPv4时代类似，源IPv6地址基本是从省会城市或者几个核心城市，还没有对应到区县。
11.IPv6网络-MTU问题
IPV6和IPV4不一样，IPv6仅发送端可分片， Path MTU协议是通过ICMPv6的Packet Too Big报文来完成的，根据响应动态调节MTU直到发送成功。
根据用户反馈及埋点数据显示，三大运营商固网环境都有类似超时问题，LTE环境由于运营商调小了TCP MSS值所以都正常。
1)从服务端ping用户固网地址，确实有发现移动运营商链路上有MTU小于正常1492字节的现象。
2)正常通过PMTU discovery 可以解决。
3)怀疑还是ICMPv6的Packet Too Big报文被过滤导致，手动调小服务端MTU值到1440字节来解决。
12.IPv6网络-DNS缓存
5月份做过IPv6降级演练，发现从权威DNS上去除AAAA记录后，三大运营商部分省份还是有IPv6的流量，并且持续了半个月左右。运营商DNS服务每个省份一般都外包出去，针对AAAA记录解析不存在的情况会有托底，返回之前缓存的AAAA记录，从而带来非预期的IPv6流量。今年双11之前，我们又做了一次降级演练，又发现针对调度域名 api.m.jd.com.gslb.qianxun.com还会有缓存的情况。我们之后又发现iOS端不完全遵从递归查询，针对api.m.jd.com的CNAME域名还会发起一次AAAA记录请求，安卓端没有类似问题。
三
立体化监控体系
下图是立体化监控全景图，监控数据涵盖业务监控、用户端监控，基础监控、服务端监控，把数据整合到APM平台与THOR平台，建设这样一个平台，方便运维、测试、运营、QA团队去订阅数据和接收告警，实现了全流程从前到后的立体化监控体系。
以实际应用场景举例，在客户端做图片加载异常埋点，按照省份运营商做拆分，把曲线画出来，结合CDN节点流量监控及时发现用户无法打开图片异常。网络异常时，曲线出现明显波动，异常曲线上涨，流量曲线下降，最后定位到是网络问题，需要进行对应的流量调度。另外，日常工作通过客户端埋点上报还能发现SSL证书配置异常、VIP被某省份运营商封禁等影响用户体验的问题。
针对全网的网络质量监控，由于京东的用户众多，传统监测不太符合需求。经过考虑后，在业务请求日志中收集用户的网络地址，从京东机房内部，多机房出口、多并发的反向ping，筛选出一批能ping通的，并且长期稳定的IP作为对应省份运营商的监测点。每个省份/运营商至少积累20个可用探测点。通过监测点的监控，实现全网的网络质量监控。目前大概99%以上IPV4的网络波动包括丢包、延时过高都能监测到，但是这套机制在IPv6上存在挑战。因为IPV6本身地址比较多，也一直在变。初期是依赖App上报各省份运营商的IPV6 DNS服务器地址及信通院发展检测平台遍布全国的IPv6监测点来进行探测。目前还在探索的是利用固定的路由器地址，不管是基站的路由器地址还是用户家里的路由器来进行探测。
经过长期积累，绘制出了全国各地区的网络质量图，打通权威DNS，出问题时自动调度到其他备用机房入口。如下图所示：
除了常规的埋点，在客户端也做了网络诊断模块，用户点击网络检测，开始启动网络诊断流程。按照策略进行网络拨测，网络异常时会利用之前缓存的策略，之前如果没有缓存过也会有内置托底的策略。通过对京东的核心域名以及其他互联网厂商的核心域名来进行Ping和HTTPS的探测，就可以定位到用户的网络问题。数据自动上报与用户手动上报结合，服务端监控展示。
京东重视用户反馈，每天会有数万条多渠道反馈过来的信息，那是如何处理的呢？基于分词库的准确率是比较低的，只有50%左右。比如，对于“卡”这个关键字分类，它有可能是做网络卡，也有可能说是绑定银行卡等等。后来与AI团队合作，机器学习自动分类，准确度提升到75%左右。相似反馈问题自动聚合告警，通知QA团队建单跟进。
活动页是京东电商领域的核心页面，我们会有专门的监测平台来进行检测——啄木鸟开放平台。啄木鸟开放平台基于headless chrome，是一套集活动可用性监控、活动性能监控、活动测试、自动告警、数据检查，体检报告为一体的多维度的活动测试监控平台，助力优化和提升用户访问活动页体验。左边检测内容表格是可用性问题，如页面打不开、空白。右边检测内容主要是性能问题，如配置的图片过大，没有做缓存参数的配置，没有做图片压缩等问题。活动页上线之前我们都会先检查一遍，在线的活动也会定时做监测，根据对应的分类，自动发告警，发到我们对应的运维团队、QA团队、运营团队，有专门的人跟进解决。
四
未来展望
未来，我们要优化的方向分为四个方面，分别是HTTPDNS优化、安全方面TLS 1.3、HTTP/2 ServerPush、QUIC/HTTP3.0，如下图所示：
对于电商消费型的 App，从进入某个页面到该页面新内容显示出来，这阶段消耗的时间，是一个 App 的生死线。如果这个时间相较于竞品差距太大，这将是毁灭性的事情，极有可能在争取用户中的赛场上处于下风。移动网络优化、监控告警是一个技术活，如何提升移动网络优化？如何构建立体化监控体系？开发者都需要去做一些特定的优化，来达到优化移动网络的目的。
End
