移动 APP 网络优化概述-天涯论坛 - Powered by Discuz! Archiver

m5k1umn 发表于 2024-8-31 01:45:21

移动 APP 网络优化概述

<img src="https://mmbiz.qpic.cn/mmbiz/QbziaGpwWGoaVEx8JZTD5r7JtXsQUZ1ZalSyibxgo9RfTwZoZicFSj4kKooADsLRuHw0ibXM0Or5hibAhwrtjP8QF8Q/640?wx_fmt=gif&tp=webp&wxfrom=5&wx_lazy=1" style="width: 50%; margin-bottom: 20px;">
通常研发一个 APP，会直接调用系统供给的网络请求接口去服务端请求数据，再针对返回的数据进行有些处理，或运用AFNetworking/OKHttp这般的网络库，管理好请求线程和队列，再自动做有些数据解析，就结束了。
但针对有些大型 APP，还会想针对网络的有些问题进行进一步优化，包含：
速度：网络请求的速度怎么样能进一步提高？
弱网：移动端网络环境随时变化，经常显现网络连接很不稳定可用性差的状况，怎么样在这种状况下最大限度最快地成功请求？
安全：怎么样防止被第三方窃听/篡改或冒充，防止运营商劫持，同期又不影响性能？
对基于浏览器的前端研发来讲，网络这块能做的事情很少，但针对客户端 APP 来讲，全部网络请求过程是自由掌控的，能够做非常多事情，非常多大型 APP 都针对这三个问题做了非常多网络层的优化，有些新的网络层协议像 HTTP2 / QUIC 亦是在这些方面进行了不少优化，在这儿边学习边整理，大致列举一下平常的做法。
速度
正常一条网络请求需要经过的流程是这般：
DNS 解析，请求DNS服务器，获取域名对应的 IP 位置。
与服务端创立连接，包含 tcp 三次握手，安全协议同步流程。
连接创立完成，发送和接收数据，解码数据。
这儿有显著的三个优化点：
直接运用 IP 位置，去除 DNS 解析过程。
不要每次请求都重新创立连接，复用连接或始终运用同一条连接(长连接)。
压缩数据，减小传输的数据体积。
逐条来看能做什么。
1.DNS
DNS 完整的解析流程很长，会先从本地系统缓存取，若无就到近期的 DNS 服务器取，若无再到主域名服务器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过期时间，这种 DNS 解析机制有几个缺点：
缓存时间设置得长，域名更新不即时，设置得短，海量 DNS 解析请求影响请求速度。
域名劫持，容易被中间人攻击，或被运营商劫持，把域名解析到第三方 IP 位置，据统计劫持率会达到7%。
DNS 解析过程不受掌控，没法保准解析到最快的IP
一次请求只能解析一个域名。
为认识决这些问题，就有了 HTTPDNS，原理很简单，便是自己做域名解析的工作，经过 HTTP 请求后台去拿到域名对应的 IP 位置，直接处理以上所有问题：
域名解析与请求分离，所有请求都直接用IP位置，无需 DNS 解析，APP 按时请求 HTTPDNS 服务器更新IP位置就可。
经过签名等方式，保准 HTTPDNS 请求的安全，避免被劫持。
DNS 解析由自己掌控，能够保证按照用户所在地返回就近的 IP 位置，或按照客户端测速结果运用速度最快的 IP。
一次请求能够解析多个域名。
其余细节就不多说了，HTTPDNS 优点这么多，几乎作为中大型 APP 的标配。至此处理了第1个问题 — DNS 解析耗时的问题，顺便把一部分安全问题 — DNS 劫持亦处理了。
2.连接
第二个问题，连接创立耗时的问题，这儿重点的优化思路是复用连接，不消每次请求都重新创立连接，怎样更有效率地复用连接，能够说是网络请求速度优化里最重点的点了，并且这儿的优化仍在演进过程中，值得认识下。
keep-alive
HTTP 协议里有个 keep-alive，HTTP1.1默认开启，必定程度上缓解了每次请求都要进行TCP三次握手创立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若此时有另一个请求要发出，请求的域名和端口是同样的，就直接拿出连接池中的连接进行发送和接收数据，少了创立连接的耗时。
实质上此刻无论是客户端还是浏览器都默认开启了keep-alive，对同个域名不会再有每发一个请求就进行一次建连的状况，纯短连接已然不存在了。但有个问题，便是这个 keep-alive 的连接一次只能发送接收一个请求，在上一个请求处理完成之前，没法接受新的请求。若同期发起多个请求，就有两种状况：
若串行发送请求，能够始终复用一个连接，但速度很慢，每一个请求都要等待上个请求完成再进行发送。
若并行发送这些请求，那样首次每一个请求都要进行tcp三次握手创立新的连接，虽然第二次能够复用连接池里这堆连接，但若连接池里保持的连接太多，对服务端资源产生很强浪费，若限制了保持的连接数，并行请求里超出的连接仍每次要建连。
对这个问题，新一代协议 HTTP2 提出了多路复用去处理。
多路复用
HTTP2 的多路复用机制同样是复用连接，但它复用的这条连接支持同期处理多条请求，所有请求都能够并发在这条连接上进行，亦就处理了上面说的并发请求需要创立多条连接带来的问题，网络上有张图能够较形象地表现这个过程：
<img src="https://mmbiz.qpic.cn/mmbiz_png/QbziaGpwWGobPNZKnww4afjToTicc64ymZfg7Zp7DicibbEjXZdia22fBAx2A2IqzzycMDRfyC7bbLIibbVwbU6faAVw/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1" style="width: 50%; margin-bottom: 20px;">
HTTP1.1的协议里，在一个连接里传送数据都是串行次序传送的，必须等上一个请求所有处理完后，下一个请求才可进行处理，引起这些请求时期这条连接并不是满带宽传输的，即使是HTTP1.1的pipelining能够同期发送多个request，但response仍是按请求的次序串行返回，只要其中一个请求的response稍微大一点或出现错误，就会阻塞住后面的请求。
HTTP2 这儿的多路复用协议处理了这些问题，它把在连接里传输的数据都封装成一个个stream，每一个stream都有标识，stream的发送和接收能够是乱序的，不依赖次序，亦就不会有阻塞的问题，接收端能够按照stream的标识去区分属于哪个请求，再进行数据拼接，得到最后数据。
解释下多路复用这个词，多路能够认为是多个连接，多个操作，复用便是字面上的意思，复用一条连接或一个线程。HTTP2这儿是连接的多路复用，网络关联的还有一个I/O的多路复用(select/epoll)，指经过事件驱动的方式让多个网络请求返回的数据在同一条线程里完成读写。
客户端来讲，iOS9 以上 NSURLSession 原生支持 HTTP2，只要服务端亦支持就能够直接运用，Android 的 okhttp3 以上亦支持了 HTTP2，国内有些大型 APP 会自建网络层，支持 HTTP2 的多路复用，避免系统的限制以及按照自己业务需要增多有些特性，例如微X的开源网络库 mars（https://github.com/Tencent/mars/wiki），做到一条长连接处理微X上的大部分请求，多路复用的特性上基本跟 HTTP2 一致。
TCP队头阻塞
HTTP2 的多路复用看起来是完美的处理方法，但还有个问题，便是队头阻塞，这是受限于 TCP 协议，TCP 协议为了保准数据的靠谱性，若传输过程中一个 TCP 包丢失，会等待这个包重传后，才会处理后续的包。HTTP2的多路复用让所有请求都在同一条连接进行，中间有一个包丢失，就会阻塞等待重传，所有请求亦就被阻塞了。
针对这个问题不改变 TCP 协议就没法优化，但 TCP 协议依赖操作系统实现以及部分硬件的定制，改进缓慢，于是 GOOGLE 提出 QUIC 协议，相当于在 UDP 协议之上再定义一套靠谱传输协议，处理 TCP 的有些缺陷，包含队头阻塞。详细处理原理网上资料较多，能够瞧瞧。
QUIC 处在起步周期，少有客户端接入，QUIC 协议相针对 HTTP2 最大的优良是对TCP队头阻塞的处理，其他的像安全握手 0RTT / 证书压缩等优化 TLS1.3 已跟进，能够用于 HTTP2，并不是独有特性。TCP 队头阻塞在 HTTP2 上对性能的影响有多大，在速度上 QUIC 能带来多大提高待科研。
3.数据
第三个问题，传输数据体积的问题。数据对请求速度的影响分两方面，一是压缩率，二是解压序列化反序列化的速度。日前最流行的两种数据格式是 json 和 protobuf，json 是字符串，protobuf 是二进制，即运用各样压缩算法压缩后，protobuf 仍会比 json 小，数据量上 protobuf 有优良，序列化速度 protobuf 亦有有些优良，这两者的对比就不细说了。
压缩算法多种多样，亦在持续演进，最新出的 Brotli 和Z-standard实现了更高的压缩率，Z-standard 能够按照业务数据样本训练出适合的字典，进一步加强压缩率，日前压缩率表现最好的算法。
除了传输的 body 数据，每一个请求 HTTP 协议头的数据亦是不可忽略，HTTP2 里对 HTTP 协议头亦进行了压缩，HTTP 头大大都是重复数据，固定的字段如 method 能够用静态字典，不固定但多个请求重复的字段例如 cookie 用动态字典，能够达到非常高的压缩率，这儿有仔细介绍。
经过 HTTPDNS，连接多路复用，更好的数据压缩算法，能够把网络请求的速度优化到较不错的程度了，接下来再瞧瞧弱网和安全上能够做的事情。
弱网
手机无线网络环境不稳定，针对弱网的优化，微X有较多实践和分享，包含：
1.提高连接成功率
复合连接，创立连接时，阶梯式并发连接，其中一条连通后其他连接都关闭。这个方法结合串行和并发的优良，加强弱网下的连接成功率，同期又不会增多服务器资源消耗：
<img src="https://mmbiz.qpic.cn/mmbiz_png/QbziaGpwWGobPNZKnww4afjToTicc64ymZlpFMUn9hURLe6UbpFGFF7BQmjfPpfBZopE7n54N5iafEic43DUnEfqQQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1" style="width: 50%; margin-bottom: 20px;">
2.制定最合适的超时时间
对总读写超时(从请求到响应的超时)、首包超时、包包超时(两个数据段之间的超时)时间制定区别的计算方法，加快对超时的判断，减少等待时间，尽早重试。这儿的超时时间还能够按照网络状态动态设定。
3.调优TCP参数，运用TCP优化算法。
对服务端的TCP协议参数进行调优，以及开启各样优化算法，使得适合业务特性和移动端网络环境，包含RTO初始值，混合慢起步，TLP，F-RTO等。
针对弱网的这些细致优化未作为标准，系统网络库无内置，不外前两个客户端优化微X的开源网络库 mars 有实现，若有需要能够运用。
安全
标准协议 TLS 保准了网络传输的安全，前身是 SSL，持续在演进，日前最新是 TLS1.3。平常的 HTTPS 便是 HTTP 协议加上 TLS 安全协议。
安全协议概括性地说处理两个问题：1.保准安全 2. 降低加密成本
在保准安全上：
运用加密算法组合对传输数据加密，避免被窃听和篡改。
认证对方身份，避免被第三方冒充。
加密算法保持灵活可更新，防止定死算法被破解后没法更换，禁用已被破解的算法。
降低加密成本上：
用对叫作加密算法加密传输数据，处理非对叫作加密算法的性能低以及长度限制问题。
缓存安全协议握手后的密钥等数据，加快第二次建连的速度。
加快握手过程：2RTT-> 0RTT。加快握手的思路，便是原本客户端和服务端需要协商运用什么算法后才可加密发送数据，变成经过内置的公钥和默认的算法，在握手的同期就把数据发出去，亦便是不需要等待握手就起始发送数据，达到0RTT。
这些点触及的细节非常多，对 TLS 的介绍有一篇雄文，说得很仔细，这里举荐。
日前基本主流都支持 TLS1.2，iOS 网络库默认运用 TLS1.2，Android4.4 以上支持 1.2。TLS1.3 iOS 还处在测试周期，Android 未查到信息。针对普通 APP，只要正确配置证书，TLS1.2 已然能保准传输安全，只是在建连速度上会有所损耗，有有些大型 APP 像微X就自动实现了 TLS1.3 的部分协议，早一步全平台支持。
最后
网络优化这个专题非常庞大，本文只是在学习过程中从优化思路上列举了日前业界平常的优化点，还有非常多细节非常多更深入的优化没触及到，网络层实践研发经验不足，若有错误欢迎指出。<img src="https://mmbiz.qpic.cn/mmbiz_jpg/QbziaGpwWGobehr9c19J6J66fKlmw0TChFBPVsrYq22GibM3qdibh0SlCbkYEFvJa8nYvLYhAjnVAW1h6Y8eYbicLA/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1" style="width: 50%; margin-bottom: 20px;">iOS猿吧关注最新技术<a style="color: black;">关注</a>

m5k1umn 发表于 2024-10-3 23:12:49

感谢你的精彩评论，带给我新的思考角度。

nqkk58 发表于 2024-10-29 19:08:44

论坛的成果是显著的，但我们不能因为成绩而沾沾自喜。

7wu1wm0 发表于 2024-11-7 07:53:38

楼主发的这篇帖子，我觉得非常有道理。

页: [1]

天涯论坛's Archiver

移动 APP 网络优化概述