1、點評

互聯(lián)網(wǎng)發(fā)展至今已經(jīng)高度發(fā)達，而對于互聯(lián)網(wǎng)應用（尤其即時通訊技術(shù)這一塊）的開發(fā)者來說，網(wǎng)絡編程是基礎中的基礎，只有更好地理解相關基礎知識，對于應用層的開發(fā)才能做到游刃有余。

對于Android程序員來說，如果您覺得本文內(nèi)容稍顯枯燥，可以看看即時通訊網(wǎng)之前整理過的一篇類似文章《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡基礎》，該文內(nèi)容更偏向于知識點的概括。

如果您希望更系統(tǒng)地學習網(wǎng)絡編程方面的知識，可以讀一讀以下專為初學者整理的系列文章或資料：

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時與重傳》

《網(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地址？》

《腦殘式網(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)換又是什么鬼？》

學習交流：

- 即時通訊/推送技術(shù)開發(fā)交流4群：101279154[推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同發(fā)布于：http://www.52im.net/thread-2216-1-1.html）

2、前言

相信計算機專業(yè)的朋友在大學都學過《計算機網(wǎng)絡》這門課程，但據(jù)我個人了解計算機專業(yè)普通大學生對計算機網(wǎng)絡的了解淺之又淺，很多人說這門學科沒用，開發(fā)的時候也用不著，其實這樣想是不對的。

說一下我個人的體會，之前老是聽別人說OkHttp怎么這么好用，但用完之后感覺和其他框架沒多大區(qū)別啊，于是就想著去專研鉆研，當時差不多花了一個星期左右把OkHttp源碼看了一遍，代碼時看懂了，但是有些地方不知道為什么這樣做，所以我就下決心把計算機網(wǎng)絡重新學一遍，學完各種網(wǎng)絡協(xié)議后再看OkHttp源碼突然有種煥然一新的感覺。

在本篇文章里，會為大家講述作為Android程序員的我，對于網(wǎng)絡通信傳輸層協(xié)議UDP、TCP的理解，希望能給你帶來啟發(fā)。

參考書籍：《計算機網(wǎng)絡-謝希仁版》

參考教程：《韓立剛視頻教程》

3、關于作者

網(wǎng)名：zskingking，博客地址：https://www.jianshu.com/u/274367e58472

4、UDP協(xié)議

4.1 概述

UDP的全稱是User Date Protocal，翻譯成中文是用戶數(shù)據(jù)包協(xié)議，它是一種不可靠的傳輸協(xié)議，一般情況下一個數(shù)據(jù)包(大概64K)能完成的數(shù)據(jù)通訊使用UDP協(xié)議，比如請求DNS解析IP地址使用的就是UDP協(xié)議，因為解析IP一個數(shù)據(jù)包完全足夠。還有就是文字聊天一般用的也是UDP，通常一段文字消息一個數(shù)據(jù)包就足夠了，如果發(fā)送失敗就再次發(fā)送，反正就一個數(shù)據(jù)包。還有一種傳遞大量數(shù)據(jù)包使用UDP協(xié)議的場景，就是廣播，類似對講機之類的，接收方并不一定能接收到所有的數(shù)據(jù)包。所以說UDP是一種不可靠的傳輸協(xié)議。

UDP的主要特點：

1）UDP是無連接的，即發(fā)送數(shù)據(jù)之前是不需要建立連接的；

2）UDP使用盡最大努力交付，不保證可靠交付，同時不使用阻塞控制；

3）UDP是面向報文的，UDP沒有擁塞控制，很適合多媒體通信的要求；

4）UDP支持一對一、一對多、多對一、多對多的交互通信；

5）UDP的首部開銷小，只需要8個字節(jié)。

4.2 UDP首部

首先我們先用一張圖來表示UDP的首部，UDP首部如下圖：

UDP首部總共是8個字節(jié)，其中源端口、目的端口、長度、檢驗和各占2字節(jié)。有的同學可能要問了，你怎么沒把偽首部加進去呢？這個我來講一下，偽首部顧名思義，就是假的首部，它是不會跟隨UDP數(shù)據(jù)報進行傳輸?shù)模嬖诘囊饬x就是為了計算UDP首部中的檢驗和。

UDP首部存儲的信息：

1）源端口：即發(fā)送方的端口號，需要接收方回應時選用，不需要全為0；

2）目的端口：接收方端口號；

3）長度：UDP數(shù)據(jù)報長度，最小為0(只存在首部)；

4）檢驗和： 檢驗UDP數(shù)據(jù)報在傳輸中是否出錯，是就丟棄。

UDP首部組裝完畢后會將完整的數(shù)據(jù)報發(fā)送到網(wǎng)絡層，跟IP數(shù)據(jù)報首部組成IP數(shù)據(jù)報再向上發(fā)送。

5、TCP協(xié)議

5.1 概述

TCP全稱為Transmission Control Protocol(傳輸控制協(xié)議)，是一種可靠的面向連接傳輸協(xié)議，同時它也是一種client-server模式的協(xié)議，因為是可靠的傳輸協(xié)議，所以它比UDP要復雜的多。

首先說一下TCP具有的一些特性：

1）TCP是面向連接的傳輸協(xié)議；

2）每一條TCP有且只有兩個端點，為一對一關系；

3）TCP提供可靠交互的服務；

4）TCP提供全雙工通信，全雙工為即可傳輸又可接收；

5）TCP是面向字節(jié)流的。

TCP的應用場景：

如果兩個臺主機想要在網(wǎng)絡上傳遞一部1G大小的電影，需要通過什么協(xié)議進行傳輸呢？UDP為不可靠傳輸協(xié)議，傳遞過程中可能會出現(xiàn)丟包，所以UDP不行，而傳輸層就兩個協(xié)議，一個是UDP一個是TCP，UDP傳輸效率高但不可靠，TCP傳輸效率低但它是可靠的，所以想要將傳遞的文件完整的到達目的地可以通過TCP協(xié)議進行傳輸。

5.2 TCP連接建立與斷開

在5.1中介紹TCP特性的時候提到，TCP是面向連接的，即TCP在傳輸數(shù)據(jù)前要建立連接，數(shù)據(jù)傳輸完畢后要斷開連接。TCP連接必須要由客戶端發(fā)起。

【5.2.1】TCP建立連接過程：

如上圖2所示：客戶端向服務端發(fā)起建立連接的請求，服務端接收到請求后告訴客戶端：“我準備好了”，客戶端接收到服務端的響應再給服務端一個確認，此過程總共分為三步被大家親切的成為：“三次握手”，三次握手后一個可靠的連接就建立了，隨后就可以進行數(shù)據(jù)的傳輸了，圖中SYN、ACK這些字段我會在TCP首部中詳細介紹，此處大家可以忽略。

疑點： TCP建立連接為什么是三次握手？兩次握手不是已經(jīng)可以建立一個連接了嗎？網(wǎng)絡上很多文章對此處的描述大多是輕描淡寫，還有的說是必須要三次握手才能建立一個可靠連接，其實這樣說是不對的，當時我也因為這些不負責任的回答費解了很久。一般情況下，兩次握手是可以建立一個TCP連接的，在《計算機網(wǎng)絡-謝希仁》中大概是這樣解釋的:“第三次握手是為了避免服務端造成資源的浪費”，為什么這樣說呢？我來給大家舉一個例子：

假如TCP是兩次握手：主機A向主機B發(fā)送了一個建立連接的請求x，但這個請求在半路里給堵了，主機A沒有得到主機B的響應于是又發(fā)了一個建立連接的請求y，主機B收到了請求y，于是給主機A發(fā)送了一個確認，此時連接建立，數(shù)據(jù)傳輸完畢后斷開了連接，但在斷開連接后堵在半路的請求x到達了主機B，此時主機B認為主機A又給自己發(fā)送了一個建立連接的請求，于是給主機A發(fā)送了一個確認，此時主機B認為連接已經(jīng)建立，處于等待狀態(tài)從而導致主機B資源的浪費。但如果是三次握手就可以避免這種情況的出現(xiàn)，所以這才是TCP第三次握手的原因。

【5.2.2】TCP斷開連接過程：

如上圖所示：主機A至主機B數(shù)據(jù)傳輸結(jié)束后主機A會向主機B發(fā)送一個斷開連接請求，主機B收到后給主機A一個確認，A就不可向B傳輸數(shù)據(jù)了，但此時主機B仍然可以往主機A傳輸數(shù)據(jù)，等B->A數(shù)據(jù)傳輸結(jié)束后主機B向主機A發(fā)送一個斷開連接請求。主機A收到后給予一個確認，這樣就成功斷開一個TCP連接，過程分四步，也被大家親切的稱為：“四次揮手”。

疑點：斷開連接為什么是四次揮手?兩次不就可以了嗎？下面我來用一個形象的例子來個大家解除疑點

TCP是全雙工的：即client和server都可以進行傳輸和接收，假設主機A和主機B建立了一個TCP連接，主機A可以往主機B發(fā)送數(shù)據(jù)同時主機B也可以往主機A發(fā)送數(shù)據(jù)，現(xiàn)在我將主機A->主機B描述成一根水管x，水管x只能由A流到B，主機B->主機A為水管y，水管y只能由B流到A，現(xiàn)在水管x已經(jīng)完成的它的輸送水源工作，此時就可以將水管x切除，對應圖中前兩次揮手，但此時水管y還在工作，必須要等水管y工作完成后才能夠?qū)⑵淝谐谐躽對應圖中后兩次揮手。

5.3 TCP首部

首先用一張圖來表示TCP首部的構(gòu)造，TCP首部如下圖所示：

TCP首部的各項內(nèi)容解釋：

1）源端口：發(fā)送方端口號；

2）目的端口：接收方端口；

3）序號：數(shù)據(jù)包的序號，以數(shù)據(jù)包第一個字節(jié)進行表示；

4）確認號：確認收到數(shù)據(jù)包的序號，同樣以字節(jié)進行標識；

5）數(shù)據(jù)偏移：TCP首部長度，以字節(jié)為單位；

6）保留：保留位，總共6為，必須都為0；

7）URG：緊急處理，可提升數(shù)據(jù)包發(fā)送的優(yōu)先級；

8）ACK：代表確認號是否有效；

9）RST：將建立的連接重置；

10）PSH：接收方應盡快將這個報文交給應用層；

11）SYN：同步序號用來發(fā)起一個連接；

12）FIN：終止一個連接。

本小節(jié)只是讓大家對TCP首部有一個概念性的認識，所以你可能會對首部中某些字段不太理解，沒關系，在下面的文章中我還會提到這些字段。

5.4 TCP進行可靠傳輸

我們知道網(wǎng)絡傳輸是不可靠的，可能存在丟包的現(xiàn)象，TCP是可靠的傳輸協(xié)議，那么它是怎么做到可靠傳輸呢？我來用幾張圖為大家分析TCP師怎樣進行可靠傳輸?shù)摹?/p>

如下圖所示：

情況a：A發(fā)送給B數(shù)據(jù)包M1，B收到之后進行確認，這樣M1包就發(fā)送成功了，以此類推，這是無差錯的情況。

情況b：A發(fā)送數(shù)據(jù)包M1給B，但中途被丟棄了，如果A遲遲等不到B的響應那么A就會重新發(fā)送M1包給B。

如下圖所示：

情況a：A發(fā)送數(shù)據(jù)包M1給B，B收到后給A發(fā)送一個M1的確認包但該確認包在中途被丟棄了，A遲遲未收到B的確認包就認為M1發(fā)送包或者M1確認包早中途丟失了，于是又發(fā)送了一個M1包給B，B又收到了一個M1包，此時B就可以認為M1確認包可能在中途丟失了，將重復的M1包丟棄后再給A發(fā)送一個M1確認包;

情況b：A發(fā)送數(shù)據(jù)包M1給B，B收到后給A發(fā)送一個M1確認包，但該確認包選擇了一個較遠的傳輸路線或者被阻塞了，A遲遲未收到M1確認包就再給B發(fā)送一個M1包，B收到重復的M1包后將其丟棄然后再給A發(fā)送一個M1確認包，A收到M1確認后就認為M1發(fā)送成功，但此時A收到半路阻塞的那個M1確認包，而A已經(jīng)確認了M1包發(fā)送成功，所以再次受到M1確認包后什么也不做。

client-server可以通過傳遞確認的方式來實現(xiàn)可靠傳輸，但這種傳輸方式有一個缺點，效率太低，因為在未收到確認包前是不可以發(fā)送下一個包的，那么我們能不能突破這一限制來提升傳輸效率呢？我們可以通過提升信道的利用率來提升傳輸效率，如下圖所示：

從上圖我們可以看到，A在未收到B確認前發(fā)送了10個數(shù)據(jù)包，在這我就將10個數(shù)據(jù)包形象的編號為1-10，A一次發(fā)送10個數(shù)據(jù)包，當B收到數(shù)據(jù)包1的時候給A一個確認，A收到確認后再發(fā)送數(shù)據(jù)包11，當B收到數(shù)據(jù)包2的時候給A一個確認，A收到確認后再發(fā)送數(shù)據(jù)包12，以此類推。

上圖中A最多一次可以連續(xù)發(fā)送10個數(shù)據(jù)包，而這個10我們可不可以理解為一個窗口呢？打個比方，現(xiàn)在有一個窗口共有10個格子，每個格子放一個數(shù)據(jù)包，發(fā)送的數(shù)據(jù)包放在格子里面，當收到第一個數(shù)據(jù)包的確認包后將該數(shù)據(jù)包從窗口中移出，然后將需要發(fā)送的下一個數(shù)據(jù)包放入窗口。

我們這里提到的窗口就是TCP首部里面說的那個窗口，下面我結(jié)合圖給大家分析一遍：

上圖中，現(xiàn)在我們有12個數(shù)據(jù)包需要發(fā)送，窗口大小為5，所以最多一次可連續(xù)發(fā)送5個數(shù)據(jù)包，假設現(xiàn)在窗口中的五個數(shù)據(jù)包都已經(jīng)發(fā)送完畢，此時收到了數(shù)據(jù)包1的確認包，那么綠色窗口就可以往右邊移一個格子，如下圖：

上圖中，數(shù)據(jù)包6被滑進格子里，此時數(shù)據(jù)包6就可以被發(fā)送，同時數(shù)據(jù)包1也可以從緩存中清除，通過這種方式可以提升信道的利用率從而提升傳輸效率，但這種傳輸方式也有一個缺點，就是接收方每收到一個數(shù)據(jù)包都要進行一次確認，這是完全沒必要的，我們可不可以這樣做：每收到5個數(shù)據(jù)包進行一個確認，如下圖：

A一次給B發(fā)送了5個數(shù)據(jù)包，B確認5個數(shù)據(jù)包都收到了，給A回復一個6，代表B已經(jīng)收到了前5個數(shù)據(jù)包讓A下次從第6個數(shù)據(jù)包開始發(fā)送，通過累積響應這種方式又進一步提升了傳輸效率，但這是理想情況下，如果說A發(fā)送完5個數(shù)據(jù)包，B只收到了1、2、4、5，數(shù)據(jù)包3丟了，怎么辦？是直接給A回復一個3嗎？是的話4、5都要進行重傳，這樣就得不償失了，而編寫TCP協(xié)議那位老哥也想到了這種情況，所以就指定了相應的策略，接著剛剛說，如果B確定數(shù)據(jù)包3丟了或者被阻塞了，那么它會立刻連續(xù)發(fā)送3個3，A收到連續(xù)的3個3后就認為數(shù)據(jù)包3丟了，然后就會只補傳數(shù)據(jù)包3。

注意點：

上面的內(nèi)容中我為了方便講解都是把數(shù)據(jù)包編成編號進行描述，其實真正的數(shù)據(jù)包編號不是這樣的，TCP協(xié)議是面向字節(jié)流的，所以說序號和確認號應以字節(jié)為標準，比如：A現(xiàn)在向B發(fā)送了5和數(shù)據(jù)包共100個字節(jié)，B收到這5個數(shù)據(jù)包后會給A回復一個101，此時A就會從第101個字節(jié)開始進行發(fā)送，以此類推。同時通過這種機制也可以實現(xiàn)斷點的下載。

5.5 流量控制

流量控制：用來協(xié)調(diào)server和client兩端因處理數(shù)據(jù)速度不同所帶來的問題。

舉個例子：

假如主機A要向主機B發(fā)送數(shù)據(jù)，如果主機A發(fā)送數(shù)據(jù)的速度比主機B處理數(shù)據(jù)的速度要快，那么很可能導致主機B崩潰，通過TCP流量控制技術(shù)可以調(diào)整主機A發(fā)送數(shù)據(jù)的速度從而解決上面的問題。

TCP是怎樣實現(xiàn)流量控制的的？首先說明一點，前面我們描述TCP傳輸數(shù)據(jù)的時候提到了滑動窗口這個概念，其實不光發(fā)送方存在滑動窗口，同樣接收方也存在滑動窗口，接收方收到數(shù)據(jù)包后會將數(shù)據(jù)包放入滑動窗口，對數(shù)據(jù)包操作完畢后將該數(shù)據(jù)包從滑動窗口中移出，當滑動窗口被填滿時不可以再接收數(shù)據(jù)，TCP中發(fā)送發(fā)窗口和接收方窗口大小是相同的。

所以，通過滑動窗口機制可以實現(xiàn)流量控制，如下圖所示：

上圖中，B為發(fā)送方A為接收方，當B與A建立連接的時候首先會明確自己滑動窗口的大小，假如是10，B就會將rwnd(滑動窗口)設置為10，A收到后也會將滑動窗口設置為10，連接建立成功會A開始向B發(fā)送數(shù)據(jù)，我們知道滑動窗口越大發(fā)送的速度越快，假如rwnd=10時B處理數(shù)據(jù)包的速度小于接收數(shù)據(jù)包的速度那么滑動窗口會逐漸被填滿，這樣會導致主機B中未處理的數(shù)據(jù)包越來越多最終可能會崩潰，為了避免這種情況的出現(xiàn)，B可以在滑動窗口被填滿了之后給A發(fā)送一個rwnd=6，A接收到rwnd=6后會將滑動窗口調(diào)整為6進而降低發(fā)送數(shù)據(jù)的速度，同樣B如果覺得A的發(fā)送速度過慢也可以通過設置rwnd的值來調(diào)整A的發(fā)送速度，B動態(tài)的設置A的滑動窗口就稱作為TCP流量控制技術(shù)。

5.6 擁塞避免

什么是擁塞呢？顧名思義就是賭了，數(shù)據(jù)被堵在半路了，那什么情況下會出現(xiàn)數(shù)據(jù)被堵在半路呢？

舉個例子：

假如現(xiàn)有兩臺主機分別是發(fā)送方主機A和接收方主機B，主機B的帶寬為50M/S，也就是說主機B每秒最多能接收50M的數(shù)據(jù)，如果主機A的發(fā)送速度遠低于50M/S，這種情況應該是不會出現(xiàn)擁塞現(xiàn)象的，但是如果主機A的發(fā)送速度遠大于50M/S，主機B的路由器接手不了這么多數(shù)據(jù)只能進行丟棄，路由器也是有CPU、內(nèi)存和自己的操作系統(tǒng)，當主句A發(fā)送速度越快主機B的路由器CPU和內(nèi)存就要分配更多的資源去處理丟棄數(shù)據(jù)包，這樣就會導致接收數(shù)據(jù)包的速度越來越低，極端的情況下可能會出現(xiàn)主機B接收不到數(shù)據(jù)包的現(xiàn)象，也就是死鎖現(xiàn)象。

如果在進行TCP數(shù)據(jù)傳輸?shù)臅r候不進行流量控制很容易出現(xiàn)死鎖現(xiàn)象，因為網(wǎng)絡是大家共用的，所以避免網(wǎng)絡擁塞現(xiàn)象的出現(xiàn)需要所有計算機遵守一種特定的規(guī)則，那這種規(guī)則是怎樣控制網(wǎng)絡避免擁塞的呢？

先來看下面這張圖：

如果不進行擁塞控制就是我們上面所說的，最終可能會出現(xiàn)上圖中綠線的情況，現(xiàn)在我們要通過擁塞控制使網(wǎng)絡數(shù)據(jù)傳輸按照上圖中藍線進行。

下面我們來說一下如何進行擁塞控制：

首先將滑動窗口設置為1，然后再傳輸過程中逐漸以指數(shù)倍增加，當滑動窗口到達ssthresh的時候再以加法進行增加，如果出現(xiàn)了擁塞現(xiàn)象就迅速再將滑動窗口設置為1，ssthresh減小依次循環(huán)，這種方式也稱為慢開始方式。但這種方式已經(jīng)被廢棄，因為每次出現(xiàn)擁塞的時候都會將滑動窗口設置為0再進行慢開始階段，這樣其實是完全沒必要的。

我們再來看升級版，如下圖：

在出現(xiàn)擁塞的時候并不會將滑動窗口設置為1重新進行慢開始，而是將滑動窗口設置為出現(xiàn)擁塞時窗口的一半，然后再以加法進行增加，此過程也可稱為是快恢復，這樣就可以避免網(wǎng)絡擁塞的出現(xiàn)。

附錄：更多網(wǎng)絡編程文章

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》

《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計算機網(wǎng)絡通訊協(xié)議關系圖（中文珍藏版）》

《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)絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關閉》

《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》

《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》

《技術(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)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術(shù)挑戰(zhàn)》

《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡基礎》

《全面了解移動端DNS域名劫持等雜癥：技術(shù)原理、問題根源、解決方案等》

《美圖App的移動端DNS優(yōu)化實踐：HTTPS請求耗時減小近半》

《Android程序員必知必會的網(wǎng)絡通信傳輸層協(xié)議——UDP和TCP》

>> 更多同類文章 ……

（本文同發(fā)布于：http://www.52im.net/thread-2216-1-1.html）