即时通讯开发移动端网络短连接的优化手段

众所周之，我们通常开发一个移动应用程序,直接调用系统提供的网络请求接口到服务器请求数据,然后对返回的数据进行一些处理,或者使用iOS的开放源AFNetworking/OKHttp网络库(HttpURLConnection或Android的开放源okhttp库),妥善管理请求线程和队列,然后做一些自动数据分析,就结束了。

但对于追求用户体验的应用来说，还会针对移动网络的特性做进一步优化，包括：

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

2)弱网络适应:移动网络环境不断变化,网络连接经常非常不稳定,可用性很低。在这个情况下,如何使请求尽可能迅速成功?

3)安全:如何防止第三方侵入/修改或误导,防止操作者偷窃而不影响性能?

对于基于浏览器的前端开发,网络可以做很少的事情,但对于固有移动端应用程序(本条主要指iOS和Android应用程序),整个网络请求过程是自由控制的,并且可以做很多事情。

许多大型应用程序已经做了大量的网络层优化来解决这些三个问题,一些新的网络层协议如HTTP2/QUIC也在这些领域做了大量的优化。

在此,请遵循我的话,对当前主流移动网络短途连接的共同优化方法进行研究,并总结总结,希望能给你带来灵感。

请求速度的优化

一个正常网络请求需要进行的过程如下:

1)DNS分析,请求DNS服务器,获取与域名相关的IP地址;

2)与服务端建立连接,包括tcp三手握,安全协议同步过程;

3)连接构建完成, 发送和接收数据, 解码数据.

有三个明显的优化点:

1)直接使用IP地址去删除DNS分析步骤;

(二)每次请求重新建立连接,重新使用连接或使用相同的连接(长连接);

3)压缩数据,减少传输数据大小。

DNS优化

DNS 完整的解析流程很长，会先从本地系统缓存取，若没有就到最近的 DNS 服务器取，若没有再到主域名服务器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过期时间。

这个 DNS 分析机制有几个缺点:

1)缓存时间设置为长,域名没有及时更新,设置为短,许多 DNS分析请求影响请求速度;

2）域名劫持，容易被中间人攻击，或被运营商劫持，把域名解析到第三方 IP 地址，据统计劫持率会达到7%；即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

3)DNS分析过程不受控制,不能保证最快速的IP分析;

4)一个请求只能分析一个域名。

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

实现HTTPDNS的优点概述如下:

1)域名分析和请求分离,所有请求直接使用IP地址,没有DNS分析,APP预定请求HTTPDNS服务器可以更新IP地址;

(二)通过签名和其他手段确保HTTPDNS请求的安全,避免劫持;

3)DNS分析是自控的,确保根据用户位置返回最接近的IP地址,或者根据客户速度测量结果使用最快速的IP地址;

4)一个请求可以分析多个域名。

其余细节就不多说了，HTTPDNS 优点这么多，几乎成为中大型 APP 的标配。至此解决了第一个问题 — DNS 解析耗时的问题，顺便把一部分安全问题 — DNS 劫持也解决了。

连接的优化

第二个问题,是耗时的连接建设问题,这里的主要优化思想是再建连接而不重新建立连接的每一个请求,如何更有效地再建连接,可以说是网络请求速度优化中最重要的点,在这里优化在进程中仍在演变,值得理解。

▼【keep-alive】：

在HTTP协议中有一个保持生命,HTTP1.1默认,打开,在某种程度上,这减少了每次请求通过三个握手建立一个TCP连接所需的时间。原则是不要在请求完成后立即释放连接。而是放入连接池中，如果目前还有其他要求,请求的域名和端口相同,直接从连接池中发送和接收数据,安装连接的时间较短。

事实上,客户端和浏览器都已默认 enabled,以便保持生命,对同个域名不会再有每发一个请求就进行一次建连的情况，一个简单的连接已经不存在了。但有个问题，也就是说,这个保持生机的连接只发送和接收一次请求,在最后处理请求之前,无法接受新的请求。

当多个请求同时启动时,有两个情况:

a）若串行发送请求，可以一直复用一个连接，但速度很慢，每个请求都要等待上个请求完成再进行发送。

( b ) 如果 这些 请求 同时 发出,因此,第一次每个请求必须通过三手的Tcp来创建一个新的连接,虽然连接池中的连接堆栈可以再次使用,但是如果连接池中存在太多的连接,服务最终资源的浪费更大,如果保持的连接数目有限,在平行请求中超过的连接仍需每次连接。

为了解决这个问题,新的HTTP2协议提出了重用多路径来解决这个问题。

▼【多路复用】：

HTTP2 的多路复用机制一样是复用连接，但它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行，也就解决了上面说的并发请求需要建立多条连接带来的问题。

HTTP1.协议中,在连接中传输的数据是按序列传输的,你必须等到最后的请求得到充分处理,下一个请求无法处理,导致这些请求的连接不是全带宽传输,甚至HTTP1.Pipeline1也可以同时发送多个请求,但答复仍以要求的订单返回,只要其中一个请求的response稍微大一点或发生错误，它将阻止随后的请求。

HTTP2多路径重用协议解决了这些问题。它将在连接中传输的数据包入流中,每个流都有标识符,流的发送和接收可能是随机的,不依赖顺序，不会有阻塞的问题,接收器可以根据流的标识符区分请求属于哪个,再进行数据拼接，得到最终数据。

解释如何反复使用这个词,多个路径可以被视为多个连接,多个操作，重复是真正的意义,重复连接或线程.HTTP2在这里是连接的多路径复制,还有与网络有关的I/O多路径复制(select/epoll),允许多个网络请求以事件驱动的方式在同一线程中返回数据。

▼[TCP小组组]:

多重HTTP2复制似乎是完美的解决方案,但还有个问题，就是队头阻塞，这仅限于TCP协议,为了确保数据的可靠性,TCP协议如果在传输过程中丢失一个TCP包,将等待重发的包,才会处理后续的包。HTTP2的多路径复制允许所有请求在相同的连接中进行,中间有一个包丢失，就会阻塞等待重传，所有请求也被封锁。

没有更改TCP协议来优化这个问题是不可能的.但TCP协议取决于操作系统实现和一些硬件定制,改进缓慢，GOOGLE随后提出 QUIC协议,它相当于在UDP协议之上重新定义一个可靠的传输协议,解决TCP的一些缺陷,包括队头阻塞。更多有关具体解决原则的网上资料,可以看看。

QUIC处于初始阶段,只有少数客户端访问,而 QUIC在HTTP2上的最大优势是解决TCP队列封锁,例如安全握手0RTT/

证书压缩等优化 TLS1.3 已跟进，可以用于 HTTP2，并不是独有特性。TCP 队头阻塞在 HTTP2 上对性能的影响有多大，在速度上

QUIC可以为研究带来巨大的进步.

针对移动弱网的优化

移动无线网络环境不稳定,为了优化弱势网络,WeChat有许多实践和分享,包括:

1)增加连接成功率:

复合连接是建立连接时一步步的同步连接,其中一个是连接的,另一个是关闭的。 该程序结合序列化和并行化的优势,以提高在弱网络下连接的成功率,而不增加服务器资源的消耗。

(二)确定最合适的加班时间:

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

3)利用TCP优化算法优化TCP参数:

为优化服务端的TCP协议参数,并开放各种优化算法,适用于业务特性和移动端网络环境,包括RTO初始值、混合慢启动、TLP、F-RTO等。

安全方面

标准协议 TLS 保证了网络传输的安全，前身是 SSL，不断在演进，目前最新是 TLS1.3。常见的 HTTPS 就是 HTTP 协议加上 TLS 安全协议。

安全 协定 一般 处理 两 个 问题 :

1）保证安全；

2)降低加密成本。

在保证安全上：

(一)采用加密算法结合加密传输数据,避免盗窃和变形;

(二)核实对方的身份,避免被第三方误导;

3)加密算法保持灵活性和最新性,防止解密后死亡固定算法的改变,并禁止解密的算法。

降低加密成本上：

(一)利用对称加密算法加密数据,解决对称加密算法低性能和长度限制问题;

2)在安全协议握手后缓存数据,加快第二次连接;

3）加快握手过程：2RTT-> 0RTT。加快握手的思路，这意味着客户端和服务端需要谈判哪些算法加密发送的数据,转换为内部公开密钥和默认算法,他们握手,发送数据,也就是说,你不需要等待手开始发送数据,达到0RTT。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/31262.html。