云端卡顿与高延迟？Android性能突围实战

　　去年中考期间，我在教育局机房盯屏，空调外机在窗外突突震——那声音我听八回就记住了，第七次它停了二十来分钟，第八次恢复时，我正把保温杯搁在服务器机柜顶上，杯底水渍一圈圈晕开。

　　后台监控弹出告警：云端接口平均延迟从三百毫秒跳到两千二，但 Android 端根本没报错，就卡在登录页倒计时——三、二、一，不动；再点“重试”，按钮变灰两秒，又自己亮回来，像没按过一样。我原以为是证书续签出问题，结果发现 TLS 握手全通，连得上，就是不返回 body。

　　运维老张蹲在机柜后面啃烧饼，油渣掉进散热孔里，他伸手去掏，说：“你看看 log，是不是那个新插件干的？”我说不是，log 里没它调用记录；他又说：“那你看看 DNS？”我说 DNS 缓存刚刷过，dig 跟 trace 都走得到云厂商的 VIP。可安卓端偏偏就在第六次请求后突然快了——不是变正常，是快得反常：半秒内闪进首页，连加载动画都没播完。

　　我翻手机抓包，Wireshark 里抓着抓着，发现有个 SYN-ACK 包的 timestamp 选项字段，值是 0x00000000，全零。这不对，本地时钟不可能为零；我让测试妹换台手机重试，她拿的是小米13，抓出来 timestamp 是 0x8A7F21B3，正常。但她一换成华为 P60，那个 timestamp 又归零了——就这一种机型，就这个系统版本，就这次云 API 的 path 带了个 /v3/submit/exam/ 字样时才触发。

　　我原以为是内核 TCP 栈 bug，结果查 kernel commit 记录，发现是某次合入的 TCP 时间戳优化补丁，只在启用 CONFIG_TCP_TS_OPT_RTT_MEASURE 后才会读取硬件 TSC 寄存器，而华为那台设备恰好 TSC 不稳定——可这玩意儿跟 Android SDK 版本无关，跟云服务端更没关系，它纯属手机启动那一刻，CPU 上电自检没校准到位，导致内核拿到个非法时间戳。所以云端收包后，按 RFC7323 默认策略静默丢弃带非法 timestamp 的 ACK，只等重传，重传超时再重发 SYN……可 Android 持久连接池根本没感知——它还在等第一个 ACK，死等。

　　（楼下有只猫在挠铁门，吱啦——吱啦——）

　　那天最后恢复不是靠改代码，是让现场老师把那批华为 P60 全部关机重启一遍。热重启不行，必须冷的，得等主板电容彻底放完电。重启后 timestamp 回归正常，所有接口立刻恢复，延迟回到二百多毫秒，波动极小。优胜劣汰？对，就是字面意思——活下来的不是调优最狠的那个，是刚好没被这块 TSC 硬伤咬中的那批机器。

文章配图，仅供参考

　　有谁碰到过这个吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!