网络与协议 · 61/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对比

TCP 三次握手与四次挥手

TCP 连接建立与断开的完整过程和状态变化

问题

TCP 三次握手与四次挥手的详细过程、状态变化,以及为什么是三次握手和四次挥手。

解答

三次握手(建立连接)

客户端                                服务端
  |                                    |
  |  -------- SYN, seq=x -------->     |
  |  (SYN_SENT)                        |
  |                            (SYN_RCVD)
  |  <--- SYN+ACK, seq=y, ack=x+1 ---  |
  |                                    |
  |  -------- ACK, ack=y+1 ------->    |
  |  (ESTABLISHED)           (ESTABLISHED)

过程说明:

  1. 第一次握手:客户端发送 SYN 报文(seq=x),进入 SYN_SENT 状态
  2. 第二次握手:服务端收到后,发送 SYN+ACK 报文(seq=y, ack=x+1),进入 SYN_RCVD 状态
  3. 第三次握手:客户端发送 ACK 报文(ack=y+1),双方进入 ESTABLISHED 状态

为什么是三次握手?

两次不行的原因:

场景:客户端发送的旧 SYN 报文延迟到达

客户端                                服务端
  |                                    |
  |  -------- 旧 SYN -------->         |  (延迟到达的历史报文)
  |                                    |
  |  <------- SYN+ACK --------         |  服务端以为要建立连接
  |                                    |
  |  (客户端发现是旧连接,不理会)        |  服务端白白等待,浪费资源

三次握手的作用:

  • 防止历史连接初始化(客户端可以通过第三次握手拒绝)
  • 同步双方的初始序列号(ISN)
  • 确认双方的收发能力都正常

四次挥手(断开连接)

客户端                                服务端
  |                                    |
  |  -------- FIN, seq=u -------->     |
  |  (FIN_WAIT_1)                      |
  |                            (CLOSE_WAIT)
  |  <------- ACK, ack=u+1 -------     |
  |  (FIN_WAIT_2)                      |
  |                                    |
  |         (服务端可能还有数据要发送)    |
  |                                    |
  |  <------- FIN, seq=w --------      |
  |                            (LAST_ACK)
  |  -------- ACK, ack=w+1 ------->    |
  |  (TIME_WAIT)               (CLOSED)|
  |                                    |
  |  等待 2MSL 后                       |
  |  (CLOSED)                          |

过程说明:

  1. 第一次挥手:客户端发送 FIN,进入 FIN_WAIT_1
  2. 第二次挥手:服务端发送 ACK,进入 CLOSE_WAIT,客户端进入 FIN_WAIT_2
  3. 第三次挥手:服务端发送 FIN,进入 LAST_ACK
  4. 第四次挥手:客户端发送 ACK,进入 TIME_WAIT,服务端收到后进入 CLOSED

为什么是四次挥手?

TCP 是全双工通信,每个方向的关闭需要单独进行:

三次握手时:SYN 和 ACK 可以合并发送(服务端同时发 SYN+ACK)

四次挥手时:ACK 和 FIN 不能合并
- 收到 FIN 只表示对方不再发送数据
- 但自己可能还有数据没发完
- 所以先回 ACK,等数据发完再发 FIN

TIME_WAIT 为什么等待 2MSL?

MSL(Maximum Segment Lifetime)是报文最大生存时间。

  • 确保最后的 ACK 能到达服务端(如果丢失,服务端会重发 FIN)
  • 让本次连接的所有报文在网络中消失,避免影响新连接

关键点

  • 三次握手:防止历史连接、同步序列号、确认双方收发能力
  • 四次挥手:TCP 全双工,每个方向单独关闭,ACK 和 FIN 不能合并
  • TIME_WAIT 等待 2MSL:确保 ACK 到达 + 旧报文消失
  • 握手用 SYN,挥手用 FIN,都需要消耗一个序列号
  • 服务端 CLOSE_WAIT 状态堆积通常是应用层没有正确关闭连接