面向连接的运输：TCP

TCP连接

TCP报文段结构

往返时间估计与超时

可靠数据传输

回退N步or超时重传

超时间隔加倍

快速重传

流量控制

TCP连接管理

三次握手

1. 客户端 → 服务器：SYN 包

2. 服务器 → 客户端：SYN+ACK 包

3. 客户端 → 服务器：ACK 包

四次挥手

1. 主动关闭方 → 被动关闭方：FIN 包

2. 被动关闭方 → 主动关闭方：ACK 包

3. 被动关闭方 → 主动关闭方：FIN 包

4. 主动关闭方 → 被动关闭方：ACK 包

为什么必须要三次握手？

为什么不能用两次握手？

四次或更多次握手可行吗？

为什么要四次挥手？

为什么不能用三次挥手？

两次挥手可行吗？

TCP是因特网运输层面向连接的可靠传输协议。为了提供可靠数据传输，TCP依赖前文可靠数据传输原理许多基本原理，其中包括差错检测，重传，累积确认，定时器以及用于序号和确认号的首部字段等。

TCP连接

TCP 被称为面向连接的协议，核心在于其通信过程需要经历 “连接建立→数据传输→连接释放” 的完整生命周期。TCP 通信前必须通过三次报文交互，在客户端和服务器之间协商并确认连接参数，确保双方具备通信能力（三次握手）。通信结束后，需通过四次报文交互主动释放连接资源，确保双方无数据残留（四次挥手）。TCP 的 “面向连接” 本质是状态化通信，连接是一种状态实体，通信依赖连接状态的一致性，错误的处理基于连接的上下文。

TCP连接提供的是全双工服务，在一个 TCP 连接中，通信双方（客户端和服务器）可以同时进行数据的发送和接收，发送方和接收方的角色是动态的、非独占的。TCP 连接包含两条独立的逻辑通道，两条通道的数据流互不干扰，各自维护独立的序列号、确认号、滑动窗口等状态信息。

TCP被设计为点对点（Point-to-Point）协议，而非一对多（如组播或广播），这是由其协议特性、设计目标和底层网络架构共同决定的。TCP 的核心定位是在两个端点之间建立一条逻辑连接，通过序列号、确认机制、滑动窗口等复杂机制实现端到端的可靠数据传输。这些机制依赖于唯一的双向通信链路，要求发送方和接收方之间有明确的一一对应关系。若支持一对多（如同时向多个接收方发送数据），每个接收方的网络状态、接收能力、数据确认逻辑均不同，需为每个接收方单独维护一套状态（如序号、窗口、超时定时器等），这会导致协议复杂度呈指数级上升，甚至无法高效管理。

TCP 将数据视为无边界的字节流，保证数据按发送顺序到达接收方。在点对点场景中，通过单一序列号空间即可实现顺序控制；但在一对多场景中，每个接收方的字节流顺序独立，发送方需为每个接收方维护独立的序列号和确认逻辑，这与 TCP 的字节流抽象模型冲突。且一对多属于网络层或应用层的职责，而TCP 专注于传输层的端到端可靠性。

应用进程将数据写入套接字后，会先存于 TCP 发送缓存，等待合适时机发送（数据暂存）。发送缓存配合滑动窗口机制，根据接收方通告的窗口大小，控制发送数据量。若接收方接收缓存快满，通告小窗口值，发送方就减少从发送缓存提取数据发送的量，避免数据丢失（流量控制）。发送缓存中未被确认的数据，在超时未收到确认时会重传（可靠传输保证）。

TCP 报文段（TCP Segment）是 TCP在网络中传输数据的基本单位，它由首部和数据部分 组成，承载着从发送端到接收端的数据以及用于实现可靠传输的控制信息。

TCP接收方将网络中传来的 TCP 报文段，经解析后数据存于接收缓存，供应用进程读取（数据接收缓存）。当收到乱序的报文段，只要序号在接收窗口内，就暂存于接收缓存，等待正确顺序时交付应用进程（乱序处理）。接收缓存剩余空间大小，决定接收方通告给发送方的窗口大小，以此反馈控制发送方发送速率（流量反馈依据）。

TCP可从缓存中取出并且放入报文段的数据数量受限于最大报文段长度（MSS）。MSS 指的是 TCP 报文段中所能承载的应用层数据的最大字节数，不包括 TCP 首部（通常 20 字节）和 IP 首部（通常 20 字节）。MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度，即所谓的最大传输单元（MTU）来设置。

MTU 指的是在数据链路层中，一个数据帧所能够携带的最大有效载荷（不包含帧头、帧尾等链路层控制信息）的字节数。不同的数据链路层协议，MTU 的默认值有所不同。比如，以太网的 MTU 默认值是 1500 字节，PPP 协议的 MTU 默认值通常为 1500 字节或 296 字节，FDDI（光纤分布式数据接口）的 MTU 则为 4352 字节。

比如，若 MSS 值为 1460 字节，那么加上 20 字节的 TCP 首部和 20 字节的 IP 首部后，整个 IP 数据报长度就是 1500 字节，这恰好是以太网默认的最大传输单元（MTU）。

TCP报文段结构

TCP 报文段首部长度通常为 20 字节（不含TCP可选字段），最多可达 60 字节，包含了实现可靠传输、连接管理等功能的关键控制信息，具体如下：

源端口号和目的端口号：各占 16 比特，标识发送方和接收方应用进程所使用的端口，帮助数据准确交付给对应的应用程序。
序号：占 32 比特，标记本报文段在发送方数据字节流中的位置，用于接收方对数据进行排序。
确认号：占 32 比特，是接收方期望接收的下一个字节的序号，用于向发送方确认已收到的数据。
首部长度：占 4 比特，指示 TCP 首部的长度，以 4 字节为单位，用于明确首部结束和数据开始的位置。
标志位：占 6 比特，包含多个标志：
- URG：紧急标志，URG = 1 时表示报文中有紧急数据。
- ACK：确认标志，ACK = 1 时确认号字段才有效。
- PSH：推送标志，指示接收方尽快将数据交付给上层应用。
- RST：重置标志，用于异常时重置连接。
- SYN：同步标志，在连接建立时同步序号。
- FIN：结束标志，在连接释放时通知对方本方无数据发送。
窗口大小：占 16 比特，接收方通过该字段告知发送方自己当前接收缓冲区的剩余空间大小，实现流量控制。
校验和：占 16 比特，用于检测 TCP 报文段在传输过程中是否出错，计算范围包括首部、数据部分以及一个伪首部。
紧急指针：占 16 比特，当 URG 标志位为 1 时有效，指出本报文段中紧急数据的最后一个字节的序号。
选项：长度可变，最多 40 字节，用于协商额外参数，如最大段大小（MSS）、窗口扩大因子、时间戳等。
数据部分：承载的是应用层实际要传输的数据，长度可变，受最大段大小（MSS）限制。在连接建立阶段，客户端和服务器会协商 MSS 值，以确保加上 IP 首部后的整个报文长度不超过链路层的最大传输单元（MTU），避免 IP 分片。

在 TCP 报文段结构中，序号和确认号是实现可靠传输最核心的两个字段。

TCP把数据看成无结构的，有序的字节流。序号是建立在传送的字节流之上，而不是建立在传送的报文段序列之上。因此一个报文段的序号就是该报文段首字节的字节流编号。

序号标识本报文段所携带数据在发送方字节流中的起始位置，用于解决数据分片后的排序问题。例如，若发送方发送的第一个报文段携带 1000 字节数据，序号为500，则下一个报文段的序号为1500。接收方通过序号判断数据是否按序到达，对乱序数据进行缓存或重传请求。在连接建立（三次握手）时，序号用于同步初始序列号（ISN），避免历史数据干扰新连接。

接收方通过确认号告知发送方期望接收的下一个字节的序号，表示 “该序号之前的数据已全部正确接收”。例如，接收方收到序号1-1000的数据后，会返回确认号1001，表示希望接收1001及之后的数据。发送方根据确认号判断哪些数据已被成功接收，哪些需要重传（基于超时重传机制）。同时实现可靠传输的双向确认：不仅发送方需要确认接收方收到数据，接收方也通过确认号主动告知发送方状态。

TCP 通过 “序号 + 确认号” 机制实现数据的有序性、完整性和去重性，是可靠传输的基础，其他字段均围绕二者提供辅助或扩展功能。

往返时间估计与超时

显然，由于路由器的拥塞和端系统负载的变化，TCP报文段中的rtt值也会随之波动，所以任何给定的RTT值也许不是典型的，所以这也造就了一个明显的问题：设置超时间隔的长度。因此为了估计一个典型的RTT，自然要对RTT进行一个均值操作。

TCP 采用一种基于采样的方法来估计 RTT。最初，TCP 会对每个发送的报文段进行计时，当收到对应的 ACK 时，计算实际的往返时间。然后通过加权平均的方式更新对 RTT 的估计值，一旦获得一个新的RTT,TCP就会用以下公式更新均值：

其中α是一个加权因子（通常取值在 0.125 左右），SampleRTT是当前测量得到的样本往返时间。

除了估算RTT以外，测量RTT的变化也是很有必要的。DEVrtt用于衡量往返时间估计值的波动情况，是计算超时时间的重要参数之一。

其中，β也是一个加权因子，一般取值为 0.25。该公式的作用是计算往返时间估计值的偏差。|SampleRTT - EstimatedRTT| 表示样本往返时间与估计往返时间的差值的绝对值，通过加权平均的方式更新 DEVrtt ，从而反映出样本往返时间围绕估计往返时间的波动程度。

既然已经给出了EstimateRTT和DevRTT的值，TCP 的超时间隔（Timeout Interval，简称 RTO）通常使用：

其中：δ 是一个经验系数，该系数用于放大 EstimatedRTT 的权重，确保超时间隔足够覆盖网络波动。 4 是 δ 的典型取值，通过将偏差放大 4 倍，使 RTO 对网络延迟的波动更敏感。

可靠数据传输

在 TCP 协议中，定时器的设置是保障可靠传输的关键机制之一。TCP 使用多种定时器来处理不同场景，其中最核心的是超时重传定时器。

TCP采用的是单计时器模型，发送方每次发送 新数据 时，若当前没有活跃的定时器，则启动一个覆盖 最早未确认数据 的定时器。当收到 最早未确认数据的 ACK 时，停止定时器。

第二个主要事件是超时处理，TCP通过超时重传来响应超时事件，然后重启定时器。

回退N步or超时重传

TCP 的可靠性机制部分借鉴了 GBN 和 SR 的思想，根据自身需求进行了优化和融合。

TCP使用滑动窗口机制，但 默认采用累积确认（与 GBN 类似），TCP 的滑动窗口大小可变（动态调整），而 GBN 窗口大小固定。TCP同样为未确认的数据设置定时器，超时后重传 最早未确认的分组及之后的数据（类似 GBN 的回退重传）。但是TCP 引入 快速重传机制，减少不必要的超时等待。

TCP引入 选择性确认（SACK）选项（类似SR），作为累积确认的补充。当接收方收到失序分组时，可通过 SACK 告知发送方具体哪些分段已接收，发送方只需重传未被确认的分段。但SACK 是 TCP 的可选功能（需双方协商启用），而累积确认是默认机制。接收方同样会缓存失序分组（通过接收窗口实现），并在收到丢失分组后按序交付。

超时间隔加倍

在 TCP 协议中，超时间隔加倍（Exponential Backoff） 是一种应对网络拥塞或丢包的重要机制，属于超时重传策略的一部分。当 TCP 发送方多次尝试重传数据仍失败时，会逐步指数级增大超时时间，避免因频繁重传加剧网络拥塞。

当 TCP 发送一个报文段后，会启动一个定时器。若在 RTO 时间内未收到该报文段的确认（ACK），则认为报文段丢失，触发重传。

首次超时按正常 RTO 值重传，后续超时每次重传后，将 RTO 值翻倍（即指数级增长）。为避免 RTO 无限增长，TCP 通常设置上限（如 64 秒）。当 RTO 达到上限后，继续重传但不再增加 RTO。

超时间隔加倍避免网络拥塞，若每次超时都以固定时间重传，可能导致大量重传报文段同时涌入网络，加剧拥塞（如 “拥塞崩溃”）。指数退避通过减缓重传频率，给网络留出恢复时间。

区分临时丢包和持续问题：

临时丢包（如网络抖动）：较小的 RTO 即可快速恢复。
持续丢包（如链路故障）：需要更长的 RTO 避免无效重传。

超时重传 → RTO指数级增长 → 降低重传频率 → 缓解网络拥塞 这一机制是 TCP自适应网络变化的关键，通过动态调整超时时间，在可靠性和效率之间找到平衡，尤其适用于高延迟或不稳定的网络环境。

快速重传

快速重传是 TCP 协议中用于快速恢复丢失报文段的机制，乱序不影响最终确认，但是会触发重传机制。通过重复确认冗余ACK（Duplicate ACK）触发重传，无需等待超时定时器到期，从而减少丢包导致的延迟。

接收方通过累加确认，只会确认按序到达的连续字节流末尾，未按序到达的字节会导致后续确认被阻断。

当接收方收到失序报文段时，会发送重复 ACK（即对最近连续收到的最高序号的确认）。发送方收到3 个重复 ACK，判定该序号的报文段丢失，立即重传，无需等待超时。

快速重传 = 3次重复ACK触发 + 立即重传丢失报文段 + 低延迟恢复传输该机制是 TCP 实现可靠传输和高吞吐量的核心技术之一，通过快速响应轻度丢包，显著提升了网络传输效率，尤其适用于实时性要求较高的场景。

流量控制

TCP流量控制为了防止发送方发送速率超过接收方处理能力，避免接收方缓冲区溢出导致丢包。通过动态调整发送窗口大小，使发送速率与接收方处理能力匹配。

核心机制：滑动窗口协议

接收窗口（Advertised Window, rwnd）
- 接收方通过 ACK 报文携带rwnd字段，告知发送方自己当前可用的接收缓冲区大小（字节）。
- 计算公式：rwnd = 接收缓冲区总大小 - 已占用空间。
发送窗口（Send Window）
- 发送方根据接收方的rwnd动态调整自己的发送窗口大小，确保已发送但未确认的数据量 ≤ rwnd。
- 发送窗口大小 = min (rwnd, cwnd)，其中cwnd为拥塞窗口（由拥塞控制决定）。

初始协商：连接建立时，双方通过 SYN 报文交换初始窗口大小（默认值通常为 4KB）。

动态调整：接收方每处理一批数据，通过 ACK 报文更新rwnd。发送方根据最新rwnd调整发送窗口，控制后续发送速率。

零窗口通知：当接收方缓冲区已满，rwnd = 0，发送方暂停发送，进入 ** 窗口探查（Window Probe）** 状态。

窗口探查：发送方定期发送窗口探测报文（1 字节数据），触发接收方回复最新rwnd，避免死锁。

该机制通过接收窗口实现端到端的速率匹配，确保接收方不会因过载而丢包。UDP没有流量控制，报文段由于缓存溢出可能在接收方丢失。