一、网络分层模型
1. OSI 七层模型
| 层级 |
名称 |
功能 |
典型协议 |
| 7 |
应用层 |
为应用程序提供网络服务 |
HTTP、FTP、SMTP、DNS |
| 6 |
表示层 |
数据格式转换、加密压缩 |
SSL/TLS、JPEG |
| 5 |
会话层 |
建立、管理、终止会话 |
RPC、Socket |
| 4 |
传输层 |
端到端可靠传输 |
TCP、UDP |
| 3 |
网络层 |
路由选择、逻辑寻址 |
IP、ICMP |
| 2 |
数据链路层 |
物理寻址、帧封装 |
Ethernet、PPP |
| 1 |
物理层 |
比特流传输 |
电信号、光信号 |
2. TCP/IP 四层模型
code
┌─────────────────────────────────────┐│ 应用层(HTTP/FTP/DNS/SMTP) │ ← 对应 OSI 5/6/7├─────────────────────────────────────┤│ 传输层(TCP/UDP) │ ← 对应 OSI 4├─────────────────────────────────────┤│ 网络层(IP/ICMP) │ ← 对应 OSI 3├─────────────────────────────────────┤│ 网络接口层(Ethernet/Wi-Fi) │ ← 对应 OSI 1/2└─────────────────────────────────────┘
3. 数据封装过程
文本
应用层数据 (Data) │ + TCP头 ▼传输层 (Segment 段) │ + IP头 ▼网络层 (Packet 包) │ + 帧头/帧尾 ▼数据链路层 (Frame 帧) │ ▼物理层 (Bit 比特流)
二、TCP 与 UDP
1. TCP 与 UDP 对比
| 特性 |
TCP |
UDP |
| 连接方式 |
面向连接 |
无连接 |
| 可靠性 |
可靠传输 |
不可靠 |
| 传输顺序 |
有序 |
无序 |
| 速度 |
较慢 |
快 |
| 头部开销 |
20 字节 |
8 字节 |
| 流量/拥塞控制 |
有 |
无 |
| 应用场景 |
HTTP、FTP、邮件 |
DNS、视频、游戏 |
2. TCP 三次握手
文本
客户端 服务端 │ │ │ ── SYN (seq=x) ──────────────►│ 第1次:客户端发起连接请求 │ │ │◄──────── SYN+ACK (seq=y,ack=x+1) ── 第2次:服务端确认并发起同步 │ │ │ ── ACK (ack=y+1) ────────────►│ 第3次:客户端确认连接建立 │ │ │ ◄════ 连接建立,开始传输 ════► │
为什么是三次?
- 两次握手无法防止已失效的连接请求到达服务端,导致资源浪费
- 三次握手能确认双方都有发送和接收能力
3. TCP 四次挥手
文本
客户端 服务端 │ │ │ ── FIN (seq=u) ──────────────►│ 第1次:客户端请求断开 │ │ │◄──────── ACK (ack=u+1) ────── 第2次:服务端确认收到 │ (服务端可能还有数据要发) │ │◄──────── FIN (seq=v) ──────── 第3次:服务端请求断开 │ │ │ ── ACK (ack=v+1) ────────────►│ 第4次:客户端确认断开 │ │ │ 等待 2MSL 后关闭 │
为什么挥手是四次?
- TCP 是全双工,关闭需要双方各自独立关闭发送通道
- 服务端收到 FIN 后可能还有数据未发完,所以 ACK 和 FIN 分开发送
4. TCP 可靠性机制
- 序列号与确认号:保证数据有序、不丢失
- 超时重传:发送后未收到 ACK 则重传
- 滑动窗口:流量控制,接收方告知发送方能接收的数据量
- 拥塞控制:慢启动、拥塞避免、快重传、快恢复
三、HTTP 协议基础
1. HTTP 简介
- 超文本传输协议(HyperText Transfer Protocol)
- 基于 TCP/IP 的应用层协议,默认端口 80
- 无状态协议(每次请求相互独立)
- 请求-响应模型
2. HTTP 请求结构
code
POST /api/user HTTP/1.1 ← 请求行:方法 路径 版本Host: www.example.com ← 请求头Content-Type: application/jsonContent-Length: 35Authorization: Bearer xxx {"name":"张三","age":20} ← 请求体
3. HTTP 响应结构
code
HTTP/1.1 200 OK ← 状态行:版本 状态码 状态描述Content-Type: application/json ← 响应头Content-Length: 28Date: Wed, 05 Aug 2026 10:00:00 GMT {"code":0,"msg":"success"} ← 响应体
4. HTTP 请求方法
| 方法 |
功能 |
幂等 |
安全 |
| GET |
获取资源 |
是 |
是 |
| POST |
创建资源 |
否 |
否 |
| PUT |
完整更新资源 |
是 |
否 |
| PATCH |
部分更新资源 |
否 |
否 |
| DELETE |
删除资源 |
是 |
否 |
| HEAD |
获取响应头 |
是 |
是 |
| OPTIONS |
预检请求(CORS) |
是 |
是 |
5. HTTP 状态码
| 分类 |
含义 |
| 1xx |
信息性状态码 |
| 2xx |
成功 |
| 3xx |
重定向 |
| 4xx |
客户端错误 |
| 5xx |
服务端错误 |
常见状态码:
| 状态码 |
含义 |
说明 |
| 200 |
OK |
请求成功 |
| 201 |
Created |
资源创建成功 |
| 204 |
No Content |
成功但无内容返回 |
| 301 |
Moved Permanently |
永久重定向 |
| 302 |
Found |
临时重定向 |
| 304 |
Not Modified |
资源未修改,用缓存 |
| 400 |
Bad Request |
请求参数错误 |
| 401 |
Unauthorized |
未认证 |
| 403 |
Forbidden |
无权限访问 |
| 404 |
Not Found |
资源不存在 |
| 405 |
Method Not Allowed |
方法不允许 |
| 500 |
Internal Server Error |
服务端错误 |
| 502 |
Bad Gateway |
网关错误 |
| 503 |
Service Unavailable |
服务不可用 |
| 504 |
Gateway Timeout |
网关超时 |
6. 常见请求头
| 请求头 |
说明 |
| Host |
目标主机域名 |
| User-Agent |
客户端信息 |
| Accept |
可接受的内容类型 |
| Content-Type |
请求体类型 |
| Content-Length |
请求体长度 |
| Authorization |
认证信息 |
| Cookie |
携带的 Cookie |
| Referer |
来源页面 |
| Origin |
请求来源(CORS) |
| If-Modified-Since |
缓存校验 |
7. 常见 Content-Type
| 值 |
说明 |
| text/html |
HTML 文档 |
| application/json |
JSON 数据 |
| application/x-www-form-urlencoded |
表单数据 |
| multipart/form-data |
文件上传 |
| text/plain |
纯文本 |
| application/xml |
XML 数据 |
四、HTTP 版本演进
1. 各版本对比
| 版本 |
特性 |
传输方式 |
| HTTP/1.0 |
每次请求新建连接 |
短连接 |
| HTTP/1.1 |
持久连接、管道化、缓存控制 |
长连接 |
| HTTP/2 |
多路复用、头部压缩、服务端推送 |
二进制分帧 |
| HTTP/3 |
基于 QUIC(UDP)、解决队头阻塞 |
UDP |
2. HTTP/1.1 关键特性
- 持久连接(Keep-Alive):一个 TCP 连接可发多个请求
- 管道化:可连续发送请求不等响应(但响应需按序)
- Host 头:支持虚拟主机
- 缓存控制:Cache-Control、ETag
3. HTTP/2 改进
文本
HTTP/1.1:串行请求(队头阻塞)请求1 ──► 响应1 ──► 请求2 ──► 响应2HTTP/2:多路复用(一个连接并行多个请求)请求1 ┐请求2 ├─► 并行响应请求3 ┘
- 二进制分帧:数据分成更小的帧传输
- 头部压缩(HPACK):减少头部开销
- 服务端推送:主动推送资源到客户端
4. HTTP/3 特点
- 基于 QUIC 协议(UDP 之上)
- 解决 TCP 层的队头阻塞
- 连接迁移(网络切换不断连)
- 更快的连接建立(0-RTT)
五、HTTPS 与 TLS
1. HTTPS 简介
- HTTP Secure = HTTP + SSL/TLS
- 默认端口 443
- 提供加密、认证、完整性保护
2. HTTPS 的作用
- 加密:防止数据被窃听
- 认证:确认服务器身份(证书)
- 完整性:防止数据被篡改
3. TLS 握手过程(简版)
文本
客户端 服务端 │ │ │ ──── Client Hello ─────────────────► │ 1. 支持的TLS版本、加密套件、随机数 │ │ │ ◄──────── Server Hello ───────────── │ 2. 选定套件、随机数 │ ◄──────── Certificate ────────────── │ 发送数字证书 │ ◄──────── Server Hello Done ──────── │ │ │ │ ──── 生成 Pre-Master Secret ────► │ 3. 用公钥加密 Pre-Master Secret │ ──── Change Cipher Spec ────────► │ │ ──── Finished ──────────────────► │ │ │ │ ◄════ 双方用三个随机数生成会话密钥 ══► │ 4. 对称加密通信
4. 对称加密 vs 非对称加密
| 类型 |
特点 |
速度 |
应用 |
| 对称加密 |
加解密用同一密钥 |
快 |
大量数据传输 |
| 非对称加密 |
公钥加密、私钥解密 |
慢 |
密钥交换、数字签名 |
HTTPS 混合加密:握手阶段用非对称加密交换密钥,通信阶段用对称加密传输数据。
5. 数字证书
- 由 CA(证书颁发机构)签发
- 包含:域名、公钥、颁发机构、有效期、数字签名
- 浏览器校验证书链,确认服务器身份
六、Cookie、Session 与 Token
1. 三者对比
| 特性 |
Cookie |
Session |
Token |
| 存储位置 |
客户端 |
服务端 |
客户端 |
| 安全性 |
较低 |
较高 |
高 |
| 大小限制 |
约 4KB |
无限制 |
无限制 |
| 跨域支持 |
不支持 |
不支持 |
支持 |
| 服务端压力 |
小 |
大 |
小 |
2. Cookie 属性
| 属性 |
说明 |
| Name/Value |
键值对 |
| Domain |
生效域名 |
| Path |
生效路径 |
| Expires/Max-Age |
过期时间 |
| HttpOnly |
禁止 JS 访问(防 XSS) |
| Secure |
仅 HTTPS 传输 |
| SameSite |
跨站限制(防 CSRF) |
3. JWT(JSON Web Token)
code
Header.Payload.SignatureeyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoxMjN9.签名
- Header:算法类型
- Payload:用户信息(不要放敏感数据)
- Signature:用密钥对前两部分签名
优点:无状态、可扩展、跨域支持
缺点:无法主动失效、载荷不宜过大
七、跨域与 CORS
1. 同源策略
- 同源 = 协议 + 域名 + 端口完全相同
- 浏览器限制跨源请求,保护用户安全
2. CORS(跨域资源共享)
简单请求(满足以下条件):
- 方法为 GET、HEAD、POST
- Content-Type 仅为三种:
text/plain、application/x-www-form-urlencoded、multipart/form-data
- 不含自定义头
文本
请求:直接发送,带 Origin 头响应:服务端返回 Access-Control-Allow-Origin
预检请求(非简单请求):
文本
┌──────────┐ ┌──────────┐│ 浏览器 │ │ 服务端 │└────┬─────┘ └────┬─────┘ │ │ │ ── OPTIONS 预检请求 ──────────► │ │ ◄── 返回允许的方法和头 ──────── │ │ │ │ ── 正式请求 ──────────────────► │ │ ◄── 正式响应 ────────────────── │
3. 常见 CORS 响应头
| 响应头 |
说明 |
| Access-Control-Allow-Origin |
允许的源 |
| Access-Control-Allow-Methods |
允许的方法 |
| Access-Control-Allow-Headers |
允许的请求头 |
| Access-Control-Allow-Credentials |
允许携带 Cookie |
| Access-Control-Max-Age |
预检缓存时间 |
4. 其他跨域方案
- JSONP:利用
<script> 标签,仅支持 GET
- 代理服务器:前端请求同源代理,代理转发到目标服务
- Nginx 反向代理:服务端配置代理转发
八、WebSocket
1. WebSocket 简介
- 全双工通信协议
- 基于 HTTP 升级(Upgrade: websocket)
- 持久连接,服务端可主动推送
2. HTTP vs WebSocket
| 特性 |
HTTP |
WebSocket |
| 通信方式 |
请求-响应 |
全双工 |
| 连接 |
短连接/长连接 |
持久连接 |
| 服务端推送 |
不支持 |
支持 |
| 协议头开销 |
大 |
小 |
| 适用场景 |
普通请求 |
实时通信 |
3. 握手过程
code
客户端请求:GET /chat HTTP/1.1Upgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==服务端响应:HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
九、RESTful API 设计
1. REST 核心原则
- 资源导向:URL 表示资源
- 统一接口:用 HTTP 方法表示操作
- 无状态:每次请求包含全部信息
- 分层架构:客户端不感知中间层
2. URL 设计规范
文本
GET /api/users # 获取用户列表GET /api/users/123 # 获取单个用户POST /api/users # 创建用户PUT /api/users/123 # 更新用户(全量)PATCH /api/users/123 # 更新用户(部分)DELETE /api/users/123 # 删除用户GET /api/users/123/orders # 获取用户的订单
3. 设计要点
- URL 使用名词,复数形式
- 用 HTTP 方法表示操作类型
- 用状态码表示结果
- 版本管理:
/api/v1/users
- 过滤、排序、分页用查询参数:
/api/users?page=1&size=20&sort=name
十、常见面试题
1. 浏览器输入 URL 到页面显示的过程
文本
1. DNS 解析:域名 → IP 地址2. TCP 三次握手:建立连接3. TLS 握手(HTTPS)4. 发送 HTTP 请求5. 服务端处理并返回响应6. 浏览器解析 HTML7. 构建 DOM 树和 CSSOM 树8. 生成渲染树、布局、绘制9. 执行 JS、加载资源
2. GET 和 POST 的区别
| 区别点 |
GET |
POST |
| 参数位置 |
URL 查询字符串 |
请求体 |
| 长度限制 |
浏览器有限制 |
理论无限制 |
| 缓存 |
可被缓存 |
不缓存 |
| 幂等性 |
幂等 |
非幂等 |
| 安全性 |
参数暴露在 URL |
相对安全 |
| 历史记录 |
可收藏/回退 |
不可 |
3. HTTP 长连接和短连接
- 短连接(HTTP/1.0):每次请求建立新 TCP 连接,完成后关闭
- 长连接(HTTP/1.1):Connection: keep-alive,复用 TCP 连接
- 长连接减少握手开销,提升性能
4. 什么是跨域?如何解决?
- 同源策略限制不同源的请求
- 解决方案:CORS、JSONP、代理服务器、Nginx 反向代理
5. HTTP 和 HTTPS 的区别
| 区别点 |
HTTP |
HTTPS |
| 端口 |
80 |
443 |
| 加密 |
无 |
SSL/TLS 加密 |
| 证书 |
不需要 |
需要 CA 证书 |
| 性能 |
快 |
略慢(握手开销) |
| 安全性 |
低 |
高 |
6. 301 和 302 的区别
- 301:永久重定向,浏览器会缓存,下次直接访问新地址
- 302:临时重定向,每次仍请求原地址
7. 常见 Web 安全问题
| 安全问题 |
说明 |
防御手段 |
| XSS |
跨站脚本攻击 |
输入过滤、HttpOnly Cookie、CSP |
| CSRF |
跨站请求伪造 |
Token、SameSite Cookie、Referer 校验 |
| SQL 注入 |
恶意 SQL 拼接 |
参数化查询、ORM |
| 点击劫持 |
透明 iframe 诱骗点击 |
X-Frame-Options |
| 中间人攻击 |
窃听篡改通信 |
HTTPS、证书校验 |
8. Token 和 Session 的区别
- Session:服务端存储,靠 Cookie 的 sessionId 关联,有状态
- Token:客户端存储,自带用户信息,无状态,天然支持分布式
9. TCP 粘包怎么解决?
- 原因:TCP 是流式协议,无消息边界
- 解决:
- 固定长度消息
- 特殊分隔符(如
\r\n)
- 消息头包含长度字段(最常用)
10. 一次完整的 HTTP 请求过程
文本
1. DNS 解析获取 IP2. TCP 三次握手3. (HTTPS)TLS 握手4. 客户端发送 HTTP 请求5. 服务端接收并处理请求6. 服务端返回 HTTP 响应7. 客户端接收响应8. (非 keep-alive)TCP 四次挥手9. 浏览器渲染页面
十一、网络分层记忆口诀
文本
OSI 七层(从下到上):物 数 网 传 会 表 应(物 理 → 数据链路 → 网络 → 传输 → 会话 → 表示 → 应用)记忆:物数网传会表应"网管传表会应" —— 网管传递报表会回应
本文档涵盖网络分层模型、TCP/UDP、HTTP 协议、HTTPS/TLS、Cookie/Session/Token、CORS、WebSocket、RESTful API 及常见面试题,适用于前后端开发与面试复习。