jho*_*ack 3 networking tcp tcp-window-scaling
TCP 窗口大小是发送方在等待 TCP 确认之前将发送的数据量。接收方是否有办法控制这一点（例如，作为 TCP 握手的一部分），还是只有发送方可以控制？
是的，接收方可以在整个 TCP 通信过程中动态控制 TCP 窗口大小，而不仅仅是在握手时，如RFC 793 中所述：
流量控制：
TCP 为接收方提供了一种方法来管理发送方发送的数据量。这是通过返回一个带有每个 ACK 的“窗口”来实现的，该窗口指示除了成功接收的最后一段之外的可接受序列号的范围。 该窗口指示发送方在接收进一步许可之前可以传输的允许的八位字节数。
由于您添加了tcp-window-scaling，因此 TCP 窗口缩放只是用于克服最大窗口大小的初始限制 64k 的乘数。这是在初始 TCP 握手中使用 TCP 选项协商的，如RFC 7323 中所述：
Window Scale 选项协商 TCP 会话的基本参数。因此，它仅在初始握手期间发送。此外，
<SYN,ACK>仅当在初始<SYN>段中接收到相应选项时，才会在段中 发送窗口缩放选项。....
该选项可以在初始
<SYN>段中发送（即，
SYN 位打开而 ACK 位关闭的段）。如果
在初始<SYN>段中接收到Window Scale 选项，则可以
在该<SYN,ACK>段中发送该选项。
没有 SYN 位的段中的窗口缩放选项必须被忽略。
所以这个比例因子以后不能改变。它在那里进一步描述：
窗口缩放扩展将 TCP 窗口的定义扩展
到 30 位，然后使用隐式缩放因子
在 TCP 标头的 16 位窗口字段中携带这个30 位值（[RFC0793] 中的 SEG.WND）。比例因子的指数包含在 TCP
选项 Window Scale 中。此选项仅在一个段中发送（SYN 位打开的段），因此当打开连接时，窗口比例在每个方向上都是固定的。
下面是一个极端和异常窗口控制“滥用”的例子，它来自发明的接收器以延迟用于传播蠕虫的扫描：Linux iptables 的TARPIT附加目标，基于 LaBrea 的tar pit（Jim McClurg，2001 PDF）：
TARPIT
不使用本地的每个连接资源来捕获和保持传入的 TCP 连接。
[...] 像监听服务器一样运行，但除了发送 ACK 或 RST 之外，没有发送任何数据。[...]
--tarpit
此模式完成与攻击者的连接，但将窗口大小限制为 0，从而使攻击者等待很长时间。当他保持连接状态并每 60-240 秒尝试继续时，我们没有保留，因此它非常轻量级。关闭连接的尝试将被忽略，迫使远程端在 12-24 分钟内超时连接。此模式为默认模式。