现代移动网络短连接优化方法综述:请求速度、弱网络适应和安全保障

 1.前言

 众所周知，当我们开发一个移动应用程序时，我们会直接调用系统提供的网络请求接口向服务器请求数据，然后对返回的数据做一些处理，或者在iOS中使用开源的AFNetworking/OKHttp网络库(在安卓中可以使用HttpURLConnection或开源的OKHttp库)，管理请求线程和队列，然后自动进行一些数据分析，就这样结束了。

 然而，对于追求用户体验的应用，移动网络的特性将进一步优化，包括:

 速度优化:如何进一步提高网络请求的速度？

 网络适应能力弱:移动网络环境随时变化，网络连接往往不稳定，可用性差。在这种情况下，如何尽快成功申请？

 安全性:如何在不影响性能的情况下防止第三方的窃听/篡改或假冒以及运营商的劫持？

 对于基于浏览器的前端开发，网络可以做的事情很少，但是对于本机移动应用(本文中的本机主要是指iOS和Android应用)，整个网络请求过程是自由控制的，很多事情都可以做。许多大规模的应用程序已经对这三个问题进行了大量的网络层优化，一些新的网络层协议如HTTP2/QUIC也在这些方面进行了大量的优化。在这里，请跟随我的文字，学习和整理，总结主流移动网络中常用的短连接优化方法，希望能给你带来启示。

 本文整理出的相关内容对移动即时通信应用也有启发意义，因为当今主流的即时通信数据通信被概括为长连接+短连接，因此短连接的优化在某些情况下可能更适合移动即时通信。在这方面，微信做了一项彻底而极端的工作，几乎重新创建了一个移动即时通讯的网络层框架(见“如约而至:火星，一个供微信自己使用的移动即时通讯网络层的跨平台组件库，已经正式开放”)。

 在阅读本文的同时，强烈建议您也阅读由即时通讯网络编辑的其他类似文章:“移动即时通讯开发者必须阅读(1):易于理解和理解移动网络的“弱”和“慢”，“移动即时通讯开发者必须阅读(2):总结历史上最全面的移动弱网络优化方法”，“全面理解移动域名劫持和其他各种疾病:技术原理，问题根源”

 2.相关文章

 1)关于网络传播的基本文章:

 如果你对网络交流了解不多，建议你阅读“网络编程懒惰系列简介”和“脑残网络编程系列简介”。对于更高级的网络通讯文章，你可以阅读“未知网络编程系列”。

 2)与移动网络优化相关的文章:

 现代移动网络短连接优化方法综述:请求速度、弱网络适应和安全保障

 “移动即时消息开发人员必须阅读(1):易于理解，理解移动网络的“弱”和“慢”(推荐)

 移动即时消息开发者必须阅读(2):历史上最全面的移动弱网络优化方法总结(推荐)

 全面了解移动域名系统域名劫持和其他各种疾病:技术原理、问题根源、解决方案等。

 “米托应用的移动域名系统优化实践:HTTPS请求时间减少了近一半”

 “百度应用移动网络深度优化实践分享(一):域名系统优化”(推荐)

 “百度应用移动网络深度优化实践分享(二):网络连接优化”(推荐)

 “百度APP移动网络深度优化实践分享(3):移动弱网络优化”

 “爱奇艺移动网络优化实践分享:网络请求成功率优化”(推荐)

 “正如承诺的那样:微信使用的移动即时通讯网络层跨平台组件库——火星已经正式开通”

 浅谈移动即时通讯开发中登录请求的优化

 腾讯原创分享(一):如何在移动网络下大幅提高手机QQ的图片传输速度和成功率

 腾讯原创分享(2):如何在移动网络下大幅降低应用的流量消耗(下)

 腾讯原创分享(3):如何大幅降低移动网络下应用的流量消耗(上)

 3)如果您觉得存在一些网络问题，并且无法从应用层找到答案，那么以下系列就是您的“菜”:

 下面的文章是即时消息/推送技术发展的边界知识，但是从物理层理解各种网络问题是有帮助的。如果你不感兴趣，你可以忽略它！

 即时通讯开发者零基通信技术介绍(XI):为什么无线信号不好？一句话就明白了！》

 即时消息开发者零基通信技术介绍(12):互联网接入？网络中断了吗？一句话就明白了！》

 即时通讯开发者零基通信技术介绍(十三):为什么手机信号不好？一句话就明白了！》

 即时通讯开发者零基通信技术介绍(14):在高速铁路上无线上网有多难？一句话就明白了！》

 3.关于作者

 现代移动网络中短连接优化方法综述:请求速度、弱网络适应、安全保证

 本文的原始内容来自JSPatch开源工程的作者bang的技术共享。他的博客是:http://blog.cnbang.net/about/,，由即时通讯网络重组发布。内容得到优化和改进。感谢原作者无私的分享。

 4.请求速度的优化

 网络请求的正常过程如下:

 域名解析，请求域名解析服务器获取域名对应的IP地址；

 与服务器建立连接，包括tcp三次握手和安全协议同步过程；

 连接建立完成，数据被发送和接收，数据被解码。

 有三个明显的优化点:

 直接使用IP地址，删除域名解析步骤；

 不要每次请求时都重新建立连接，重复使用连接或总是使用相同的连接(长连接)；

 压缩数据并减小传输数据的大小。

 看看你能一个一个做些什么。

 4.1DNS优化

 完整的域名解析过程非常长。它将首先从本地系统缓存。如果没有，将从最近的域名系统服务器检索。如果不是从主域名服务器检索，每个层都有一个缓存，但是对于实时域名解析，每个层都有一个过期时间。

 上述域名解析机制有几个缺点:

 缓存时间设置长，域名不及时更新，设置短。大量的域名解析请求会影响请求速度；

 域名劫持很容易被中间人攻击或被运营商劫持，域名被解析为第三方IP地址。据统计，劫机率将达到7%；

 域名解析过程不受控制，无法保证最快的域名解析；

 一次只能解析一个域名。

 为了解决这些问题，有了HTTPDNS，原理很简单，就是自己做域名解析工作，并通过HTTP请求后台获取域名对应的IP地址，从而直接解决上述所有问题。

 您自己实现HTTPDNS的好处总结如下:

 域名解析与请求是分开的，所有的请求都直接使用IP地址，没有域名解析，应用程序定期请求HTTPDNS服务器更新IP地址；

 确保HTTPDNS请求的安全性，并通过签名避免劫持；

 域名解析由自身控制，可以保证根据用户的位置返回最近的IP地址，或者根据客户端的测速结果使用最快的IP地址；

 一个请求可以解析多个域名。

 其余的细节我就不多说了。HTTPDNS有如此多的优势，几乎已经成为大中型应用的标准。到目前为止，第一个问题——耗时的域名解析问题已经解决，顺便提一下，一些安全问题——域名劫持也已经解决。

 关于移动网络中的域名系统，“谈移动终端即时通讯开发中登录请求的优化”也仅供参考。

 4.2连接优化

 第二个问题是连接建立的耗时问题。这里的主要优化思想是重用连接，而不是每次都重新建立连接。如何更有效地重用连接可以说是网络请求速度优化中最重要的一点，而这里的优化仍处于进化过程中，这一点是值得了解的。

 ▼【保活】:

 在HTTP协议中有一个保活机制，默认情况下HTTP1.1是打开的，这减少了每次请求时TCP三次握手连接的耗时。原则是在请求完成后不立即释放连接，而是将连接放入连接池。如果此时有另一个请求要发送，并且该请求的域名和端口相同，连接池中的连接将被直接取出来发送和接收数据，从而减少建立连接的时间消耗。

 事实上，默认情况下，客户端和浏览器都打开了保活，并且每次向同一个域名发送请求时，连接都不会建立一次，因此纯短连接不再存在。但是有一个问题，即这种保活连接一次只能发送和接收一个请求，并且在处理前一个请求之前不能接受新的请求。如果同时发起多个请求，有两种情况:

 如果一个请求是串行发送的，一个连接可以一直重复使用，但是速度非常慢，每个请求都必须等待最后一个请求完成后才能发送。

 如果这些请求是并行发送的，则首次为每个请求执行tcp三次握手，以建立新的连接。虽然连接池中的这一堆连接可以再次使用，但是如果连接池中维护的连接太多，服务器的资源将会被浪费。如果保持的连接数量有限，则每次仍会建立并行请求中超出的连接。

 为了解决这个问题，新一代协议HTTP2提出了复用。

 注意:下面的文章可能有助于你理解TCP的三次握手原理

 TCP/IP的详细说明-第18章TCP连接的建立和终止

 理论经典:三次握手和四波TCP协议详解

 理论与实践相结合:无线鲨鱼对TCP三握手四波的数据包捕获分析

 易于理解——对TCP协议的深刻理解(一):理论基础

 ▼[多路复用]:

 HTTP2的复用机制与复用连接相同，但复用连接支持同时处理多个请求，所有请求都可以在此连接上并发执行，解决了上述并发请求需要建立多个连接的问题。

 网络上有一些图片可以生动地展示这个过程:

 现代移动网络中短连接优化方法综述:请求速度、弱网络适应、安全保证

 在HTTP1.1协议中，连接中传输的数据是按串行顺序传输的，下一个请求直到前一个请求被完全处理后才能被处理，这导致在这些请求期间连接不能以全带宽传输。尽管HTTP1.1的流水线可以同时发送多个请求，但响应仍然根据请求按串行顺序返回，只要一个请求的响应稍大或出现错误，后续请求就会被阻塞。

 HTTP2中的多路复用协议解决了这些问题。它将连接中传输的数据封装成流，每个流都有一个标识符。流的发送和接收可能是无序的，与序列无关，因此不会有阻塞问题。接收者可以根据流的标识符来区分哪个请求属于哪个请求，然后拼接数据以获得最终的数据。

 解释单词复用。多路复用可以被认为是多个连接和操作。多路复用的字面意思是多路复用一个连接或一个线程。这里的HTTP2是连接的多路复用，还有与网络相关的I/O (select/epoll)的多路复用，这意味着多个网络请求返回的数据可以在同一线程中以事件驱动的方式读写。

 就移动客户端而言，iOS 9之上的NSURLSession已经在本地支持了HTTP2，只要服务器支持，它就可以直接使用。安卓的开源网络库okhttp3和更高版本也支持HTTP2。一些大型国内应用将建立自己的网络层，并支持HTTP2复用。避开系统限制，根据自身业务需求增加一些功能，如微信开源网络库mars(见“如约而至:移动即时通讯网络层的跨平台组件库Mars已正式开通供微信使用”)，使长连接可以处理微信上的大部分请求，复用功能与HTTP2基本一致。

 ▼ [TCP队列头阻塞]:

 HTTP2的多路复用似乎是一个完美的解决方案，但还有另一个问题，即队列头阻塞，它受到TCP协议的限制。为了确保数据的可靠性，如果传输过程中丢失了一个TCP数据包，它将在处理后续数据包之前等待该数据包的重传。HTTP2的多路复用允许在同一连接上发出所有请求。如果数据包在中间丢失，它将阻塞等待重传，并且所有请求都将被阻塞。

 为了解决这个问题，不改变协议就不能优化协议。然而，TCP协议依赖于操作系统的实现和一些硬件的定制，其改进缓慢。因此，谷歌提出了QUIC协议(参见“技术素养:新一代基于UDP的低延迟网络传输层协议——QUIC详细说明”)，相当于在UDP协议之上定义一个可靠的传输协议，以解决TCP的一些缺陷，包括队列头阻塞。网上有很多关于具体解决方案原理的信息，所以你可以看看。

 QUIC处于初始阶段，很少有客户访问它。与HTTP2相比，QUIC在解决TCP队列头阻塞方面具有最大的优势。其他优化TLS1.3(如安全握手0RTT/证书压缩)也已跟进，可用于不是唯一功能的HTTP2。还有待研究的是，TCP报头阻塞对HTTP2的性能有多大影响，以及QUIC能在多大程度上提高速度(关于这一点，请参见腾讯的QUIC技术实践“让互联网更快:在腾讯的技术实践中分享新一代QUIC协议”)。

 关于新一代QUIC协议的更多文章，请参见

 技术素养:新一代基于UDP的低延迟网络传输层协议

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

 “七牛云技术共享:用QUIC协议实现实时视频直播0卡住了！》

 4.3数据压缩优化

 第三个问题是传输数据的大小。数据对请求速度的影响分为两个方面，一个是压缩率，另一个是解压缩、序列化和反序列化的速度。目前，两种最流行的数据格式是json和protobuf。json是一个字符串，而protobuf是二进制的，也就是说，protobuf在被各种压缩算法压缩后仍然比json小。protobuf在数据量方面有优势，在序列化速度方面也有一些优势，因此它们之间的比较将不再赘述。(关于protobuf原理的详细信息，请参见Protobuf通信协议的详细说明:代码演示、详细原理介绍等。，综合评估:Protobuf的性能比JSON快5倍吗？“，”强专栏建议Protobuf作为您的即时消息应用程序数据传输格式”)

 压缩算法是多种多样且不断发展的。最新的Brotli和Z标准实现了更高的压缩比。Z-standard可以根据业务数据样本训练合适的字典，进一步提高压缩率。目前，压缩比最好的算法是最好的。

 除了传输的主体数据之外，每个请求的数据都不能被忽略。HTTP协议报头也在HTTP2中被压缩，并且大多数HTTP报头是重复数据。静态字典可用于固定字段，如方法，而动态字典可用于不固定但有重复请求的字段，如cookie，这可实现非常高的压缩率。对HTTP/2报头压缩技术进行了详细的介绍(作者对HTTP2做了大量的研究，更多的HTTP2文章可以在作者的HTTP2技术主题中找到，便于深入研究)。

 通过HTTPDNS、连接复用和更好的数据压缩算法，可以很好地优化网络请求的速度。接下来，让我们看看在网络和安全薄弱的情况下可以做些什么。

 5.移动弱网络优化

 手机无线网络环境不稳定，微信对于弱势网络的优化有更多的实践和分享，包括:

 1)提高连接成功率:

 复合连接:当建立一个连接时，一步一步的并发连接，其中所有其他连接在一个连接后关闭。该方案结合了串行和并发的优点，在不增加服务器资源消耗的情况下，提高了弱网络下的连接成功率，如下图所示

 现代移动网络中短连接优化方法综述:请求速度、弱网络适应、安全保证

 2)进行最合适的超时:

 对总读写超时(从请求到响应的超时)、首包超时和包超时(两个数据段之间的超时)制定不同的计算方案，以加快超时判断，减少等待时间，尽快重试。这里的超时也可以根据网络状态动态设置。

 3)调整传输控制协议参数并使用传输控制协议优化算法:

 对服务器的TCP协议参数进行优化，并启动各种优化算法以适应业务特点和移动网络环境，包括RTO初始值、混合慢启动、TLP、F-RTO等。

 这些针对弱网络的详细优化尚未成为标准，系统网络库也不是内置的。不过，前两个客户优化的微信开源网络库mars已经实现，必要时可以使用(见“如约而至:微信自有移动终端即时通讯网络层跨平台组件库Mars已经正式开通”)。

 6.安全

 标准协议TLS保证了网络传输的安全性。它的前身是不断发展的SSL。目前，顶级域名1.3是最新的。常见的HTTPS是HTTP协议加TLS安全协议。

 安全协议通常解决两个问题:

 1)确保安全；

 2)降低加密成本。

 在确保安全方面:

 1)使用加密算法组合来加密传输数据，以避免窃听和篡改；

 2)验证对方的身份，避免被第三方冒充；

 3)加密算法保持灵活和可更新，防止失效算法在被破解后被替换，并禁用被破解的算法。

 为了降低加密成本:

 1)采用对称加密算法对传输数据进行加密，解决了非对称加密算法性能低、长度受限的问题；

 2)在安全协议握手之后缓存密钥和其他数据，以加速第二连接建立；

 3)加快握手过程:2RTT-> 0RTT。加快握手的想法是，原始客户端和服务器需要协商使用什么算法，然后才能加密和发送数据。相反，他们使用内置的公钥和默认算法在握手时发送数据，也就是说，他们开始发送数据而不等待握手，直到0。

 这些要点涉及许多细节。有一篇关于顶级域名的文章，非常详细。我在这里推荐它:“TLS协议分析与现代加密通信协议设计”(杰克江注:这篇文章很精彩，希望你能耐心阅读。

 以下文章是关于移动通信安全的基本文章，比上面的文章更容易理解:

 即时消息安全第3部分:常见加密和解密算法及通信安全说明

 即时通讯安全第六部分:非对称加密技术的原理及应用实践

 传输层安全协议的Java平台实现介绍与演示

 微信新一代通信安全解决方案:基于顶级域名1.3的彩信顶级域名详解

 来自阿里OpenIM:分享创建安全可靠的即时消息服务的技术实践

 易于理解:掌握即时消息的消息传输安全原理

 目前，基本主流支持TLS1.2，iOS网络库默认使用TLS1.2，安卓4.4支持1.2，TLS1.3 iOS仍处于测试阶段，安卓未发现任何消息。对于普通应用，只要证书配置正确，TLS1.2就能保证传输安全，但连接速度会有损失。一些大型应用，如微信，已经自行实现了部分顶级域名1.3协议，并提前一步得到了整个平台的支持(微信团队专门分享了一些关于顶级域名1.3的实用文章，详见微信新一代通信安全解决方案:基于顶级域名1.3的MMTLS详细说明)。

 7.在末尾写

 移动网络优化的话题非常庞大。本文仅从学习过程中的优化思想出发，列举了行业中常见的优化点。还有许多细节没有涉及到更深入的优化，网络层也没有足够的实际开发经验。如果有任何错误，请指出来。

 即时消息网络-即时消息开发者社区！来源:即时消息网络-即时消息开发者社区！