2.3. Window Size for Overlapping Requests (重叠请求的窗口大小)

2.3. Window Size for Overlapping Requests (重叠请求的窗口大小)

SET_WINDOW_SIZE 通知断言发送端能够为多个未决交换保存状态, 从而允许接收方在收到对第一个请求的响应之前发送多个请求. 与 SET_WINDOW_SIZE 通知关联的数据必须为 4 字节, 并以大端格式表示发送方承诺保存的消息数量. 在初始交换完成之前, 窗口大小始终为一.

除非 IKE 端点已从对等方收到 SET_WINDOW_SIZE Notify 消息, 获知对等方准备为维护多条在途消息的状态以提升吞吐, 否则 IKE 端点必须等待对其每条消息的响应之后, 才能发送后续消息.

IKE SA 建立后, 为最大化 IKE 吞吐, IKE 端点可以在收到任一条响应之前发出多条请求, 数量上限为其对等方 SET_WINDOW_SIZE 所设限制. 这些请求可能在网络上交错通过. IKE 端点必须准备在自身仍有请求未决时接受并处理请求, 以避免此种情形下的死锁. IKE 端点也可以在仍有请求未决时接受并处理多条请求.

IKE 端点绝对不能超过对等方声明的窗口大小来发送 IKE 请求. 换言之, 若响应方声明窗口大小为 N, 则当发起方需要发出请求 X 时, 必须已收到对直至请求 X-N 的全部响应. IKE 端点必须保存 (或能够完全再生) 其已发送的每条请求, 直到收到对应响应. IKE 端点必须保存 (或能够完全再生) 数量等于其声明窗口大小的先前响应, 以防响应丢失且发起方通过重传请求要求重传响应.

支持大于一的窗口大小的 IKE 端点应当能够对乱序到达的入站请求进行处理, 以在网络故障或分组重排时尽量提高性能.

窗口大小通常是特定实现的 (可配置的) 属性, 与拥塞控制无关 (例如不同于 TCP 的窗口). 特别是, 当响应方收到所含值小于当前生效值的 SET_WINDOW_SIZE 通知时应如何处理并未定义. 因此, 目前无法缩小已有 IKE SA 的窗口大小; 只能增大. 重密钥 IKE SA 时, 新 IKE SA 的窗口大小从 1 开始, 直到显式发送新的 SET_WINDOW_SIZE 通知增大为止.

当收到窗口支持范围之外的 IKE Message ID 时, 发送 INVALID_MESSAGE_ID 通知. 此类 Notify 消息绝对不能放在响应中发送; 绝对不能确认无效请求. 应通过发起 INFORMATIONAL 交换通知对端, Notification Data 中包含四字节的无效 Message ID. 发送此通知是可选的, 且此类通知必须限速.