1、點評
互聯網發展至今已經高度發達，而對于互聯網應用（尤其即時通訊技術這一塊）的開發者來說，網絡編程是基礎中的基礎，只有更好地理解相關基礎知識，對于應用層的開發才能做到游刃有余。
對于Android程序員來說，如果您覺得本文內容稍顯枯燥，可以看看即時通訊網之前整理過的一篇類似文章《邁向高階：優秀Android程序員必知必會的網絡基礎》，該文內容更偏向于知識點的概括。
如果您希望更系統地學習網絡編程方面的知識，可以讀一讀以下專為初學者整理的系列文章或資料：
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
學習交流：
- 即時通訊/推送技術開發交流4群：101279154[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同發布于：http://www.52im.net/thread-2216-1-1.html）
2、前言
相信計算機專業的朋友在大學都學過《計算機網絡》這門課程，但據我個人了解計算機專業普通大學生對計算機網絡的了解淺之又淺，很多人說這門學科沒用，開發的時候也用不著，其實這樣想是不對的。
說一下我個人的體會，之前老是聽別人說OkHttp怎么這么好用，但用完之后感覺和其他框架沒多大區別啊，于是就想著去專研鉆研，當時差不多花了一個星期左右把OkHttp源碼看了一遍，代碼時看懂了，但是有些地方不知道為什么這樣做，所以我就下決心把計算機網絡重新學一遍，學完各種網絡協議后再看OkHttp源碼突然有種煥然一新的感覺。
在本篇文章里，會為大家講述作為Android程序員的我，對于網絡通信傳輸層協議UDP、TCP的理解，希望能給你帶來啟發。
參考書籍：《計算機網絡-謝希仁版》
參考教程：《韓立剛視頻教程》
3、關于作者
網名：zskingking，博客地址：https://www.jianshu.com/u/274367e58472
4、UDP協議
4.1 概述
UDP的全稱是User Date Protocal，翻譯成中文是用戶數據包協議，它是一種不可靠的傳輸協議，一般情況下一個數據包(大概64K)能完成的數據通訊使用UDP協議，比如請求DNS解析IP地址使用的就是UDP協議，因為解析IP一個數據包完全足夠。還有就是文字聊天一般用的也是UDP，通常一段文字消息一個數據包就足夠了，如果發送失敗就再次發送，反正就一個數據包。還有一種傳遞大量數據包使用UDP協議的場景，就是廣播，類似對講機之類的，接收方并不一定能接收到所有的數據包。所以說UDP是一種不可靠的傳輸協議。
UDP的主要特點：
1）UDP是無連接的，即發送數據之前是不需要建立連接的；
2）UDP使用盡最大努力交付，不保證可靠交付，同時不使用阻塞控制；
3）UDP是面向報文的，UDP沒有擁塞控制，很適合多媒體通信的要求；
4）UDP支持一對一、一對多、多對一、多對多的交互通信；
5）UDP的首部開銷小，只需要8個字節。
4.2 UDP首部
首先我們先用一張圖來表示UDP的首部，UDP首部如下圖：
UDP首部總共是8個字節，其中源端口、目的端口、長度、檢驗和各占2字節。有的同學可能要問了，你怎么沒把偽首部加進去呢？這個我來講一下，偽首部顧名思義，就是假的首部，它是不會跟隨UDP數據報進行傳輸的，它存在的意義就是為了計算UDP首部中的檢驗和。
UDP首部存儲的信息：
1）源端口：即發送方的端口號，需要接收方回應時選用，不需要全為0；
2）目的端口：接收方端口號；
3）長度：UDP數據報長度，最小為0(只存在首部)；
4）檢驗和： 檢驗UDP數據報在傳輸中是否出錯，是就丟棄。
UDP首部組裝完畢后會將完整的數據報發送到網絡層，跟IP數據報首部組成IP數據報再向上發送。
5、TCP協議
5.1 概述
TCP全稱為Transmission Control Protocol(傳輸控制協議)，是一種可靠的面向連接傳輸協議，同時它也是一種client-server模式的協議，因為是可靠的傳輸協議，所以它比UDP要復雜的多。
首先說一下TCP具有的一些特性：
1）TCP是面向連接的傳輸協議；
2）每一條TCP有且只有兩個端點，為一對一關系；
3）TCP提供可靠交互的服務；
4）TCP提供全雙工通信，全雙工為即可傳輸又可接收；
5）TCP是面向字節流的。
TCP的應用場景：
如果兩個臺主機想要在網絡上傳遞一部1G大小的電影，需要通過什么協議進行傳輸呢？UDP為不可靠傳輸協議，傳遞過程中可能會出現丟包，所以UDP不行，而傳輸層就兩個協議，一個是UDP一個是TCP，UDP傳輸效率高但不可靠，TCP傳輸效率低但它是可靠的，所以想要將傳遞的文件完整的到達目的地可以通過TCP協議進行傳輸。
5.2 TCP連接建立與斷開
在5.1中介紹TCP特性的時候提到，TCP是面向連接的，即TCP在傳輸數據前要建立連接，數據傳輸完畢后要斷開連接。TCP連接必須要由客戶端發起。
【5.2.1】TCP建立連接過程：
如上圖2所示：客戶端向服務端發起建立連接的請求，服務端接收到請求后告訴客戶端：“我準備好了”，客戶端接收到服務端的響應再給服務端一個確認，此過程總共分為三步被大家親切的成為：“三次握手”，三次握手后一個可靠的連接就建立了，隨后就可以進行數據的傳輸了，圖中SYN、ACK這些字段我會在TCP首部中詳細介紹，此處大家可以忽略。
疑點： TCP建立連接為什么是三次握手？兩次握手不是已經可以建立一個連接了嗎？網絡上很多文章對此處的描述大多是輕描淡寫，還有的說是必須要三次握手才能建立一個可靠連接，其實這樣說是不對的，當時我也因為這些不負責任的回答費解了很久。一般情況下，兩次握手是可以建立一個TCP連接的，在《計算機網絡-謝希仁》中大概是這樣解釋的:“第三次握手是為了避免服務端造成資源的浪費”，為什么這樣說呢？我來給大家舉一個例子：
假如TCP是兩次握手：主機A向主機B發送了一個建立連接的請求x，但這個請求在半路里給堵了，主機A沒有得到主機B的響應于是又發了一個建立連接的請求y，主機B收到了請求y，于是給主機A發送了一個確認，此時連接建立，數據傳輸完畢后斷開了連接，但在斷開連接后堵在半路的請求x到達了主機B，此時主機B認為主機A又給自己發送了一個建立連接的請求，于是給主機A發送了一個確認，此時主機B認為連接已經建立，處于等待狀態從而導致主機B資源的浪費。但如果是三次握手就可以避免這種情況的出現，所以這才是TCP第三次握手的原因。
【5.2.2】TCP斷開連接過程：
如上圖所示：主機A至主機B數據傳輸結束后主機A會向主機B發送一個斷開連接請求，主機B收到后給主機A一個確認，A就不可向B傳輸數據了，但此時主機B仍然可以往主機A傳輸數據，等B->A數據傳輸結束后主機B向主機A發送一個斷開連接請求。主機A收到后給予一個確認，這樣就成功斷開一個TCP連接，過程分四步，也被大家親切的稱為：“四次揮手”。
疑點：斷開連接為什么是四次揮手?兩次不就可以了嗎？下面我來用一個形象的例子來個大家解除疑點
TCP是全雙工的：即client和server都可以進行傳輸和接收，假設主機A和主機B建立了一個TCP連接，主機A可以往主機B發送數據同時主機B也可以往主機A發送數據，現在我將主機A->主機B描述成一根水管x，水管x只能由A流到B，主機B->主機A為水管y，水管y只能由B流到A，現在水管x已經完成的它的輸送水源工作，此時就可以將水管x切除，對應圖中前兩次揮手，但此時水管y還在工作，必須要等水管y工作完成后才能夠將其切除，切除水管y對應圖中后兩次揮手。
5.3 TCP首部
首先用一張圖來表示TCP首部的構造，TCP首部如下圖所示：
TCP首部的各項內容解釋：
1）源端口：發送方端口號；
2）目的端口：接收方端口；
3）序號：數據包的序號，以數據包第一個字節進行表示；
4）確認號：確認收到數據包的序號，同樣以字節進行標識；
5）數據偏移：TCP首部長度，以字節為單位；
6）保留：保留位，總共6為，必須都為0；
7）URG：緊急處理，可提升數據包發送的優先級；
8）ACK：代表確認號是否有效；
9）RST：將建立的連接重置；
10）PSH：接收方應盡快將這個報文交給應用層；
11）SYN：同步序號用來發起一個連接；
12）FIN：終止一個連接。
本小節只是讓大家對TCP首部有一個概念性的認識，所以你可能會對首部中某些字段不太理解，沒關系，在下面的文章中我還會提到這些字段。
5.4 TCP進行可靠傳輸
我們知道網絡傳輸是不可靠的，可能存在丟包的現象，TCP是可靠的傳輸協議，那么它是怎么做到可靠傳輸呢？我來用幾張圖為大家分析TCP師怎樣進行可靠傳輸的。
如下圖所示：
情況a：A發送給B數據包M1，B收到之后進行確認，這樣M1包就發送成功了，以此類推，這是無差錯的情況。
情況b：A發送數據包M1給B，但中途被丟棄了，如果A遲遲等不到B的響應那么A就會重新發送M1包給B。
如下圖所示：
情況a：A發送數據包M1給B，B收到后給A發送一個M1的確認包但該確認包在中途被丟棄了，A遲遲未收到B的確認包就認為M1發送包或者M1確認包早中途丟失了，于是又發送了一個M1包給B，B又收到了一個M1包，此時B就可以認為M1確認包可能在中途丟失了，將重復的M1包丟棄后再給A發送一個M1確認包;
情況b：A發送數據包M1給B，B收到后給A發送一個M1確認包，但該確認包選擇了一個較遠的傳輸路線或者被阻塞了，A遲遲未收到M1確認包就再給B發送一個M1包，B收到重復的M1包后將其丟棄然后再給A發送一個M1確認包，A收到M1確認后就認為M1發送成功，但此時A收到半路阻塞的那個M1確認包，而A已經確認了M1包發送成功，所以再次受到M1確認包后什么也不做。
client-server可以通過傳遞確認的方式來實現可靠傳輸，但這種傳輸方式有一個缺點，效率太低，因為在未收到確認包前是不可以發送下一個包的，那么我們能不能突破這一限制來提升傳輸效率呢？我們可以通過提升信道的利用率來提升傳輸效率，如下圖所示：
從上圖我們可以看到，A在未收到B確認前發送了10個數據包，在這我就將10個數據包形象的編號為1-10，A一次發送10個數據包，當B收到數據包1的時候給A一個確認，A收到確認后再發送數據包11，當B收到數據包2的時候給A一個確認，A收到確認后再發送數據包12，以此類推。
上圖中A最多一次可以連續發送10個數據包，而這個10我們可不可以理解為一個窗口呢？打個比方，現在有一個窗口共有10個格子，每個格子放一個數據包，發送的數據包放在格子里面，當收到第一個數據包的確認包后將該數據包從窗口中移出，然后將需要發送的下一個數據包放入窗口。
我們這里提到的窗口就是TCP首部里面說的那個窗口，下面我結合圖給大家分析一遍：
上圖中，現在我們有12個數據包需要發送，窗口大小為5，所以最多一次可連續發送5個數據包，假設現在窗口中的五個數據包都已經發送完畢，此時收到了數據包1的確認包，那么綠色窗口就可以往右邊移一個格子，如下圖：
上圖中，數據包6被滑進格子里，此時數據包6就可以被發送，同時數據包1也可以從緩存中清除，通過這種方式可以提升信道的利用率從而提升傳輸效率，但這種傳輸方式也有一個缺點，就是接收方每收到一個數據包都要進行一次確認，這是完全沒必要的，我們可不可以這樣做：每收到5個數據包進行一個確認，如下圖：
A一次給B發送了5個數據包，B確認5個數據包都收到了，給A回復一個6，代表B已經收到了前5個數據包讓A下次從第6個數據包開始發送，通過累積響應這種方式又進一步提升了傳輸效率，但這是理想情況下，如果說A發送完5個數據包，B只收到了1、2、4、5，數據包3丟了，怎么辦？是直接給A回復一個3嗎？是的話4、5都要進行重傳，這樣就得不償失了，而編寫TCP協議那位老哥也想到了這種情況，所以就指定了相應的策略，接著剛剛說，如果B確定數據包3丟了或者被阻塞了，那么它會立刻連續發送3個3，A收到連續的3個3后就認為數據包3丟了，然后就會只補傳數據包3。
注意點：
上面的內容中我為了方便講解都是把數據包編成編號進行描述，其實真正的數據包編號不是這樣的，TCP協議是面向字節流的，所以說序號和確認號應以字節為標準，比如：A現在向B發送了5和數據包共100個字節，B收到這5個數據包后會給A回復一個101，此時A就會從第101個字節開始進行發送，以此類推。同時通過這種機制也可以實現斷點的下載。
5.5 流量控制
流量控制：用來協調server和client兩端因處理數據速度不同所帶來的問題。
舉個例子：
假如主機A要向主機B發送數據，如果主機A發送數據的速度比主機B處理數據的速度要快，那么很可能導致主機B崩潰，通過TCP流量控制技術可以調整主機A發送數據的速度從而解決上面的問題。
TCP是怎樣實現流量控制的的？首先說明一點，前面我們描述TCP傳輸數據的時候提到了滑動窗口這個概念，其實不光發送方存在滑動窗口，同樣接收方也存在滑動窗口，接收方收到數據包后會將數據包放入滑動窗口，對數據包操作完畢后將該數據包從滑動窗口中移出，當滑動窗口被填滿時不可以再接收數據，TCP中發送發窗口和接收方窗口大小是相同的。
所以，通過滑動窗口機制可以實現流量控制，如下圖所示：
上圖中，B為發送方A為接收方，當B與A建立連接的時候首先會明確自己滑動窗口的大小，假如是10，B就會將rwnd(滑動窗口)設置為10，A收到后也會將滑動窗口設置為10，連接建立成功會A開始向B發送數據，我們知道滑動窗口越大發送的速度越快，假如rwnd=10時B處理數據包的速度小于接收數據包的速度那么滑動窗口會逐漸被填滿，這樣會導致主機B中未處理的數據包越來越多最終可能會崩潰，為了避免這種情況的出現，B可以在滑動窗口被填滿了之后給A發送一個rwnd=6，A接收到rwnd=6后會將滑動窗口調整為6進而降低發送數據的速度，同樣B如果覺得A的發送速度過慢也可以通過設置rwnd的值來調整A的發送速度，B動態的設置A的滑動窗口就稱作為TCP流量控制技術。
5.6 擁塞避免
什么是擁塞呢？顧名思義就是賭了，數據被堵在半路了，那什么情況下會出現數據被堵在半路呢？
舉個例子：
假如現有兩臺主機分別是發送方主機A和接收方主機B，主機B的帶寬為50M/S，也就是說主機B每秒最多能接收50M的數據，如果主機A的發送速度遠低于50M/S，這種情況應該是不會出現擁塞現象的，但是如果主機A的發送速度遠大于50M/S，主機B的路由器接手不了這么多數據只能進行丟棄，路由器也是有CPU、內存和自己的操作系統，當主句A發送速度越快主機B的路由器CPU和內存就要分配更多的資源去處理丟棄數據包，這樣就會導致接收數據包的速度越來越低，極端的情況下可能會出現主機B接收不到數據包的現象，也就是死鎖現象。
如果在進行TCP數據傳輸的時候不進行流量控制很容易出現死鎖現象，因為網絡是大家共用的，所以避免網絡擁塞現象的出現需要所有計算機遵守一種特定的規則，那這種規則是怎樣控制網絡避免擁塞的呢？
先來看下面這張圖：
如果不進行擁塞控制就是我們上面所說的，最終可能會出現上圖中綠線的情況，現在我們要通過擁塞控制使網絡數據傳輸按照上圖中藍線進行。
下面我們來說一下如何進行擁塞控制：
首先將滑動窗口設置為1，然后再傳輸過程中逐漸以指數倍增加，當滑動窗口到達ssthresh的時候再以加法進行增加，如果出現了擁塞現象就迅速再將滑動窗口設置為1，ssthresh減小依次循環，這種方式也稱為慢開始方式。但這種方式已經被廢棄，因為每次出現擁塞的時候都會將滑動窗口設置為0再進行慢開始階段，這樣其實是完全沒必要的。
我們再來看升級版，如下圖：
在出現擁塞的時候并不會將滑動窗口設置為1重新進行慢開始，而是將滑動窗口設置為出現擁塞時窗口的一半，然后再以加法進行增加，此過程也可稱為是快恢復，這樣就可以避免網絡擁塞的出現。
附錄：更多網絡編程文章
《技術往事：改變世界的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變的可靠？》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長連接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面了解移動端DNS域名劫持等雜癥：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
>> 更多同類文章 ……
（本文同發布于：http://www.52im.net/thread-2216-1-1.html）