1.網絡分層
OSI七層協(xié)議模型主要是：
1.應用層（Application）
2.表示層（Presentation）
3.會話層（Session）
4.傳輸層（Transport）
5.網絡層（Network）
6.數(shù)據鏈路層（Data Link）
7.物理層（Physical）
2.TCP/IP五層模型
TCP/IP五層模型：
1.應用層（Application）唆香、
2.傳輸層（Transport）、
3.網絡層（Network）裆装、
4.數(shù)據鏈路層（Data Link）果录、
5.物理層（Physical）。
3.三次握手與四次揮手
第一次握手：
客戶端發(fā)送syn包(syn=j)到服務器，并進入SYN_SEND狀態(tài)蔚出，等待服務器確認；
第二次握手：
服務器收到syn包虫腋，必須確認客戶的SYN（ack=j+1）骄酗，同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包悦冀，此時服務器進入SYN_RECV狀態(tài)趋翻；
第三次握手：
客戶端收到服務器的SYN＋ACK包，向服務器發(fā)送確認包ACK(ack=k+1)盒蟆，此包發(fā)送完畢踏烙，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手历等。
握手過程中傳送的包里不包含數(shù)據讨惩，三次握手完畢后，客戶端與服務器才正式開始傳送數(shù)據募闲。
理想狀態(tài)下步脓，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前浩螺，TCP 連接都將被一直保持下去。
斷開連接時服務器和客戶端均可以主動發(fā)起斷開TCP連接的請求仍侥，斷開過程需要經過“四次握手”
第一次揮手：
客戶端發(fā)送報文告訴服務器沒有數(shù)據要發(fā)送了
第二次揮手：
服務端收到要出，再發(fā)送給客戶端告訴它我收到了
第三次揮手：
服務端向客戶端發(fā)送報文，請求關閉連接
第四次揮手：
客戶端收到關閉連接的請求农渊，向服務端發(fā)送報文患蹂，服務端關閉連接
4.TCP為什么三次握手不是兩次握手，為什么兩次握手不安全
為了實現(xiàn)可靠數(shù)據傳輸砸紊， TCP 協(xié)議的通信雙方传于， 都必須維護一個序列號， 以標識發(fā)送出去的數(shù)據包中醉顽， 哪些是已經被對方收到的沼溜。
三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經收到了序列號起始值的必經步驟
如果只是兩次握手游添， 至多只有連接發(fā)起方的起始序列號能被確認系草， 另一方選擇的序列號則得不到確認
5.為什么TCP是可靠的通熄，UDP早不可靠的?為什么UDP比TCP快?
TCP/IP協(xié)議擁有三次握手雙向機制，這一機制保證校驗了數(shù)據找都，保證了他的可靠性唇辨。
UDP就沒有了，udp信息發(fā)出后,不驗證是否到達對方,所以不可靠能耻。
6.http協(xié)議
http協(xié)議是一個基于請求與響應模式的無連接赏枚，無狀態(tài)，應用層的協(xié)議晓猛，支持c/s模式饿幅，簡單快速，靈活
簡單快速：協(xié)議簡單鞍帝，通信速度快
靈活：允許傳輸任意類型的數(shù)據對象诫睬，由Content-Type標記
無連接：每次處理一個請求，處理完成后既斷開
無狀態(tài)：對事務處理沒有記憶能力
http有兩種報文：請求報文和響應報文
請求報文由請求行帕涌，請求報頭摄凡，和請求數(shù)據組成
請求行：抓包第一行，包括請求方法蚓曼，url和http版本
請求報頭：指的就是題目中“里面的協(xié)議頭部”
請求數(shù)據：指post方式提交的表單數(shù)據
響應報文由狀態(tài)行亲澡，響應報頭，響應正文組成
狀態(tài)行：狀態(tài)碼
響應報頭：同請求報頭
響應正文：服務器返回的資源數(shù)據
接下來是http頭部纫版，既請求報頭和響應報頭床绪，統(tǒng)稱消息報頭，消息報頭可以分為通用報頭其弊，請求報頭癞己，響應報頭，實體報頭等
通用報頭和實體報頭既可以出現(xiàn)在請求報頭中梭伐，也可以出現(xiàn)在響應報頭中痹雅，通用報頭包含的字段如：Date Connection Cache-Control,實體報頭中有Content-Type Content-Length Content-Language Content-Encoding.
請求報頭中包含的字段有：
Host,User-Agent,Accept-Encoding,Accept-Language,Connection
響應報頭包含的字段：
Location，Server
7.http的get和post的區(qū)別
http是應用層的協(xié)議糊识，底層基于TCP/IP協(xié)議绩社，所以本質上，get和post請求都是TCP請求赂苗。所以二者的區(qū)別都是體現(xiàn)在應用層上（HTTP的規(guī)定和瀏覽器/服務器的限制）
1.參數(shù)的傳輸方式：GET參數(shù)通過URL傳遞愉耙，POST放在Request body中。
2.GET請求在URL中傳送的參數(shù)是有長度限制的拌滋，而POST沒有朴沿。
3.對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去鸠真，服務器響應200（返回數(shù)據）悯仙；而對于POST龄毡，瀏覽器先發(fā)送header，服務器響應100 continue锡垄，瀏覽器再發(fā)送data沦零，服務器響應200 ok（返回數(shù)據）。不過要注意货岭，并不是所有瀏覽器都會在POST中發(fā)送兩次包路操，比如火狐
4.對參數(shù)的數(shù)據類型，GET只接受ASCII字符千贯，而POST沒有限制屯仗。
5.GET比POST更不安全，因為參數(shù)直接暴露在URL上搔谴，所以不能用來傳遞敏感信息魁袜。
6.GET請求只能進行url編碼，而POST支持多種編碼方式敦第。
7.GET在瀏覽器回退時是無害的峰弹，而POST會再次提交請求。
8.GET產生的URL地址可以被Bookmark芜果，而POST不可以鞠呈。
9.GET請求會被瀏覽器主動cache，而POST不會右钾，除非手動設置蚁吝。
8.socket和http的區(qū)別：
Http連接：
http連接就是所謂的短連接，及客戶端向服務器發(fā)送一次請求舀射，服務器端相應后連接即會斷掉窘茁。
socket連接：
socket連接及時所謂的長連接，理論上客戶端和服務端一旦建立連接脆烟，則不會主動斷掉庙曙；但是由于各種環(huán)境因素可能會是連接斷開，比如說：服務器端或客戶端主機down了浩淘，網絡故障，或者兩者之間長時間沒有數(shù)據傳輸吴攒，網絡防火墻可能會斷開該鏈接已釋放網絡資源张抄。所以當一個socket連接中沒有數(shù)據的傳輸，那么為了位置連續(xù)的連接需要發(fā)送心跳消息洼怔，具體心跳消息格式是開發(fā)者自己定義的署惯。
9.TCP與UDP區(qū)別總結
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的镣隶，即發(fā)送數(shù)據之前不需要建立連接
2极谊、TCP提供可靠的服務诡右。也就是說，通過TCP連接傳送的數(shù)據轻猖，無差錯帆吻，不丟失，不重復咙边，且按序到達;UDP盡最大努力交付猜煮，即不保 證可靠交付
3、TCP面向字節(jié)流败许，實際上是TCP把數(shù)據看成一連串無結構的字節(jié)流;UDP是面向報文的
UDP沒有擁塞控制王带，因此網絡出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如IP電話市殷，實時視頻會議等）
4愕撰、每一條TCP連接只能是點到點的;UDP支持一對一，一對多醋寝，多對一和多對多的交互通信
5搞挣、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個字節(jié)
6甥桂、TCP的邏輯通信信道是全雙工的可靠信道柿究，UDP則是不可靠信道
10.https
HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全為目標的HTTP通道黄选，簡單講是HTTP的安全版蝇摸。HTTP是應用層協(xié)議，位于HTTP協(xié)議之下是傳輸協(xié)議TCP办陷。TCP負責傳輸貌夕，HTTP則定義了數(shù)據如何進行包裝，在HTTP跟TCP中間加多了一層加密層TLS/SSL民镜，SSL是個加密套件啡专，負責對HTTP的數(shù)據進行加密。TLS是SSL的升級版≈迫Γ現(xiàn)在提到HTTPS们童，加密套件基本指的是TLS。
傳輸加密的流程：http是應用層將數(shù)據直接給到TCP進行傳輸鲸鹦，https是應用層將數(shù)據給到TLS/SSL慧库，將數(shù)據加密后，再給到TCP進行傳輸馋嗜。
HTTPS是如何加密數(shù)據的：
一般來說齐板，加密分為對稱加密、非對稱加密
- 對稱加密
對稱加密的意思就是，加密數(shù)據用的密鑰甘磨，跟解密數(shù)據用的密鑰是一樣的橡羞。
對稱加密的優(yōu)點在于加密、解密效率通常比較高济舆。缺點在于卿泽，數(shù)據發(fā)送方、數(shù)據接收方需要協(xié)商吗冤、共享同一把密鑰又厉，并確保密鑰不泄露給其他人。傳輸過程中容易被截獲椎瘟。
網上一個很形象的例子：假如現(xiàn)在小客與小服要進行一次私密的對話覆致，他們不希望這次對話內容被其他外人知道》挝担可是煌妈，我們平時的數(shù)據傳輸過程中又是明文傳輸?shù)模f一被某個黑客把他們的對話內容給竊取了宣羊，那就難受了璧诵。為了解決這個問題，小服這家伙想到了一個方法來加密數(shù)據仇冯，讓黑客看不到具體的內容之宿。該方法是這樣子的：在每次數(shù)據傳輸之前，小服會先傳輸小客一把密鑰苛坚，然后小服在之后給小客發(fā)消息的過程中比被，會用這把密鑰對這些消息進行加密。小客在收到這些消息后泼舱，會用之前小服給的那把密鑰對這些消息進行解密等缀，這樣，小客就能得到密文里面真正的數(shù)據了娇昙。如果小客要給小服發(fā)消息尺迂，也同樣用這把密鑰來對消息進行加密，小服收到后也用這把密鑰進行解密冒掌。 這樣噪裕，就保證了數(shù)據傳輸?shù)陌踩浴?/li>
2.非對稱加密
非對稱加密的意思就是，加密數(shù)據用的密鑰（公鑰）股毫，跟解密數(shù)據用的密鑰（私鑰）是不一樣的州疾。
網上一個很形象的例子：小服還是挺聰明的，得意了一會之后皇拣，小服意識到了密鑰會被截取這個問題。倔強的小服又想到了另外一種方法：用非對稱加密的方法來加密數(shù)據。該方法是這樣的：小服和小客都擁有兩把鑰匙氧急，一把鑰匙的公開的（全世界都知道也沒關系）颗胡，稱之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道）吩坝，稱之為私鑰毒姨。并且，用公鑰加密的數(shù)據钉寝，只有對應的私鑰才能解密弧呐；用私鑰加密的數(shù)據，只有對應的公鑰才能解密嵌纲。所以在傳輸數(shù)據的過程中俘枫，小服在給小客傳輸數(shù)據的過程中，會用小客給他的公鑰進行加密逮走，然后小客收到后鸠蚪，再用自己的私鑰進行解密。小客給小服發(fā)消息的時候师溅，也一樣會用小服給他的公鑰進行加密茅信，然后小服再用自己的私鑰進行解密。 這樣墓臭，數(shù)據就能安全著到達雙方蘸鲸。是什么原因導致非對稱加密這種方法的不安全性呢？它和對稱加密方法的不安全性不同窿锉。非對稱加密之所以不安全酌摇，是因為小客收到了公鑰之后，無法確定這把公鑰是否真的是小服榆综。
解決的辦法就是數(shù)字證書：小服再給小客發(fā)公鑰的過程中妙痹，會把公鑰以及小服的個人信息通過Hash算法生成消息摘要，為了防止摘要被人調換鼻疮，小服還會用CA提供的私鑰對消息摘要進行加密來形成數(shù)字簽名怯伊，當小客拿到這份數(shù)字證書之后，就會用CA提供的公鑰來對數(shù)字證書里面的數(shù)字簽名進行解密得到消息摘要判沟，然后對數(shù)字證書里面小服的公鑰和個人信息進行Hash得到另一份消息摘要耿芹，然后把兩份消息摘要進行對比，如果一樣挪哄，則證明這些東西確實是小服的吧秕，否則就不是。
11.加密算法
1.對稱加密算法
Data Encryption Standard(DES)
DES 是一種典型的塊加密方法：將固定長度的明文通過一系列復雜的操作變成同樣長度的密文迹炼，塊的長度為64位砸彬。同時颠毙，DES 使用的密鑰來自定義變換過程，因此算法認為只有持有加密所用的密鑰的用戶才能解密密文砂碉。 DES 的密鑰表面上是64位的蛀蜜，實際有效密鑰長度為56位，其余8位可以用于奇偶校驗增蹭。
DES 現(xiàn)在已經不被視為一種安全的加密算法滴某，主要原因是它使用的56位密鑰過短。
為了提供實用所需的安全性滋迈，可以使用 DES 的派生算法 3DES 來進行加密 (雖然3DES 也存在理論上的攻擊方法)霎奢。
Advanced Encryption Standard(AES)
AES 在密碼學中又稱 Rijndael 加密法，用來替代原先的 DES饼灿，已經被多方分析且廣泛使用幕侠。
DES與AES的比較
自DES 算法公諸于世以來，學術界圍繞它的安全性等方面進行了研究并展開了激烈的爭論赔退。在技術上橙依，對DES的批評主要集中在以下幾個方面：
1、作為分組密碼硕旗，DES 的加密單位僅有64 位二進制窗骑，這對于數(shù)據傳輸來說太小，因為每個分組僅含8 個字符漆枚，而且其中某些位還要用于奇偶校驗或其他通訊開銷创译。
2、DES 的密鑰的位數(shù)太短墙基，只有56 比特软族，而且各次迭代中使用的密鑰是遞推產生的，這種相關必然降低密碼體制的安全性残制，在現(xiàn)有技術下用窮舉法尋找密鑰已趨于可行立砸。
3、DES 不能對抗差分和線性密碼分析初茶。
4颗祝、DES 用戶實際使用的密鑰長度為56bit，理論上最大加密強度為256恼布。DES 算法要提高加密強度（例如增加密鑰長度）螺戳，則系統(tǒng)開銷呈指數(shù)增長。除采用提高硬件功能和增加并行處理功能外折汞，從算法本身和軟件技術方面都無法提高DES 算法的加密強度倔幼。
- 非對稱加密算法
RSA
1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出爽待，以他們三人姓氏開頭字母命名损同，是一種獲得廣泛使用的非對稱加密算法翩腐。
對極大整數(shù)做因數(shù)分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性。換言之揖庄，對一個極大整數(shù)做因數(shù)分解愈困難栗菜，RSA 算法就愈可靠。假如有人找到一種快速因數(shù)分解的算法的話蹄梢，那么用 RSA 加密的信息的可靠性就肯定會極度下降。目前看來找到這樣的算法的可能性非常小富俄。
DES與RSA的比較
RSA算法的密鑰很長禁炒，具有較好的安全性，但加密的計算量很大霍比，加密速度較慢限制了其應用范圍幕袱。為減少計算量，在傳送信息時悠瞬，常采用傳統(tǒng)加密方法與公開密鑰加密方法相結合的方式们豌，即信息采用改進的DES對話密鑰加密，然后使用RSA密鑰加密對話密鑰和信息摘要浅妆。對方收到信息后望迎，用不同的密鑰解密并可核對信息摘要。
采用DES與RSA相結合的應用凌外，使它們的優(yōu)缺點正好互補辩尊，即DES加密速度快，適合加密較長的報文康辑，可用其加密明文摄欲；RSA加密速度慢，安全性好疮薇，應用于DES 密鑰的加密胸墙，可解決DES 密鑰分配的問題。
目前這種RSA和DES結合的方法已成為EMAIL保密通信標準按咒。
12.Volley
1迟隅、Volley的特點
Volley是谷歌大會上推出的網絡通信框架（2.3之前使用HttpClient，之后使用HttpUrlConnection）胖齐，它既可以訪問網絡獲取數(shù)據玻淑，也可以加載圖片，并且在性能方面進行了大幅度的調整呀伙，它的設計目的就是適合進行數(shù)據量不大但通信頻繁的網絡操作补履，而對于大數(shù)據量的操作，比如文件下載剿另，表現(xiàn)很糟糕箫锤，因為volley處理http返回的默認實現(xiàn)是BasicNetwork贬蛙，它會把返回的流全部導入內存中，下載大文件會發(fā)生內存溢出
2谚攒、Volley執(zhí)行的過程：
默認情況下阳准，Volley中開啟四個網絡調度線程和一個緩存調度線程，首先請求會加入緩存隊列馏臭，野蝇，緩存調度線程從緩存隊列中取出線程，如果找到該請求的緩存就直接讀取該緩存并解析括儒，然后回調給主線程绕沈，如果沒有找到緩存的響應，則將這個請求加入網絡隊列帮寻，然后網絡調度線程會輪詢取出網絡隊列中的請求乍狐，發(fā)起http請求，解析響應并將響應存入緩存固逗，回調給主線程
3浅蚪、Volley為什么不適合下載上傳大文件？為什么適合數(shù)據量小的頻率高的請求烫罩？
1.volley基于請求隊列惜傲，Volley的網絡請求線程池默認大小為4淮逊。意味著可以并發(fā)進行4個請求半开，大于4個，會排在隊列中伙窃。并發(fā)量小所以適合數(shù)據量下頻率高的請求
2.因為Volley下載文件會將流存入內存中（是一個小于4k的緩存池）饿这，大文件會導致內存溢出浊伙，所以不能下載大文件，不能上傳大文件的原因和1中差不多长捧，設想你上傳了四個大文件嚣鄙，同時占用了volley的四個線程，導致其他網絡請求都阻塞在隊列中串结，造成反應慢的現(xiàn)象
13.OKHttp
1哑子、OKHttp的特點
1.相較于Volley，它的最大并發(fā)量為64
2.使用連接池技術肌割，支持5個并發(fā)的socket連接默認keepAlive時間為5分鐘卧蜓，解決TCP握手和揮手的效率問題，減少握手次數(shù)
3.支持Gzip壓縮把敞，且操作對用戶透明弥奸，可以通過header設置，在發(fā)起請求的時候自動加入header奋早，Accept-Encoding: gzip盛霎，而我們的服務器返回的時候header中有Content-Encoding: gzip
4.利用響應緩存來避免重復的網絡請求
5.很方便的添加攔截器赠橙，通常情況下，攔截器用來添加愤炸，移除期揪，轉換請求和響應的頭部信息，比如添加公參等
6.請求失敗规个，自動重連凤薛，發(fā)生異常時重連，看源碼調用recover方法重連了一次
7.支持SPDY協(xié)議(SPDY是Google開發(fā)的基于TCP的應用層協(xié)議诞仓，用以最小化網絡延遲枉侧，提升網絡速度，優(yōu)化用戶的網絡使用體驗狂芋。SPDY并不是一種用于替代HTTP的協(xié)議，而是對HTTP協(xié)議的增強憨栽。新協(xié)議的功能包括數(shù)據流的多路復用帜矾、請求優(yōu)先級以及HTTP報頭壓縮。谷歌表示屑柔，引入SPDY協(xié)議后屡萤，在實驗室測試中頁面加載速度比原先快64%)
8.使用Okio來簡化數(shù)據的訪問與存儲，提高性能
2掸宛、 OkHttp的缺點
1.消息回來需要切到主線程死陆，主線程要自己去寫。
2.調用比較復雜唧瘾，需要自己進行封裝措译。
3.緩存失效：網絡請求時一般都會獲取手機的一些硬件或網絡信息，比如使用的網絡環(huán)境饰序。同時為了信息傳輸?shù)陌踩粤旌纾赡苓€會對請求進行加密。在這些情況下OkHttp的緩存系統(tǒng)就會失效了求豫，導致用戶在無網絡情況下不能訪問緩存塌衰。
3、 OkHttp框架中都用到了哪些設計模式
1.最明顯的Builder設計模式蝠嘉，如構建對象OkHttpClient最疆，還有單利模式
2.工廠方法模式，如源碼中的接口Call
3.觀察者模式如EventListener蚤告，監(jiān)聽請求和響應
4.策略模式
5.責任鏈模式努酸，如攔截器
14.Retrofit
Retrofit底層是基于OkHttp實現(xiàn)的，與其他網絡框架不同的是罩缴，它更多使用運行時注解的方式提供功能
1蚊逢、原理
通過java接口以及注解來描述網絡請求层扶，并用動態(tài)代理的方式生成網絡請求的request，然后通過client調用相應的網絡框架（默認okhttp）去發(fā)起網絡請求烙荷，并將返回的response通過converterFactorty轉換成相應的數(shù)據model镜会，最后通過calladapter轉換成其他數(shù)據方式（如rxjava Observable）
2、Retrofit流程
（1）通過解析 網絡請求接口的注解 配置 網絡請求參數(shù)
（2）通過 動態(tài)代理 生成 網絡請求對象
（3）通過 網絡請求適配器 將 網絡請求對象 進行平臺適配
（4）通過 網絡請求執(zhí)行器 發(fā)送網絡請求
（5）通過 數(shù)據轉換器 解析服務器返回的數(shù)據
（6）通過 回調執(zhí)行器 切換線程（子線程 ->>主線程）
（7）用戶在主線程處理返回結果
3终抽、 Retrofit優(yōu)點
1.可以配置不同HTTP client來實現(xiàn)網絡請求戳表，如okhttp、httpclient等昼伴；
2.請求的方法參數(shù)注解都可以定制匾旭；
3.支持同步、異步和RxJava圃郊；
4.超級解耦价涝；
5.可以配置不同的反序列化工具來解析數(shù)據持舆，如json色瘩、xml等
6.框架使用了很多設計模式
至此，本篇已結束逸寓，如有不對的地方居兆，歡迎您的建議與指正。同時期待您的關注竹伸，感謝您的閱讀泥栖，謝謝！
