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