网络与协议 · 59/72
1. Ajax、Axios、Fetch 对比 2. Ajax 原理 3. Ajax 技术与实现 4. 常见的应用层协议 5. 浏览器缓存的存储位置 6. 从输入 URL 到页面显示的过程 7. Cache-Control 常见配置值 8. CDN 工作原理 9. 为什么推荐将静态资源放到 CDN 上 10. Cookie 的弊端 11. Cookie 的 Secure 属性设置 12. CORS 请求携带身份凭证的方法 13. CORS 跨域原理 14. 复杂请求预检检查内容 15. CORS 预检请求 16. CORS简单请求的条件 17. 简单请求为何无需预检 18. DNS 域名解析与网络请求路由 19. 什么是跨域 20. 什么是 DNS 劫持? 21. DNS 预解析优化网页加载速度 22. DNS 解析过程与优化 23. URL 参数为什么需要 encodeURIComponent 转码 24. Last-Modified 和 ETag 的区别 25. Fetch 发送两次请求的原因 26. 正向代理与反向代理 27. 前后端通信方式 28. GET请求能否上传图片 29. GET 请求的传参长度限制 30. HTTP 缓存策略 31. GET 与 POST 的区别 32. HTTP状态码301与302的区别 33. HTTP 数据传输 34. HTTP 队头阻塞 35. HTTP 请求头和响应头的重要字段 36. HTTP发展历程 37. HTTP与HTTPS总结 38. HTTP 和 HTTPS 的区别 39. HTTP 报文结构与状态码 40. HTTP Keep-Alive 机制 41. HTTP管道机制的作用 42. HTTP协议优缺点 43. HTTP 重定向状态码 301/302/303/307/308 44. HTTP 请求方法 45. HTTP 协议版本演进 46. HTTP与TCP的区别 47. HTTP/2 多路复用原理 48. HTTPS 协议的缺点 49. HTTP/3 如何保证传输可靠性 50. HTTP/2 的改进 51. HTTPS 加密原理 52. 什么是负载均衡? 53. Nginx 负载均衡调度算法 54. Nginx 是什么 55. 对象存储 OSS 是什么 56. OPTIONS 请求方法及使用场景 57. 轮询与 WebSocket 对比 58. HTTPS 中 SSL 的 OSI 层位置 59. SSL连接恢复 60. 强缓存和协商缓存 61. TCP 三次握手与四次挥手 62. TCP三次握手中的数据传输 63. TCP 和 HTTP 请求的关系 64. TCP/IP 协议 65. TCP 如何判断丢包 66. TCP 与 UDP 的区别 67. WebSocket 的 Handshaking 握手过程 68. TLS 1.3 相比 TLS 1.2 的改进 69. URI、URL、URN 的区别 70. WebSocket 心跳机制 71. WebSocket 协议原理 72. XML与JSON对比

SSL连接恢复

SSL/TLS 连接断开后的两种恢复机制

问题

SSL 连接断开后如何恢复?为什么需要连接恢复机制?

解答

SSL/TLS 完整握手需要 2-RTT(往返时间),计算开销大。连接恢复机制可以跳过部分握手步骤,提升性能。

1. Session ID 恢复

服务器为每个会话分配唯一 ID,客户端重连时携带该 ID,服务器查找缓存恢复会话。

# 完整握手流程
Client                              Server
  |---- ClientHello ---------------->|
  |<--- ServerHello + Certificate ---|
  |<--- ServerKeyExchange -----------|
  |<--- ServerHelloDone -------------|
  |---- ClientKeyExchange ---------->|
  |---- ChangeCipherSpec ----------->|
  |---- Finished ------------------->|
  |<--- ChangeCipherSpec ------------|
  |<--- Finished --------------------|

# Session ID 恢复流程(1-RTT)
Client                              Server
  |---- ClientHello + SessionID ---->|
  |<--- ServerHello + SessionID -----|
  |<--- ChangeCipherSpec ------------|
  |<--- Finished --------------------|
  |---- ChangeCipherSpec ----------->|
  |---- Finished ------------------->|

Nginx 配置示例:

server {
    listen 443 ssl;
    
    # 启用 Session 缓存
    ssl_session_cache shared:SSL:10m;  # 10MB 共享缓存
    ssl_session_timeout 10m;            # 会话有效期 10 分钟
}

2. Session Ticket 恢复

服务器将会话状态加密后发给客户端保存,重连时客户端携带 Ticket,服务器解密恢复会话。

server {
    listen 443 ssl;
    
    # 启用 Session Ticket
    ssl_session_tickets on;
    ssl_session_ticket_key /path/to/ticket.key;  # 加密密钥
}

3. TLS 1.3 的 0-RTT 恢复

TLS 1.3 支持 0-RTT 恢复,首次请求就可以携带加密数据:

Client                              Server
  |---- ClientHello + EarlyData --->|  # 首包就带数据
  |<--- ServerHello + Finished -----|
  |---- Finished ------------------>|

Node.js 启用 0-RTT:

const tls = require('tls');
const fs = require('fs');

const server = tls.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  // TLS 1.3 默认启用,支持 0-RTT
  minVersion: 'TLSv1.3'
});

server.on('secureConnection', (socket) => {
  // 检查是否为恢复的会话
  if (socket.isSessionReused()) {
    console.log('Session resumed');
  }
});

server.listen(443);

两种方式对比

特性Session IDSession Ticket
状态存储服务器端客户端
服务器内存需要缓存无需缓存
分布式支持需要共享缓存只需共享密钥
安全性较高依赖密钥管理

关键点

  • Session ID 由服务器存储会话状态,需要内存缓存
  • Session Ticket 由客户端存储加密的会话状态,服务器无状态
  • 两种方式都能将握手从 2-RTT 降到 1-RTT
  • TLS 1.3 支持 0-RTT,但存在重放攻击风险,仅适用于幂等请求
  • 分布式环境下 Session Ticket 更易扩展,只需同步加密密钥