跳到主要内容

5.4 Packetization Layer Actions (分组层操作)

5.4 Packetization Layer Actions (分组层操作)

分组层 (例如 TCP) 必须使用连接正在使用的路径的 PMTU; 它不应该发送会导致数据包大于 PMTU 的段 (segments), 除非在 PMTU 发现期间进行探测 (此探测数据包禁止被分片到 PMTU)。一个简单的实现可以在每次创建新段时向 IP 层询问此值, 但这可能效率低下。实现通常会缓存从 PMTU 派生的其他值。当 PMTU 改变时接收异步通知可能更简单, 以便这些变量也可以被更新。

TCP 实现还必须存储从其对等方 (peer) 接收到的最大段大小 (Maximum Segment Size, MSS) 值, 该值表示 EMTU_R, 即接收方可以重组的最大数据包, 并且禁止发送任何大于此 MSS 的段, 无论 PMTU 如何。

TCP MSS 选项中发送的值与 PMTU 无关; 它由接收方重组限制 EMTU_R 决定。此 MSS 选项值由连接的另一端使用, 该端可能使用不相关的 PMTU 值。有关选择 TCP MSS 选项值的信息, 请参见 [RFC8200] 的第 5 节 "Packet Size Issues" 和第 8.3 节 "Maximum Upper-Layer Payload Size"。

接收到 Packet Too Big 消息意味着发送 ICMPv6 消息的节点丢弃了一个数据包。可靠的上层协议将通过其自己的方式检测到这种丢失, 并通过其正常的重传方法进行恢复。重传可能会导致延迟, 这取决于上层协议使用的丢失检测方法。如果路径 MTU 发现过程需要多个步骤才能找到完整路径的 PMTU, 这最终可能会延迟重传许多往返时间 (round-trip times)。

或者, 可以立即响应路径 MTU 降低的通知而进行重传, 但仅针对 Packet Too Big 消息指定的特定连接。重传中使用的数据包大小应该不大于新的 PMTU。

注意: 确定探测数据包丢失的分组层需要调整重传的段大小。然而, 使用最后一个 Packet Too Big 消息中报告的大小可能会导致进一步的丢失, 因为路径中更远的路由器可能有更小的 PMTU 限制。这将导致所有重传段的丢失, 从而导致不必要的拥塞 (congestion) 以及每次新路由器宣布更小的 MTU 时发送额外的数据包。因此, 任何使用重传的分组层也负责其重传的拥塞控制 [RFC8085]。

由接收到 Packet Too Big 消息指示的 PMTU 探测引起的丢失禁止被视为拥塞通知 (congestion notification), 因此拥塞窗口 (congestion window) 可能不会改变。