TCP 接收窗口的最大可能大小。
接收窗口决定了 TCP 在必须等待接收方报告接收到该数据之前可以传输多少数据（以字节为单位）。这是由接收方宣布的。接收方将在读取并确认接收到传入数据时不断更新此值。接收窗口的当前值包含在 TCP 报头 中，它是 TCP 发送的每个数据段的一部分。因此，只要发送方接收到来自对等方的确认，它就知道当前的接收窗口。这意味着往返时间（RTT）越长，发送方获得接收窗口更新所需的时间就越长。、
TCP 支持可选扩展。这允许使用新特性增强协议，而无需立即更新所有实现。当 TCP 发起方连接到对等方时，它还会发送一个支持的扩展列表。所有扩展都遵循相同的格式：一个唯一的选项号，后跟选项的长度以及选项数据本身。
TCP 响应方检查连接请求中包含的所有选项号。如果它遇到一个不能理解的选项号，则会跳过 该选项号附带的“长度”字节的数据，并检查下一个选项号。响应方忽略了从答复中无法理解的内容。这使发送方和接收方都够理解所支持的公共选项集。
使用窗口缩放时，选项数据总是由单个数字组成。
用最简单的术语来说，TCP 时间戳只是在数据包上添加时间戳，以解决由非常快速的序列号回绕引起的歧义。如果一个段看起来包含新数据，但其时间戳早于上一个在接收窗口内的数据包，则该序列号已被重新回绕，而“新”数据包实际上是一个较旧的重复项。这解决了即使在极端情况下重传的歧义。
但是，该扩展不仅仅是检测旧数据包。TCP 时间戳的另一个主要功能是更精确的往返时间测量（RTTm）。
当两个对等方都支持时间戳时，每个 TCP 段都携带两个附加数字：时间戳值和回显时间戳。
在服务器端建立 TCP 连接
当连接请求到达的速度快于服务器应用程序可以接受新的传入连接的速度时，连接积压最终将达到其极限。这可能是由于系统配置错误或应用程序中的错误引起的。当一个或多个客户端发送连接请求而不对 “SYN ACK” 响应做出反应时，也会发生这种情况。这将用不完整的连接填充连接队列。这些条目需要几秒钟才会超时。这被称为“同步泛洪攻击”。
TCP 时间戳和 TCP Syn Cookie
即使队列已满，某些 TCP 协议栈也允许继续接受新连接。发生这种情况时，Linux 内核将在系统日志中打印一条突出的消息：
端口 P 上可能发生 SYN 泛洪。正在发送 Cookie。检查 SNMP 计数器。
此机制将完全绕过连接队列。通常存储在连接队列中的信息被编码到 SYN/ACK 响应 TCP 序列号中。当 ACK 返回时，可以根据序列号重建队列条目。
序列号只有有限的空间来存储信息。因此，使用 “TCP Syn Cookie” 机制建立的连接不能支持 TCP 选项。
但是，对两个对等点都通用的 TCP 选项可以存储在时间戳中。ACK 数据包在回显时间戳字段中反映了该值，这也允许恢复已达成共识的 TCP 选项。否则，cookie 连接受标准的 64KB 接收窗口限制。
常见误区 —— 时间戳不利于性能
不幸的是，一些指南建议禁用 TCP 时间戳，以减少内核访问时间戳时钟来获取当前时间所需的次数。这是不正确的。如前所述，RTT 估算是 TCP 的必要部分。因此，内核在接收/发送数据包时总是采用微秒级的时间戳。
在包处理步骤的其余部分中，Linux 会重用 RTT 估算所需的时钟时间戳。这还避免了将时间戳添加到传出 TCP 数据包的额外时钟访问。
整个时间戳选项在每个数据包中仅需要 10 个字节的 TCP 选项空间，这不会显著减少可用于数据包有效负载的空间。
