DNS如何优化-百度APP移动端网络深度优化分享

浏览量:0

本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《一》DNS优化》,感谢原作者的无私分享。一、前言 网络优化是客户端几大技术方向中公认的一个深度领域,所...

本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《一》DNS优化》,感谢原作者的无私分享。

一、前言 网络优化是客户端几大技术方向中公认的一个深度领域,所以百度App给大家带来网络深度优化系列文章。

本系列文章目录如下:

《百度APP移动端网络深度优化实践分享(一):DNS优化篇》(*本文)

《百度APP移动端网络深度优化实践分享(二):网络连接优化篇》

《百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇》

希望对大家在网络方向的学习和实践有所帮助。 百度起家于搜索,整个公司的网络架构和部署都是基于标准的internet协议,目前已经是全栈HTTPS,来到移动互联网时代后,总的基础架构不变,但在客户端上需要做很多优化工作。 DNS(DomainNameSystem),它的作用是根据域名查出IP地址,它是HTTP协议的前提,只有将域名正确的解析成IP地址后,后面的HTTP流程才能进行,所以一般做网络优化会首选优化DNS。 (本文同步发布于:http://www.52im.net/thread-2472-1-1.html) 二、相关文章 《TCP/IP详解卷1:协议-第14章DNS:域名系统》 《全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等》 《美图App的移动端DNS优化实践:HTTPS请求耗时减小近半》 《现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障》 《移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”》 《移动端IM开发者必读(二):史上最全移动弱网络优化方法总结》 三、技术背景 DNS优化核心需要解决的问题有两点: 1)由于DNS劫持或故障造成的服务不可用,进而影响用户体验,影响公司的收入; 2)由于DNS调度不准确导致的性能退化,进而影响用户体验。 百度App承载着亿级流量,每年都会遇到运营商DNS劫持或运营商DNS故障,整体影响非常不好,所以DNS优化刻不容缓,通过下图会更直观的了解运营商劫持或故障的原理。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲运营商劫持或故障的原理 有关移动端DNS劫持等各种疑难杂症,详见文章《全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等》。 四、HTTPDNS 4.1概述 既然我们面临这么严峻的问题,那么我们如何优化DNS呢?答案就是HTTPDNS。 大部分标准DNS都是基于UDP与DNS服务器交互的,HTTPDNS则是利用HTTP协议与DNS服务器交互,绕开了运营商的LocalDNS服务,有效防止了域名劫持,提高域名解析效率,下图是HTTPDNS的原理。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲HTTPDNS原理 百度AppHTTPDNS端上的实现是基于百度SYS团队的HTTPDNS服务,下图介绍了HTTPDNS的服务端部署结构。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲HTTPDNS部署结构 HTTPDNS服务是基于BGP接入的,BGP英文BorderGatewayProtocol,即边界网关协议,是一种在自治系统之间动态的交换路由信息的路由协议,BGP可以根据当前用户的运营商路由到百度服务点的对应集群上,对于第三方域名,服务点会通过百度部署在运营商的CDN节点向其他域名权威DNS发起查询,查询这个运营商下域名的最优IP。 百度App独立实现了端的HTTPDNSSDK,下图介绍了端HTTPDNS的整体架构。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲端HTTPDNS的整体架构 更多HTTPDNS的资料,请见:《全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等》、《美图App的移动端DNS优化实践:HTTPS请求耗时减小近半》。 4.2DNS接口层 DNS接口层解决的问题是屏蔽底层的细节,对外提供简单整洁的API,降低使用者的上手成本,提高开发效率。 4.3DNS策略层 DNS策略层通过多种策略的组合,使HTTPDNS服务在性能,稳定性,可用性上均保持较高的水准,下面讲解下每个策略设计的初衷和具体实现。 【4.3.1容灾策略】: 这是一个非常关键的策略,主要解决HTTPDNS服务可用性的问题,实践证明,这个策略帮助百度App在异常情况下挽救回很多流量。 (1)当HTTPDNS服务不可用并且本地也没有缓存或者缓存失效的时候,会触发降级策略,降级成运营商的localDNS方案,虽然存在运营商事故或者劫持的风险,但保障了DNS服务的可用性。 (2)当HTTPDNS服务和localDNS服务双双不可用的情况下,会触发backup策略,使用端上的backupIP。 什么是backupIP?backupIP是多组根据域名分类的IP列表,可云端动态更新,方便后续运维同学调整服务端的节点IP,不是所有域名都有对应的backupIP列表,目前百度App只能保证核心域名的可用性。 既然是一组IP,便有选取问题,backupIP选取机制是怎样的呢?我们的中心思想就是要在端上利用最小的代价,并且考虑服务端的负载均衡,得到相对正确或者合理的选取结果。通过运营商和地理信息,可以选择一个相对较优的IP,但获取地理信息需要很大耗时,外加频次很高,代价很大,所以我们选择了RR算法来代替上面的方法(RR算法是Round-Robin,轮询调度),这样客户端的代价降低到最小,服务端也实现了负载均衡。 【4.3.2安全策略】: (1)HTTPDNS解决的核心问题就是安全,标准的DNS查询大部分是基于UDP的,但也有基于TCP的,如果UDP被封禁,就需要使用TCP。不管是UDP还是TCP,安全性都是没有保障的,HTTPDNS查询是基于标准的HTTP协议,为了保证安全我们会在HTTP上加一层TLS(安全传输层协议),这便是HTTPS; (2)解决了传输层协议的安全性后,我们要解决下域名解析的问题,上面我们提到HTTPDNS服务是基于BGP接入的,在端上采用VIP方式请求HTTPDNS数据(VIP即VirtualIP,VIP并没有与某设备存在必定的绑定关系,会跟随主备切换之类的情况发生而变换,VIP提供的服务是对应到某一台或若干台服务器的),既然请求原始数据需要使用IP直连的方式,那么就摆脱了运营商localDNS的解析限制,这样即使运营商出现了故障或者被劫持,都不会影响百度App的可用性。 【4.3.3任务调度策略】: HTTPDNS服务提供了两类HTTP接口,用于请求最优域名结果。第一种是多域名接口,针对不同的产品线,下发产品线配置的域名,第二种是单域名接口,只返回你要查询的那个域名结果,这样的设计和标准的DNS查询基本是一样的,只不过是从UDP协议变成了HTTP协议。 (1)域名接口会在App冷启动和网络切换的时候请求一次,目的是在App的网络环境初始化或者变化的时候预先获取域名结果,这样也会减少单域名接口的请求次数。 (2)域名接口会在本地cache过期后,由用户的操作触发网络请求,进而做一次单域名请求,用户这次操作的DNS结果会降级成localDNS的结果,但在没有过期的情况下,下次会返回HTTPDNS的结果。 【4.3.4IP选取策略】: IP选取策略解决的核心问题是最优IP的选取,避免因为接入点的选取错误造成的跨运营商耗时。HTTPDNS服务会将最优IP按照顺序下发,客户端默认选取第一个,这里没有做客户端的连通性校验的原因,主要还是担心端上的性能问题,不过有容灾策略兜底,综合评估还是可以接受的。 【4.3.5缓存策略】: 大家对于DNS缓存并不陌生,它主要是为了提升访问效率,操作系统,网络库等都会做DNS缓存。 DNS缓存中一个重要的概念就是TTL(Time-To-Live),在localDNS中针对不同的域名,TTL的时间是不一样的,在HTTPDNS中这个值由服务端动态下发,百度App目前所有的域名TTL的配置是5分钟,过期后如果没有新的IP将继续沿用老的IP,当然也可以选择不沿用老的IP,而降级成localDNS的IP,那么这就取决于localDNS对于过期IP的处理。 【4.3.6命中率策略】: 如果HTTPDNS的命中率是100%,在保证HTTPDNS服务稳定高效的前提下,我们就可以做到防劫持,提升精准调度的能力。 (1)为了提升HTTPDNS的命中率,我们选择使用多域名接口,在冷启动和网络切换的时候,批量拉取域名结果并缓存在本地,便于接下来的请求使用。 (2)为了再一次提升HTTPDNS的命中率,当用户操作触发网络请求,获取域名对应的IP时,会提前进行本地过期时间判断,时间是60s,如果过期,会发起单域名的请求并缓存起来,这样会持续延长域名结果的过期时间。本地过期时间与上面提到的TTL是客户端和服务端的双重过期时间,目的是在异常情况下可以双重保证过期时间的准确性。 4.4基础能力层 基础能力层主要提供给DNS策略层所需要的基础能力,包括IPv4/IPv6协议栈探测的能力,数据传输的能力,缓存实现的能力,下面将讲解每种能力的具体实现。 【4.4.1IPv4/IPv6协议栈探测】: 百度App的IPv6改造正在如火如荼的进行中,端上在HTTPDNS的IP选取上如何知道目前属于哪个协议栈成为关键性问题,并且这种判断要求性能极高,因为IP选取的频次实在是太高了。 我们选取的方案是UDPConnect,那么何为UDPConnect? 大家都知道TCP是面向连接的,传输数据前客户端都要调用connect方法通过三次握手建立连接,UDP是面向无连接的,无需建立连接便能收发数据,但是如果我们调用了UDP的connect方法会发生什么呢?当我们调用UDP的connect方法时,系统会检测其端口是否可用,地址是否正确,然后记录对端的IP地址和端口号,返回给调用者,所以UDPConnect不会像TCPConnect发起三次握手,发生网络真实损耗,UDP客户端只有调用send或者sendto方法后才会真正发起真实网络损耗。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲UDPConnect原理 有了UDPConnect的基础保障,我们在上层做了缓存机制,用来减少系统调用的损耗,时机上目前仅在冷启动和网络切换会触发探测,在同一种网络制式下探测一次基本可以确保当前网络是IPv4栈还是IPv6栈。 目前百度App客户端对于IPv4/IPv6双栈的策略是保守的,仅在IPv6-only的情况下使用v6的IP,其余使用的都是v4的IP,双栈下的方案后续需要优化,业内目前标准的做法是happyeyeball算法。 什么叫happyeyeball呢? 就是不会因为IPv4或IPv6的故障问题,导致用户的眼球一直在等待加载或者出错,这就是happyeyeball名字的由来。happyeyeball有v1版本RFC6555和v2版本RFC8305,前者是Cisco提出来的,后者是苹果提出来的。happyeyeball解决的核心问题是,复杂环境下v4和v6IP选取的问题,它是一套整体解决方案,对于域名查询的处理,地址的排序,连接的尝试等方面均做出了规定,感兴趣的同学可以查看参考资料里的【5】和【6】。 【4.4.2数据传输】: 数据传输主要提供网络请求的能力和数据解析的能力。 (1)网络请求失败重试的机制,获取HTTPDNS结果的成功率会大大影响HTTPDNS的命中率,所以客户端会有一个三次重试的机制,保障成功率。 (2)数据解析异常的机制,如果获取的HTTPDNS的结果存在异常,将不会覆盖端上的缓存。 【4.4.3缓存实现】: 缓存的实现基本可以分为磁盘缓存和内存缓存,对于HTTPDNS的缓存场景,我们是选其一还是都选择呢? 百度App选择的是内存缓存,目的是防止我们自己的服务出现问题,运维同学在紧急情况下切换流量,如果做了磁盘缓存,会导致百度App在重启后也可能不可用,但这种问题会导致APP在冷启动期间,HTTPDNS结果未返回前,还是存在故障或者劫持的风险,综合评估来看可以接受,如果出现这种极端情况,影响的是冷启动阶段的一些请求,但只要HTTPDNS结果返回后便会恢复正常。 五、HTTPDNS的最佳实践 百度App目前客户端网络架构由于历史原因还未统一,不过我们正朝着这个目标努力,下面着重介绍下HTTPDNS在Android和iOS网络架构中的位置及实践。 HTTPDNS在Android网络架构的位置及实践: 百度App的Android网络流量都在okhttp之上,上层进行了网络门面的封装,封装内部的实现细节和对外友好的API,供各个业务和基础模块使用,在okhttp上我们扩展了DNS模块,使用HTTPDNS替换了原有的系统DNS。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲HTTPDNS在Android网络架构的位置 HTTPDNS在iOS网络架构的位置及实践: 百度App的iOS网络流量都在cronet(chromium的net模块)之上,上层我们使用AOP的方式将cronetstack注入进URLSession里,这样我们就可以直接使用URLSession的API进行网络的操作而且更易于系统维护。 在上层封装了网络门面,供各个业务和基础模块使用,在cronet内部我们修改了DNS模块,除了原有的系统DNS逻辑外,还添加了HTTPDNS的逻辑。 iOS上还有一部分流量是在原生URLSession上,主要是有些第三方业务没有使用cronet但还想单独使用HTTPDNS的能力,所以就有了下面的HTTPDNS封装层,方法是在上层直接将域名替换成IP,域名对于底层很多机制是至关重要的,比如https校验,cookie,重定向,SNI(ServerNameIndication)等,所以将域名修改成了IP直连后,我们又处理了以上三种情况,保证请求的可用性。
百度APP移动端网络深度优化实践分享(一):DNS优化篇



▲HTTPDNS在iOS网络架构的位置 六、实际收益 DNS优化的收益主要有两点: 1)防止DNS的劫持(在出问题时显得尤为重要); 2)降低网络时延(在调度不准确的情况下,会增大网络的时延,降低用户的体验)。 这两点收益需要结合业务来说,以百度AppFeed业务为例: 1)第一点上我们取得了比较大的效果,iOS劫持率由0.12%降低到0.0002%,Android劫持率由0.25%降低到0.05%; 2)第二点的收益不明显,原因在于Feed业务主要目标群体在国内,百度在国内节点布局相对丰富,服务整体质量也较高,即使出现调度不准确的情况,差值也不会太大,但如果在国外情况可能会差很多。 七、本文结语 DNS优化是个持续性的话题,上面介绍的百度App的一些经验和做法并不见得完美,但我们会持续深入的优化下去,为百度App的DNS能力保驾护航。最后感谢大家的辛苦阅读,希望对你有所帮助,后面会继续推出《百度APP移动端网络深度优化实践分享(二):网络连接优化篇》,敬请期待。 八、个人心得 做为一个工程师,如何才能做好网络优化这件事情,是个值得我们交流探讨的话题,个人认为应该从以下五方面入手。 1)基础知识要了解学习,要夯实:网络相关的内容很多,很杂,不易学习,啃过IETF发布的RFC的同学应该深有感触。 2)学会将看不见的网络变成看得见的:很多自认为对于网络很了解的同学,动不动就背诵tcp协议原理,拥塞控制算法,滑动窗口大小等,但真正遇到线上问题,无从下手。对于客户端同学,我们在PC上要学会使用tcpdump和Wireshark等工具,适当使用Fiddler和Charles等工具,很多时候电脑和手机的网络环境不见得一致,所以要在手机上使用iNetTools,Ping&DNS或终端工具。学会使用工具后,要学着创造不同的网络环境,有很多工具能帮助你完成这点,比如苹果的NetworkLinkConditioner,FaceBook的ATC(AugmentedTrafficControl)等。具备以上两个场景后,你的第一条储备就发挥了作用,你要能看懂握手过程,传输过程,异常断开过程等。 3)有了以上两点的准备,接下来需要一个会出现各种网络问题的平台,给你积累经验,让一个个高压下的线上问题锤炼你,折磨你。 4)网络优化是需要数据支撑的:但数据的采集和分析是需要经验的,有些数据一眼看下去就是不靠谱的,有些数据怎么分析都是负向收益的,一般来说是有三重奏来对数据进行分析的,一,线下数据的采集和分析,得出正向收益,二,灰度数据的采集和分析,得出正向收益,三,线上数据的采集和分析,得出正向收益。 5)数据的正向收益,不能完全证明提升了用户的体验,所以很多时候需要针对特定场景,特定case来分析和优化,就算是大家公认做的很好的微信,也不是在所有场景下都能保证体验上的最佳。 九、参考资料

[1]https://chromium.googlesource.com/chromium/src/+/HEAD/docs/android_build_instructions.md

[2]https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md

[3]https://github.com/Tencent/mars

[4]https://tools.ietf.org/html/rfc7858

[5]https://tools.ietf.org/html/rfc6555

[6]https://tools.ietf.org/html/rfc8305

(原文链接:点此进入) 附录:更多网络通信方面的精华文章

《TCP/IP详解-第11章·UDP:用户数据报协议》

《TCP/IP详解-第17章·TCP:传输控制协议》

《TCP/IP详解-第18章·TCP连接的建立与终止》

《TCP/IP详解-第21章·TCP的超时与重传》

《技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)》

《通俗易懂-深入理解TCP协议(上):理论基础》

《通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理》

《理论经典:TCP协议的3次握手与4次挥手过程详解》

《理论联系实际:Wireshark抓包分析TCP3次握手、4次挥手过程》

《计算机网络通讯协议关系图(中文珍藏版)》

《UDP中一个包的大小最大能多大?》

《P2P技术详解(一):NAT详解——详细原理、P2P简介》

《P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解》

《P2P技术详解(三):P2P技术之STUN、TURN、ICE详解》

《通俗易懂:快速理解P2P技术中的NAT穿透原理》

《高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少》

《高性能网络编程(二):上一个10年,著名的C10K并发连接问题》

《高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了》

《高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索》

《高性能网络编程(五):一文读懂高性能网络编程中的I/O模型》

《高性能网络编程(六):一文读懂高性能网络编程中的线程模型》

《不为人知的网络编程(一):浅析TCP协议中的疑难杂症(上篇)》

《不为人知的网络编程(二):浅析TCP协议中的疑难杂症(下篇)》

《不为人知的网络编程(三):关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》

《不为人知的网络编程(四):深入研究分析TCP的异常关闭》

《不为人知的网络编程(五):UDP的连接性和负载均衡》

《不为人知的网络编程(六):深入地理解UDP协议并用好它》

《不为人知的网络编程(七):如何让不可靠的UDP变的可靠?》

《不为人知的网络编程(八):从数据传输层深度解密HTTP》

《网络编程懒人入门(一):快速理解网络通信协议(上篇)》

《网络编程懒人入门(二):快速理解网络通信协议(下篇)》

《网络编程懒人入门(三):快速理解TCP协议一篇就够》

《网络编程懒人入门(四):快速理解TCP和UDP的差异》

《网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势》

《网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门》

《网络编程懒人入门(七):深入浅出,全面理解HTTP协议》

《网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接》

《网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?》

《技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解》

《让互联网更快:新一代QUIC协议在腾讯的技术实践分享》

《现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障》

《聊聊iOS中网络编程长连接的那些事》

《移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”》

《移动端IM开发者必读(二):史上最全移动弱网络优化方法总结》

《IPv6技术详解:基本概念、应用现状、技术实践(上篇)》

《IPv6技术详解:基本概念、应用现状、技术实践(下篇)》

《从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路》

《脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手》

《脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?》

《脑残式网络编程入门(三):HTTP协议必知必会的一些知识》

《脑残式网络编程入门(四):快速理解HTTP/2的服务器推送(ServerPush)》

《脑残式网络编程入门(五):每天都在用的Ping命令,它到底是什么?》

《脑残式网络编程入门(六):什么是公网IP和内网IP?NAT转换又是什么鬼?》

《以网游服务端的网络接入层设计为例,理解实时通信的技术挑战》

《迈向高阶:优秀Android程序员必知必会的网络基础》

《全面了解移动端DNS域名劫持等杂症:技术原理、问题根源、解决方案等》

《美图App的移动端DNS优化实践:HTTPS请求耗时减小近半》

《Android程序员必知必会的网络通信传输层协议——UDP和TCP》

《IM开发者的零基础通信技术入门(一):通信交换技术的百年发展史(上)》

《IM开发者的零基础通信技术入门(二):通信交换技术的百年发展史(下)》

《IM开发者的零基础通信技术入门(三):国人通信方式的百年变迁》

《IM开发者的零基础通信技术入门(四):手机的演进,史上最全移动终端发展史》

《IM开发者的零基础通信技术入门(五):1G到5G,30年移动通信技术演进史》

《IM开发者的零基础通信技术入门(六):移动终端的接头人——“基站”技术》

《IM开发者的零基础通信技术入门(七):移动终端的千里马——“电磁波”》

《IM开发者的零基础通信技术入门(八):零基础,史上最强“天线”原理扫盲》

《IM开发者的零基础通信技术入门(九):无线通信网络的中枢——“核心网”》

《IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲》

《IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!》

《IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!》

《IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!》

《IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!》

《IM开发者的零基础通信技术入门(十五):理解定位技术,一篇就够》

《百度APP移动端网络深度优化实践分享(一):DNS优化篇》

《百度APP移动端网络深度优化实践分享(二):网络连接优化篇》

>>更多同类文章……

(本文同步发布于:http://www.52im.net/thread-2472-1-1.html)

在线客服系统      云服务器      建站      企业邮局      域名注册查询      saas平台      免费邮箱      站群      虚拟主机      域名抢注      website builder      企业秀      whois查询      

版权声明:本文内容转载自互联网,版权归作者所有,本站不拥有所有权,也不承担相关法律责任。如果您发现有涉嫌抄袭的内容,欢迎 提交反馈 进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。
CNDNS相关资讯
南京一创业郑州一创业长沙一创业武汉一创业成都一创业重庆一创业天津一创业苏州一创业佛山一创业东莞一创业广州一创业杭州一创业深圳一创业上海一创业北京一创业南京淘宝京东直播郑州淘宝京东直播长沙淘宝京东直播武汉淘宝京东直播成都淘宝京东直播重庆淘宝京东直播天津淘宝京东直播苏州淘宝京东直播佛山淘宝京东直播东莞淘宝京东直播广州淘宝京东直播杭州淘宝京东直播深圳淘宝京东直播上海淘宝京东直播北京淘宝京东直播苏州食堂承包涡轮流量计合肥保洁公司青岛创业加油站西安创业加油站郑州创业加油站东莞创业加油站天津创业加油站长沙创业加油站武汉创业加油站重庆创业加油站成都创业加油站杭州创业加油站深圳创业加油站广州创业加油站上海创业加油站北京创业加油站域名购买域名查询海南房产三亚房三亚房产海景房产海南房三亚房地产三亚海景房海口海景房买海南房三亚买房亚龙湾房地产海南二手房海景二手房西安seo优化长沙seo优化重庆seo优化成都seo优化南京seo优化杭州seo优化郑州seo优化武汉seo优化天津seo优化苏州seo优化北京seo优化广州seo优化上海seo优化深圳seo优化saas企业秀在线教育系统SEO优化微店在线客服系统商城系统企业建站建站邮件群发企业邮箱免费邮箱站群虚拟主机云服务器域名抢注whois域名website builder網頁設計佛山域名抢注福州域名抢注厦门域名抢注珠海域名抢注中山域名抢注宁波域名抢注无锡域名抢注梅州域名抢注清远域名抢注杭州域名抢注南京域名抢注苏州域名抢注惠州域名抢注北京域名抢注重庆域名抢注天津域名抢注成都域名抢注青海省负载均衡台湾省阿里云服务器广西壮族自治区站群贵州省分销云南省域名甘肃省微店河南省虚拟主机重庆市合伙人计划四川省招聘管理系统福建省微餐饮江西省OA系统山东省天翼云服务器江苏省旅游网站系统浙江省金蝶在线进销存安徽省云服务器代理辽宁省负载均衡吉林省金蝶云代账黑龙江省小程序上海市商标注册天津市网络推广河北省华为云服务器山西省云服务器代理香港特别行政区分销澳门特别行政区SSL数字证书北京市邮箱发件独享青海省网络推广宁夏回族自治区邮件群发新疆维吾尔自治区云服务器代理台湾省金蝶在线进销存西藏自治区SSL数字证书甘肃省站群四川省云课堂贵州省本地门户网站系统云南省阿里云数据库广东省域名购买广西壮族自治区邮箱发件独享海南省商标注册重庆市金蝶在线进销存河南省网易企业邮箱湖北省品牌宝湖南省网站模板江西省云会议山东省商城系统江苏省邮箱发件独享浙江省网站建设安徽省合伙人计划福建省天翼云服务器吉林省域名注册黑龙江省公司注册上海市网站建设山西省域名安全内蒙古自治区网店辽宁省在线客服系统北京市金蝶在线进销存天津市商标注册河北省网易企业邮箱拱墅区微信网站巩义市OA系统工农区私有云共青城市私有云贡山独龙族怒族自治县华为云服务器贡嘎县公司注册共和县微小店贡井区OA系统贡觉县虚拟主机巩留县旅游网站系统工布江达县公司注册弓长岭区阿里云企业邮箱恭城瑶族自治县云服务器耿马傣族佤族自治县考试系统根河市微信小程序珙县微店公安县网店格尔木市公司注册革吉县微店个旧市网易企业邮箱