Android面試之網絡

本文是Android面試題整理中的一篇，結合右下角目錄食用更佳

1. 計算機網絡的分層

按照不一樣組織的標準和規範，能夠有不一樣的分層方式

OSI七層

應用層、表示層、會話層、運輸層、網絡層、數據鏈路層、物理層

TCP/IP（四層）

應用層、傳輸層、網絡層、網絡接口層

五層協議

1. 應用層：爲操做系統或網絡應用程序提供訪問網絡服務的接口；經過應用進程間的交互來完成特定網絡應用，應用層協議定義的是應用進程間通訊和交互規則。不一樣的網絡應用層有不一樣的應用層協議，如：萬維網應用的HTTP協議，電子郵件的SMTP協議，支持文件傳送的FTP協議，應用層交互的數據單元稱爲報文。當不一樣的應用進程數據通訊或者數據交換時，就去調用應用層的不一樣協議實體，讓這些實體去調用TCP或者UDP層服務來進行網絡傳輸
2. 傳輸層：向兩個主機中應用進程之間的通訊提供通用的數據傳輸服務。應用進程以利用該服務傳送應用層報文。運輸層使用如下兩種協議：傳輸控制協議TCP（提供面向鏈接的、可靠的數據傳輸服務，其數據傳輸的單位是報文段）；用戶數據報協議UDP（提供無鏈接的、盡最大努力的數據傳輸服務，不保證數據傳輸的可靠性，單位是用戶數據報）；
3. 網絡層： 數據報封裝和路由尋址功能 網絡互連層的主要功能是尋址和對數據報的封裝以及重要的路由選擇功能。 這些功能大部分都是由IP協議來完成的，再加上地址解析協議（Address Resolution Protocol，ARP）、因特網控制報文協議（Internet Control Message Protocol，ICMP）等協議從旁協助，因此IP協議是本層衆多實體中的核心。下面簡單介紹這幾個協議。 **網際協議（Internet Protocol，IP）。該協議是一個無鏈接的協議，主要負責將數據報從源結點轉發到目的結點。也就是說，IP協議經過對每一個數據報中都有的源地址和目的地址進行分析，而後進行路由選擇（即選擇一條到達目標的最佳路徑），最後再轉發到目的地。**須要注意的是：IP協議只是負責對數據進行轉發，並不對數據進行檢查。也就是說，它不負責數據的可靠性，這樣設計的主要目的是提升IP協議傳送和轉發數據的效率。 地址解析協議（Address Resolution Protocol，ARP）。該協議主要負責將TCP/IP網絡中的IP地址解析和轉換成計算機的物理地址，以便於物理設備（如網卡）按該地址來接收數據。 反向地址解析協議（Reverse Address Resolution Protocol，RARP）。該協議的做用與ARP的做用相反，它主要負責將設備的物理地址解析和轉換成IP地址。 因特網控制報文協議（Internet Control Message Protocol，ICMP）。該協議主要負責發送和傳遞包含控制信息的數據報，這些控制信息包括哪臺計算機出了什麼錯誤、網絡路由出現了什麼錯誤等內容
4. 數據鏈路層 ：兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議，數據鏈路層將網絡層交下來IP數據報組裝成數據幀，在兩個相鄰節點間的鏈路上傳送幀；數據幀：（所謂數據幀（Data frame），就是數據鏈路層的協議數據單元，它包括三部分：幀頭，數據部分，幀尾。其中，幀頭和幀尾包含一些必要的控制信息，好比同步信息、地址信息、差錯控制信息等；數據部分則包含網絡層傳下來的數據，好比IP數據包）
5. 物理層：物理層上所傳數據的單位是比特，肯定要鏈接電纜的插頭應當有多少根引腳，以及各條引腳應如何鏈接。傳遞信息所利用的是一些物理媒體，如電纜、光纜、無線信道等，並不在物理層協議以內而是在物理層協議的下面

2. TCP與UDP的區別

1. TCP協議是一種可靠的、面向鏈接的協議:保證通訊主機之間有可靠的字節流傳輸，完成流量控制功能，協調收發雙方的發送與接收速度，達到正確傳輸的目的
2. UDP是一種不可靠、無鏈接的協議:其特色是協議簡單、額外開銷小、效率較高，可是不能保證傳輸是否正確

3. TCP對應的協議和UDP對應的協議

TCP

1. HTTP協議：從Web服務器傳輸超文本到本地瀏覽器的傳送協議，默認使用80端口。
2. FTP：文件傳輸協議，默認使用21端口。
3. SMTP：簡單郵件傳送協議，用於發送郵件，默認使用25號端口。
4. POP3：和SMTP對應，POP3用於接收郵件，默認使用110端口
5. Telnet：一種用於遠程登錄的端口，用戶能夠以本身的身份遠程鏈接到計算機上，經過這種端口能夠提供一種基於DOS模式下的通訊服務，默認使用23端口

UDP

1. DNS：域名解析服務，將域名地址轉換爲IP地址，默認使用53號端口。
2. TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，默認使用69號端口。
3. SNMP：簡單網絡管理協議，默認使用161號端口，是用來管理網絡設備的。

4. TCP的報文段

TCP是一種面向鏈接的、可靠的傳輸層協議，經過TCP報文段進行傳輸，報文段分爲頭部和數據兩個部分，頭部包含了此報文段的一些基本信息，基本格式以下圖。

1. 原端口和目的端口：即應用程序在客戶端和服務器端所對應的端口號
2. 序號（seq）和確認序號（ack）：是TCP可靠傳輸的關鍵部分。序號是本報文段發送的數據組的第一個字節的序號。在TCP傳送的流中，每個字節一個序號。e.g.一個報文段的序號爲300，此報文段數據部分共有100字節，則下一個報文段的序號爲400。因此序號確保了TCP傳輸的有序性。確認號，即ACK，指明下一個期待收到的字節序號，代表該序號以前的全部數據已經正確無誤的收到。確認號只有當ACK標誌爲1時纔有效。好比創建鏈接時，SYN報文的ACK標誌位爲0。
3. 數據偏移／首部長度：代表報文段頭部的長度。因爲首部可能含有可選項內容，所以TCP報頭的長度是不肯定的，報頭不包含任何任選字段則長度爲20字節，4位首部長度字段所能表示的最大值爲1111，轉化爲10進製爲15，15*32/8 = 60，故報頭最大長度爲60字節。首部長度也叫數據偏移，是由於首部長度實際上指示了數據區在報文段中的起始偏移值。
4. 保留：爲未來定義新的用途保留，如今通常置0。
5. 控制位：URG ACK PSH RST SYN FIN，共6個，每個標誌位表示一個控制功能，0無效，1有效
   1. URG：緊急指針標誌，爲1時表示緊急指針有效，爲0則忽略緊急指針。
   2. ACK：確認序號標誌，爲1時表示確認號有效，爲0表示報文中不含確認信息，忽略確認號字段。
   3. PSH：push標誌，爲1表示是帶有push標誌的數據，指示接收方在接收到該報文段之後，應儘快將這個報文段交給應用程序，而不是在緩衝區排隊。
   4. RST：重置鏈接標誌，用於重置因爲主機崩潰或其餘緣由而出現錯誤的鏈接。或者用於拒絕非法的報文段和拒絕鏈接請求
   5. SYN：同步序號，用於創建鏈接過程，在鏈接請求中，SYN=1和ACK=0表示該數據段沒有使用捎帶的確認域，而鏈接應答捎帶一個確認，即SYN=1和ACK=1。
   6. FIN：finish標誌，用於釋放鏈接，爲1時表示發送方已經沒有數據發送了，即關閉本方數據流。
6. 窗口：滑動窗口大小，用來告知發送端接受端的緩存大小，以此控制發送端發送數據的速率，從而達到流量控制。窗口大小時一個16bit字段，於是窗口大小最大爲65535。
7. 校驗和：奇偶校驗，此校驗和是對整個的 TCP 報文段，包括 TCP 頭部和 TCP 數據，以 16 位字進行計算所得。由發送端計算和存儲，並由接收端進行驗證
8. 緊急指針：指向後面是優先數據的字節，在URG標誌設置了時纔有效。若是URG標誌沒有被設置，緊急域做爲填充。加快處理標示爲緊急的數據段。

5. TCP三次握手

三次握手:TCP是經過報文段進行通訊的，在創建TCP鏈接過程當中，須要客戶端和服務端總共發送3個報文段以確認鏈接的創建。

1. 第一次握手：Client將標誌位SYN置爲1，隨機產生一個序號（seq）J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
2. 第二次握手：Server接收到報文段，生成一個新的報文段發送給Client，新報文段中：SYN = 1，ACK = 1，序號（seq）= J+1，確認序號（ack） = k（k爲隨機生成）；Server進入SYN_RCVD狀態
3. 第三次握手：Client收到報文段，對報文段進行校驗（ACK是否爲1，ack是否爲J+1），校驗經過生成一個新的報文段發送給Server：ACK = 1，ack = K+1，此時Client進入ESTABLISHED狀態；Server對接收到的報文段校驗，校驗經過進入ESTABLISHED狀態。

6. TCP爲何是三次握手不是兩次

TCP的三次握手最主要是防止已過時的鏈接再次傳到被鏈接的主機：若是使兩次握手，有可能能第一次握手客戶端發送的報文段過了好久纔到達服務器端，此時客戶端已經不須要鏈接了，若是服務器端創建了鏈接，就會形成服務器資源的浪費

7. TCP四次揮手

因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉，上圖描述的便是如此。

1. 第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態
2. 第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
3. 第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
4. 第四次揮手:Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

8. 揮手中TCP爲何要等待終止

1. 假如 Client 最後的 ACK 報文段丟失了，這時 Server 就會從新發送 FIN+ACK 報文給 Client，若是 Client 不等待 2MSL 直接關閉鏈接，那麼 Server 就會一直處於 LAST-ACK 狀態，形成了 Server 的資源浪費。而等待 2MSL，Client 就會再次收到 Server 的 FIN+ACK 報文，而後從新給 Server 發送 ACK 報文，確保雙方都確認要關閉鏈接。
2. 假如 ACK 報文段沒有丟失，也是在網絡中滯留了，這 2MSL 的等待時間可讓滯留的報文傳到 Server，保證本鏈接持續的時間內所生產的報文都從網絡中消失，以避免影響下一次鏈接。還有若是不等待 2MSL ，報文滯留也可能致使 Server 資源浪費，緣由同 (1)。

9. 爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？

這是由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。

10. TCP流量控制：滑動窗口

1. 所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收
2. 每次Client返回的ACK都會告知Server當前Client窗口的大小，Server會根據窗口的大小來控制發送數據和向前滑動

11. TCP的擁塞控制

防止過多的數據注入到網絡中，這樣可使網絡中的路由器或鏈路不致過載。擁塞控制所要作的都有一個前提：網絡可以承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到全部的主機、路由器，以及與下降網絡傳輸性能有關的全部因素。

擁塞控制方法: 慢開始( slow-start )和擁塞避免( congestion avoidance ) 發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，而且動態地在變化。發送方讓本身的發送窗口等於擁塞窗口的大小。 發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減少一些，以減小注入到網絡中的分組數。

1. 慢開始算法：每通過一個傳輸輪次，擁塞窗口 cwnd 就加倍。慢開始的"慢"並非指cwnd的增加速率慢，而是指在TCP開始發送報文段時先設置cwnd=1，使得發送方在開始時只發送一個報文段（目的是試探一下網絡的擁塞狀況），而後再逐漸增大cwnd。 爲了防止擁塞窗口cwnd增加過大引發網絡擁塞，還須要設置一個慢開始門限ssthresh狀態變量（如何設置ssthresh）。慢開始門限ssthresh的用法以下： 當 cwnd < ssthresh 時，使用上述的慢開始算法。 當 cwnd > ssthresh 時，中止使用慢開始算法而改用擁塞避免算法。 當 cwnd = ssthresh 時，既可以使用慢開始算法，也可以使用擁塞避免算法。
2. 擁塞避免算法：讓擁塞窗口cwnd緩慢地增大，即每通過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增加，比慢開始算法的擁塞窗口增加速率緩慢得多。

不管在慢開始階段仍是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置爲出現擁塞時的發送方窗口值的一半（但不能小於2）。而後把擁塞窗口cwnd從新設置爲1，執行慢開始算法。這樣作的目的就是要迅速減小主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

快重傳算法：要求接收方每收到一個失序的報文段後就當即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時才進行捎帶確認。 快重傳算法還規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器到期。
快恢復過程 1.當發送方連續收到三個重複確認，就執行"乘法減少"算法，把慢開始門限ssthresh減半。這是爲了預防網絡發生擁塞。請注意：接下去不執行慢開始算法。 2.因爲發送方如今認爲網絡極可能沒有發生擁塞，所以與慢開始不一樣之處是如今不執行慢開始算法（即擁塞窗口cwnd如今不設置爲1），而是把cwnd值設置爲慢開始門限ssthresh減半後的數值，而後開始執行擁塞避免算法（"加法增大"），使擁塞窗口緩慢地線性增大。

12. 在瀏覽器中輸入www.baidu.com 後執行的所有過程

1. 客戶端瀏覽器請求DNS服務器解析域名www.baidu.com 對應的IP地址，而後經過這個IP地址和默認端口80，和服務器創建TCP鏈接，鏈接創建以後經過TCP將HTTP會話封裝成數據包。
2. 在客戶端的傳輸層，把HTTP會話請求分紅報文段，添加源和目的端口（如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口）而後使用IP層的IP地址查找目的端。
3. 在客戶端的網絡層，經過查找路由表肯定如何到達服務器，期間可能通過多個路由器，這些都是由路由器來完成的工做，主要是經過查找路由表來決定經過哪一個路徑到達服務器。
4. 在客戶端的鏈路層，數據包經過鏈路層發送到路由器，經過鄰居協議查找給定IP地址的MAC地址，而後發送ARP請求查找目的地址，若是獲得迴應後就可使用ARP（地址解析協議：將ip地址解析成物理地址）的請求應答交換的IP數據包如今就能夠傳輸了，而後發送IP數據包到達服務器的地址。

13. HTTP協議包括哪些請求？

經常使用的請求有：get，post，update，delete，head，options。GET：請求讀取由URL所標誌的數據 POST：給服務器添加或者更新數據 PUT：在給定的URL下存儲一個文檔 DELETE：刪除給定的URL所標誌的資源 OPTIONS：服務器針對特定資源所支持的HTTP請求方法 HEAD：向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息

HTTP中POST與GET的區別

1. GET是將請求參數加到URL中，POST是將請求數據放在請求體中。
2. GET傳送的數據量較小，不能超過2KB(1024字節?)，POST傳送的數據量較大，默認爲不受限制。

14. HTTP協議的格式

HTTP請求

1. 請求行：三個部分組成：第一部分是請求方法，第二部分是請求網址，第三部分是HTTP版本
2. 請求頭：請求頭(request header) ；普通頭(general header) ；實體頭(entity header)
3. 內容：一般來講，因爲GET請求每每不包含內容實體，所以也不會有實體頭。 第三部份內容只在POST請求中存在，由於GET請求並不包含任何實體

HTTP響應

1. 狀態行：第一部分是HTTP版本，第二部分是響應狀態碼，第三部分是狀態碼的描述
2. HTTP頭：響應頭(response header) ；普通頭(general header) ；實體頭(entity header)
3. 內容：響應內容就是HTTP請求所請求的信息。這個信息能夠是一個HTML，也能夠是一個圖片

15. HTTP緩存

####HTTP緩存的處理流程：

1. 請求處理 用戶發起一個http請求，緩存獲取到URL，根據URL查找是否有匹配的副本，這個副本可能在內存中，也可能在本地磁盤。
2. 新鮮度檢測 若是緩存中存在所請求資源的副本，則進行新鮮度檢測。新鮮度檢測舉個簡單的例子，咱們在商店買了一瓶汽水，汽水瓶上確定會標有過時時間，咱們會根據這個過時時間和如今的時間作對比，看看飲料過時了沒，若是沒過時，咱們正常喝就好了，若是已通過期，咱們確定要找商家。其實這就是一個新鮮度檢測的過程，HTTP請求的新鮮度檢測流程也是這樣的，HTTP發起一個請求時，發現緩存中有相應的副本，接着就會檢查這個副本有沒有過時，若是沒有過時，直接使用。若是已通過期，則進行再驗證。
3. 服務器再驗證 緩存中的文檔過時了並不表明它和服務器上的不同，因此這個時候就須要問問服務器，過時的這段時間裏這個文檔到底有沒有改變。若是改變了，緩存就會獲取一份新的文檔副本，而後發送給客戶端。若是沒有改變，緩存只須要獲取新的首部，包括一個新的過時時間，並對緩存中的首部更新。
4. 建立響應並返回 咱們但願緩存看起來就像是來自原始服務器同樣，緩存將已緩存的服務器響應首部做爲響應首部，發送給客戶端。

擴展（緩存保質期的實現）：HTTP中，經過Cache-Control首部和Expires首部爲文檔指定了過時時間，經過對過時時間的判斷，緩存就能夠知道文檔是否是在保質期內。Expires首部和Cache-Control:max-age 首部都是來告訴緩存文檔有沒有過時，爲何須要兩個響應首部來作這件簡單的事情了？其實這一切都是歷史緣由，Expires首部是HTTP 1.0中提出來的，由於他使用的是絕對日期，若是服務端和客戶端時鐘不一樣步的話（實際上這種狀況很是常見），緩存可能就會認爲文檔已通過了保質期。 HTTP 1.1爲了修正這個問題，引入了Cache-Control:max-age 首部，這個首部使用相對時間來控制保質期。

16. Http和Socket區別

1. Http是一個協議，Socket是一個接口
2. Http多是基於Socket的
3. Socket能夠維持一個長鏈接，http是請求響應式，一般Socket效率高

17. Http1.0 /1.1/2.0區別

1. 1.1相對於1.0：
   1. 支持長鏈接
   2. 增長了host域
   3. 增長了range頭域，支持斷點續傳
2. 2.0 相對於1.x：
   1. 支持多路複用
   2. 採用二進制分幀
   3. 首部壓縮
   4. 服務器推送

18. HTTPS

HTTPS是安全版本的HTTP，基於SSL加密。如下是SSL創建過程：

1. 客戶端給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法
2. 服務器確認雙方使用的加密方法，並給出數字證書、以及一個服務器生成的隨機數（Server random）
3. 客戶端確認數字證書有效，而後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給服務器
4. 服務器使用本身的私鑰，獲取客戶端絲髮來的隨機數（即Premaster secret）
5. 客戶端和服務器根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程

19. COOKIE和SESSION有什麼區別

1. 由於HTTP是無狀態的，因此須要某種機制識別用戶
2. Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中；
3. Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。

20. Http 狀態碼

1. 1 ：繼續
2. 2 ：成功
3. 3 ：重定向
4. 4 ：請求錯誤
5. 5： 服務器內部錯誤

21. 常見請求和響應頭

1. 請求頭：Accept/Accept—Language/Cache-Control/Cookie/User-Agent/Date/Host/Range
2. 返回頭：Accept-Ranges/Date/Cache-Control/Content-Length