4. Grouping packets into packet streams (将分组分组为分组流)
4. Grouping packets into packet streams (将分组分组为分组流)
本节解释如何将分组组合在一起成为分组流以进行压缩.为了实现最佳压缩率, 分组应该被组合在一起, 以便同一分组流中的分组具有相似的头.如果此分组失败, 头压缩性能将很差, 因为压缩算法很少能利用分组流的现有上下文, 并且必须频繁发送完整头.
分组由压缩器完成.压缩器可以使用它认为适当的任何标准将分组分组到分组流中.为了确定分组属于哪个分组流, 压缩器可以
a) 检查可压缩的子头链 (参见第 7 节),
b) 检查跟随可压缩子头链的上层协议头的内容, 例如 ICMP 头、DVMRP 头或隧道 IPX 头,
c) 使用从资源管理器获得的信息, 例如, 如果资源管理器请求特定分组流的压缩并提供识别属于该分组流的分组的方式,
d) 使用任何其他相关信息, 例如, 如果路由抖动并且分组流中的跳数限制 (TTL) 字段在 n 和 n+k 之间频繁变化, 压缩器可以选择将分组分组到两个不同的分组流中.
压缩器也可以不将分组分组到分组流中进行压缩, 让一些分组保留其常规头并不加修改地传递它们.
只要遵循何时为非 TCP 分组流发送完整头的规则, 并且按照本文档中的规定压缩子头, 解压缩器就能够正确重建压缩头, 而不管分组如何分组到分组流中.
4.1 Guidelines for grouping packets (分组分组的指南)
在本节中, 我们提供关于压缩器如何将分组分组到分组流中进行压缩的可选指南.
Defining fields (定义字段)
头的定义字段应该在属于同一分组流的所有分组中存在且相同.这些字段在第 7 节中标记为 DEF.定义字段包括流标签、IP 头的源和目的地地址、路由头中的最终目的地地址、下一个头字段 (对于 IPv6)、协议字段 (IPv4)、端口号 (UDP 和 TCP) 以及认证和加密头中的 SPI.
Fragmented packets (分片分组)
分片和未分片的分组永远不应该分组到同一分组流中.不应使用分片头或 IPv4 头的标识字段来识别分组流.如果是这样, 新分组的第一个分片将导致压缩慢启动.
在分片头之后或用于分片的 IPv4 头之后的任何字段都不应用于分组目的.
Upper protocol identification (上层协议识别)
标识第 7 节中未描述的头的第一个下一个头字段应用于识别分组流, 即, 具有相同 DEF 字段和相同上层协议的所有分组应该分组在一起.
TTL field (Hop Limit field) (TTL 字段 (跳数限制字段))
复杂的实现可能会监视 TTL (跳数限制) 字段, 如果它频繁更改, 则将其用作 DEF 字段.当存在频繁的路由抖动时可能会发生这种情况, 以便分组通过互联网遍历不同的路径.
Traffic Class field (IPv6), Type of Service field (IPv4) (流量类别字段 (IPv6), 服务类型字段 (IPv4))
IPv6 头的流量类别字段和 IPv4 头的服务类型可能在具有相同 DEF 字段的分组之间频繁更改.复杂的实现应该注意这一点, 并准备好将这些字段用作定义字段.
当 IP 分组被隧道传输时, 它们在隧道入口点用额外的 IP 头封装, 然后发送到隧道端点.为了将此类分组分组到分组流中, 还应该检查内部头以确定分组流.如果不这样做, 则每次内部 IP 分组的头更改时都将发送完整头.因此, 当分组被隧道传输时, 除了初始 IP 头的识别字段之外, 还应考虑内部子头的识别字段.
实现可以使用除此处描述的字段之外的其他字段进行识别.如果用于识别的字段太多, 性能可能会受到影响, 因为将使用更多的 CID, 并且当新流需要 CID 时可能会重复使用错误的 CID.如果用于识别的字段太少, 性能可能会受到影响, 因为对上下文的更改过于频繁.
我们强调这些指南是有根据的猜测.当 IPv6 被广泛部署并且可以分析 IPv6 流量时, 我们可能会发现其他分组算法表现更好.我们还强调, 如果分组失败, 结果将是性能差, 但不会导致不正确的解压缩.解压缩器可以完成其任务, 而不管分组算法如何工作.