2001年的11月网益科技园三层
技术部的服务器指示灯像串坏了的糖葫芦，红得刺眼。
我攥着测温枪贴在机柜上，38.6c的读数让呼出的白气都带着焦灼，这已经是本周第三次服务器过热告警。
而屏幕上“短信发送队列积压 1238条”的红色提示，比机柜温度更让人窒息。
“又卡了！”
老谭把鼠标往桌上一拍，他面前的监控屏分着四个窗口：Apache服务器连接数、mySqL查询耗时、移动梦网接口响应时间，还有实时用户投诉量。
此刻前三个数字像被吹胀的气球，投诉量的折线图更是直戳天花板。
这一切的源头，得从两个月前沈剑锋的电话说起。
彼时的短信江湖，网益与信浪像两把开刃的刀，都盯着移动梦网这块肥肉，但磨刃的方式截然不同。
丁雷在财报危机后押下的注很明确：游戏与短信捆绑。
我们的短信系统架构是“Apache+mySqL +自定义交互模块”，核心在“交互”二字。
《大话西游》玩家能通过短信接收师徒系统提醒，移动 qq用户可以用短信收发即时消息。
为了处理这些高频交互，我和老谭给 user_sms表加了双索引：user_id主键索引和 msg_time时间索引。还在应用层写了个简单的消息缓存池，把未读短信先存在内存里，每 30秒批量写入数据库，这样能把 mySqL的 qpS从 200压到 80以下。
信浪则走资讯推送的路子。
他们依托新闻门户的优势，搞了套“Apache+oracle +资讯分发引擎”，oracle的稳定性扛得住每日百万级的资讯订阅请求，分发引擎能按用户标签（如“股市”“体育”）批量生成短信包。
听说他们的工程师给推送系统做了“热点缓存”，把突发新闻比如“国足出线”的短信模板预存在服务器内存，一旦触发就能直接调用移动梦网接口，比我们的资讯推送快 2秒。
我们的服务器机架上堆着不少二手戴尔 powerEdge 2650，丁雷说“能省则省”，所以用负载均衡器把请求分到 8台服务器；信浪那边清一色的 Ibm xSeries，单台内存就有 4Gb，比我们的 2Gb机型吞吐量大不少。
但论灵活性，我们的自定义模块更胜一筹——比如用户发“绑定游戏账号”到 ，后台能直接调用《大话西游》的用户验证接口，这是信浪的资讯系统学不来的。
沈剑锋当时还是信浪技术部的骨干，每周都要打两三个电话问技术细节。
“你们的短信验证码是怎么防重复的？”
“移动梦网接口超时怎么重试？”
我按公司规定只敢说些皮毛：“就是用随机数生成验证码，超时就等 3秒再发一次。”
他在电话那头笑：“刘军，咱们都是搞技术的，别藏着掖着。”
现在想来，那些问话早露了马脚。
我把这个情况报告了jackson和老谭
11月28日凌晨三点，监控屏突然炸了。
“连接数破 1000了！”
老谭的声音惊醒了趴在桌上打盹的我。
正常情况下，我们的 Apache maxclients设为 500，即使峰值也超不过 600。
我点开服务器日志，密密麻麻的 poSt请求占满了屏幕，全是调用“\/sms\/send”接口的记录。
用户 Id从 到 随机生成，手机号段涵盖全国各省，请求头里的“Referer”字段全是“sina点\/sms”——虽然 Ip地址分散，但这痕迹太明显了。
更糟的是数据库。
老谭打开 mySqL的慢查询日志，满屏都是“SELEct * FRom sms_queue whERE user_id =? ANd status = 0”的查询，执行时间最短 15秒，最长 48秒。
“他们用了模糊查询，还不限制结果集，把表给扫崩了！”
老谭拍着键盘，我看到 sms_queue表的行数已经从正常的 2万涨到 18万，全是伪造的未发送记录。
上午九点，投诉电话快把前台打爆了。
“我订的股市短信怎么没收到？”
“游戏里的好友消息发不出去！”
副总陈建仁黑着脸冲进技术部：“移动那边刚发函，说我们的短信送达率跌到 60%，再这样就暂停合作！”
我盯着监控屏上还在涨的连接数，突然想起沈剑锋昨天的电话：“刘军，你们服务器扛得住大流量吗？我开公司可能也要做短信业务。”
当时我还以为他只是问问，现在才明白是示威。
技术总监 Jackson把我们拉进会议室：“先定位攻击方式。”
老谭调出网络抓包记录：“都是合法的 http请求，没有恶意代码，就是量太大，每秒 200个请求，把连接池占满了，数据库查询又拖慢了处理速度，形成恶性循环。”
Jackson敲着桌子：“是伪造请求的 ddoS，肯定沈剑锋收买了信浪的核心技术人员，知道我们接口的参数格式。”
那天我们试了临时方案：重启 Apache释放连接，把 mySqL的查询超时设为 5秒，没用——刚清完连接，新的请求又涌进来，数据库还是卡。
陈建仁每隔半小时就来催一次，技术部的气氛像闷在罐子里的火药。
接下来的一个星期，我们几乎住在技术部。
Jackson提出“堵源头、优处理、分负载”的三层方案，每一步都得抠 2001年的技术极限。
那时候还没有云防护，cdN只在少数门户网站试用，一切都得靠自己动手。
第一层是“堵源头”。
老谭发现攻击请求的 Ip虽然分散，但有 30%来自北京海淀区的固定网段，正好是信浪总部所在的区域。
我们找运维借了台华为的 quidway路由器，在 AcL规则里加了“拒绝 123点125点0点0\/16网段访问 80端口”的配置。
又写了个简单的 Shell脚本，每 10秒扫描一次 Apache的访问日志，把每分钟请求超过 50次的 Ip自动加入黑名单。
第一天下来，攻击请求量降了 40%。
第二层是“优处理”。
针对数据库卡顿，我把 sms_queue表拆成两个：sms_pending（待发送）和 sms_history（历史记录），只在 sms_pending上加 user_id索引。
还把“SELEct *”改成“SELEct id， phone， content”，减少数据传输量。
老谭更绝。
他在应用层加了个“请求过滤”模块：用户发送短信前必须验证手机号格式，伪造的随机手机号直接在应用层拦截，不传入数据库。
改完之后，mySqL的慢查询从每分钟 200条降到 10条以内，cpU占用率从 98%掉到 50%。
第三层是“分负载”。
我们把服务器分成两组：A组处理游戏短信（移动 qq、游戏通知），b组处理资讯订阅。每组 4台服务器，用硬件负载均衡器分流。
Jackson还亲自去移动梦网总部，说服他们调整接口协议：增加“请求方 Ip +时间戳”的验证，同一 Ip每分钟最多发送 30次请求，超过就返回“429 too many Requests”。
移动的工程师帮我们在短信网关加了特征识别——伪造请求的“User-Agent”字段都是“mozilla\/4.0”，真实用户的则是“Nokia6100”“motorolaV3”等手机型号，网关直接过滤掉异常 User-Agent的请求。
12月 5日凌晨，我们上线了全套方案。
监控屏上的连接数稳定在 300左右，短信发送队列积压量以每分钟 100条的速度减少。
早上八点，投诉电话第一次出现了空闲。
陈建仁走进技术部时，手里拎着两袋豆浆油条：“你们几个，总算把这窟窿填上了。”
我咬着油条看向窗外，冬阳照在服务器的指示灯上，红光灯变成了柔和的橙黄色。
老谭戳了戳我的胳膊：“我问了下王蒙，沈剑锋那公司好像还没开张。”
我打开手机，看到沈剑锋发了条短信过来：“江湖路远，总有新机会。”
确实有新机会。
短信业务这块蓝海，除了我们和信浪，还有不少公司在摩拳擦掌。
我摸了摸服务器的外壳，温度已经降到 32c。
但我知道，这只是第一轮攻防战的结束——只要蛋糕还在，就永远有人想拿着刀冲进来。