即时通讯移动端开发之网络连接优化

原创已于 2023-04-03 10:36:20 修改 · 271 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #服务器 #java

于 2022-07-29 09:54:18 首次发布

技术背景

连接优化需要解决两个核心问题：

1）连接建立耗时较长，导致请求的总时长变长，进而影响用户体验；

2）在多变的网络环境下，连接建立的过程可能会失败，导致成功率下降，进而影响用户体验。

百度App承载着亿级流量，对于每一个请求都需要追求耗时短，成功率高的体验。从协议角度出发，如何才能做到这一点呢？首先我们来看下建立连接耗时的原理。

我们能清晰的看出：

1）DNS Query需要1个RTT（Round-Trip

Time，即往返时间），百度App都是基于HTTPDNS服务的，所以大部分会命中缓存，如果降级走了系统DNS，也会命中缓存，命中不了的由于是基于UDP协议，所以在连接耗时上没有太大的影响，线上的数据也能说明这点；

2）TCP要经历SYN，SYN/ACK，ACK三次握手的1.5个RTT，不过ACK和ClientHello合并了，所以就是1个RTT；

3）TLS（Transport Layer Security，即传输层安全性协议）需要经过握手和密钥交换2个RTT。

综上所述：DNS、TLS、TCP握手阶段用了4个RTT才到了ApplicationData阶段，也就是数据开始传输阶段。

通过上面的分析可以总结出，如果我们能尽量的将TLS和TCP的RTT减少，将会大大降低连接耗时的时间。

连接优化我们都能做什么？

百度App的优化目标分为两类，一类是TLS的连接优化，一类是TCP的连接优化。

下面，我们将分别介绍基于这两种优化的思路和实践总结。

连接优化之“TLS的连接优化”

TLS的连接优化，需要服务端和客户端都需要支持，共同完成优化手段，包括Session Resumption和False Start。

TLS密钥协商交换的过程没有了，但具体是如何实现的呢？包含两种方式，一种是Sesssion Identifier，一种是Session Ticket。

1）Session Identifier：

Session Identifier中文为会话标识符，更像我们熟知的session的概念。是 TLS 握手中生成的 Session ID。服务端会将Session ID保存起来，客户端也会存储Session ID，在后续的ClientHello中带上它，服务端如果能找到匹配的信息，就可以完成一次快速握手。

2）Session Ticket：

Session Identifier存在一些弊端，比如客户端多次请求如果没有落在同一台机器上就无法找到匹配的信息，但Session Ticket可以。Session Ticket更像我们熟知的cookie的概念，Session Ticket用只有服务端知道的安全密钥加密过的会话信息，保存在客户端上。客户端在ClientHello时带上了Session Ticket，服务器如果能成功解密就可以完成快速握手。

不管是Session Identifier还是Session Ticket都存在时效性问题，不是永久生效，对于这两种方式大家可以查看参考资料【4】。百度App的网络协议层对这两种方式都是支持的，省去了TLS握手过程中证书下载，密钥协商交换的环节，节省了1个RTT的时间。

在TLS第一步握手成功后，客户端在发送Change Cipher Spec Finished的同时开始数据传输，服务端在TLS握手完成时直接返回应用数据。应用数据的发送实际上并未等到握手全部完成，所以称之为抢跑。即时通讯聊天软件app开发可以加蔚可云咨询

从结果看省去了1个RTT的时间。False Start有两个前提条件：

一是要通过应用层协议协商ALPN（Application Layer Protocol Negotiation）握手；

二是要支持前向安全的加密算法。

Session Resumption和False Start的区别

两者对于TLS来说都是节省一个RTT，Session Resumption在第一次握手时还是需要2个RTT，在第二次握手时才能复用减少到1个RTT。False Start是端上的行为，故每次都会减少到1个RTT。

连接优化之“TCP的连接优化”

TCP的连接优化，我们先从连接池说起，首先让我们来认识下连接池都有哪些类型。

连接池的不同类型，都是大家耳熟能详的协议连接池，有低级连接池，包含TCP连接池（管理HTTP请求的连接）和WebSocket连接池（管理WebSocket连接）。

有高级连接池，包括HTTP代理连接池（管理HTTP代理请求的连接），SpdySession连接池（管理SPDY和HTTP/2请求的连接），SOCKS连接池（管理SOCKS和SOCKS5代理的连接），SSL连接池（管理HTTPS请求的连接）。

不同类型的连接池以组合的形式互相复用能力：

1）SSL连接池管理的是SSLSocket，但SSLSocket又依赖于TCP连接池提供的TCPSocket；

2）HTTP代理连接池如果走HTTP协议，那么就需要TCP连接池提供TCPSocket，如果走HTTPS协议，那么就需要SSL连接池提供SSLSocket；

3）SpdySession连接池依赖SSL连接池提供SSLSocket，这里需要说明下，虽然HTTP/2协议没有强制绑定HTTPS，但是在实际开发中确实都是绑定HTTPS，百度App使用ALPN来协商HTTP/2；

4）SOCKS连接池管理的SOCKSSocket和SOCKS5Socket都需要依赖TCP连接池提供的TCPSocket，虽然SOCKS5支持UDP，但cronet网络库暂时没有实现；

5）WebSocket连接池依赖TCP连接池提供的TCPSocket，声明下这里没有说明WSS（Web Socket Secure）的情况。

TCP连接优化是一个比较复杂的内容，百度App做了针对性场景优化，包括预连接，连接重建，备用连接，复合连接。

预连接和连接重建

预连接：预先创建好的连接。它解决的场景是在App使用阶段可以无耗时的获取连接。下面用四个问答来解释预连接。

问题一：预连接是否能解决所有网络请求的提前连接建立？

答：答案是否定的，预连接需要业务方进行核心业务的评估，针对核心的域名进行预连接的建立。

问题二：预连接既然针对的是特定的域名，那么是如何配置的呢？

答：采用域名+连接数的方式进行配置，表示给a.baidu.com这个域名配置两条预连接，这里要说明下，在HTTP/1.x协议下，网络库的实现都会对于单域名有最大连接数的限制，不同网络库的个数限制不一样，有5个也有6个，但对于HTTP/2协议，这个连接数就只能是1个。

问题三：预连接是如何建立的？

答：在网络库初始化的时候，会根据使用者的配置延迟5s进行预连接的建立，主要是考虑网络库在冷启动下对于启动性能的影响，为了保证网络库的整体性能，预连接的总个数限制在20个。

问题四：预连接是如何保持的？

答：在网络库初始化的时候，除了进行预连接的建立，还会创建一个预连接的定时器，这个定时器会每隔31s，这个值的设定取决于BFE（Baidu Front End，是七层流量的统一接入系统）和BGW（Baidu Gate Way，百度自主研发的四层负载均衡平台）对超时的最小值设定，根据使用者的配置重新建立连接。

连接重建

连接重建，将连接重新建立。它解决的场景是App网络状态发生变化，IP地址变化，导致连接不可用。下面用三个问答来解释连接重建。

问题一：连接重建是否针对连接池里的所有连接？

答：答案是肯定的。

问题二：连接重建的过程是什么样的？

答：在网络状态变化的时候，第一步会清除掉连接池里的idle socket，何为idle socket？即空闲socket，对于从未使用过的空闲socket超过60秒清除，对于使用过的空闲socket超过90秒清除。第二步重建连接需要等待200ms，目的是等待DNS先重建完成。

问题三：连接重建对于性能有影响吗？

答：出于性能考虑，连接重建的连接个数限制是100个。

备用连接和复合连接

备用连接，预备的连接。它解决的场景是正常发送一个请求当group内无连接可用的时候（何为group？group是管理socket的最小单元，内部包含活跃socket，空闲socket，连接任务，等待请求）。下面用三个问答来解释备用连接。

问题一：备用连接是否针对所有请求？

答：答案是肯定的。