Transmission Control Protocol（TCP）是什么？
简答：Transmission Control Protocol，简称 TCP，是 TCP/IP 网络中的传输层协议，为两台主机提供面向连接、可靠且有序的字节流传输。理解一次网页访问时，可以按“DNS解析→TCP三次握手→TLS协商（HTTPS）→HTTP请求→TCP传输→连接关闭”这条链路排查问题。
定义：Transmission Control Protocol（TCP）是一种通过连接建立、序列号、确认、重传、流量控制和拥塞控制，在主机之间传输有序字节流的传输层协议。
先看结论：TCP 解决什么问题
TCP 位于 TCP/IP 协议栈的传输层。IP 主要负责把数据报送到目标主机，而 TCP 在两台主机之间建立连接，并把应用数据组织成可确认、可重传、按序交付的字节流。NIST 对 TCP 的定义也强调了连接建立、数据流交换和有序交付这些特征。查看 NIST 术语定义
需要注意，TCP 提供的是协议机制，不等于无条件保证应用最终成功。链路中断、对端进程退出、路由不可达、接收窗口为零或连接被重置时，TCP 仍可能结束连接或向应用报告错误。
| 层次或协议 | 主要职责 | 不负责什么 |
|---|---|---|
| IP | 按 IP 地址转发数据报 | 不保证按序、可靠交付 |
| TCP | 连接、序列号、确认、重传、流量与拥塞控制 | 不负责应用层加密 |
| TLS | 在 HTTPS 等场景中提供加密、完整性和身份校验机制 | 不替代 TCP 的连接和字节流功能 |
| HTTP/HTTPS | 定义网页请求、响应和应用语义 | 不直接负责 IP 路由 |
一次网页连接的完整流程
下面是适合初学者的文本版流程图。它不是单纯的“打开网页”，而是把名称解析、传输连接、安全协商和应用请求分开：
输入域名 → DNS 返回 IP → TCP SYN → TCP SYN-ACK → TCP ACK → TLS 协商（HTTPS）→ HTTP 请求 → HTTP 响应 → TCP 按序传输 → FIN/ACK 关闭
- DNS 解析：应用先把域名解析为一个或多个 IP 地址。DNS 成功只说明名称解析有结果，不代表目标端口一定可连接。
- TCP 三次握手：客户端发送 SYN，服务端返回 SYN-ACK，客户端再发送 ACK。双方借此同步初始序列号，并确认对方能够收发连接建立报文。RFC 9293 TCP 规范
- TLS 协商：如果访问的是 HTTPS，TLS 在 TCP 连接建立后完成加密参数和证书相关协商。TCP 本身不负责加密。
- HTTP 请求：应用层发送请求，TCP 将字节流切分为报文段并维护序列号、确认号和窗口。
- 连接关闭：通常由 FIN 和 ACK 逐步完成；如果发生严重异常，也可能使用 RST 快速重置。
因此，网页打不开时不要只看“网络是否在线”：应分别判断 DNS 是否成功、TCP 端口是否能建立、TLS 是否失败，以及 HTTP 是否返回错误。
TCP 的核心机制：可靠性、流量控制和拥塞控制不是一回事
可靠、有序的字节流
TCP 会为发送的数据字节编号，接收方通过确认号告知“下一个期待的序列号”。如果报文段丢失、校验失败或确认未在预期时间内到达，发送方可能进行重传。序列号还帮助接收方识别重复数据并按正确顺序交给应用。RFC 9293 的序列号、确认和重传说明
流量控制：照顾接收方
接收方会通过接收窗口告诉发送方自己还能接收多少数据。窗口较小或变为零，通常表示接收端处理速度跟不上，发送端需要减慢发送或等待窗口重新开放。流量控制解决的是“接收方来不来得及处理”。
拥塞控制：照顾网络路径
拥塞控制关注的是网络中间设备和链路是否过载。TCP 的基本拥塞控制包括慢启动、拥塞避免、快速重传和快速恢复等机制；这些机制与流量控制相互关联，但目的不同。RFC 5681 TCP 拥塞控制
| 机制 | 主要观察对象 | 典型表现 |
|---|---|---|
| 可靠性 | 数据是否丢失、重复或乱序 | 确认、序列号、重传 |
| 流量控制 | 接收端缓冲区 | 接收窗口变小或为零 |
| 拥塞控制 | 网络路径承载能力 | 拥塞窗口调整、丢包后的降速 |
TCP 头部、端口与连接四元组怎么理解
TCP 报文段头部包含源端口、目的端口、序列号、确认号、窗口、校验和以及控制位等字段。常见控制位包括 SYN、ACK、FIN、RST、PSH、URG、ECE 和 CWR；RFC 9293 对这些控制位及窗口、校验和字段作出了规范说明。查看 RFC 9293 头部字段
- 端口：让同一台主机上的多个应用复用网络连接，例如浏览器、数据库和文件服务可以使用不同端口。
- 四元组：在常见 TCP 连接识别语境中，是本地 IP、本地端口、远端 IP、远端端口。
- 五元组：如果再加上传输协议类型，例如 TCP 或 UDP，通常称为五元组。
- 连接状态：LISTEN 表示等待连接，SYN-SENT 表示已发出 SYN，SYN-RECEIVED 表示收到并准备确认，ESTABLISHED 表示连接已建立；FIN-WAIT、CLOSE-WAIT、TIME-WAIT 等则与关闭流程有关。
四元组或五元组描述的是“这条流由哪些字段识别”，而 LISTEN、ESTABLISHED、TIME-WAIT 描述的是“当前 TCP 状态”。两者不能混为一谈。
TCP 与 UDP 怎么选
TCP 与 UDP 都属于传输层，但设计目标不同。TCP 适合需要连接管理、按序传输和丢失重传的场景；UDP 更接近无连接的数据报发送，应用可以自行决定是否处理顺序、重传和速率控制。
| 场景 | 通常更关注的能力 | 常见选择思路 |
|---|---|---|
| 网页访问、接口调用 | 完整请求、顺序和错误处理 | 传统 HTTP/1.1、HTTP/2 通常基于 TCP |
| 文件传输、软件包下载 | 数据完整性和顺序 | 通常选择 TCP 或在更高层实现可靠机制 |
| 实时音视频 | 低延迟和及时到达 | 可能选择 UDP，并由上层处理丢包和拥塞 |
| 简单查询或局域网发现 | 低开销、无需保持连接 | 可考虑 UDP，但要接受其不提供 TCP 式可靠字节流 |
不存在脱离场景的“TCP 一定更快”或“UDP 一定更好”。选型应看应用是否能接受丢包、乱序、重复数据，以及是否需要稳定的连接语义。
连接异常时的最短排查流程
当应用提示连接超时、连接被拒绝或连接重置，可以按下面顺序缩小范围：
- 先查 DNS：确认域名能解析到预期地址；如果不同网络得到的结果不同，记录解析结果再继续，不要直接把问题归因于 TCP。
- 再查 TCP 端口：确认目标主机的对应端口是否可达。超时通常表示路径、过滤或对端没有及时响应；拒绝通常表示目标主机明确返回了拒绝，或该端口没有监听，但具体原因仍需结合服务端日志。
- 观察握手：抓包或查看连接状态，区分 SYN-SENT、SYN-RECEIVED、ESTABLISHED、TIME-WAIT 等状态。
- 最后查应用层：TCP 已建立但网页仍失败，应继续检查 TLS 证书、HTTP 状态码、代理配置和应用日志。
| 提示或现象 | 检查 | 下一步 |
|---|---|---|
| 域名无法解析 | DNS 服务器、域名拼写、网络环境 | 先修复解析，再测试 TCP |
| 连接超时 | 路由、端口过滤、服务端是否响应 | 对比其他网络并查看两端日志 |
| 连接被拒绝 | 目标端口是否监听、服务是否启动 | 检查服务配置和防火墙规则 |
| 连接被重置 | RST 来源、服务崩溃、代理或中间设备 | 抓包定位发送 RST 的一端 |
| TCP 已连接但请求失败 | TLS、HTTP 响应、应用日志 | 进入应用层排查，不要只重复测试端口 |
排障时应记录测试时间、目标域名或 IP、目标端口、网络环境和错误提示。不要把一次连通或一次超时当成长期可用性结论。
安全提醒与标准边界
TCP 本身不提供应用数据加密，也不能单独证明通信对端身份。涉及账号、隐私或敏感业务时，应由 HTTPS、TLS 或其他经过验证的安全协议提供相应保护。
RFC 9293 是当前 TCP 基础规范的主要入口，并整合、更新了早期 TCP 规范内容；RFC 793 更适合作为历史背景阅读，而不应被单独当作现行完整标准。RFC 9293 标准说明 RFC 793 历史规范
常见问题
TCP 是不是一种网速？
不是。TCP 是传输层协议，负责连接和数据传输机制；实际体验还会受到链路带宽、往返时延、丢包、拥塞、服务器处理能力和应用协议影响。
TCP 三次握手为什么不是两次？
三次交互让双方分别确认自己的发送方向和接收方向，并同步双方的初始序列号。只交换两次时，双方无法充分确认彼此的收发能力和序列号状态。
TCP 建立连接后还会丢包吗？
链路仍可能丢失或重复报文段。TCP 通过确认、序列号和重传机制处理部分丢失，但重传会增加延迟，持续异常时连接仍可能失败。
TIME-WAIT 是不是故障？
不一定。TIME-WAIT 是连接关闭流程中的正常状态，用于处理延迟到达的旧报文并避免新旧连接混淆。只有当数量异常、耗尽资源并伴随业务故障时，才需要进一步排查。
TCP 端口开放就代表服务正常吗？
不代表。端口可建立连接只能说明 TCP 层有响应，应用仍可能在 TLS、认证、请求格式或后端依赖处失败。
TCP 与 HTTPS 是同一回事吗？
不是。TCP提供传输层连接和字节流，HTTPS是在HTTP之上使用TLS保护通信。一次传统HTTPS访问通常会先建立TCP连接，再进行TLS协商，之后才交换HTTP内容。
常见问题
TCP 可以直接替代 DNS 吗？
不可以。DNS 负责名称解析，TCP 负责建立传输连接；DNS 得到 IP 后，应用才可能继续连接目标端口。
为什么 ping 通但 TCP 端口仍然连不上？
ping 通常测试的是 ICMP 可达性，不等于目标 TCP 端口正在监听或允许访问。应单独测试目标端口并查看连接状态。
TCP 的校验和能保证数据绝对正确吗？
TCP 校验和用于检测部分传输错误，但它不是端到端应用语义校验，也不能替代 TLS、文件哈希或应用层完整性校验。
RST 和 FIN 有什么区别？
FIN 通常表示一方正常结束自己的发送方向，RST 表示连接被重置或异常终止。具体原因要结合报文方向、状态和服务日志判断。
TCP 为什么会让实时业务感觉变慢？
TCP 的按序交付和重传机制有助于完整传输，但丢包时可能等待重传，后续数据也可能受队头阻塞影响。是否适合实时业务取决于应用需求。
排查 TCP 问题一定要抓包吗？
不一定。先看 DNS、端口测试、系统连接状态和应用日志；当这些信息无法区分超时、拒绝、重置或TLS失败时，再使用抓包工具定位。