4、传输层基石：TCP协议详解、三次握手与四次挥手、滑动窗口与流量控制
各位同学，今天我们聊一个真正硬核的话题——TCP协议。
说实话，我在刚入行那会儿，觉得TCP就是个“黑盒子”。调接口时只管发数据，至于底层怎么保证可靠、怎么控制流量，完全没概念。直到有一次线上事故，让我彻底栽了个跟头……嗯，从那以后，我老老实实把TCP啃了个透。
今天这一章，我们就把它掰开揉碎，讲清楚。
4.1 TCP协议：为什么它是传输层的基石？
TCP，全称Transmission Control Protocol，翻译过来叫“传输控制协议”。
你想想看，IP层只负责把数据包从A点送到B点，但它不保证顺序、不保证不丢包、不保证不重复。说白了，IP就是个“尽力而为”的快递员，包裹丢了它也不管。
而TCP呢？它在这之上加了一层“可靠传输”的机制。我个人的理解是：TCP就像快递公司的客服，不仅帮你寄件，还帮你跟踪、确认、重发。这才是真正的“端到端可靠”。
核心特性：
- 面向连接：通信前必须先建立连接（三次握手）
- 可靠传输：确认机制、超时重传、序列号保证
- 流量控制：防止发送方太快，接收方来不及处理
- 拥塞控制：防止网络过载
- 全双工通信：双方可以同时收发数据
我在项目中遇到过最典型的场景：用TCP传输大文件。如果不做流量控制，接收方的缓冲区瞬间就满了，然后就是丢包、重传、性能雪崩。嗯，这个坑我踩过。
4.2 三次握手：建立连接的艺术
三次握手，说白了就是客户端和服务器互相确认“你准备好了吗？”“我准备好了！”的过程。
为什么非得是三次？两次不行吗？四次呢？
我刚开始学的时候也有这个疑问。后来在调试一个自定义协议时，才真正理解了——两次握手会导致“历史连接”问题。你想想看，如果客户端发了一个SYN，网络延迟了，客户端以为丢了就重发。结果第一个SYN又到了，服务器如果只回一个ACK就建立连接，那就会产生两个连接。三次握手就是为了解决这个“历史重复连接”的问题。
具体流程是这样的：
| 步骤 | 发送方 | 接收方 | 状态变化 |
|---|---|---|---|
| 第一次 | 客户端 → SYN=1, seq=x | 服务器 | 客户端：SYN_SENT |
| 第二次 | 客户端 | 服务器 → SYN=1, ACK=1, seq=y, ack=x+1 | 服务器：SYN_RCVD |
| 第三次 | 客户端 → ACK=1, seq=x+1, ack=y+1 | 服务器 | 双方：ESTABLISHED |
避坑指南：我曾经在写一个高并发服务器时，发现大量连接处于SYN_RCVD状态。排查了半天，原来是客户端发完SYN后就不管了，服务器一直在等第三次握手。这就是典型的SYN Flood攻击。解决方案是启用SYN Cookie，或者设置合理的超时时间。
4.3 四次挥手：优雅地告别
断开连接比建立连接复杂一些。为什么？因为TCP是全双工的，双方都需要关闭自己的发送通道。
四次挥手的过程：
- 第一次挥手：客户端发送FIN，表示“我不再发数据了”
- 第二次挥手：服务器回复ACK，表示“收到，但我可能还有数据要发”
- 第三次挥手：服务器发送FIN，表示“我的数据也发完了”
- 第四次挥手：客户端回复ACK，表示“收到，可以关闭了”
这里有个关键点：TIME_WAIT状态。客户端在发送最后一个ACK后，会进入TIME_WAIT状态，持续2MSL（最大报文段生存时间）。
为什么要等这么久？
我个人的理解是：防止最后一个ACK丢失。如果服务器没收到ACK，它会重发FIN。如果客户端已经关闭了，那服务器就永远收不到确认了。2MSL的时间足够让所有可能的重复报文都消失。
注意：在高并发场景下，TIME_WAIT状态的连接会占用大量端口资源。我曾经在一个短连接服务上遇到过端口耗尽的问题，最后通过开启SO_REUSEADDR选项解决了。嗯，这个坑值得记下来。
4.4 滑动窗口：流量控制的精髓
滑动窗口，说白了就是接收方告诉发送方：“我还能收多少数据，你别发太快。”
没有滑动窗口会怎样？
你想想看，如果发送方不管不顾地猛发，接收方的缓冲区瞬间就满了。然后就是丢包、重传、性能崩溃。我在做视频流传输时深有体会——不加流量控制，画面卡成PPT。
滑动窗口的核心机制：
- 发送窗口：发送方可以连续发送的数据量，不需要等待ACK
- 接收窗口：接收方当前可用的缓冲区大小
- 窗口大小：通过TCP头部的Window字段通告
举个例子：
假设接收窗口大小为4个报文段
发送方可以连续发送4个报文段，不需要等待ACK
收到第一个ACK后，窗口向前滑动，可以继续发送第5个
如果接收方处理不过来，它会减小窗口大小
发送方收到新的窗口值后，会调整发送速率关键点：滑动窗口实现了“按需发送”。接收方忙不过来，就缩小窗口；接收方空闲了，就扩大窗口。这是一种动态的、自适应的流量控制机制。
4.5 流量控制 vs 拥塞控制
这两个概念容易混淆，我简单区分一下：
| 控制类型 | 控制对象 | 目的 | 机制 |
|---|---|---|---|
| 流量控制 | 接收方 | 防止接收方过载 | 滑动窗口 |
| 拥塞控制 | 网络 | 防止网络过载 | 慢启动、拥塞避免、快重传、快恢复 |
说白了，流量控制是“点对点”的，拥塞控制是“全局”的。我在做CDN加速时，这两个机制配合使用才能达到最佳效果。
4.6 实战经验总结
最后，分享几个我在项目中踩过的坑：
- Nagle算法：默认开启，会把小包合并成大包再发送。实时性要求高的场景（如游戏、视频通话），建议关闭。
- 延迟确认：接收方不会立即回复ACK，而是等一段时间。如果数据量小，会导致延迟增加。
- Keep-Alive：TCP的保活机制，默认是关闭的。长连接场景建议开启，但间隔时间要合理设置。
我的建议：做全栈开发，TCP协议是绕不开的。不要只停留在调API的层面，理解底层机制才能写出高性能的网络应用。尤其是做IM、直播、游戏这类实时性要求高的系统，TCP的每一个细节都可能成为性能瓶颈。
好了，这一章的内容就到这里。TCP协议虽然复杂，但掌握了核心机制，你会发现它其实很优雅。下一章我们聊UDP，那个“爱发不发、丢了不管”的协议，对比着学效果更好。