1、前言

網(wǎng)絡(luò)通信一直是Android項(xiàng)目里比較重要的一個(gè)模塊，Android開源項(xiàng)目上出現(xiàn)過很多優(yōu)秀的網(wǎng)絡(luò)框架，從一開始只是一些對(duì)HttpClient和HttpUrlConnection簡(jiǎn)易封裝使用的工具類，到后來Google開源的比較完善豐富的Volley，再到如今比較流行的Okhttp、Retrofit。

要想理解他們之間存在的異同(或者具體點(diǎn)說，要想更深入地掌握Android開發(fā)中的網(wǎng)絡(luò)通信技術(shù))，必須對(duì)網(wǎng)絡(luò)基礎(chǔ)知識(shí)、Android網(wǎng)絡(luò)框架的基本原理等做到心中有數(shù)、信手拈來，關(guān)鍵時(shí)刻才能找到適合您APP的最佳網(wǎng)絡(luò)通信技術(shù)實(shí)踐。

事實(shí)證明在Android的日常開發(fā)和源碼閱讀中也會(huì)經(jīng)常碰到相關(guān)知識(shí)，掌握這些網(wǎng)絡(luò)基礎(chǔ)知識(shí)，也是Android程序員真正邁向高階的過程中必備的一些基本技術(shù)素質(zhì)之一。

有鑒于此，本文將主要介紹計(jì)算機(jī)網(wǎng)絡(luò)的一些基礎(chǔ)，以及在Android開發(fā)中的一些使用及遇到的問題和解決。

本篇主要分為以下幾部分：

• 1)計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu);
• 2)Http相關(guān);
• 3)Tcp相關(guān);
• 4)Socket。

2、關(guān)于作者

舒大飛：攜程網(wǎng)Android開發(fā)工程師。

注：在收錄本文時(shí)，為了更易于理解，對(duì)內(nèi)容做了更為細(xì)致的修訂。

3、計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)，即經(jīng)?？吹降挠?jì)算機(jī)網(wǎng)絡(luò)體系的分層結(jié)構(gòu)，理清這個(gè)還是有必要的，防止對(duì)Http和Tcp兩個(gè)根本不在同一層的協(xié)議糾纏不清。 根據(jù)不同的參考模型，分層結(jié)構(gòu)有幾個(gè)不同的版本，如OSI模型以及TCP/IP模型。

下面就以比較經(jīng)常看到的的5層結(jié)構(gòu)為例： 

如上圖所示，五層的體系結(jié)構(gòu)至上往下，最終可以實(shí)現(xiàn)端對(duì)端之間的數(shù)據(jù)傳輸與通信，他們各自負(fù)責(zé)一些什么，最終如何實(shí)現(xiàn)端對(duì)端之間的通信?

• 應(yīng)用層：如http協(xié)議，它實(shí)際上是定義了如何包裝和解析數(shù)據(jù)，應(yīng)用層是http協(xié)議的話，則會(huì)按照協(xié)議規(guī)定包裝數(shù)據(jù)，如按照請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體包裝，包裝好數(shù)據(jù)后將數(shù)據(jù)傳至運(yùn)輸層。
• 運(yùn)輸層：運(yùn)輸層有TCP和UDP兩種協(xié)議，分別對(duì)應(yīng)可靠的運(yùn)輸和不可靠的運(yùn)輸，如TCP因?yàn)橐峁┛煽康膫鬏?，所以?nèi)部要解決如何建立連接、如何保證傳輸是可靠的不丟數(shù)據(jù)、如何調(diào)節(jié)流量控制和擁塞控制。關(guān)于這一層，我們平常一般都是和Socket打交道，Socket是一組封裝的編程調(diào)用接口，通過它，我們就能操作TCP、UDP進(jìn)行連接的建立等。我們平常使用Socket進(jìn)行連接建立的時(shí)候，一般都要指定端口號(hào),所以這一層指定了把數(shù)據(jù)送到對(duì)應(yīng)的端口號(hào)。
• 網(wǎng)絡(luò)層：這一層IP協(xié)議，以及一些路由選擇協(xié)議等等，所以這一層的指定了數(shù)據(jù)要傳輸?shù)侥膫€(gè)IP地址。中間涉及到一些最優(yōu)線路，路由選擇算法等等。
• 數(shù)據(jù)鏈路層：印象比較深的就是ARP協(xié)議，負(fù)責(zé)把IP地址解析為MAC地址，即硬件地址，這樣就找到了對(duì)應(yīng)的唯一的機(jī)器。
• 物理層：這一層就是最底層了，提供二進(jìn)制流傳輸服務(wù)，也就是也就是真正開始通過傳輸介質(zhì)(有線、無(wú)線)開始進(jìn)行數(shù)據(jù)的傳輸了。

所以通過上面五層的各司其職，實(shí)現(xiàn)物理傳輸介質(zhì)--MAC地址--IP地址--端口號(hào)--獲取到數(shù)據(jù)根據(jù)應(yīng)用層協(xié)議解析數(shù)據(jù)最終實(shí)現(xiàn)了網(wǎng)絡(luò)通信和數(shù)據(jù)傳輸。

下面會(huì)著重講一下HTTP和TCP相關(guān)的東西。

4、HTTP相關(guān)

本節(jié)主要講一些關(guān)于Http的基礎(chǔ)知識(shí)，以及在Android中的一些實(shí)際應(yīng)用和碰到的問題和解決。

4.1 正確理解HTTP的“無(wú)連接”“與無(wú)狀態(tài)”

Http是無(wú)連接無(wú)狀態(tài)的。

無(wú)連接并不是說不需要連接，Http協(xié)議只是一個(gè)應(yīng)用層協(xié)議，最終還是要靠運(yùn)輸層的如TCP協(xié)議向上提供的服務(wù)進(jìn)行連接。

無(wú)連接的含義是http約定了每次連接只處理一個(gè)請(qǐng)求，一次請(qǐng)求完成后就斷開連接，這樣主要是為了緩解服務(wù)器的壓力，減小連接對(duì)服務(wù)器資源的占用。我的理解是，建立連接實(shí)際上是運(yùn)輸層的事，面向應(yīng)用層的http來說的話，它就是無(wú)連接的，因?yàn)樯蠈訉?duì)下層無(wú)感知。

無(wú)狀態(tài)的指每個(gè)請(qǐng)求之間都是獨(dú)立的，對(duì)于之前的請(qǐng)求事務(wù)沒有記憶的能力。所以就出現(xiàn)了像Cookie這種，用來保存一些狀態(tài)的東西。

4.2 請(qǐng)求報(bào)文與響應(yīng)報(bào)文

這里主要簡(jiǎn)單說一下HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文的格式方面的基礎(chǔ)知識(shí)。

請(qǐng)求報(bào)文： 

響應(yīng)報(bào)文: 

關(guān)于Get和Post，我們都熟知的關(guān)于Get和Post的區(qū)別大致有以下幾點(diǎn)：

• Get會(huì)把請(qǐng)求參數(shù)都拼接在url后面，最終顯示在地址欄，而Post則會(huì)把請(qǐng)求參數(shù)數(shù)據(jù)放進(jìn)請(qǐng)求體中，不會(huì)再地址欄顯示出來;
• 傳遞參數(shù)的長(zhǎng)度限制。

問題：

• 對(duì)于第1)點(diǎn)，如果是在瀏覽器里把隱私數(shù)據(jù)暴露在地址欄上確實(shí)不妥，但是如果是在App開發(fā)中呢，沒有地址欄的概念，那么這一點(diǎn)是不是還會(huì)成為選擇post還是get的制約條件;
• 對(duì)于第2)點(diǎn)，長(zhǎng)度的限制應(yīng)該是瀏覽器的限制，跟get本身無(wú)關(guān)，如果是在App開發(fā)中，這一點(diǎn)是否也可以忽略。

4.3 HTTP的緩存機(jī)制

之所以想介紹以下Http的緩存機(jī)制，是因?yàn)镺khttp中對(duì)于網(wǎng)絡(luò)請(qǐng)求緩存這一塊就是利用了Http的的緩存機(jī)制，而不是像Volley等框架那樣客戶端完全自己寫一套緩存策略自己玩。

Http的緩存主要利用header里的兩個(gè)字段來控制：即Cache-control和ETag，下面將分別來介紹。

1)Cache-control主要包含以及幾個(gè)字段：

• private:則只有客戶端可以緩存;
• public:客戶端和代理服務(wù)器都可以緩存;
• max-age:緩存的過期時(shí)間;
• no-cache:需要使用對(duì)比緩存來驗(yàn)證緩存數(shù)據(jù);
• no-store:所有內(nèi)存都不會(huì)進(jìn)行緩存。

實(shí)際上就是在這里面設(shè)置了一個(gè)緩存策略，由服務(wù)端第一次通過header下發(fā)給客戶端，可以看到：

• max-age：即緩存過期的時(shí)間，則之后再次請(qǐng)求，如果沒有超過緩存失效的時(shí)間則可以直接使用緩存;
• no-cache：表示需要使用對(duì)比緩存來驗(yàn)證緩存數(shù)據(jù)，如果這個(gè)字段是打開的，則就算max-age緩存沒有失效，則還是需要發(fā)起一次請(qǐng)求向服務(wù)端確認(rèn)一下資源是否有更新，是否需要重新請(qǐng)求數(shù)據(jù)，至于怎么做對(duì)比緩存，就是下面要說的Etag的作用。如果服務(wù)端確認(rèn)資源沒有更新，則返回304，取本地緩存即可，如果有更新，則返回最新的資源;
• no-store：這個(gè)字段打開，則不會(huì)進(jìn)行緩存，也不會(huì)取緩存。

2)ETag：即用來進(jìn)行對(duì)比緩存，Etag是服務(wù)端資源的一個(gè)標(biāo)識(shí)碼

當(dāng)客戶端發(fā)送第一次請(qǐng)求時(shí)服務(wù)端會(huì)下發(fā)當(dāng)前請(qǐng)求資源的標(biāo)識(shí)碼Etag，下次再請(qǐng)求時(shí)，客戶端則會(huì)通過header里的If-None-Match將這個(gè)標(biāo)識(shí)碼Etag帶上，服務(wù)端將客戶端傳來的Etag與最新的資源Etag做對(duì)比，如果一樣，則表示資源沒有更新，返回304。

3)小結(jié)：

通過Cache-control和Etag的配合來實(shí)現(xiàn)Http的緩存機(jī)制。

4.4 HTTP的Cookie

上面說了Http協(xié)議是無(wú)狀態(tài)的，而Cookie就是用來在本地緩存記住一些狀態(tài)的，一個(gè)Cookie一般都包含domin(所屬域)、path、Expires(過期時(shí)間)等幾個(gè)屬性。服務(wù)端可以通過在響應(yīng)頭里的set-cookies來將狀態(tài)寫入客戶端的Cookie里。下次客戶端發(fā)起請(qǐng)求時(shí)可以將Cookie帶上。

Android開發(fā)中遇到的問題及解決：

說起Cookie，一般如果平常只是做App開發(fā)，比較不經(jīng)常遇到，但是如果是涉及到WebView的需求，則有可能會(huì)遇到。

下面就說一下我在項(xiàng)目里遇到過的一個(gè)關(guān)于WebView Cookie的揪心往事：需求是這樣的，加載的WebView中的H5頁(yè)面需要是已登錄狀態(tài)的，所以我們需要在原生頁(yè)面登錄后，手動(dòng)將ticket寫入WebView的Cookie，之后WebView里加載的H5頁(yè)面帶著Cookie里的ticket給服務(wù)端驗(yàn)證通過就好了。

但是遇到一個(gè)問題：通過Chrome inspect調(diào)試WebView，手動(dòng)寫的Cookie確實(shí)是已經(jīng)寫進(jìn)去了，但是發(fā)起請(qǐng)求的時(shí)候，Cookie就是沒有帶上，導(dǎo)致請(qǐng)求驗(yàn)證失敗，之后通過排查，是WebView的屬性默認(rèn)關(guān)閉引起，通過下面的代碼設(shè)置打開即可：

CookieManager cookieManager = CookieManager.getInstance();  
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {  
cookieManager.setAcceptThirdPartyCookies(mWebView, true);  
} else{  
cookieManager.setAcceptCookie(true);  
} 

4.5 Https

我們都知道Https保證了我們數(shù)據(jù)傳輸?shù)陌踩?，Https=Http+Ssl，之所以能保證安全主要的原理就是利用了非對(duì)稱加密算法，平常用的對(duì)稱加密算法之所以不安全，是因?yàn)殡p方是用統(tǒng)一的密匙進(jìn)行加密解密的，只要雙方任意一方泄漏了密匙，那么其他人就可以利用密匙解密數(shù)據(jù)。

而非對(duì)稱加密算法之所以能實(shí)現(xiàn)安全傳輸?shù)暮诵木A就是：公鑰加密的信息只能用私鑰解開，私鑰加密的信息只能被公鑰解開。

1)簡(jiǎn)述非對(duì)稱加密算法為什么安全：

服務(wù)端申請(qǐng)CA機(jī)構(gòu)頒發(fā)的證書，則獲取到了證書的公鑰和私鑰，私鑰只有服務(wù)器端自己知道，而公鑰可以告知其他人，如可以把公鑰傳給客戶端，這樣客戶端通過服務(wù)端傳來的公鑰來加密自己傳輸?shù)臄?shù)據(jù)，而服務(wù)端利用私鑰就可以解密這個(gè)數(shù)據(jù)了。由于客戶端這個(gè)用公鑰加密的數(shù)據(jù)只有私鑰能解密，而這個(gè)私鑰只有服務(wù)端有，所以數(shù)據(jù)傳輸就安全了。

上面只是簡(jiǎn)單說了一下非對(duì)稱加密算法是如何保證數(shù)據(jù)安全的，實(shí)際上Https的工作過程遠(yuǎn)比這要復(fù)雜(篇幅限制這里就不細(xì)說了，網(wǎng)上有很多相關(guān)文章)：

一個(gè)是客戶端還需要驗(yàn)證服務(wù)端傳來的CA證書的合法性、有效性，因?yàn)榇嬖趥鬏斶^程CA證書被人調(diào)包的風(fēng)險(xiǎn),涉及到客戶端如何驗(yàn)證服務(wù)器證書的合法性的問題，保證通信雙方的身份合法;

另一個(gè)是非對(duì)稱算法雖然保證了數(shù)據(jù)的安全，但是效率相對(duì)于對(duì)稱算法來說比較差，如何來優(yōu)化，實(shí)現(xiàn)既保證了數(shù)據(jù)的安全，又提高了效率。

2)客戶端如何驗(yàn)證證書的合法性：

首先CA證書一般包括以下內(nèi)容：

• 證書的頒發(fā)機(jī)構(gòu)以及版本;
• 證書的使用者;
• 證書的公鑰;
• 證書有效時(shí)間;
• 證書的數(shù)字簽名Hash值以及簽名Hash算法(這個(gè)數(shù)字簽名Hash值是用證書的私鑰加密過的值);
• 等等。

客戶端驗(yàn)證服務(wù)端傳過來的證書的合法性是通過：先利用獲取到的公鑰來解密證書中的數(shù)字簽名Hash值1(因?yàn)樗抢盟借€加密的嘛)，然后在利用證書里的簽名Hash算法生成一個(gè)Hash值2，如果兩個(gè)值相等，則表示證書合法，服務(wù)器端可以被信任。

3)Android開發(fā)中遇到的問題及解決：

順便說一個(gè)在項(xiàng)目開發(fā)中使用Android WebView加載公司測(cè)試服務(wù)器上網(wǎng)頁(yè)證書過期導(dǎo)致網(wǎng)頁(yè)加載不出來白屏的問題。

解決方案就是測(cè)試環(huán)境下暫時(shí)忽略SSL的報(bào)錯(cuò)，這樣就可以把網(wǎng)頁(yè)加載出來，當(dāng)然在生產(chǎn)上不要這么做，一個(gè)是會(huì)有安全問題，一個(gè)是google play應(yīng)該審核也不會(huì)通過。

最佳辦法是重寫WebViewClient的onReceivedSslError()：

@Override  
publicvoidonReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {  
if(ContextHolder.sDebug) {  
handler.proceed();  
return;  
}  
super.onReceivedSslError(view, handler, error);  
} 

4.6 Http 2.0

Okhttp支持配置使用Http 2.0協(xié)議，Http2.0相對(duì)于Http1.x來說提升是巨大的，主要有以下幾點(diǎn)。

1)二進(jìn)制格式：http1.x是文本協(xié)議，而http2.0是二進(jìn)制以幀為基本單位，是一個(gè)二進(jìn)制協(xié)議，一幀中除了包含數(shù)據(jù)外同時(shí)還包含該幀的標(biāo)識(shí)：Stream Identifier，即標(biāo)識(shí)了該幀屬于哪個(gè)request,使得網(wǎng)絡(luò)傳輸變得十分靈活;

2)多路復(fù)用：一個(gè)很大的改進(jìn)，原先http1.x一個(gè)連接一個(gè)請(qǐng)求的情況有比較大的局限性，也引發(fā)了很多問題，如建立多個(gè)連接的消耗以及效率問題。

http1.x為了解決效率問題，可能會(huì)盡量多的發(fā)起并發(fā)的請(qǐng)求去加載資源，然而瀏覽器對(duì)于同一域名下的并發(fā)請(qǐng)求有限制，而優(yōu)化的手段一般是將請(qǐng)求的資源放到不同的域名下來突破這種限制。

而http2.0支持的多路復(fù)用可以很好的解決這個(gè)問題，多個(gè)請(qǐng)求共用一個(gè)TCP連接，多個(gè)請(qǐng)求可以同時(shí)在這個(gè)TCP連接上并發(fā)，一個(gè)是解決了建立多個(gè)TCP連接的消耗問題，一個(gè)也解決了效率的問題。

那么是什么原理支撐多個(gè)請(qǐng)求可以在一個(gè)TCP連接上并發(fā)呢?基本原理就是上面的二進(jìn)制分幀，因?yàn)槊恳粠加幸粋€(gè)身份標(biāo)識(shí)，所以多個(gè)請(qǐng)求的不同幀可以并發(fā)的無(wú)序發(fā)送出去，在服務(wù)端會(huì)根據(jù)每一幀的身份標(biāo)識(shí)，將其整理到對(duì)應(yīng)的request中。

3)header頭部壓縮：主要是通過壓縮header來減少請(qǐng)求的大小，減少流量消耗，提高效率。因?yàn)橹按嬖谝粋€(gè)問題是，每次請(qǐng)求都要帶上header，而這個(gè)header中的數(shù)據(jù)通常是一層不變的。

4)支持服務(wù)端推送。

5、TCP相關(guān)

TCP面向連接，提供可靠的數(shù)據(jù)傳輸。在這一層，我們通常都是通過Socket Api來操作TCP，建立連接等等。

5.1 三次握手建立連接 

• 第一次：發(fā)送SNY=1表示此次握手是請(qǐng)求建立連接的，然后seq生成一個(gè)客戶端的隨機(jī)數(shù)X
• 第二次：發(fā)送SNY=1,ACK=1表示是回復(fù)請(qǐng)求建立連接的，然后ack=客戶端的seq+1(這樣客戶端收到后就能確認(rèn)是之前想要連接的那個(gè)服務(wù)端)，然后把服務(wù)端也生成一個(gè)代表自己的隨機(jī)數(shù)seq=Y發(fā)給客戶端。
• 第三次：ACK=1。 seq=客戶端隨機(jī)數(shù)+1，ack=服務(wù)端隨機(jī)數(shù)+1(這樣服務(wù)端就知道是剛剛那個(gè)客戶端了)

為什么建立連接需要三次握手?

首先非常明確的是兩次握手是最基本的，第一次握手，C端發(fā)了個(gè)連接請(qǐng)求消息到S端，S端收到后S端就知道自己與C端是可以連接成功的，但是C端此時(shí)并不知道S端是否接收到這個(gè)消息，所以S端接收到消息后得應(yīng)答，C端得到S端的回復(fù)后，才能確定自己與S端是可以連接上的，這就是第二次握手。

C端只有確定了自己能與S端連接上才能開始發(fā)數(shù)據(jù)。所以兩次握手肯定是最基本的。

那么為什么需要第三次握手呢?假設(shè)一下如果沒有第三次握手，而是兩次握手后我們就認(rèn)為連接建立，那么會(huì)發(fā)生什么?

第三次握手是為了防止已經(jīng)失效的連接請(qǐng)求報(bào)文段突然又傳到服務(wù)端，因而產(chǎn)生錯(cuò)誤。

具體情況就是：

C端發(fā)出去的第一個(gè)網(wǎng)絡(luò)連接請(qǐng)求由于某些原因在網(wǎng)絡(luò)節(jié)點(diǎn)中滯留了，導(dǎo)致延遲，直到連接釋放的某個(gè)時(shí)間點(diǎn)才到達(dá)S端，這是一個(gè)早已失效的報(bào)文，但是此時(shí)S端仍然認(rèn)為這是C端的建立連接請(qǐng)求第一次握手，于是S端回應(yīng)了C端，第二次握手。

如果只有兩次握手，那么到這里，連接就建立了，但是此時(shí)C端并沒有任何數(shù)據(jù)要發(fā)送，而S端就會(huì)傻傻的等待著，造成很大的資源浪費(fèi)。所以需要第三次握手，只有C端再次回應(yīng)一下，就可以避免這種情況。

5.2 四次揮手?jǐn)嚅_連接 

經(jīng)過上面的建立連接圖的解析，這個(gè)圖應(yīng)該不難看懂。

這里主要有一個(gè)問題：為什么比建立連接時(shí)多了一次揮手?

可以看到這里服務(wù)端的ACK(回復(fù)客戶端)和FIN(終止)消息并不是同時(shí)發(fā)出的，而是先ACK，然后再FIN，這也很好理解，當(dāng)客戶端要求斷開連接時(shí)，此時(shí)服務(wù)端可能還有未發(fā)送完的數(shù)據(jù)，所以先ACK，然后等數(shù)據(jù)發(fā)送完再FIN。這樣就變成了四次握手了。

上面講了TCP建立連接和斷開連接的過程，TCP最主要的特點(diǎn)就是提供可靠的傳輸，那么他是如何保證數(shù)據(jù)傳輸是可靠的呢，這就是下面要講的滑動(dòng)窗口協(xié)議。

5.3 滑動(dòng)窗口協(xié)議

滑動(dòng)窗口協(xié)議是保證TCP的可靠傳輸?shù)母?，因?yàn)榘l(fā)送窗口只有收到確認(rèn)幀才會(huì)向后移動(dòng)窗口繼續(xù)發(fā)送其他幀。

下面舉個(gè)例子：假如發(fā)送窗口是3幀

一開始發(fā)送窗口在前3幀[1,2,3],則前3幀是可以發(fā)送的，后面的則暫時(shí)不可以發(fā)送，比如[1]幀發(fā)送出去后，收到了來自接收方的確認(rèn)消息，則此時(shí)發(fā)送窗口才可以往后移1幀，發(fā)送窗口來到[2，3，4]，同樣只有發(fā)送窗口內(nèi)的幀才可以被發(fā)送，一次類推。

而接收窗口接收到幀后將其放入對(duì)應(yīng)的位置，然后移動(dòng)接收窗口，接口窗口與發(fā)送窗口一樣也有一個(gè)大小，如接收窗口是5幀，則落在接收窗口之外的幀會(huì)被丟棄。

發(fā)送窗口和接收窗口大小的不同設(shè)定就延伸出了不同的協(xié)議： 

停止-等待協(xié)議：每發(fā)一幀都要等到確認(rèn)消息才能發(fā)送下一幀，缺點(diǎn):效率較差。

后退N幀協(xié)議：采取累計(jì)確認(rèn)的方式，接收方正確的接受到N幀后發(fā)一個(gè)累計(jì)確認(rèn)消息給發(fā)送窗口，確認(rèn)N幀已正確收到，如果發(fā)送方規(guī)定時(shí)間內(nèi)未收到確認(rèn)消息則認(rèn)為超時(shí)或數(shù)據(jù)丟失，則會(huì)重新發(fā)送確認(rèn)幀之后的所有幀。缺點(diǎn):出錯(cuò)序號(hào)后面的PDU已經(jīng)發(fā)送過了，但是還是要重新發(fā)送，比較浪費(fèi)。

選擇重傳協(xié)議：若出現(xiàn)差錯(cuò)，只重新傳輸出現(xiàn)差錯(cuò)涉及需要的PDU,提高了傳輸效率，減少不必要的重傳。

到這里還剩下最后一個(gè)問題：由于發(fā)送窗口與接收窗口之間會(huì)存在發(fā)送效率和接收效率不匹配的問題，就會(huì)導(dǎo)致?lián)砣?，解決這個(gè)問題TCP有一套流量控制和擁塞控制的機(jī)制。

5.4 流量控制和擁塞控制

1)流量控制：

流量控制是對(duì)一條通信路徑上的流量進(jìn)行控制，就是發(fā)送方通過獲取接收方的回饋來動(dòng)態(tài)調(diào)整發(fā)送的速率，來達(dá)到控制流量的效果，其目的是保證發(fā)送者的發(fā)送速度不超過接收者的接收速度。

2)擁塞控制：

擁塞控制是對(duì)整個(gè)通信子網(wǎng)的流量進(jìn)行控制，屬于全局控制。

① 慢開始+擁塞避免

先來看一張經(jīng)典的圖： 

一開始使用慢啟動(dòng)，即擁塞窗口設(shè)為1，然后擁塞窗口指數(shù)增長(zhǎng)到慢開始的門限值(ssthresh=16),則切換為擁塞避免,即加法增長(zhǎng)，這樣增長(zhǎng)到一定程度，導(dǎo)致網(wǎng)絡(luò)擁塞，則此時(shí)會(huì)把擁塞窗口重新降為1，即重新慢開始，同時(shí)調(diào)整新的慢開始門限值為12，之后以此類推。

② 快重傳+快恢復(fù)

快重傳：上面我們說的重傳機(jī)制都是等到超時(shí)還未收到接收方的回復(fù)，才開始進(jìn)行重傳。而快重傳的設(shè)計(jì)思路是：如果發(fā)送方收到3個(gè)重復(fù)的接收方的ACK，就可以判斷有報(bào)文段丟失，此時(shí)就可以立即重傳丟失的報(bào)文段，而不用等到設(shè)置的超時(shí)時(shí)間到了才開始重傳，提高了重傳的效率。

快恢復(fù)：上面的擁塞控制會(huì)在網(wǎng)絡(luò)擁塞時(shí)將擁塞窗口降為1，重新慢開始，這樣存在的一個(gè)問題就是網(wǎng)絡(luò)無(wú)法很快恢復(fù)到正常狀態(tài)?？旎謴?fù)就是來優(yōu)化這個(gè)問題的，使用快恢復(fù)，則出現(xiàn)擁塞時(shí)，擁塞窗口只會(huì)降低到新的慢開始門閥值(即12)，而不會(huì)降為1，然后直接開始進(jìn)入擁塞避免加法增長(zhǎng)，如下圖所示： 

快重傳和快恢復(fù)是對(duì)擁塞控制的進(jìn)一步改進(jìn)。

6、有關(guān)Socket

Socket是一組操作TCP/UDP的API，像HttpURLConnection和Okhttp這種涉及到比較底層的網(wǎng)絡(luò)請(qǐng)求發(fā)送的，最終當(dāng)然也都是通過Socket來進(jìn)行網(wǎng)絡(luò)請(qǐng)求連接發(fā)送，而像Volley、Retrofit則是更上層的封裝，最后是依靠HttpURLConnection或者Okhttp來進(jìn)行最終的連接建立和請(qǐng)求發(fā)送。

Socket的簡(jiǎn)單使用的話應(yīng)該都會(huì)，兩個(gè)端各建立一個(gè)Socket，服務(wù)端的叫ServerSocket，然后建立連接即可。

7、本文小結(jié)

當(dāng)然，以上這些內(nèi)容只是我自己知道的并且認(rèn)為挺重要的計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)，還有非常多的網(wǎng)絡(luò)基礎(chǔ)知識(shí)需要去深入了解去探索。寫了很多，算是對(duì)自己網(wǎng)絡(luò)基礎(chǔ)的一個(gè)整理，可能也會(huì)有紕漏，權(quán)當(dāng)拋磚引玉，還請(qǐng)各位大牛不吝賜教。