1、前言
網(wǎng)絡通信一直是Android項目里比較重要的一個模塊，Android開源項目上出現(xiàn)過很多優(yōu)秀的網(wǎng)絡框架，從一開始只是一些對HttpClient和HttpUrlConnection簡易封裝使用的工具類，到后來Google開源的比較完善豐富的Volley，再到如今比較流行的Okhttp、Retrofit。
要想理解他們之間存在的異同（或者具體點說，要想更深入地掌握Android開發(fā)中的網(wǎng)絡通信技術(shù)），必須對網(wǎng)絡基礎(chǔ)知識、Android網(wǎng)絡框架的基本原理等做到心中有數(shù)、信手拈來，關(guān)鍵時刻才能找到適合您APP的最佳網(wǎng)絡通信技術(shù)實踐。
事實證明在Android的日常開發(fā)和源碼閱讀中也會經(jīng)常碰到相關(guān)知識，掌握這些網(wǎng)絡基礎(chǔ)知識，也是Android程序員真正邁向高階的過程中必備的一些基本技術(shù)素質(zhì)之一。
有鑒于此，本文將主要介紹計算機網(wǎng)絡的一些基礎(chǔ)，以及在Android開發(fā)中的一些使用及遇到的問題和解決。
本篇主要分為以下幾部分：
1）計算機網(wǎng)絡體系結(jié)構(gòu)；
2）Http相關(guān)；
3）Tcp相關(guān)；
4）Socket。
學習交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1963-1-1.html）
2、關(guān)于作者
舒大飛：攜程網(wǎng)Android開發(fā)工程師，作者博客：https://www.jianshu.com/u/ae379336190b。
注：在收錄本文時，為了更易于理解，對內(nèi)容做了更為細致的修訂。
3、計算機網(wǎng)絡體系結(jié)構(gòu)
計算機網(wǎng)絡體系結(jié)構(gòu)，即經(jīng)常看到的計算機網(wǎng)絡體系的分層結(jié)構(gòu)，理清這個還是有必要的，防止對Http和Tcp兩個根本不在同一層的協(xié)議糾纏不清。 根據(jù)不同的參考模型，分層結(jié)構(gòu)有幾個不同的版本，如OSI模型以及TCP/IP模型。
下面就以比較經(jīng)常看到的的5層結(jié)構(gòu)為例：
（更為清晰完整的圖，請見《計算機網(wǎng)絡通訊協(xié)議關(guān)系圖（中文珍藏版）[附件下載] 》）
如上圖所示，五層的體系結(jié)構(gòu)至上往下，最終可以實現(xiàn)端對端之間的數(shù)據(jù)傳輸與通信，他們各自負責一些什么，最終如何實現(xiàn)端對端之間的通信？
1）應用層：如http協(xié)議，它實際上是定義了如何包裝和解析數(shù)據(jù)，應用層是http協(xié)議的話，則會按照協(xié)議規(guī)定包裝數(shù)據(jù)，如按照請求行、請求頭、請求體包裝，包裝好數(shù)據(jù)后將數(shù)據(jù)傳至運輸層。
2）運輸層：運輸層有TCP和UDP兩種協(xié)議，分別對應可靠的運輸和不可靠的運輸，如TCP因為要提供可靠的傳輸，所以內(nèi)部要解決如何建立連接、如何保證傳輸是可靠的不丟數(shù)據(jù)、如何調(diào)節(jié)流量控制和擁塞控制。關(guān)于這一層，我們平常一般都是和Socket打交道，Socket是一組封裝的編程調(diào)用接口，通過它，我們就能操作TCP、UDP進行連接的建立等。我們平常使用Socket進行連接建立的時候，一般都要指定端口號,所以這一層指定了把數(shù)據(jù)送到對應的端口號。
3）網(wǎng)絡層：這一層IP協(xié)議，以及一些路由選擇協(xié)議等等，所以這一層的指定了數(shù)據(jù)要傳輸?shù)侥膫€IP地址。中間涉及到一些最優(yōu)線路，路由選擇算法等等。
4）數(shù)據(jù)鏈路層：印象比較深的就是ARP協(xié)議，負責把IP地址解析為MAC地址，即硬件地址，這樣就找到了對應的唯一的機器。
5）物理層：這一層就是最底層了，提供二進制流傳輸服務，也就是也就是真正開始通過傳輸介質(zhì)（有線、無線）開始進行數(shù)據(jù)的傳輸了。
所以通過上面五層的各司其職，實現(xiàn)物理傳輸介質(zhì)--MAC地址--IP地址--端口號--獲取到數(shù)據(jù)根據(jù)應用層協(xié)議解析數(shù)據(jù)最終實現(xiàn)了網(wǎng)絡通信和數(shù)據(jù)傳輸。
下面會著重講一下HTTP和TCP相關(guān)的東西，關(guān)于其他層，畢業(yè)了這么久也忘的很多，如果想更加細致具體的了解像下面三層的如路由選擇算法、ARP尋址以及物理層等等還是要重新去看一下《TCP/IP詳解 卷1：協(xié)議》~
4、HTTP相關(guān)
本節(jié)主要講一些關(guān)于Http的基礎(chǔ)知識，以及在Android中的一些實際應用和碰到的問題和解決。
限于篇幅原因，本文在一些知識點上只做簡要性的概述，如果想要全面深入地掌握HTTP協(xié)議，請閱讀以下文章：
《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
4.1 正確理解HTTP的“無連接”“與無狀態(tài)”
Http是無連接無狀態(tài)的。
無連接并不是說不需要連接，Http協(xié)議只是一個應用層協(xié)議，最終還是要靠運輸層的如TCP協(xié)議向上提供的服務進行連接。
無連接的含義是http約定了每次連接只處理一個請求，一次請求完成后就斷開連接，這樣主要是為了緩解服務器的壓力，減小連接對服務器資源的占用。我的理解是，建立連接實際上是運輸層的事，面向應用層的http來說的話，它就是無連接的，因為上層對下層無感知。
無狀態(tài)的指每個請求之間都是獨立的，對于之前的請求事務沒有記憶的能力。所以就出現(xiàn)了像Cookie這種，用來保存一些狀態(tài)的東西。
4.2 請求報文與響應報文
這里主要簡單說一下HTTP請求報文和響應報文的格式方面的基礎(chǔ)知識。
請求報文：
響應報文:
關(guān)于Get和Post，我們都熟知的關(guān)于Get和Post的區(qū)別大致有以下幾點：
1）Get會把請求參數(shù)都拼接在url后面，最終顯示在地址欄，而Post則會把請求參數(shù)數(shù)據(jù)放進請求體中，不會再地址欄顯示出來；
2）傳遞參數(shù)的長度限制。
問題：
對于第1）點，如果是在瀏覽器里把隱私數(shù)據(jù)暴露在地址欄上確實不妥，但是如果是在App開發(fā)中呢，沒有地址欄的概念，那么這一點是不是還會成為選擇post還是get的制約條件；
對于第2）點，長度的限制應該是瀏覽器的限制，跟get本身無關(guān)，如果是在App開發(fā)中，這一點是否也可以忽略。
4.3 HTTP的緩存機制
之所以想介紹以下Http的緩存機制，是因為Okhttp中對于網(wǎng)絡請求緩存這一塊就是利用了Http的的緩存機制，而不是像Volley等框架那樣客戶端完全自己寫一套緩存策略自己玩。
Http的緩存主要利用header里的兩個字段來控制：即Cache-control和ETag，下面將分別來介紹。
1）Cache-control主要包含以及幾個字段：
private:則只有客戶端可以緩存；
public:客戶端和代理服務器都可以緩存；
max-age:緩存的過期時間；
no-cache:需要使用對比緩存來驗證緩存數(shù)據(jù)；
no-store:所有內(nèi)存都不會進行緩存。
實際上就是在這里面設(shè)置了一個緩存策略，由服務端第一次通過header下發(fā)給客戶端，可以看到：
max-age：即緩存過期的時間，則之后再次請求，如果沒有超過緩存失效的時間則可以直接使用緩存；
no-cache：表示需要使用對比緩存來驗證緩存數(shù)據(jù)，如果這個字段是打開的，則就算max-age緩存沒有失效，則還是需要發(fā)起一次請求向服務端確認一下資源是否有更新，是否需要重新請求數(shù)據(jù)，至于怎么做對比緩存，就是下面要說的Etag的作用。如果服務端確認資源沒有更新，則返回304，取本地緩存即可，如果有更新，則返回最新的資源；
no-store：這個字段打開，則不會進行緩存，也不會取緩存。
2）ETag：即用來進行對比緩存，Etag是服務端資源的一個標識碼
當客戶端發(fā)送第一次請求時服務端會下發(fā)當前請求資源的標識碼Etag，下次再請求時，客戶端則會通過header里的If-None-Match將這個標識碼Etag帶上，服務端將客戶端傳來的Etag與最新的資源Etag做對比，如果一樣，則表示資源沒有更新，返回304。
3）小結(jié)：
通過Cache-control和Etag的配合來實現(xiàn)Http的緩存機制。更多有關(guān)HTTP緩存方面的的知識，在文章《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》的相關(guān)章節(jié)做了詳細的讀解，可以參閱之。
4.4 HTTP的Cookie
上面說了Http協(xié)議是無狀態(tài)的，而Cookie就是用來在本地緩存記住一些狀態(tài)的，一個Cookie一般都包含domin(所屬域)、path、Expires(過期時間)等幾個屬性。服務端可以通過在響應頭里的set-cookies來將狀態(tài)寫入客戶端的Cookie里。下次客戶端發(fā)起請求時可以將Cookie帶上。
Android開發(fā)中遇到的問題及解決：
說起Cookie，一般如果平常只是做App開發(fā)，比較不經(jīng)常遇到，但是如果是涉及到WebView的需求，則有可能會遇到。
下面就說一下我在項目里遇到過的一個關(guān)于WebView Cookie的揪心往事：需求是這樣的，加載的WebView中的H5頁面需要是已登錄狀態(tài)的，所以我們需要在原生頁面登錄后，手動將ticket寫入WebView的Cookie，之后WebView里加載的H5頁面帶著Cookie里的ticket給服務端驗證通過就好了。
但是遇到一個問題：通過Chrome inspect調(diào)試WebView，手動寫的Cookie確實是已經(jīng)寫進去了，但是發(fā)起請求的時候，Cookie就是沒有帶上，導致請求驗證失敗，之后通過排查，是WebView的屬性默認關(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ù)陌踩琀ttps=Http+Ssl，之所以能保證安全主要的原理就是利用了非對稱加密算法，平常用的對稱加密算法之所以不安全，是因為雙方是用統(tǒng)一的密匙進行加密解密的，只要雙方任意一方泄漏了密匙，那么其他人就可以利用密匙解密數(shù)據(jù)。
而非對稱加密算法之所以能實現(xiàn)安全傳輸?shù)暮诵木A就是：公鑰加密的信息只能用私鑰解開，私鑰加密的信息只能被公鑰解開。
1）簡述非對稱加密算法為什么安全：
服務端申請CA機構(gòu)頒發(fā)的證書，則獲取到了證書的公鑰和私鑰，私鑰只有服務器端自己知道，而公鑰可以告知其他人，如可以把公鑰傳給客戶端，這樣客戶端通過服務端傳來的公鑰來加密自己傳輸?shù)臄?shù)據(jù)，而服務端利用私鑰就可以解密這個數(shù)據(jù)了。由于客戶端這個用公鑰加密的數(shù)據(jù)只有私鑰能解密，而這個私鑰只有服務端有，所以數(shù)據(jù)傳輸就安全了。
上面只是簡單說了一下非對稱加密算法是如何保證數(shù)據(jù)安全的，實際上Https的工作過程遠比這要復雜（篇幅限制這里就不細說了，網(wǎng)上有很多相關(guān)文章）：
一個是客戶端還需要驗證服務端傳來的CA證書的合法性、有效性，因為存在傳輸過程CA證書被人調(diào)包的風險,涉及到客戶端如何驗證服務器證書的合法性的問題，保證通信雙方的身份合法；
另一個是非對稱算法雖然保證了數(shù)據(jù)的安全，但是效率相對于對稱算法來說比較差，如何來優(yōu)化，實現(xiàn)既保證了數(shù)據(jù)的安全，又提高了效率。
2）客戶端如何驗證證書的合法性：
首先CA證書一般包括以下內(nèi)容：
證書的頒發(fā)機構(gòu)以及版本；
證書的使用者；
證書的公鑰；
證書有效時間；
證書的數(shù)字簽名Hash值以及簽名Hash算法（這個數(shù)字簽名Hash值是用證書的私鑰加密過的值）；
等等。
客戶端驗證服務端傳過來的證書的合法性是通過：先利用獲取到的公鑰來解密證書中的數(shù)字簽名Hash值1（因為它是利用私鑰加密的嘛），然后在利用證書里的簽名Hash算法生成一個Hash值2，如果兩個值相等，則表示證書合法，服務器端可以被信任。
3）Android開發(fā)中遇到的問題及解決：
順便說一個在項目開發(fā)中使用Android WebView加載公司測試服務器上網(wǎng)頁證書過期導致網(wǎng)頁加載不出來白屏的問題。
解決方案就是測試環(huán)境下暫時忽略SSL的報錯，這樣就可以把網(wǎng)頁加載出來，當然在生產(chǎn)上不要這么做，一個是會有安全問題，一個是google play應該審核也不會通過。
最佳辦法是重寫WebViewClient的onReceivedSslError()：
@Override
publicvoidonReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
if(ContextHolder.sDebug) {
handler.proceed();
return;
}
super.onReceivedSslError(view, handler, error);
}
最后：有關(guān)HTTPS更為詳細全面的知識，請深入閱讀《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》。
4.6 Http 2.0
Okhttp支持配置使用Http 2.0協(xié)議，Http2.0相對于Http1.x來說提升是巨大的，主要有以下幾點。
1）二進制格式：http1.x是文本協(xié)議，而http2.0是二進制以幀為基本單位，是一個二進制協(xié)議，一幀中除了包含數(shù)據(jù)外同時還包含該幀的標識：Stream Identifier，即標識了該幀屬于哪個request,使得網(wǎng)絡傳輸變得十分靈活；
2）多路復用：一個很大的改進，原先http1.x一個連接一個請求的情況有比較大的局限性，也引發(fā)了很多問題，如建立多個連接的消耗以及效率問題。
http1.x為了解決效率問題，可能會盡量多的發(fā)起并發(fā)的請求去加載資源，然而瀏覽器對于同一域名下的并發(fā)請求有限制，而優(yōu)化的手段一般是將請求的資源放到不同的域名下來突破這種限制。
而http2.0支持的多路復用可以很好的解決這個問題，多個請求共用一個TCP連接，多個請求可以同時在這個TCP連接上并發(fā)，一個是解決了建立多個TCP連接的消耗問題，一個也解決了效率的問題。
那么是什么原理支撐多個請求可以在一個TCP連接上并發(fā)呢？基本原理就是上面的二進制分幀，因為每一幀都有一個身份標識，所以多個請求的不同幀可以并發(fā)的無序發(fā)送出去，在服務端會根據(jù)每一幀的身份標識，將其整理到對應的request中。
3）header頭部壓縮：主要是通過壓縮header來減少請求的大小，減少流量消耗，提高效率。因為之前存在一個問題是，每次請求都要帶上header，而這個header中的數(shù)據(jù)通常是一層不變的。
4）支持服務端推送。
有關(guān)HTTP2的更多知識，請閱讀《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》。
5、TCP相關(guān)
TCP面向連接，提供可靠的數(shù)據(jù)傳輸。在這一層，我們通常都是通過Socket Api來操作TCP，建立連接等等。
5.1 三次握手建立連接
第一次：發(fā)送SNY=1表示此次握手是請求建立連接的，然后seq生成一個客戶端的隨機數(shù)X
第二次：發(fā)送SNY=1,ACK=1表示是回復請求建立連接的，然后ack=客戶端的seq+1（這樣客戶端收到后就能確認是之前想要連接的那個服務端），然后把服務端也生成一個代表自己的隨機數(shù)seq=Y發(fā)給客戶端。
第三次：ACK=1。 seq=客戶端隨機數(shù)+1，ack=服務端隨機數(shù)+1（這樣服務端就知道是剛剛那個客戶端了）
為什么建立連接需要三次握手？
首先非常明確的是兩次握手是最基本的，第一次握手，C端發(fā)了個連接請求消息到S端，S端收到后S端就知道自己與C端是可以連接成功的，但是C端此時并不知道S端是否接收到這個消息，所以S端接收到消息后得應答，C端得到S端的回復后，才能確定自己與S端是可以連接上的，這就是第二次握手。
C端只有確定了自己能與S端連接上才能開始發(fā)數(shù)據(jù)。所以兩次握手肯定是最基本的。
那么為什么需要第三次握手呢？假設(shè)一下如果沒有第三次握手，而是兩次握手后我們就認為連接建立，那么會發(fā)生什么？
第三次握手是為了防止已經(jīng)失效的連接請求報文段突然又傳到服務端，因而產(chǎn)生錯誤。
具體情況就是：
C端發(fā)出去的第一個網(wǎng)絡連接請求由于某些原因在網(wǎng)絡節(jié)點中滯留了，導致延遲，直到連接釋放的某個時間點才到達S端，這是一個早已失效的報文，但是此時S端仍然認為這是C端的建立連接請求第一次握手，于是S端回應了C端，第二次握手。
如果只有兩次握手，那么到這里，連接就建立了，但是此時C端并沒有任何數(shù)據(jù)要發(fā)送，而S端就會傻傻的等待著，造成很大的資源浪費。所以需要第三次握手，只有C端再次回應一下，就可以避免這種情況。
要想深刻理解TCP三次握手，請不要錯過以下文章：
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
5.2 四次揮手斷開連接
經(jīng)過上面的建立連接圖的解析，這個圖應該不難看懂。
這里主要有一個問題：為什么比建立連接時多了一次揮手？
可以看到這里服務端的ACK(回復客戶端)和FIN(終止)消息并不是同時發(fā)出的，而是先ACK，然后再FIN，這也很好理解，當客戶端要求斷開連接時，此時服務端可能還有未發(fā)送完的數(shù)據(jù)，所以先ACK，然后等數(shù)據(jù)發(fā)送完再FIN。這樣就變成了四次握手了。
上面講了TCP建立連接和斷開連接的過程，TCP最主要的特點就是提供可靠的傳輸，那么他是如何保證數(shù)據(jù)傳輸是可靠的呢，這就是下面要講的滑動窗口協(xié)議。
相關(guān)知識請深入閱讀：
《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
5.3 滑動窗口協(xié)議
滑動窗口協(xié)議是保證TCP的可靠傳輸?shù)母荆驗榘l(fā)送窗口只有收到確認幀才會向后移動窗口繼續(xù)發(fā)送其他幀。
下面舉個例子：假如發(fā)送窗口是3幀
一開始發(fā)送窗口在前3幀[1,2,3],則前3幀是可以發(fā)送的，后面的則暫時不可以發(fā)送，比如[1]幀發(fā)送出去后，收到了來自接收方的確認消息，則此時發(fā)送窗口才可以往后移1幀，發(fā)送窗口來到[2，3，4]，同樣只有發(fā)送窗口內(nèi)的幀才可以被發(fā)送，一次類推。
而接收窗口接收到幀后將其放入對應的位置，然后移動接收窗口，接口窗口與發(fā)送窗口一樣也有一個大小，如接收窗口是5幀，則落在接收窗口之外的幀會被丟棄。
發(fā)送窗口和接收窗口大小的不同設(shè)定就延伸出了不同的協(xié)議：
停止-等待協(xié)議：每發(fā)一幀都要等到確認消息才能發(fā)送下一幀，缺點:效率較差。
后退N幀協(xié)議：采取累計確認的方式，接收方正確的接受到N幀后發(fā)一個累計確認消息給發(fā)送窗口，確認N幀已正確收到，如果發(fā)送方規(guī)定時間內(nèi)未收到確認消息則認為超時或數(shù)據(jù)丟失，則會重新發(fā)送確認幀之后的所有幀。缺點:出錯序號后面的PDU已經(jīng)發(fā)送過了，但是還是要重新發(fā)送，比較浪費。
選擇重傳協(xié)議：若出現(xiàn)差錯，只重新傳輸出現(xiàn)差錯涉及需要的PDU,提高了傳輸效率，減少不必要的重傳。
到這里還剩下最后一個問題：由于發(fā)送窗口與接收窗口之間會存在發(fā)送效率和接收效率不匹配的問題，就會導致?lián)砣鉀Q這個問題TCP有一套流量控制和擁塞控制的機制。
5.4 流量控制和擁塞控制
1）流量控制：
流量控制是對一條通信路徑上的流量進行控制，就是發(fā)送方通過獲取接收方的回饋來動態(tài)調(diào)整發(fā)送的速率，來達到控制流量的效果，其目的是保證發(fā)送者的發(fā)送速度不超過接收者的接收速度。
2）擁塞控制：
擁塞控制是對整個通信子網(wǎng)的流量進行控制，屬于全局控制。
① 慢開始+擁塞避免
先來看一張經(jīng)典的圖：
一開始使用慢啟動，即擁塞窗口設(shè)為1，然后擁塞窗口指數(shù)增長到慢開始的門限值(ssthresh=16),則切換為擁塞避免,即加法增長，這樣增長到一定程度，導致網(wǎng)絡擁塞，則此時會把擁塞窗口重新降為1，即重新慢開始，同時調(diào)整新的慢開始門限值為12，之后以此類推。
② 快重傳+快恢復
快重傳：上面我們說的重傳機制都是等到超時還未收到接收方的回復，才開始進行重傳。而快重傳的設(shè)計思路是：如果發(fā)送方收到3個重復的接收方的ACK，就可以判斷有報文段丟失，此時就可以立即重傳丟失的報文段，而不用等到設(shè)置的超時時間到了才開始重傳，提高了重傳的效率。
快恢復：上面的擁塞控制會在網(wǎng)絡擁塞時將擁塞窗口降為1，重新慢開始，這樣存在的一個問題就是網(wǎng)絡無法很快恢復到正常狀態(tài)。快恢復就是來優(yōu)化這個問題的，使用快恢復，則出現(xiàn)擁塞時，擁塞窗口只會降低到新的慢開始門閥值（即12），而不會降為1，然后直接開始進入擁塞避免加法增長，如下圖所示：
快重傳和快恢復是對擁塞控制的進一步改進。
要更深入地理解本小節(jié)問題，請詳讀：《TCP/IP詳解 - 第21章·TCP的超時與重傳》、《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》。
6、有關(guān)Socket
Socket是一組操作TCP/UDP的API，像HttpURLConnection和Okhttp這種涉及到比較底層的網(wǎng)絡請求發(fā)送的，最終當然也都是通過Socket來進行網(wǎng)絡請求連接發(fā)送，而像Volley、Retrofit則是更上層的封裝，最后是依靠HttpURLConnection或者Okhttp來進行最終的連接建立和請求發(fā)送。
Socket的簡單使用的話應該都會，兩個端各建立一個Socket，服務端的叫ServerSocket，然后建立連接即可。
相關(guān)資料，請閱讀：
《網(wǎng)絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》
《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
7、本文小結(jié)
當然，以上這些內(nèi)容只是我自己知道的并且認為挺重要的計算機網(wǎng)絡基礎(chǔ)，還有非常多的網(wǎng)絡基礎(chǔ)知識需要去深入了解去探索。寫了很多，算是對自己網(wǎng)絡基礎(chǔ)的一個整理，可能也會有紕漏，權(quán)當拋磚引玉，還請各位大牛不吝賜教。
附錄：更多網(wǎng)絡基礎(chǔ)知識文章
《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)絡通訊協(xié)議關(guān)系圖（中文珍藏版）》
《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)絡編程(三)：關(guān)閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》
《網(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長連接》
《技術(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é)議的歷史演變和設(shè)計思路》
《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》
《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《以網(wǎng)游服務端的網(wǎng)絡接入層設(shè)計為例，理解實時通信的技術(shù)挑戰(zhàn)》
《邁向高階：優(yōu)秀Android程序員必知必會的網(wǎng)絡基礎(chǔ)》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1963-1-1.html）