![]()
你的Mac最长连续开机多久?一周?一个月?如果你碰巧是服务器运维,这个数字可能直奔三位数。然后某天凌晨,所有网络连接突然僵死,ping能通,SSH连不上,服务全挂——重启才能活。
这不是硬件老化,是macOS埋了20年的代码级地雷。AI公司Photon最近拆弹时发现:系统连续运行49天17小时2分47秒后,TCP协议栈会触发整数溢出,网络能力彻底瘫痪。
49天零47秒:一个精确到秒的崩溃倒计时
Photon在监控苹果Messages服务的Mac服务器上首次遭遇这个问题。两台测试机复现成功,时间分秒不差。故障表现堪称诡异:既有连接冻在原地不会过期,临时端口池慢慢枯竭,最终新TCP连接完全无法建立。
ICMP协议独善其身——ping命令永远畅通,仿佛在嘲讽你:"网络没坏,只是你的应用都死了。"
根源是TCP时间戳计数器的设计。macOS用一个32位整数记录毫秒级时间戳,持续累加约49.7天后数值溢出归零。这个时间戳本该用于判断连接是否超时失效,归零后系统逻辑混乱,该杀的连接杀不掉,该建的新连接建不了。
Photon在博客原文里用了个精准描述:"ticking time bomb"——滴答作响的定时炸弹。不是比喻,是字面意思:倒计时结束,爆炸准时发生。
微软20年前踩过同样的坑
这种49天魔咒不是苹果独创。Photon特意翻出旧账:Windows 95就有过49.7天崩溃漏洞,原理一模一样。当时微软的GetTickCount()函数同样用32位毫秒计数器,溢出后系统时间概念混乱,引发连锁故障。
区别在于时代背景。1995年的个人电脑鲜少连续开机超过一周,这个bug近乎理论存在。2025年的服务器7×24小时运行是基操,同样的代码债就成了生产事故。
苹果显然知道这个隐患。TCP时间戳是RFC 1323标准定义的机制,Linux和FreeBSD的实现都做过防溢出处理。macOS的BSD血统没能避免这个问题,说明是苹果自己的修改或维护疏漏。
Photon的发现过程本身就有戏剧性。他们部署的AI代理监控服务需要长期稳定连接,结果Mac服务器"周期性神秘失联"。排查日志时发现故障间隔高度规律——换算成毫秒,刚好是2的32次方。
谁该真正担心这个问题
普通Mac用户基本可以忽略。即使你把笔记本当台式机用,系统更新、软件安装、偶尔卡顿重启都会打断计时。能连续49天不重启的,只有特定场景的服务器部署。
但正是这些场景最要命。CI/CD构建农场、消息队列中间件、轻量级边缘节点——这些用Mac Mini或Mac Studio堆出来的基础设施,现在多了条隐性SLO:必须在第49天前安排重启窗口。
更隐蔽的风险是容器化和虚拟化层。物理机49天重启一次可接受,但如果宿主机时间戳溢出,所有容器的网络状态可能同时污染。Photon没有测试这种场景,但逻辑上无法排除。
临时解决方案倒是不复杂:cron定时重启,或者监控uptime接近阈值时主动触发。但"定时重启Mac服务器"这件事本身,对苹果生态的运维人员就有些 surreal——你们不是以稳定著称吗?
苹果尚未公开回应这个bug。按照惯例,可能会在下个补丁版本中默默修复,CHANGELOG里写一句"改进网络稳定性"。Photon已经公布技术细节和检测脚本,算是帮同行踩了雷。
这个案例的讽刺之处在于:整数溢出是计算机科学入门课就会讲的基础陷阱,TCP时间戳溢出的解决方案在开源社区存在多年。一家万亿市值公司的操作系统,却在2025年还在为此交学费。
Photon的工程师在博客结尾留了句话:他们现在给所有Mac服务器设了45天强制重启策略。多出来的4天缓冲,是留给值班人员的睡眠尊严。
你的生产环境有运行超过40天的Mac吗?如果有,现在是时候检查一下uptime了。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.