2019Android網絡編程面試題

極力推薦文章：歡迎收藏
Android 乾貨分享

閱讀五分鐘，每日十點，和您一塊兒終身學習，這裏是程序員Android

1.網絡分層

OSI七層協議模型主要是：

1.應用層（Application）
2.表示層（Presentation）
3.會話層（Session）
4.傳輸層（Transport）
5.網絡層（Network）
6.數據鏈路層（Data Link）
7.物理層（Physical）

2.TCP/IP五層模型

TCP/IP五層模型：

1.應用層（Application）、
2.傳輸層（Transport）、
3.網絡層（Network）、
4.數據鏈路層（Data Link）、
5.物理層（Physical）。

3.三次握手與四次揮手

第一次握手：

客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：

服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：

客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。
理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，TCP 鏈接都將被一直保持下去。

斷開鏈接時服務器和客戶端都可以主動發起斷開TCP鏈接的請求，斷開過程須要通過「四次握手」

第一次揮手：

客戶端發送報文告訴服務器沒有數據要發送了

第二次揮手：

服務端收到，再發送給客戶端告訴它我收到了

第三次揮手：

服務端向客戶端發送報文，請求關閉鏈接

第四次揮手：

客戶端收到關閉鏈接的請求，向服務端發送報文，服務端關閉鏈接

4.TCP爲何三次握手不是兩次握手，爲何兩次握手不安全

爲了實現可靠數據傳輸， TCP 協議的通訊雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。

三次握手的過程便是通訊雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟

若是隻是兩次握手， 至多隻有鏈接發起方的起始序列號能被確認， 另外一方選擇的序列號則得不到確認

5.爲何TCP是可靠的，UDP早不可靠的?爲何UDP比TCP快?

TCP/IP協議擁有三次握手雙向機制，這一機制保證校驗了數據，保證了他的可靠性。
UDP就沒有了，udp信息發出後,不驗證是否到達對方,因此不可靠。

6.http協議

http協議是一個基於請求與響應模式的無鏈接，無狀態，應用層的協議，支持c/s模式，簡單快速，靈活

簡單快速：協議簡單，通訊速度快
靈活：容許傳輸任意類型的數據對象，由Content-Type標記
無鏈接：每次處理一個請求，處理完成後既斷開
無狀態：對事務處理沒有記憶能力
http有兩種報文：請求報文和響應報文
請求報文由請求行，請求報頭，和請求數據組成
請求行：抓包第一行，包括請求方法，url和http版本
請求報頭：指的就是題目中「裏面的協議頭部」
請求數據：指post方式提交的表單數據
響應報文由狀態行，響應報頭，響應正文組成
狀態行：狀態碼
響應報頭：同請求報頭
響應正文：服務器返回的資源數據
接下來是http頭部，既請求報頭和響應報頭，統稱消息報頭，消息報頭能夠分爲通用報頭，請求報頭，響應報頭，實體報頭等
通用報頭和實體報頭既能夠出如今請求報頭中，也能夠出如今響應報頭中，通用報頭包含的字段如：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的區別

http是應用層的協議，底層基於TCP/IP協議，因此本質上，get和post請求都是TCP請求。因此兩者的區別都是體如今應用層上（HTTP的規定和瀏覽器/服務器的限制）

1.參數的傳輸方式：GET參數經過URL傳遞，POST放在Request body中。
2.GET請求在URL中傳送的參數是有長度限制的，而POST沒有。
3.對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。不過要注意，並非全部瀏覽器都會在POST中發送兩次包，好比火狐
4.對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
5.GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。
6.GET請求只能進行url編碼，而POST支持多種編碼方式。
7.GET在瀏覽器回退時是無害的，而POST會再次提交請求。
8.GET產生的URL地址能夠被Bookmark，而POST不能夠。
9.GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

8.socket和http的區別：

Http鏈接：

http鏈接就是所謂的短鏈接，及客戶端向服務器發送一次請求，服務器端相應後鏈接即會斷掉。

socket鏈接：

socket鏈接及時所謂的長鏈接，理論上客戶端和服務端一旦創建鏈接，則不會主動斷掉；可是因爲各類環境因素可能會是鏈接斷開，好比說：服務器端或客戶端主機down了，網絡故障，或者二者之間長時間沒有數據傳輸，網絡防火牆可能會斷開該連接已釋放網絡資源。因此當一個socket鏈接中沒有數據的傳輸，那麼爲了位置連續的鏈接須要發送心跳消息，具體心跳消息格式是開發者本身定義的。

9.TCP與UDP區別總結

一、TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接
二、TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保 證可靠交付
三、TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
四、每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊
五、TCP首部開銷20字節;UDP的首部開銷小，只有8個字節
六、TCP的邏輯通訊信道是全雙工的可靠信道，UDP則是不可靠信道

10.https

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。HTTP是應用層協議，位於HTTP協議之下是傳輸協議TCP。TCP負責傳輸，HTTP則定義了數據如何進行包裝，在HTTP跟TCP中間加多了一層加密層TLS/SSL，SSL是個加密套件，負責對HTTP的數據進行加密。TLS是SSL的升級版。如今提到HTTPS，加密套件基本指的是TLS。
傳輸加密的流程：http是應用層將數據直接給到TCP進行傳輸，https是應用層將數據給到TLS/SSL，將數據加密後，再給到TCP進行傳輸。
HTTPS是如何加密數據的：
通常來講，加密分爲對稱加密、非對稱加密

1. 對稱加密

對稱加密的意思就是，加密數據用的密鑰，跟解密數據用的密鑰是同樣的。
對稱加密的優勢在於加密、解密效率一般比較高。缺點在於，數據發送方、數據接收方須要協商、共享同一把密鑰，並確保密鑰不泄露給其餘人。傳輸過程當中容易被截獲。
網上一個很形象的例子：假如如今小客與小服要進行一次私密的對話，他們不但願此次對話內容被其餘外人知道。但是，咱們平時的數據傳輸過程當中又是明文傳輸的，萬一被某個黑客把他們的對話內容給竊取了，那就難受了。爲了解決這個問題，小服這傢伙想到了一個方法來加密數據，讓黑客看不到具體的內容。該方法是這樣子的：在每次數據傳輸以前，小服會先傳輸小客一把密鑰，而後小服在以後給小客發消息的過程當中，會用這把密鑰對這些消息進行加密。小客在收到這些消息後，會用以前小服給的那把密鑰對這些消息進行解密，這樣，小客就能獲得密文裏面真正的數據了。若是小客要給小服發消息，也一樣用這把密鑰來對消息進行加密，小服收到後也用這把密鑰進行解密。 這樣，就保證了數據傳輸的安全性。

2.非對稱加密

非對稱加密的意思就是，加密數據用的密鑰（公鑰），跟解密數據用的密鑰（私鑰）是不同的。
網上一個很形象的例子：小服仍是挺聰明的，得意了一會以後，小服意識到了密鑰會被截取這個問題。倔強的小服又想到了另一種方法：用非對稱加密的方法來加密數據。該方法是這樣的：小服和小客都擁有兩把鑰匙，一把鑰匙的公開的（全世界都知道也不要緊），稱之爲公鑰；而另外一把鑰匙是保密（也就是隻有本身才知道），稱之爲私鑰。而且，用公鑰加密的數據，只有對應的私鑰才能解密；用私鑰加密的數據，只有對應的公鑰才能解密。因此在傳輸數據的過程當中，小服在給小客傳輸數據的過程當中，會用小客給他的公鑰進行加密，而後小客收到後，再用本身的私鑰進行解密。小客給小服發消息的時候，也同樣會用小服給他的公鑰進行加密，而後小服再用本身的私鑰進行解密。 這樣，數據就能安全着到達雙方。是什麼緣由致使非對稱加密這種方法的不安全性呢？它和對稱加密方法的不安全性不一樣。非對稱加密之因此不安全，是由於小客收到了公鑰以後，沒法肯定這把公鑰是否真的是小服。
解決的辦法就是數字證書：小服再給小客發公鑰的過程當中，會把公鑰以及小服的我的信息經過Hash算法生成消息摘要，爲了防止摘要被人調換，小服還會用CA提供的私鑰對消息摘要進行加密來造成數字簽名，當小客拿到這份數字證書以後，就會用CA提供的公鑰來對數字證書裏面的數字簽名進行解密獲得消息摘要，而後對數字證書裏面小服的公鑰和我的信息進行Hash獲得另外一份消息摘要，而後把兩份消息摘要進行對比，若是同樣，則證實這些東西確實是小服的，不然就不是。

11.加密算法

1.對稱加密算法

Data Encryption Standard(DES)
DES 是一種典型的塊加密方法：將固定長度的明文經過一系列複雜的操做變成一樣長度的密文，塊的長度爲64位。同時，DES 使用的密鑰來自定義變換過程，所以算法認爲只有持有加密所用的密鑰的用戶才能解密密文。 DES 的密鑰表面上是64位的，實際有效密鑰長度爲56位，其他8位能夠用於奇偶校驗。
DES 如今已經不被視爲一種安全的加密算法，主要緣由是它使用的56位密鑰太短。
爲了提供實用所需的安全性，可使用 DES 的派生算法 3DES 來進行加密 (雖然3DES 也存在理論上的攻擊方法)。
Advanced Encryption Standard(AES)
AES 在密碼學中又稱 Rijndael 加密法，用來替代原先的 DES，已經被多方分析且普遍使用。
DES與AES的比較
自DES 算法公諸於世以來，學術界圍繞它的安全性等方面進行了研究並展開了激烈的爭論。在技術上，對DES的批評主要集中在如下幾個方面：
一、做爲分組密碼，DES 的加密單位僅有64 位二進制，這對於數據傳輸來講過小，由於每一個分組僅含8 個字符，並且其中某些位還要用於奇偶校驗或其餘通信開銷。
二、DES 的密鑰的位數過短，只有56 比特，並且各次迭代中使用的密鑰是遞推產生的，這種相關必然下降密碼體制的安全性，在現有技術下用窮舉法尋找密鑰已趨於可行。
三、DES 不能對抗差分和線性密碼分析。
四、DES 用戶實際使用的密鑰長度爲56bit，理論上最大加密強度爲256。DES 算法要提升加密強度（例如增長密鑰長度），則系統開銷呈指數增加。除採用提升硬件功能和增長並行處理功能外，從算法自己和軟件技術方面都沒法提升DES 算法的加密強度。

2. 非對稱加密算法

RSA
1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一塊兒提出，以他們三人姓氏開頭字母命名，是一種得到普遍使用的非對稱加密算法。
對極大整數作因數分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性。換言之，對一個極大整數作因數分解愈困難，RSA 算法就愈可靠。假若有人找到一種快速因數分解的算法的話，那麼用 RSA 加密的信息的可靠性就確定會極度降低。目前看來找到這樣的算法的可能性很是小。
DES與RSA的比較
RSA算法的密鑰很長，具備較好的安全性，但加密的計算量很大，加密速度較慢限制了其應用範圍。爲減小計算量，在傳送信息時，常採用傳統加密方法與公開密鑰加密方法相結合的方式，即信息採用改進的DES對話密鑰加密，而後使用RSA密鑰加密對話密鑰和信息摘要。對方收到信息後，用不一樣的密鑰解密並可覈對信息摘要。
採用DES與RSA相結合的應用，使它們的優缺點正好互補，即DES加密速度快，適合加密較長的報文，可用其加密明文；RSA加密速度慢，安全性好，應用於DES 密鑰的加密，可解決DES 密鑰分配的問題。
目前這種RSA和DES結合的方法已成爲EMAIL保密通訊標準。

12.Volley

一、Volley的特色

Volley是谷歌大會上推出的網絡通訊框架（2.3以前使用HttpClient，以後使用HttpUrlConnection），它既能夠訪問網絡獲取數據，也能夠加載圖片，而且在性能方面進行了大幅度的調整，它的設計目的就是適合進行數據量不大但通訊頻繁的網絡操做，而對於大數據量的操做，好比文件下載，表現很糟糕，由於volley處理http返回的默認實現是BasicNetwork，它會把返回的流所有導入內存中，下載大文件會發生內存溢出

二、Volley執行的過程：

默認狀況下，Volley中開啓四個網絡調度線程和一個緩存調度線程，首先請求會加入緩存隊列，，緩存調度線程從緩存隊列中取出線程，若是找到該請求的緩存就直接讀取該緩存並解析，而後回調給主線程，若是沒有找到緩存的響應，則將這個請求加入網絡隊列，而後網絡調度線程會輪詢取出網絡隊列中的請求，發起http請求，解析響應並將響應存入緩存，回調給主線程

三、Volley爲何不適合下載上傳大文件？爲何適合數據量小的頻率高的請求？

1.volley基於請求隊列，Volley的網絡請求線程池默認大小爲4。意味着能夠併發進行4個請求，大於4個，會排在隊列中。併發量小因此適合數據量下頻率高的請求
2.由於Volley下載文件會將流存入內存中（是一個小於4k的緩存池），大文件會致使內存溢出，因此不能下載大文件，不能上傳大文件的緣由和1中差很少，設想你上傳了四個大文件，同時佔用了volley的四個線程，致使其餘網絡請求都阻塞在隊列中，形成反應慢的現象

13.OKHttp

一、OKHttp的特色

1.相較於Volley，它的最大併發量爲64
2.使用鏈接池技術，支持5個併發的socket鏈接默認keepAlive時間爲5分鐘，解決TCP握手和揮手的效率問題，減小握手次數
3.支持Gzip壓縮，且操做對用戶透明，能夠經過header設置，在發起請求的時候自動加入header，Accept-Encoding: gzip，而咱們的服務器返回的時候header中有Content-Encoding: gzip
4.利用響應緩存來避免重複的網絡請求
5.很方便的添加攔截器，一般狀況下，攔截器用來添加，移除，轉換請求和響應的頭部信息，好比添加公參等
6.請求失敗，自動重連，發生異常時重連，看源碼調用recover方法重連了一次
7.支持SPDY協議(SPDY是Google開發的基於TCP的應用層協議，用以最小化網絡延遲，提高網絡速度，優化用戶的網絡使用體驗。SPDY並非一種用於替代HTTP的協議，而是對HTTP協議的加強。新協議的功能包括數據流的多路複用、請求優先級以及HTTP報頭壓縮。谷歌表示，引入SPDY協議後，在實驗室測試中頁面加載速度比原先快64%)
8.使用Okio來簡化數據的訪問與存儲，提升性能

二、 OkHttp的缺點

1.消息回來須要切到主線程，主線程要本身去寫。
2.調用比較複雜，須要本身進行封裝。
3.緩存失效：網絡請求時通常都會獲取手機的一些硬件或網絡信息，好比使用的網絡環境。同時爲了信息傳輸的安全性，可能還會對請求進行加密。在這些狀況下OkHttp的緩存系統就會失效了，致使用戶在無網絡狀況下不能訪問緩存。

三、 OkHttp框架中都用到了哪些設計模式

1.最明顯的Builder設計模式，如構建對象OkHttpClient，還有單利模式
2.工廠方法模式，如源碼中的接口Call
3.觀察者模式如EventListener，監聽請求和響應
4.策略模式
5.責任鏈模式，如攔截器

14.Retrofit

Retrofit底層是基於OkHttp實現的，與其餘網絡框架不一樣的是，它更多使用運行時註解的方式提供功能

一、原理

經過java接口以及註解來描述網絡請求，並用動態代理的方式生成網絡請求的request，而後經過client調用相應的網絡框架（默認okhttp）去發起網絡請求，並將返回的response經過converterFactorty轉換成相應的數據model，最後經過calladapter轉換成其餘數據方式（如rxjava Observable）

二、Retrofit流程

（1）經過解析 網絡請求接口的註解 配置 網絡請求參數
（2）經過 動態代理 生成 網絡請求對象
（3）經過 網絡請求適配器 將 網絡請求對象 進行平臺適配
（4）經過 網絡請求執行器 發送網絡請求
（5）經過 數據轉換器 解析服務器返回的數據
（6）經過 回調執行器 切換線程（子線程 ->>主線程）
（7）用戶在主線程處理返回結果

三、 Retrofit優勢

1.能夠配置不一樣HTTP client來實現網絡請求，如okhttp、httpclient等；
2.請求的方法參數註解均可以定製；
3.支持同步、異步和RxJava；
4.超級解耦；
5.能夠配置不一樣的反序列化工具來解析數據，如json、xml等
6.框架使用了不少設計模式

至此，本篇已結束，若有不對的地方，歡迎您的建議與指正。同時期待您的關注，感謝您的閱讀，謝謝！