文中由百度搜索技术性精英团队“蔡锐”原創发布于“百度搜索App技术性”微信公众号，原名为《百度搜索App互联网深层优化系列产品《二》连接优化》，谢谢创作者的不求回报共享。
在《百度搜索APP手机端互联网深层优化实践活动共享(一)：DNS优化篇》里大伙儿掌握到互联网优化一般会优选优化DNS，而下面的HTTP协议变成优化的关键，一般优化者会挑选协议转换，合拼请求，精减数据文件尺寸等方式来对HTTP协议开展优化，认真细致的说这都不属于互联网优化的范围。
HTTP协议的基本是连接，因此大家的《百度搜索APP手机端互联网深层优化实践活动共享(二)：互联网连接优化篇》应时而生，期待对大伙儿在互联网方位的学习培训和实践活动有一定的协助。
本系列产品文章内容文件目录以下：
（文中同歩公布于：.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必须一个RTT（Round-Trip Time，即来回時间），百度搜索App全是根据HTTPDNS服务项目的，因此绝大多数会击中缓存文件，假如退级离开了系统软件DNS，也会击中缓存文件，击中不上的因为是根据UDP协议，因此在连接用时上沒有很大的危害，网上的数据信息也可以表明这一点；
2）TCP要历经SYN，SYN/ACK，ACK三次握手的1.五个RTT，但是ACK和ClientHello合拼了，因此便是一个RTT；
3）TLS（Transport Layer Security，即网络层安全系数协议）必须历经握手和密匙互换两个RTT。
总的来说：DNS、TLS、TCP握手环节用了4个RTT才到ApplicationData环节，也就是数据信息逐渐传送环节。
根据上边的剖析能够小结出，如果我们能尽可能的将TLS和TCP的RTT降低，可能大幅度降低连接用时的時间。
百度搜索App的优化总体目标分成两大类，一类是TLS的连接优化，一类是TCP的连接优化。
下边，大家将各自详细介绍根据这二种优化的构思和实践心得。
TLS的连接优化，必须服务器端和手机客户端都必须适用，互相配合优化方式，包含Session Resumption和False Start。
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中携带它，服务器端假如能寻找配对的信息内容，就可以进行一次迅速握手。
2）Session Ticket：
Session Identifier存有一些缺点，例如手机客户端数次请求要是没有落在同一台设备上就无法找到配对的信息内容，但Session Ticket能够。Session Ticket更像大家熟识的cookie的定义，Session Ticket用仅有服务器端了解的安全密钥数据加密过的对话信息内容，储存在手机客户端上。手机客户端在ClientHello时携带了Session Ticket，网络服务器假如能取得成功破译就可以进行迅速握手。
无论是Session Identifier還是Session Ticket都存有及时性难题，并不是永久性起效，针对这二种方法大伙儿能够查询参考文献【4】。百度搜索App的互联网协议层对这二种方法全是适用的，省掉了TLS握手全过程中证书下载，密匙商议互换的阶段，节约了一个RTT的時间。
False Start的中文翻译是弯道超车，下面的图解读了False Start的协议基本原理。
▲ False Start的协议基本原理
图中很清楚的表明在TLS第一步握手取得成功后，手机客户端在推送Change Cipher Spec Finished的另外逐渐传输数据，服务器端在TLS握手过去进行时立即回到运用数据信息。运用数据信息的推送事实上仍未直到握手所有进行，因此称作弯道超车。
从結果看省掉了一个RTT的時间。False Start有两个必要条件：
一是要根据网络层协议商议ALPN（Application Layer Protocol Negotiation）握手；
二是要适用前向安全性的加密技术。
False Start在没完成握手的状况下就推送了数据信息，前向安全性能够提升安全系数，实际协议完成，大伙儿能够查询参考文献【3】。百度搜索App的互联网协议层对False Start是适用的。
这儿说句题外话，实际上TCP层有一个相近的连接优化方式叫Fast Open，很感兴趣的同学们，能够查询参考文献【5】。
二者针对TLS而言全是节约一个RTT，Session Resumption在第一次握手时還是必须两个RTT，在第二次握手时才可以多路复用降低到一个RTT。False Start是端上的个人行为，故每一次都是会降低到一个RTT。
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应用环节能够无用时的获得连接。下边用四个话题讨论来表述预连接。
难题一：预连接是不是能处理全部互联网请求的提早连接创建？
答：回答是否认的，预连接必须业务流程方开展关键业务流程的评定，对于关键的网站域名开展预连接的创建。
难题二：预连接即然对于的是特殊的网站域名，那麼是如何配置的呢？
答：选用网站域名 连接数的方法开展配备，例如 连接数的限定，不一样互联网库的数量限定不一样，有五个也是有6个，但针对HTTP/2协议，这一连接数就只有是一个。
难题三：预连接是怎样创建的？
答：在互联网库复位的情况下，会依据使用人的配备延迟时间5s开展预连接的创建，主要是考虑到互联网库在冷启下针对运行特性的危害，为了更好地确保互联网库的总体特性，预连接的总数量限定在20个。
难题四：预连接是怎样维持的？
答：在互联网库复位的情况下，除开开展预连接的创建，还会继续建立一个预连接的计时器，这一计时器会每过31s，这一值的设置在于BFE（Baidu Front End，是七层总流量的统一连接系统软件）和BGW（Baidu Gate Way，百度搜索自主研发的四层负载均衡服务平台）对请求超时的极小值设置，依据使用人的配备再次创建连接。
连接复建，将连接再次创建。它处理的情景是App网络状态产生变化，IP地址转变，造成 连接不能用。下边用三个话题讨论来表述连接复建。
难题一：连接复建是不是对于连接池中的全部连接？
答：回答是毫无疑问的。
难题二：连接复建的全过程是哪些的？
答：在网络状态转变的情况下，第一步会消除掉连接池中的idle socket，什么是idle socket？即空余socket，针对从没应用过的空余socket超出60秒消除，针对应用过的空余socket超出90秒消除。第二步复建连接必须等候200ms，目地是等候DNS先复建进行。
难题三：连接复建针对特性有影响吗？
答：出自于特性考虑到，连接复建的连接数量限定是一百个。
▲ 预留连接和复合型连接
预留连接，准备的连接。它处理的情景是一切正常推送一个请求当group内无连接能用的情况下（什么是group？group是管理方法socket的*少模块，內部包括活跃性socket，空余socket，连接每日任务，等候请求）。下边用三个话题讨论来表述预留连接。
难题一：预留连接是不是对于全部请求？
答：回答是毫无疑问的。
难题二：预留连接的全过程是哪些的？
答：当有请求来临时性，连接池中无连接能用，会运行一个计时器打开预留连接，计时器的时间间隔是250Ms，与主连接开展市场竞争，假如主连接由于网络抖动或是网络状态不太好，造成 连接不成功，那麼预留连接就立即推送请求。假如主连接取得成功，那麼预留连接就被撤消掉。
难题三：预留连接的目地是啥？
答：在连接池无连接的状况下，尽量是要建立连接的，在主连接以外加一个预留连接，会大大的提高建立连接的通过率，进而提高客户体验。
复合型连接，即好几条连接。它处理的情景是为了更好地好几个IP地址的连接选择难题。下边用三个话题讨论来表述复合型连接。
难题一：复合型连接是不是对于全部请求？
答：回答是毫无疑问的。复合型连接能够全局性电源开关，百度搜索App目前暂时没有打开复合型连接。
难题二：复合型连接的全过程是哪些的？
答：大家都知道网站域名DNS查看一般状况下能回到好几个IP，大家以域名注册查询回到2个IP为例子
1）假如結果中存有IPv6的详细地址，那麼会优先选择采用IPv6的详细地址，这一标准follow HappyEyeBall体制（可参照系列产品一针对HappyEyeBall的详细介绍）。
2） 接下来这两个IP会按照顺序尝试建立连接，如果第一个IP返回失败，将立即开始连接第二个IP。
3）如果第一个IP率先成功返回，那么第二个IP将被加入连接尝试列表并停止所有尝试连接。
4）如果第一个IP失败，会立刻开始第二个IP的连接。
5）如果第一个IP处于pending状态，那么会启动一个定时器，默认延迟2s会发起第二个IP的连接，如果是多个IP将会递归连接，需要特别说明下，不同的网络制式延迟时间会不一样，这样体验也会更好。
问题三：复合连接的目的是什么？
答：复合连接的好处是提供*优的IP选取机制，但也会带来服务端的高负载，所以使用的时候需要进行综合评估。
百度App目前客户端网络架构由于历史原因还未统一，不过我们正朝着这个目标努力。
我们的中心思想是以系统网络库的API调用接口为中心，上层建立网络门面，供外部便捷调用，底层通过系统机制以AOP的方式将cronet（chromium的net模块）注入进系统网路库，达到双端网络架构统一，能力复用。
下面着重介绍下连接优化在Android和iOS网络架构中的位置及实践。
▲ 连接优化在Android网络架构的位置
百度App的Android网络流量目前都在okhttp之上，上层进行了网络门面的封装，封装内部的实现细节和对外友好的API，目前我们正在进行重构，默认采用Android标准的网络接口HttpURLConnection，它的底层由系统提供的okhttp的实现。
订制方面利用URL Stream Protocol机制将HttpURLConnection底层网络协议栈接管为cronet，供各个业务和基础模块使用，连接优化的所有内容在cronet网络库内部实现。
▲ 连接优化在iOS网络架构的位置
百度App的iOS网络流量目前都在cronet之上，上层我们使用iOS的URL Loading System机制将cronet stack注入进URLSession里，这样我们就可以直接使用URLSession的API进行网络的操作而且更易于系统维护，在上层封装了网络门面，供各个业务和基础模块使用。
在cronet内部实现了预连接（主要针对百度App的几个核心域名进行预连和保活），连接重建（针对所有请求），备用连接（针对所有请求），复合连接（iOS上暂时没有开启），Session Resumption（针对所有请求），False Start（针对所有请求）。
连接优化的收益主要体现在网络时延和网络成功率上，这两点收益需要结合业务来说，以百度App Feed刷新这个典型业务场景为例。
Feed刷新文本请求网络时延降低16%，Feed刷新图片请求网络时延降低12%，可谓收益相当明显。
成功率方面，Feed刷新文本请求成功率提升0.29%，Feed刷新图片请求成功率提升0.23%，也是非常不错的收益。
连接优化是个持续性的话题，没有*优只有更优。上面介绍的百度App的一些经验和做法并不见得完美，但我们会继续深入的优化下去，持续提升百度App的网络性能。
以上优化由百度App团队，内核团队，OP团队共建完成。*后感谢大家的辛苦阅读，希望对你有所帮助，后面会继续推出-百度App网络深度优化系列《三》弱网优化，敬请期待。
[1] ... ild_instructions.md
[2] ... ild_instructions.md
[3] False Start：
[4] Session Resumption：
[5] TCP Fast Open：
（原文链接：点此进入）
《TCP/IP详解-第11章·UDP：用户数据报协议》
《TCP/IP详解-第17章·TCP：传输控制协议》
《TCP/IP详解-第18章·TCP连接的建立与终止》
《TCP/IP详解-第21章·TCP的超时与重传》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《UDP中一个包的大小*大能多大？》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》
《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》
《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
《不为人知的网络编程(五)：UDP的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
《不为人知的网络编程(八)：从数据传输层深度解密HTTP》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差异》
《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
《网络编程懒人入门(六)：史上*通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解HTTP协议》
《网络编程懒人入门(八)：手把手教你写基于TCP的Socket长连接》
《网络编程懒人入门(九)：通俗讲解，有了IP地址，为何还要用MAC地址？》
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊iOS中网络编程长连接的那些事》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上*全移动弱网络优化方法总结》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写Socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》
《脑残式网络编程入门(五)：每天都在用的Ping命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《迈向高阶：优秀Android程序员必知必会的网络基础》
《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图App的移动端DNS优化实践：HTTPS请求耗时减小近半》
《Android程序员必知必会的网络通信传输层协议——UDP和TCP》
《IM开发者的零基础通信技术入门(一)：通信交换技术的百年发展史(上)》
《IM开发者的零基础通信技术入门(二)：通信交换技术的百年发展史(下)》
《IM开发者的零基础通信技术入门(三)：国人通信方式的百年变迁》
《IM开发者的零基础通信技术入门(四)：手机的演进，史上*全移动终端发展史》
《IM开发者的零基础通信技术入门(五)：1G到5G，30年移动通信技术演进史》
《IM开发者的零基础通信技术入门(六)：移动终端的接头人——“基站”技术》
《IM开发者的零基础通信技术入门(七)：移动终端的千里马——“电磁波”》
《IM开发者的零基础通信技术入门(八)：零基础，史上*强“天线”原理扫盲》
《IM开发者的零基础通信技术入门(九)：无线通信网络的中枢——“核心网”》
《IM开发者的零基础通信技术入门(十)：零基础，史上*强5G技术扫盲》
《IM开发者的零基础通信技术入门(十一)：为什么WiFi信号差？一文即懂！》
《IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
《IM开发者的零基础通信技术入门(十三)：为什么手机信号差？一文即懂！》
《IM开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》
《IM开发者的零基础通信技术入门(十五)：理解定位技术，一篇就够》
《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》
《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》
>>更多同类文章 ……
（本文同步发布于：.1.html）
