🔗
网络
7 道题目
难度筛选：
HTTP：明文传输，端口 80
HTTPS：HTTP + TLS/SSL 加密，端口 443
HTTPS 的优势：
1. 数据加密 — 防止窃听
2. 身份验证 — 防止伪装
3. 数据完整性 — 防止篡改
TLS 握手流程：
1. 客户端发送支持的加密套件列表
2. 服务端返回证书和选定的加密套件
3. 客户端验证证书有效性
4. 双方协商生成对称密钥
5. 后续通信使用对称加密
性能：HTTPS 有 TLS 握手开销，但 HTTP/2 和 TLS 1.3 已大幅优化。
HTTPS：HTTP + TLS/SSL 加密，端口 443
HTTPS 的优势：
1. 数据加密 — 防止窃听
2. 身份验证 — 防止伪装
3. 数据完整性 — 防止篡改
TLS 握手流程：
1. 客户端发送支持的加密套件列表
2. 服务端返回证书和选定的加密套件
3. 客户端验证证书有效性
4. 双方协商生成对称密钥
5. 后续通信使用对称加密
性能：HTTPS 有 TLS 握手开销，但 HTTP/2 和 TLS 1.3 已大幅优化。
查看答案即标记为已答
三次握手（建立连接）：
1. 客户端 → SYN → 服务端（"我要连接"）
2. 服务端 → SYN+ACK → 客户端（"收到，我也准备好了"）
3. 客户端 → ACK → 服务端（"确认，开始通信"）
为什么是三次？确保双方都能收发，防止历史连接请求导致资源浪费。
四次挥手（断开连接）：
1. 主动方 → FIN → 被动方（"我没有数据了"）
2. 被动方 → ACK → 主动方（"收到了"）
3. 被动方 → FIN → 主动方（"我也没有数据了"）
4. 主动方 → ACK → 被动方（"收到，再见"）
为什么是四次？被动方收到 FIN 后可能还有数据要发，所以 ACK 和 FIN 分开。
1. 客户端 → SYN → 服务端（"我要连接"）
2. 服务端 → SYN+ACK → 客户端（"收到，我也准备好了"）
3. 客户端 → ACK → 服务端（"确认，开始通信"）
为什么是三次？确保双方都能收发，防止历史连接请求导致资源浪费。
四次挥手（断开连接）：
1. 主动方 → FIN → 被动方（"我没有数据了"）
2. 被动方 → ACK → 主动方（"收到了"）
3. 被动方 → FIN → 主动方（"我也没有数据了"）
4. 主动方 → ACK → 被动方（"收到，再见"）
为什么是四次？被动方收到 FIN 后可能还有数据要发，所以 ACK 和 FIN 分开。
查看答案即标记为已答
HTTP/1.1：
• 文本协议
• 队头阻塞（一个 TCP 连接同时只处理一个请求）
• 需要多个 TCP 连接并行请求
HTTP/2：
• 二进制分帧
• 多路复用（一个连接并行多个请求）
• Header 压缩（HPACK）
• 服务端推送
• 仍有 TCP 层队头阻塞
HTTP/3：
• 基于 QUIC（UDP）
• 解决 TCP 队头阻塞
• 0-RTT 连接建立
• 内置 TLS 1.3
• 连接迁移（网络切换不断开）
• 文本协议
• 队头阻塞（一个 TCP 连接同时只处理一个请求）
• 需要多个 TCP 连接并行请求
HTTP/2：
• 二进制分帧
• 多路复用（一个连接并行多个请求）
• Header 压缩（HPACK）
• 服务端推送
• 仍有 TCP 层队头阻塞
HTTP/3：
• 基于 QUIC（UDP）
• 解决 TCP 队头阻塞
• 0-RTT 连接建立
• 内置 TLS 1.3
• 连接迁移（网络切换不断开）
查看答案即标记为已答
| GET | POST | |
|---|---|---|
| 语义 | 获取资源 | 提交数据 |
| 参数位置 | URL 查询字符串 | 请求体 |
| 缓存 | 可被缓存 | 默认不缓存 |
| 长度限制 | 浏览器有限制（~2KB） | 无限制 |
| 安全性 | 参数暴露在 URL | 相对安全 |
| 幂等性 | 幂等 | 非幂等 |
| 历史记录 | 保留在浏览器历史 | 不保留 |
误区：GET 和 POST 本质都是 TCP 连接，技术上 GET 也可以有 body，POST 也可以有 URL 参数。区别主要是语义和浏览器实现。
查看答案即标记为已答
HTTP：请求-响应模式，单向，每次请求需要建立连接（HTTP/1.1 可复用）
WebSocket：
• 全双工通信，服务端可主动推送
• 只需一次握手（通过 HTTP Upgrade 升级）
• 持久连接，低延迟
• 支持文本和二进制数据
建立过程：
1. 客户端发送 HTTP 请求，携带
2. 服务端返回 101 Switching Protocols
3. 连接升级为 WebSocket
适用场景：实时聊天、在线游戏、股票行情、协同编辑。
WebSocket：
• 全双工通信，服务端可主动推送
• 只需一次握手（通过 HTTP Upgrade 升级）
• 持久连接，低延迟
• 支持文本和二进制数据
建立过程：
1. 客户端发送 HTTP 请求，携带
Upgrade: websocket2. 服务端返回 101 Switching Protocols
3. 连接升级为 WebSocket
适用场景：实时聊天、在线游戏、股票行情、协同编辑。
查看答案即标记为已答
CDN（Content Delivery Network，内容分发网络）是一组分布在不同地理位置的服务器节点。
工作原理：
1. 用户请求资源时，DNS 解析将域名指向最近的 CDN 节点
2. CDN 节点检查是否有缓存
3. 有缓存：直接返回（命中）
4. 无缓存：向源站请求，缓存后返回给用户（回源）
核心优势：
• 降低延迟 — 就近访问
• 减轻源站压力 — 缓存命中
• 高可用 — 多节点冗余
• 安全 — DDoS 防护、WAF
适用资源：静态文件（JS/CSS/图片/视频）、API 加速。
工作原理：
1. 用户请求资源时，DNS 解析将域名指向最近的 CDN 节点
2. CDN 节点检查是否有缓存
3. 有缓存：直接返回（命中）
4. 无缓存：向源站请求，缓存后返回给用户（回源）
核心优势：
• 降低延迟 — 就近访问
• 减轻源站压力 — 缓存命中
• 高可用 — 多节点冗余
• 安全 — DDoS 防护、WAF
适用资源：静态文件（JS/CSS/图片/视频）、API 加速。
查看答案即标记为已答
CSRF（Cross-Site Request Forgery，跨站请求伪造）：利用用户已登录的身份，在用户不知情的情况下发送恶意请求。
攻击流程：
1. 用户登录银行网站，获得 Cookie
2. 用户访问恶意网站
3. 恶意网站自动向银行发送转账请求（自动携带 Cookie）
防御措施：
1. CSRF Token：服务端生成随机 token，请求时验证
2. SameSite Cookie：
3. 验证 Referer/Origin：检查请求来源
4. 双重 Cookie：请求 URL 和 Header 中都携带 Cookie 值
攻击流程：
1. 用户登录银行网站，获得 Cookie
2. 用户访问恶意网站
3. 恶意网站自动向银行发送转账请求（自动携带 Cookie）
防御措施：
1. CSRF Token：服务端生成随机 token，请求时验证
2. SameSite Cookie：
SameSite=Strict/Lax 限制跨站发送3. 验证 Referer/Origin：检查请求来源
4. 双重 Cookie：请求 URL 和 Header 中都携带 Cookie 值
查看答案即标记为已答