文中由百度搜索技術性精英團隊“蔡銳”原創發布于“百度搜索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）
