德泰_高分内容_个人页_阿里云开发者社区

发表了文章 2018-02-24

基于阿里云移动推送的移动应用推送模式最佳实践

一、概念以下概念对应系统设计时的语义，对于如何合理使用移动推送有借鉴意义 1.1 设备安装并使用开发者移动应用的装置 1.2 设备ID 阿里云移动推送为设备分配的唯一ID，可以通过阿里云移动推送SDK端提供的接口获取 1.3 账号使用开发者开发应用的终端用户账号，以手淘为例，这个的账号指的是终端用户的淘宝账号 1.4 标签终端用户的属性标识，用于对用户进行分组 1.5 别名设备（及使用设备的用户）的昵称二、关联关系和限制 2.1 deviceID 与设备一一对应，阿里云移动推送系统自动分配，通过接口获取 2.2 账号与deviceID一一对应，对于同一设备切换账号的场景，通过重新绑定账号实现 2.3 别名一个deviceID可以对应多个别名别名是用户粒度的概念，建议用于单推的场景 2.4 标签一个deviceID可以对应多个标签，一个标签也可以对应多个deviceID 三、推送模式最佳实践 3.1 单推向指定设备推送，可以通过向指定的deviceID、账号、别名推送实现 deviceID是阿里云移动推送系统为设备分配的ID号，默认只存储在推送SDK和阿里云后台，这个ID除标识作用外没有特殊的意义，一般开发者推送管理平台无需存储该ID 账号、别名都是开发者设置的ID信息，开发者的推送管理系统中保存有相关的信息和关联关系，易于管理和维护。别名推送在单推场景下的几种常见使用方法：对单个用户的别名进行推送以教育类App的一种常见场景为例：某学生进入校园，需要向家长推送一条消息，此时为注册的家长添加一个别名，并通过别名推送。多渠道统一管理 Android系统碎片化比较严重，App往往需要接入多种推送渠道，此时不同渠道可以使用统一的别名，简化推送系统的管理复杂度非登录状态推送部分App用户支持非登录状态使用，这种情况下无法使用账号推送功能，可以通过为该终端用户绑定别名，并使用别名推送，来实现向非登录状态用户推送消息的目标 3.2 组推向一组用户推送消息建议使用标签推送 3.3 全推向全体用户推送使用全量推送模式

发表了文章 2018-02-24

移动推送消息送达常见问题与解决办法

一、收到重复的推送内容收到重复的推送内容，排除了业务自身的推送逻辑之外，重点介绍一下部分机型多渠道推送可能带来的重复推送问题。对于Android系统，对于设备已经在某些三方系统中注册过，并且通过该三方推送接入了厂商ROM通道，会出现重复推送的问题，原因是：三方推送接口功能开放不足 SDK中未提供停止推送的接口服务端未提供历史设备清理接口，导致三方推送后台仍然将这些设备保留在推送列表中这种情况下，如果同时对阿里云推送和三方推送通道推送消息，即使新版本App没有集成三方推送的SDK，也会导致收到重复的内容对于iOS系统，由于APNS也是ROM级的推送通道，对于没有提供停止推送接口，也没有提供历史设备清理接口的三方推送，也会收到重复推送内容解决办法请有问题的三方厂商提供SDK端停止推送接口，并在新版本App中调用停止推送接口请有问题的三方厂商提供历史设备清理接口，将不需要推送的设备清理掉 App升级完成后，停止向有问题的三方厂商推送二、收不到推送内容 Android系统由于系统ROM的限制，无法确保消息一定送达，对于无法送达的情况，常见的改进方法有：对于华为、小米等机型，接入辅助通道设置合理的离线消息存储时间使用移动推送的短信复合推送功能对于其他异常情况 Android推送失败排查方法

发表了文章 2017-03-11

视频直播推流拉流慢、卡顿解决方案

一、摘要视频直播类App当前已经普遍采用CDN来实现访问加速，但还是经常遇到推拉流慢、卡顿的问题。这类问题一般是由于调度不精准、域名劫持、终端手机接入网络动态切换等因素导致，结合使用CDN和HTTPDNS可以比较完美解决此类问题。二、视频直播经典加速架构当前视频直播类App经典加速架构如下图所示：图1 视频直播类App经典加速架构经典加速架构中，推流阶段使用CDN就近接入实现推流加速，用户播放拉流阶段也可以使用CDN来做加速。由于CDN节点分布的广泛性与边缘性确保了客户能够就近接入与缓存。同直连源站相比，通过CDN加速直播推拉流取得了非常显著的加速效果。三、经典架构中存在的问题尽管已经采用了CDN加速，直播类App仍然经常出现访问慢、卡顿等问题，导致大量用户投诉，其主要原因是当前架构中存在以下几方面问题： 3.1 运营商Local DNS配置不合理导致无法就近接入关于这个问题的描述参考文章App如何实现就近接入？如何改善调度不准问题？，那些年移动App域名解析踩过的坑，移动互联网时代，如何优化你的网络 —— 域名解析篇。 3.2 域名劫持关于这个问题可以参考文章域名劫持与防范，那些年移动App域名解析踩过的坑，移动互联网时代，如何优化你的网络 —— 域名解析篇。 3.3 用户手机网络制式切换假设用户A从移动4G切换到家中联通的wifi网络，仍然按照原先的CDN节点进行加速会出现跨ISP调度，访问质量差的悲剧事件。四、解决办法 HTTPDNS + CDN 上述3个问题都可以通过接入HTTPDNS解决。解决方案1: 终端源站配合的解决方案图2 终端源站配合使用HTTPDNS的解决方案下面通过推流阶段2个场景说明改进方案如何确保调度到最佳CDN节点： case 1： Local DNS配置问题导致没有调度到最优节点的场景 Step 1：用户手机上Local DNS配置不准确，域名解析阶段为域名dn返回的是CDN节点B的IP_b，而非最优的CDN节点IP IP_a。 Step 2：推流的终端应用需要向CDN节点发起鉴权请求，CDN节点在收到鉴权请求后，需要提取终端的公网IP_c，然后除了转发鉴权相关信息到视频源站之外，还必须带上推流终端的公网IP_c 给源站。 Step 3：源站收到鉴权信息和终端IP后，首先做鉴权工作，然后源站利用推流的域名dn和推流终端公网IP IP_c向HTTPDNS服务器发起请求，获取最优的CDN节点IP_a，并将IP_a回传给推流终端，告知推流终端IP_a是最佳接入节点 Step 4：终端推流时可以直接向CDN IP_a推流，或者等到发现出现卡顿、慢时切换到IP_a case 2：用户网络制式切换（如移动4G切联通wifi）的场景 Step 1：假设之前移动4G网络下最佳CDN节点是IP_b，用户网络制式切换成联通wifi后，最佳节点换成了IP_a。网络切换后，终端第一步仍然向CDN节点IP_b推流，此时会鉴权失败。 Step 2：重复场景1的Step 2到Step 4，推流终端最终可以找到最佳CDN节点IP_a并通过IP_a推流。解决方案2：轻服务端解决方案图3 完全基于终端调用HTTPDNS的方案本方案非常清晰，当推流或者拉流出现服务质量问题（如慢、卡顿）时，立即使用HTTPDNS获取最新的最佳服务质量节点，并利用最新的节点进行推拉流。另外，首次选用接入哪个CDN节点时也建议使用HTTPDNS来解析决定。其他要点请注意，用户网络制式切换时，本架构能够自动找出最优节点并顺利切换到最优节点。其他因调度问题导致拉流、推流阶段慢、卡顿的问题都可以通过上述方案解决。五、总结视频直播类App经常遇到播放质量不佳、慢、卡顿等问题，会引起客户投诉和流失，使用HTTPDNS可以较好解决这类问题。六、附录阿里云HTTPDNS六大优势： 1、支持全网域名解析接口简单统一无需对接多家HTTPDNS 2、以IP方式对外提供服务，防止自身被劫持 3、AnyCast IP支持异地容灾各地域使用同一个IP地址提供服务 4、接入延迟低且稳定以北京为例，测试一下阿里云HTTPDNS的访问延迟：图4 阿里云HTTPDNS服务器RTT延迟5、支持https接口 6、提供Android SDK/iOS SDK，方便接入

发表了文章 2017-03-08

那些年移动App域名解析踩过的坑

一、摘要移动应用出现域名劫持、解析结果修改生效慢、跨运营商跨地域访问问题？阿里云HTTPDNS可以解决这类问题。二、域名解析阿喀琉斯之踵域名解析是终端设备访问互联网的第一步，扮演着至关重要的角色。同时，域名解析服务是当前整个互联网基础设施中最脆弱的几个环节之一。移动互联网时代，由于接入智能终端数量激增，问题愈加严重。案例1：域名解析问题导致访问流量减半 2017年2月24日21:20-2月25日1:00之间，某App A在江苏省某ISP访问流量减半，排查后发现为递归DNS故障导致。图1 递归DNS故障导致业务访问受害如图1所示，正常访问期间，App业务访问大致分为四步： Step 1： App发起业务域名解析 Step 2：递归DNS返回域名解析结果IP Step 3： App根据返回的IP向业务服务器发起请求 Step 4：业务服务器返回响应，交互结束。故障发生时，递归DNS在第二步无法返回解析结果或者返回错误的结果，导致App无法正确获取业务服务器的IP，最终业务访问受到巨大影响。案例2：域名解析结果修改不生效导致流量无法迁移 2016年11月中旬，由于某App B访问的节点存在服务质量方面问题，计划通过修改域名解析记录将流量切走，但由于域名解析不生效，导致流量无法调走，最终4个小时后节点服务质量恢复了业务才回归正常。图2 域名解析不生效的恶果如图2所示，正常访问期间，App业务访问的细化步骤可以分解成六步： Step 1： App发起业务域名解析 Step 2：递归DNS向权威DNS发起域名解析结果 Step 3：权威DNS返回域名对应的IP给递归DNS Step 4：递归DNS给App返回域名解析结果 Step 5： App根据返回的IP向业务服务器发起请求 Step 6：业务服务器返回响应，交互结束。故障发生时，尽管权威DNS的解析记录已经修改，但递归DNS的解析结果却没有任何变化（常见原因是递归DNS不遵循返回结果的TTL，私自设置缓存时间），仍然返回之前的结果，导致了故障的发生。案例3：不能碰的递归DNS节点 2011年，某公司流量峰值期间，运维人员计划通过修改CDN的智能DNS系统配置将某一地区的部分流量从负载高的CDN节点到相对流量小的CDN节点去。实施过程中，发现某一个DNS IP对应的流量到达5G+，无法实现“调部分流量”的目标。案例4：客户端调度不准客户反馈的服务质量问题往往是由于调度不准确导致的。参见以下案例。图3 手机DNS配置不准导致跨ISP跨地域访问根据IP地址来判断，案例中的用户位于武汉联通，而递归DNS却配置成了上海电信的DNS服务器，导致最终调度系统会按照上海电信区域来做就近接入，出现了跨运营商、跨地域访问问题。三、问题溯源 3.1 域名劫持问题现网上DNS解析一般基于UDP来实现，由于UDP自身的脆弱性，很容易被劫持。图4 域名劫持原理根据多种渠道统计数据，国内现网的周劫持率在3%-5%左右（对于某一个业务，一周之内曾经被劫持过的用户占比），部分地区部分时段的劫持率超过20%。基于国内严重的流量劫持情况，腾讯、小米等六公司与2015年底联合声明抵制流量劫持等违法行为，但当前的形式仍不容乐观。域名劫持的危害性在于隐蔽性强、品牌伤害严重、解决难度大。隐蔽性强。劫持偶发，难以复现，举证难。品牌伤害严重。劫持后往往弹出涉黄、涉赌等内容，严重伤害应用品牌。解决难度大。确认域名劫持后，一般开发者没有渠道去解决问题。 3.2 递归DNS数量少且分布不均导致无法就近接入在国内，递归DNS数量较少且分布不均。据统计，top 200的递归DNS承担国内90%+的DNS访问流量。这样少的递归DNS是无法承载就近接入需求的。 3.3 终端手机的Local DNS配置错误导致无法就近接入上节的案例4就是典型的递归服务器配置错误导致的就近接入问题。四、阿里云飞天的解决之道 4.1 小工具大本领：HTTPDNS HTTPDNS原理图5 HTTPDNS服务原理如图5所示，HTTPDNS与传统的DNS对比起来，有以下几项功能：使用HTTP协议进行域名解析，极大增强了域名解析的安全性绕过了递归DNS服务器，最大限度防止域名劫持的发生 HTTPDNS服务自身利用IP地址而非域名对外提供服务，防止HTTPDNS自身域名被劫持 HTTPDNS想权威请求解析结果时，使用客户端IP进行解析 HTTPDNS优势零劫持域名解析结果修改秒级生效零延迟解析基于手机IP就近接入支持https接口批量域名解析接口 Android/iOS SDK 4.2 适用对象有自己App的开发者，并且需要一定的App编码能力（接入HTTPDNS必须修改App源码）。 4.3 如何使用 Step 1：开通HTTPDNS Step 2：到HTTPDNS产品控制台配置待解析域名 Step 3：通过Android/iOS SDK或者HTTP API将App接入HTTPDNS服务请参见HTTPDNS的帮助文档五、案例手机淘宝、支付宝钱包等阿里系App都已经接入HTTPDNS产品，治愈了上面提到的一系列顽疾。案例中App B尝试接入阿里云飞天HTTPDNS后，在2017年2月24日的故障中，新版本未受任何影响，老版本则遇到了App A类似的问题。

发表了文章 2017-02-15

移动应用低成本消息推送的正确姿势

一、移动App消息推送的分类 1.1、应用内消息推送应用内消息推送基于App自身的功能实现消息推送，一般以消息弹框形式展现。 1.2、短信推送短信推送基于服务商提供的短信接口和短信通道实现推送，展现形式与普通短信一致。 1.3、两种推送方式对比方式名称载体接入方式查看方式应用内推送 App自身 App嵌入SDK，开发者调用推送的API推送消息唤起App 短信推送短信开发者调用服务商提供的接口推送消息查看短信二、推送的正确姿势简单说来，必须送达用户的消息建议用短信，其他消息建议用应用内推送。 2.1 消息必达的场景使用短信推送应用内推送受制于应用的活跃程度、Android系统的碎片化与ROM自身的限制，无法确保消息100%送达用户，因此对于到达率要求很高的场景，建议使用短信推送。对到达率要求高的典型场景有：用户注册登陆认证密码找回动账信息 2.2 其他场景使用应用内消息推送对于到达率没有特殊要求的场景，建议使用应用内消息推送。典型的场景有：商品折扣消息营销活动消息非关键性通知实时新闻推送三、App内消息推送/短信推送组合方案的优势与消息推送全部使用短信服务比较起来，组合使用App内消息推送/短信推送的优势体现在成本、转化率和用户体验三个方面。 3.1、成本优势某O2O类型App，月活200万。App平均每个月向每个用户发送20条推广消息，两者使用的成本如下：注这里的应用内推送成本使用阿里云移动推送的官网价格为例来说明推送方式月活设备数月推送条数月付费价格(元) 短信推送 2,000,000 40,000,000 2,000,000 App推送 2,000,000 40,000,000 40,000 可以看出，对于上面的案例，移动推送可以帮助客户节省支出196万/月。 3.2、转化率优势应用内推送支持根据客户标签、别名进行推送，可以实现精准营销，提升转化率应用内推送支持客户查看/删除等状态的详细跟踪，有利于后续的二次跟进营销策略应用内推送增加客户对品牌的认知，更加方便操作，进一步提升了转化率 3.3、用户体验优势同上节描述因素一致，App内推送终端用户体验大幅提升，非常有利于App的推广和品牌运营。四、App内推送/短信推送的技术选型 4.1 应用内消息推送选型方法 4.1.1 到达率到达率 = 实际触达终端用户数/目标终端用户数 4.1.2 推送延迟推送延迟 = 终端用户收到消息的时间 - 开发者调用推送接口时间 4.2.3 系统支撑能力系统每秒支持推送的消息数系统支撑的推送用户量级阿里云移动推送服务了手机淘宝、UC浏览器、高德、天猫、大姨吗等一大批超级App，另外，阿里云移动推送在到达率、推送延迟、系统容量等方面有非常显著的优势。阿里云短信服务是阿里云为用户提供的一款通信服务产品，支持快速发送短信验证码、短信通知等。完美支撑双11期间2亿用户，发送6亿短信。三网合一专属通道，与工信部携号转网平台实时互联。电信级运维保障，实时监控自动切换，到达率高达99%。五、附录 5.1 App内推送样例

发表了文章 2016-09-05

如何解决域名解析不生效问题？

一、前言域名解析不生效产生的原因很多，除了网络不可用，域名劫持(已有成熟解决办法)等因素之外，按照排查链路先后顺序列举如下： 1.1 域名状态是否正常先检查域名的状态，可以查看注册服务商提供的 whois 域名信息，如果域名状态为 clienthold 或 serverhold 状态，说明域名是被禁止解析的。这种状态下，即使设置了域名解析，也无法生效，域名无法被访问到，需要联系域名注册商取消这个状态。 1.2 权威修改是否已经修改生效请确认权威DNS的域名解析记录已修改成功。 1.3 递归DNS缓存记录是否已更新修改域名解析后，还取决于各运营商递归DNS的缓存是否生效。 1.4 客户端DNS缓存记录是否已更新客户端在老的解析记录TTL过期前无法更新。其中1.3，1.4是常见不生效原因，长时间无法生效大多由于1.3导致。二、域名解析不生效解决办法 2.1 通过递归DNS解决 2.1.1 方法一：使用HTTPDNS (1) HTTPDNS简介 HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务器，从而绕过运营商的Local DNS，能够解决Local DNS造成的域名劫持、调度不准确、域名解析不生效三方面问题，并且能够提升域名解析效率。 (2) HTTPDNS原理 HTTPDNS与传统的域名解析流程对比如下图所示。图一 HTTPDNS与传统DNS对比图 (3) HTTPDNS如何使用参见文档如何使用HTTPDNS (4)使用HTTPDNS有什么限制？ HTTPDNS需要修改应用的DNS解析过程，因此主要适用于C/S架构的场景。对于无法修改域名解析过程的场景，如PC浏览器访问、微信H5页面访问都无法使用HTTPDNS。 2.1.2 方法二：使用公共DNS 上面提到，由于ISP提供的递归域名服务器质量参差不齐，导致比较容易出现解析失败、解析不生效等问题，因此部分厂商提供了公共DNS解决这个问题。常见的公共dns有： DNS 服务器 IP 提供方名称提供方国家 8.8.8.8 google 美国 4.4.4.4 google 美国 223.5.5.5 阿里巴巴中国 223.6.6.6 阿里巴巴中国 114.114.114.114 114dns 中国 114.114.115.115 114dns 中国 2.1.3 两种方法优劣对比方法名实现简便程度通用性合计 HTTPDNS 7 7 14 公共DNS 9 1 10 备注：满分10分，分数越高说明方法优势越大对上面对比做一个说明：（1）HTTPDNS使用时需要开发者修改DNS解析流程，因此只适用于C/S架构的应用，对于PC浏览器、微信H5等场景不适用，程序编写也有一定的工作量，好在国内的HTTPDNS厂商都提供了封装好的SDK和示例代码供开发者使用和参考，大大降低了实现难度。（2）使用public dns的方法通用性很低，因为需要每个客户都对自己终端的DNS服务器配置进行修改，由于需要面向庞大的、水平参差不齐的终端用户，这种方式对于开发者而言实施难度非常大。 2.2 通过客户端自身解决对于客户端缓存结果不能更新的问题，可以通过强制刷新系统DNS缓存来删除老的解析结果。以windows系统为例，方法如下：打开windows命令行,执行ipconfig/flushdns命令清空DNS缓存图二 Windows系统情况DNS缓存方法示意图三、悲催的域名解析不生效问题尽管权威DNS系统属于变更相对较少的一个底层服务，但系统管理员可能还会在以下几种情况下变更DNS服务器的域名解析记录：（1）域名对应IP变更（替换、增加、减少等情况）（2）接入CDN系统，增加域名的CNAME记录（3）系统受到攻击时切换IP躲避攻击！！！（4）其他需要变更的情形修改解析记录后常见难题是：不生效图三域名解析不生效示意图下面首先看看域名解析的流程。四、域名解析过程分析以常见的递归解析方式为例，说明解析流程图四域名解析流程示意图上图是相对完整的域名解析流程（假设各个环节的缓存没有命中）： 1）用户终端发起域名解析请求www.abc.com 2）本地递归域名服务器向根域名服务器(.)请求并得到.com域名服务器的IP地址 3）本地递归域名服务器向.com域名服务器请求并得到abc.com权威域名服务器的地址 4）本地递归域名服务器向abc.com发出www.abc.com的解析请求并得到返回结果 5）用户终端从本地递归域名服务器得到最终的解析结果五、域名解析不生效根源 5.1 域名结果缓存环节分析域名解析不生效（生效慢）是由于域名解析结果被缓存住，并且缓存结果短时间无法更新导致的。域名解析可能在访问终端系统、本地递归域名解析服务器两个环节被缓存住，如下图所示。图五域名解析结果缓存环节分析示意图 5.2 终端缓存特征终端的缓存是由终端应用（如PC浏览器）控制的，一般情况下会遵循域名解析结果的TTL规范，也就是在域名有效期过期后会自动重新请求，因此这个时间是可预期的，也是可控的（通过修改权威TTL）。 5.3 递归域名服务器缓存特征本地递归域名服务器一般由提供服务的ISP设置，服务器自身也是由ISP维护，公网上存在大量的递归域名服务器不遵循权威的TTL，导致我们的域名解析修改不生效（全球生效时间最长可能有72小时之久）。由上面的分析可以知道，域名解析不生效最重要的诱因是递归域名服务器不能及时更新解析结果。六： TIPS 耐心看到这里的读者必须予以奖励，这里提供几个域名解析的几个TIPS。 6.1 域名解析从入门到中级看完这篇https://yq.aliyun.com/articles/58967就欧了。 6.2 无线场景下的域名服务器设置 Android/iOS在wifi接入场景下可以通过在系统的设置中找到修改DNS服务器的入口，但非wifi的网络制式接入（如2/3/4G网络）无法修改DNS服务器配置，因此当ISP为我们配置的默认递归域名服务器不合理时，就会碰到调度精确性的问题，这个问题可以参考移动场景下如何实现就近接入？ 6.3 黑科技：解析实时生效方法上面通过改进递归DNS设置（使用HTTPDNS或者配置公共DNS），可以确保域名解析结果在TTL过期后生效，但如果TTL设置时间较长（如10分钟），这时候我们仍然需要等待比较久的时间才能看到解析结果生效。有没有更好的办法？从第五节的分析来看，域名解析不生效的关键环节之一是递归DNS服务器缓存的域名解析结果需要等待TTL过期才会去权威更新，这个等待时间能否消除掉？答案是肯定的。如果权威解析记录修改后，能够同步更新递归DNS的缓存记录，就可以实现解析记录的实时生效。这种特性只能通过递归DNS和权威DNS配合才能实现，阿里云云解析即将发布支持解析记录修改实时生效的版本，敬请期待。 HTTPDNS产品页 HTTPDNS原理介绍 HTTPDNS快速开始云解析产品页

发表了文章 2016-06-17

HTTPDNS-信任的小船永不翻

1、背景时间 2016年6月2日地点人物和本少任务网易发表话题：如何同时和两位美女搭讪？在线等。知乎发表话题：和两位美女在马来古达海滩玩耍是什么样一种体验？结果网易无法访问，知乎也无法访问。然后，就没有然后了。意外发现阿里系的手淘、支付宝钱包、钉钉等基本都能访问通。 2、分析作为有尊严的程序员，我们不会放过任何一个Bug。知乎网易不可访问原因装上Surge，很快发现一众App不可访问的原因是本地DNS服务器不可用。 161002 <WARNING> [SGDNSClient-1] DNS query timeout: short.weixin.qq.com 161002 <WARNING> [SGDirectConnector-250] DNS failed: short.weixin.qq.com, DNS lookup failed: Timeout 161005 <WARNING> [SGDNSClient-1] DNS query timeout: g1.163.com 161005 <WARNING> [SGDNSClient-1] DNS query timeout: www.qchannel01.cn 161005 <WARNING> [SGDNSClient-1] DNS query timeout: api.weibo.com 161005 <WARNING> [SGDirectConnector-247] DNS failed: api.weibo.com, DNS lookup failed: Timeout 161005 <WARNING> [SGDNSClient-1] DNS query timeout: c.3g.163.com 161005 <WARNING> [SGDNSClient-1] DNS query timeout: pingma.qq.com 161005 <WARNING> [SGDirectConnector-255] DNS failed: pingma.qq.com, DNS lookup failed: Timeout 161008 <WARNING> [SGDNSClient-1] DNS query timeout: c.m.163.com 161013 <WARNING> [SGDNSClient-1] DNS query timeout: m.analytics.126.net 161013 <WARNING> [SGDNSClient-1] DNS query timeout: m.163.com 161013 <WARNING> [SGDNSClient-1] DNS query timeout: mmsns.qpic.cn 161013 <WARNING> [SGDirectConnector-251] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161013 <WARNING> [SGDirectConnector-252] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161013 <WARNING> [SGDirectConnector-253] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161013 <WARNING> [SGDirectConnector-254] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161020 <WARNING> [SGDNSClient-1] DNS query timeout: g1.163.com 161020 <WARNING> [SGDNSClient-1] DNS query timeout: www.qchannel01.cn 161020 <WARNING> [SGDNSClient-1] DNS query timeout: c.3g.163.com 161023 <WARNING> [SGDNSClient-1] DNS query timeout: c.m.163.com 161028 <WARNING> [SGDNSClient-1] DNS query timeout: m.163.com 161028 <WARNING> [SGDNSClient-1] DNS query timeout: mmsns.qpic.cn 161028 <WARNING> [SGDirectConnector-261] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161028 <WARNING> [SGDNSClient-1] DNS query timeout: m.analytics.126.net 161028 <WARNING> [SGDirectConnector-262] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161028 <WARNING> [SGDirectConnector-263] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 161028 <WARNING> [SGDirectConnector-264] DNS failed: mmsns.qpic.cn, DNS lookup failed: Timeout 阿里集团App基本不受影响原因阿里集团App整体上都接入了HTTPDNS，HTTPDNS旁路了运营商本地DNS服务器，因而避免了不可访问的问题。 HTTPDNS原理如下图所示： 3、总结 3.1、接入HTTPDNS，客户信任小船永不翻 HTTPDNS具有以下五大特性：域名防劫持精确调度零解析延迟降低解析失败率按时生效详细信息请参见阿里云HTTPDNS官网介绍

发表了文章 2016-05-22

App如何实现就近接入？如何改善调度不准问题？

一、常规DNS调度策略原理以CDN系统为例（其他业务系统大多采用类似的策略），来说明一下多地域部署服务如何实现用户访问请求调度的。 Step 1:客户端（假设IP地址为IP1）向Local DNS（假设IP地址为IP2）发出域名解析请求（假设请求的域名为www.taobao.com） Step 2:Local DNS代理客户端向权威服务器发起域名解析请求 Step 3：权威服务器根据域名(www.taobao.com)和IP2（对应的地域和ISP）进行调度并返回对应的解析结果。 Step 4: 客户端根据调度返回的IP发起业务访问请求。二、调度精确性问题 2.1 问题描述从上面的调度过程可以看出，业务系统会根据客户端的local dns IP来判断客户所处地域和运营商，并根据该地域和运营商来调度到就近的服务节点。可以看出，当客户的Local DNS与客户的地域和运营商不匹配时，此时按照Local DNS来调度就会出现调度不精确的问题。下面看几个来自客户的反馈（探测结果来自AliCDN昆仑探测工具）：探测的客户端IP和Local DNS IP以及对应的地域，运营商如下所示：客户端IP 220.249.84.** 220.249.84.** 客户端归属武汉联通武汉联通 Local DNS IP 183.61.13.** 222.73.134.** Local DNS 归属珠海电信上海电信很容易看出，Local DNS地域和运营商与客户端都不匹配，此时按照Local DNS IP调度会对用户体验造成非常大的影响（国内跨运营商的访问延迟和带宽都存在非常大的问题，相信大家有深刻体验）。 2.2 问题影响面根据我们的经验，影响的客户端占比在3%-7%之间。 2.3 原因无线场景下主要由于以下两个方面因素导致：（1）国内三大运营商Local DNS布点不足且不均匀，大量流量集中在2000个以内的Local DNS上，大的Local DNS对应的流量超过5Gb （2）很多手机（尤其是山寨机）Local DNS配置不准确如果扩展到全网（含有线访问请求），还需要考虑一个因素：（3）公共DNS（如google 8.8.8.8，阿里的223.5.5.5,223.6.6.6）导致调度系统无法识别Local DNS的具体位置。三、解决办法业界当前常见的解决思路都是通过获取客户端的IP来精确定位客户端地域和运营商，实现上，有三种方式：（1）HTTPDNS 客户端通过HTTP请求向httpdns服务器发出域名解析请求，此时httpdns服务器可以拿到客户端的精确IP，并基于客户端IP进行调度。（2）edns client subnet 通过dns包中加入客户端IP信息，使得DNS调度系统可以拿到客户端IP并进行调度。（3）http 302跳转当调度系统给出的调度结果不准确时，业务服务器仍然可以根据客户端IP来判断调度是否合理，并且在必要时通过302跳转来实现重定向进而实现精确调度。三种方式的优缺点对比如下：客户端修改 Local DNS修改权威DNS修改系统开销使用范围 HTTPDNS 有无低最广 edns client subnet 无需支持edns client subnet 需支持edns client subnet 低中等 http 302 有(需支持302跳转) 无高最差 HTTPDNS综合来看是最优的解决方案，当前阿里云已经推出了HTTPDNS商业化产品。

发表了文章 2016-03-23

流量劫持与防范

2015年12月15日，今日头条、美团大众点评网、360、腾讯、微博、小米科技六家公司发表联合声明，共同呼吁有关运营商严格打击流量劫持问题，重视互联网被流量劫持可能导致的严重后果。联合声明指出，在当前的移动互联网环境下，流量劫持主要分为两种方式：域名劫持和数据劫持，放任流量劫持会导致扰乱市场秩序、损害用户利益以及传播诈骗、色情等低俗甚至严重违法信息的恶果。而在2015年11月，上海浦东法院也刚刚对中国大陆地区首例流量劫持刑案作出判决，两名被告人被判有期徒刑三年，缓刑三年，扣押在案的作案工具以及没收退缴在案的违法所得。在此前的很长时间内，流量劫持行为并没有被定义为刑事犯罪，而随着浦东法院的判决、六大互联网公司联合声明的发出，流量劫持正在得到更大范围的关注。如何防范流量劫持正成为各家互联网公司的探讨重点。就此，记者联系了阿里云资深开发工程师亭林，请他介绍了流量劫持的技术原理以及相应的防范措施，精简分享如下。 -------------------------------------------------------------------------------------------------------------------- 相对于PC端的网络环境，移动端的网络环境更为复杂，2G、3G、4G、Wi-Fi各有不同，而复杂的网络环境也增加了流量劫持的可能性和复杂程度。流量劫持的方式主要分为两种，域名劫持和数据劫持。域名劫持是针对传统DNS解析的常见劫持方式。用户在浏览器输入网址，即发出一个HTTP请求，首先需要进行域名解析，得到业务服务器的IP地址。使用传统DNS解析时，会通过当地网络运营商提供的Local DNS解析得到结果。域名劫持，即是在请求Local DNS解析域名时出现问题，目标域名被恶意地解析到其他IP地址，造成用户无法正常使用服务。传统DNS解析流程解决域名劫持的一个办法就是绕开Local DNS，通过一个可信的源头来解析域名，解析方式不需要拘泥于DNS协议，也可以通过HTTP的方式。两年前，手机淘宝等APP也曾遇到这一问题，随后在做底层网络优化时，通过使用自己定制的HTTPDNS，一个安全可信的域名解析方案，解决了域名劫持问题。 HTTPDNS技术也准备通过阿里云平台开放给广大开发者使用，当前这款产品正在公测中，将于2016年3月29日提供商业化服务。到时，阿里云上的移动开发者也能自主选择，将需要防劫持的域名进行保护。数据劫持基本针对明文传输的内容发生。用户发起HTTP请求，服务器返回页面内容时，经过中间的运营商网络，页面内容被篡改或加塞内容，强行插入弹窗或者广告。行业内解决的办法即是对内容进行HTTPS加密，实现密文传输，彻底避免劫持问题。MD5校验同样能起到防止数据劫持的作用，MD5校验是指内容返回前，应用层对返回的数据进行校验，生成校验值；同时，内容接收方接收到内容后，也对内容进行校验，同样生成校验值，将这两个校验值进行比对，倘若一致，则可以判断数据无劫持。但相比HTTPS加密，MD5校验存在一定风险，劫持方技术能力强则有可能在篡改内容后替换校验值，导致接收方判断错误。使用HTTPS加密，已经成为了互联网行业的大势所趋。今年双11，阿里的淘宝、天猫、聚划算等电商平台也都全面实现了HTTPS加密访问，全站改造投入巨大，但有效防止了资源被劫持，保障了用户的收发信息安全。未来，这一技术将不仅限于电商平台，还将通过阿里云对外输出，赋能更多的中小互联网企业，降低他们的创业成本，在更安全的移动互联网环境中得到发展。立即试用阿里云 HTTPDNS。

德泰_个人页

个人介绍

擅长的技术

基于阿里云移动推送的移动应用推送模式最佳实践

移动推送消息送达常见问题与解决办法

视频直播推流拉流慢、卡顿解决方案

那些年移动App域名解析踩过的坑

移动应用低成本消息推送的正确姿势

如何解决域名解析不生效问题？

HTTPDNS-信任的小船永不翻

App如何实现就近接入？如何改善调度不准问题？

流量劫持与防范

基于阿里云移动推送的移动应用推送模式最佳实践

移动推送消息送达常见问题与解决办法

视频直播推流拉流慢、卡顿解决方案

那些年移动App域名解析踩过的坑

移动应用低成本消息推送的正确姿势

如何解决域名解析不生效问题？

HTTPDNS-信任的小船永不翻

App如何实现就近接入？如何改善调度不准问题？

流量劫持与防范

阿里百川移动推送

tag提问如何操作

德泰_个人页

个人介绍

擅长的技术

基于阿里云移动推送的移动应用推送模式最佳实践

移动推送消息送达常见问题与解决办法

视频直播推流拉流慢、卡顿解决方案

那些年移动App域名解析踩过的坑

移动应用低成本消息推送的正确姿势

如何解决域名解析不生效问题？

HTTPDNS-信任的小船永不翻

App如何实现就近接入？如何改善调度不准问题？

流量劫持与防范

基于阿里云移动推送的移动应用推送模式最佳实践

移动推送消息送达常见问题与解决办法

视频直播推流拉流慢、卡顿解决方案

那些年移动App域名解析踩过的坑

移动应用低成本消息推送的正确姿势

如何解决域名解析不生效问题？

HTTPDNS-信任的小船永不翻

App如何实现就近接入？如何改善调度不准问题？

流量劫持与防范

阿里百川 移动推送

tag提问如何操作

阿里百川移动推送