1.網(wǎng)絡(luò)分層

OSI七層協(xié)議模型主要是：

1.應(yīng)用層（Application）
2.表示層（Presentation）
3.會話層（Session）
4.傳輸層（Transport）
5.網(wǎng)絡(luò)層（Network）
6.數(shù)據(jù)鏈路層（Data Link）
7.物理層（Physical）

2.TCP/IP五層模型

TCP/IP五層模型：
1.應(yīng)用層（Application）、
2.傳輸層（Transport）白胀、
3.網(wǎng)絡(luò)層（Network）嗦明、
4.數(shù)據(jù)鏈路層（Data Link）、
5.物理層（Physical）。

3.三次握手與四次揮手

第一次握手：
客戶端發(fā)送syn包(syn=j)到服務(wù)器闹击，并進(jìn)入SYN_SEND狀態(tài)返弹，等待服務(wù)器確認(rèn)；

第二次握手：
服務(wù)器收到syn包滤淳，必須確認(rèn)客戶的SYN（ack=j+1）梧喷，同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包脖咐，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)铺敌；

第三次握手：
客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)屁擅，此包發(fā)送完畢偿凭，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手派歌。

握手過程中傳送的包里不包含數(shù)據(jù)弯囊，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)胶果。
理想狀態(tài)下匾嘱，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連接之前稽物，TCP 連接都將被一直保持下去奄毡。

斷開連接時(shí)服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“四次握手”

第一次揮手：
客戶端發(fā)送報(bào)文告訴服務(wù)器沒有數(shù)據(jù)要發(fā)送了

第二次揮手：
服務(wù)端收到贝或，再發(fā)送給客戶端告訴它我收到了

第三次揮手：
服務(wù)端向客戶端發(fā)送報(bào)文吼过，請求關(guān)閉連接

第四次揮手：
客戶端收到關(guān)閉連接的請求，向服務(wù)端發(fā)送報(bào)文咪奖，服務(wù)端關(guān)閉連接

4.TCP為什么三次握手不是兩次握手盗忱，為什么兩次握手不安全

為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方羊赵， 都必須維護(hù)一個(gè)序列號趟佃， 以標(biāo)識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對方收到的昧捷。

三次握手的過程即是通信雙方相互告知序列號起始值闲昭， 并確認(rèn)對方已經(jīng)收到了序列號起始值的必經(jīng)步驟

如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號能被確認(rèn)靡挥， 另一方選擇的序列號則得不到確認(rèn)

5.為什么TCP是可靠的序矩，UDP早不可靠的?為什么UDP比TCP快?

TCP/IP協(xié)議擁有三次握手雙向機(jī)制，這一機(jī)制保證校驗(yàn)了數(shù)據(jù)跋破，保證了他的可靠性簸淀。
UDP就沒有了瓶蝴，udp信息發(fā)出后,不驗(yàn)證是否到達(dá)對方,所以不可靠。

6.http協(xié)議

http協(xié)議是一個(gè)基于請求與響應(yīng)模式的無連接租幕，無狀態(tài)舷手，應(yīng)用層的協(xié)議，支持c/s模式劲绪，簡單快速男窟，靈活

簡單快速：協(xié)議簡單，通信速度快
靈活：允許傳輸任意類型的數(shù)據(jù)對象珠叔，由Content-Type標(biāo)記
無連接：每次處理一個(gè)請求蝎宇，處理完成后既斷開
無狀態(tài)：對事務(wù)處理沒有記憶能力
http有兩種報(bào)文：請求報(bào)文和響應(yīng)報(bào)文
請求報(bào)文由請求行，請求報(bào)頭祷安，和請求數(shù)據(jù)組成
請求行：抓包第一行，包括請求方法兔乞，url和http版本
請求報(bào)頭：指的就是題目中“里面的協(xié)議頭部”
請求數(shù)據(jù)：指post方式提交的表單數(shù)據(jù)
響應(yīng)報(bào)文由狀態(tài)行汇鞭，響應(yīng)報(bào)頭，響應(yīng)正文組成
狀態(tài)行：狀態(tài)碼
響應(yīng)報(bào)頭：同請求報(bào)頭
響應(yīng)正文：服務(wù)器返回的資源數(shù)據(jù)
接下來是http頭部庸追，既請求報(bào)頭和響應(yīng)報(bào)頭霍骄，統(tǒng)稱消息報(bào)頭，消息報(bào)頭可以分為通用報(bào)頭淡溯，請求報(bào)頭读整，響應(yīng)報(bào)頭，實(shí)體報(bào)頭等
通用報(bào)頭和實(shí)體報(bào)頭既可以出現(xiàn)在請求報(bào)頭中咱娶，也可以出現(xiàn)在響應(yīng)報(bào)頭中米间，通用報(bào)頭包含的字段如：Date Connection Cache-Control,實(shí)體報(bào)頭中有Content-Type Content-Length Content-Language Content-Encoding.
請求報(bào)頭中包含的字段有：
Host,User-Agent,Accept-Encoding,Accept-Language,Connection
響應(yīng)報(bào)頭包含的字段：
Location，Server

7.http的get和post的區(qū)別

http是應(yīng)用層的協(xié)議膘侮，底層基于TCP/IP協(xié)議屈糊，所以本質(zhì)上，get和post請求都是TCP請求琼了。所以二者的區(qū)別都是體現(xiàn)在應(yīng)用層上（HTTP的規(guī)定和瀏覽器/服務(wù)器的限制）

1.參數(shù)的傳輸方式：GET參數(shù)通過URL傳遞逻锐，POST放在Request body中。
2.GET請求在URL中傳送的參數(shù)是有長度限制的雕薪，而POST沒有昧诱。
3.對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去所袁，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）盏档；而對于POST，瀏覽器先發(fā)送header纲熏，服務(wù)器響應(yīng)100 continue妆丘，瀏覽器再發(fā)送data锄俄，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。不過要注意勺拣，并不是所有瀏覽器都會在POST中發(fā)送兩次包奶赠，比如火狐
4.對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符药有，而POST沒有限制毅戈。
5.GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上愤惰，所以不能用來傳遞敏感信息苇经。
6.GET請求只能進(jìn)行url編碼，而POST支持多種編碼方式宦言。
7.GET在瀏覽器回退時(shí)是無害的扇单，而POST會再次提交請求。
8.GET產(chǎn)生的URL地址可以被Bookmark奠旺，而POST不可以蜘澜。
9.GET請求會被瀏覽器主動cache，而POST不會响疚，除非手動設(shè)置鄙信。

8.socket和http的區(qū)別：

Http連接：
http連接就是所謂的短連接，及客戶端向服務(wù)器發(fā)送一次請求忿晕，服務(wù)器端相應(yīng)后連接即會斷掉装诡。

socket連接：
socket連接及時(shí)所謂的長連接，理論上客戶端和服務(wù)端一旦建立連接践盼，則不會主動斷掉鸦采；但是由于各種環(huán)境因素可能會是連接斷開，比如說：服務(wù)器端或客戶端主機(jī)down了宏侍，網(wǎng)絡(luò)故障赖淤，或者兩者之間長時(shí)間沒有數(shù)據(jù)傳輸，網(wǎng)絡(luò)防火墻可能會斷開該鏈接已釋放網(wǎng)絡(luò)資源谅河。所以當(dāng)一個(gè)socket連接中沒有數(shù)據(jù)的傳輸咱旱，那么為了位置連續(xù)的連接需要發(fā)送心跳消息，具體心跳消息格式是開發(fā)者自己定義的绷耍。

9.TCP與UDP區(qū)別總結(jié)

1吐限、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2褂始、TCP提供可靠的服務(wù)诸典。也就是說，通過TCP連接傳送的數(shù)據(jù)崎苗，無差錯狐粱，不丟失舀寓，不重復(fù)，且按序到達(dá);UDP盡最大努力交付肌蜻，即不保 證可靠交付
3互墓、TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的
UDP沒有擁塞控制蒋搜，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時(shí)應(yīng)用很有用篡撵，如IP電話，實(shí)時(shí)視頻會議等）
4豆挽、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對一育谬，一對多，多對一和多對多的交互通信
5帮哈、TCP首部開銷20字節(jié);UDP的首部開銷小膛檀，只有8個(gè)字節(jié)
6、TCP的邏輯通信信道是全雙工的可靠信道娘侍，UDP則是不可靠信道

10.https

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)宿刮，是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版私蕾。HTTP是應(yīng)用層協(xié)議，位于HTTP協(xié)議之下是傳輸協(xié)議TCP胡桃。TCP負(fù)責(zé)傳輸踩叭，HTTP則定義了數(shù)據(jù)如何進(jìn)行包裝，在HTTP跟TCP中間加多了一層加密層TLS/SSL翠胰，SSL是個(gè)加密套件容贝，負(fù)責(zé)對HTTP的數(shù)據(jù)進(jìn)行加密。TLS是SSL的升級版≈埃現(xiàn)在提到HTTPS斤富，加密套件基本指的是TLS。
傳輸加密的流程：http是應(yīng)用層將數(shù)據(jù)直接給到TCP進(jìn)行傳輸锻狗，https是應(yīng)用層將數(shù)據(jù)給到TLS/SSL满力，將數(shù)據(jù)加密后，再給到TCP進(jìn)行傳輸轻纪。
HTTPS是如何加密數(shù)據(jù)的：
一般來說油额，加密分為對稱加密、非對稱加密

1. 對稱加密

對稱加密的意思就是刻帚，加密數(shù)據(jù)用的密鑰潦嘶，跟解密數(shù)據(jù)用的密鑰是一樣的。
對稱加密的優(yōu)點(diǎn)在于加密崇众、解密效率通常比較高掂僵。缺點(diǎn)在于航厚，數(shù)據(jù)發(fā)送方、數(shù)據(jù)接收方需要協(xié)商锰蓬、共享同一把密鑰幔睬，并確保密鑰不泄露給其他人。傳輸過程中容易被截獲互妓。
網(wǎng)上一個(gè)很形象的例子：假如現(xiàn)在小客與小服要進(jìn)行一次私密的對話溪窒，他們不希望這次對話內(nèi)容被其他外人知道》朊悖可是澈蚌，我們平時(shí)的數(shù)據(jù)傳輸過程中又是明文傳輸?shù)模f一被某個(gè)黑客把他們的對話內(nèi)容給竊取了灼狰，那就難受了宛瞄。為了解決這個(gè)問題，小服這家伙想到了一個(gè)方法來加密數(shù)據(jù)交胚，讓黑客看不到具體的內(nèi)容份汗。該方法是這樣子的：在每次數(shù)據(jù)傳輸之前，小服會先傳輸小客一把密鑰蝴簇，然后小服在之后給小客發(fā)消息的過程中杯活，會用這把密鑰對這些消息進(jìn)行加密。小客在收到這些消息后熬词，會用之前小服給的那把密鑰對這些消息進(jìn)行解密旁钧，這樣，小客就能得到密文里面真正的數(shù)據(jù)了互拾。如果小客要給小服發(fā)消息歪今，也同樣用這把密鑰來對消息進(jìn)行加密，小服收到后也用這把密鑰進(jìn)行解密颜矿。 這樣寄猩，就保證了數(shù)據(jù)傳輸?shù)陌踩浴?/p>

2.非對稱加密

非對稱加密的意思就是，加密數(shù)據(jù)用的密鑰（公鑰）骑疆，跟解密數(shù)據(jù)用的密鑰（私鑰）是不一樣的田篇。
網(wǎng)上一個(gè)很形象的例子：小服還是挺聰明的，得意了一會之后封断，小服意識到了密鑰會被截取這個(gè)問題斯辰。倔強(qiáng)的小服又想到了另外一種方法：用非對稱加密的方法來加密數(shù)據(jù)。該方法是這樣的：小服和小客都擁有兩把鑰匙坡疼，一把鑰匙的公開的（全世界都知道也沒關(guān)系）彬呻，稱之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道），稱之為私鑰闸氮。并且剪况，用公鑰加密的數(shù)據(jù)，只有對應(yīng)的私鑰才能解密蒲跨；用私鑰加密的數(shù)據(jù)译断，只有對應(yīng)的公鑰才能解密。所以在傳輸數(shù)據(jù)的過程中或悲，小服在給小客傳輸數(shù)據(jù)的過程中孙咪，會用小客給他的公鑰進(jìn)行加密，然后小客收到后巡语，再用自己的私鑰進(jìn)行解密翎蹈。小客給小服發(fā)消息的時(shí)候，也一樣會用小服給他的公鑰進(jìn)行加密男公，然后小服再用自己的私鑰進(jìn)行解密荤堪。 這樣，數(shù)據(jù)就能安全著到達(dá)雙方枢赔。是什么原因?qū)е路菍ΨQ加密這種方法的不安全性呢澄阳？它和對稱加密方法的不安全性不同。非對稱加密之所以不安全踏拜，是因?yàn)樾】褪盏搅斯€之后碎赢，無法確定這把公鑰是否真的是小服。
解決的辦法就是數(shù)字證書：小服再給小客發(fā)公鑰的過程中速梗，會把公鑰以及小服的個(gè)人信息通過Hash算法生成消息摘要揩抡，為了防止摘要被人調(diào)換，小服還會用CA提供的私鑰對消息摘要進(jìn)行加密來形成數(shù)字簽名镀琉，當(dāng)小客拿到這份數(shù)字證書之后，就會用CA提供的公鑰來對數(shù)字證書里面的數(shù)字簽名進(jìn)行解密得到消息摘要蕊唐，然后對數(shù)字證書里面小服的公鑰和個(gè)人信息進(jìn)行Hash得到另一份消息摘要屋摔，然后把兩份消息摘要進(jìn)行對比，如果一樣替梨，則證明這些東西確實(shí)是小服的钓试，否則就不是。

11.加密算法

1.對稱加密算法
Data Encryption Standard(DES)
DES 是一種典型的塊加密方法：將固定長度的明文通過一系列復(fù)雜的操作變成同樣長度的密文副瀑，塊的長度為64位弓熏。同時(shí)，DES 使用的密鑰來自定義變換過程糠睡，因此算法認(rèn)為只有持有加密所用的密鑰的用戶才能解密密文挽鞠。 DES 的密鑰表面上是64位的，實(shí)際有效密鑰長度為56位，其余8位可以用于奇偶校驗(yàn)信认。
DES 現(xiàn)在已經(jīng)不被視為一種安全的加密算法材义，主要原因是它使用的56位密鑰過短。
為了提供實(shí)用所需的安全性嫁赏，可以使用 DES 的派生算法 3DES 來進(jìn)行加密 (雖然3DES 也存在理論上的攻擊方法)其掂。
Advanced Encryption Standard(AES)
AES 在密碼學(xué)中又稱 Rijndael 加密法，用來替代原先的 DES潦蝇，已經(jīng)被多方分析且廣泛使用款熬。
DES與AES的比較
自DES 算法公諸于世以來，學(xué)術(shù)界圍繞它的安全性等方面進(jìn)行了研究并展開了激烈的爭論攘乒。在技術(shù)上贤牛，對DES的批評主要集中在以下幾個(gè)方面：
1、作為分組密碼持灰，DES 的加密單位僅有64 位二進(jìn)制盔夜，這對于數(shù)據(jù)傳輸來說太小，因?yàn)槊總€(gè)分組僅含8 個(gè)字符堤魁，而且其中某些位還要用于奇偶校驗(yàn)或其他通訊開銷喂链。
2、DES 的密鑰的位數(shù)太短妥泉，只有56 比特椭微，而且各次迭代中使用的密鑰是遞推產(chǎn)生的，這種相關(guān)必然降低密碼體制的安全性盲链，在現(xiàn)有技術(shù)下用窮舉法尋找密鑰已趨于可行蝇率。
3、DES 不能對抗差分和線性密碼分析刽沾。
4本慕、DES 用戶實(shí)際使用的密鑰長度為56bit，理論上最大加密強(qiáng)度為256侧漓。DES 算法要提高加密強(qiáng)度（例如增加密鑰長度）锅尘，則系統(tǒng)開銷呈指數(shù)增長。除采用提高硬件功能和增加并行處理功能外布蔗，從算法本身和軟件技術(shù)方面都無法提高DES 算法的加密強(qiáng)度藤违。

2. 非對稱加密算法
   RSA
   1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出纵揍，以他們?nèi)诵帐祥_頭字母命名顿乒，是一種獲得廣泛使用的非對稱加密算法。
   對極大整數(shù)做因數(shù)分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性泽谨。換言之璧榄，對一個(gè)極大整數(shù)做因數(shù)分解愈困難特漩，RSA 算法就愈可靠。假如有人找到一種快速因數(shù)分解的算法的話犹菱，那么用 RSA 加密的信息的可靠性就肯定會極度下降拾稳。目前看來找到這樣的算法的可能性非常小。
   DES與RSA的比較
   RSA算法的密鑰很長腊脱，具有較好的安全性访得，但加密的計(jì)算量很大，加密速度較慢限制了其應(yīng)用范圍陕凹。為減少計(jì)算量悍抑，在傳送信息時(shí)，常采用傳統(tǒng)加密方法與公開密鑰加密方法相結(jié)合的方式杜耙，即信息采用改進(jìn)的DES對話密鑰加密搜骡，然后使用RSA密鑰加密對話密鑰和信息摘要。對方收到信息后佑女，用不同的密鑰解密并可核對信息摘要记靡。
   采用DES與RSA相結(jié)合的應(yīng)用，使它們的優(yōu)缺點(diǎn)正好互補(bǔ)团驱，即DES加密速度快摸吠，適合加密較長的報(bào)文，可用其加密明文嚎花；RSA加密速度慢寸痢，安全性好，應(yīng)用于DES 密鑰的加密紊选，可解決DES 密鑰分配的問題啼止。
   目前這種RSA和DES結(jié)合的方法已成為EMAIL保密通信標(biāo)準(zhǔn)。

12.Volley

1兵罢、Volley的特點(diǎn)
Volley是谷歌大會上推出的網(wǎng)絡(luò)通信框架（2.3之前使用HttpClient献烦，之后使用HttpUrlConnection），它既可以訪問網(wǎng)絡(luò)獲取數(shù)據(jù)卖词，也可以加載圖片仿荆，并且在性能方面進(jìn)行了大幅度的調(diào)整，它的設(shè)計(jì)目的就是適合進(jìn)行數(shù)據(jù)量不大但通信頻繁的網(wǎng)絡(luò)操作坏平，而對于大數(shù)據(jù)量的操作，比如文件下載锦亦，表現(xiàn)很糟糕舶替，因?yàn)関olley處理http返回的默認(rèn)實(shí)現(xiàn)是BasicNetwork，它會把返回的流全部導(dǎo)入內(nèi)存中杠园，下載大文件會發(fā)生內(nèi)存溢出

2顾瞪、Volley執(zhí)行的過程：

默認(rèn)情況下，Volley中開啟四個(gè)網(wǎng)絡(luò)調(diào)度線程和一個(gè)緩存調(diào)度線程，首先請求會加入緩存隊(duì)列陈醒，惕橙，緩存調(diào)度線程從緩存隊(duì)列中取出線程，如果找到該請求的緩存就直接讀取該緩存并解析钉跷，然后回調(diào)給主線程弥鹦，如果沒有找到緩存的響應(yīng)，則將這個(gè)請求加入網(wǎng)絡(luò)隊(duì)列爷辙，然后網(wǎng)絡(luò)調(diào)度線程會輪詢?nèi)〕鼍W(wǎng)絡(luò)隊(duì)列中的請求彬坏，發(fā)起http請求，解析響應(yīng)并將響應(yīng)存入緩存膝晾，回調(diào)給主線程

3栓始、Volley為什么不適合下載上傳大文件？為什么適合數(shù)據(jù)量小的頻率高的請求？

1.volley基于請求隊(duì)列，Volley的網(wǎng)絡(luò)請求線程池默認(rèn)大小為4浪秘。意味著可以并發(fā)進(jìn)行4個(gè)請求豁延，大于4個(gè)，會排在隊(duì)列中量没。并發(fā)量小所以適合數(shù)據(jù)量下頻率高的請求
2.因?yàn)閂olley下載文件會將流存入內(nèi)存中（是一個(gè)小于4k的緩存池），大文件會導(dǎo)致內(nèi)存溢出，所以不能下載大文件领跛，不能上傳大文件的原因和1中差不多，設(shè)想你上傳了四個(gè)大文件撤奸，同時(shí)占用了volley的四個(gè)線程吠昭，導(dǎo)致其他網(wǎng)絡(luò)請求都阻塞在隊(duì)列中，造成反應(yīng)慢的現(xiàn)象

13.OKHttp

1胧瓜、OKHttp的特點(diǎn)
1.相較于Volley矢棚，它的最大并發(fā)量為64
2.使用連接池技術(shù)，支持5個(gè)并發(fā)的socket連接默認(rèn)keepAlive時(shí)間為5分鐘府喳，解決TCP握手和揮手的效率問題蒲肋，減少握手次數(shù)
3.支持Gzip壓縮，且操作對用戶透明钝满，可以通過header設(shè)置兜粘，在發(fā)起請求的時(shí)候自動加入header，Accept-Encoding: gzip弯蚜，而我們的服務(wù)器返回的時(shí)候header中有Content-Encoding: gzip
4.利用響應(yīng)緩存來避免重復(fù)的網(wǎng)絡(luò)請求
5.很方便的添加攔截器孔轴，通常情況下，攔截器用來添加碎捺，移除路鹰，轉(zhuǎn)換請求和響應(yīng)的頭部信息贷洲，比如添加公參等
6.請求失敗，自動重連晋柱，發(fā)生異常時(shí)重連优构，看源碼調(diào)用recover方法重連了一次
7.支持SPDY協(xié)議(SPDY是Google開發(fā)的基于TCP的應(yīng)用層協(xié)議，用以最小化網(wǎng)絡(luò)延遲雁竞，提升網(wǎng)絡(luò)速度钦椭，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)。SPDY并不是一種用于替代HTTP的協(xié)議浓领，而是對HTTP協(xié)議的增強(qiáng)玉凯。新協(xié)議的功能包括數(shù)據(jù)流的多路復(fù)用、請求優(yōu)先級以及HTTP報(bào)頭壓縮联贩。谷歌表示漫仆，引入SPDY協(xié)議后，在實(shí)驗(yàn)室測試中頁面加載速度比原先快64%)
8.使用Okio來簡化數(shù)據(jù)的訪問與存儲泪幌，提高性能

2盲厌、 OkHttp的缺點(diǎn)
1.消息回來需要切到主線程，主線程要自己去寫祸泪。
2.調(diào)用比較復(fù)雜吗浩，需要自己進(jìn)行封裝。
3.緩存失效：網(wǎng)絡(luò)請求時(shí)一般都會獲取手機(jī)的一些硬件或網(wǎng)絡(luò)信息没隘，比如使用的網(wǎng)絡(luò)環(huán)境懂扼。同時(shí)為了信息傳輸?shù)陌踩裕赡苓€會對請求進(jìn)行加密右蒲。在這些情況下OkHttp的緩存系統(tǒng)就會失效了阀湿，導(dǎo)致用戶在無網(wǎng)絡(luò)情況下不能訪問緩存。

3瑰妄、 OkHttp框架中都用到了哪些設(shè)計(jì)模式
1.最明顯的Builder設(shè)計(jì)模式陷嘴，如構(gòu)建對象OkHttpClient，還有單利模式
2.工廠方法模式间坐，如源碼中的接口Call
3.觀察者模式如EventListener灾挨，監(jiān)聽請求和響應(yīng)
4.策略模式
5.責(zé)任鏈模式，如攔截器

14.Retrofit

Retrofit底層是基于OkHttp實(shí)現(xiàn)的竹宋，與其他網(wǎng)絡(luò)框架不同的是劳澄，它更多使用運(yùn)行時(shí)注解的方式提供功能

1、原理
通過java接口以及注解來描述網(wǎng)絡(luò)請求蜈七，并用動態(tài)代理的方式生成網(wǎng)絡(luò)請求的request秒拔，然后通過client調(diào)用相應(yīng)的網(wǎng)絡(luò)框架（默認(rèn)okhttp）去發(fā)起網(wǎng)絡(luò)請求，并將返回的response通過converterFactorty轉(zhuǎn)換成相應(yīng)的數(shù)據(jù)model宪潮，最后通過calladapter轉(zhuǎn)換成其他數(shù)據(jù)方式（如rxjava Observable）

2溯警、Retrofit流程
（1）通過解析 網(wǎng)絡(luò)請求接口的注解 配置 網(wǎng)絡(luò)請求參數(shù)
（2）通過 動態(tài)代理 生成 網(wǎng)絡(luò)請求對象
（3）通過 網(wǎng)絡(luò)請求適配器 將 網(wǎng)絡(luò)請求對象 進(jìn)行平臺適配
（4）通過 網(wǎng)絡(luò)請求執(zhí)行器 發(fā)送網(wǎng)絡(luò)請求
（5）通過 數(shù)據(jù)轉(zhuǎn)換器 解析服務(wù)器返回的數(shù)據(jù)
（6）通過 回調(diào)執(zhí)行器 切換線程（子線程 ->>主線程）
（7）用戶在主線程處理返回結(jié)果

3、 Retrofit優(yōu)點(diǎn)
1.可以配置不同HTTP client來實(shí)現(xiàn)網(wǎng)絡(luò)請求狡相，如okhttp梯轻、httpclient等；
2.請求的方法參數(shù)注解都可以定制尽棕；
3.支持同步喳挑、異步和RxJava；
4.超級解耦滔悉；
5.可以配置不同的反序列化工具來解析數(shù)據(jù)伊诵，如json、xml等
6.框架使用了很多設(shè)計(jì)模式