一、网络模型：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 拥塞控制影响网络优化（如慢启动算法） |
经典问题：
-
三次握手过程
- 客户端发 SYN 包（SEQ=x，请求连接），进入 SYN_SENT；
- 服务端回复 SYN+ACK（SEQ=y，ACK=x+1），进入 SYN_RCVD；
- 客户端回复 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 加密原理（面试必问）
- 两次加密结合 ：
- 非对称加密（TLS 握手阶段）：客户端用服务端公钥加密随机生成的对称密钥（如 AES）；
- 对称加密（数据传输阶段）：用上述对称密钥加密实际数据（效率高）。
- 证书校验流程 ：
客户端验证证书链（根证书→中间证书→服务器证书），防止中间人攻击（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 握手过程中，客户端如何验证证书？
- 答 ：
- 检查证书有效期、主机名是否匹配；
- 用根证书（系统内置或自定义）解密证书签名，对比签名哈希值；
- 递归验证证书链直到根证书（Android 中可通过
X509TrustManager自定义校验逻辑）。
3. 开放题：如何设计一个高可用的 Android 网络请求库？
- 思路 ：
- 分层设计：底层用 OkHttp/Socket，中层封装重试、缓存、序列化（如 Gson/Moshi），上层提供响应式接口（协程 / RxJava）；
- 容错机制：超时重试、网络切换重试（如从 4G 切 Wi-Fi 时重新请求）、熔断机制（多次失败后暂时拒绝请求）；
- 性能优化：HTTP 2.0 支持、连接池复用、流量压缩、按需选择 TCP/UDP（如文件上传用 TCP，实时日志用 UDP）。
4.描述一次完整的 HTTP 请求流程（结合 Android）
-
流程步骤：
- DNS 解析 ：客户端通过 DNS 服务器将域名（如
www.example.com）解析为 IP 地址（需处理缓存和超时）。 - TCP 连接建立 ：三次握手建立可靠连接（SYN→SYN+ACK→ACK），Android 中通过
Socket或 OkHttp 实现。 - 数据传输 ：
- 应用层 ：构造 HTTP 请求（如
GET /api/data HTTP/1.1），通过 OkHttp/Retrofit 发送。 - 传输层：TCP 分段传输，Android 中需处理超时重传（OkHttp 默认超时 10 秒）。
- 网络层 ：IP 路由选择，Android 通过
ConnectivityManager获取网络类型（WiFi / 移动网络）。
- 应用层 ：构造 HTTP 请求（如
- 响应处理 ：服务器返回 HTTP 响应（如
200 OK），客户端解析 JSON/XML 数据（使用 Gson/Moshi）。 - 连接关闭 ：四次挥手断开 TCP 连接，Android 中需注意
Socket及时关闭避免泄漏。
- DNS 解析 ：客户端通过 DNS 服务器将域名（如
-
面试陷阱：
- 若 DNS 解析失败，Android 会抛出
UnknownHostException，需在try-catch中处理。 - TCP 连接复用（HTTP Keep-Alive）可减少三次握手开销，OkHttp 默认开启连接池。
- 若 DNS 解析失败，Android 会抛出
知识扩展
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加密流程与证书校验
└─ 网络优化方案设计