# 信令风暴解剖：一款App放倒docomo全网 **概述**：2012年1月26日，日本NTT docomo全国数据业务大面积瘫痪数小时，官方调查结论令全行业错愕——肇事者不是地震、不是光缆、不是黑客，而是docomo自家官方邮件App「spモードメール」的一个缺陷：它驱使数百万部手机向网络发起海量会话建立请求，把分组域信令处理节点活活压垮。本文以这起经典事故为主轴，解剖信令风暴的产生机理、放大链条，梳理3GPP定义的层层过载保护机制，并给出一套从KPI反推终端行为、分级限流的排查实战方法——这套方法今天在5G物联网海量连接时代，反而更值钱了。 ## 目录 - 一、事故还原：那个下午，全日本的手机都转圈 - 二、根因解剖：信令是怎么雪崩的 - 三、Retry Storm：压垮骆驼的最后一万根稻草 - 四、网络的免疫系统：过载保护有几层 - 五、排查实战：从核心网KPI反推终端行为 - 六、docomo的整改与「限局运転」 - 七、今天的教训：物联网时代信令风暴更凶 - 八、写在最后 - 参考来源 ## 一、事故还原：那个下午，全日本的手机都转圈 先把时间线摆出来。以下信息以docomo官方公告与当年日本主流媒体报道为准，个别精确到分钟的细节因原始页面年代久远，标注为“据公开报道”： | 时间（当地时间） | 事件 | |---|---| | 2012年1月26日下午 | docomo全国范围内数据业务（sp模式上网、邮件收发）开始大面积无法使用，用户端表现为连接超时、一直转圈 | | 当天傍晚晚高峰 | 故障持续发酵，影响范围从部分区域扩大到全国，社交媒体和新闻网站开始刷屏 | | 当晚 | docomo陆续发布公告，组织应急处理 | | 约4~5小时后 | 数据业务基本恢复（据公开报道） | | 随后数日 | docomo公布初步调查方向，协调应用侧紧急修复 | | 2012年2月 | docomo发布正式调查结果：官方邮件App「spモードメール」存在缺陷，引发海量会话连接请求，导致分组网过负荷；督促用户更新应用版本，并公布网络侧再发防止对策 | 这起事故有几个让工程师脊背发凉的细节。 第一，**故障不是从网络“坏”开始的，而是从网络“忙”开始的**。事后看核心网告警，很可能从头到尾都没有一块板子报硬件故障——所有的板子都在正常工作，只是活太多了。 第二，**肇事者是自己人**。spモードメール是docomo官方出品、预装推送给Android用户的邮件应用，用户量和活跃度都是顶级的。官方应用带着缺陷大规模分发，等于给全网埋了一颗按用户数装药量的炸弹。 第三，**这起故障不是孤例**。2011年末到2012年春，docomo连续发生多次大规模通信障碍，一度成为日本社会议题，时任社长公开鞠躬道歉，监管部门总务省介入要求提交原因与再发防止报告（据当时媒体报道）。运营商的信任危机，往往就是这样一连串故障堆出来的。 ## 二、根因解剖：信令是怎么雪崩的 要理解这起事故，得先建立一个反直觉的认知：**移动网络里最脆弱的不是管道，是信令**。 用户面（你的微信图片、视频流量）走的是数据通道，设备是大容量转发硬件，单用户成本极低。而信令面负责的是“每次用网之前的手续”：RRC连接建立、鉴权、会话（承载/PDP上下文）建立、寻呼、位置更新。这些手续每一条都要消耗控制节点的CPU、内存和信令链路带宽。 一部手机发一张图，用户面可能就几MB；但为了发这张图，手机要经历：空闲态→发起RRC连接请求→完成鉴权与安全模式→建立会话→传数据→释放连接回空闲态。**如果App设计不当（频繁断开重连、用轮询代替推送），用户面流量可以小到忽略不计，信令开销却可以被放大几十倍甚至上百倍**。这就是行业里说的“信令放大系数”——学术界对信令风暴的研究（可检索arXiv上关于signaling storm的系列论文）反复验证过：一条即时消息在“坏App”手里，可以触发远比消息本身昂贵的信令序列。 docomo这次事故的雪崩链条，可以画成一张图： ```mermaid flowchart TD A["App重试缺陷"] --> B["海量会话建立请求"] B --> C["信令面处理节点过载"] C --> D["响应变慢 超时增多"] D --> B C --> E["正常用户请求被拖死"] E --> F["全国数据业务不可用"] ``` 注意图里那个环：`C --> D --> B`。这是雪崩的灵魂——**过载导致超时，超时触发重试，重试加重过载**。这是一个正反馈回路。系统一旦越过临界点，就不是“慢一点”而是“指数恶化”，几秒钟之内从高负载跳到完全不可用。做过压力测试的工程师都见过这个相变：负载从70%爬到90%时看起来都还行，92%的时候系统突然死亡。 还要强调一点：信令风暴攻击的是**共享资源**。spモードメール的用户只发了自己的请求，但分组域处理节点是全量用户共享的——App用户的海量请求把公共信令资源吃光，不装这个App、行为完全正常的用户也一并遭殃。这就是为什么一个App能放倒一张全国网：**它劫持的不是某个业务，是公共控制平面**。 ## 三、Retry Storm：压垮骆驼的最后一万根稻草 把镜头拉近到终端侧。docomo官方结论是App缺陷导致“会话连接要求大量发生”，行业复盘时普遍将其归入典型的**重试风暴（Retry Storm）**模式（具体的缺陷代码逻辑属厂商内部信息，公开渠道未见完整披露，此处为通用机理分析）： 1. App的网络模块存在缺陷，在特定条件下（如收到大量邮件、连接异常中断时）反复发起会话建立； 2. 网络开始变慢，请求超时； 3. 超时触发App的重试逻辑——而且很多实现是“立即重试”甚至“并发重试”，没有指数退避； 4. 每一次重试都是一条全新的信令请求，网络更慢； 5. 更多终端超时，更多重试……循环加剧。 数据库圈的同仁对这套剧本应该毫不陌生：连接池耗尽、雪崩式重试、服务连锁宕机——本质是同一个故障模式在移动网核心网上演。区别在于，核心网的“重启”比微服务慢得多，涉及全网数以千万计的终端状态。 这个案例给所有写网络程序的工程师上了深刻一课：**客户端的重试策略从来不只是客户端的事**。没有退避、没有抖动、没有上限的重试代码，在单机测试里无害，在千万级分发规模下就是武器。顺带一提，这段教训在2018年爱立信证书过期导致多国运营商瘫痪的事件里再度验证——终端/软件侧的一个“小事”，经网络放大后就是国家级事故。 ## 四、网络的免疫系统：过载保护有几层 雪崩讲完了，讲防御。3GPP为移动网络设计了一整套从空口到核心网的过载保护机制，可以理解为免疫系统的分层防线。这也是本文最想让你带走的干货——下次做网络设计或故障预案时，对照检查每一层是否配置到位： | 防线 | 所在层 | 动作 | 标准依据 | |---|---|---|---| | 接入等级控制ACB | 空口RRC | 系统广播按接入等级0~9设置限制因子，直接禁止部分用户发起连接；等级10留给高优先级呼叫，11~15为运营商及特殊用途（如公共事业）预留 | TS 22.011 | | 扩展接入限制EAB | 空口RRC | 面向海量物联网终端单独设限——人先上、机排队 | TS 22.011（Rel-11引入） | | 业务级接入限制SSAC | 空口RRC | 按业务类型（如VoLTE语音）单独控制，保语音弃数据 | TS 22.011 | | S1-AP过载指示 | 核心↔无线 | 核心网节点过载时通知基站削减信令请求，把压力挡在门外 | TS 36.413 | | NAS级过载拒绝 | 核心网NAS | 对Attach/TAU/Service Request直接拒绝，并下发退避定时器（如T3346），让终端老老实实等够时间再来 | TS 24.301 | | APN级拥塞控制 | 核心网 | 只对特定APN下发退避，精准锁定问题终端群，不影响其他业务 | TS 24.301 | | 统一接入控制UAC | 5G空口 | 按接入类别×接入身份矩阵统一控制，取代4G碎片化的各类barring | TS 38.331 | | NGAP过载与切片级控制 | 5G核心网 | AMF过载通知gNB；支持按网络切片维度控制并发与拒绝 | TS 38.413 / TS 24.501 | 几点实战注释： - **紧急呼叫永远最高优先级**，所有barring机制都为紧急呼叫留了豁免通道。运营商做限流预案时，第一件事是确认这条底线没有被参数配置意外破坏。 - 这些机制标准都定义了，但**标准允许多种实现，具体参数粒度、默认值与联动行为以各厂家官方文档为准**——运维要做的是把本网每层开关的位置摸清楚，而不是假设它们“默认会干活”。 - 分层防御的精髓是**梯度**：空口barring是阀门（挡得早、代价小），NAS拒绝是闸门（带退避定时器，教会终端礼貌重试），核心网过载指示是保险丝（最后的自我保护）。理想状态下，风暴应该在空口就被削峰，根本到不了核心网。 docomo事故时（2012年，3G网络时代），这套体系还远没有今天完整——EAB是Rel-11才有的，APN级拥塞控制也是后来的演进。这正是那一代运营商“只能眼睁睁看着雪崩”的技术背景：**防御工具落后于攻击形态**。今天的5G网络武器库齐整得多，缺的往往不是机制，是把机制参数化、演练化的运维纪律。 ## 五、排查实战：从核心网KPI反推终端行为 现在换运维视角。假设你就是当晚docomo网络运维中心值班的人，告警可能只有零星几条“负载高”，你怎么定位到“一款App”这个粒度？总结一套信令异常排查的通用打法： ```mermaid flowchart TD G["信令KPI突涨"] --> H["按APN与终端群聚合"] H --> I["锁定异常应用或终端群"] I --> J["启用分级限流"] J --> K["通报应用方修复"] K --> L["观察KPI回落确认"] ``` **第一步：分辨“容量型故障”和“缺陷型故障”。** 告警体系对硬件坏、链路断很敏感，但对“所有东西都活着只是太忙”天生迟钝。容量型故障的指纹是：无硬件告警、KPI缓涨后突然陡增、故障范围随用户行为（晚高峰）扩大。值班看到“信令量涨了但没有任何板子红”，就要立刻切换到信令风暴预案，而不是等硬件告警。 **第二步：从核心网计数器反推终端行为特征。** 核心网看得见每一个请求：Attach/TAU/Service Request的速率、会话建立成功率、按APN/号段/漫游属性的分布。把突增期的信令请求按这些维度做聚合，异常群体的特征会自己浮出来——比如“某一APN的会话建立请求是基线的40倍，集中在某一批IMSI段”。这就是从果推因：网络不知道App叫什么名字，但网络看得见它的行为指纹。 **第三步：分级限流，边止血边定位。** 定位到终端群之后，用APN级拥塞控制或barring精准限制该群体，把全网信令量压回安全水位。注意顺序：**先限流保全网，再谈根因**——根因分析可以事后慢慢做，全网瘫痪每分钟都在烧用户信任。限流时务必核对紧急呼叫豁免路径。 **第四步：信令跟踪留证。** 对异常IMSI段开信令跟踪（S1AP/NGAP抓包），拿到第一手的请求序列——这是和应用开发方对质的证据，也是回归测试的基线。 **第五步：闭环确认。** 应用修复、群体限制解除后，观察信令KPI是否回到基线形态。很多团队止于“故障恢复了”，但重试风暴的余震（积压的定时任务、延迟的重试）可能在深夜再来一波，KPI要盯满一个完整周期。 这套打法里最值钱的思想是：**把终端群当成可观测的对象，而不是黑盒**。信令风暴排查的本质，是用核心网的观测数据给几百万部手机做“群体行为画像”。 ## 六、docomo的整改与「限局运転」 事故之后docomo做了什么，比事故本身更有学习价值。综合其官方公告与后续披露（据公开报道整理）： - **应用侧**：紧急发布修复版本，官方渠道推送更新，并公开向用户说明原因、请求配合升级——把终端侧修复当作头等大事，因为根子在终端。 - **网络侧**：增强异常流量的检测与控制能力，对明显异常的连接请求模式具备识别和抑制手段，把“单点异常不扩散”做成网络能力。 - **运维制度**：日本运营商语境里有个专门术语叫「限局運転」——故障发生时主动把影响压制在局部，牺牲一小块保住全网大部分的可用性，避免局部过载扩散成全网事故。此后历次故障通报中，docomo都明确报告限局运転的执行情况，把它变成了标准动作和公开承诺。 - **透明度**：docomo对重大故障公开时间线、原因、对策的披露风格，在行业里是出了名的较真。对运维团队而言，这种“把丑事写清楚”的纪律，本身就是防止复发最便宜的药。 一句话总结docomo学费换来的共识：**信令风暴的治理，三分靠网络机制，七分靠运维纪律——参数有没有配、预案有没有演练、终端准入有没有抓手、应用方有没有联动的紧急通道。** ## 七、今天的教训：物联网时代信令风暴更凶 有人会说，2012年的故事，智能手机时代的老黄历了。恰恰相反——**5G时代信令风暴的弹药库比当年大得多**。 第一，终端数量级变了。当年是百万级智能手机，现在是百亿级物联网终端。3GPP在物联网需求研究（TR 45.820）里明确过“每小区5万连接”的容量目标——海量终端意味着海量周期性TAU、海量状态迁移。一个配置错误的T3412（周期性位置更新定时器）值，配得太短，就是全网定时器同步的一波TAU风暴；一批终端固件里的重连缺陷，就是放大版的spモードメール事件。区别只是这次的“App”变成了烧死在模组里的固件，你想召回都召回不动。 第二，切片带来了新的过载维度。5G核心网的AMF过载、按切片的拥塞控制（TS 24.501）是必须吃透的新工具——风暴可能只打某一个切片，处置时既要保住该切片的SLA承诺，又不能让压力外溢到其他切片。 第三，给今天运维团队的落地清单： - 把本网空口barring/EAB/UAC、NAS退避、核心网过载指示每一层的**当前参数值**做成台账，纳入变更管理——过载保护参数几年没人看过，是行业的普遍现状； - 对物联网卡/行业终端建立**准入与行为基线**：异常信令速率自动触发限流而非告警等人看； - 与主要行业客户/终端厂商建立**信令级联动的应急通道**，故障时能在一小时内让对端停发或降频； - 每年至少一次**信令风暴演练**：在保障窗口人为注入受控的信令过载，验证限流梯度和紧急呼叫豁免——预案没演练过，等于没有预案。 ## 八、写在最后 回到2012年1月26日的那个下午。全网瘫痪的直接肇因，是一个App里的几行重试代码。它没有攻击任何人，它只是在自己的职责范围内“正常地”失败了——然后在几百万部的分发规模和几亿用户共享的信令面上，失败被复利成了灾难。 分布式系统有一句老话：一切最终一致的系统，都会在某一天考验你的重试策略。移动网络把这句话的代价放大到了全国尺度。信令风暴这类故障最狡猾的地方在于，它发生的每一环单看都不算错：App想可靠收发邮件没有错，网络尽力响应没有错，终端超时重试也没有错——**错的是没有人负责看它们相乘之后的总量**。 运维的价值，就藏在“相乘”两个字里。容量规划要算的是乘积，过载保护防的是乘积，故障排查要反推的也是乘积。下次深夜值班，看到信令量悄悄爬坡而告警屏一片安详时，愿你想起docomo那个下午——告警不响，不代表风平浪静；那可能正是雪崩出发前，最后一秒的宁静。 ## 参考来源 1. [NTT docomo 官方信息/障碍情报页](https://www.nttdocomo.co.jp/info/) — docomo官方故障公告入口，2012年1月spモードメール事件的官方通报与再发防止对策均经此渠道发布（当年具体报告页现多已归档下线） 2. [Spモードメール - Wikipedia（日本語）](https://ja.wikipedia.org/wiki/Sp%E3%83%A2%E3%83%BC%E3%83%89%E3%83%A1%E3%83%BC%E3%83%AB) — 该应用的词条，收录2012年1月26日由应用缺陷引发的大规模通信障碍概述 3. [3GPP TS 24.301](https://www.3gpp.org/dynareport/24301.htm) — LTE NAS层规范：NAS级过载控制、退避定时器（T3346）、APN级拥塞控制的定义出处 4. [3GPP TS 22.011](https://www.3gpp.org/dynareport/22011.htm) — 业务可达性规范：接入等级控制（ACB）、EAB、SSAC等空口接入限制机制的标准依据 5. [3GPP TS 38.331](https://www.3gpp.org/dynareport/38331.htm) — 5G NR RRC规范：统一接入控制（UAC）的定义出处 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。