🔗
网络
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 值
查看答案即标记为已答