Android第三次面试总结之网络篇补充
一、网络模型: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加密流程与证书校验└─ 网络优化方案设计