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