文中由百度搜索技術(shù)性精英團隊“蔡銳”原創(chuàng)發(fā)布于“百度搜索App技術(shù)性”微信公眾號，原名為《百度搜索App互聯(lián)網(wǎng)深層優(yōu)化系列產(chǎn)品《二》連接優(yōu)化》，謝謝創(chuàng)作者的不求回報共享。
在《百度搜索APP手機端互聯(lián)網(wǎng)深層優(yōu)化實踐活動共享(一)：DNS優(yōu)化篇》里大伙兒掌握到互聯(lián)網(wǎng)優(yōu)化一般會優(yōu)選優(yōu)化DNS，而下面的HTTP協(xié)議變成優(yōu)化的關(guān)鍵，一般優(yōu)化者會挑選協(xié)議轉(zhuǎn)換，合拼請求，精減數(shù)據(jù)文件尺寸等方式來對HTTP協(xié)議開展優(yōu)化，認真細致的說這都不屬于互聯(lián)網(wǎng)優(yōu)化的范圍。
HTTP協(xié)議的基本是連接，因此大家的《百度搜索APP手機端互聯(lián)網(wǎng)深層優(yōu)化實踐活動共享(二)：互聯(lián)網(wǎng)連接優(yōu)化篇》應時而生，期待對大伙兒在互聯(lián)網(wǎng)方位的學習培訓和實踐活動有一定的協(xié)助。
本系列產(chǎn)品文章內(nèi)容文件目錄以下：
（文中同歩公布于：.1.html）
《TCP/IP詳細說明-第17章·TCP：傳送操縱協(xié)議》
《TCP/IP詳細說明-第18章·TCP連接的創(chuàng)建與停止》
《TCP/IP詳解-第21章·TCP的超時與重傳》
《淺顯易懂-深層次了解TCP協(xié)議（上）：理論基礎》
《淺顯易懂-深層次了解TCP協(xié)議（下）：RTT、滑動窗口、時延解決》
《基礎理論經(jīng)典：TCP協(xié)議的3次握手與4次招手全過程詳細說明》
《當代手機端互聯(lián)網(wǎng)短連接的優(yōu)化方式小結(jié)：請求速率、弱網(wǎng)融入、安全防范措施》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《手機端IM開發(fā)人員必看(二)：史上***牛全挪動弱互聯(lián)網(wǎng)優(yōu)化方式 小結(jié)》
連接優(yōu)化必須處理兩個核心難題：
1）連接創(chuàng)建用時較長，造成 請求的總時間拉長，從而危害客戶體驗；
2）在變化多端的網(wǎng)絡空間下，連接創(chuàng)建的全過程很有可能會不成功，造成 通過率降低，從而危害客戶體驗。
百度搜索App安裝著億級總流量，針對每一個請求都必須追求完美用時短，成功率較高的感受。從協(xié)議視角考慮，怎樣才可以保證這一點呢？***先大家看來下創(chuàng)建連接用時的基本原理。
▲ 創(chuàng)建連接用時的基本原理
從圖中大家能清楚的看得出：
1）DNS Query必須一個RTT（Round-Trip Time，即來回時間），百度搜索App全是根據(jù)HTTPDNS服務項目的，因此絕大多數(shù)會擊中緩存文件，假如退級離開了系統(tǒng)軟件DNS，也會擊中緩存文件，擊中不上的因為是根據(jù)UDP協(xié)議，因此在連接用時上沒有很大的危害，網(wǎng)上的數(shù)據(jù)信息也可以表明這一點；
2）TCP要歷經(jīng)SYN，SYN/ACK，ACK三次握手的1.五個RTT，但是ACK和ClientHello合拼了，因此便是一個RTT；
3）TLS（Transport Layer Security，即網(wǎng)絡層安全系數(shù)協(xié)議）必須歷經(jīng)握手和密匙互換兩個RTT。
總的來說：DNS、TLS、TCP握手環(huán)節(jié)用了4個RTT才到ApplicationData環(huán)節(jié)，也就是數(shù)據(jù)信息逐漸傳送環(huán)節(jié)。
根據(jù)上邊的剖析能夠小結(jié)出，如果我們能盡可能的將TLS和TCP的RTT降低，可能大幅度降低連接用時的時間。
百度搜索App的優(yōu)化總體目標分成兩大類，一類是TLS的連接優(yōu)化，一類是TCP的連接優(yōu)化。
下邊，大家將各自詳細介紹根據(jù)這二種優(yōu)化的構(gòu)思和實踐心得。
TLS的連接優(yōu)化，必須服務器端和手機客戶端都必須適用，互相配合優(yōu)化方式，包含Session Resumption和False Start。
Session Resumption中文翻譯是對話多路復用，下面的圖解讀了Session Resumption的協(xié)議基本原理。
▲ Session Resumption的協(xié)議基本原理
根據(jù)圖中能夠看得出TLS密匙商議互換的全過程沒了，但實際是怎樣完成的呢？包括二種方法，一種是Sesssion Identifier，一種是Session Ticket。
1）Session Identifier：
Session Identifier漢語為對話標志符，更像大家熟識的session的定義。是 TLS 握手中形成的 Session ID。服務器端會將Session ID保存，手機客戶端也會儲存Session ID，在事后的ClientHello中攜帶它，服務器端假如能尋找配對的信息內(nèi)容，就可以進行一次迅速握手。
2）Session Ticket：
Session Identifier存有一些缺點，例如手機客戶端數(shù)次請求要是沒有落在同一臺設備上就無法找到配對的信息內(nèi)容，但Session Ticket能夠。Session Ticket更像大家熟識的cookie的定義，Session Ticket用僅有服務器端了解的安全密鑰數(shù)據(jù)加密過的對話信息內(nèi)容，儲存在手機客戶端上。手機客戶端在ClientHello時攜帶了Session Ticket，網(wǎng)絡服務器假如能取得成功破譯就可以進行迅速握手。
無論是Session Identifier還是Session Ticket都存有及時性難題，并不是永久性起效，針對這二種方法大伙兒能夠查詢參考文獻【4】。百度搜索App的互聯(lián)網(wǎng)協(xié)議層對這二種方法全是適用的，省掉了TLS握手全過程中證書下載，密匙商議互換的階段，節(jié)約了一個RTT的時間。
False Start的中文翻譯是彎道超車，下面的圖解讀了False Start的協(xié)議基本原理。
▲ False Start的協(xié)議基本原理
圖中很清楚的表明在TLS第一步握手取得成功后，手機客戶端在推送Change Cipher Spec Finished的另外逐漸傳輸數(shù)據(jù)，服務器端在TLS握手過去進行時立即回到運用數(shù)據(jù)信息。運用數(shù)據(jù)信息的推送事實上仍未直到握手所有進行，因此稱作彎道超車。
從結(jié)果看省掉了一個RTT的時間。False Start有兩個必要條件：
一是要根據(jù)網(wǎng)絡層協(xié)議商議ALPN（Application Layer Protocol Negotiation）握手；
二是要適用前向安全性的加密技術(shù)。
False Start在沒完成握手的狀況下就推送了數(shù)據(jù)信息，前向安全性能夠提升安全系數(shù)，實際協(xié)議完成，大伙兒能夠查詢參考文獻【3】。百度搜索App的互聯(lián)網(wǎng)協(xié)議層對False Start是適用的。
這兒說句題外話，實際上TCP層有一個相近的連接優(yōu)化方式叫Fast Open，很感興趣的同學們，能夠查詢參考文獻【5】。
二者針對TLS而言全是節(jié)約一個RTT，Session Resumption在第一次握手時還是必須兩個RTT，在第二次握手時才可以多路復用降低到一個RTT。False Start是端上的個人行為，故每一次都是會降低到一個RTT。
TCP的連接優(yōu)化，大家先從連接池談起，***先使我們來了解下連接池都有哪些種類。
▲ 連接池的種類
圖中展現(xiàn)了連接池的不一樣種類，全是大伙兒廣為人知的協(xié)議連接池，有低等連接池，包括TCP連接池（管理方法HTTP請求的連接）和WebSocket連接池（管理方法WebSocket連接）。
有高級連接池，包含HTTP代理商連接池（管理方法HTTP代理商請求的連接），SpdySession連接池（管理方法SPDY和HTTP/2請求的連接），SOCKS連接池（管理方法SOCKS和SOCKS5代理商的連接），SSL連接池（管理方法HTTPS請求的連接）。
不一樣種類的連接池以組成的方式相互之間多路復用工作能力：
1）SSL連接池管理方法的是SSLSocket，但SSLSocket又取決于TCP連接池出示的TCPSocket；
2）HTTP代理商連接池假如走HTTP協(xié)議，那麼就必須TCP連接池出示TCPSocket，假如走HTTPS協(xié)議，那麼就必須SSL連接池出示SSLSocket；
3）SpdySession連接池依靠SSL連接池出示SSLSocket，這兒必須表明下，盡管HTTP/2協(xié)議沒有強制性關(guān)聯(lián)HTTPS，可是在具體開發(fā)設計中的確全是關(guān)聯(lián)HTTPS，百度搜索App應用ALPN來商議HTTP/2；
4）SOCKS連接池管理方法的SOCKSSocket和SOCKS5Socket都必須依靠TCP連接池出示的TCPSocket，盡管SOCKS5適用UDP，但cronet互聯(lián)網(wǎng)庫暫時沒有完成；
5）WebSocket連接池依靠TCP連接池出示的TCPSocket，申明下這兒沒有表明WSS（Web Socket Secure）的狀況。
TCP連接優(yōu)化是一個非常復雜的內(nèi)容，百度搜索App干了目的性情景優(yōu)化，包含預連接，連接復建，預留連接，復合型連接。
▲ 預連接和連接復建
預連接：事先建立好的連接。它處理的情景是在App應用環(huán)節(jié)能夠無用時的獲得連接。下邊用四個話題討論來表述預連接。
難題一：預連接是不是能處理全部互聯(lián)網(wǎng)請求的提早連接創(chuàng)建？
答：回答是否認的，預連接必須業(yè)務流程方開展關(guān)鍵業(yè)務流程的評定，對于關(guān)鍵的網(wǎng)站域名開展預連接的創(chuàng)建。
難題二：預連接即然對于的是特殊的網(wǎng)站域名，那麼是如何配置的呢？
答：選用網(wǎng)站域名 連接數(shù)的方法開展配備，例如 連接數(shù)的限定，不一樣互聯(lián)網(wǎng)庫的數(shù)量限定不一樣，有五個也是有6個，但針對HTTP/2協(xié)議，這一連接數(shù)就只有是一個。
難題三：預連接是怎樣創(chuàng)建的？
答：在互聯(lián)網(wǎng)庫復位的情況下，會依據(jù)使用人的配備延遲時間5s開展預連接的創(chuàng)建，主要是考慮到互聯(lián)網(wǎng)庫在冷啟下針對運行特性的危害，為了更好地確?；ヂ?lián)網(wǎng)庫的總體特性，預連接的總數(shù)量限定在20個。
難題四：預連接是怎樣維持的？
答：在互聯(lián)網(wǎng)庫復位的情況下，除開開展預連接的創(chuàng)建，還會繼續(xù)建立一個預連接的計時器，這一計時器會每過31s，這一值的設置在于BFE（Baidu Front End，是七層總流量的統(tǒng)一連接系統(tǒng)軟件）和BGW（Baidu Gate Way，百度搜索自主研發(fā)的四層負載均衡服務平臺）對請求超時的極小值設置，依據(jù)使用人的配備再次創(chuàng)建連接。
連接復建，將連接再次創(chuàng)建。它處理的情景是App網(wǎng)絡狀態(tài)產(chǎn)生變化，IP地址轉(zhuǎn)變，造成 連接不能用。下邊用三個話題討論來表述連接復建。
難題一：連接復建是不是對于連接池中的全部連接？
答：回答是毫無疑問的。
難題二：連接復建的全過程是哪些的？
答：在網(wǎng)絡狀態(tài)轉(zhuǎn)變的情況下，第一步會消除掉連接池中的idle socket，什么是idle socket？即空余socket，針對從沒應用過的空余socket超出60秒消除，針對應用過的空余socket超出90秒消除。第二步復建連接必須等候200ms，目地是等候DNS先復建進行。
難題三：連接復建針對特性有影響嗎？
答：出自于特性考慮到，連接復建的連接數(shù)量限定是一百個。
▲ 預留連接和復合型連接
預留連接，準備的連接。它處理的情景是一切正常推送一個請求當group內(nèi)無連接能用的情況下（什么是group？group是管理方法socket的***少模塊，內(nèi)部包括活躍性socket，空余socket，連接每日任務，等候請求）。下邊用三個話題討論來表述預留連接。
難題一：預留連接是不是對于全部請求？
答：回答是毫無疑問的。
難題二：預留連接的全過程是哪些的？
答：當有請求來臨時性，連接池中無連接能用，會運行一個計時器打開預留連接，計時器的時間間隔是250Ms，與主連接開展市場競爭，假如主連接由于網(wǎng)絡抖動或是網(wǎng)絡狀態(tài)不太好，造成 連接不成功，那麼預留連接就立即推送請求。假如主連接取得成功，那麼預留連接就被撤消掉。
難題三：預留連接的目地是啥？
答：在連接池無連接的狀況下，盡量是要建立連接的，在主連接以外加一個預留連接，會大大的提高建立連接的通過率，進而提高客戶體驗。
復合型連接，即好幾條連接。它處理的情景是為了更好地好幾個IP地址的連接選擇難題。下邊用三個話題討論來表述復合型連接。
難題一：復合型連接是不是對于全部請求？
答：回答是毫無疑問的。復合型連接能夠全局性電源開關(guān)，百度搜索App目前暫時沒有打開復合型連接。
難題二：復合型連接的全過程是哪些的？
答：大家都知道網(wǎng)站域名DNS查看一般狀況下能回到好幾個IP，大家以域名注冊查詢回到2個IP為例子
1）假如結(jié)果中存有IPv6的詳細地址，那麼會優(yōu)先選擇采用IPv6的詳細地址，這一標準follow HappyEyeBall體制（可參照系列產(chǎn)品一針對HappyEyeBall的詳細介紹）。
2） 接下來這兩個IP會按照順序嘗試建立連接，如果第一個IP返回失敗，將立即開始連接第二個IP。
3）如果第一個IP率先成功返回，那么第二個IP將被加入連接嘗試列表并停止所有嘗試連接。
4）如果第一個IP失敗，會立刻開始第二個IP的連接。
5）如果第一個IP處于pending狀態(tài)，那么會啟動一個定時器，默認延遲2s會發(fā)起第二個IP的連接，如果是多個IP將會遞歸連接，需要特別說明下，不同的網(wǎng)絡制式延遲時間會不一樣，這樣體驗也會更好。
問題三：復合連接的目的是什么？
答：復合連接的好處是提供***優(yōu)的IP選取機制，但也會帶來服務端的高負載，所以使用的時候需要進行綜合評估。
百度App目前客戶端網(wǎng)絡架構(gòu)由于歷史原因還未統(tǒng)一，不過我們正朝著這個目標努力。
我們的中心思想是以系統(tǒng)網(wǎng)絡庫的API調(diào)用接口為中心，上層建立網(wǎng)絡門面，供外部便捷調(diào)用，底層通過系統(tǒng)機制以AOP的方式將cronet（chromium的net模塊）注入進系統(tǒng)網(wǎng)路庫，達到雙端網(wǎng)絡架構(gòu)統(tǒng)一，能力復用。
下面著重介紹下連接優(yōu)化在Android和iOS網(wǎng)絡架構(gòu)中的位置及實踐。
▲ 連接優(yōu)化在Android網(wǎng)絡架構(gòu)的位置
百度App的Android網(wǎng)絡流量目前都在okhttp之上，上層進行了網(wǎng)絡門面的封裝，封裝內(nèi)部的實現(xiàn)細節(jié)和對外友好的API，目前我們正在進行重構(gòu)，默認采用Android標準的網(wǎng)絡接口HttpURLConnection，它的底層由系統(tǒng)提供的okhttp的實現(xiàn)。
訂制方面利用URL Stream Protocol機制將HttpURLConnection底層網(wǎng)絡協(xié)議棧接管為cronet，供各個業(yè)務和基礎模塊使用，連接優(yōu)化的所有內(nèi)容在cronet網(wǎng)絡庫內(nèi)部實現(xiàn)。
▲ 連接優(yōu)化在iOS網(wǎng)絡架構(gòu)的位置
百度App的iOS網(wǎng)絡流量目前都在cronet之上，上層我們使用iOS的URL Loading System機制將cronet stack注入進URLSession里，這樣我們就可以直接使用URLSession的API進行網(wǎng)絡的操作而且更易于系統(tǒng)維護，在上層封裝了網(wǎng)絡門面，供各個業(yè)務和基礎模塊使用。
在cronet內(nèi)部實現(xiàn)了預連接（主要針對百度App的幾個核心域名進行預連和?；睿?，連接重建（針對所有請求），備用連接（針對所有請求），復合連接（iOS上暫時沒有開啟），Session Resumption（針對所有請求），F(xiàn)alse Start（針對所有請求）。
連接優(yōu)化的收益主要體現(xiàn)在網(wǎng)絡時延和網(wǎng)絡成功率上，這兩點收益需要結(jié)合業(yè)務來說，以百度App Feed刷新這個典型業(yè)務場景為例。
Feed刷新文本請求網(wǎng)絡時延降低16%，F(xiàn)eed刷新圖片請求網(wǎng)絡時延降低12%，可謂收益相當明顯。
成功率方面，F(xiàn)eed刷新文本請求成功率提升0.29%，F(xiàn)eed刷新圖片請求成功率提升0.23%，也是非常不錯的收益。
連接優(yōu)化是個持續(xù)性的話題，沒有***優(yōu)只有更優(yōu)。上面介紹的百度App的一些經(jīng)驗和做法并不見得完美，但我們會繼續(xù)深入的優(yōu)化下去，持續(xù)提升百度App的網(wǎng)絡性能。
以上優(yōu)化由百度App團隊，內(nèi)核團隊，OP團隊共建完成。***后感謝大家的辛苦閱讀，希望對你有所幫助，后面會繼續(xù)推出-百度App網(wǎng)絡深度優(yōu)化系列《三》弱網(wǎng)優(yōu)化，敬請期待。
[1] ... ild_instructions.md
[2] ... ild_instructions.md
[3] False Start：
[4] Session Resumption：
[5] TCP Fast Open：
（原文鏈接：點此進入）
《TCP/IP詳解-第11章·UDP：用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解-第17章·TCP：傳輸控制協(xié)議》
《TCP/IP詳解-第18章·TCP連接的建立與終止》
《TCP/IP詳解-第21章·TCP的超時與重傳》
《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎》
《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網(wǎng)絡通訊協(xié)議關(guān)系圖（中文珍藏版）》
《UDP中一個包的大小***大能多大？》
《P2P技術(shù)詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三)：P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡編程(一)：單臺服務器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡編程(二)：上一個10年，著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》
《高性能網(wǎng)絡編程(四)：從C10K到C10M高性能網(wǎng)絡應用的理論探索》
《高性能網(wǎng)絡編程(五)：一文讀懂高性能網(wǎng)絡編程中的I/O模型》
《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》
《不為人知的網(wǎng)絡編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡編程(三)：關(guān)閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網(wǎng)絡編程(八)：從數(shù)據(jù)傳輸層深度解密HTTP》
《網(wǎng)絡編程懶人入門(一)：快速理解網(wǎng)絡通信協(xié)議（上篇）》
《網(wǎng)絡編程懶人入門(二)：快速理解網(wǎng)絡通信協(xié)議（下篇）》
《網(wǎng)絡編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》
《網(wǎng)絡編程懶人入門(六)：史上***通俗的集線器、交換機、路由器功能原理入門》
《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《網(wǎng)絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網(wǎng)絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》
《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應、安全保障》
《聊聊iOS中網(wǎng)絡編程長連接的那些事》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上***全移動弱網(wǎng)絡優(yōu)化方法總結(jié)》
《IPv6技術(shù)詳解：基本概念、應用現(xiàn)狀、技術(shù)實踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應用現(xiàn)狀、技術(shù)實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網(wǎng)絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網(wǎng)絡編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？》
《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術(shù)原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網(wǎng)絡通信傳輸層協(xié)議——UDP和TCP》
《IM開發(fā)者的零基礎通信技術(shù)入門(一)：通信交換技術(shù)的百年發(fā)展史(上)》
《IM開發(fā)者的零基礎通信技術(shù)入門(二)：通信交換技術(shù)的百年發(fā)展史(下)》
《IM開發(fā)者的零基礎通信技術(shù)入門(三)：國人通信方式的百年變遷》
《IM開發(fā)者的零基礎通信技術(shù)入門(四)：手機的演進，史上***全移動終端發(fā)展史》
《IM開發(fā)者的零基礎通信技術(shù)入門(五)：1G到5G，30年移動通信技術(shù)演進史》
《IM開發(fā)者的零基礎通信技術(shù)入門(六)：移動終端的接頭人——“基站”技術(shù)》
《IM開發(fā)者的零基礎通信技術(shù)入門(七)：移動終端的千里馬——“電磁波”》
《IM開發(fā)者的零基礎通信技術(shù)入門(八)：零基礎，史上***強“天線”原理掃盲》
《IM開發(fā)者的零基礎通信技術(shù)入門(九)：無線通信網(wǎng)絡的中樞——“核心網(wǎng)”》
《IM開發(fā)者的零基礎通信技術(shù)入門(十)：零基礎，史上***強5G技術(shù)掃盲》
《IM開發(fā)者的零基礎通信技術(shù)入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發(fā)者的零基礎通信技術(shù)入門(十二)：上網(wǎng)卡頓？網(wǎng)絡掉線？一文即懂！》
《IM開發(fā)者的零基礎通信技術(shù)入門(十三)：為什么手機信號差？一文即懂！》
《IM開發(fā)者的零基礎通信技術(shù)入門(十四)：高鐵上無線上網(wǎng)有多難？一文即懂！》
《IM開發(fā)者的零基礎通信技術(shù)入門(十五)：理解定位技術(shù)，一篇就夠》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(一)：DNS優(yōu)化篇》
《百度APP移動端網(wǎng)絡深度優(yōu)化實踐分享(二)：網(wǎng)絡連接優(yōu)化篇》
>>更多同類文章 ……
（本文同步發(fā)布于：.1.html）
