Android面試中問到網路基礎，基本是圍繞OSI七層模型或者是TCP/IP四層模型展開的，主要包括各層名稱及功能、每層有哪些協議。

另外會深入考察應用層和傳輸層。

應用層：（HTTP、DNS等）
- HTTP報文格式、頭部有哪些欄位
- HTTP狀態碼
- HTTP和HTTPS的區別
- HTTPS中SSL/TLS加密的握手過程
- HTTP一次連線的具體過程
- GET、POST的區別
- DNS解析過程
- Cookie、Session原理

傳輸層：（TCP、UDP等）

• TCP/IP四層模型（和OSI的層次對應關係）
• TCP三次握手、四次握手的過程，狀態變化和原因
• TCP、UDP區別
• TCP擁控、流控原理
• Socket原理

更多Android面試相關請點選
- 四步準備Android面試
- Android開發概要
- 大疆提前批第一次電面
- 大疆提前批第二次電面
- 大疆提前批終面
- 大疆提前批終面後加面

以下是正文，其中空出的標題是我目前還沒有整理完畢，或者是整理不夠完整的內容。在對應內容完善後會進行更新。其中包括Cookie、Session原理，TCP擁控、流控原理，Socket原理。

OSI七層模型及其功能

TCP/IP 四層模型及對應協議

TCP/IP中的應用層對應OSI中的應用層、表示層、會話層，網路訪問層對應OSI中的資料鏈路層和物理層。

注：DNS作用是將域名轉為IP地址；ARP作用是將IP地址轉為MAC地址

HTTP報文格式、頭部有哪些欄位

先說一下HTTP。
HTTP：HyperText Transfer Protocol 超文字傳輸協議，處於應用層，基於請求響應模式，無狀態協議。
URL：Uniform Resource Location 統一資源定位符，就是常說的網頁地址。

HTTP報文

• 請求報文
  
  • 報文頭部
    
    • 請求行：包括請求方法型別：GET、POST等，請求地址，協議版本
    • 請求頭部欄位
    • 通用頭部欄位
    • 實體頭部欄位
    • 其他
  • 報文主體：包括如POST中的請求引數、檔案上傳資料、郵件傳輸資料等內容
• 響應報文
  
  • 報文頭部
    
    • 狀態行
    • 響應頭部欄位
    • 通用頭部欄位
    • 實體頭部欄位
    • 其他
  • 報文主體：包括網頁正文等內容

根據上述內容，HTTP頭部欄位包括：

• 請求頭部欄位：補充請求的附加內容、客戶端資訊、響應內容相關優先順序等。有Accept、From、Host等欄位
• 響應頭部欄位：補充響應的附加內容
• 通用頭部欄位：請求報文、響應報文都會使用，包括Cache-Control欄位，作用是控制HTTP快取機制
• 實體頭部欄位：補充資源內容的更新時間等

HTTP狀態碼

HTTP和HTTPS的區別

簡單來說，HTTPS是加密的HTTP。
HTTPS = HTTP + SSL/TLS

HTTPS使用SSL/TLS進行加密，這既是它的優點也是它的缺點，加密使HTTPS的安全性大大提高，但是加密的過程也導致通訊過程中效能的下降。
但總的來說用失去的一點點效能換來極高的安全性是非常值得的，蘋果和谷歌也大力支援HTTPS的使用。

HTTPS的關鍵是加密過程，見下一標題。

HTTPS中SSL/TLS加密的握手過程

以下的C代表Client客戶端，S代表Server服務端。
1. C告訴S：協議版本號，支援的加密方法，以及自己生成的隨機數
2. S確認加密方法，給C方鬆證書和自己產生的隨機數
3. C確認證書有效性，產生新的隨機數，並使用數字證書中的公鑰加密隨機數，傳送給S
4. S使用對應的私鑰解密得到C發過來的隨機數
5. C和S使用約定的加密方法，使用前面的三個隨機數，生成對話金鑰，然後用此金鑰加密接下來的整個對話過程

總的來說，整個過程就是使用非對稱加密演算法交換“對話中要使用的對稱加密演算法的金鑰”，然後使用對稱加密演算法進行對話。

注：
- 加密演算法分為兩種：對稱和非對稱。
- 對稱加密是指對話雙方使用同一金鑰進行加密和解密。特性是速度快，但存在如何安全確認金鑰的問題。
- 非對稱加密是指擁有兩個金鑰，公鑰和私鑰。公鑰加密的內容只有私鑰能夠解密，私鑰加密的內容只有公約能夠解密。C向S傳送內容時使用S的公鑰加密，這樣就只有持有對應私鑰的S能夠解密。特性是安全，但速度慢。同時存在如何證明公鑰是S的問題，因為可能有人從中間劫持，偽裝S傳送劫持人的公鑰。為了解決這個問題，引入了數字證書來保證公鑰的有效性。
- SSL/TLS結合了兩個加密演算法的優點，利用非對稱加密的安全來交換對稱加密的金鑰，然後利用對稱加密的速度快來對這個會話進行加密。

HTTP一次連線的具體過程

域名解析（DNS）——> TCP三次握手，建立連線 ——> 發起HTTP請求 ——> 伺服器響應請求，返回資料 ——> 客戶端處理資料 ——> 合適時刻四次握手，斷開連線

這裡可能會繼續追問諸如DNS解析過程、三次握手四次握手過程和原因等等問題，解答見下文

GET、POST的區別

• GET請求可以被瀏覽器快取，POST不可以
• POST安全一些，因為GET請求都在URL中，也會被瀏覽器儲存記錄；而POST請求可以放到Body中
• POST可以用RequestBody傳輸更多的資料，GET的資料量受到URL長度限制
• POST支援更多編碼，且不對資料型別限制
• GET的目標功能是查詢資料，POST的目標功能是修改資料，或者上傳資料

DNS解析過程

DNS功能是將域名解析為IP地址。

1. 查詢瀏覽器快取，是否有解析記錄，沒有則進入第二步
2. 查詢系統快取，是否有解析記錄，沒有則進入第二步
3. 給配置的DNS伺服器（LDNS）傳送請求，LDNS查詢到則返回
4. LDNS沒有找到時會請求RootServer，返回一個頂級域名伺服器
5. LDNS請求頂級域名伺服器，返回NameServer地址
6. NameServer返回IP給LDNS，LDNS會進行快取
7. LDNS返回給使用者

注：各級都會對IP的解析進行快取，同時會根據各自的快取策略對一些記錄進行清理

Cookie、Session原理

TCP三次握手、四次握手的過程，狀態變化和原因

為什麼需要三次握手建立連線？
為了防止已失效的連線請求報文段突然又傳到了服務端，服務端以為要建立連線，造成資源浪費（無效連線）。發生場景是，客戶端傳送第一個建立連線的請求由於網路原因服務端一開始沒有接收到，因此客戶端發了第二個連線請求，這個請求成功，建立起了連線。但是第一個請求後來又到達服務端，如果沒有第三次確認，服務端將多形成一個連線，造成資源浪費。

為什麼需要四次握手斷開連線？
斷開連線時，分為兩個階段。一次是客戶端通知伺服器，告知自己不會再發送資料。注意，此時伺服器仍可以發資料給客戶端。第二次是伺服器告知客戶端自己不會再發送資料。
要弄清楚的是，斷開時，任意一方都可以主動斷開，表明自己不再發送資料，但仍可接收資料。所以中間的FIN和ACK不能合併。另外每次斷開連線需要FIN請求 + ACK，所以斷開需要四次。

TIME_WAIT等待2MSL的意義？
1. 確保連線可靠關閉，防止最後一個ACK的丟失。
2. 避免套接字混淆（同一個埠對應多個socket）

注：主要目的是，對客戶端回發ACK丟失的情況做處理，可以在服務端再次傳送FIN時回發ACK。

TCP、UDP區別

TCP擁控、流控原理

Socket原理

如有任何遺漏或錯誤，請聯絡我，我會把你作為此部落格的共同作者。

版權宣告
本文首發自簡書：
搜尋作者：QinGeneral
無需授權即可轉載，甚至無需保留以上版權宣告；
轉載時請務必註明作者。