TCP小结

1. 核心特性

面向连接：通过三次握手建立连接，四次挥手终止连接，确保通信双方状态同步。

TCP连接建立的3次握手

抓包：

client发出连接请求；

server回应client请求，并且同步发送syn连接；

client回应连接，至此3步握手完成。

TCP连接释放的4次握手

Client：192.168.2.100 -- server：192.168.2.101之间的TCP 4次挥手（释放连接）

client主动断开连接

 server确认断开，server主动断开，client确认断开。

可靠性传输：通过序列号、确认应答（ACK）、超时重传、重复ACK检测等机制保证数据完整有序。

序列号、确认应答（ACK）：

超时重传

重复ACK

全双工通信：双方可同时发送和接收数据。

字节流服务：数据被拆分为TCP段传输，接收方按序重组为连续字节流。

流量控制：通过滑动窗口机制动态调整发送速率，避免接收方缓冲区溢出。

什么是TCP窗口

TCP 采用流量控制（Flow Control）机制，使用滑动窗口（Sliding Window）来管理数据的发送和接收。

TCP 头部中的 窗口大小字段（Window Size） 指定了接收方当前可以接受的最大数据量，用于控制数据流，以防止接收方被发送方淹没。

窗口大小字段（16 位）最大能表示的值是 65,535（2¹⁶ - 1）字节，即约 64 KB，这个值在现代高速网络环境下严重不足，因此 TCP 提供了 Window Scale 选项来扩展窗口大小。

Window Scale选项的作用

Window Scale（窗口缩放）选项用于扩展 TCP 窗口的大小，使其支持最大 1GB（2³⁰ 字节）的窗口，而不是 64KB。

在 TCP 头部，窗口大小字段 只有 16 位，最大值为 65,535 字节（64KB）。

但是，高带宽-时延（BDP，Bandwidth Delay Product）网络环境下，64KB 可能会严重限制吞吐量。

Window Scale 选项通过左移窗口大小字段，扩展了窗口的范围，最大可达 1GB。

Window Scale 选项的工作原理

TCP 窗口扩展通过一个"缩放因子"（Scaling Factor）来扩大窗口的大小：

Window Scale 选项定义了一个因子 n（0 ≤ n ≤ 14），窗口大小的计算方式变为：

实际窗口大小=TCP 头部窗口大小字段×2^n(2的n次方)

其中：

   TCP 头部的窗口字段（Window Size） 仍然存储 16 位的值（最大 65,535）。

   缩放因子 n 在 Window Scale 选项中存储，范围是 0 到 14。

   最终的实际窗口大小最大可达 65,535 × 2¹⁴ = 1,073,725,440 字节（即 1GB）。

Window Scale 选项的格式

Kind    Length  Shift Count

+------+--------+-------------+

|  3     |   3      |     n         |

+------+--------+-------------+

字段解释：

Kind = 3：表示这是 Window Scale 选项。

Length = 3：整个字段占用 3 字节。

Shift Count：即缩放因子 n，接收方必须用 2^n 进行窗口扩展计算。

Window Scale 选项的协商（在 TCP 三次握手时）

Window Scale 选项只能在 TCP 三次握手期间协商，后续不能更改。

双方都必须在 SYN 报文中发送 Window Scale 选项，否则不会启用。

每一方独立协商自己的窗口缩放因子。

Tcp连接第一次握手协商win-mss-ws

Tcp连接第二次握手协商win-mss-ws

Tcp连接第三次握手协商win

TCP发送窗口和接收窗口

拥塞控制：通过慢启动、拥塞避免、快速重传/恢复等算法避免网络过载。

慢启动（Slow Start）：

初始拥塞窗口（cwnd）较小，每收到一个ACK，cwnd指数增长（如1, 2, 4, 8...）。

达到阈值（ssthresh）后进入拥塞避免阶段。

拥塞避免：

cwnd线性增长（如每RTT增加1），避免激进发送。

快速重传与快速恢复：

检测到3个重复ACK时，立即重传丢失包，并设置ssthresh = cwnd/2, cwnd = ssthresh + 3，进入快速恢复阶段。

超时重传（拥塞处理）：

超时表明严重拥塞，重置ssthresh = cwnd/2, cwnd = 1，重新慢启动。

1、慢启动；慢启动的算法：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。（慢启动呈指数增加）；

这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个栗子：

连接建立完成后，一开始初始化 cwnd = 1，表示可以传一个 MSS 大小的数据。

当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个

当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个

当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。可以看出慢启动算法，发包的个数是指数性的增长。

那慢启动涨到什么时候是个头呢？

有一个叫慢启动门限  ssthresh （slow start threshold）状态变量。

当 cwnd（拥塞窗口） < ssthresh 时，使用慢启动算法。

当 cwnd（拥塞窗口） >= ssthresh 时，就会使用「拥塞避免算法」。

2、拥塞避免；进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。（拥塞避免线性增长），当触发了重传机制，也就进入了「拥塞发生算法」。

前面说道，当拥塞窗口 cwnd 「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。

一般来说 ssthresh 的大小是 65535 字节。

那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的例子，现假定 ssthresh 为 8：当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。

当触发了重传机制，也就进入了「拥塞发生算法」。

3、拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：超时重传、快速重传

当发生了「超时重传」，就会使用拥塞发生算法。

这个时候，Ssthresh（慢启动门限） 和 cwnd（拥塞窗口） 的值会发生变化：

ssthresh 设为 cwnd/2（慢启动门限设置为当前拥塞窗口的1/2），

cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1），

接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。

发生快速重传的拥塞发生算法：

快速重传算法：当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

cwnd（拥塞窗口） = cwnd/2 ，也就是设置为原来的一半;

ssthresh（慢启动门限） = cwnd;

进入快速恢复算法。

4、快速恢复

快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。

进入快速恢复之前，cwnd 和 ssthresh 已被更新了：

cwnd = cwnd/2 ，也就是设置为原来的一半;

ssthresh = cwnd;

进入快速恢复算法如下：

1.拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；

2.重传丢失的数据包；

3.如果再收到重复的 ACK，那么 cwnd 增加 1；

4.如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；

2. 抓包分析技巧

Wireshark过滤：

  tcp.analysis.retransmission：定位重传包。

  tcp.analysis.window_update：观察窗口变化。

  tcp.options.sack：分析SACK块范围。

关键指标：

  重传率 = 重传包数 / 总包数（>1%需告警）。

  乱序深度：连续Out-Of-Order包数量。

  RTT波动：标准差反映网络稳定性。