Android面試之網路

一隻有交流障礙的醜程式猿發表於2018-04-02
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報文段進行傳輸，報文段分為頭部和資料兩個部分，頭部包含了此報文段的一些基本資訊，基本格式如下圖。

Android面試之網路

  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三次握手

Android面試之網路

三次握手: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四次揮手

Android面試之網路

由於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快取

Android面試之網路
####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

相關文章