网络学习文档

目标：理解前端与服务器之间的“高速公路”是如何工作的，以及如何设计高效、可靠的网络通信。

核心要点（TL;DR）

分层模型降低了网络复杂度，HTTP/2 多路复用解决应用层队头阻塞，HTTP/3（QUIC）进一步解决传输层队头阻塞。
TCP 通过三次握手、四次挥手与拥塞控制保证可靠传输，UDP 轻量快速但不可靠，适合低延迟、可容忍丢包场景。
DNS 解析与 CDN 边缘节点是减少延迟的关键，静态资源应强缓存 + hash 文件名，HTML 宜用协商缓存。
HTTPS/TLS 通过证书与对称加密保护数据，TLS 1.3 显著降低握手延迟并提升安全性。
RESTful 与 GraphQL 是主流 API 设计范式，前端网络优化的核心是减少请求数、传输体积与等待时间。

学习时长与前置知识

建议学习时长：2-3 周（每周投入 6-8 小时）
前置知识：Web 基础概念、HTTP 初步了解

一、网络模型：分层是为了降低复杂度

网络通信非常复杂，分层模型把大问题拆成小问题，每层只关心自己的职责。

1.1 OSI 七层模型

物理层：比特流传输（网线、光纤、无线信号）。
数据链路层：MAC 地址、帧传输、局域网通信。
网络层：IP 地址、路由选择、跨网络通信。
传输层：端到端通信，TCP/UDP。
会话层：建立、管理、终止会话。
表示层：数据格式转换、加密、压缩。
应用层：用户直接接触，HTTP、FTP、SMTP 等。

1.2 TCP/IP 四层模型

更贴近实际网络实现：

网络接口层：对应 OSI 物理层 + 数据链路层。
网络层（IP 层）：IP、ICMP、路由。
传输层：TCP、UDP。
应用层：HTTP、DNS、FTP 等（对应 OSI 上三层）。

生活化比喻：寄快递。应用层是写快递单的内容；传输层是保证包裹完整送达的物流公司；网络层是选择路线和门牌号（IP）；数据链路层是同城配送；物理层是货车和飞机。

二、HTTP 协议：Web 的“通用语言”

2.1 HTTP/1.1

持久连接：默认 Connection: keep-alive，一个 TCP 连接可发送多个请求。
管道化（Pipelining）：允许连续发送多个请求，但响应必须按顺序返回，存在队头阻塞问题。
缓存控制：Cache-Control、ETag、Last-Modified。
Host 头：支持同一 IP 上的多个虚拟主机。

2.2 HTTP/2

二进制分帧：把请求/响应拆成帧，多路复用。
多路复用（Multiplexing）：一个 TCP 连接上并行传输多个请求，解决队头阻塞。
头部压缩（HPACK）：减少重复头部传输。
服务器推送：服务器可主动推送资源（如 CSS/JS）。

HTTP/2 解决了 HTTP 层的队头阻塞，但 TCP 层的队头阻塞仍然存在。

2.3 HTTP/3

基于 QUIC 协议：QUIC 基于 UDP，内置 TLS 1.3。
连接迁移：通过连接 ID 标识连接，网络切换（如 WiFi 切 4G）不断连。
更低的握手延迟：0-RTT 或 1-RTT。
彻底解决队头阻塞：基于 UDP 的独立流。

2.4 对比总结

特性	HTTP/1.1	HTTP/2	HTTP/3
传输层	TCP	TCP	UDP (QUIC)
多路复用	无（管道化不完善）	有	有
头部压缩	无	HPACK	QPACK
队头阻塞	严重	HTTP 层解决，TCP 层仍存在	基本解决
连接建立	TCP + TLS 多次握手	TCP + TLS	QUIC 合并

三、TCP：可靠传输的“快递员”

3.1 TCP 三次握手

建立连接时，客户端和服务器交换三个包：

SYN：客户端发送 SYN，进入 SYN_SENT。
SYN + ACK：服务器收到 SYN，回复 SYN+ACK，进入 SYN_RCVD。
ACK：客户端收到 SYN+ACK，回复 ACK，双方进入 ESTABLISHED。

为什么不是两次？为了防止已失效的连接请求突然到达服务器造成错误，同时确认双方收发能力正常。

3.2 TCP 四次挥手

断开连接时：

FIN：主动方发送 FIN，表示不再发送数据。
ACK：被动方确认 FIN。
FIN：被动方也发送 FIN。
ACK：主动方确认 FIN，进入 TIME_WAIT 后关闭。

四次挥手是因为 TCP 是全双工的，双方都需要单独关闭自己的发送通道。

3.3 TCP 可靠传输机制

序列号与确认应答：确保数据按序到达。
超时重传：未收到 ACK 则重发。
滑动窗口：提高传输效率。
流量控制：根据接收方处理能力调整发送速度。
拥塞控制：根据网络状况调整发送速度（慢启动、拥塞避免、快重传、快恢复）。

四、UDP：轻量快速的“明信片”

UDP 是无连接、不可靠的协议：

不保证到达、不保证顺序、不重传。
头部开销小，延迟低。
适用场景：视频直播、在线游戏、DNS、QUIC。

五、DNS 解析：域名到 IP 的“电话簿”

5.1 DNS 查询过程

浏览器缓存。
操作系统缓存。
本地 DNS 服务器（通常是路由器或 ISP）。
递归查询根域名服务器 → 顶级域名服务器 → 权威域名服务器。

5.2 DNS 记录类型

A 记录：域名 → IPv4 地址。
AAAA 记录：域名 → IPv6 地址。
CNAME：域名 → 另一个域名。
MX：邮件服务器。
NS：指定域名服务器。
TXT：文本记录，常用于验证和 SPF。

5.3 DNS 优化

DNS 预解析：<link rel="dns-prefetch" href="//cdn.example.com">。
减少域名数量：降低 DNS 查询次数。
DNS 缓存：合理设置 TTL。

六、CDN：内容分发的“本地仓库”

6.1 CDN 原理

CDN（内容分发网络）把网站内容缓存到全球各地的边缘节点，用户从最近的节点获取资源。

工作流程：

用户请求资源。
DNS 解析到最近的 CDN 边缘节点。
边缘节点有缓存则直接返回；没有则回源站获取并缓存。

6.2 CDN 优势

降低延迟，提高访问速度。
分担源站压力。
提高可用性和抗 DDoS 能力。

6.3 前端使用 CDN 的注意事项

静态资源加版本号或 hash，便于缓存更新。
配置 CORS，允许跨域加载字体等资源。
对第三方 CDN 资源做 SRI（子资源完整性）校验。

七、WebSocket：全双工实时通信

7.1 为什么需要 WebSocket

HTTP 是请求-响应模式，服务器不能主动推送。WebSocket 提供全双工、长连接通道。

7.2 握手过程

客户端发送 HTTP 升级请求，带 Upgrade: websocket 和 Connection: Upgrade。
服务器返回 101 Switching Protocols，连接升级为 WebSocket。

7.3 应用场景

即时通讯、在线客服。
股票行情、游戏同步。
协同编辑、实时通知。

const ws = new WebSocket("wss://example.com/socket");
ws.onopen = () => ws.send("hello");
ws.onmessage = (e) => console.log(e.data);

八、RESTful 设计：资源的“命名艺术”

RESTful 是一种基于 HTTP 的 API 设计风格，核心是资源。

8.1 设计原则

用 URL 表示资源：/users、/users/123。
用 HTTP 方法表示操作：
- GET：查询
- POST：创建
- PUT/PATCH：更新
- DELETE：删除
使用状态码表达结果：200、201、204、400、401、403、404、500 等。
无状态：每个请求包含完整信息，服务器不保存客户端状态。

8.2 示例

GET    /users          # 获取用户列表
GET    /users/123      # 获取用户 123
POST   /users          # 创建用户
PUT    /users/123      # 全量更新用户 123
PATCH  /users/123      # 部分更新用户 123
DELETE /users/123      # 删除用户 123

九、GraphQL：一种查询语言

9.1 GraphQL 与 REST 的区别

REST：每个端点返回固定结构，可能需要多次请求。
GraphQL：一个端点，客户端指定所需字段，一次请求获取精确数据。

9.2 GraphQL 核心概念

Schema：定义 API 的数据结构。
Query：查询数据。
Mutation：修改数据。
Subscription：订阅实时数据。

graphql

query {
  user(id: 1) {
    name
    email
  }
}

9.3 优缺点

优点：减少过度获取和不足获取、强类型 Schema、聚合多个数据源。缺点：增加服务器复杂度、缓存不如 REST 成熟、文件上传需额外处理。

十、网络安全传输：HTTPS/TLS

10.1 HTTPS 是什么

HTTPS = HTTP + TLS（旧称 SSL），在 HTTP 之下加入加密层，保护数据传输安全。

10.2 TLS 握手过程

简化版：

客户端发送 Client Hello，包含支持的加密套件、随机数。
服务器返回 Server Hello、证书、随机数。
客户端验证证书，生成预主密钥，用公钥加密发送。
双方生成会话密钥。
后续通信使用会话密钥对称加密。

10.3 TLS 1.3 改进

握手步骤更少，延迟更低。
移除过时加密算法，更安全。
支持 0-RTT 恢复会话。

十一、DoH / DoT：加密的 DNS 查询

11.1 为什么 DNS 也需要加密？

传统 DNS 查询是明文的，任何人（包括运营商、公共 Wi-Fi 运营者、中间人攻击者）都能看到你在访问哪些域名。DoH（DNS over HTTPS）和 DoT（DNS over TLS）通过加密 DNS 查询，保护用户隐私并防止 DNS 劫持。

生活化比喻：传统 DNS 像在公共场所大声报出你要去的地址；DoH/DoT 像把地址写在密封信封里交给邮差。

11.2 DoH vs DoT

特性	DoH（DNS over HTTPS）	DoT（DNS over TLS）
传输协议	HTTPS（端口 443）	TLS（端口 853）
伪装性	流量看起来像普通 HTTPS，易被放行	独立端口，可能被防火墙拦截
部署复杂度	依赖现有 HTTP/2 基础设施	需要独立端口和配置
隐私保护	强	强
主流支持	Chrome、Firefox、Edge 支持	主要在某些系统和路由器支持

11.3 前端如何感知 DoH？

普通前端开发者通常不需要直接操作 DoH，但浏览器和操作系统 increasingly 默认使用 DoH。前端可以：

检查页面是否通过 HTTPS 加载，确保 DNS 查询可被加密。
使用 DNS 预解析时，依赖浏览器的 DoH 策略。
在测试环境中通过 Chrome 的 chrome://settings/security 配置安全 DNS。

// 浏览器支持检测（实验性）
if ("resolve" in navigator) {
  // 某些浏览器提供 DNS 解析 API
}

11.4 部署建议

企业内网可通过 DNS-over-HTTPS 服务（如 Cloudflare 1.1.1.1、Google 8.8.8.8）提升隐私。
前端性能优化中，DNS 解析仍是关键路径，DoH 的额外 TLS 握手可能轻微增加首次查询延迟，但可通过缓存和连接复用缓解。

十二、WebRTC：浏览器内的实时音视频

12.1 什么是 WebRTC？

WebRTC（Web Real-Time Communication）是一组允许浏览器和移动应用进行实时音视频通信、P2P 数据交换的开放标准。它无需安装插件，就能实现视频会议、屏幕共享、文件传输、低延迟游戏同步等功能。

生活化比喻：WebRTC 像一部内置在手机里的对讲机，不需要拨号到中心交换机，两台设备可以直接通话。

12.2 WebRTC 核心组件

组件	作用
getUserMedia	获取摄像头、麦克风媒体流
RTCPeerConnection	建立 P2P 连接，处理音视频编解码、网络穿透
RTCDataChannel	在 P2P 连接上传输任意数据
ICE / STUN / TURN	解决 NAT 穿透，让不同内网设备找到对方

12.3 基本流程

// 1. 获取本地媒体流
const localStream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true
});
localVideo.srcObject = localStream;

// 2. 创建 RTCPeerConnection
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

// 3. 添加本地轨道
localStream.getTracks().forEach((track) => {
  pc.addTrack(track, localStream);
});

// 4. 处理远端流
pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

// 5. 通过信令服务器交换 SDP 和 ICE candidate（省略信令细节）

12.4 WebRTC 的挑战

NAT 穿透：复杂网络环境下需要 STUN/TURN 服务器中继。
信令服务器：WebRTC 只负责媒体传输，建立连接前的 SDP 交换需要额外实现。
编解码兼容性：不同浏览器支持的 codec 不同。
QoS 与拥塞控制：实时媒体对网络抖动敏感。

十三、HTTP 状态码真实场景

13.1 2xx 成功系列

状态码	含义	真实场景
200 OK	请求成功	GET 用户详情返回 JSON
201 Created	资源创建成功	POST 创建订单后返回新订单
204 No Content	成功但无返回体	DELETE 删除评论
206 Partial Content	分片内容	视频断点续传、大文件分片下载

13.2 3xx 重定向系列

状态码	含义	真实场景
301 Moved Permanently	永久重定向	网站换域名，SEO 权重转移
302 Found	临时重定向	未登录用户跳转登录页
304 Not Modified	协商缓存命中	静态资源未变更，浏览器用本地缓存

13.3 4xx 客户端错误系列

状态码	含义	真实场景
400 Bad Request	请求参数错误	表单校验失败、JSON 格式错误
401 Unauthorized	未认证	Token 过期、未登录
403 Forbidden	无权限	普通用户访问管理员接口
404 Not Found	资源不存在	商品已下架、URL 拼写错误
409 Conflict	资源冲突	并发修改导致版本冲突
429 Too Many Requests	限流	接口调用频率过高

13.4 5xx 服务端错误系列

状态码	含义	真实场景
500 Internal Server Error	服务端内部错误	代码异常、数据库连接失败
502 Bad Gateway	网关错误	Nginx upstream 无响应
503 Service Unavailable	服务不可用	服务器过载、维护中
504 Gateway Timeout	网关超时	后端处理时间过长

13.5 状态码使用最佳实践

不要所有错误都返回 200，然后靠 body 里的 code 区分。
401 和 403 要区分清楚：401 是“不知道你是谁”，403 是“知道你是谁但你不允许”。
429 应配合 Retry-After 响应头，告诉客户端多久后再试。
500 系列错误不应把敏感堆栈信息暴露给前端。

十四、前端网络优化

14.1 减少请求数量

合并 JS/CSS（权衡缓存）。
使用 CSS Sprites（现代已较少使用）。
使用图标字体或 SVG Symbol。

14.2 减少传输体积

开启 Gzip/Brotli 压缩。
图片使用 WebP/AVIF。
代码压缩、Tree Shaking。

14.3 提高传输效率

使用 HTTP/2 或 HTTP/3。
启用 keep-alive。
使用 CDN。
合理设置缓存策略。

14.4 减少等待时间

DNS 预解析、预连接、预加载。
服务端渲染或静态生成。
接口聚合，减少串行请求。

总结

网络是前端与后端、用户与服务的桥梁。理解 OSI/TCP-IP 模型、HTTP 各版本特性、TCP/UDP 差异、DNS/CDN 原理、WebSocket、WebRTC、DoH/DoT 以及 RESTful/GraphQL 设计，能帮助你构建更快、更可靠、更安全的 Web 应用。掌握 HTTP 状态码的真实场景，能让你在前后端协作中更准确地定位问题和设计 API。

延伸阅读：

《HTTP 权威指南》
《图解 HTTP》
IETF RFC 文档
Web.dev 网络优化指南
WebRTC 官方文档

领域编号：F04 计算机网络
最后更新：2026-06-24

本领域学习进度

学习进度0 / 43 （0%）

网络学习文档 ​

核心要点（TL;DR） ​

学习时长与前置知识 ​

一、网络模型：分层是为了降低复杂度 ​

1.1 OSI 七层模型 ​

1.2 TCP/IP 四层模型 ​

二、HTTP 协议：Web 的“通用语言” ​

2.1 HTTP/1.1 ​

2.2 HTTP/2 ​

2.3 HTTP/3 ​

2.4 对比总结 ​

三、TCP：可靠传输的“快递员” ​

3.1 TCP 三次握手 ​

3.2 TCP 四次挥手 ​

3.3 TCP 可靠传输机制 ​

四、UDP：轻量快速的“明信片” ​

五、DNS 解析：域名到 IP 的“电话簿” ​

5.1 DNS 查询过程 ​

5.2 DNS 记录类型 ​

5.3 DNS 优化 ​

六、CDN：内容分发的“本地仓库” ​

6.1 CDN 原理 ​

6.2 CDN 优势 ​

6.3 前端使用 CDN 的注意事项 ​

七、WebSocket：全双工实时通信 ​

7.1 为什么需要 WebSocket ​

7.2 握手过程 ​

7.3 应用场景 ​

八、RESTful 设计：资源的“命名艺术” ​

8.1 设计原则 ​

8.2 示例 ​

九、GraphQL：一种查询语言 ​

9.1 GraphQL 与 REST 的区别 ​

9.2 GraphQL 核心概念 ​

9.3 优缺点 ​

十、网络安全传输：HTTPS/TLS ​

10.1 HTTPS 是什么 ​

10.2 TLS 握手过程 ​

10.3 TLS 1.3 改进 ​

十一、DoH / DoT：加密的 DNS 查询 ​

11.1 为什么 DNS 也需要加密？ ​

11.2 DoH vs DoT ​

11.3 前端如何感知 DoH？ ​

11.4 部署建议 ​

十二、WebRTC：浏览器内的实时音视频 ​

12.1 什么是 WebRTC？ ​

12.2 WebRTC 核心组件 ​

12.3 基本流程 ​

12.4 WebRTC 的挑战 ​

十三、HTTP 状态码真实场景 ​

13.1 2xx 成功系列 ​

13.2 3xx 重定向系列 ​

13.3 4xx 客户端错误系列 ​

13.4 5xx 服务端错误系列 ​

13.5 状态码使用最佳实践 ​

十四、前端网络优化 ​

14.1 减少请求数量 ​

14.2 减少传输体积 ​

14.3 提高传输效率 ​

14.4 减少等待时间 ​

总结 ​

本领域学习进度 ​