TCP：修订间差异

| 标题 = 传输控制协议

| 内容 =  

! 中文名

{{!}} 传输控制协议

! 英文名

{{!}} Transmission Control Protocol

! 缩写

{{!}} TCP

! 标准编号

{{!}} STD 7（RFC 9293）

! 首次发布

{{!}} RFC 793（1981年9月）

! 当前版本

{{!}} RFC 9293（2022年8月）

! 端口类型

{{!}} 传输层协议，协议号6

! 主要功能

{{!}} 面向连接的可靠字节流传输

! 关键机制

{{!}} 序列号、确认应答、滑动窗口、拥塞控制

! 设计者

{{!}} Vint Cerf、Bob Kahn

! 标准化机构

{{!}} IETF

'''传输控制协议（Transmission Control Protocol，缩写TCP）''' 是TCP/IP协议套件中的核心传输层协议，设计用于在不可靠的IP网络上提供面向连接的、可靠的、有序的字节流传输服务<ref name="RFC9293">[https://datatracker.ietf.org/doc/rfc9293/ Eddy, W., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022.]</ref>。TCP通过序列号机制和累积确认应答实现对丢失或乱序数据段的检测与重传，利用滑动窗口协议实施流量控制以防止接收方缓冲区溢出，并内置拥塞控制算法以防止发送方速率过快导致网络过载<ref name="RFC9293" />。TCP与上层应用之间通过端口号建立复用/解复用通道，使单台主机上的多个应用程序能够同时维持独立的TCP连接<ref name="RFC9293" />。TCP具有全双工特性——每一个TCP连接支持两条独立的字节流，分别向两个方向传输数据<ref name="RFC9293" />。自1981年首次标准化以来，TCP历经数十年的持续演进，在原始规范基础上增加了多项扩展和改进，是当今互联网中承载Web浏览、电子邮件、文件传输、远程登录等绝大多数应用流量的基础协议<ref name="RFC9293" />。2022年8月发布的RFC 9293收集并整合了自RFC 793以来的所有重要修订，正式取代后者成为TCP的现行标准<ref name="RFC9293" />。

TCP使用16位的端口号对上层应用进行标识。IANA将端口号空间划分为三类：0至1023为系统端口或熟知端口，由IANA统一分配给标准的网络服务（如HTTP使用80端口，HTTPS使用443端口）；1024至49151为用户端口或注册端口，可供IANA注册或自由使用；49152至65535为动态端口或私有端口，通常由操作系统在客户端建立连接时临时分配<ref name="IANAPorts">[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml Service Name and Transport Protocol Port Number Registry，IANA.]</ref>。

TCP连接通过“三报文握手”（Three-Way Handshake）过程建立。具体步骤如下：首先，主动连接发起方（客户端）发送SYN报文段（SYN标志位为1），携带客户端选择的初始序列号ISN_c<ref name="ThreeWayHandshake" />。服务器收到后，回复SYN+ACK报文段，在确认客户端的序列号（ACK号置为ISN_c+1）的同时，携带有服务器初始序列号ISN_s。客户端收到SYN+ACK报文后，回复ACK报文，确认服务器的序列号（ACK号置为ISN_s+1）<ref name="ThreeWayHandshake" />。至此连接进入ESTABLISHED状态，双方可以进行数据通信<ref name="MSThreeWay">[https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/three-way-handshake-via-tcpip 透過 TCP/IP 進行三向交握的說明，Microsoft Learn.]</ref>。

CUBIC是Linux、Windows和macOS等主流操作系统中TCP拥塞控制的默认实现。与Reno的线性窗口增长不同，CUBIC使用三次函数来描述窗口随时间的增长曲线，在拥塞窗口接近上一次丢包时的窗口值后进入稳定区域，窗口增长较为平缓，在此稳定区域之外则采用更积极的窗口增长策略。CUBIC的窗口增长函数与RTT无关，使其在高带宽长距离网络以及存在不同RTT的竞争流时具有更好的扩展性和带宽利用率<ref name="CUBICDefault">[https://mail.openjdk.org/pipermail/security-dev/2024-August/001234.html HTTP Client CUBIC Congestion Control，OpenJDK Security-dev Mailing List.]</ref>。

在CUBIC之外，业界也发展出了多种旨在优化特定网络场景的TCP拥塞控制变体，包括但不限于：BBR（Google开发的基于瓶颈带宽和RTT的拥塞控制算法）、NewReno（对Reno算法在恢复机制上的改进和细化）、Westwood+（适用于无线网络的拥塞控制算法）以及Compound TCP（由微软开发，在长RTT高带宽环境中引入延迟敏感组件来改进拥塞窗口增长）。

TCP在数据完整性要求严格而时延容忍度相对宽松的场景中占据主导地位，其服务模型掩盖了丢包、乱序、重传和拥塞等底层网络的复杂性。绝大多数现代网络应用依赖TCP作为其传输协议：HTTP/1.x、HTTP/2及HTTP/3尽管QUIC使用了UDP和类似可靠性层，但web传统流量中的大部分仍运行于TCP之上；SMTP及IMAP/POP3邮件传输与收取；FTP数据与命令通道；SSH安全远程登录；Telnet早期远程登录；数据库客户端/服务器远程交互等。

TCP在设计之初优先考虑了数据可靠传输和流量/拥塞控制问题，安全并非首要设计目标。因此，TCP面临多种已知的安全威胁，包括TCP序列号预测攻击（1985年罗伯特·莫里斯最早描述）、会话劫持和连接复位攻击等。由于TCP头部校验和覆盖了IP伪头部部分信息，该校验和可以在一定程度上帮助接收端验证IP地址合法性，但并不提供对加密性的保证。在实际部署中，传输层安全协议（TLS）通常工作在TCP之上，通过在TCP字节流中插入加密/认证握手和加密数据帧，为上层应用提供通信的机密性、数据完整性及端到端身份认证能力。RFC 9293中提及早期TCP校验和依赖于伪头部中的IP源和目标地址进行校验，以维护TCP的端到端属性，但该设计也带来了一些对IP变化的不适应性。现代TCP安全主要依赖上层加密隧道和网络基础设施中的通用安全机制，而非协议本身的内建安全特征。

主流操作系统的内核协议栈中都包含TCP的完整实现。Linux内核的TCP/IP协议栈版本持续演进，长期支持Reno、CUBIC、BBR等多种拥塞控制算法并通过sysctl接口允许用户动态切换；微软Windows中的TCP/IP协议栈从Windows Vista和Windows Server 2008开始引入CTCP等多种改进，自Windows 10及Windows Server 2019起默认启用了基于类似CUBIC的拥塞控制和现代流量/拥塞窗口参数等调优；Apple的macOS和iOS则基于BSD协议栈的XNU内核TCP/IP实现，并同样将CUBIC作为默认拥塞控制算法；除上述完整内核实现外，学术界和嵌入式软件生态中还存在多个简约或形式验证驱动的TCP实现，例如LwIP、μC/TCP-IP以及经过高阶逻辑证明的TCP/HOL4实现等。