dns延时高怎么办（dns耽误 多少ms算正常）〔dns延迟高〕

（点击上方公众号 ，可快速关注）

　　泉源 ：hrchen（@dr_hrchen）

　　链接：https://www.jianshu.com/p/3c1941acbd79

　　App网络服务的高可靠和低耽误 对于无线业务稳固 发展至关紧张 ，已往 两年来我们不停 在连续 优化App网络服务的性能，到本年 Q2竣事 时根本 完成了App网络服务通道管理 和性能优化的阶段性目标 ，特此撰文总结此中 的履历 教导 ，为以后的工作打下底子 。

　　携程App无线网络服务架构

　　2014年携程为无线服务开辟 了Mobile Gateway，有两种范例 ：TCP Gateway和HTTP Gateway 。 TCP Gateway计划 用于App中Native业务网络服务，基于TCP协议之上计划 了应用层协议 ，雷同 于RPC机制。TCP Gateway兼具了接入层和服务动态路由的功能，接入层的功能基于Netty实现，管理客户端的TCP长毗连 大概 短毗连 ；动态路由的功能基于Netfix开源的Zuul实现（Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security, and more. ） ，可以在TCP Gateway上实现服务路由 、监控、反爬和用户鉴权等功能。

TCP Gateway

　　每个TCP服务哀求 到达TCP Gateway之后，会根据报文头中的服务号，转发到后端对应的业务服务集群上 ，从而实现后端服务的解耦。TCP Gateway到后端业务服务集群之间的转发利用 HTTP协议的接口情势 实现，一个TCP服务哀求 的完备 报文会作为HTTP哀求 的Payload转发到后端业务服务集群，吸取 到HTTP相应 后 ，会将其Payload完备 的返回到对应的TCP毗连 中 。

　　HTTP Gateway用于App中Hybrid和H5 Web站点的网络服务，采取 HTTP Restful接口情势 提供服务，其逻辑相对简单 ，核心 是HTTP服务动态转发的功能。

HTTP Gateway

　　Mobile Gateway的更多计划 实现细节可以参考王兴朝同砚 在2015上海QCon的演讲《携程无线Gateway》。

　　基于TCP协议实现App网络服务

　　带宽和耽误 是影响网络服务性能的两个因素 ，带宽受网络通道上最小带宽的网段限定 ，耽误 是网络包在客户端和服务端之间的来回 传输时长，差别 网络范例 上的带宽和耽误 差别 非常大（见下图） 。

带宽和耽误

　　我们要实现更好性能的网络服务 ，对于网络自身的带宽和耽误 这两点而言，能做只是尽大概 选择最符合 的网络通道，其他只能在怎样 利用 网络通道上举行 优化。

　　传统的非IM即时消息类App通常都是利用 HTTP协议来实现网络服务的（Restful API情势 ） ，携程利用 TCP协议来实现，确实会增长 很多 开辟 本钱 ，比方 必要 计划 应用层协议、管理网络毗连 、处理 惩罚 非常 等 ，但下面几点缘故起因 还是 让我们终极 选择基于TCP协议来实现App网络服务：

携程用户偶然 会在网络环境 非常差的景区利用 ，必要 针对弱网举行 特别 的优化，单纯HTTP应用层协议很难实现。

HTTP哀求 初次 必要 举行 DNS域名分析 ，我们发现国底细 况 下针对携程域名的失败率在2-3%（包罗 域名挟制 息争 析失败的环境 ），严峻 影响用户体验 。

HTTP固然 是基于TCP协议实现的应用层协议，上风 是封装性好，客户端和服务端办理 方案成熟。劣势是可控性小 ，无法针对网络毗连 、发送哀求 和吸取 相应 做定制性的优化，纵然 是HTTP的特性如保持长毗连 KeepAlive大概 管道Pipeline等都会受制于网络环境 中的Proxy大概 服务端实现，很难充实 发挥作用。

　　基于TCP协议实现可以让我们可以或许 完备 控制整个网络服务生命周期的各个阶段 ，包罗 如下几个阶段：

　　1. 获取服务端IP地点

　　2. 创建 毗连

　　3. 序列化网络哀求 报文

　　4. 发送网络哀求

　　5. 担当 网络相应

　　6. 反序列化网络相应 报文

　　我们的网络服务通道管理 和优化工作就是从这几个方面睁开 的 。

　　TCP网络服务通道管理 和性能优化

　　1. 告别DNS，直接利用 IP地点

　　假如 是初次 发送基于HTTP协议的网路服务，第一件事就是举行 DNS域名分析 ，我们统计过DNS分析 乐成 率只有98%，剩下2%是分析 失败大概 运营商DNS挟制 （Local DNS返回了非源站IP地点 ），同时DNS分析 在3G下耗时200毫秒左右 ，4G也有100毫秒左右，耽误 显着 。我们基于TCP毗连 ，直接跳过了DNS分析 阶段 ，利用 内置IP列表的方式举行 网络毗连 。

　　携程App内置了一组Server IP列表，同时每个IP具备权重 。每次创建 新毗连 ，会选择权重最高的IP地点 举行 毗连 。App启动时，IP列表的全部 权重是雷同 的 ，此时会启动一组Ping的操纵 ，根据Ping值的耽误 时间来盘算 IP的权重，这么做的原理是Ping值越小的IP地点 ，毗连 后的网络传输耽误 也应该相对更小。业界也有利用 HTTP DNS方式来办理 DNS挟制 题目 ，同时返回最符合 用户网络的Server IP。然而HTTP DNS的开辟 和摆设 必要 不小的开辟 本钱 ，我们如今 没有利用 。

　　内置Server IP列表也会被更新 ，每次App启动后会有个Mobile Config服务（支持TCP和HTTP两种网络范例 服务）更新Server IP列表，同时支持差别 产物 线的Server IP列表更新。因此，传统DNS分析 可以或许 办理 多IDC导流的功能也可以通过此方法办理 。

　　2. Socket毗连 优化 ，镌汰 毗连 时间

　　和HTTP协议中的Keepalive特性一样，最直接镌汰 网络服务时间的优化本领 就是保持长毗连 。每次TCP三次握手毗连 必要 淹灭 客户端和服务端各一个RTT（Round trip time）时间才华 完成，就意味着100-300毫秒的耽误 ；TCP协议自身应对网络拥塞的Slow Start机制也会影响新毗连 的传输性能。

　　携程App利用 了长毗连 池的方式来利用 长毗连 ，长毗连 池中维护了多个保持和服务端的TCP毗连 ，每次网络服务发起后会从长毗连 池中获取一个空闲长毗连 ，完成网络服务后再将该TCP毗连 放回长毗连 池。我们没有在单个TCP毗连 上实现Pipeline和Multiplexing机制，而是采取 最简单 的FIFO机制 ，缘故起因 有二：1. 简化Mobile Gateway的服务处理 惩罚 逻辑，镌汰 开辟 本钱 ；2. 在服务端同时返回多个相应 时，假如 某个相应 报文非常大 ，利用 多个长毗连 方式可以加快 吸取 服务相应 报文速率 。

　　假如 发起网络服务时长毗连 池中的TCP毗连 都正在被占用，大概 TCP长毗连 的网络服务失败，则会发起一个TCP短毗连 实现网络服务。这里长毗连 和短毗连 的区别仅仅是服务完成后是否直接关闭这个TCP毗连 。

　　附：Pipeline和Multiplexing是有区别的 ，如HTTP/1.1支持Pipeline，客户端可否 同时发送多个哀求 ，但是服务端返反响 应时也要按照哀求 的发送序次 来返反响 应；SPDY和HTTP/2协议支持Multiplexing ，即支持相应 报文的乱序返回，发送哀求 和吸取 相应 互不干扰，因此克制 了HTTP/1.1 Pipeline也没能完全办理 的Head of line blocking题目 。参考资料：1,2。参考资历2中提到HTTP/1.1的Pipeline特性只是部分 办理 了Head of line blocking题目 ，由于 a large or slow response can still block others behind it。

　　3. 弱网和网络抖动优化

　　携程App引入了网络质量参数，通过网络范例 和端到端Ping值举行 盘算 ，根据差别 的网络质量改变网络服务战略 ：

　　调解 长毗连 池个数：比方 在2G/2.5G Egde网络下，会镌汰 长毗连 池个数为1（运营商会限定 单个目标 IP的TCP毗连 个数）；WIFI网络下可以增长 长毗连 池个数等机制 。

　　动态调解 TCP connection、write、read的超时时间。

　　网络范例 切换时 ，比方 WIFI和移动网络 、4G/3G切换至2G时，客户端IP地点 会发生变革 ，已经毗连 上的TCP Socket注定已经失效（每个Socket对应一个四元组：源IP、源Port、目标 IP 、目标 Port） ，此时会主动 关闭全部 空闲长毗连 ，现有网络服务也会根据状态主动 重试。

　　4. 数据格式优化，镌汰 数据传输量和序列化时间

　　传输数据量越小 ，在雷同 TCP毗连 上的传输时间越短。携程App曾经利用 自行计划 的一套数据格式，厥后 和Google ProtocolBuffer对比后发现，特定命 据范例 下数据包巨细 会低落 20-30% ，序列化和反序列化时间可以低落 10-20%，因此如今 核心 服务都在渐渐 迁徙 到到ProtocolBuffer格式 。别的 Facebook曾分享过他们利用 FlatBuffer数据格式进步 性能的实践，我们分析后不太得当 携程的业务场景因而没有利用 。

　　5. 引入重试机制 ，提拔 网络服务乐成 率

　　受TCP协议重传机制来包管 可靠传输的机制开导 ，我们在应用层面也引入了重试机制来进步 网络服务乐成 率。我们发现90%以上的的网络服务失败都是由于网络毗连 失败，此时再次重试是有机遇 毗连 乐成 并完成服务的；同时我们发现前面提到的网络服务生命周期处于1创建 毗连 、序列化网络哀求 报文、发送网络哀求 这三个阶段失败时，都是可以主动 重试的 ，由于 我们可以确信哀求 还没有到达 服务端举行 处理 惩罚 ，不会产生幂等性题目 （假如 存在幂等性题目 ，会出现重复订单等环境 ） 。当网络服务必要 重试时 ，会利用 短毗连 举行 补偿 ，而不再利用 长毗连 。

　　实现了上述机制后，携程App网络服务乐成 率由原先的95.3%+提拔 为如今 的99.5%+（这里的服务乐成 率是指端到端服务乐成 率 ，即客户端收罗 的服务乐成 数除以哀求 总量盘算 的，而且 不区分当前网络状态 ），结果 明显 。

　　6. 其他网络服务机制 Tricks

　　携程App也实现了其他一些网络服务机制方便业务开辟 ，如网络服务优先级机制，高优先级服务优先利用 长毗连 ，低优先级服务默认利用 短毗连 ；网络服务依靠 机制 ，根据依靠 关系主动 发起或取消网络服务，比方 主服务失败时，子服务主动 取消 。

　　开辟 过程中我们也发现一些移动平台上的TCP Socket开辟 tricks：

　　1. iOS平台上的原生Socket接口创建毗连 并不会激活移动网络，这里原生Socket接口是指POSIX Socket接口 ，必须利用 CFSocket大概 再上层的网络接口实行 网络毗连 时才会激活网络。因此携程App启动时会优先激活注册一些第三方SDK以及发送HTTP哀求 来激活移动网络。

　　2. 公道 设置Socket的几个参数：SO_KEEPALIVE参数确保TCP毗连 保持（注：此KeepAlive是TCP中的属性，和HTTP的KeepAlive是两个场景概念），SO_NOSIGPIPE参数关闭SIGPIPE变乱 ，TCP_NODELAY参数关闭TCP Nagle算法的影响 。

　　3. 由于iOS要求支持IPv6-Only网络，因此利用 原生Socket必须支持IPv6。

　　4. 假如 利用 select来处理 惩罚 nonblocking IO操纵 ，确保精确 处理 惩罚 差别 的返回值和超时参数。

　　5. 保持TCP长毗连 可用性的心跳机制：对于非IM类应用而言 ，心跳机制的作用不大，由于 用户会不绝 触发哀求 去利用 TCP毗连 ，尤其在携程业务场景下 ，通过数据统计发现利用 心跳与否对服务耗时和乐成 率影响极小，因此如今 已经关闭心跳机制 。原先的心跳机制是TCP长毗连 池中的空闲TCP毗连 每60秒发送一个心跳包到Gateway，Gateway返回一个心跳相应 包 ，从而让两边 确认TCP毗连 有效 。

　　Hybrid网络服务优化

　　携程App中有相称 比例的业务是利用 Hybrid技能 实现的，运行在WebView环境 中，此中 的全部 网络服务（HTTP哀求 ）都是由体系 控制的，我们无法掌控 ，也就无法举行 优化，其端到端服务乐成 率也仅有97%左右（注：这里指页面中业务逻辑发送的网络服务哀求 ，而非静态资源哀求 ）。

　　我们采取 了名为『TCP Tunnel for Hybrid』的技能 方案来优化Hybrid网络服务 ，和传统HTTP加快 产物 的方法差别 ，我们没有采取 拦截HTTP哀求 再转发的方式，而是在携程Hybrid框架中的网络服务层举行 主动 切换。

TCP Tunnel for Hybrid

　　如图所示 ，该技能 方案的流程如下：

　　1. 假如 App支持TCP Tunnel for Hybrid，Hybrid业务在发网络服务时，会通过Hybrid接口转发至App Native层的TCP网络通讯层 ，该模块会封装这个HTTP哀求 ，作为TCP网络服务的Payload转发到TCP Gateway；

　　2. TCP Gateway会根据服务号判定 出是Hybrid转发服务，解包后将Payload直接转发至HTTP Gateway ，此HTTP哀求 对HTTP Gateway是透明的，HTTP Gateway无需区分是App直接发来的还是 TCP Gateway转发来的HTTP哀求 ；

　　3. 后端业务服务处理 惩罚 完成后，HTTP相应 会经HTTP Gateway返回给TCP Gateway，TCP Gateway将此HTTP相应 作为Payload返回给App的TCP网络通讯层；

　　4. TCP网络通讯层会再将该Payload反序列化后返回给Hybrid框架 ，终极 异步回调给Hybrid业务调用方 。整个过程对于Hybrid业务调用方也是透明的，它并不知道TCP Tunnel的存在。

　　采取 该技能 方案后，携程App中Hybrid业务的网络服务乐成 率提拔 至99%以上 ，均匀 耗时降落 了30%

TCP Tunnel for Hybrid Result

　　外洋 网络服务优化

　　携程如今 没有摆设 外洋 IDC，外洋 用户在利用 App时必要 访问位于国内的IDC，服务均匀 耗时显着 高于国内用户。我们采取 了名为『TCP Bypass for Oversea』的技能 方案来优化外洋 网络服务性能 ，重要 是利用 了Akamai的外洋 专属网络通道，同时在携程国内IDC摆设 了局端装备 ，利用 专用加快 通道的方式来提拔 外洋 用户体验 。

TCP Bypass for Oversea

　　外洋 用户启动App后先通过Akamai定制域名获取Server IP ，全部 网络服务优先走Akamai通道；假如 Akamai通道的网络服务失败而且 重试机制见效 时，会改走传统Internet通道举行 重试。相比只用传统Internet通道，在保持网络服务乐成 率稳固 的环境 下 ，利用 Akamai通道Bypass技能 后均匀 服务耗时降落 了33%。

TCP Bypass for Oversea Result

　　其他网络协议探究

　　已往 两年我们的网络服务优化工作都是基于TCP协议实现的，根本 到达 了优化目标 。不外 这两年来新的应用层网络协议SPDY和HTTP/2渐渐 迈入主流，基于UDP的QUIC协议看起来也非常风趣 ，值得跟进调研。

　　SPDY HTTP/2

　　SPDY是Google基于TCP开辟 的网络应用层协议 ，如今 已经克制 开辟 ，转向支持基于SPDY结果 计划 的HTTP/2协议，HTTP/2协议的核心 改进着实 就是针对HTTP/1.x中影响耽误 性能的痛点举行 优化：

　　1. Header压缩：压缩冗余的HTTP哀求 和相应 Header。

　　2. 支持Multiplexing：支持一个TCP毗连 上同时实现多个哀求 和相应 。

　　3. 保持长毗连 （比HTTP/1.x更彻底）：镌汰 网络毗连 时间。

　　4. 支持推送：可以由服务端主动 推送数据到客户端。

　　官方性能测试结果 表现 利用 SPDY大概 HTTP/2的页面加载时间镌汰 30%左右 ，不外 这是针对网页的测试结果 ，对于App中的网络服务，具体 优化结果 我们还在举行 内部测试 ，不外 其优化本领 看和如今 我们利用 TCP协议的优化本领 雷同 ，因此性能优化结果 大概 不会很明显 。

　　QUIC

　　QUIC是Google基于UDP开辟 的应用层协议，UDP协议无需毗连 ，不存在重传机制，因此应用层必要 包管 服务的可靠性。如今 国内腾讯有针对弱网络实行 过QUIC协议，我们也在举行 测试 ，终极 是否会采取 还必要 看测试的结果 。

　　综述

　　技能 只是本领 ，终极 还是 要反映在业务结果 上。我们已经实现除静态资源等必要 访问CDN的网络哀求 外，其他App网络服务利用 同一 的TCP通道，从而具备更好的性能调优和业务监控本领 。携程如今 基于TCP协议的各种App网络服务优化 ，也是各种技能 方案的均衡 ，固然 如今 HTTP/2等新协议渐渐 成熟，但是TCP协议自身的机动 性支持有针对性的性能优化 ，还是 具备其特别 的上风 ，盼望 我们的实践总结能对国内无线技能 从业者有一些鉴戒 代价 。

【本日 微信公号保举 ↓】

更多保举 请看《值得关注的技能 和计划 公众号》

　　此中 保举 了包罗 技能 、计划 、极客 和 IT相亲相干 的热门公众号。技能 涵盖：Python、Web前端 、Java、安卓、iOS、PHP 、C/C++、.NET、Linux 、数据库、运维、大数据 、算法、IT职场等 。点击《值得关注的技能 和计划 公众号》，发现出色 ！