一、网络模型：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加密流程与证书校验
   └─ 网络优化方案设计