Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 131, comments - 13, trackbacks - 0, articles - 0

本文由百度技术团队“蔡锐”原创发表于“百度App技术”公众号,原题为《百度App网络深度优化系列《二》连接优化》,感谢原作者的无私分享。

一、前言

在《百度APP移动端网络深度优化实践分享(一):DNS优化篇》里大家了解到网络优化一般会首选优化DNS,而接下来的HTTP协议成为优化的重点,一般优化者会选择协议切换,合并请求,精简数据包大小等手段来对HTTP协议进行优化,严谨的说这都不属于网络优化的范畴。

HTTP协议的基础是连接,所以我们的《百度APP移动端网络深度优化实践分享(二):网络连接优化篇》应运而生,希望对大家在网络方向的学习和实践有所帮助。

本系列文章目录如下:

(本文同步发布于:http://www.52im.net/thread-2479-1-1.html

二、相关文章

TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
通俗易懂-深入理解TCP协议(上):理论基础
通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理
理论经典:TCP协议的3次握手与4次挥手过程详解
现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

三、技术背景

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

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。

5.1 Session Resumption

Session Resumption中文意思是会话复用,下图讲解了Session Resumption的协议原理。

▲ Session Resumption的协议原理

通过上图可以看出TLS密钥协商交换的过程没有了,但具体是如何实现的呢?包含两种方式,一种是Sesssion Identifier,一种是Session Ticket。

1)Session Identifier:

Session Identifier中文为会话标识符,更像我们熟知的session的概念。是 TLS 握手中生成的 Session ID。服务端会将Session ID保存起来,客户端也会存储Session ID,在后续的ClientHello中