浏览器访问网页时，一条新的 TCP 连接可能很快就建立起来。抓包中能看到客户端发出 `SYN`，服务器回送 `SYN + ACK`，客户端再发出 `ACK`。三个报文看着简单，背后却有三个不同的问题。通信双方怎样确认这次连接，接收方还有多少空间收数据，发送方又该怎样试探网络能够承受的数据量。

慢启动扩大发送能力，通常以收到确认新数据的 `ACK` 为依据，并非在收到确认之前自行逐步扩大窗口。把这处细节弄清，三道题之间的关系也就通了。

从连接建立说起。TCP 提供的是双向字节流。即使一次业务看上去只有客户端向服务器上传文件，服务器仍须通过同一连接返回确认和响应。因此，两端都要为各自发送的数据选定起始序号，并知道对方的数据从哪个序号开始。`SYN` 承担的工作，就是提出建立连接并同步一端的起始序号。

设客户端选择起始序号 `1000`，服务器选择 `5000`。客户端发出的第一个报文带有 `SYN`，序号为 `1000`。服务器收到后回送 `SYN + ACK`，一面用确认号 `1001` 表明已收到客户端的连接请求，一面把自己的起始序号 `5000` 告诉客户端。客户端收到这个报文，再回送确认号 `5001` 的 `ACK`。这样，客户端的连接请求得到服务器回答，服务器提出的序号同步请求也得到客户端回答。`SYN` 各占用一个序号，所以确认号分别向前推进一位。

据此，第（38）题选 A。A 项所说的双方都提出自己的连接请求并回答对方的连接请求，可以用上述序号交换来理解。这里的两个请求不必表现为两个互不相干的连接。常见的主动打开场景中，服务器把对客户端请求的确认，以及自己这一方向的 `SYN`，合在第二个报文里发出；客户端在第三个报文中确认服务器的 `SYN`。也正因为能够合并，整个过程通常只需三个报文。

为什么不能在服务器发出第二个报文后就算双方建立完毕？服务器此时知道自己收到了客户端的 `SYN`，却不知道带着服务器起始序号的 `SYN + ACK` 是否抵达客户端。第三个报文让服务器获得这项确认。正常情况下，主动打开的一端在收到第二个报文时可以进入已建立状态，被动打开的一端则要等到第三个报文，才确认对方已经接受自己的起始序号。两端进入状态的时刻并不完全相同，这比笼统说成同一瞬间完成连接更准确。

三次握手也要处理网络中的旧报文。设某次客户端尝试建立连接，`SYN` 在网络中严重延迟；客户端等不到回应，放弃了那次尝试。稍后，旧 `SYN` 才到达服务器。服务器只凭收到一个 `SYN`，无法立即断定客户端现在仍想建立那条连接。它会用 `SYN + ACK` 回应，把收到的客户端序号放进确认号，并提供自己的序号。如果客户端当前没有发起与这个回应相符的连接请求，就不会把它当成有效回应来完成握手。TCP 标准给出的旧重复 `SYN` 示例中，客户端还会发送 `RST`，使服务器退回监听状态。

这也是第（38）题 B 项容易吸引人的原因。旧的重复连接请求确实是三次握手要应对的重要情况，TCP 标准甚至明确强调了这一点。但 B 项只写了防止建立重复的连接，未说清旧请求、序号确认与状态核对的机制，读起来也容易被误解为 TCP 可以禁止应用程序再次建立连接。应用程序当然可以再次连接同一台服务器。就这道题给出的四种表述而言，A 项更贴近出题者对三次报文交换过程的概括。

C 项说防止建立单边的连接，同样碰到了相关现象，却不能作为精确答案。现实网络里，一端仍认为连接存在、另一端已经重启，或者一端发出的报文长期得不到回应，都可能出现状态不一致。三次握手能在建立阶段核对双方的请求与序号，却不能保证此后永远不会发生一端失去连接状态的情况。D 项把握手说成防止网络崩溃和数据丢失，更超出了握手的能力。路由器排队、链路中断、接收设备故障仍可能发生；TCP 对丢失数据的处理还依赖确认、重传等机制。

用公司文件服务来想，这个过程更具体。我们的客户端准备向文件服务器传送一份大型文件，发出 `SYN`。服务器回送 `SYN + ACK`，相当于告知客户端，文件服务端已收到建立请求，也给出了自己后续发送数据所使用的序号起点。客户端回送 `ACK`，服务器才确认客户端收到了自己的回应。假如网络里滞留着客户端先前某次尝试的旧 `SYN`，序号和状态核对就能帮助双方识别这次异常交换，避免把旧请求直接当成已经完成的新连接。这个例子对应的是真实文件传输中会遇到的延迟与重传问题，无须假定某一次具体事故已经发生。

连接建好之后，客户端准备发送文件数据，却不能只看自己有多快。服务器的 TCP 接收缓冲区容量有限，应用程序读取缓冲区的速度也可能变化。如果客户端不断把数据送来，而服务器还没来得及取走前面的数据，服务器就需要让客户端放慢。TCP 报文首部的窗口字段，传达的正是这一方向的接收能力。

窗口字段由报文发送方填写，向对端通告自己当前愿意接收多少数据。由于 TCP 是双向的，客户端和服务器都可以在各自发出的报文中通告窗口。讨论服务器向客户端发文件时，客户端是数据接收方，客户端发出的窗口值就约束服务器向它发送数据；讨论客户端上传文件时，方向反过来。窗口不是一条连接共享的单一数字，阅读抓包时一定要看清报文从哪一端发出。

第（39）题因此选 C，表示接收方希望继续接收的字节数。这里的希望，更精确地说是接收方当前通告的、从确认位置起可接纳的数据范围。窗口字段按字节计量，不是按报文个数计量，也不是接收数据的时间段。假设接收方已按序收到序号 `1000` 至 `1999` 的字节，于是确认号为 `2000`，同时通告窗口为 `3000`。发送方据此知道，接收方当前开放的接收范围从序号 `2000` 起，宽度为 `3000` 字节。随着接收方处理数据、更新确认号或窗口，允许发送的范围会继续移动，因而称为滑动窗口。

此处还要防止一种常见误读。窗口为 `3000`，不表示发送方每收到一次确认，就又获得额外 `3000` 字节且可以无限累加。窗口有当前位置和右边界，已发送但尚未确认的数据会占用其中的额度。发送方必须同时查看累计确认位置、已发出的数据范围，以及最新有效的窗口通告，才知道还能放入多少新数据。

还是文件传输的例子。服务器准备向我们的笔记本发送文件，笔记本的接收缓冲区眼下只有 `16 KiB` 可用，于是通告相应的接收窗口。即便两端之间的网络线路很空闲，服务器也不能仅凭线路宽敞就无视笔记本的缓冲区限制。反过来，笔记本通告一个很大的窗口，只能说明它有能力接收更多数据，并不能证明途中每台路由器都有足够容量。这就把接收窗口与下一题的拥塞控制分开了。

第（39）题的 B 项写着限制发送方的数据流量以避免拥塞，看上去与窗口作用相近，关键问题在于它把两种不同的限制合到了一起。TCP 首部的窗口字段反映接收端的接纳能力，主要服务于流量控制，避免发送方压满接收方缓冲区。网络拥塞关注的是发送路径中的链路和路由器能否承受数据量，由发送端的拥塞控制机制处理。前者关心终点能不能收下，后者关心路上能不能顺利送达。A 项把窗口当成时间段，D 项把它当成阻塞链路的时长，都与字段按字节通告接收空间的定义不符。

发送端实际能够保持多少未确认数据，要同时服从两种约束。工程上常用接收窗口 `rwnd` 表示接收方通告的限制，用拥塞窗口 `cwnd` 表示发送方依据网络反馈设定的限制。直观地看，发送量受两者中较小的一个约束，也就是 `min(rwnd, cwnd)`；已经发送、仍在途中的数据还要占去可用额度。如果接收方通告 `64 KiB`，而发送方当前的拥塞窗口只允许 `8 KiB`，发送方不能因为对方缓冲区大就一次向网络投入 `64 KiB`。如果拥塞窗口允许 `64 KiB`，接收方却只通告 `8 KiB`，发送方同样不能越过接收方给出的边界。

现在回到第（40）题。新连接刚准备传输数据时，发送方通常不了解当前路径的可用容量。同一台服务器到客户端的路径可能经过不同接入链路、运营商网络与路由器，其他连接也在争用其中的资源。贸然以很大的速率发送，数据包会在瓶颈处排队，队列满时还会丢包。TCP 所采用的基本思路，是以受限制的初始拥塞窗口开始发送，观察确认反馈，再按照拥塞控制规则调整发送能力。经典机制中的这一阶段称为慢启动。

慢启动的名字容易让人以为拥塞窗口只会缓慢、匀速增加。实际情况更细。按照经典 TCP 拥塞控制规则，在慢启动阶段，收到确认了新数据的 `ACK` 后，发送方可以增加 `cwnd`。随着一个往返周期内有更多已发送的数据得到确认，可在途的数据量会较快增长；达到慢启动阈值或观察到拥塞后，增长方式与处理策略会改变。这里的确认既表明相应数据已经到达对端，也为发送方继续向路径投入数据提供了反馈节奏。`ACK` 到来，并不构成整条路径从此不会拥塞的保证。

第（40）题应选 D，因为四个选项中，只有它试图描述这种依据确认反馈逐步扩大发送窗口的端到端拥塞控制过程。不过，原选项的「在收到确认之前逐步扩大」不能照字面记忆。标准描述中的关键动作是，**收到确认新数据的 `ACK` 后，按规则增加拥塞窗口**。发送方可以在已有窗口允许的范围内发送多个报文，无须每发一个报文都停下等待确认；但不能把尚未到来的确认，当作任意增大拥塞窗口的依据。如果把 D 项改写为「从受限制的初始拥塞窗口开始，在收到确认后逐步扩大拥塞窗口」，技术表达会更妥当。

一个数值例子能帮助区分窗口、确认和在途数据。假定为便于说明，初始拥塞窗口允许发送 `2` 个等长数据段，接收窗口允许发送 `20` 个。发送方可先发出 `2` 个，而不是直接发出 `20` 个。等确认新数据的 `ACK` 到达，慢启动规则允许拥塞窗口增加，发送方才可能让更多数据同时处于未确认状态。这里的 `2` 和 `20` 只是演示控制关系的数字，不能当成所有 TCP 实现统一采用的初始窗口值；窗口在协议计算中也以字节为单位。若接收方此时把通告窗口缩小，即使拥塞窗口已经扩大，实际发送仍要遵守接收窗口的约束。

A 项要求等网络不忙时再建立连接，可互联网中没有一个能向普通 TCP 端点准确报告整条路径「现在不忙」的总开关。某一刻看起来空闲，也不能保证下一刻其他主机不会同时开始传输。B 项说预先申请网络带宽，这不是普通 TCP 三次握手的工作方式。C 项提到流量工程，网络运营者可以通过路径与容量管理改善运行状况，但单条普通 TCP 连接建立时，不靠执行流量工程来决定怎样开始发送。D 项所指的确认驱动的窗口增长，才与 TCP 自身的拥塞控制机制相连。

还要留意题干中的「在建立 TCP 连接时」容易让人误以为，慢启动就是三次握手的第四步。两者在逻辑上分属不同阶段。握手负责建立连接、交换并确认起始序号，也可协商某些 TCP 选项；拥塞窗口控制的是连接开始发送数据时，以及后续传输中，发送方能向网络投入多少尚未确认的数据。建立连接并不会自动证明网络可承受一整份文件的突发发送，拥塞控制因此要伴随数据传输持续工作。现代实现的初始窗口和拥塞算法可以不同，但接收窗口与拥塞窗口分别解决什么问题，这条界线仍然重要。

把三题放回一次文件传输里，脉络很清楚。客户端和服务器借三次握手核对彼此的建连意图与序号，对应（38）A。服务器发送文件时，客户端通过 TCP 首部窗口字段通告自己还能接纳多少字节，对应（39）C。服务器即使看到客户端尚有充足接收空间，也要受自身拥塞窗口约束，在收到数据确认后依据算法调整发送量，对应（40）D。掌握这三种职责，比单独记住 A、C、D 更能帮助我们判断真实抓包中究竟是连接未建成、接收端跟不上，还是发送路径出现了拥塞。

## 参考资料

[RFC 9293，Transmission Control Protocol](https://www.rfc-editor.org/info/rfc9293/)

[RFC 5681，TCP Congestion Control](https://www.rfc-editor.org/info/rfc5681/)

[RFC 7323，TCP Extensions for High Performance](https://www.rfc-editor.org/info/rfc7323/)

浏览器访问网页时，一条新的 TCP 连接可能很快就建立起来。抓包中能看到客户端发出 SYN，服务器回送 SYN + ACK，客户端再发出 ACK。三个报文看着简单，背后却有三个不同的问题。通信双方怎样确认这次连接，接收方还有多少空间收数据，发送方又该怎样试探网络能够承受的数据量。

从三次握手到慢启动，读懂 TCP 如何建立连接并控制数据发送

紫薇堂堂主

网络与通信

架构设计

后端

TCP三次握手同步双方起始序号并确认建连意图；接收窗口字段通告接收能力，实现流量控制；拥塞窗口受ACK反馈驱动，在慢启动阶段逐步扩大发送量。三机制分别对应序号确认、接收方缓存限制和网络路径容量约束，共同决定数据传输效率与可靠性。

数据丢失

文件传输

服务器

路由器

数据流

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从三次握手到慢启动，读懂 TCP 如何建立连接并控制数据发送-腾讯云开发者社区-腾讯云

从三次握手到慢启动，读懂 TCP 如何建立连接并控制数据发送

从三次握手到慢启动，读懂 TCP 如何建立连接并控制数据发送

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐