域名解析这件事平时没人会多看它一眼。但一到双十一抢购、抖音刷视频卡在加载圈的时候问题就全都冒出来了。早期我做过几年移动端基础架构接到过最多的线上反馈就是“为什么我家的网打不开淘宝换个WiFi就能开了”还有“我们App里某个页面在某个地区永远加载失败”。这类问题排查到最后十有八九都会落到同一个环节DNS解析被改了或者压根没解析出来。所以当淘宝、抖音这些大厂前几年陆续被曝出自己搞了一套HTTPDNS的时候我一点都不意外。不是他们钱多烧得慌而是传统的DNS链路在移动场景下已经烂到没法用了。这篇文章我就以实际做过的项目经验为底把HTTPDNS这件事从头到尾拆开讲清楚包括它到底解决了什么、为什么不直接用现成的公共DNS、自研的难点在哪、以及落地时那些文档里不会写的坑。1. 先搞清楚域名解析是怎么被劫持的要理解HTTPDNS的价值首先得明白传统DNS在移动端会遇到什么破事。我见过太多开发者在应用里排查慢请求查来查去发现HTTP层一切正常TCP连接建立却要花两三秒最终定位到是DNS解析在作祟。1.1 一条完整的DNS解析链路里藏着多少个中间人当你的手机WiFi连着路由器、路由器又连着运营商宽带时App要访问某个接口域名第一步是向系统配置的Local DNS发起查询。这个Local DNS通常是运营商自动下发的比如你拨号上网后自动获取的那组地址。如果你的手机用的是4G/5G蜂窝网络那DNS服务器就是运营商核心网里的设备。整条链路是这样的手机系统里的Resolver拿到域名后会向Local DNS发一个UDP请求Local DNS如果本地没有缓存就会向根DNS、顶级域DNS、权威DNS逐级查询最终拿到IP地址返回给手机。注意这个过程里你的手机只和Local DNS直接通信中间那几级查询全是由Local DNS代劳的。而你完全不知道Local DNS做了什么手脚。1.2 动手脚的常见手段缓存投毒、篡改响应、流量劫持恶意攻击者要劫持你的域名解析根本不需要攻破什么高级系统。最常见的手段是在你和Local DNS之间的链路上做UDP欺骗——因为标准DNS是明文UDP协议没有认证机制谁先返回一个伪造的应答包系统就信谁。伪造的应答里可以把某域名指向一个钓鱼服务器IP流量就过去了。比恶意攻击更普遍的是运营商层面的“商业劫持”。有些Local DNS会对特定域名返回一个非权威的IP比如把某电商App的图片域名解析到运营商自己的缓存服务器上用来节省跨网流量甚至插入广告。用户感知到的就是某个页面多了个悬浮窗或者图片加载出来但很模糊。还有一类是纯“解析污染”。某些域名在特定网络环境下返回不了正确结果原因可能是防火墙策略、Local DNS的劣质缓存、或者是分布式拒绝服务攻击导致权威DNS被淹没但结果都一样解析失败。1.3 为什么这些劫持对电商和短视频是致命的对淘宝这类电商App来说DNS被劫持的后果不只是页面加载慢严重时会导致下单请求被导向一个仿冒服务器用户隐私数据直接暴露。对抖音这类视频App来说CDN节点调度依赖精准的解析结果一旦DNS被污染或者被调度到了距离用户很远的节点视频首屏加载就会卡成PPT。更要命的是这类问题具有地域随机性。同一个App在广东地区一切正常到了某些省份就频繁超时。因为每个地区的运营商Local DNS行为不一样有些地区网络环境干净有些地区长期处于被污染状态。你在应用商店的评论里看到那些“换个网络就好了”“打开飞行模式再关掉就恢复了”的反馈本质上都是DNS在作祟。2. HTTPDNS的核心思路绕开那条不靠谱的链路既然传统DNS有这么多问题大厂们想的不是去和运营商吵架而是从架构上直接绕过整个Local DNS体系。这就引出了HTTPDNS。2.1 HTTPDNS到底是什么把DNS请求放进HTTP里HTTPDNS字面意思就是“基于HTTP协议的域名解析服务”。核心思路非常简单把原来系统级的DNS查询变成一次HTTP请求。你的App不再向Local DNS发UDP包而是直接向一个你指定的HTTP服务器发请求比如请求https://10.10.10.10/d?dnapi.example.com这个服务器返回给你该域名对应的真实IP列表。第一次接触这个概念的朋友可能会问这不就是把DNS服务器换了个地址吗本质上确实是把“谁来给你解析域名”的选择权从网络环境手里拿回来了自己指定谁来解析、以及解析结果能不能信。关键的差异在于传输链路。HTTPDNS走的是HTTP/HTTPS协议可以基于TCP连接可以加签名鉴权可以做加密传输。这意味着整个请求对你来说是透明的链路里谁都无法篡改返回结果。通过预先配置的鉴权参数服务器还能验证请求者的身份返回的数据包也都经过签名校验从机制上杜绝了伪造响应。2.2 一次完整的HTTPDNS请求长什么样用我之前在项目中做过的一个简化版HTTPDNS服务来说明一下典型流程。我在本地用Go语言实现过一套返回格式类似# 请求 curl http://10.10.10.10/d?dnapi.example.comip192.168.1.100t1700000000signabc123 # 返回 { code: 0, msg: success, data: { domain: api.example.com, ips: [203.0.113.10, 203.0.113.11], ttl: 60 } }App拿到这个响应后直接把IP缓存在本地后续请求不走系统Resolver直接用IP去建立TCP连接同时在HTTP请求头里带上原域名Host头保证服务端能正常处理虚拟主机的情况。这里有几个设计细节值得展开说明一下。请求里的ip参数是客户端的上网IPHTTPDNS服务器通过这个IP来判断客户端所在的网络位置从而返回距离最近的节点IP。sign参数是鉴权签名通常是把域名、时间戳、客户端标识拼起来做一个哈希计算服务端用同样的算法验证防止有人恶意刷接口或者伪造响应。TTL不建议设太长我之前习惯设60秒左右既有缓存效果又能在节点故障时快速切换。2.3 和传统DNS相比到底解决了什么问题我直接用一个对比表格来说明这样更直观对比维度传统DNS解析HTTPDNS解析传输协议UDP明文无认证TCP/HTTP可加密可签名中间环节Local DNS、各级递归DNS直连HTTPDNS服务器被篡改风险高链路劫持、缓存投毒低鉴权校验、HTTPS保护调度精准度运营商Local DNS可能返回错误地域IP基于客户端出口IP精确调度故障感知被动等待超时可实时监控、快速切IP接入成本系统默认无需开发需要集成SDK或改造网络层网络依赖依赖当地运营商Local DNS质量依赖HTTPDNS服务器可用性这个对比就能看出来HTTPDNS本质上是用“应用层可控性”换取了“链路安全性”。它没法让所有网络环境都变好但它把解析这件事的主动权握到了自己手里不再被动接受链路里任何一方的“馈赠”。3. 大厂为什么一定要自研而不是采购现成的聊完原理后很多人自然会问市面上不是有现成的HTTPDNS云服务吗找厂商买个SDK接入不就完事了吗这个问题我在实际项目里被人问过很多次身边也有朋友所在的公司直接用第三方HTTPDNS服务。确实能用但对于淘宝、抖音这个体量来说自研的价值不只是省一笔授权费那么简单。3.1 第三方服务解决不了“极致性能”这个硬指标淘宝和抖音的App日活都是以亿为单位的每天发起的解析请求量是天文数字。这带来的第一个问题就是容量规划。第三方HTTPDNS服务商是共享集群某个时段如果多个大客户同时做活动解析压力全堆在一起响应延迟就会出现抖动。而对于淘宝这种大促场景晚高峰的每一毫秒都会被放大到真金白银的转化率上。自建集群之后你可以针对自己的流量模型做容量规划。比如大促前提前扩容针对流量峰值做限流预案核心链路的超时时间可以压到极低的水平。我在做某活动系统的压测时目标是HTTPDNS的P99响应时间不能超过20毫秒这个指标如果用第三方服务完全没法保障。3.2 深度定制能力把解析和调度算法掌握在自己手里第三方HTTPDNS服务基本都是标准产品提供的功能无非是解析、缓存、调度这些通用能力。但淘宝的调度逻辑有多复杂它涉及到全局流量管理GTM、单元化部署、多活机房切换、以及CDN厂商的联合调度。这些逻辑很难抽象成通用的产品功能。举个例子淘宝App里一个页面可能同时依赖十几个域名每个域名的调度策略不完全一样。有些域名要求优先走某条专线有些域名在某个区域内必须指到本地机房还有些域名在故障切换时要立刻切到异地灾备节点。这些规则如果全塞给第三方服务商去实现沟通成本就高得吓人而且排障时两边互相踢皮球是家常便饭。自研HTTPDNS之后调度逻辑可以完全内嵌到自己的基础设施里。解析服务可以直接读取内部的单元化路由表业务方甚至可以通过接口动态调整某类域名的解析策略整个过程不需要任何外部协调。3.3 安全问题也是自研的强驱动力DNS链路劫持是黑灰产的重点攻击面。第三方HTTPDNS虽然也有安全防护但它的防护策略是通用的不可能针对你的业务特征做定制。而大厂的安全团队最清楚自己面临什么类型的攻击。淘宝和抖音这类平台早就是黑产的重点关照对象。他们不仅会通过DNS劫持导流还会尝试通过恶意解析来干扰风控系统甚至直接伪造请求来薅羊毛。自研HTTPDNS后安全团队可以在解析环节直接注入自己的风控策略比如对异常IP段的解析请求返回假IP、对疑似恶意设备返回延迟响应这些能力都很难寄托在外部服务上。3.4 成本账也要算一笔说白了到这个体量还得考虑成本。第三方HTTPDNS的收费模式通常是按解析量计费淘宝抖音每天的解析请求量以百亿计一年下来的费用绝对是个大数字。而自建一套HTTPDNS系统虽然前期投入人力物力做研发但服务器成本可控而且这部分基础能力还能复用到集团内其他业务上长期算下来性价比高得多。4. 自研HTTPDNS的核心技术拆解聊完动机下面说点实在的。如果你也想在团队内部落地一套HTTPDNS或者纯粹想搞清楚这套系统到底是怎么设计的我在这里把拆解后的核心模块和实操细节列出来。4.1 整体架构客户端SDK 接入层 调度集群一套完整的HTTPDNS系统至少包含四层。第一层是客户端SDK嵌入App内部负责发起请求、缓存结果、切换逻辑。第二层是接入层也就是一组高性能的HTTP网关负责接收客户端请求做鉴权、限流、参数校验。第三层是调度集群这是核心大脑里面运行着各种调度策略、路由规则、健康检查逻辑。第四层是数据源负责从权威DNS或者其他上游渠道同步域名解析数据。客户端SDK是最容易被低估的一层。我见过不少团队把精力全花在服务器端结果SDK写得稀烂导致线上各种奇奇怪怪的问题。客户端SDK的核心职责有几个一是要拦截系统DNS调用二是在请求失败时有降级策略三是缓存管理要精细。尤其是第三点缓存设太短会导致解析请求量暴增设太长又会导致节点切换不及时需要根据业务场景动态调整。4.2 解析过程中的关键参数是怎么算出来的很多人会忽略TTLTime To Live这个参数的设计。传统DNS的TTL是权威DNS服务器设置的标准做法是给个600秒或者3600秒。但HTTPDNS的TTL不能简单照搬因为HTTPDNS的核心优势之一就是能快速感知节点故障并切换。我之前在项目里的经验是把TTL分为两层来设计。第一层是域名源站记录的解析TTL这个可以沿用权威DNS的TTL一般建议60到300秒之间。第二层是客户端本地缓存TTL这个建议设得比源站TTL更短一点比如30到120秒。这样设计的好处是一旦服务器端检测到某个节点异常可以在几秒钟内更新解析结果客户端在下一个TTL周期内就会拿到新IP。调度距离的计算也有一套实操方法。当客户端发起请求时服务端会拿到客户端的出口IP然后通过IP库定位到地理位置和运营商。调度集群依据这个信息从节点列表中找出“距离最近链路质量最好”的节点。注意这里不能只看物理距离还要看运营商之间的互联情况。移动用户访问电信机房的节点物理距离可能只有几十公里但跨运营商的延迟可能远远高于几百公里外的同运营商节点。所以调度加权时同运营商权重远高于地理距离权重。4.3 容灾降级和缓存更新策略是命门自研HTTPDNS最怕的就是自己挂掉。如果客户端所有请求都走HTTPDNS服务器一宕机整个App的域名解析就全废了这比运营商Local DNS不稳定还要命。所以容灾降级是必须优先设计的模块。我做过的最稳妥的方案是“三级降级”。第一级客户端SDK维护一个本地缓存即使HTTPDNS服务器完全不可用App依然可以正常解析已经缓存过的域名。第二级如果本地缓存里没有对应域名SDK自动切回系统默认的Local DNS解析虽然可能有劫持风险但至少服务可用。第三级SDK内置一个极简域名列表里面是最核心的几个接口域名内置的IP地址直接写在代码里用于极端情况下的保底访问。缓存更新也不能靠全量刷新那样对服务器和网络的压力都太大。实操上一般用版本号机制。服务器端给每个域名配置一个版本号客户端带着上次拿到的版本号来请求如果版本号没变服务器返回304之类的轻量响应不重复下发IP列表。只有版本号变化时才下发完整的解析记录。这样能大大减少无效流量。5. 落地实践中的常见问题和排查实录理论说完了来说点实战的。这部分我整理了在项目落地HTTPDNS过程中真实遇到过的问题希望能帮准备上车的人少踩几个坑。5.1 问题一部分老机型解析失败率反而升高这是很多团队接入HTTPDNS后遇到的第一个意外。原本系统DNS虽然慢但至少能用结果切到HTTPDNS后某些Android老机型和低版本iOS设备上反而频繁出问题。排查后发现是两个原因叠加造成的。第一老机型上App的WebView不会走HTTPDNS的解析逻辑。WebView内部有自己的一套网络栈它会直接调用系统Resolver根本不经过App的网络层。也就是说HTTPDNS只对App内自己发起的网络请求生效页面里内嵌的H5请求还是走老链路。第二部分低端机在HTTP库实现上有兼容性问题。比如某些手机自带网络框架对自签名证书校验过严导致HTTPS请求直接失败。我的建议是接入HTTPDNS时先做一个白名单机制只对核心API域名走HTTPDNS其余域名还是走系统解析等验证稳定了再逐步放量。另外对WebView场景不要期望太高目前比较成熟的方案是配合自定义Scheme拦截来做成本很高团队要有心理准备。5.2 问题二解析结果不断变化导致连接复用率暴跌这是另一个隐蔽的性能坑。HTTPDNS返回的IP列表是动态的比如第一次返回IP-A第二次可能就变成IP-B。客户端如果没有处理策略每次请求拿到不同IP就会建立新连接导致TLS握手次数剧增连接复用率大幅下降。表现为服务器端负载不算高但客户端延迟明显增加。我当年的调整方式是在SDK端增加了“会话保持”的逻辑。具体来说客户端对同一个域名在一定时间窗口内偏好使用同一个IP只有这个IP连续失败达到一定阈值时才切换到下一个IP。另外IP列表的排序由服务器端计算出来客户端不能自己做轮询避免出现同一连接池里多IP混用的情况。这个问题的排查技巧也分享一下如果发现线上连接复用率指标骤降先别急着查服务器用开发工具抓一下客户端的IP变化频率基本一眼就能看出是不是解析结果抖动导致的。5.3 问题三HTTPS证书校验和IP直连打架当客户端拿到HTTPDNS返回的IP后Socket连接的是IP地址但TLS握手时服务器返回的证书里绑定的域名是原始域名比如api.example.com。如果客户端在做证书校验时发现连接目标是IP而不是域名就可能出现证书域名不匹配的错误。解决方案有两种。第一种客户端在校验证书时手动指定SNIServer Name Indication也就是在TLS握手时显式声明域名。业界标准做法是连接建立的IP用HTTPDNS返回的地址但SNI和Host头都用原始域名。第二如果内部测试环境证书管理混乱建议先做一层IP和域名的绑定关系配置让测试环境走特殊通道避免证书问题干扰主流程开发。这个问题在技术排查时特别容易误导人。我见过有团队排查了一整天TLS握手失败问题最后发现是证书域名匹配问题——不是服务端挂了不是网络中断就是客户端校验逻辑太严格。5.4 问题四HTTPDNS服务器本身被攻击怎么办HTTPDNS服务器是核心基础服务也是被攻击的高价值目标。一旦被DDoS攻击打瘫影响的是全量用户。自研方案在这个层面必须做几层防护。首先接入层要部署在多个地域和多个云服务提供商形成跨云容灾。其次要对每个客户端的解析请求做限流单IP每秒超过阈值直接拒绝。另外在服务器端要建立一套实时监控系统监控指标包括解析成功率、解析耗时、返回结果的一致性、以及异常请求特征。攻击发生时通过排查特征库自动阻断异常流量而不是等人力介入。我在项目中就吃过一次亏。某个晚间流量高峰期一组HTTPDNS集群突然收到大量来自随机IP地址的解析请求每个请求的域名都是随机生成的。由于当时没有对未知域名的过滤策略导致后端数据库压力飙升部分正常请求被排队处理。后来加了一层严格的“已知域名白名单”过滤这个问题彻底解决了。6. 自研HTTPDNS的边界和适用场景思考讲了很多技术细节最后想聊聊边界。HTTPDNS不是一个万能解药落到不同体量的业务上是否应该自研、以及自研到多深答案是不一样的。6.1 什么情况下适合自研如果业务体量已经达到日活千万级别以上并且对解析调度的精准度有极高要求或者面临的黑灰产攻击压力大到外部服务无法兜底那自研是有充分理由的。典型特征包括业务依赖大量CDN节点、需要精细的地域流量调度能力、已有成熟的内部基础设施团队。另外如果业务所在的行业对数据合规要求极高域名解析记录本身就是敏感数据的一部分那自研带来的数据可控性就非常重要。这种情况下不只是自研HTTPDNS整个DNS链路包括日志留存、访问审计、加密策略都需要自己掌控。6.2 什么时候建议先用第三方服务如果业务还处在快速增长期或者团队规模有限我更建议先在成熟的第三方HTTPDNS服务上跑通业务场景把精力聚焦在App本身的业务功能上。等用户的日均解析量到了千万级别再评估自研的投入产出比这个节奏是最稳的。毕竟HTTPDNS只是整个网络加速和安全体系里的一环真正有价值的是与之配合的智能调度、性能监控、故障自愈这些整体能力。团队资源有限时先解决最痛的问题比追求大而全的基础设施更实在。6.3 未来HTTPDNS的趋势加密化和内嵌化从目前的技术趋势来看HTTPDNS会往两个方向演进。一个是彻底加密化以杜绝任何形式的数据泄露风险。现在行业内已经有基于HTTPS的双向认证方案客户端不仅校验服务端证书服务端也校验客户端证书这个做法在安全性上又上了一个台阶。另一个是内嵌化把HTTPDNS的能力下沉到网络基础设施层面让App的网络框架在底层就支持而不是在每个业务方都要做一层侵入式的SDK改造。我在实际开发中最大的体会是HTTPDNS的本质不是“换个DNS服务器”而是把网络解析这件事从一个不可控的黑盒变成了一个可以编程控制的白盒。这个转变带来的价值远不止防劫持那么简单——它让应用层第一次有了对网络路径的发言权。如果你正在调研或者准备落地HTTPDNS我的建议是先从一个小范围的核心域名做起做好监控和对比数据用数据说服团队和业务方。等看到首屏加载时间下降、地域性超时问题减少之后你自然会明白大厂们为什么舍得在这件事上投入那么大的研发成本。
