一、網絡模型：OSI 七層 vs TCP/IP 四層（必考點）

1. 分層模型對比

OSI 七層模型	TCP/IP 四層模型	核心功能	Android 相關場景
應用層（7 層）	應用層	定義數據格式（HTTP/HTTPS/FTP/API）	OkHttp/Retrofit 封裝的網絡請求（如 JSON 解析、Header 處理）
表示層（6 層）	-	數據加密、壓縮（TLS/SSL 屬于此層）	HTTPS 通信時的證書校驗、數據加密（Android 需處理 SSL Pinning）
會話層（5 層）	-	建立 / 管理會話（如 TCP 連接狀態）	TCP 長連接保持（如 HTTP 1.1 的Connection: keep-alive）
傳輸層（4 層）	傳輸層	端到端通信（TCP/UDP）	網絡請求底層選擇（TCP 用于可靠傳輸如接口調用，UDP 用于實時通信如 VoIP）
網絡層（3 層）	網絡層	路由尋址（IP 協議、ARP 協議）	IP 地址獲取（WifiManager.getDhcpInfo()）、子網劃分
數據鏈路層（2 層）	數據鏈路層	MAC 尋址、差錯校驗（以太網協議）	Wi-Fi / 藍牙的 MAC 地址識別（getMacAddress()在 Android 6.0 + 需權限）
物理層（1 層）	物理層	二進制數據傳輸（光纖 / 電磁波）	網絡類型判斷（Wi-Fi/4G / 藍牙，ConnectivityManager）

2. 面試題：為什么網絡要分層設計？

• 答：解耦復雜度（每層專注單一功能）、標準化接口（跨平臺兼容）、便于故障定位（如 HTTP 404 定位到應用層問題）。
• Android 實例：OkHttp 底層用 Socket（傳輸層），上層封裝 HTTP（應用層），分層設計讓開發者無需關心 TCP 握手細節。

二、核心協議深度解析（高頻考點）

1. 傳輸層：TCP vs UDP（必問）

特性	TCP	UDP	Android 典型場景
連接方式	面向連接（三次握手 / 四次揮手）	無連接（即發即棄）	TCP：接口請求、文件下載；UDP：視頻通話、IM 心跳包
可靠性	可靠（確認應答、重傳機制）	不可靠（無重傳，需上層處理）	TCP 通過HttpURLConnection實現重試策略
傳輸效率	低（額外控制報文）	高（無額外開銷）	UDP 適合實時性要求高的場景（如直播推流）
流量控制	滑動窗口、擁塞控制	無	TCP 擁塞控制影響網絡優化（如慢啟動算法）

經典問題：

• 三次握手過程

  1. 客戶端發 SYN 包（SEQ=x，請求連接），進入 SYN_SENT；
  2. 服務端回復 SYN+ACK（SEQ=y，ACK=x+1），進入 SYN_RCVD；
  3. 客戶端回復 ACK（ACK=y+1），進入 ESTABLISHED。
     為什么是三次？?兩次無法確認雙方收發能力（如服務端 ACK 丟失時客戶端無法知曉）。

• 四次揮手原因：
  服務端收到 FIN 后，可能仍有數據未發完，需先 ACK 確認，待數據發完再發 FIN，故 ACK 和 FIN 分開發送（兩次揮手）。

2. 應用層：HTTP/HTTPS（核心考點）

（1）HTTP 1.1 vs 2.0 vs 3.0（QUIC）

特性	1.1	2.0（基于 SPDY）	3.0（QUIC，基于 UDP）
連接方式	短連接（默認）/ 長連接	長連接（強制）	無連接（基于 UDP，0RTT 建連）
多路復用	管道化（有隊頭阻塞）	二進制分幀（無阻塞）	多路復用 + 流量控制
頭部壓縮	無（明文）	HPACK 算法	類似 2.0，但基于 UDP 更高效
Android 支持	全版本	OkHttp 3.0 + 支持	Android 10 + 部分支持

（2）HTTPS 加密原理（面試必問）

• 兩次加密結合：
  1. 非對稱加密（TLS 握手階段）：客戶端用服務端公鑰加密隨機生成的對稱密鑰（如 AES）；
  2. 對稱加密（數據傳輸階段）：用上述對稱密鑰加密實際數據（效率高）。
• 證書校驗流程：
  客戶端驗證證書鏈（根證書→中間證書→服務器證書），防止中間人攻擊（Android 可通過SSLSocketFactory自定義校驗）。

（3）HTTP 狀態碼（實戰考點）

• 301/302：永久 / 臨時重定向，Android 中 OkHttp 默認跟隨重定向（可通過followRedirects()禁用）；
• 401/403：認證失敗 / 權限不足，需處理 Token 刷新（如 Interceptor 中捕獲后重新登錄）；
• 500 系列：服務端錯誤，需實現重試機制（結合 Retrofit 的RetryCallAdapter）。

3. 網絡層：IP/ARP 協議（易忽略但重要）

• IP 地址 vs MAC 地址：
  • IP（網絡層）：邏輯地址，動態分配（如 DHCP 獲取），用于跨子網尋址；
  • MAC（數據鏈路層）：物理地址，固化在網卡，用于局域網內尋址。
• ARP 協議：通過 IP 地址獲取 MAC 地址（如 Android 設備連接 Wi-Fi 時，用 ARP 解析路由器 MAC）。

三、Android 網絡開發深度結合（面試重點）

1. 網絡庫底層原理（OkHttp 為例）

• 攔截器鏈：RealInterceptorChain按順序執行RetryAndFollowUpInterceptor（重試）→BridgeInterceptor（處理 Header/Cookie）→CacheInterceptor（緩存策略）→ConnectInterceptor（建立 TCP 連接）→ 網絡請求。
• Connection Pool：復用 TCP 連接（默認保持 5 分鐘，最多 5 個空閑連接），減少三次握手開銷。

2. 網絡優化實戰（面試高頻）

• 緩存策略：
  • 強制緩存（Cache-Control: max-age）：直接讀本地，不發請求；
  • 協商緩存（ETag/Last-Modified）：發請求驗證，304 狀態碼返回緩存；
  • OkHttp 集成Cache（需配置CacheInterceptor）。
• 流量壓縮：GZip/Brotli 壓縮請求 / 響應體（OkHttp 默認支持，需在 Header 加Accept-Encoding: gzip）。
• 避免隊頭阻塞：HTTP 2.0 多路復用（OkHttp 默認開啟），或拆分為多個獨立接口。

3. 網絡安全（必問）

• SSL Pinning：在 Android 中固定服務端證書，防止中間人攻擊（通過CertificatePinner實現）；
• HTTPS 雙向認證：客戶端也需提供證書（如企業內網 API），通過KeyStore加載客戶端證書。

4. 系統級網絡管理

• 網絡類型檢測：ConnectivityManager.getNetworkInfo()判斷 Wi-Fi / 移動網絡，Android 10 + 推薦用NetworkCapabilities（區分 5G/4G）；
• 后臺網絡限制：Android 9 + 的Background Execution Limits，需用WorkManager/JobScheduler處理后臺網絡任務。

四、面試真題與進階思考

1. 經典問題：TCP 如何保證可靠性？

• 答：序列號（標識數據順序）、確認應答（ACK 機制）、超時重傳（RTO 動態計算）、流量控制（滑動窗口）、擁塞控制（慢啟動→擁塞避免→快重傳→快恢復）。
• Android 關聯：OkHttp 的RetryAndFollowUpInterceptor實現超時重傳，需注意 TCP 重傳與應用層重試的區別（避免重復提交）。

2. 難題：HTTPS 握手過程中，客戶端如何驗證證書？

• 答：
  1. 檢查證書有效期、主機名是否匹配；
  2. 用根證書（系統內置或自定義）解密證書簽名，對比簽名哈希值；
  3. 遞歸驗證證書鏈直到根證書（Android 中可通過X509TrustManager自定義校驗邏輯）。

3. 開放題：如何設計一個高可用的 Android 網絡請求庫？

• 思路：
  • 分層設計：底層用 OkHttp/Socket，中層封裝重試、緩存、序列化（如 Gson/Moshi），上層提供響應式接口（協程 / RxJava）；
  • 容錯機制：超時重試、網絡切換重試（如從 4G 切 Wi-Fi 時重新請求）、熔斷機制（多次失敗后暫時拒絕請求）；
  • 性能優化：HTTP 2.0 支持、連接池復用、流量壓縮、按需選擇 TCP/UDP（如文件上傳用 TCP，實時日志用 UDP）。

4.描述一次完整的 HTTP 請求流程（結合 Android）

• 流程步驟：

  1. DNS 解析：客戶端通過 DNS 服務器將域名（如www.example.com）解析為 IP 地址（需處理緩存和超時）。
  2. TCP 連接建立：三次握手建立可靠連接（SYN→SYN+ACK→ACK），Android 中通過Socket或 OkHttp 實現。
  3. 數據傳輸：
     • 應用層：構造 HTTP 請求（如GET /api/data HTTP/1.1），通過 OkHttp/Retrofit 發送。
     • 傳輸層：TCP 分段傳輸，Android 中需處理超時重傳（OkHttp 默認超時 10 秒）。
     • 網絡層：IP 路由選擇，Android 通過ConnectivityManager獲取網絡類型（WiFi / 移動網絡）。
  4. 響應處理：服務器返回 HTTP 響應（如200 OK），客戶端解析 JSON/XML 數據（使用 Gson/Moshi）。
  5. 連接關閉：四次揮手斷開 TCP 連接，Android 中需注意Socket及時關閉避免泄漏。

• 面試陷阱：

  • 若 DNS 解析失敗，Android 會拋出UnknownHostException，需在try-catch中處理。
  • TCP 連接復用（HTTP Keep-Alive）可減少三次握手開銷，OkHttp 默認開啟連接池。

知識擴展

TCP 可靠傳輸機制（面試高頻原理題）

• 序列號與確認應答：如何通過 seq/ack 確保數據按序到達？
• 重傳機制：超時重傳（RTO 動態計算）、快速重傳（三次冗余 ACK 觸發）的區別。
• 滑動窗口：流量控制的核心，窗口大小動態調整，與 SACK（選擇性確認）的結合優化。
• 擁塞控制：慢啟動（cwnd 指數增長）→擁塞避免（線性增長）→快恢復（ssthresh 調整）的完整流程，Android 網絡請求庫（如 OkHttp）如何實現擁塞控制。

UDP 與 Android 實時通信

1.?UDP 特性與不可靠性解決方案

• 優點：無連接、低延遲、適合實時場景（如視頻通話、IM 消息）；
• 缺點：丟包、無序、無流量控制，需應用層實現：
  • 序列號 + ACK 確認機制（類似簡化版 TCP）；
  • 重傳策略（超時重傳 + 最大重傳次數限制）；
  • 擁塞控制（如 Google 的 CongeSTion Control for UDP）。
• Android 中的 UDP 使用：DatagramSocket的阻塞模式處理（需子線程），分片問題（MTU 通常 1500 字節，超過需手動分片重組）。

2.?UDP vs TCP 應用場景對比

• 必問面試題：“為什么 DNS 用 UDP？”（響應快，容忍偶爾丟包，可重試）；“微信視頻通話用什么協議？”（UDP 為主，結合 NAT 穿透與 FEC 前向糾錯）。

面試問題：

TCP 為什么是可靠的？UDP 如何實現可靠傳輸？

答：TCP 通過序列號、確認應答、重傳、滑動窗口、擁塞控制實現可靠；UDP 需在應用層添加 ACK 機制、重傳策略、流量控制（如 GTP-U 協議在 5G 中的應用）。

HTTPS 比 HTTP 慢的原因？如何優化？

答：慢在 TLS 握手（1-RTT 或 2-RTT）、加密計算；優化手段：啟用 HTTP3.0（0-RTT）、會話重用（Session ID/Session Ticket）、壓縮證書（OCSP Stapling）。

核心知識點腦圖

網絡模型與協議
├─ 分層模型（OSI/TCP/IP）
│  ├─ 各層職責與Android對應場景
│  └─ 分層設計優勢（解耦/標準化）
├─ 核心協議
│  ├─ 傳輸層（TCP三次握手/四次揮手，UDP應用場景）
│  ├─ 應用層（HTTP/HTTPS原理，版本區別，狀態碼處理）
│  └─ 網絡層（IP/ARP，MAC與IP區別）
├─ Android實戰
│  ├─ 網絡庫原理（OkHttp攔截器、連接池）
│  ├─ 優化（緩存、壓縮、多路復用）
│  └─ 安全與系統適配（證書校驗、后臺限制）
└─ 面試高頻題├─ TCP可靠性/UDP優缺點├─ HTTPS加密流程與證書校驗└─ 網絡優化方案設計