TCP 如何保证可靠传输：序列号、ACK、重传和窗口控制

上一篇讲 TCP 和 UDP 的区别时，我们说 TCP 是可靠传输。这个说法很常见，但如果只停在“可靠”两个字，还是太粗。TCP 可靠，不是因为网络本身突然变可靠了，而是因为 TCP 在协议里设计了一整套补救和控制机制。

文中把 TCP 保证可靠性的方式归纳为：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制。它们分别处理不同问题：数据有没有错、顺序乱没乱、对方收没收到、丢了怎么补、连接状态是否明确、接收方能不能处理、网络是否已经拥堵。

这篇就按这个顺序讲。你不需要一次记住所有细节，但要能回答一个核心问题：当数据在网络里可能丢、可能乱、可能慢、可能把对方撑爆时，TCP 是怎么把这些不确定性压下来的。

TCP 是面向连接的协议。在正式传数据之前，它要先通过三次握手建立连接。后文也单独讲了三次握手：客户端发 SYN，服务器回 SYN + ACK，客户端再回 ACK。这个过程不是形式主义，而是在确认双方都有发送和接收能力。

连接建立后，双方会维护一组状态，包括序列号、确认号、窗口大小等。所谓 TCP 连接，并不是两台机器之间真的拉了一根线，而是双方通过报文和状态维护出一条逻辑连接。

连接关闭时也要管理状态。四次挥手之所以分多步，是因为 TCP 是双向通信。客户端不再发送数据，不代表服务器也已经没有数据要发。双方都要分别告知和确认，连接才算完整关闭。

TCP 是字节流协议。应用层写入的数据到了 TCP 里，会被看成连续的字节流。为了让接收方知道每段数据在这条流里的位置，TCP 会给发送的数据分配序列号。

序列号的作用很朴素：跟踪数据。接收方收到一段数据后，可以根据序列号判断它应该放在哪里。如果后面的数据先到了，接收方也能知道中间缺了一段；如果重复数据到了，也能识别出来。

这就是 TCP 能按序交付的基础。没有序列号，接收方只能看到一堆到达的片段，很难知道谁先谁后、谁缺了、谁重复了。

确认应答，也就是 ACK，是 TCP 可靠性的另一个核心。文中说，接收方会确认已经成功接收的数据，发送方根据确认来判断哪些数据已经成功传输，哪些需要重新发送。

ACK 通常表示“我已经收到前面的数据，下一段希望从哪里开始”。比如接收方返回 ACK=1003，可以理解为 1003 之前的数据已经收到了，下一次请从 1003 开始发。这样发送方就不用猜。

ACK 让 TCP 有了反馈回路。发送方不是把数据扔出去就不管，而是持续听接收方的确认。确认来了，说明这部分可以从待确认队列里移走；确认迟迟不来，就要考虑是不是丢了。

网络传输不保证每个包都能顺利到达。数据包可能丢，ACK 也可能丢。TCP 用超时机制检测这类情况：发送方发出数据后，会等待确认；如果在一定时间内没有收到 ACK，就认为这段数据可能丢了，于是触发重传。

这里的难点在于超时时间不能随便定。太短，会把还在路上的数据误判为丢失，导致重复重传；太长，真正丢包时又会恢复太慢。资料 在可靠 UDP 部分也提到 RTT 和 RTO 的概念：根据往返时间估算合适的重传超时时间。

所以超时重传不是简单“没收到就马上发”。它要根据网络延迟动态判断什么时候该等、什么时候该补。

可靠传输还要处理数据损坏。TCP 头里有校验和字段，用来检查数据在传输过程中是否出现错误。接收方收到数据后，会根据校验和判断报文是否完整、是否被破坏。

如果校验失败，这段数据就不能交给应用层当作正常数据使用。后续发送方如果收不到对应 ACK，就会通过重传把数据补回来。

校验和不是为了防攻击，它主要处理传输错误。真正的安全完整性保护要靠 TLS、签名、消息认证码等机制。把这些边界分清，排查网络问题时会少走很多弯路。

如果 TCP 每发一个数据段都停下来等 ACK，效率会很低。滑动窗口解决的是这个问题：发送方可以在窗口允许范围内连续发送多段数据，不必每一段都等确认回来。

窗口会随着 ACK 向前滑动。接收方确认了一部分数据，说明缓冲区腾出了空间，发送方就可以继续发送后面的数据。这样既提高吞吐，也不会完全失控。

滑动窗口也和流量控制有关。接收方会告诉发送方自己的接收窗口大小，也就是还能接收多少数据。发送方不能超过这个范围，否则接收方处理不过来，缓冲区可能溢出。

文中说，TCP 使用滑动窗口机制进行流量控制，确保发送方不会以高于接收方处理速度的速率发送数据。这句话很重要。流量控制看的不是整个网络，而是接收方。

接收方应用处理慢、缓冲区变小，就会通过窗口大小告诉发送方少发点。发送方看到接收窗口变小，就要降低发送量。这样可以避免接收方缓存溢出，也避免大量数据到了却没地方放。

这也是 TCP 比 UDP 更省心的地方之一。UDP 默认不会帮你看接收方吃不吃得下，应用层如果疯狂发送，接收方处理不过来，就只能丢包或自己做限速。

拥塞控制看的不是接收方，而是网络。文中说，TCP 会通过动态调整发送速率适应网络状态。当网络出现拥塞时，TCP 会减慢发送速度，避免进一步加剧拥塞。

可以把它想成一条路。接收方仓库可能还能收货，但路上已经堵住了。如果发送方继续加速，只会让更多包排队、丢失、重传，最后整体更慢。拥塞控制就是让发送方根据丢包、延迟、确认情况判断路况。

常见过程包括慢启动、拥塞避免、丢包后降低窗口，再逐步恢复增长。细节可以很深，但入门先记住一句：流量控制保护接收方，拥塞控制保护网络。

序列号解决位置问题，ACK 解决确认问题，重传解决丢包问题，校验和解决传输错误问题，连接管理解决状态问题，滑动窗口提高效率，流量控制和拥塞控制负责别发太快。

这些机制不是彼此独立地背，而是在一次传输里同时工作。发送方发数据，接收方按序接收并确认；ACK 回来后窗口滑动；如果等不到 ACK，就重传；如果接收方窗口变小，发送方降速；如果网络拥塞，发送方也要收敛。

也正因为 TCP 做了这么多事，它才适合网页浏览、文件传输、邮件、数据库连接、普通 API 请求这类要求数据完整和顺序正确的场景。

如果被问 TCP 如何保证可靠传输，可以这样答：TCP 通过连接管理建立通信状态，通过校验和发现传输错误，通过序列号保证数据可追踪和按序重组，通过 ACK 确认已收到的数据，通过超时重传补发丢失数据，通过滑动窗口提高传输效率，并用流量控制和拥塞控制限制发送速度。

然后补一句区分：流量控制主要看接收方处理能力，避免把接收方缓冲区撑爆；拥塞控制主要看网络拥堵程度，避免发送方把网络挤得更堵。

这样回答比罗列七个名词更自然。你讲的不只是“有哪些机制”，而是每个机制在解决哪个真实问题。