前言
相信計算機專業(yè)的朋友在大學(xué)都學(xué)過《計算機網(wǎng)絡(luò)》這門課程等缀，但據(jù)我個人了解計算機專業(yè)普通大學(xué)生對計算機網(wǎng)絡(luò)的了解淺之又淺，很多人說這門學(xué)科沒用娇昙，開發(fā)的時候也用不著尺迂，其實這樣想是不對的，說一下我個人的體會冒掌，之前老是聽別人說OkHttp怎么這么好用噪裕，但用完之后感覺和其他框架沒多大區(qū)別啊，于是就想著去專研鉆研股毫，當時差不多花了一個星期左右把OkHttp源碼看了一遍膳音，代碼時看懂了，但是有些地方不知道為什么這樣做铃诬，所以我就下決心把計算機網(wǎng)絡(luò)重新學(xué)一遍祭陷，學(xué)完各種網(wǎng)絡(luò)協(xié)議后再看OkHttp源碼突然有種煥然一新的感覺苍凛。在本系列課程我會為大家講述傳輸層協(xié)議UDP、TCP和應(yīng)用層協(xié)議HTTP颗胡、HTTPS以及Android中優(yōu)秀的網(wǎng)絡(luò)框架的基本使用和源碼解析毫深。
參考書籍：《計算機網(wǎng)絡(luò)-謝希仁版》
參考教程：《韓立剛視頻教程》
1 UDP
1.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的主要特點：
- UDP是無連接的，即發(fā)送數(shù)據(jù)之前是不需要建立連接的
- UDP使用盡最大努力交付蘸鲸，不保證可靠交付妖谴，同時不使用阻塞控制
- UDP是面向報文的，UDP沒有擁塞控制酌摇，很適合多媒體通信的要求
- UDP支持一對一膝舅、一對多、多對一窑多、多對多的交互通信
- UDP的首部開銷小仍稀，只需要8個字節(jié)
1.2 UDP首部
首先我們先用一張圖來表示UDP的首部，UDP首部如圖1-1
UDP首部總共是8個字節(jié)埂息，其中源端口琳轿、目的端口、長度耿芹、檢驗和各占2字節(jié)崭篡。有的同學(xué)可能要問了，你怎么沒把偽首部加進去呢吧秕？這個我來講一下琉闪，偽首部顧名思義，就是假的首部砸彬，它是不會跟隨UDP數(shù)據(jù)報進行傳輸?shù)牡弑校嬖诘囊饬x就是為了計算UDP首部中的檢驗和斯入。
UDP首部存儲的信息：
- 源端口：即發(fā)送方的端口號，需要接收方回應(yīng)時選用蛀蜜，不需要全為0刻两。
- 目的端口：接收方端口號。
- 長度：UDP數(shù)據(jù)報長度滴某，最小為0(只存在首部)磅摹。
- 檢驗和： 檢驗UDP數(shù)據(jù)報在傳輸中是否出錯，是就丟棄
UDP首部組裝完畢后會將完整的數(shù)據(jù)報發(fā)送到網(wǎng)絡(luò)層霎奢，跟IP數(shù)據(jù)報首部組成IP數(shù)據(jù)報再向上發(fā)送户誓。
2 TCP
2.1概述
TCP全稱為Transmission Control Protocol(傳輸控制協(xié)議)，是一種可靠的面向連接傳輸協(xié)議幕侠，同時它也是一種client-server模式的協(xié)議帝美，因為是可靠的傳輸協(xié)議，所以它比UDP要復(fù)雜的多晤硕。
首先說一下TCP具有的一些特性：
- TCP是面向連接的傳輸協(xié)議
- 每一條TCP有且只有兩個端點悼潭，為一對一關(guān)系
- TCP提供可靠交互的服務(wù)
- TCP提供全雙工通信，全雙工為即可傳輸又可接收
- TCP是面向字節(jié)流的
TCP的應(yīng)用場景：
如果兩個臺主機想要在網(wǎng)絡(luò)上傳遞一部1G大小的電影舞箍，需要通過什么協(xié)議進行傳輸呢舰褪？UDP為不可靠傳輸協(xié)議，傳遞過程中可能會出現(xiàn)丟包创译，所以UDP不行抵知，而傳輸層就兩個協(xié)議墙基，一個是UDP一個是TCP软族，UDP傳輸效率高但不可靠，TCP傳輸效率低但它是可靠的残制，所以想要將傳遞的文件完整的到達目的地可以通過TCP協(xié)議進行傳輸立砸。
2.2 TCP連接建立與斷開
在2.1中介紹TCP特性的時候提到，TCP是面向連接的初茶，即TCP在傳輸數(shù)據(jù)前要建立連接颗祝，數(shù)據(jù)傳輸完畢后要斷開連接。TCP連接必須要由客戶端發(fā)起恼布。
2.2.1 TCP建立連接過程：
如圖2-1：客戶端向服務(wù)端發(fā)起建立連接的請求螺戳，服務(wù)端接收到請求后告訴客戶端：“我準備好了”，客戶端接收到服務(wù)端的響應(yīng)再給服務(wù)端一個確認折汞，此過程總共分為三步被大家親切的成為：“三次握手”倔幼，三次握手后一個可靠的連接就建立了，隨后就可以進行數(shù)據(jù)的傳輸了爽待，圖中SYN损同、ACK這些字段我會在TCP首部中詳細介紹翩腐，此處大家可以忽略。
疑點： TCP建立連接為什么是三次握手膏燃？兩次握手不是已經(jīng)可以建立一個連接了嗎茂卦？網(wǎng)絡(luò)上很多文章對此處大多是輕描淡寫，還有的說是必須要三次握手才能建立一個可靠連接组哩，其實這樣說是不對的等龙，當時我也因為這些不負責(zé)任的回答費解了很久。一般情況下禁炒，兩次握手是可以建立一個TCP連接的而咆，在《計算機網(wǎng)絡(luò)-謝希仁》中大概是這樣解釋的:“第三次握手是為了避免服務(wù)端造成資源的浪費”，為什么這樣說呢幕袱？我來給大家舉一個例子：
假如TCP是兩次握手：主機A向主機B發(fā)送了一個建立連接的請求x暴备，但這個請求在半路里給堵了，主機A沒有得到主機B的響應(yīng)于是又發(fā)了一個建立連接的請求y们豌，主機B收到了請求y涯捻，于是給主機A發(fā)送了一個確認，此時連接建立望迎，數(shù)據(jù)傳輸完畢后斷開了連接障癌，但在斷開連接后堵在半路的請求x到達了主機B，此時主機B認為主機A又給自己發(fā)送了一個建立連接的請求辩尊，于是給主機A發(fā)送了一個確認涛浙，此時主機B認為連接已經(jīng)建立，處于等待狀態(tài)從而導(dǎo)致主機B資源的浪費摄欲。但如果是三次握手就可以避免這種情況的出現(xiàn)轿亮，所以這才是TCP第三次握手的原因。
2.2.2 TCP斷開連接過程：
如圖2-2：主機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都可以進行傳輸和接收，假設(shè)主機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īng)圖中前兩次揮手讼稚，但此時水管y還在工作，必須要等水管y工作完成后才能夠?qū)⑵淝谐粕颍谐躽對應(yīng)圖中后兩次揮手锐想。
2.3 TCP首部
首先用一張圖來表示TCP首部的構(gòu)造，TCP首部如圖2-3
- 源端口：發(fā)送方端口號
- 目的端口：接收方端口
- 序號：數(shù)據(jù)包的序號乍狐，以數(shù)據(jù)包第一個字節(jié)進行表示
- 確認號：確認收到數(shù)據(jù)包的序號赠摇，同樣以字節(jié)進行標識
- 數(shù)據(jù)偏移：TCP首部長度，以字節(jié)為單位
- 保留：保留位浅蚪，總共6為藕帜，必須都為0
- URG：緊急處理，可提升數(shù)據(jù)包發(fā)送的優(yōu)先級
- ACK：代表確認號是否有效
- RST：將建立的連接重置
- PSH：接收方應(yīng)盡快將這個報文交給應(yīng)用層
- SYN：同步序號用來發(fā)起一個連接
- FIN：終止一個連接
本小節(jié)只是讓大家對TCP首部有一個概念性的認識惜傲，所以你可能會對首部中某些字段不太理解洽故，沒關(guān)系，在下面的文章中我還會提到這些字段盗誊。
2.3 TCP進行可靠傳輸
我們知道網(wǎng)絡(luò)傳輸是不可靠的时甚，可能存在丟包的現(xiàn)象，TCP是可靠的傳輸協(xié)議哈踱，那么它是怎么做到可靠傳輸呢荒适？我來用幾張圖為大家分析TCP師怎樣進行可靠傳輸?shù)摹?/p>
如圖2-4：
- 情況a：A發(fā)送給B數(shù)據(jù)包M1，B收到之后進行確認嚣鄙，這樣M1包就發(fā)送成功了吻贿，以此類推串结，這是無差錯的情況。
- 情況b：A發(fā)送數(shù)據(jù)包M1給B，但中途被丟棄了芒填，如果A遲遲等不到B的響應(yīng)那么A就會重新發(fā)送M1包給B眉撵。
如圖2-5：
- 情況a：A發(fā)送數(shù)據(jù)包M1給B，B收到后給A發(fā)送一個M1的確認包但該確認包在中途被丟棄了把敞，A遲遲未收到B的確認包就認為M1發(fā)送包或者M1確認包早中途丟失了弥奸，于是又發(fā)送了一個M1包給B，B又收到了一個M1包奋早，此時B就可以認為M1確認包可能在中途丟失了盛霎，將重復(fù)的M1包丟棄后再給A發(fā)送一個M1確認包赠橙。
- 情況b：A發(fā)送數(shù)據(jù)包M1給B，B收到后給A發(fā)送一個M1確認包愤炸，但該確認包選擇了一個較遠的傳輸路線或者被阻塞了期揪，A遲遲未收到M1確認包就再給B發(fā)送一個M1包，B收到重復(fù)的M1包后將其丟棄然后再給A發(fā)送一個M1確認包规个，A收到M1確認后就認為M1發(fā)送成功凤薛，但此時A收到半路阻塞的那個M1確認包，而A已經(jīng)確認了M1包發(fā)送成功诞仓，所以再次受到M1確認包后什么也不做缤苫。
client-server可以通過傳遞確認的方式來實現(xiàn)可靠傳輸，但這種傳輸方式有一個缺點墅拭，效率太低活玲，因為在未收到確認包前是不可以發(fā)送下一個包的，那么我們能不能突破這一限制來提升傳輸效率呢谍婉？我們可以通過提升信道的利用率來提升傳輸效率翼虫，如圖2-6
圖2-6我們可以看到，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措译，以此類推别凤。
圖2-6中A最多一次可以連續(xù)發(fā)送10個數(shù)據(jù)包，而這個10我們可不可以理解為一個窗口呢领虹？打個比方规哪，現(xiàn)在有一個窗口共有10個格子，每個格子放一個數(shù)據(jù)包塌衰，發(fā)送的數(shù)據(jù)包放在格子里面诉稍，當收到第一個數(shù)據(jù)包的確認包后將該數(shù)據(jù)包從窗口中移出，然后將需要發(fā)送的下一個數(shù)據(jù)包放入窗口最疆。我們這里提到的窗口就是TCP首部里面說的那個窗口杯巨，下面我結(jié)合圖給大家分析一遍：
如圖2-7，現(xiàn)在我們有12個數(shù)據(jù)包需要發(fā)送努酸，窗口大小為5服爷，所以最多一次可連續(xù)發(fā)送5個數(shù)據(jù)包，假設(shè)現(xiàn)在窗口中的五個數(shù)據(jù)包都已經(jīng)發(fā)送完畢，此時收到了數(shù)據(jù)包1的確認包仍源，那么綠色窗口就可以往右邊移一個格子心褐，如圖2-8
圖2-8中數(shù)據(jù)包6被滑進格子里，此時數(shù)據(jù)包6就可以被發(fā)送笼踩，同時數(shù)據(jù)包1也可以從緩存中清除檬寂，通過這種方式可以提升信道的利用率從而提升傳輸效率，但這種傳輸方式也有一個缺點戳表，就是接收方每收到一個數(shù)據(jù)包都要進行一次確認桶至，這是完全沒必要的，我們可不可以這樣做：每收到5個數(shù)據(jù)包進行一個確認匾旭，如圖2-9
A一次給B發(fā)送了5個數(shù)據(jù)包镣屹，B確認5個數(shù)據(jù)包都收到了，給A回復(fù)一個6价涝，代表B已經(jīng)收到了前5個數(shù)據(jù)包讓A下次從第6個數(shù)據(jù)包開始發(fā)送女蜈，通過累積響應(yīng)這種方式又進一步提升了傳輸效率，但這是理想情況下色瘩，如果說A發(fā)送完5個數(shù)據(jù)包伪窖，B只收到了1、2居兆、4覆山、5，數(shù)據(jù)包3丟了泥栖，怎么辦簇宽？是直接給A回復(fù)一個3嗎？是的話4吧享、5都要進行重傳魏割，這樣就得不償失了，而編寫TCP協(xié)議那位老哥也想到了這種情況钢颂，所以就指定了相應(yīng)的策略钞它，接著剛剛說，如果B確定數(shù)據(jù)包3丟了或者被阻塞了殊鞭，那么它會立刻連續(xù)發(fā)送3個3遭垛，A收到連續(xù)的3個3后就認為數(shù)據(jù)包3丟了，然后就會只補傳數(shù)據(jù)包3钱豁。
注意點：
上面的文章中我為了方便講解都是把數(shù)據(jù)包編成編號進行描述耻卡，其實真正的數(shù)據(jù)包編號不是這樣的疯汁，TCP協(xié)議是面向字節(jié)流的牲尺，所以說序號和確認號應(yīng)以字節(jié)為標準，比如：A現(xiàn)在向B發(fā)送了5和數(shù)據(jù)包共100個字節(jié)，B收到這5個數(shù)據(jù)包后會給A回復(fù)一個101谤碳，此時A就會從第101個字節(jié)開始進行發(fā)送溃卡，以此類推。
2.4 流量控制
流量控制：用來協(xié)調(diào)server和client兩端因處理數(shù)據(jù)速度不同所帶來的問題蜒简。
舉個例子：
假如主機A要向主機B發(fā)送數(shù)據(jù)瘸羡，如果主機A發(fā)送數(shù)據(jù)的速度比主機B處理數(shù)據(jù)的速度要快，那么很可能導(dǎo)致主機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)流量控制锚扎，如圖2-10：
圖2-10中B為發(fā)送方A為接收方吞瞪，當B與A建立連接的時候首先會明確自己滑動窗口的大小，假如是10驾孔，B就會將rwnd(滑動窗口)設(shè)置為10尸饺，A收到后也會將滑動窗口設(shè)置為10，連接建立成功會A開始向B發(fā)送數(shù)據(jù)助币，我們知道滑動窗口越大發(fā)送的速度越快浪听，假如rwnd=10時B處理數(shù)據(jù)包的速度小于接收數(shù)據(jù)包的速度那么滑動窗口會逐漸被填滿，這樣會導(dǎo)致主機B中未處理的數(shù)據(jù)包越來越多最終可能會崩潰眉菱，為了避免這種情況的出現(xiàn)迹栓，B可以在滑動窗口被填滿了之后給A發(fā)送一個rwnd=6，A接收到rwnd=6后會將滑動窗口調(diào)整為6進而降低發(fā)送數(shù)據(jù)的速度俭缓，同樣B如果覺得A的發(fā)送速度過慢也可以通過設(shè)置rwnd的值來調(diào)整A的發(fā)送速度克伊，B動態(tài)的設(shè)置A的滑動窗口就稱作為TCP流量控制技術(shù)。
2.5 擁塞避免
什么是擁塞呢华坦？顧名思義就是賭了愿吹，數(shù)據(jù)被堵在半路了，那什么情況下會出現(xiàn)數(shù)據(jù)被堵在半路呢惜姐？舉個例子：
假如現(xiàn)有兩臺主機分別是發(fā)送方主機A和接收方主機B犁跪，主機B的帶寬為50M/S椿息，也就是說主機B每秒最多能接收50M的數(shù)據(jù)，如果主機A的發(fā)送速度遠低于50M/S坷衍，這種情況應(yīng)該是不會出現(xiàn)擁塞現(xiàn)象的寝优，但是如果主機A的發(fā)送速度遠大于50M/S，主機B的路由器接手不了這么多數(shù)據(jù)只能進行丟棄枫耳，路由器也是有CPU乏矾、內(nèi)存和自己的操作系統(tǒng)，當主句A發(fā)送速度越快主機B的路由器CPU和內(nèi)存就要分配更多的資源去處理丟棄數(shù)據(jù)包迁杨，這樣就會導(dǎo)致接收數(shù)據(jù)包的速度越來越低钻心，極端的情況下可能會出現(xiàn)主機B接收不到數(shù)據(jù)包的現(xiàn)象，也就是死鎖現(xiàn)象铅协。
如果在進行TCP數(shù)據(jù)傳輸?shù)臅r候不進行流量控制很容易出現(xiàn)死鎖現(xiàn)象扔役，因為網(wǎng)絡(luò)是大家共用的，所以避免網(wǎng)絡(luò)擁塞現(xiàn)象的出現(xiàn)需要所有計算機遵守一種特定的規(guī)則警医，那這種規(guī)則是怎樣控制網(wǎng)絡(luò)避免擁塞的呢亿胸？先來看圖2-11
如果不進行擁塞控制就是我們上面所說的，最終可能會出現(xiàn)圖2-11中綠線的情況预皇，現(xiàn)在我們要通過擁塞控制使網(wǎng)絡(luò)數(shù)據(jù)傳輸按照圖2-11中藍線進行侈玄，下面我們來說一下如何進行擁塞控制：如圖2-12
首先將滑動窗口設(shè)置為1，然后再傳輸過程中逐漸以指數(shù)倍增加吟温，當滑動窗口到達ssthresh的時候再以加法進行增加序仙，如果出現(xiàn)了擁塞現(xiàn)象就迅速再將滑動窗口設(shè)置為1，ssthresh減小依次循環(huán)鲁豪，這種方式也稱為慢開始方式潘悼。但這種方式已經(jīng)被廢棄，因為每次出現(xiàn)擁塞的時候都會將滑動窗口設(shè)置為0再進行慢開始階段爬橡，這樣其實是完全沒必要的治唤，我們再來看升級版，如圖2-13
在出現(xiàn)擁塞的時候并不會將滑動窗口設(shè)置為1重新進行慢開始糙申，而是將滑動窗口設(shè)置為出現(xiàn)擁塞時窗口的一半宾添，然后再以加法進行增加，此過程也可稱為是快恢復(fù)柜裸，這樣就可以避免網(wǎng)絡(luò)擁塞的出現(xiàn)缕陕。
總結(jié)
這篇文章描述了傳輸層協(xié)議UDP和TCP，而傳輸層就這兩個協(xié)議疙挺，所以想要掌握傳輸層就必須掌握UDP和TCP扛邑，UDP為不可靠傳輸?shù)珎鬏斝矢撸琓CP為可靠傳輸铐然，是面向連接的蔬崩，同時相對于UDP傳輸效率要低一些恶座。
這篇文章是我Android網(wǎng)絡(luò)編程的第一篇文章，因為寫的是純理論的文章所以一些概念需要借助圖來講解舱殿，由于筆者手比較殘從生下來就沒有一顆美術(shù)細胞奥裸，所以文章中大多數(shù)圖都是摘自韓立剛老師計算機網(wǎng)絡(luò)教程中险掀，這篇文章對傳輸層協(xié)議描述到此為止沪袭，下篇文章Android網(wǎng)絡(luò)編程(二)Socket編程。
