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

• OSI七層模型
  OSI七層協(xié)議模型主要是：應(yīng)用層（Application）憔鬼、表示層（Presentation）龟劲、會(huì)話層（Session）、傳輸層（Transport）轴或、網(wǎng)絡(luò)層（NetWork）昌跌、數(shù)據(jù)鏈路層（DataLink）、物理層（Physical）照雁。

2蚕愤、TCP/IP五層模型

TCP/IP五層模型：應(yīng)用層（Application）、傳輸層（Transport）饺蚊、網(wǎng)絡(luò)層（Network）萍诱、數(shù)據(jù)鏈路層（Data Link）、物理層（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)得问，完成三次握手囤攀。

握手過(guò)程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后宫纬，客戶端與服務(wù)器才正式開(kāi)始傳送數(shù)據(jù)焚挠。理想狀態(tài)下，TCP連接一旦建立漓骚，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前蝌衔，TCP 連接都將被一直保持下去。斷開(kāi)連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開(kāi)TCP連接的請(qǐng)求蝌蹂，斷開(kāi)過(guò)程需要經(jīng)過(guò)“四次握手”

第一次揮手：客戶端發(fā)送報(bào)文告訴服務(wù)器沒(méi)有數(shù)據(jù)要發(fā)送了
第二次揮手：服務(wù)端收到噩斟，再發(fā)送給客戶端告訴它我收到了
第三次揮手：服務(wù)端向客戶端發(fā)送報(bào)文，請(qǐng)求關(guān)閉連接
第四次揮手：客戶端收到關(guān)閉連接的請(qǐng)求孤个，向服務(wù)端發(fā)送報(bào)文剃允，服務(wù)端關(guān)閉連接

4、TCP為什么三次握手不是兩次握手齐鲤，為什么兩次握手不安全

為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸斥废， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個(gè)序列號(hào)给郊， 以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中营袜， 哪些是已經(jīng)被對(duì)方收到的。 三次握手的過(guò)程即是通信雙方相互告知序列號(hào)起始值丑罪， 并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值的必經(jīng)步驟
如果只是兩次握手荚板， 至多只有連接發(fā)起方的起始序列號(hào)能被確認(rèn)， 另一方選擇的序列號(hào)則得不到確認(rèn)

5吩屹、為什么TCP是可靠的跪另，UDP早不可靠的?為什么UDP比TCP快?

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

6嘲驾、http協(xié)議

http協(xié)議是一個(gè)基于請(qǐng)求與響應(yīng)模式的無(wú)連接，無(wú)狀態(tài)迹卢，應(yīng)用層的協(xié)議辽故，支持c/s模式，簡(jiǎn)單快速腐碱，靈活
簡(jiǎn)單快速：協(xié)議簡(jiǎn)單誊垢，通信速度快
靈活：允許傳輸任意類型的數(shù)據(jù)對(duì)象，由Content-Type標(biāo)記
無(wú)連接：每次處理一個(gè)請(qǐng)求，處理完成后既斷開(kāi)
無(wú)狀態(tài)：對(duì)事務(wù)處理沒(méi)有記憶能力
http有兩種報(bào)文：請(qǐng)求報(bào)文和響應(yīng)報(bào)文
請(qǐng)求報(bào)文由請(qǐng)求行喂走，請(qǐng)求報(bào)頭殃饿，和請(qǐng)求數(shù)據(jù)組成
請(qǐng)求行：抓包第一行，包括請(qǐng)求方法芋肠，url和http版本
請(qǐng)求報(bào)頭：指的就是題目中“里面的協(xié)議頭部”
請(qǐng)求數(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)頭：同請(qǐng)求報(bào)頭
響應(yīng)正文：服務(wù)器返回的資源數(shù)據(jù)
接下來(lái)是http頭部帖池，既請(qǐng)求報(bào)頭和響應(yīng)報(bào)頭秒咐，統(tǒng)稱消息報(bào)頭，消息報(bào)頭可以分為通用報(bào)頭碘裕，請(qǐng)求報(bào)頭，響應(yīng)報(bào)頭攒钳，實(shí)體報(bào)頭等
通用報(bào)頭和實(shí)體報(bào)頭既可以出現(xiàn)在請(qǐng)求報(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.
請(qǐng)求報(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請(qǐng)求都是TCP請(qǐng)求。所以二者的區(qū)別都是體現(xiàn)在應(yīng)用層上（HTTP的規(guī)定和瀏覽器/服務(wù)器的限制）
1.參數(shù)的傳輸方式：GET參數(shù)通過(guò)URL傳遞实愚，POST放在Request body中兼呵。
2.GET請(qǐng)求在URL中傳送的參數(shù)是有長(zhǎng)度限制的，而POST沒(méi)有腊敲。
3.對(duì)于GET方式的請(qǐng)求击喂，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）碰辅；而對(duì)于POST懂昂，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue没宾，瀏覽器再發(fā)送data凌彬，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。不過(guò)要注意循衰，并不是所有瀏覽器都會(huì)在POST中發(fā)送兩次包铲敛，比如火狐
4.對(duì)參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符会钝，而POST沒(méi)有限制原探。
5.GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上，所以不能用來(lái)傳遞敏感信息咽弦。
6.GET請(qǐng)求只能進(jìn)行url編碼徒蟆，而POST支持多種編碼方式。
7.GET在瀏覽器回退時(shí)是無(wú)害的型型，而POST會(huì)再次提交請(qǐng)求段审。
8.GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以闹蒜。
9.GET請(qǐng)求會(huì)被瀏覽器主動(dòng)cache寺枉，而POST不會(huì)，除非手動(dòng)設(shè)置绷落。

8姥闪、socket和http的區(qū)別：

Http協(xié)議：簡(jiǎn)單的對(duì)象訪問(wèn)協(xié)議，對(duì)應(yīng)于應(yīng)用層砌烁。Http協(xié)議是基于TCP鏈接的筐喳。
tcp協(xié)議：對(duì)應(yīng)于傳輸層
ip協(xié)議：對(duì)應(yīng)與網(wǎng)絡(luò)層
TCP/IP是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸函喉；而Http是應(yīng)用層協(xié)議避归，主要解決如何包裝數(shù)據(jù)。
Socket是對(duì)TCP/IP協(xié)議的封裝管呵，Socket本身并不是協(xié)議梳毙，而是一個(gè)調(diào)用接口（API），通過(guò)Socket捐下，我們才能使用TCP/IP協(xié)議账锹。
Http連接：http連接就是所謂的短連接，及客戶端向服務(wù)器發(fā)送一次請(qǐng)求坷襟，服務(wù)器端相應(yīng)后連接即會(huì)斷掉牌废。
socket連接：socket連接及時(shí)所謂的長(zhǎng)連接，理論上客戶端和服務(wù)端一旦建立連接啤握，則不會(huì)主動(dòng)斷掉鸟缕；但是由于各種環(huán)境因素可能會(huì)是連接斷開(kāi)，比如說(shuō)：服務(wù)器端或客戶端主機(jī)down了排抬，網(wǎng)絡(luò)故障懂从，或者兩者之間長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)傳輸，網(wǎng)絡(luò)防火墻可能會(huì)斷開(kāi)該鏈接已釋放網(wǎng)絡(luò)資源蹲蒲。所以當(dāng)一個(gè)socket連接中沒(méi)有數(shù)據(jù)的傳輸番甩，那么為了位置連續(xù)的連接需要發(fā)送心跳消息，具體心跳消息格式是開(kāi)發(fā)者自己定義的届搁。

9缘薛、TCP與UDP區(qū)別總結(jié)：

1窍育、TCP面向連接（如打電話要先撥號(hào)建立連接）;UDP是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2宴胧、TCP提供可靠的服務(wù)漱抓。也就是說(shuō)，通過(guò)TCP連接傳送的數(shù)據(jù)恕齐，無(wú)差錯(cuò)乞娄，不丟失，不重復(fù)显歧，且按序到達(dá);UDP盡最大努力交付仪或，即不保 證可靠交付
3、TCP面向字節(jié)流士骤，實(shí)際上是TCP把數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的
UDP沒(méi)有擁塞控制范删，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低（對(duì)實(shí)時(shí)應(yīng)用很有用，如IP電話拷肌，實(shí)時(shí)視頻會(huì)議等）
4到旦、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多廓块，多對(duì)一和多對(duì)多的交互通信
5、TCP首部開(kāi)銷(xiāo)20字節(jié);UDP的首部開(kāi)銷(xiāo)小契沫，只有8個(gè)字節(jié)
6带猴、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道

10懈万、https

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)拴清，是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是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é)對(duì)HTTP的數(shù)據(jù)進(jìn)行加密木张。TLS是SSL的升級(jí)版。現(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ù)的：
一般來(lái)說(shuō)，加密分為對(duì)稱加密育拨、非對(duì)稱加密

1. 對(duì)稱加密：
   對(duì)稱加密的意思就是谨履，加密數(shù)據(jù)用的密鑰，跟解密數(shù)據(jù)用的密鑰是一樣的至朗。
   對(duì)稱加密的優(yōu)點(diǎn)在于加密屉符、解密效率通常比較高。缺點(diǎn)在于锹引，數(shù)據(jù)發(fā)送方矗钟、數(shù)據(jù)接收方需要協(xié)商、共享同一把密鑰嫌变，并確保密鑰不泄露給其他人吨艇。傳輸過(guò)程中容易被截獲。
   網(wǎng)上一個(gè)很形象的例子：假如現(xiàn)在小客與小服要進(jìn)行一次私密的對(duì)話腾啥，他們不希望這次對(duì)話內(nèi)容被其他外人知道东涡。可是倘待，我們平時(shí)的數(shù)據(jù)傳輸過(guò)程中又是明文傳輸?shù)拇埽f(wàn)一被某個(gè)黑客把他們的對(duì)話內(nèi)容給竊取了，那就難受了凸舵。為了解決這個(gè)問(wèn)題祖娘，小服這家伙想到了一個(gè)方法來(lái)加密數(shù)據(jù)，讓黑客看不到具體的內(nèi)容啊奄。該方法是這樣子的：在每次數(shù)據(jù)傳輸之前渐苏，小服會(huì)先傳輸小客一把密鑰，然后小服在之后給小客發(fā)消息的過(guò)程中菇夸，會(huì)用這把密鑰對(duì)這些消息進(jìn)行加密琼富。小客在收到這些消息后，會(huì)用之前小服給的那把密鑰對(duì)這些消息進(jìn)行解密庄新，這樣鞠眉，小客就能得到密文里面真正的數(shù)據(jù)了。如果小客要給小服發(fā)消息择诈，也同樣用這把密鑰來(lái)對(duì)消息進(jìn)行加密凡蚜，小服收到后也用這把密鑰進(jìn)行解密。 這樣吭从，就保證了數(shù)據(jù)傳輸?shù)陌踩浴?br> 2.非對(duì)稱加密
   非對(duì)稱加密的意思就是朝蜘，加密數(shù)據(jù)用的密鑰（公鑰），跟解密數(shù)據(jù)用的密鑰（私鑰）是不一樣的涩金。
   網(wǎng)上一個(gè)很形象的例子：小服還是挺聰明的谱醇，得意了一會(huì)之后暇仲，小服意識(shí)到了密鑰會(huì)被截取這個(gè)問(wèn)題。倔強(qiáng)的小服又想到了另外一種方法：用非對(duì)稱加密的方法來(lái)加密數(shù)據(jù)副渴。該方法是這樣的：小服和小客都擁有兩把鑰匙奈附，一把鑰匙的公開(kāi)的（全世界都知道也沒(méi)關(guān)系），稱之為公鑰煮剧；而另一把鑰匙是保密（也就是只有自己才知道）斥滤，稱之為私鑰。并且勉盅，用公鑰加密的數(shù)據(jù)佑颇，只有對(duì)應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)草娜，只有對(duì)應(yīng)的公鑰才能解密挑胸。所以在傳輸數(shù)據(jù)的過(guò)程中，小服在給小客傳輸數(shù)據(jù)的過(guò)程中宰闰，會(huì)用小客給他的公鑰進(jìn)行加密茬贵，然后小客收到后馋劈，再用自己的私鑰進(jìn)行解密携丁。小客給小服發(fā)消息的時(shí)候沮协，也一樣會(huì)用小服給他的公鑰進(jìn)行加密瘟则，然后小服再用自己的私鑰進(jìn)行解密。 這樣尘盼，數(shù)據(jù)就能安全著到達(dá)雙方荆秦。是什么原因?qū)е路菍?duì)稱加密這種方法的不安全性呢背捌？它和對(duì)稱加密方法的不安全性不同戳粒。非對(duì)稱加密之所以不安全路狮，是因?yàn)樾】褪盏搅斯€之后虫啥，無(wú)法確定這把公鑰是否真的是小服蔚约。
   解決的辦法就是數(shù)字證書(shū)：小服再給小客發(fā)公鑰的過(guò)程中，會(huì)把公鑰以及小服的個(gè)人信息通過(guò)Hash算法生成消息摘要涂籽，為了防止摘要被人調(diào)換苹祟，小服還會(huì)用CA提供的私鑰對(duì)消息摘要進(jìn)行加密來(lái)形成數(shù)字簽名，當(dāng)小客拿到這份數(shù)字證書(shū)之后评雌，就會(huì)用CA提供的公鑰來(lái)對(duì)數(shù)字證書(shū)里面的數(shù)字簽名進(jìn)行解密得到消息摘要树枫，然后對(duì)數(shù)字證書(shū)里面小服的公鑰和個(gè)人信息進(jìn)行Hash得到另一份消息摘要，然后把兩份消息摘要進(jìn)行對(duì)比景东，如果一樣砂轻，則證明這些東西確實(shí)是小服的，否則就不是斤吐。

11搔涝、加密算法

1.對(duì)稱加密算法
Data Encryption Standard(DES)
DES 是一種典型的塊加密方法：將固定長(zhǎng)度的明文通過(guò)一系列復(fù)雜的操作變成同樣長(zhǎng)度的密文厨喂，塊的長(zhǎng)度為64位。同時(shí)庄呈，DES 使用的密鑰來(lái)自定義變換過(guò)程蜕煌，因此算法認(rèn)為只有持有加密所用的密鑰的用戶才能解密密文。 DES 的密鑰表面上是64位的诬留，實(shí)際有效密鑰長(zhǎng)度為56位斜纪，其余8位可以用于奇偶校驗(yàn)。
DES 現(xiàn)在已經(jīng)不被視為一種安全的加密算法文兑，主要原因是它使用的56位密鑰過(guò)短盒刚。
為了提供實(shí)用所需的安全性，可以使用 DES 的派生算法 3DES 來(lái)進(jìn)行加密 (雖然3DES 也存在理論上的攻擊方法)彩届。
Advanced Encryption Standard(AES)
AES 在密碼學(xué)中又稱 Rijndael 加密法伪冰，用來(lái)替代原先的 DES，已經(jīng)被多方分析且廣泛使用樟蠕。
DES與AES的比較
自DES 算法公諸于世以來(lái)贮聂，學(xué)術(shù)界圍繞它的安全性等方面進(jìn)行了研究并展開(kāi)了激烈的爭(zhēng)論。在技術(shù)上寨辩，對(duì)DES的批評(píng)主要集中在以下幾個(gè)方面：
1吓懈、作為分組密碼，DES 的加密單位僅有64 位二進(jìn)制靡狞，這對(duì)于數(shù)據(jù)傳輸來(lái)說(shuō)太小耻警，因?yàn)槊總€(gè)分組僅含8 個(gè)字符，而且其中某些位還要用于奇偶校驗(yàn)或其他通訊開(kāi)銷(xiāo)甸怕。
2甘穿、DES 的密鑰的位數(shù)太短，只有56 比特梢杭，而且各次迭代中使用的密鑰是遞推產(chǎn)生的温兼，這種相關(guān)必然降低密碼體制的安全性，在現(xiàn)有技術(shù)下用窮舉法尋找密鑰已趨于可行武契。
3募判、DES 不能對(duì)抗差分和線性密碼分析。
4咒唆、DES 用戶實(shí)際使用的密鑰長(zhǎng)度為56bit届垫，理論上最大加密強(qiáng)度為256。DES 算法要提高加密強(qiáng)度（例如增加密鑰長(zhǎng)度）全释，則系統(tǒng)開(kāi)銷(xiāo)呈指數(shù)增長(zhǎng)装处。除采用提高硬件功能和增加并行處理功能外，從算法本身和軟件技術(shù)方面都無(wú)法提高DES 算法的加密強(qiáng)度浸船。

2. 非對(duì)稱加密算法
   RSA
   1977年由 MIT 的 Ron Rivest妄迁、Adi Shamir 和 Leonard Adleman 一起提出找前，以他們?nèi)诵帐祥_(kāi)頭字母命名，是一種獲得廣泛使用的非對(duì)稱加密算法判族。
   對(duì)極大整數(shù)做因數(shù)分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性躺盛。換言之，對(duì)一個(gè)極大整數(shù)做因數(shù)分解愈困難形帮，RSA 算法就愈可靠槽惫。假如有人找到一種快速因數(shù)分解的算法的話，那么用 RSA 加密的信息的可靠性就肯定會(huì)極度下降辩撑。目前看來(lái)找到這樣的算法的可能性非常小界斜。
   DES與RSA的比較
   RSA算法的密鑰很長(zhǎng)，具有較好的安全性合冀，但加密的計(jì)算量很大各薇，加密速度較慢限制了其應(yīng)用范圍。為減少計(jì)算量君躺，在傳送信息時(shí)峭判，常采用傳統(tǒng)加密方法與公開(kāi)密鑰加密方法相結(jié)合的方式，即信息采用改進(jìn)的DES對(duì)話密鑰加密棕叫，然后使用RSA密鑰加密對(duì)話密鑰和信息摘要林螃。對(duì)方收到信息后，用不同的密鑰解密并可核對(duì)信息摘要俺泣。
   采用DES與RSA相結(jié)合的應(yīng)用疗认，使它們的優(yōu)缺點(diǎn)正好互補(bǔ)，即DES加密速度快伏钠，適合加密較長(zhǎng)的報(bào)文横漏，可用其加密明文；RSA加密速度慢熟掂，安全性好缎浇，應(yīng)用于DES 密鑰的加密，可解決DES 密鑰分配的問(wèn)題打掘。
   目前這種RSA和DES結(jié)合的方法已成為EMAIL保密通信標(biāo)準(zhǔn)华畏。

12鹏秋、Volley

1尊蚁、Volley的特點(diǎn)
Volley是谷歌大會(huì)上推出的網(wǎng)絡(luò)通信框架（2.3之前使用HttpClient，之后使用HttpUrlConnection）侣夷，它既可以訪問(wèn)網(wǎng)絡(luò)獲取數(shù)據(jù)横朋，也可以加載圖片，并且在性能方面進(jìn)行了大幅度的調(diào)整百拓，它的設(shè)計(jì)目的就是適合進(jìn)行數(shù)據(jù)量不大但通信頻繁的網(wǎng)絡(luò)操作琴锭，而對(duì)于大數(shù)據(jù)量的操作晰甚，比如文件下載，表現(xiàn)很糟糕决帖，因?yàn)関olley處理http返回的默認(rèn)實(shí)現(xiàn)是BasicNetwork厕九，它會(huì)把返回的流全部導(dǎo)入內(nèi)存中，下載大文件會(huì)發(fā)生內(nèi)存溢出
2地回、Volley執(zhí)行的過(guò)程：
默認(rèn)情況下扁远，Volley中開(kāi)啟四個(gè)網(wǎng)絡(luò)調(diào)度線程和一個(gè)緩存調(diào)度線程，首先請(qǐng)求會(huì)加入緩存隊(duì)列刻像，畅买，緩存調(diào)度線程從緩存隊(duì)列中取出線程，如果找到該請(qǐng)求的緩存就直接讀取該緩存并解析细睡，然后回調(diào)給主線程谷羞，如果沒(méi)有找到緩存的響應(yīng)，則將這個(gè)請(qǐng)求加入網(wǎng)絡(luò)隊(duì)列溜徙，然后網(wǎng)絡(luò)調(diào)度線程會(huì)輪詢?nèi)〕鼍W(wǎng)絡(luò)隊(duì)列中的請(qǐng)求湃缎，發(fā)起http請(qǐng)求，解析響應(yīng)并將響應(yīng)存入緩存蠢壹，回調(diào)給主線程
3雁歌、Volley為什么不適合下載上傳大文件？為什么適合數(shù)據(jù)量小的頻率高的請(qǐng)求知残？
1.volley基于請(qǐng)求隊(duì)列靠瞎，Volley的網(wǎng)絡(luò)請(qǐng)求線程池默認(rèn)大小為4。意味著可以并發(fā)進(jìn)行4個(gè)請(qǐng)求求妹，大于4個(gè)乏盐，會(huì)排在隊(duì)列中。并發(fā)量小所以適合數(shù)據(jù)量下頻率高的請(qǐng)求
2.因?yàn)閂olley下載文件會(huì)將流存入內(nèi)存中（是一個(gè)小于4k的緩存池）制恍，大文件會(huì)導(dǎo)致內(nèi)存溢出父能，所以不能下載大文件，不能上傳大文件的原因和1中差不多净神，設(shè)想你上傳了四個(gè)大文件何吝，同時(shí)占用了volley的四個(gè)線程，導(dǎo)致其他網(wǎng)絡(luò)請(qǐng)求都阻塞在隊(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握手和揮手的效率問(wèn)題，減少握手次數(shù)
3.支持Gzip壓縮跪者，且操作對(duì)用戶透明棵帽，可以通過(guò)header設(shè)置，在發(fā)起請(qǐng)求的時(shí)候自動(dòng)加入header渣玲，Accept-Encoding: gzip逗概，而我們的服務(wù)器返回的時(shí)候header中有Content-Encoding: gzip
4.利用響應(yīng)緩存來(lái)避免重復(fù)的網(wǎng)絡(luò)請(qǐng)求
5.很方便的添加攔截器，通常情況下忘衍，攔截器用來(lái)添加仗谆，移除，轉(zhuǎn)換請(qǐng)求和響應(yīng)的頭部信息淑履，比如添加公參等
6.請(qǐng)求失敗隶垮，自動(dòng)重連，發(fā)生異常時(shí)重連秘噪，看源碼調(diào)用recover方法重連了一次
7.支持SPDY協(xié)議(SPDY是Google開(kāi)發(fā)的基于TCP的應(yīng)用層協(xié)議狸吞，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度指煎，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)蹋偏。SPDY并不是一種用于替代HTTP的協(xié)議，而是對(duì)HTTP協(xié)議的增強(qiáng)至壤。新協(xié)議的功能包括數(shù)據(jù)流的多路復(fù)用威始、請(qǐng)求優(yōu)先級(jí)以及HTTP報(bào)頭壓縮。谷歌表示像街，引入SPDY協(xié)議后黎棠，在實(shí)驗(yàn)室測(cè)試中頁(yè)面加載速度比原先快64%)
8.使用Okio來(lái)簡(jiǎn)化數(shù)據(jù)的訪問(wèn)與存儲(chǔ)，提高性能
2镰绎、 OkHttp的缺點(diǎn)
1.消息回來(lái)需要切到主線程脓斩，主線程要自己去寫(xiě)。
2.調(diào)用比較復(fù)雜畴栖，需要自己進(jìn)行封裝随静。
3.緩存失效：網(wǎng)絡(luò)請(qǐng)求時(shí)一般都會(huì)獲取手機(jī)的一些硬件或網(wǎng)絡(luò)信息，比如使用的網(wǎng)絡(luò)環(huán)境吗讶。同時(shí)為了信息傳輸?shù)陌踩粤敲停赡苓€會(huì)對(duì)請(qǐng)求進(jìn)行加密。在這些情況下OkHttp的緩存系統(tǒng)就會(huì)失效了照皆，導(dǎo)致用戶在無(wú)網(wǎng)絡(luò)情況下不能訪問(wèn)緩存重绷。
3、 OkHttp框架中都用到了哪些設(shè)計(jì)模式
1.最明顯的Builder設(shè)計(jì)模式纵寝，如構(gòu)建對(duì)象OkHttpClient论寨，還有單利模式
2.工廠方法模式，如源碼中的接口Call
3.觀察者模式如EventListener爽茴，監(jiān)聽(tīng)請(qǐng)求和響應(yīng)
4.策略模式
5.責(zé)任鏈模式葬凳，如攔截器

14、Retrofit

Retrofit底層是基于OkHttp實(shí)現(xiàn)的室奏，與其他網(wǎng)絡(luò)框架不同的是火焰，它更多使用運(yùn)行時(shí)注解的方式提供功能
1、原理
通過(guò)java接口以及注解來(lái)描述網(wǎng)絡(luò)請(qǐng)求胧沫，并用動(dòng)態(tài)代理的方式生成網(wǎng)絡(luò)請(qǐng)求的request昌简，然后通過(guò)client調(diào)用相應(yīng)的網(wǎng)絡(luò)框架（默認(rèn)okhttp）去發(fā)起網(wǎng)絡(luò)請(qǐng)求，并將返回的response通過(guò)converterFactorty轉(zhuǎn)換成相應(yīng)的數(shù)據(jù)model绒怨，最后通過(guò)calladapter轉(zhuǎn)換成其他數(shù)據(jù)方式（如rxjava Observable）
2纯赎、Retrofit流程
（1）通過(guò)解析 網(wǎng)絡(luò)請(qǐng)求接口的注解 配置 網(wǎng)絡(luò)請(qǐng)求參數(shù)
（2）通過(guò) 動(dòng)態(tài)代理 生成 網(wǎng)絡(luò)請(qǐng)求對(duì)象
（3）通過(guò) 網(wǎng)絡(luò)請(qǐng)求適配器 將 網(wǎng)絡(luò)請(qǐng)求對(duì)象 進(jìn)行平臺(tái)適配
（4）通過(guò) 網(wǎng)絡(luò)請(qǐng)求執(zhí)行器 發(fā)送網(wǎng)絡(luò)請(qǐng)求
（5）通過(guò) 數(shù)據(jù)轉(zhuǎn)換器 解析服務(wù)器返回的數(shù)據(jù)
（6）通過(guò) 回調(diào)執(zhí)行器 切換線程（子線程 ->>主線程）
（7）用戶在主線程處理返回結(jié)果
3、 Retrofit優(yōu)點(diǎn)
1.可以配置不同HTTP client來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)請(qǐng)求南蹂，如okhttp犬金、httpclient等；
2.請(qǐng)求的方法參數(shù)注解都可以定制六剥；
3.支持同步晚顷、異步和RxJava；
4.超級(jí)解耦疗疟；
5.可以配置不同的反序列化工具來(lái)解析數(shù)據(jù)该默，如json、xml等
6.框架使用了很多設(shè)計(jì)模式