《系统架构师成长之路》第 3 期计算机网络TCP 三次握手与可靠传输导读第 2 期我们用一次malloc(16)把内存管理从头看到尾。本期进入计算机网络线从为什么 TCP 需要三次握手出发推导可靠传输的三大支柱——序号确认、超时重传RTO 的数学与滑动窗口最后画出拥塞控制的 cwnd 曲线。读完你会真正理解可靠是拿什么换来的。一、为什么需要 TCP可靠不是免费的IP 层只做尽力而为best-effort数据报可能丢失、重复、乱序。TCP 要在这条不可靠的管道上向上层提供字节流式、可靠、有序的传输。可靠性的代价是头部开销20 字节、握手延迟、拥塞控制下的吞吐波动。一个架构师必须记住的对照TCP 用确认-重传换可靠性UDP 用不确认换实时性。飞控遥测、实时音视频这类容忍少量丢失、不能容忍延迟抖动的场景往往选 UDP 应用层自建重传。二、三次握手为什么必须是三次先看时序如图 3-1 所示客户端发SYN, seqx服务端回SYNACK, seqy, ackx1客户端再回ACK, seqx1, acky1连接建立。图3-1TCP 三次握手①②③ 三次报文交互双方各维护一套状态机seq/ack 互相确认对方初始序号。为什么两次不够——反证法推导假设只用两次握手客户端 SYN服务端 SYNACK连接即建立。构造一个真实会发生的时间线客户端发起连接请求 Aseqx报文在网络中滞留比如路由器缓存队列拥塞超时了。客户端等不到回应发起连接请求 Bseqx’这次正常完成握手数据传输完毕连接关闭。滞留的旧报文 A 此时才到达服务端。服务端收到 A误以为是新的连接请求回复 SYNACK——于是服务端单方面认为连接建立一直等待客户端发数据。但客户端根本没有这个连接它认为已经关闭于是服务端资源被白白占用且一旦收到旧连接的数据还会造成数据错乱。三次握手如何解决服务端在收到SYN并回复SYNACK后连接并未建立必须等客户端的第三个ACK才进入 ESTABLISHED。旧报文 A 到达时服务端虽然会回 SYNACK但客户端不会应答它没有这个连接服务端超时后自行释放——错误连接建立不起来。关键推导结论三次握手让发起方掌握最终确认权——只有真正想建连的一端能完成第三次 ACK滞留的旧请求永远无法单方面建立连接。三次握手的两个工程细节SYN 泛洪SYN Flood攻击者只发 SYN 不回 ACK让服务端堆积半连接。对策tcp_syncookies把连接信息编码进 SYNACK 的序号里不占用半连接队列。seq 初始值 ISNRFC 793 建议 ISN 随时间递增每 4 微秒 1防止旧连接的数据段混入新连接。三、可靠传输支柱一序号与确认TCP 把字节流编号每个字节一个序号。接收方确认连续收到的最后一个字节ack 期望收到的下一个序号。超时重传 RTO 的数学推导RFC 6298第一步RTT 采样。每收到一个 ACK测量发送到确认的时间差得到样本 RTT。第二步加权平均平滑。用指数加权移动平均EWMA估计正常的往返时延SRTT_new (1 - α) · SRTT_old α · RTT_sample取 α 1/8。推导技巧越新的样本权重越大α 越大对新样本越敏感α 是 1/8 是因为工程上优先稳——网络抖动大时平滑值不剧烈跳动。第三步估计方差。RTT 本身是波动的重传超时不能只盯平均值要给一个波动裕量。RFC 6298 用 RTTVAR 近似方差RTTVAR_new (1 - β) · RTTVAR_old β · |RTT_sample - SRTT_old|取 β 1/4。这里的技巧是用一阶差分 |RTT_sample − SRTT_old| 代替真正的方差公式省掉平方/开方工程上足够用。第四步合成 RTORTO SRTT 4 · RTTVAR推导含义把 RTT 近似看成均值 ± 4 倍标准差覆盖的区间——4 倍保证绝大多数正常 ACK 不会误判超时若真的超时说明网络状态已变RTO 按指数退避×2。四、可靠传输支柱二滑动窗口光靠发一个等一个停等协议效率太低链路往返一次只能发一个报文。TCP 用窗口允许一次性发送窗口内的多个报文如图 3-2 所示。图3-2发送窗口示意窗口大小 min(cwnd, rwnd)累计确认 窗口滑动是流水线效率的关键。累计确认与快重传接收方只确认连续收到的字节不必逐段回 ACK。若中间缺了一段后续到达的段都会触发重复 ACK值等于缺口的期望序号。发送方连续收到3 个重复 ACK判定该段丢失——不等超时立刻重传叫快重传。推导为什么是 3 而不是 1 或 2个别报文乱序到达如 4 先到、3 后到也会产生 1~2 个重复 ACK用 3 个做阈值是在误判丢包乱序与检测延迟超时之间取的工程折中。五、可靠传输支柱三拥塞控制窗口由两把锁共同决定接收方通告的rwnd流量控制 发送方维护的cwnd拥塞控制。实际发送窗口 min(cwnd, rwnd)。cwnd 随时间的变化规律如图 3-3 所示分四阶段图3-3cwnd 随 RTT 的变化横轴为 RTT 轮次纵轴为 cwnd单位 MSS。慢启动指数增长连接刚建立不知道网络容量从 cwnd1个 MSS开始每个 RTT 翻倍第 k 个 RTT 后cwnd_k 2^k (MSS)推导每收到一个 ACKcwnd 1——因为 ACK 确认了 cwnd 个段一个 RTT 内全部收到后 cwnd 翻倍。指数增长直到cwnd ssthresh初始约 16 或 65535 字节。拥塞避免线性增长超过 ssthresh 后改加法增长每个 RTT 只 1 个 MSScwnd cwnd 1 (每个 RTT)推导技巧相比慢启动的每 ACK 1这里是每 RTT 1——实现上每收到 ACK 只增加 1/cwnd凑满一个 RTT 才 1。目的在接近网络容量时放慢增速避免瞬间打爆网络。丢包后快重传 快恢复检测到 3 个重复 ACK 时ssthresh max(cwnd/2, 2) // 阈值降到一半推导保守假设网络容量只剩一半 cwnd ssthresh // 不回到 1直接降到新阈值继续线性增长推导技巧快恢复相对超时重传cwnd 直接回 1的改进在于——既然还能收到重复 ACK说明网络链路仍在工作没必要清空窗口只有真正的超时网络可能彻底拥塞才 cwnd1 重新慢启动。六、架构视角什么时候不用 TCPTCP 的可靠是端到端重传代价是延迟不可控最坏情况一个段重传多次、队头阻塞。因此实时遥测/流媒体/游戏用 UDP丢包靠应用层补偿如飞控 MAVLink over UDP、WebRTC需要可靠且能容忍延迟TCP既要低延迟又要可靠QUIC在 UDP 之上实现类似 TCP 的可靠 多路复用且握手 1-RTT。架构决策的本质在可靠性、延迟、吞吐三者之间显式地做权衡而不是默认全要。小结三次握手 发起方最终确认防滞留旧 SYN 误建连反证法推出两次不够可靠传输 序号 累计确认 RTOEWMA 推导出RTO SRTT 4·RTTVAR 滑动窗口min(cwnd, rwnd)拥塞控制 慢启动指数/ 拥塞避免线性/ 快重传快恢复阈值减半三阶段架构权衡TCP 可靠换延迟UDP 实时换可靠QUIC 试图兼得。思考题用反证法证明四次握手是多余的提示第三次 ACK 后双方都确认了什么。如果 RTT 采样混入重传报文的 ACK歧义问题SRTT 会被拉大还是拉小Karn 算法怎么处理为什么快恢复后 ssthresh 取 cwnd/2 而不是更小网络容量假设在哪里成立、哪里不成立下期预告第 4 期「HTTP/HTTPS从一次请求到 TLS 握手」——把第 2 期一次请求的六层旅程落到 HTTP 协议层报文结构、缓存、连接复用以及 TLS 握手如何用非对称对称加密保护数据。参考资料RFC 793 — Transmission Control ProtocolTCP 协议原始规范RFC 6298 — Computing TCP’s Retransmission TimerRTO 计算的权威推导RFC 5681 — TCP Congestion Control慢启动/拥塞避免/快重传/快恢复《TCP/IP 详解 卷 1协议》第 17–21 章Kurose Ross《计算机网络自顶向下方法》第 3 章TCP 拥塞控制动画演示Interactive TCP Congestion Control