本篇文章是对bang神的文章挪动App收集优化概述停止的总结，文章中也加了的一些本身的理解与扩展。
我们每次在做营业做收集恳求的时候，想必每小我都根究过若何进一步优化收集恳求吧，好比那三点包罗：
速度：收集恳求的速度如何能进一步提拔？
弱网：挪动端收集情况随时改变，经常呈现收集毗连很不不变可用性差的情状，如何在那种情状下更大限度最快地胜利恳求？
平安：如何避免被第三方窃听/窜改或冒充，避免运营商劫持，同时又不影响性能？
对基于阅读器的前端开发来说，收集那块能做的工作很少，但关于客户端 APP 来说，整个收集恳求过程是自在掌握的，能够做良多工作，良多大型 APP 都针对那三个问题做了良多收集层的优化，一些新的收集层协议像 也是在那些方面停止了很多优化，在那里边进修边整理，大致列举一下常见的做法。
一 速度
一般一条收集恳求需要颠末的流程是如许：
1、DNS 解析，恳求DNS办事器，获取域名对应的 IP 地址。
2、与办事端成立毗连，包罗 tcp 三次握手，平安协议同步流程。
3、毗连成立完成，发送和领受数据，解码数据。
那里有明显的三个优化点：
1、间接利用 IP 地址，往除 DNS 解析步调。
2、不要每次恳求都从头成立毗连，复用毗连或不断利用统一条毗连(长毗连)。
3、压缩数据，减小传输的数据大小。
依次来阐发每个优化点我们能做什么
1 DNS
DNS 完全的解析流程很长，会先从当地系统缓存取，若没有就到比来的 DNS 办事器取，若没有再到主域名办事器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过时时间，那种 DNS 解析机造有几个缺点：
1、缓存时间设置得长，域名更新不及时，设置得短，大量 DNS 解析恳求影响恳求速度。
2、域名劫持，随便被中间人进攻，或被运营商劫持，把域名解析到第三方 IP 地址，据统计劫持率会到达7%。
3、DNS 解析过程不受掌握，无法包管解析到最快的IP
4、一次恳求只能解析一个域名。
为领会决那些问题，就有了 地址，间接处理上述所有问题：
1、域名解析与恳求别离，所有恳求都间接用IP地址，无需 DNS 解析，APP 按时恳求 地址即可。
2、通过签名等体例，包管 恳求的平安，制止被劫持。
3、DNS 解析由本身掌握，能够确保根据用户所在地返回就近的 IP 地址，或根据客户端测速成果利用速度最快的 IP。
4、一次恳求能够解析多个域名。
其余细节就不多说了， 劫持也处理了。
2 毗连
第二个问题，毗连成立耗时的问题，那里次要的优化构想是复用毗连，不消每次恳求都从头成立毗连，若何更有效率地复用毗连，能够说是收集恳求速度优化里最次要的点了，而且那里的优化仍在演进过程中，值得领会下。
keep-alive
三次握手成立毗连的耗时。原理是恳求完成后不立即释放毗连，而是放进毗连池中，若那时有另一个恳求要发出，恳求的域名和端口是一样的，就间接拿出毗连池中的毗连停止发送和领受数据，少了成立毗连的耗时。
**现实上如今无论是客户端仍是阅读器都默认开启了keep-alive，对同个域名不会再有每发一个恳求就停止一次建连的情状，纯短毗连已经不存在了。**但有个问题，就是那个 keep-alive 的毗连一次只能发送领受一个恳求，在上一个恳求处置完成之前，无法承受新的恳求。若同时倡议多个恳求，就有两种情状：
1、若串行发送恳求，能够不断复用一个毗连，但速度很慢，每个恳求都要期待上个恳求完成再停止发送。
2、若并行发送那些恳求，那么初次每个恳求都要停止tcp三次握手成立新的毗连，固然第二次能够复用毗连池里那堆毗连，但若毗连池里连结的毗连过多，对办事端资本产生较大浪费，若限造了连结的毗连数，并行恳求里超出的毗连仍每次要建连。
对那个问题，新一代协议 提出了多路复用往处理。
多路复用
的多路复用机造一样是复用毗连，但它复用的那条毗连撑持同时处置多条恳求，所有恳求都能够并发在那条毗连长进行，也就处理了上面说的并发恳求需要成立多条毗连带来的问题，收集上有张图能够较形象地表示那个过程：
略微大一点或发作错误，就会阻塞住后面的恳求。
的标识往区分属于哪个恳求，再停止数据拼接，得到最末数据。
阐明下多路复用那个词，多路能够认为是多个毗连，多个操做，复用就是字面上的意思，复用一条毗连或一个线程。)，指通过事务驱动的体例让多个收集恳求返回的数据在统一条线程里完成读写。
客户端来说，iOS9 以上 NSURLSession 原生撑持 一致。
TCP队头阻塞
的多路复用让所有恳求都在统一条毗连停止，中间有一个包丧失，就会阻塞期待重传，所有恳求也就被阻塞了。
关于那个问题不改动 TCP 协议就无法优化，但 TCP 协议依靠操做系统实现以及部门硬件的定造，改进迟缓，于是GOOGLE 提出 QUIC 协议，相当于在 UDP 协议之上再定义一套可靠传输协议，处理 TCP 的一些缺陷，包罗队头阻塞。QUIC协议固然是基于UDP，但它不单具有TCP的可靠性、拥塞掌握、流量掌握等，QUIC 协议相关于 成立平安的会话。
3 数据
第三个问题，传输数据大小的问题。数据对恳求速度的影响分两方面，一是压缩率，二是解压序列化反序列化的速度。目前最时髦的两种数据格局是 json 和 protobuf，json 是字符串，protobuf 是二进造，即便用各类压缩算法压缩后，protobuf 仍会比 json 小，数据量上 protobuf 有优势，序列化速度 protobuf 也有一些优势，那两者的比照就不细说了。能够看此文章protobuf 在iOS上的理论来进一步领会protobuf
压缩算法多种多样，也在不竭演进，最新出的 Brotli 和Z-standard实现了更高的压缩率，Z-standard 能够根据营业数据样本操练出合适的字典，进一步进步压缩率，目前压缩率表示更好的算法。
除了传输的 body 数据，每个恳求 用动态字典，能够到达十分高的压缩率，那里有详尽介绍。
通过 ，毗连多路复用，更好的数据压缩算法，能够把收集恳求的速度优化到较不错的水平了，接下来再看看弱网和平安上能够做的工作。
二 弱网
手机无线收集情况不不变，针对弱网的优化，微信有较多理论和分享，包罗：
1、 提拔毗连胜利率复合毗连，成立毗连时，阶梯式并发毗连，此中一条连通后其他毗连都 封闭。那个计划连系串行和并发的优势，进步弱网下的毗连胜利率，同时又不会增加办事器资本消耗：
2、造定最适宜的超不时间对总读写超时(从恳求到响应的超时)、首包超时、包包超时(两个数据段之间的超时)时间造定差别的计算计划，加快对超时的揣度，削减期待时间，尽早重试。那里的超不时间还能够根据收集形态动态设定。
3、调优TCP参数，利用TCP优化算法。对办事端的TCP协议参数停止调优，以及开启各类优化算法，使得合适营业特征和挪动端收集情况，包罗RTO初始值，混合慢启动，TLP，F-RTO等
针对弱网的那些详尽优化未成为原则，系统收集库没有内置，不外前两个客户端优化微信的开源收集库 mars 有实现，如有需要能够利用。
三 平安
原则协议 TLS 包管了收集传输的平安，前身是 SSL，不竭在演进，目前最新是 TLS1.3。常见的 平安协议。
平安协议归纳综合性地说处理两个问题：1.包管平安 2. 降低加密成本
在包管平安上：
1、利用加密算法组合对传输数据加密，制止被窃听和窜改。
2、认证对方身份，制止被第三方冒充。
3、加密算法连结乖巧可更新，避免定死算法被破解后无法改换，禁用已被破解的算法。
降低加密成本上：
1、用对称加密算法加密传输数据，处理非对称加密算法的性能低以及长度限造问题。
2、缓存平安协议握手后的密钥等数据，加快第二次建连的速度。
3、加快握手过程：2RTT- 0RTT。加快握手的构想，就是本来客户端和办事端需要协商利用什么算法后才气加密发送数据，酿成通过内置的公钥和默认的算法，在握手的同时就把数据发出往，也就是不需要期待握手就起头发送数据，到达0RTT。
那些点涉及的细节十分多，对 TLS 的介绍有一篇雄文，说得很详尽，在此选举。
目前根本支流都撑持 TLS1.2，iOS 收集库默认利用 TLS1.2，Android4.4 以上撑持 1.2。TLS1.3 iOS 还处于测试阶段，Android 未查到动静。关于通俗 APP，只要准确设置装备摆设证书，TLS1.2 已经能包管传输平安，只是在建连速度上会有所损耗，有一些大型 APP 像微信就自行实现了 TLS1.3 的部门协议，早一步全平台撑持。
转载自：