网络基础 7 TCP IP协议 2
④TCP保证可靠性的机制
| 机制 | 原理 | 记忆梗 |
|---|---|---|
| 建立连接+序号机制 | 建立连接→保证连接实体真实存在，序号机制→保证数据是按序、完整到达 | |
| 合理分片 | TCP会按最大传输单元(MTU)合理分片，接收方会缓存未按序到达的数据，重新排序后交给应用层 | |
| 数据校验 | TCP报文头有校验和，用于校验报文是否损坏 | |
| 超时重传 | 如果发送一直收不到应答，可能是发送数据丢失，也可能是应答丢失，发送方再等待一段时间之后都会进行重传 | 确认不到，再发一票 |
| 流量控制 | 当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失 | 别送太快，我家收件箱要爆了 |
| 拥塞控制 | 网络层拥堵造成的拥塞，包括慢开始，拥塞避免，快速重传和快速恢复 | 堵车就减速，通畅再加速 |
(a) 建立连接+序号机制
- 建立连接（三次握手）
- 确认通信能力：确保双方收发功能正常。
- 同步初始序号（ISN）：为后续数据包提供排序基准。
- 序号机制（Sequence Number）
- 标识数据顺序：每个字节分配唯一序号，解决乱序问题。
- 确认应答（ACK）：通过
ack=下一个期望序号，保证数据完整到达。 - 重传丢包：超时未收到ACK则重发，避免数据丢失。
(b) 合理分片
- 避免IP层强制分片
- TCP按**MSS（最大报文段大小）**主动分片，比IP层分片更可靠（IP分片丢失=整个包重传）
- MTU = MSS + TCP/IP头（通常MSS=1460，MTU=1500）
- 提升传输效率
- 分片大小适配网络路径MTU（Path MTU Discovery）
- 小分片减少重传成本（丢一片只需重传一片）
- 保证可靠性
- 每个分片有独立序号，接收方按序重组
- 分片丢失会触发快速重传（无需等超时）
(c) 数据校验
- 错误检测
- 校验和（Checksum）：计算TCP头部+数据的16位反码和，接收方验证一致性
- 发现错误直接丢弃包，触发重传机制
- 完整性保护
- 覆盖TCP头部+数据+伪头部（IP核心字段），防止传输中比特翻转
- 关键字段保护：序列号、ACK号、标志位等
- 可靠性兜底
- 配合序号/ACK机制，形成双重保险（校验防损坏，序号防乱序）
- 物理层CRC校验后，TCP层再加固防护
(d) 超时重传
- 丢包兜底机制
- 每个发送的包启动超时定时器（RTO）
- 未收到ACK且超时，立即重传数据包
- 动态超时阈值
- 根据**RTT（往返时间）**实时计算RTO
- 公式：
RTO = 平均RTT + 4×RTT波动值（避免过早/过晚重传）
- 可靠性最后防线
- 与快速重传（重复ACK）形成互补
- 极端网络下仍能保证数据可达
此外，数据也不会被反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。
(e) 流量控制
流量控制和拥塞控制对比：
✅ 谁控制？ → 接收方（通过 rwnd 限制发送方）
✅ 目标？ → 防止接收方缓冲区溢出
通俗的理解：把报文当成包裹，你家客户的收件箱（接收方的缓冲区）只能收10个包裹，如果你一次性发20个，那就放不下会有丢弃的情况（丢包），所以客户在签收时每次都会告诉你我这里还能放多少，比如说还能放5个（rwnd=5），那下次发送就只发送5个，避免溢出
(f) 拥塞控制
✅ 谁控制？ → 发送方（通过 cwnd 适应网络状况）
✅ 目标？ → 避免网络拥堵
✅ 两种情况 → 部分丢包和完全阻塞
流程：慢拥快重恢
- 慢开始：采用慢开始算法，拥塞窗口指数级增长。
- 拥塞避免：拥塞窗口达到慢开始门限（ssthresh）时，进入拥塞避免阶段，拥塞窗口线性增长。
- 超时重传：若一定时间内没收到接收方ack，触发超时重传，表明网络出现严重拥塞，将慢开始门限设置为当前拥塞窗口的一半，拥塞窗口重置为1个MSS，重新开始慢开始过程。
- 快速重传和快速恢复：若连续收到3个重复ACK，执行快速重传和快速恢复算法，调整拥塞窗口和慢开始门限，然后进入拥塞避免阶段。
(g) 滑动窗口控制
上图中的窗口内的数据即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机需要设置缓存保留这些待被重传的数据，直到收到他们的确认应答。 在滑动窗口以外的部分包括未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓存区清除。 收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也别称为滑动窗口控制。
(h) 窗口控制中的重发控制
在使用窗口控制中， 出现丢包一般分为两种情况：
① 确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的，如下图：
部分确认应答丢失
② 某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序列号以外的数据时，会针对当前为止收到数据返回确认应答。如下图所示，当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，因此，在窗口比较大，又出现报文段丢失的情况下，同一个序列号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答，就会将其对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称为高速重发控制。
