深圳网络营销,网站推广,网站优化,关键词SEO,品牌百度推广

简单谈谈移动网络端的优化

来源:乐云践新作者:乐云践新发布时间:2021-08-17
这篇文章,就试图从一个移动开发者的角度出发,分析一下整个内容加载过程,如何在不出错的情况下来优化和监控加载时间。     衡量   我们做一件优化的事情时,首先不是急于寻找优化点,立马动笔写代码、改架构,而是得知道如何衡量这件事情。这样,我们不仅能帮我们整理思路,也能将优化的成果获得更多人认可。

  就 "进入某个页面到该页面新内容显示" 这个优化目标而言,我们先抛弃 Android、iOS、Web 的差异,缩减成 "在移动设备上网络发起请求到接收数据" 的时间,这样剔除掉组件加载、页面构建等等其他不确定因素。  那么首先映入我们脑海的,肯定是响应速度,同样的请求要是只用更少的时间就能拿回数据,那一定很棒!所以我们有了第一个考虑维度 — 速度。  第二个需要考虑的点是安全,用户在请求数据时,往往会携带很多隐私信息 (地区、设备、账号等等),如何保护这些信息不被窃取,也是另一个需要考虑的地方。  第三个需要考虑的点是稳定,这里主要由两部分组成。一是服务端的宕机率,很多大型 APP 的宕机率都要求小于 0.1%;二是复杂网络环境下的策略,这里简单地举个例子,用户在偏远地区使用我们的 APP,信号不稳定,此时还能否正常返回数据?  这是三点,我考虑到的衡量内容加载的三个维度,这篇文章的后续内容也从这三个维度上,去思考如何优化内容加载。   

 解剖   我们知道如何衡量这件事情后,接下来就解剖 "内容加载",把其中发生的各个步骤拎出来,通过上述三个维度,来分析每个步骤。当然如果要详细地将每一个步骤说清楚,这就不是一篇文章的事情,因而在这里只能言简意赅地说说,最常见的路径下的各个步骤如下: DNS 查询 URL 对应 IP 地址。  与服务器建立连接 (通常情况下为 TCP/IP 协议)。  根据应用层协议 (HTTP/HTTPS) 发送请求。  服务器响应请求,返回序列化的数据 (Json/Proto)。  APP 反序列化数据,并予以呈现。    更多更详细信息,可以参考 GitHub - alex/what-happens-when: An attempt to answer the age old interview question "What happens when you type google.com into your browser and press enter?",详细地解答了 "当你在浏览器中输入 google.com 并且按下回车之后发生了什么?" 这个问题。  那现在开始,分别从上一小节提到的三个维度出发,分析每一个步骤。   

 DNS   加载内容时,我们往往是通过 URL (统一资源定位符),诸如 www.google.com 这样的链接。但这样的 URL 是不能直接使用的,就好像知道一个人的别名,但不能送货给他。因此我们访问 Google 时,通过某种查询服务得知到对应的 IP 地址,然后通过这个 IP 地址,我们才能建立连接请求,获取内容信息。

这个服务叫做 Domain Name System,也就是大家常说的 DNS。  DNS 本身非常复杂,这里简要介绍流程。假设用户使用移动网络访问 APP 时,就会首先由网络服务商 (移动网络就是电信、移动和联通等等运营商) 分配一个本地域名服务器 LocalDNS,层层向上询问,最终通过权威域名服务器,返回一个 IP 地址。  问题 本地域名服务器 LocalDNS 是一个经常被人诟病的服务,我们具体看看都有些什么问题。   1. 安全 首先 LocalDNS 为了自身效率考虑,会做一些缓存,也就是将一些数据记录在本地,但这样会导致时效性问题。设想服务端在 12:00 上线了一个很棒的活动,并更改了 IP 地址和对应的解析协议,但由于 LocalDNS 的缓存导致过了一定时间后新的 IP 才生效,用户就不能及时地体验这个活动。 

  上面这条还不是最严重的情况,LocalDNS 特别是一些小运营商,经常被人喷的是 DNS 劫持。可能为了某种创收,LocalDNS 缓存了部分页面,篡改了一下并添加了广告后,当用户请求 DNS 服务时,直接返回这个添加了广告的页面,用户就会相当反感!    2. 速度 不仅安全方面可能出现问题,速度也同样得不到保障。

导致速度可能出现问题的本质原因是,本应作为参考的原始信息丢失,最终导致权威服务器没有返回一个最优 IP 地址,从而速度受到影响。下面罗列几种可能性:  小运营商直接将解析请求转给大运营商,权威 DNS 服务误以为这是大运营商的请求,从而没有返回服务器专门针对小运营商优化的 IP 地址。 NAT,更多信息参考网络地址转换 - 维基百科,自由的百科全书。当内网的某台设备想要与互联网上的服务器进行通信时,IP 地址可能会被更换,一旦做了网络地址的转换,权威的 DNS 服务器,就没办法通过这个信息作出最优解。 

 方案 优化的出发点就是尽量减少 DNS 请求,例如将大部分请求都放在同一个域名下。另外也已经有比较成熟的方案,既然 LocalDNS 坑,那我不陪你玩了,自己搞一套!   1. HttpDns HttpDns 就是应运而生的一套解决方案。APP 不再通过 LocalDNS 解析域名,而是通过服务端实现的服务,自己来查询域名对应的 IP 地址,这里查询的时候,是直接通过 IP 地址进行查询的。这样就略掉了域名解析,速度上面会有优化,直连服务器的做法也规避了 DNS 劫持导致的安全性问题。    当然 HttpDns 能做的事情还有很多,例如客户端可以有一定的缓存策略,通过缓存来进一步优化时间。又比如服务端可以通过客户端提供的地区、服务商等等信息,做一些策略优化。 

  2. CDN 我们查看快递的时候,经常会发现这样一种类型的 Case,例如我在南宁买了一个手机,那京东会首先查看南宁仓库有没有,没有继续就查询广西仓库 (不一定真实存在),如果还没有就再查询京东物流总部。这样下来,快递的效率很高。某些服务提供商,就提供了这样的服务 — CDN(Content Delivery Network),让对应的请求能够找到最优的仓库,降低网络拥塞,以最快的速度返回。   CDN 通常会和 DNS 配合起来使用,所以这里单独拎出来说,运营同学修改 DNS 的设置,使得用户在访问资源时能够通过 CDN 来执行。由于 CDN 部署和生效需要一定的时间,一般用于分发静态资源。    TCP - HTTP   再来看看拿到 IP 地址之后的事情,大多数情况下,App 在请求数据时,都是通过 TCP 协议来建立和关闭连接。只有在链接建立的基础之上,才能通过 Http/Https 或者其他应用层协议与服务端交互。

由于 Http 的优化与 TCP 协议紧密相关,这里就放在一块讲。    问题 TCP 协议是面向连接的,可靠的流协议,但在移动网络下也有些水土不服,需要针对性地做一些优化。HTTP 本身也存在安全性等等问题,咱们具体看看。   1. 速度  TCP 协议在建立和关闭链接的时候,会涉及到三次握手和四次挥手,这是相对耗时的操作。但对于绝大多数 App 而言, 单次数据量都不大,但是次数很多,这会导致频繁地建立和关闭链接,导致用户体感上响应较慢。  HTTP/1.1 的时候,通过管道一次性发送多个请求,希望这样来提高效率。由于 TCP 协议的设定,每个请求必须按顺序进行,也就是说如果上一个请求阻塞住,后面的请求必须等待被阻塞的请求处理完毕过后再进行,这个问题被称为队头阻塞 (Head-of-line blocking)。尽管在 HTTP/2 的时候,将数据拆分成若干个 Frame 发送,减少了阻塞的可能性,但只要是 TCP 协议,问题本质是在传输层,其实还是不能完全解决。  2. 安全  前些年 iOS 强制要求开发者使用 HTTPS 协议的新闻,在 IT 圈被广泛讨论。原因就在于 HTTP 协议不能很好地保护用户隐私,隐患一直存在。因而即便在 Android 上,越来越多的 APP 也主动切换到更为安全的 HTTPS 上。  3. 稳定  移动 APP 可能处于各种网络环境下,2G/3G/4G/校园网/公网等等。Socket 的参数不能适用于所有情况,默认的参数可能表现很差。前面也提到,TCP 协议是有状态的,请求过去都需要回来的 ACK 包,但弱网环境下,包可能有很大的延迟,包越多就能耗时越久,用户体感越差。 

 方案 1. 链接复用  既然建立和关闭链接耗时,那就尽可能地复用它,这样就能优化速度。HTTP/1.x 可以设置为 keep-alive,或者接入 HTTP/2,HTTP/2 不仅能提供连接复用,也提供了诸多其他优化,例如 header 数据压缩,TLS 优化等等。  2. HTTPS  HTTP 协议存在安全隐患,那我们给他加上安全控制不就好了吗? HTTPS 也就诞生了,关于其如何加密数据的方式,也随着时间迭代了数个版本。有兴趣的同学,可以深入地了解下这段历史,能学到不少东西呢。   3. QUIC  既然 TCP 协议的机制决定速度不是最优的,那能不能用它的兄弟 UDP 来做一些事情? 在 UDP 的基础之上,添加一些控制,在保证安全性的基础之上,尽可能地加快速度呢? QUIC,a multiplexed stream transport over UDP 在 Google 的推动下就诞生了,相较于 TCP + TLS + HTTP2 的模式,有以下几点优势: Dramatically reduced connection establishment time Improved congestion control Multiplexing without head of line blocking Forward error correction Connection migration    DATA   终于到实际传输的数据了,这里核心的点,在于如何尽可能地减少包大小和如何保证数据安全上。罗列一下常见的优化方法:  对于服务端定义的协议,查看有没有冗余的地方,优化数据结构。对于常见的公参字段做简化,例如 vc = version code,vn = version name 等等。  尝试使用 Protocol Buffers | Google Developers,相较于其他格式而言,更小更快。  对于图片而言,可以使用 A new image format for the Web | WebP | Google Developers。     

 篇幅所限,很多知识都是点到为止,起到抛砖引玉的作用。最后阐述下,并没有万能的银弹,网络本身的复杂性就决定了没有统一的解决方案,各 APP 都需要针对自身的情况,去做一些特定的优化,来达到优化的目的,实践才是唯一的真理。
本文标签:



地址:深圳市宝安区宝安大道4018号华丰国际大厦506

电话: 17688744199

邮箱:963359518@qq.com

QQ:1605354269 


Copyright© 深圳市乐云践新媒体技术有限公司 粤ICP备15060126号 leyunseo.com.All Rights Reser







微信二维码

地址:深圳市宝安区宝安大道4018号华丰国际大厦506

联系人: 17688744199

邮箱:963359518@qq.com

QQ:1605354269 


Copyright© 深圳市乐云践新媒体技术有限公司 粤ICP备15060126号 leyunseo.com.All Rights Reser