网络（一）：体系结构、TCP/UDP 与基础协议
导语：网络面试的第一梯队永远是「分层模型 + TCP/UDP + 一次完整请求」。本篇先把 OSI/TCP-IP 分层与各层职责打牢，再讲清 TCP 与 UDP 的本质差异，然后串起「输入 URL 到页面渲染」这条贯穿全场的链路，最后补齐 DNS、ARP/ICMP、Socket 与连接标识、最大连接数、CDN 这些常作追问的基础协议，共 10 题。
一、分层模型与协议栈
1. OSI 七层与 TCP/IP 四层（五层）的对应关系？为什么实际用 TCP/IP？
答：
各层一句话职责：
| 层 | 职责 | 数据单位 | 关键点 |
|---|---|---|---|
| 应用层 | 定义业务语义（怎么请求、怎么响应） | 报文（Message） | HTTP/DNS 在这一层 |
| 传输层 | 端到端（进程到进程）通信、可靠性与复用 | 报文段（Segment）/ 用户数据报 | 端口号在这一层；TCP/UDP/QUIC |
| 网络层 | 主机到主机寻址与路由（跨网络转发） | 数据包（Packet） | IP 地址在这一层；只负责"尽力而为" |
| 数据链路层 | 同一链路内相邻节点的帧传输与差错检测 | 帧（Frame） | MAC 地址在这一层；交换机工作在此 |
| 物理层 | 比特流的传输（电/光信号） | 比特（Bit） | 网卡、线缆 |
为什么实际用 TCP/IP 而不是 OSI：
- OSI 是"先有标准后有实现"，实现复杂、层次划分过细（会话/表示层职责重叠），落地成本高；
- TCP/IP 是"先有实现后有标准"（ARPANET 实践），简单、开放、免费，且有可用的代码与生态；
- OSI 仍有价值：它的分层思想是教学与排障的标准语言——面试说「这是第几层的问题」时，用的就是 OSI 的层号。
分层带来的工程价值（面试要点）：
- 解耦：每层只依赖下层的接口，HTTP 换版本不影响 IP；
- 排障定位：从物理层往上逐层排除（插拔网线 → ping 通不通 → 端口通不通 → HTTP 返回什么）；
- 封装与解封装：发送时逐层加头（Application Data → +TCP 头 → +IP 头 → +帧头），接收时逐层剥离，每层只关心自己的头。
2. TCP 与 UDP 的区别？各自适用什么场景？
答：
| 维度 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（需三次握手、四次挥手） | 无连接（直接发） |
| 可靠性 | 可靠：确认、重传、按序、去重 | 不可靠：尽最大努力交付，不保证到达与顺序 |
| 传输单位 | 面向字节流（无消息边界，可能粘包/拆包） | 面向数据报（保留消息边界，一次发一次收） |
| 流量/拥塞控制 | 有（滑动窗口 + 拥塞控制） | 无（会"欺负"TCP） |
| 首部开销 | 20~60 字节 | 8 字节 |
| 通信模式 | 一对一（单播） | 一对一、一对多（组播/广播） |
| 传输速度 | 相对慢（握手、重传、拥塞收缩） | 快 |
| 有序性 | 保证按序交付 | 不保证 |
| 头部字段 | seq/ack/窗口/标志位/选项 | 源端口、目的端口、长度、校验和 |
适用场景：
| 协议 | 适用 | 例子 |
|---|---|---|
| TCP | 要求可靠、有序、数据完整 | HTTP/HTTPS（1.1/2）、文件传输、数据库连接、RPC、SSH |
| UDP | 实时性优先、可容忍少量丢包，或需要组播/广播 | 视频会议/直播、VoIP、DNS 查询、游戏帧同步、DHCP、SNMP、HTTP/3（QUIC） |
三个高频追问：
「UDP 会不会丢包？丢了怎么办？」 → 会丢。丢包处理不在 UDP 层，要么应用层自己实现（序号 + 确认 + 重传 + 拥塞控制），要么接受丢失（音视频用丢帧/FEC 冗余）。QUIC 就是"在 UDP 上重做了一套可靠传输"。
「为什么 DNS 用 UDP？」 → 查询报文小、请求响应简单，UDP 省掉握手（1 RTT 变 0 RTT），且应用层自带重试；但响应超过 UDP 报文限制时（如区域传送 AXFR、大响应）会改用 TCP。
「为什么说 UDP 更"公平"？」 → TCP 有拥塞控制会退让，UDP 不会——所以「UDP 一多，TCP 就被挤」是真实存在的现象，这也是为什么 HTTP/3（QUIC）虽基于 UDP，但必须自己在用户态实现拥塞控制才敢大规模用。
一句话记忆：TCP 是"打电话"（先接通、确认对方听懂、顺序不乱），UDP 是"寄明信片"（直接投递、可能丢、不管顺序）。
二、全链路请求过程
3. 浏览器输入 www.taobao.com 到页面显示，经历了哪些过程？
答： 这是网络面试的第一大题，建议按"六大阶段"讲成一条完整故事线：
可以主动补充的三个"加分点"：
| 加分点 | 说明 |
|---|---|
| 每一步的"缓存" | DNS 缓存、ARP 缓存、TCP/TLS 会话复用、HTTP 缓存（强缓存命中就不发请求了）、浏览器内存/磁盘缓存 |
| 可能被问的变体 | 「为什么有的请求没走 DNS」（缓存/连接复用）、「HTTP/2 下还会开多个连接吗」（一般不会，但受同源限制影响）、「如果 ping 不通但网页能开」（可能被 ICMP 限速/禁 Ping，不代表 HTTP 不通） |
| 对照排障 | 若卡在某一阶段，对应的排查手段不同：nslookup/dig（DNS）、ping/traceroute（网络层）、telnet ip port/nc -vz（TCP 层）、curl -v/浏览器 Network 面板（HTTP/TLS 层） |
4. DNS 解析的完整过程是什么？递归与迭代查询有什么区别？
答： DNS 是分布式 + 层次化的域名系统，默认基于 UDP 53。
递归 vs 迭代（高频区分）：
| 方式 | 谁在问 | 特点 |
|---|---|---|
| 递归查询 | 客户端 → 本地 DNS | 客户端只发一次请求，本地 DNS 负责问到底并给出最终结果（"你帮我搞定"） |
| 迭代查询 | 本地 DNS → 根/TLD/权威 | 每次只返回下一步该问谁，由本地 DNS 一步步追问（"去找他"） |
必须知道的三点修正与补充：
- 「DNS 只用 UDP」是不准确的：UDP 报文默认限 512 字节，但 EDNS0 扩展可协商到 1232 字节以上；响应过大、区域传送（AXFR/IXFR）时使用 TCP；现代还有 DoT（DNS over TLS，853 端口）与 DoH（DNS over HTTPS，443） 用于加密防窃听与防劫持；
- DNS 劫持与污染：本地 DNS 被篡改可返回错误 IP → 这是 DoH/DoT 出现的原因之一；
- DNS 也能做负载均衡：一个域名可配多个 A 记录，本地 DNS 轮转返回；结合地理/运营商调度就是 GSLB（CDN 的核心之一，见第 10 题）。
排查命令：dig www.taobao.com +trace（看完整迭代过程）、nslookup、dig @8.8.8.8 xxx（指定 DNS）、dig -x ip（反查 PTR）。
三、基础协议与寻址
5. ARP、ICMP 的作用？ping 与 traceroute 的原理是什么？
答：
ARP（地址解析协议）——"同网段内 IP → MAC"
为什么需要 ARP：IP 是网络层的逻辑地址，MAC 是链路层的物理地址，跨网段转发时每一跳都要重新封装帧头，所以每一跳都需要"下一跳 IP → 下一跳 MAC"的映射。
反向的 RARP（MAC → IP）已基本被 DHCP 取代。相关的还有 ARP 欺骗（伪造 ARP 响应做中间人），防御靠静态 ARP 绑定、DAI 等。
ICMP——网络层的"差错与控制报文"
| 类型 | 用途 |
|---|---|
| Echo Request / Reply（类型 8/0） | ping 的原理 |
| Destination Unreachable（类型 3） | 目标不可达（含"需要分片但 DF 置位"，用于 PMTUD） |
| Time Exceeded（类型 11） | TTL 耗尽，traceroute 的基础 |
ping 原理：发送 ICMP Echo Request，对端回 Echo Reply，据此测连通性与往返时延（RTT）。
易错点：ping 不走 TCP/UDP 端口，所以「TCP 端口不通但 ping 得通」是完全可能的（说明网络层可达、应用没监听或被防火墙拦了）。反之，ping 不通也不代表服务不可用（很多服务器禁 ICMP 或被安全组丢弃）。
traceroute 原理（高频追问）：
6. TCP 首部有哪些关键字段？选项字段有什么用？
答： TCP 首部固定 20 字节 + 选项（最多 40 字节）= 最长 60 字节。
| 字段 | 作用 | 面试要点 |
|---|---|---|
| 源/目的端口（16 位） | 标识进程，实现多路复用/多路分解 | 端口范围 0~65535，65535 个端口就是"客户端并发上限"的来源之一（配合 IP 才是四元组） |
| seq（32 位） | 本报文段数据第一个字节的编号 | 初始序号 ISN 是随机生成的（防旧连接与预测攻击） |
| ack（32 位） | 期望收到的下一个字节序号 = 已收最大序号 + 1 | 累计确认（确认"到此为止都收到了"） |
| 窗口 rwnd（16 位） | 接收方剩余接收缓冲大小 | 流量控制；16 位不够用时靠窗口扩大选项 |
| 标志位 | URG/ACK/PSH/RST/SYN/FIN | RST 是"复位"（异常关闭/端口未监听）；PSH 表示"尽快交给应用" |
| 校验和 | 端到端差错检测 | 伪首部 + 首部 + 数据 |
四个重点选项字段（写出来就显专业）：
| 选项 | 作用 |
|---|---|
| MSS（最大报文段长度） | 握手时协商「本端能接收的最大 TCP 数据长度」，避免 IP 分片（见《网络（二）》） |
| 窗口扩大因子（Window Scale） | 把 16 位窗口放大到最多 2³⁰，高带宽长肥管道（BDP 大）必需 |
| SACK（选择确认） | 告诉发送方「我收到了哪些不连续的段」，避免"一个段丢了把后面全重传" |
| 时间戳（Timestamps） | 更精确的 RTT 测量（RTTM）+ PAWS 防序号回绕；也是 tcp_tw_reuse 生效的前提 |
7. 什么是 Socket？一条 TCP 连接是如何被唯一标识的？
答：
Socket（套接字）是"应用进程与传输层协议之间的编程接口"——它把「IP + 端口 + 协议」抽象成一个可读写的文件描述符，让应用用 read/write 就能收发网络数据。
一条连接由「四元组」唯一标识：
关键理解：同一时刻，服务端可以有几万条连接来自同一个客户端？
可以，只要源端口不同。 所以「一台客户端最多能连同一个服务端的连接数 ≈ 客户端可用端口数（约 6.4 万）」（同 IP 场景），而服务端可同时接受的连接总数不受端口限制（只受 fd/内存/CPU 限制，见第 8 题）。
Socket 编程的典型流程（对照三次握手）：
高频易错点：
accept()返回的是一个新的 socket fd，监听 fd 继续负责接收新连接。若服务端只listen不accept，连接会堆在全连接队列里，队列满后新连接被丢（见《网络（二）》）。
四、连接规模与内容分发
8. 一台服务端最多能支撑多少 TCP 连接？实际受哪些限制？
答：
理论上限：服务端在固定 (服务端 IP, 服务端端口) 上监听，连接由四元组唯一标识。客户端侧可变的只有源 IP（2³²）与源端口（2¹⁶）：
理论最大并发连接数 ≈ 2³²（客户端 IP 数）× 2¹⁶（客户端端口数）≈ 2⁴⁸但现实远达不到，真正的瓶颈是这四个：
| 限制 | 说明 | 调优手段 |
|---|---|---|
| 文件描述符上限 | 每条连接一个 fd | 进程级 ulimit -n（可用 prlimit 动态调）、系统级 fs.file-max |
| 内核内存 | 每连接要占接收/发送缓冲区 + socket 结构体（几 KB~几百 KB） | 调 tcp_rmem/tcp_wmem（注意不要在 socket 上硬设 SO_RCVBUF，会关闭动态调整）、tcp_mem |
| CPU 与上下文切换 | 高并发下软中断 + 系统调用开销剧增 | 多路复用（epoll）、多队列网卡 + RPS/RFS、SO_REUSEPORT 多进程分担 |
| 应用层模型 | 每连接一线程会在几万连接时崩 | 用 epoll + Reactor、协程/虚拟线程（见《网络（四）》） |
单机百万连接的关键词（面试常问）：
反面案例提醒：TIME_WAIT 堆积通常出现在客户端侧（主动关闭方）或短连接代理上，而不是"服务端连接数不够"——不要混淆（见《网络（二）》）。
9. 常见应用层协议及其默认端口？各层还有哪些典型协议？
答： 面试偶尔会直接问端口，记住高频的即可：
| 端口 | 协议 | 说明 |
|---|---|---|
| 20/21 | FTP | 20 数据、21 控制（主动/被动模式是经典考点） |
| 22 | SSH / SFTP | 远程登录与安全文件传输 |
| 23 | Telnet | 明文，已淘汰（不要用于生产） |
| 25 / 465 / 587 | SMTP | 邮件发送（465/587 为加密端口） |
| 53 | DNS | UDP 为主，TCP 备用；853 为 DoT，443 为 DoH |
| 80 / 443 | HTTP / HTTPS | 最常用 |
| 110 / 143 / 993 / 995 | POP3 / IMAP | 邮件接收（993/995 加密） |
| 123 | NTP | 时间同步（UDP） |
| 161/162 | SNMP | 网络管理（UDP） |
| 3306 / 5432 / 6379 / 27017 | MySQL / PostgreSQL / Redis / MongoDB | 数据库 |
| 5672 / 9092 / 2181 / 8848 | RabbitMQ / Kafka / ZooKeeper / Nacos | 中间件与注册中心 |
| 9200 / 9300 | Elasticsearch | REST / 节点间通信 |
| 2375/2376/6443 | Docker / K8s | 容器与集群 API |
各层典型协议速查（回答"这一层有哪些协议"时用）：
| 层 | 协议 |
|---|---|
| 应用层 | HTTP/HTTPS、DNS、FTP、SMTP/POP3/IMAP、SSH、Telnet、SNMP、DHCP、WebSocket、gRPC |
| 传输层 | TCP、UDP、QUIC、SCTP |
| 网络层 | IPv4/IPv6、ICMP、ICMPv6、ARP（有争议，常归链路层）、OSPF、BGP、GRE、IPsec |
| 数据链路层 | 以太网（Ethernet）、PPP、VLAN（802.1Q）、STP、ARP |
| 物理层 | 双绞线、光纤、Wi-Fi(802.11 物理层部分) |
10. CDN 的原理是什么？如何实现就近访问？
答： CDN（内容分发网络）本质是"用 DNS + 边缘节点把内容推到离用户最近的地方"。
CDN 的四个核心机制：
| 机制 | 说明 |
|---|---|
| DNS 调度 | 用 CNAME + GSLB 做就近接入（最主流的接入方式） |
| 缓存分层 | 边缘节点 → 中间层节点 → 源站，逐层回源降低源站压力；靠 Cache-Control/Expires 与刷新/预热接口控制 |
| 内容刷新 | 主动 purge（删除缓存）与 prefetch（预热热点内容），解决"发布后用户还看到旧图" |
| 动态加速 | 非缓存类（API 请求）走最优路径路由（专线/长连接复用）降低 RTT |
CDN 与 HTTP 缓存的联动（容易被追问）：
- CDN 节点自身就是一个"共享缓存"：它严格遵守你设置的
Cache-Control: max-age、s-maxage（专对共享缓存）、private（private的响应 CDN 不会缓存）； - 所以「为什么加了 CDN 后发布静态资源要改文件名？」→ 因为强缓存没过期，用户/CDN 都不会去取新文件，只能靠内容哈希文件名（
app.a1b2c3.js）做"以变更为单位的缓存失效"。
相关追问：
- 「CDN 回源失败用户会看到什么？」 → 边缘节点无法取到内容，通常返回 502/504 或 CDN 厂商自定义错误页；
- 「HTTPS 下 CDN 怎么工作？」 → 需要把证书部署到 CDN（或 CDN 提供证书），形成"用户 ↔ CDN ↔ 源站"两段加密，运维要关注证书过期与私钥托管安全。
下一篇：《网络（二）》进入 TCP 的核心地带——三次握手/四次挥手的细节与状态机、TIME_WAIT 与 CLOSE_WAIT、可靠传输的四大机制、拥塞控制从 Reno 到 CUBIC/BBR 的演进、滑动窗口与零窗口、粘包拆包、半连接/全连接队列与 SYN Flood、Keepalive、超时重传与 MTU/MSS。