Network Working Group M. West
Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
Network Working Group M. West
Request for Comments: 4413 S. McCann
Category: Informational Siemens/Roke Manor Research
March 2006
TCP/IP Field Behavior
TCP/IP字段行为
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers.
此备忘录描述了头压缩上下文中的TCP/IP字段行为。报头压缩是可能的，因为大多数报头字段不会随数据包随机变化。许多字段以或多或少可预测的方式显示静态行为或更改。在设计报头压缩方案时，详细了解字段的行为非常重要。这种分析的一个例子可以在RFC 3095中看到。此备忘录对TCP/IP头的压缩执行类似的作用。
Table of Contents
目录
1. Introduction ....................................................3
2. General classification ..........................................4
2.1. IP Header Fields ...........................................5
2.1.1. IPv6 Header Fields ....................................5
2.1.2. IPv4 Header Fields ....................................7
2.2. TCP Header Fields .........................................10
2.3. Summary for IP/TCP ........................................11
3. Classification of Replicable Header Fields .....................11
3.1. IPv4 Header (Inner and/or Outer) ..........................12
3.2. IPv6 Header (inner and/or outer) ..........................14
3.3. TCP Header ................................................14
3.4. TCP Options ...............................................15
3.5. Summary of Replication ....................................16
4. Analysis of Change Patterns of Header Fields ...................16
4.1. IP Header .................................................19
4.1.1. IP Traffic-Class / Type-Of-Service (TOS) .............19
4.1.2. ECN Flags ............................................19
4.1.3. IP Identification ....................................20
4.1.4. Don't Fragment (DF) flag .............................22
4.1.5. IP Hop-Limit / Time-To-Live (TTL) ....................22
4.2. TCP Header ................................................23
4.2.1. Sequence Number ......................................23
4.2.2. Acknowledgement Number ...............................24
4.2.3. Reserved .............................................25
4.2.4. Flags ................................................25
4.2.5. Checksum .............................................26
4.2.6. Window ...............................................26
4.2.7. Urgent Pointer .......................................27
4.3. Options ...................................................27
4.3.1. Options Overview .....................................28
4.3.2. Option Field Behavior ................................29
5. Other Observations .............................................36
5.1. Implicit Acknowledgements .................................36
5.2. Shared Data ...............................................36
5.3. TCP Header Overhead .......................................37
5.4. Field Independence and Packet Behavior ....................37
5.5. Short-Lived Flows .........................................37
5.6. Master Sequence Number ....................................38
5.7. Size Constraint for TCP Options ...........................38
6. Security Considerations ........................................39
7. Acknowledgements ...............................................39
8. References .....................................................40
8.1. Normative References ......................................40
8.2. Informative References ....................................41
1. Introduction ....................................................3
2. General classification ..........................................4
2.1. IP Header Fields ...........................................5
2.1.1. IPv6 Header Fields ....................................5
2.1.2. IPv4 Header Fields ....................................7
2.2. TCP Header Fields .........................................10
2.3. Summary for IP/TCP ........................................11
3. Classification of Replicable Header Fields .....................11
3.1. IPv4 Header (Inner and/or Outer) ..........................12
3.2. IPv6 Header (inner and/or outer) ..........................14
3.3. TCP Header ................................................14
3.4. TCP Options ...............................................15
3.5. Summary of Replication ....................................16
4. Analysis of Change Patterns of Header Fields ...................16
4.1. IP Header .................................................19
4.1.1. IP Traffic-Class / Type-Of-Service (TOS) .............19
4.1.2. ECN Flags ............................................19
4.1.3. IP Identification ....................................20
4.1.4. Don't Fragment (DF) flag .............................22
4.1.5. IP Hop-Limit / Time-To-Live (TTL) ....................22
4.2. TCP Header ................................................23
4.2.1. Sequence Number ......................................23
4.2.2. Acknowledgement Number ...............................24
4.2.3. Reserved .............................................25
4.2.4. Flags ................................................25
4.2.5. Checksum .............................................26
4.2.6. Window ...............................................26
4.2.7. Urgent Pointer .......................................27
4.3. Options ...................................................27
4.3.1. Options Overview .....................................28
4.3.2. Option Field Behavior ................................29
5. Other Observations .............................................36
5.1. Implicit Acknowledgements .................................36
5.2. Shared Data ...............................................36
5.3. TCP Header Overhead .......................................37
5.4. Field Independence and Packet Behavior ....................37
5.5. Short-Lived Flows .........................................37
5.6. Master Sequence Number ....................................38
5.7. Size Constraint for TCP Options ...........................38
6. Security Considerations ........................................39
7. Acknowledgements ...............................................39
8. References .....................................................40
8.1. Normative References ......................................40
8.2. Informative References ....................................41
This document describes the format of the TCP/IP header and the header field behavior, i.e., how fields vary within a TCP flow. The description is presented in the context of header compression.
本文档描述TCP/IP标头的格式和标头字段行为，即TCP流中字段的变化方式。描述在头压缩的上下文中给出。
Since the IP header does exhibit slightly different behavior from that previously presented in RFC 3095 [31] for UDP and RTP, it is also included in this document.
由于IP报头的行为与之前在RFC 3095[31]中针对UDP和RTP给出的行为略有不同，因此它也包含在本文档中。
This document borrows much of the classification text from RFC 3095 [31], rather than inserting many references to that document.
本文档借用了RFC 3095[31]中的大部分分类文本，而不是插入对该文档的许多引用。
According to the format presented in RFC 3095 [31], TCP/IP header fields are classified and analyzed in two steps. First, we have a general classification in Section 2, where the fields are classified on the basis of stable knowledge and assumptions. This general classification does not take into account the change characteristics of changing fields, as those will vary more or less depending on the implementation and on the application used. Section 3 considers how field values can be used to optimize short-lived flows. A more detailed analysis of the change characteristics is then done in Section 4. Finally, Section 5 summarizes with conclusions about how the various header fields should be handled by the header compression scheme to optimize compression.
根据RFC 3095[31]中给出的格式，TCP/IP头字段分两步进行分类和分析。首先，我们在第2节中有一个一般分类，根据稳定的知识和假设对字段进行分类。这种一般分类没有考虑变化字段的变化特征，因为这些变化特征或多或少取决于实现和使用的应用程序。第3节考虑如何使用字段值优化短期流。第4节对变化特征进行了更详细的分析。最后，第5节总结了头压缩方案应如何处理各种头字段以优化压缩的结论。
A general question raised by this analysis is: what 'baseline' definition of all possible TCP/IP implementations is to be considered? This review is based on an analysis of currently deployed TCP implementations supporting mechanisms standardised by the IETF.
该分析提出的一个普遍问题是：所有可能的TCP/IP实现的“基线”定义是什么？本综述基于对当前部署的支持IETF标准化机制的TCP实现的分析。
The general requirement for transparency is also interesting. A number of recent proposals for extensions to TCP use some of the previously 'reserved' bits in the TCP packet header. Therefore, a 'reserved' bit cannot be taken to have a guaranteed zero value; it may change. Ideally, this should be accommodated by the compression profile.
透明度的一般要求也很有趣。最近一些关于TCP扩展的建议在TCP数据包头中使用了一些以前的“保留”位。因此，“保留”位不能被视为有保证的零值；它可能会改变。理想情况下，这应通过压缩剖面进行调节。
A number of reserved bits are available for future expansion. A treatment of field behavior cannot predict the future use of such bits, but we expect that they will be used at some point. Given this, a compression scheme can optimise for the current situation but should be capable of supporting any arbitrary usage of the reserved bits. However, it is impossible to optimise for usage patterns that have yet to be defined.
许多保留位可用于将来的扩展。对场行为的处理无法预测此类比特的未来使用，但我们预计它们将在某个时候被使用。鉴于此，压缩方案可针对当前情况进行优化，但应能够支持保留位的任意使用。但是，不可能优化尚未定义的使用模式。
The following definitions (and some text) are copied from RFC 3095 [31], Appendix A. Differences of IP field behavior between RFC 3095 [31] (i.e., IP/UDP/RTP behavior for audio and video applications) and this document have been identified.
以下定义（和一些文本）摘自RFC 3095[31]，附录A。已确定RFC 3095[31]（即音频和视频应用的IP/UDP/RTP行为）与本文件之间的IP字段行为差异。
For the following, we define "session" as a TCP packet stream, being a series of packets with the same IP addresses and port numbers. A packet flow is defined by certain fields (see STATIC-DEF, below) and may be considered a subset of a session. See [31] for a fuller discussion of separation of sessions into streams of packets for header compression.
对于以下内容，我们将“会话”定义为TCP数据包流，即具有相同IP地址和端口号的一系列数据包。数据包流由某些字段定义（见下文的STATIC-DEF），可以被视为会话的子集。有关将会话分离为数据包流以进行报头压缩的更全面讨论，请参见[31]。
At a general level, the header fields are separated into 5 classes:
在一般级别，标题字段分为5类：
o INFERRED
o 推断
These fields contain values that can be inferred from other values (for example, the size of the frame carrying the packet) and thus do not have to be handled at all by the compression scheme.
这些字段包含可以从其他值（例如，承载数据包的帧的大小）推断的值，因此根本不必由压缩方案处理。
o STATIC
o 静止的
These fields are expected to be constant throughout the lifetime of the packet stream. Static information must in some way be communicated once.
这些字段在数据包流的整个生命周期内都是恒定的。静态信息必须以某种方式通信一次。
o STATIC-DEF
o 静态-DEF
STATIC fields whose values define a packet stream. They are in general handled as STATIC.
其值定义数据包流的静态字段。它们通常被视为静态的。
o STATIC-KNOWN
o 静态已知
These STATIC fields are expected to have well-known values and therefore do not need to be communicated at all.
这些静态字段应具有众所周知的值，因此根本不需要进行通信。
o CHANGING
o 改变
These fields are expected to vary randomly within a limited value set or range or in some other manner.
这些字段预期在有限的值集或范围内或以其他方式随机变化。
In this section, each of the IP and TCP header fields is assigned to one of these classes. For all fields except those classified as CHANGING, the motives for the classification are also stated. In section 4, CHANGING fields are further examined and classified on the basis of their expected change behavior.
在本节中，每个IP和TCP头字段都分配给其中一个类。对于除被归类为变化的领域外的所有领域，也说明了分类的动机。在第4节中，根据预期的变化行为，对变化领域进行了进一步的检查和分类。
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT,
and CE flags were amalgamated into the Traffic
Class octet in RFC 3095).
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT,
and CE flags were amalgamated into the Traffic
Class octet in RFC 3095).
Figure 1. IPv6 Header Fields
图1。IPv6头字段
o Version
o 版本
The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC.
版本字段说明使用哪个IP版本。此字段中具有不同值的数据包必须由不同的IP堆栈处理。因此，数据包流的所有数据包必须具有相同的IP版本。因此，该字段被分类为静态字段。
o Flow Label
o 流标签
This field may be used to identify packets belonging to a specific packet stream. If the field is not used, its value should be zero. Otherwise, all packets belonging to the same stream must have the same value in this field, it being one of the fields that define the stream. The field is therefore classified as STATIC-DEF.
该字段可用于识别属于特定分组流的分组。如果未使用该字段，则其值应为零。否则，属于同一流的所有数据包在此字段中必须具有相同的值，它是定义流的字段之一。因此，该字段被分类为STATIC-DEF。
o Payload Length
o 净荷长度
Information about packet length (and, consequently, payload length) is expected to be provided by the link layer. The field is therefore classified as INFERRED.
关于分组长度（以及因此有效负载长度）的信息预期由链路层提供。因此，该字段被归类为推断字段。
o Next Header
o 下一包头
This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header. Only when extension headers are sometimes absent will the field change its value during the lifetime of the stream. The field is therefore classified as STATIC. The classification of STATIC is inherited from RFC 3095 [31]. However, note that the next header field is actually determined by the type of the following header. Thus, it might be more appropriate to view this as an inference, although this depends upon the specific implementation of the compression scheme.
该字段通常在数据包流的所有数据包中具有相同的值。它对后续标头的类型进行编码。只有当扩展头有时不存在时，字段才会在流的生存期内更改其值。因此，该字段被归类为静态字段。静态分类继承自RFC 3095[31]。但是，请注意，下一个标头字段实际上是由下一个标头的类型决定的。因此，尽管这取决于压缩方案的具体实现，但将其视为推论可能更合适。
o Source and Destination Addresses
o 源地址和目标地址
These fields are part of the definition of a stream and therefore must be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
这些字段是流定义的一部分，因此对于流中的所有数据包都必须是常量。因此，这些字段被分类为STATIC-DEF。
This might be considered as a slightly simplistic view. In this document, the IP addresses are associated with the transport layer connection and assumed to be part of the definition of a flow. More complex flow-separation could, of course, be considered (see also RFC 3095 [31] for more discussion of this issue). Where tunneling is being performed, the use of the IP addresses in outer tunnel headers is also assumed to be STATIC-DEF.
这可能被认为是一种稍微简单化的观点。在本文档中，IP地址与传输层连接关联，并假定为流定义的一部分。当然，可以考虑更复杂的流动分离（有关此问题的更多讨论，请参见RFC 3095[31]）。在执行隧道的情况下，外部隧道头中IP地址的使用也假定为静态-DEF。
The total size of the fields in each class is as follows:
每个类中字段的总大小如下所示：
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| STATIC-KNOWN | 0 |
| CHANGING | 2 |
+--------------+--------------+
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| STATIC-KNOWN | 0 |
| CHANGING | 2 |
+--------------+--------------+
Figure 2: Field sizes
图2：字段大小
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING |
| Don't Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT
and CE flags were amalgamated into the TOS
octet in RFC 3095; the DF flag behavior is
considered later; the reserved field is
discussed below).
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| DSCP* | 6 | ALTERNATING |
| ECT flag* | 1 | CHANGING |
| CE flag* | 1 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag* | 1 | CHANGING |
| Don't Fragment flag*| 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
* Differs from RFC 3095 [31]. (The DSCP, ECT
and CE flags were amalgamated into the TOS
octet in RFC 3095; the DF flag behavior is
considered later; the reserved field is
discussed below).
Figure 3. IPv4 Header Fields
图3。IPv4标头字段
o Version
o 版本
The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC.
版本字段说明使用哪个IP版本。此字段中具有不同值的数据包必须由不同的IP堆栈处理。因此，数据包流的所有数据包必须具有相同的IP版本。因此，该字段被分类为静态字段。
o Header Length
o 包头长度
As long as no options are present in the IP header, the header length is constant and well known. If there are options, the fields would be STATIC, but it is assumed here that there are no options. The field is therefore classified as STATIC-KNOWN.
只要IP报头中不存在任何选项，报头长度就会保持不变并且众所周知。如果有选项，字段将是静态的，但此处假定没有选项。因此，该字段被归类为静态-已知字段。
o Packet Length
o 数据包长度
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
有关数据包长度的信息预计将由链路层提供。因此，该字段被归类为推断字段。
o Flags
o 旗帜
The Reserved flag must be set to zero, as defined in RFC 791 [1]. In RFC 3095 [31] the field is therefore classified as STATIC-KNOWN. However, it is expected that reserved fields may be used at some future point. It is undesirable to select an encoding that would preclude the use of a compression profile for a future change in the use of reserved fields. For this reason, the alternative encoding of CHANGING is used. (A compression profile can, of course, still optimise for the current situation, where the field value is known to be 0).
保留标志必须设置为零，如RFC 791[1]中所定义。因此，在RFC 3095[31]中，该字段被归类为静态已知字段。但是，预计在将来的某个时候可能会使用保留字段。不希望选择一种编码方式，这种编码方式会阻止在将来更改保留字段的使用时使用压缩配置文件。因此，使用了变更的替代编码。（当然，压缩剖面仍然可以针对当前情况进行优化，其中已知字段值为0）。
The More Fragments (MF) flag is expected to be zero because fragmentation is, ideally, not expected. However, it is also understood that some scenarios (for example, some tunnelling architectures) do cause fragmentation. In general, though, fragmentation is not expected to be common in the Internet due to a combination of initial MSS negotiation and subsequent use of path-MTU discovery. RFC 3095 [31] points out that, for RTP, only the first fragment will contain the transport layer protocol header; subsequent fragments would have to be compressed with a different profile. This is also obviously the case for TCP. If fragmentation were to occur, the first fragment, by definition, would be relatively large, minimizing the header overhead. Subsequent fragments would be compressed with another profile. It is therefore considered undesirable to optimise for fragmentation in performing header compression. The More Fragments flag is therefore classified as STATIC-KNOWN.
More Fragments（MF）标志应为零，因为理想情况下，不应出现碎片。但是，也可以理解，某些场景（例如，某些隧道体系结构）确实会导致碎片。但是，一般来说，由于初始MSS协商和随后使用路径MTU发现的组合，碎片预计不会在互联网中普遍存在。RFC 3095[31]指出，对于RTP，只有第一个片段将包含传输层协议头；随后的片段必须使用不同的概要文件进行压缩。这显然也是TCP的情况。如果要发生碎片，根据定义，第一个片段将相对较大，从而最小化头开销。随后的片段将使用另一个概要文件进行压缩。因此，在执行报头压缩时优化碎片被认为是不可取的。因此，More Fragments标志被分类为STATIC-KNOWN。
o Fragment Offset
o 碎片偏移量
Under the assumption that no fragmentation occurs, the fragment offset is always zero. The field is therefore classified as STATIC-KNOWN. Even if fragmentation were to be further considered, only the first fragment would contain the TCP header, and the fragment offset of this packet would still be zero.
假设不发生碎片，碎片偏移量始终为零。因此，该字段被归类为静态-已知字段。即使进一步考虑分段，也只有第一个分段包含TCP头，并且该数据包的分段偏移量仍然为零。
o Protocol
o 协议
This field will usually have the same value in all packets of a packet stream. It encodes the type of the subsequent header.
该字段通常在数据包流的所有数据包中具有相同的值。它对后续标头的类型进行编码。
Only where the sequence of headers changes (e.g., an extension header is inserted or deleted or a tunnel header is added or removed) will the field change its value. The field is therefore classified as STATIC. Whether such a change would cause the sequence of packets to be treated as a new flow (for header compression) is an issue for profile design. ROHC profiles must be able to cope with extension headers and tunnelling, but the choice of strategy is outside the scope of this document.
只有在头序列发生变化的情况下（例如，插入或删除扩展头或添加或删除隧道头），字段才会改变其值。因此，该字段被归类为静态字段。这样的更改是否会导致数据包序列被视为新流（用于报头压缩）是概要文件设计的一个问题。ROHC配置文件必须能够处理扩展头和隧道，但是策略的选择超出了本文档的范围。
o Header Checksum
o 报头校验和
The header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, there is no point in having this additional checksum. Instead, it can be regenerated at the decompressor side. The field is therefore classified as INFERRED.
标头校验和保护单个跃点不处理损坏的标头。当几乎所有的IP报头信息都被压缩掉时，没有必要使用这个额外的校验和。相反，它可以在减压器侧重新生成。因此，该字段被归类为推断字段。
Note that the TCP checksum does not protect the whole TCP/IP header, but only the TCP pseudo-header (and the payload). Compare this with ROHC [31], which uses a CRC to verify the uncompressed header. Given the need to validate the complete TCP/IP header, the cost of computing the TCP checksum over the entire payload, and known weaknesses in the TCP checksum [37], an additional check is necessary. Therefore, it is highly desirable that some additional checksum (such as a CRC) will be used to validate correct decompression.
请注意，TCP校验和不保护整个TCP/IP报头，只保护TCP伪报头（和有效负载）。将其与ROHC[31]进行比较，ROHC[31]使用CRC验证未压缩的报头。考虑到需要验证完整的TCP/IP报头、在整个有效负载上计算TCP校验和的成本以及TCP校验和中的已知弱点[37]，需要进行额外的检查。因此，非常希望使用一些额外的校验和（例如CRC）来验证正确的解压缩。
o Source and Destination Addresses
o 源地址和目标地址
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
这些字段是流定义的一部分，因此对于流中的所有数据包都必须是常量。因此，这些字段被分类为STATIC-DEF。
The total size of the fields in each class is as follows:
每个类中字段的总大小如下所示：
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC* | 1.5 |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 |
+--------------+--------------+
* Differs from RFC 3095 [31]
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 4 |
| STATIC* | 1.5 |
| STATIC-DEF | 8 |
| STATIC-KNOWN*| 2.25 |
| CHANGING* | 4.25 |
+--------------+--------------+
* Differs from RFC 3095 [31]
Figure 4. Field sizes
图4。字段大小
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Sequence Number | 32 | CHANGING |
| Acknowledgement Num | 32 | CHANGING |
| Data Offset | 4 | INFERRED |
| Reserved | 4 | CHANGING |
| CWR flag | 1 | CHANGING |
| ECE flag | 1 | CHANGING |
| URG flag | 1 | CHANGING |
| ACK flag | 1 | CHANGING |
| PSH flag | 1 | CHANGING |
| RST flag | 1 | CHANGING |
| SYN flag | 1 | CHANGING |
| FIN flag | 1 | CHANGING |
| Window | 16 | CHANGING |
| Checksum | 16 | CHANGING |
| Urgent Pointer | 16 | CHANGING |
| Options | 0(-352) | CHANGING |
+---------------------+-------------+----------------+
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Sequence Number | 32 | CHANGING |
| Acknowledgement Num | 32 | CHANGING |
| Data Offset | 4 | INFERRED |
| Reserved | 4 | CHANGING |
| CWR flag | 1 | CHANGING |
| ECE flag | 1 | CHANGING |
| URG flag | 1 | CHANGING |
| ACK flag | 1 | CHANGING |
| PSH flag | 1 | CHANGING |
| RST flag | 1 | CHANGING |
| SYN flag | 1 | CHANGING |
| FIN flag | 1 | CHANGING |
| Window | 16 | CHANGING |
| Checksum | 16 | CHANGING |
| Urgent Pointer | 16 | CHANGING |
| Options | 0(-352) | CHANGING |
+---------------------+-------------+----------------+
Figure 5: TCP header fields
图5:TCP头字段
o Source and Destination ports
o 源端口和目标端口
These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
这些字段是流定义的一部分，因此对于流中的所有数据包都必须是常量。因此，这些字段被分类为STATIC-DEF。
o Data Offset
o 数据偏移量
The number of 4 octet words in the TCP header, indicating the start of the data. It is always a multiple of 4 octets. It can be re-constructed from the length of any options, and thus it is not necessary to carry this explicitly. The field is therefore classified as INFERRED.
TCP标头中4个八位字节的字数，表示数据的开始。它始终是4个八位字节的倍数。它可以从任何选项的长度重新构造，因此没有必要显式地进行此操作。因此，该字段被归类为推断字段。
Summarizing this for IP/TCP, one obtains the following:
总结IP/TCP的这一点，可以得出以下结论：
+----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 4 bits | 19 + 6 bits |
+----------------+----------------+----------------+
| Totals | 60 | 40 |
+----------------+----------------+----------------+
(Excludes options, which are all classified as CHANGING).
+----------------+----------------+----------------+
| Class \ IP ver | IPv6 (octets) | IPv4 (octets) |
+----------------+----------------+----------------+
| INFERRED | 2 + 4 bits | 4 + 4 bits |
| STATIC | 1 + 4 bits | 1 + 4 bits |
| STATIC-DEF | 38 + 4 bits | 12 |
| STATIC-KNOWN | - | 2 + 2 bits |
| CHANGING | 17 + 4 bits | 19 + 6 bits |
+----------------+----------------+----------------+
| Totals | 60 | 40 |
+----------------+----------------+----------------+
(Excludes options, which are all classified as CHANGING).
Figure 6. Overall field sizes
图6。总体字段大小
Where multiple flows either overlap in time or occur sequentially within a short space of time, there can be a great deal of similarity in header field values. Such commonality of field values is reflected in the compression context. Thus, it should be possible to utilise commonality between fields across different flows to improve the compression ratio. In order to do this, it is important to understand the 'replicable' characteristics of the various header fields.
当多个流在时间上重叠或在短时间内顺序发生时，报头字段值可能存在很大的相似性。字段值的这种公共性反映在压缩上下文中。因此，应该可以利用不同流中字段之间的共性来提高压缩比。为了做到这一点，了解各种头字段的“可复制”特征非常重要。
The key concept is that of 'replication': an existing context is used as a baseline and replicated to initialise a new context. Those fields that are the same are then automatically initialised in the new context. Those that have changed will be updated or overwritten with values from the initialisation packet that triggered the replication. This section considers the commonality between fields in different flows.
关键概念是“复制”：将现有上下文用作基线，并进行复制以初始化新上下文。然后在新上下文中自动初始化相同的字段。已更改的将使用触发复制的初始化数据包中的值进行更新或覆盖。本节考虑不同流中字段之间的共性。
Note, however, that replication is based on contexts (rather than on just field values), so compressor-created fields that are part of the context may also be included. These, of course, are dependent upon the nature of the compression protocol (ROHC profile) being applied.
但是，请注意，复制是基于上下文的（而不仅仅是字段值），因此也可以包括作为上下文一部分的压缩器创建的字段。当然，这取决于所应用的压缩协议（ROHC配置文件）的性质。
A brief analysis of the relationship of TCP/IP fields among 'replicable' packet streams follows.
下面简要分析“可复制”数据包流之间TCP/IP字段的关系。
'N/A': The field need not be considered in the replication process, as it is inferred or known 'a priori' (and, therefore, does not appear in the context).
“N/A”：复制过程中不需要考虑该字段，因为它是“先验”推断或已知的（因此不会出现在上下文中）。
'No': The field cannot be replicated since its change pattern between two packet flows is uncorrelated.
“否”：由于两个数据包流之间的更改模式不相关，因此无法复制该字段。
'Yes': The field may be replicated. This does not guarantee that the field value will be the same across two candidate streams, only that it might be possible to exploit replication to increase the compression ratio. Specific encoding methods can be used to improve the compression efficiency.
“是”：可以复制该字段。这并不保证两个候选流中的字段值相同，只是可能利用复制来提高压缩比。可以使用特定的编码方法来提高压缩效率。
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Header Length | STATIC-KNOWN | N/A |
| DSCP | ALTERNATING | No (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Packet Length | INFERRED | N/A |
| Identification | CHANGING | Yes (3) |
| Reserved flag | CHANGING | No (4) |
| Don't Fragment flag | CHANGING | Yes (5) |
| More Fragments flag | STATIC-KNOWN | N/A |
| Fragment Offset | STATIC-KNOWN | N/A |
| Time To Live | CHANGING | Yes |
| Protocol | STATIC | N/A |
| Header Checksum | INFERRED | N/A |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Header Length | STATIC-KNOWN | N/A |
| DSCP | ALTERNATING | No (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Packet Length | INFERRED | N/A |
| Identification | CHANGING | Yes (3) |
| Reserved flag | CHANGING | No (4) |
| Don't Fragment flag | CHANGING | Yes (5) |
| More Fragments flag | STATIC-KNOWN | N/A |
| Fragment Offset | STATIC-KNOWN | N/A |
| Time To Live | CHANGING | Yes |
| Protocol | STATIC | N/A |
| Header Checksum | INFERRED | N/A |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
Figure 7: IPv4 header
图7:IPv4报头
(1) The DSCP is marked according to the application's requirements. If it can be assumed that replicable connections belong to the same diffserv class, then it is likely that the DSCP will be replicable. The DSCP can be set not only by the sender but by any packet marker. Thus, a flow may have a number of DSCP values at different points in the network. However, header compression
(1) DSCP根据应用程序的要求进行标记。如果可以假设可复制连接属于同一个diffserv类，那么DSCP很可能是可复制的。DSCP不仅可以由发送方设置，还可以由任何数据包标记设置。因此，流在网络中的不同点处可以具有多个DSCP值。然而，报头压缩
operates on a point-to-point link and so would expect to see a relatively stable value. If re-marking is being done based on the state of a meter, then the value may change mid-flow. Overall, though, we expect supporting replication of the DSCP to be useful for header compression.
在点到点链接上运行，因此期望看到相对稳定的值。如果根据流量计的状态进行重新标记，则该值可能会改变。不过，总的来说，我们希望支持DSCP的复制对报头压缩有用。
(2) It is not possible for the ECN bits to be replicated (note that use of the ECN nonce scheme [19] is anticipated). However, it seems likely that all TCP flows between ECN-capable hosts will use ECN, the use (or not) of ECN for flows between the same end-points might be considered replicable. See also note (4).
(2) 不可能复制ECN比特（注意，预期使用ECN nonce方案[19]）。但是，支持ECN的主机之间的所有TCP流似乎都将使用ECN，相同端点之间的流使用（或不使用）ECN可能被认为是可复制的。另见注（4）。
(3) The replicable context for this field includes the IP-ID, NBO, and RND flags (as described in ROHC RTP). This highlights that the replication is of the context, rather than just the header field values and, as such, needs to be considered based on the exact nature of compression applied to each field.
(3) 此字段的可复制上下文包括IP-ID、NBO和RND标志（如ROHC RTP中所述）。这强调了复制是上下文的，而不仅仅是头字段值，因此需要根据应用于每个字段的压缩的确切性质来考虑。
(4) Since the possible future behavior of the 'Reserved Flag' cannot be predicted, it is not considered as replicable. However, it might be expected that the behavior of the reserved flag between the same end-points will be similar. In this case, any selection of packet formats (for example) based on this behavior might carry across to the new flow. In the case of packet formats, this can probably be considered as a compressor-local decision.
(4) 由于无法预测“保留标志”未来可能的行为，因此不认为它是可复制的。但是，可以预期，相同端点之间保留标志的行为将类似。在这种情况下，基于此行为的任何数据包格式选择（例如）都可能传递到新的流。在分组格式的情况下，这可能被视为一个本地决定。
(5) In theory, the DF bit may be replicable. However, this is not guaranteed and, in practice, it is unlikely to be useful to do this. From the perspective of header compression, having to indicate whether or not a 1-bit flag should be replicated or specified explicitly is likely to require more bits than simply conveying the value of the flag. We do not rule out DF replication.
(5) 理论上，DF位可能是可复制的。然而，这并不能保证，在实践中，这样做不太可能有用。从报头压缩的角度来看，必须指示是否应该复制或显式指定1位标志可能需要更多的位，而不仅仅是传递标志的值。我们不排除DF复制。
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Traffic Class | CHANGING | Yes (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Flow Label | STATIC-DEF | N/A |
| Payload Length | INFERRED | N/A |
| Next Header | STATIC | N/A |
| Hop Limit | CHANGING | Yes |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
(1) See comment about DSCP field for IPv4, above.
(2) See comment about ECT and CE flags for IPv4, above.
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Traffic Class | CHANGING | Yes (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Flow Label | STATIC-DEF | N/A |
| Payload Length | INFERRED | N/A |
| Next Header | STATIC | N/A |
| Hop Limit | CHANGING | Yes |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
(1) See comment about DSCP field for IPv4, above.
(2) See comment about ECT and CE flags for IPv4, above.
Figure 8. IPv6 Header
图8。IPv6报头
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Source Port | STATIC-DEF | Yes (1) |
| Destination Port | STATIC-DEF | Yes (1) |
| Sequence Number | CHANGING | No (2) |
| Acknowledgement Number| CHANGING | No |
| Data Offset | INFERRED | N/A |
| Reserved Bits | CHANGING | No (3) |
| Flags | | |
| CWR | CHANGING | No (4) |
| ECE | CHANGING | No (4) |
| URG | CHANGING | No |
| ACK | CHANGING | No |
| PSH | CHANGING | No |
| RST | CHANGING | No |
| SYN | CHANGING | No |
| FIN | CHANGING | No |
| Window | CHANGING | Yes |
| Checksum | CHANGING | No |
| Urgent Pointer | CHANGING | Yes (5) |
+-----------------------+---------------+------------+
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Source Port | STATIC-DEF | Yes (1) |
| Destination Port | STATIC-DEF | Yes (1) |
| Sequence Number | CHANGING | No (2) |
| Acknowledgement Number| CHANGING | No |
| Data Offset | INFERRED | N/A |
| Reserved Bits | CHANGING | No (3) |
| Flags | | |
| CWR | CHANGING | No (4) |
| ECE | CHANGING | No (4) |
| URG | CHANGING | No |
| ACK | CHANGING | No |
| PSH | CHANGING | No |
| RST | CHANGING | No |
| SYN | CHANGING | No |
| FIN | CHANGING | No |
| Window | CHANGING | Yes |
| Checksum | CHANGING | No |
| Urgent Pointer | CHANGING | Yes (5) |
+-----------------------+---------------+------------+
Figure 9: TCP Header
图9:TCP头
(1) On the server side, the port number is likely to be a well-known value. On the client side, the port number is generally selected by the stack automatically. Whether the port number is replicable depends upon how the stack chooses the port number. Whilst most implementations use a simple scheme that sequentially picks the next available port number, it may not be desirable to rely on this behavior.
(1) 在服务器端，端口号可能是一个众所周知的值。在客户端，端口号通常由堆栈自动选择。端口号是否可复制取决于堆栈如何选择端口号。虽然大多数实现使用一个简单的方案，按顺序选择下一个可用的端口号，但依赖这种行为可能并不可取。
(2) With the recommendation (and expected deployment) of TCP Initial Sequence Number randomization, defined in RFC 1948 [10], it will be impossible to share the sequence number. Thus, this field will not be regarded as replicable.
(2) 根据RFC 1948[10]中定义的TCP初始序列号随机化的建议（和预期部署），不可能共享序列号。因此，此字段将不被视为可复制。
(3) See comment (4) for the IPv4 header, above.
(3) 请参阅上面的IPv4标头注释（4）。
(4) See comment (2) on ECN flags for the IPv4 header, above.
(4) 请参见上文中有关IPv4标头的ECN标志的注释（2）。
(5) The urgent pointer is very rarely used. This means that, in practice, the field may be considered replicable.
(5) 紧急指针很少使用。这意味着，在实践中，该领域可能被认为是可复制的。
+---------------------------+--------------+------------+
| Option | SYN-only (1) | Replicable |
+---------------------------+--------------+------------+
| End of Option List | No | No (2) |
| No-Operation | No | No (2) |
| Maximum Segment Size | Yes | Yes |
| Window Scale | Yes | Yes |
| SACK-Permitted | Yes | Yes |
| SACK | No | No |
| Timestamp | No | No |
+---------------------------+--------------+------------+
+---------------------------+--------------+------------+
| Option | SYN-only (1) | Replicable |
+---------------------------+--------------+------------+
| End of Option List | No | No (2) |
| No-Operation | No | No (2) |
| Maximum Segment Size | Yes | Yes |
| Window Scale | Yes | Yes |
| SACK-Permitted | Yes | Yes |
| SACK | No | No |
| Timestamp | No | No |
+---------------------------+--------------+------------+
Figure 10. TCP Options
图10。TCP选项
(1) This indicates whether the option only appears in SYN packets. Options that are not 'SYN-only' may appear in any packet. Many TCP options are used only in SYN packets. Some options, such as MSS, Window Scale, and SACK-Permitted, will tend to have the same value among replicable packet streams.
(1) 这表示该选项是否仅出现在SYN数据包中。并非“仅SYN”的选项可能出现在任何数据包中。许多TCP选项仅在SYN数据包中使用。一些选项，如MSS、窗口缩放和SACK许可，在可复制的数据包流中往往具有相同的值。
Thus, to support context sharing, the compressor should maintain such TCP options in the context (even though they only appear in the SYN segment).
因此，为了支持上下文共享，压缩器应该在上下文中维护这些TCP选项（即使它们只出现在SYN段中）。
(2) Since these options have fixed values, they could be regarded as replicable. However, the only interesting thing to convey about
(2) 由于这些选项具有固定值，因此可以将其视为可复制选项。然而，要传达的唯一有趣的事情
these options is their presence. If it is known that such an option exists, its value is defined.
这些选择就是他们的存在。如果已知存在此类选项，则定义其值。
From the above analysis, it can be seen that there are reasonable grounds for exploiting redundancy between flows as well as between packets within a flow. Simply consider the advantage of being able to elide the source and destination addresses for a repeated connection between two IPv6 endpoints. There will also be a cost (in terms of complexity and robustness) for replicating contexts, and this must be considered when one decides what constitutes an appropriate solution.
从以上分析可以看出，有合理的理由利用流之间以及流中的数据包之间的冗余。简单地考虑能够在两个IPv6端点之间重复连接的源地址和目的地址的优点。复制上下文也会有成本（在复杂性和健壮性方面），在决定什么是合适的解决方案时必须考虑到这一点。
Finally, note that the use of replication requires that the compressor have a suitable degree of confidence that the source data is present and correct at the decompressor. This may place some restrictions on which of the 'changing' fields, in particular, can be utilised during replication.
最后，请注意，使用复制要求压缩器对源数据在解压器中的存在和正确性有适当的信心。这可能会对复制过程中可以使用的“更改”字段设置一些限制。
To design suitable mechanisms for efficient compression of all header fields, their change patterns must be analyzed. For this reason, an extended classification is done based on the general classification in 2, considering the fields that were labeled CHANGING in that classification.
为了设计适当的机制来有效压缩所有头字段，必须分析它们的变化模式。因此，在2中的常规分类的基础上进行扩展分类，考虑到在该分类中标记的字段发生变化。
The CHANGING fields are separated into five different subclasses:
更改字段分为五个不同的子类：
o STATIC
o 静止的
These are fields that were classified as CHANGING on a general basis, but that are classified as STATIC here due to certain additional assumptions.
这些字段在一般情况下被归类为变化字段，但由于某些附加假设，在此处被归类为静态字段。
o SEMISTATIC
o 半静态
These fields are STATIC most of the time. However, occasionally the value changes but reverts to its original value after a known number of packets.
这些字段大部分时间是静态的。但是，该值偶尔会更改，但在已知数量的数据包之后会恢复为其原始值。
o RARELY-CHANGING (RC)
o 变化不大（RC）
These are fields that change their values occasionally and then keep their new values.
这些字段偶尔更改其值，然后保留其新值。
o ALTERNATING
o 交替
These fields alternate between a small number of different values.
这些字段在少量不同的值之间交替。
o IRREGULAR
o 不整齐的
These, finally, are the fields for which no useful change pattern can be identified.
最后，这些是无法识别有用更改模式的字段。
To further expand the classification possibilities without increasing complexity, the classification can be done either according to the values of the field and/or according to the values of the deltas for the field.
为了在不增加复杂性的情况下进一步扩展分类可能性，可以根据字段的值和/或根据字段的增量值来进行分类。
When the classification is done, other details are also stated regarding possible additional knowledge about the field values and/or field deltas, according to the classification. For fields classified as STATIC or SEMISTATIC, the value of the field could be not only STATIC but also well-KNOWN a priori (two states for SEMISTATIC fields). For fields with non-irregular change behavior, it could be known that changes are usually within a LIMITED range compared to the maximal change for the field. For other fields, the values are completely UNKNOWN.
分类完成后，还将根据分类说明关于字段值和/或字段增量的可能附加知识的其他详细信息。对于分类为静态或半静态的字段，字段的值不仅可以是静态的，还可以是众所周知的先验值（半静态字段有两种状态）。对于具有非不规则变化行为的场，可以知道，与场的最大变化相比，变化通常在有限的范围内。对于其他字段，值是完全未知的。
Figure 11 classifies all the CHANGING fields on the basis of their expected change patterns. (4) refers to IPv4 fields and (6) refers to IPv6.
图11根据预期的更改模式对所有更改字段进行了分类。（4） 指IPv4字段，（6）指IPv6。
+------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+
| DSCP(4) / Tr.Class(6) | Value | ALTERNATING | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP ECT flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP CE flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+
| IP Id(4) Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP DF flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Sequence Number | Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Acknowledgement Num| Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Reserved | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| TCP flags | | | |
| ECN flags | Value | IRREGULAR | UNKNOWN |
| CWR flag | Value | IRREGULAR | UNKNOWN |
| ECE flag | Value | IRREGULAR | UNKNOWN |
| URG flag | Value | IRREGULAR | UNKNOWN |
| ACK flag | Value | SEMISTATIC | KNOWN |
| PSH flag | Value | IRREGULAR | UNKNOWN |
| RST flag | Value | IRREGULAR | UNKNOWN |
| SYN flag | Value | SEMISTATIC | KNOWN |
| FIN flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Window | Value | ALTERNATING | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Checksum | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Urgent Pointer | Value | IRREGULAR | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Options | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
+------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+
| DSCP(4) / Tr.Class(6) | Value | ALTERNATING | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP ECT flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP CE flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+
| IP Id(4) Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP DF flag(4) | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TTL(4) / Hop Lim(6) | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Sequence Number | Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Acknowledgement Num| Delta | IRREGULAR | LIMITED |
+------------------------+-------------+-------------+-------------+
| TCP Reserved | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| TCP flags | | | |
| ECN flags | Value | IRREGULAR | UNKNOWN |
| CWR flag | Value | IRREGULAR | UNKNOWN |
| ECE flag | Value | IRREGULAR | UNKNOWN |
| URG flag | Value | IRREGULAR | UNKNOWN |
| ACK flag | Value | SEMISTATIC | KNOWN |
| PSH flag | Value | IRREGULAR | UNKNOWN |
| RST flag | Value | IRREGULAR | UNKNOWN |
| SYN flag | Value | SEMISTATIC | KNOWN |
| FIN flag | Value | SEMISTATIC | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Window | Value | ALTERNATING | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Checksum | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Urgent Pointer | Value | IRREGULAR | KNOWN |
+------------------------+-------------+-------------+-------------+
| TCP Options | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
Figure 11. Classification of CHANGING Fields
图11。变化领域的分类
The following subsections discuss the various header fields in detail. Note that Table 1 and the discussion below do not consider changes caused by loss or reordering before the compression point.
以下小节将详细讨论各种标题字段。注意，表1和下面的讨论不考虑在压缩点之前由丢失或重新排序引起的变化。
The Traffic-Class (IPv6) or Type-Of-Service/DSCP (IPv4) field might be expected to change during the lifetime of a packet stream. This analysis considers several RFCs that describe modifications to the original RFC 791 [1].
在数据包流的生存期内，流量类别（IPv6）或服务类型/DSCP（IPv4）字段可能会更改。该分析考虑了几个RFC，这些RFC描述了对原始RFC 791[1]的修改。
The TOS byte was initially described in RFC 791 [1] as 3 bits of precedence followed by 3 bits of TOS and 2 reserved bits (defined to be zero). RFC 1122 [21] extended this to specify 5 bits of TOS, although the meanings of the additional 2 bits were not defined. RFC 1349 [23] defined the 4th bit of TOS as 'minimize monetary cost'. The next significant change was in RFC 2474 [14] (obsoleting RFC 1349 [23]). RFC 2474 reworked the TOS octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits. Most recently, RFC 2780 [30] identified the 2 reserved bits in the TOS or traffic class octet for experimental use with ECN.
TOS字节最初在RFC 791[1]中描述为3位优先，后面是3位TOS和2位保留位（定义为零）。RFC 1122[21]对此进行了扩展，以指定TOS的5位，尽管未定义额外2位的含义。RFC 1349[23]将TOS的第四位定义为“最小化货币成本”。下一个重大变化是RFC 2474[14]（淘汰RFC 1349[23]）。RFC 2474将TOS八位字节改写为DSCP的6位（区分服务码点）加上2个未使用的位。最近，RFC 2780[30]确定了TOS或流量类八位字节中的2个保留位，以便与ECN一起进行实验使用。
It is therefore proposed that the TOS (or traffic class) octet be classified as 6 bits for the DSCP and 2 additional bits. These 2 bits may be expected to be zero or to contain ECN data. From a future-proofing perspective, it is preferable to assume the use of ECN, especially with respect to TCP.
因此，建议将TOS（或业务类）八位字节分类为6位用于DSCP，另外2位用于DSCP。这2位可能预期为零或包含ECN数据。从未来的角度来看，最好假设使用ECN，特别是关于TCP。
It is also considered important that the profile work with legacy stacks, since these will be in existence for some considerable time to come. For simplicity, this will be considered as 6 bits of TOS information and 2 bits of ECN data, so the fields are always considered to be structured the same way.
配置文件与遗留堆栈一起工作也被认为是重要的，因为它们将在相当长的一段时间内存在。为简单起见，这将被视为6位TOS信息和2位ECN数据，因此字段的结构始终被视为相同。
The DSCP (as for TOS in ROHC RTP) is not expected to change frequently (although it could change mid-flow, for example, as a result of a route change).
预计DSCP（与ROHC RTP中的TOS一样）不会频繁更改（尽管它可能会更改中间流，例如，由于路由更改）。
Initially, we describe the ECN flags as specified in RFC 2481 [15] and RFC 3168 [18]. Subsequently, a suggested update is described that would alter the behavior of the flags.
正如我们最初在[RF8]和[RF18]中规定的那样，RF8和[RF18]标志。随后，将描述一个建议的更新，该更新将改变标志的行为。
In RFC 2481 [15] there are 2 separate flags, the ECT (ECN Capable Transport) flag and the CE (Congestion Experienced) flag. The ECT
在RFC 2481[15]中，有两个单独的标志，ECT（支持ECN的传输）标志和CE（经历拥塞）标志。ECT
flag, if negotiated by the TCP stack, will be '1' for all data packets and '0' for all 'pure acknowledgement' packets. This means that the behavior of the ECT flag is linked to behavior in the TCP stack. Whether this can be exploited for compression is not clear.
如果由TCP堆栈协商，则所有数据包的标志将为“1”，所有“纯确认”数据包的标志将为“0”。这意味着ECT标志的行为链接到TCP堆栈中的行为。目前尚不清楚是否可以利用这一点进行压缩。
The CE flag is only used if ECT is set to '1'. It is set to '0' by the sender and can be set to '1' by an ECN-capable router in the network to indicate congestion. Thus the CE flag is expected to be randomly set to '1' with a probability dependent on the congestion state of the network and the position of the compressor in the path. Therefore, a compressor located close to the receiver in a congested network will see the CE bit set frequently, but a compressor located close to a sender will rarely, if ever, see the CE bit set to '1'.
CE标志仅在ECT设置为“1”时使用。发送方将其设置为“0”，网络中支持ECN的路由器可将其设置为“1”，以指示拥塞。因此，预计CE标志将随机设置为“1”，其概率取决于网络的拥塞状态和压缩机在路径中的位置。因此，在拥挤的网络中，位于接收器附近的压缩器将经常看到CE位设置，但位于发送器附近的压缩器很少看到CE位设置为“1”。
A recent experimental proposal [19] suggests an alternative view of these 2 bits. This considers the two bits together to have 4 possible codepoints. Meanings are then assigned to the codepoints:
最近的一项实验建议[19]提出了这两个比特的另一种观点。这将两个位考虑在一起有4个可能的码点。然后将含义分配给代码点：
00 Not ECN capable 01 ECN capable, no congestion (known as ECT(0)) 10 ECN capable, no congestion (known as ECT(1)) 11 Congestion experienced
00不支持ECN 01支持ECN，无拥塞（称为ECT（0））10支持ECN，无拥塞（称为ECT（1））11经历拥塞
The use of 2 codepoints for signaling ECT allows the sender to detect when a receiver is not reliably echoing congestion information.
在发送ECT信号时使用2个码点，使得发送方能够检测到接收机何时不能可靠地回显拥塞信息。
For the purposes of compression, this update means that ECT(0) and ECT(1) are equally likely (for an ECN capable flow) and that '11' will be seen relatively rarely. The probability of seeing a congestion indication is discussed above in the description of the CE flag.
出于压缩的目的，此更新意味着ECT（0）和ECT（1）的可能性相同（对于支持ECN的流），而“11”的可能性相对较小。在上面对CE标志的描述中讨论了看到拥塞指示的概率。
It is suggested that, for the purposes of compression, ECN with nonces be assumed as the baseline, although the compression scheme must be able to compress the original ECN scheme transparently.
有人建议，为了压缩的目的，可以假设带有nonce的ECN作为基线，尽管压缩方案必须能够透明地压缩原始ECN方案。
The Identification field (IP ID) of the IPv4 header identifies which fragments constitute a datagram, when fragmented datagrams are reassembled. The IPv4 specification does not specify exactly how this field is to be assigned values, only that each packet should get an IP ID that is unique for the source-destination pair and protocol for the time during which the datagram (or any of its fragments) could be alive in the network. This means that assignment of IP ID values can be done in various ways, which we have separated into three classes:
当碎片数据报重新组装时，IPv4报头的标识字段（IP ID）标识构成数据报的碎片。IPv4规范没有明确指定如何分配此字段的值，只是每个数据包都应该获得一个IP ID，该ID对于源-目的地对和协议来说是唯一的，在这段时间内，数据报（或其任何片段）可能在网络中处于活动状态。这意味着可以通过各种方式分配IP ID值，我们将其分为三类：
o Sequential jump
o 顺序跳转
This is the most common assignment policy in today's IP stacks. A single IP ID counter is used for all packet streams. When the sender is running more than one packet stream simultaneously, the IP ID can increase by more than one between packets in a stream. The IP ID values will be much more predictable and will require fewer bits to transfer than random values, and the packet-to-packet increment (determined by the number of active outgoing packet streams and sending frequencies) will usually be limited.
这是当今IP堆栈中最常见的分配策略。单个IP ID计数器用于所有数据包流。当发送方同时运行多个分组流时，IP ID可以在一个流中的分组之间增加一个以上。与随机值相比，IP ID值将更加可预测，并且需要更少的比特来传输，并且包到包的增量（由活动传出包流的数量和发送频率确定）通常将受到限制。
o Random
o 随机的
Some IP stacks assign IP ID values by using a pseudo-random number generator. There is thus no correlation between the ID values of subsequent datagrams. Therefore, there is no way to predict the IP ID value for the next datagram. For header compression purposes, this means that the IP ID field needs to be sent uncompressed with each datagram, resulting in two extra octets of header. IP stacks in cellular terminals that need optimum header compression efficiency should not use this IP ID assignment policy.
一些IP堆栈使用伪随机数生成器分配IP ID值。因此，后续数据报的ID值之间没有相关性。因此，无法预测下一个数据报的IP ID值。出于报头压缩的目的，这意味着IP ID字段需要与每个数据报一起未压缩发送，从而导致报头的两个额外八位字节。需要最佳报头压缩效率的蜂窝终端中的IP堆栈不应使用此IP ID分配策略。
o Sequential
o 顺序的
This assignment policy keeps a separate counter for each outgoing packet stream, and thus the IP ID value will increment by one for each packet in the stream, except at wrap around. Therefore, the delta value of the field is constant and well known a priori. This assignment policy is the most desirable for header compression purposes. However, its usage is not as common as it perhaps should be.
此分配策略为每个传出数据包流保留一个单独的计数器，因此，流中的每个数据包的IP ID值将增加一个，环绕时除外。因此，场的增量值是恒定的，并且是众所周知的。此分配策略最适合用于头压缩目的。然而，它的使用并不像它应该的那样普遍。
In order to avoid violating RFC 791 [1], packets sharing the same IP address pair and IP protocol number cannot use the same IP ID values. Therefore, implementations of sequential policies must make the ID number spaces disjoint for packet streams of the same IP protocol going between the same pair of nodes. This can be done in a number of ways, all of which introduce occasional jumps and thus make the policy less than perfectly sequential. For header compression purposes, less frequent jumps are preferred.
为了避免违反RFC 791[1]，共享相同IP地址对和IP协议号的数据包不能使用相同的IP ID值。因此，顺序策略的实现必须使相同IP协议的数据包流在同一对节点之间的ID号空间不相交。这可以通过多种方式实现，所有这些方式都会引入偶尔的跳跃，从而使策略不那么完美有序。出于报头压缩的目的，较不频繁的跳转是首选。
Note that the ID is an IPv4 mechanism and is therefore not a problem for IPv6. For IPv4, the ID could be handled in three different ways. First, we have the inefficient but reliable solution where the ID field is sent as-is in all packets, increasing the compressed headers by two octets. This is the best way to handle the ID field if the sender uses random assignment of the ID field. Second, there can be
请注意，ID是IPv4机制，因此对于IPv6来说不是问题。对于IPv4，可以用三种不同的方式处理ID。首先，我们有一个低效但可靠的解决方案，其中ID字段按所有数据包中的原样发送，将压缩头增加两个八位组。如果发送方使用ID字段的随机分配，这是处理ID字段的最佳方法。第二，可以有
solutions with more flexible mechanisms that require fewer bits for the ID handling as long as sequential jump assignment is used. Such solutions will probably require even more bits if random assignment is used by the sender. Knowledge about the sender's assignment policy could therefore be useful when choosing between the two solutions above. Finally, even for IPv4, header compression could be designed without any additional information for the ID field included in compressed headers. To use such schemes, it must be known which assignment policy for the ID field is being used by the sender. That might not be possible to know, which implies that the applicability of such solutions is very uncertain. However, designers of IPv4 stacks for cellular terminals should use an assignment policy close to sequential.
具有更灵活机制的解决方案，只要使用顺序跳转分配，就需要更少的ID处理位。如果发送方使用随机分配，这种解决方案可能需要更多的位。因此，在选择上述两种解决方案时，了解发送者的分配策略可能非常有用。最后，即使对于IPv4，也可以设计标头压缩，而无需为压缩标头中包含的ID字段提供任何附加信息。要使用此类方案，必须知道发送方正在使用ID字段的哪个分配策略。这可能不可能知道，这意味着此类解决方案的适用性非常不确定。然而，蜂窝终端IPv4协议栈的设计者应该使用接近顺序的分配策略。
With regard to TCP compression, the behavior of the IP ID field is essentially the same. However, in RFC 3095 [31], the IP ID is generally inferred from the RTP Sequence Number. There is no obvious candidate in the TCP case for a field to offer this 'master sequence number' role.
关于TCP压缩，IP ID字段的行为基本相同。然而，在RFC 3095[31]中，IP ID通常是从RTP序列号推断出来的。在TCP案例中，没有明显的候选字段提供此“主序列号”角色。
Clearly, from a busy server, the observed behavior may well be quite erratic. This is a case where the ability to share the IP compression context between a number of flows (between the same end-points) could offer potential benefits. However, this would only have any real impact where there is a large number of flows between one machine and the server. If context sharing is being considered, then it is preferable to share the IP part of the context.
显然，在繁忙的服务器上，观察到的行为可能非常不稳定。在这种情况下，在多个流之间（在相同的端点之间）共享IP压缩上下文的能力可能会带来潜在的好处。然而，这只会在一台机器和服务器之间存在大量流的情况下产生任何实际影响。如果正在考虑上下文共享，那么最好共享上下文的IP部分。
Path-MTU discovery (RFC 1191 for IPv4 [6] and RFC 1981 for IPv6 [11]) is widely deployed for TCP, in contrast to little current use for UDP packet streams. This employs the DF flag value of '1' to detect the need for fragmentation in the end-to-end path and to probe the minimum MTU along the network path. End hosts using this technique may be expected to send all packets with DF set to '1', although a host may end PMTU discovery by clearing the DF bit to '0'. Thus, for compression, we expect the field value to be stable.
路径MTU发现（RFC 1191用于IPv4[6]和RFC 1981用于IPv6[11]）广泛用于TCP，而UDP数据包流目前很少使用。这使用DF标志值“1”来检测端到端路径中的碎片需求，并沿网络路径探测最小MTU。使用此技术的终端主机可能会发送DF设置为“1”的所有数据包，尽管主机可能会通过将DF位清除为“0”来结束PMTU发现。因此，对于压缩，我们希望字段值是稳定的。
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be constant during the lifetime of a packet stream or to alternate between a limited number of values due to route changes.
跃点限制（IPv6）或生存时间（IPv4）字段预计在数据包流的生存期内保持不变，或由于路由更改而在有限数量的值之间交替。
Any discussion of compressability of TCP fields borrows heavily from RFC 1144 [22]. However, the premise of how the compression is performed is slightly different, and the protocol has evolved slightly in the intervening time.
关于TCP字段可压缩性的任何讨论都大量借鉴了RFC 1144[22]。然而，如何执行压缩的前提稍有不同，协议在中间时间也有了一些变化。
Understanding the sequence and acknowledgement number behavior is essential for a TCP compression scheme.
理解序列和确认号行为对于TCP压缩方案至关重要。
At the simplest level, the behavior of the sequence number can be described relatively easily. However, there are a number of complicating factors that also need to be considered.
在最简单的层次上，序列号的行为可以相对容易地描述。然而，也需要考虑一些复杂的因素。
For transferring in-sequence data packets, the sequence number will increment for each packet by between 0 and an upper limit defined by the MSS (Maximum Segment Size) and, if it is being used, by Path-MTU discovery.
对于按顺序传输数据包，每个包的序列号将增加0到MSS（最大段大小）和路径MTU发现（如果正在使用）定义的上限之间。
There are common MSS values, but these can be quite variable and unpredictable for any given flow. Given this variability and the range of window sizes, it is hard (compared with the RTP case, for example) to select a 'one size fits all' encoding for the sequence number. (The same argument applies equally to the acknowledgement number).
有常见的MSS值，但对于任何给定的流，这些值都可能是非常可变和不可预测的。鉴于这种可变性和窗口大小的范围，很难（例如，与RTP情况相比）为序列号选择“一刀切”编码。（相同的论点同样适用于确认号）。
Note that the increment of the sequence number in a packet is the size of the data payload of that packet (including the SYN and FIN flags). This is, of course, exactly the relationship that RFC 1144 [22] exploits to compress the sequence number in the most efficient case. This technique may not be directly applicable to a robust solution, but it may be a useful relationship to consider.
请注意，数据包中序列号的增量是该数据包的数据有效负载的大小（包括SYN和FIN标志）。当然，这正是RFC 1144[22]在最有效的情况下用来压缩序列号的关系。这种技术可能不直接适用于鲁棒的解决方案，但它可能是一个有用的关系来考虑。
However, at any point on the path (i.e., wherever a compressor might be deployed), the sequence number can be anywhere within a range defined by the TCP window. This is a combination of a number of values (buffer space at the sender; advertised buffer size at the receiver; and TCP congestion control algorithms). Missing packets or retransmissions can cause the TCP sequence number to fluctuate within the limits of this window.
但是，在路径上的任何点（即，可能部署压缩器的位置），序列号可以在TCP窗口定义的范围内的任何位置。这是多个值的组合（发送方的缓冲区空间；接收方的公布缓冲区大小；以及TCP拥塞控制算法）。丢失的数据包或重新传输可能会导致TCP序列号在此窗口范围内波动。
It is desirable to be able to predict the sequence number with some regularity. However, this also appears to be difficult to do. For example, during bulk data transfer, the sequence number will tend to go up by 1 MSS per packet (assuming no packet loss). Higher layer values have been seen to have an impact as well, where sequence
人们希望能够以某种规律性预测序列号。然而，这似乎也很难做到。例如，在批量数据传输期间，每个数据包的序列号将增加1 ms（假设没有数据包丢失）。较高的层值也会产生影响，其中
number behavior has been observed with an 8 kbyte repeating pattern -- 5 segments of 1460 bytes followed by 1 segment of 892 bytes. The implementation of TCP and the management of buffers within a protocol stack can affect the behavior of the sequence number.
通过8kbyte的重复模式观察到了数字行为——1460字节的5段，后跟892字节的1段。TCP的实现和协议栈中缓冲区的管理会影响序列号的行为。
It may be possible to track the TCP window by the compressor, allowing it to bound the size of these jumps.
压缩器可以跟踪TCP窗口，允许它限制这些跳转的大小。
For interactive flows (for example, telnet), the sequence number will change by small, irregular amounts. In this case, the Nagle algorithm [3] commonly applies, coalescing small packets where possible in order to reduce the basic header overhead. This may also mean that predictable changes in the sequence number are less likely to occur. The Nagle algorithm is an optimisation and is not required to be used (applications can disable its use). However, it is turned on by default in all common TCP implementations.
对于交互式流（例如telnet），序列号将以小的、不规则的数量变化。在这种情况下，通常采用Nagle算法[3]，在可能的情况下合并小数据包，以减少基本的报头开销。这也可能意味着序列号中不太可能发生可预测的变化。Nagle算法是一种优化，无需使用（应用程序可以禁用其使用）。但是，在所有常见的TCP实现中，默认情况下都会启用该选项。
Note also that the SYN and FIN flags (which have to be acknowledged) each consume 1 byte of sequence space.
还要注意，SYN和FIN标志（必须确认）各自占用1字节的序列空间。
Much of the information about the sequence number applies equally to the acknowledgement number. However, there are some important differences.
关于序列号的许多信息同样适用于确认号。然而，有一些重要的区别。
For bulk data transfers, there will tend to be 1 acknowledgement for every 2 data segments. The algorithm is specified in RFC 2581 [16]. An ACK need not always be sent immediately on receipt of a data segment, but it must be sent within 500ms and should be generated for at least every second full-size segment (MSS) of received data. It may be seen from this that the delta for the acknowledgement number is roughly twice that of the sequence number. This is not always the case, and the discussion about sequence number irregularity should be applied.
对于批量数据传输，每2个数据段将有1个确认。RFC 2581[16]中规定了该算法。ACK不一定总是在收到数据段后立即发送，但必须在500ms内发送，并且应至少每秒钟为接收数据的全尺寸段（MSS）生成一次。由此可以看出，确认号的增量大约是序列号的两倍。情况并非总是如此，应该应用关于序列号不规则性的讨论。
As an aside, a common implementation bug is 'stretch ACKs' [33] (acknowledgements may be generated less frequently than every two full-size data segments). This pattern can also occur following loss on the return path.
另一方面，常见的实现错误是“拉伸确认”[33]（确认的生成频率可能低于每两个完整大小的数据段生成一次）。这种模式也可能发生在返回路径丢失之后。
Since the acknowledgement number is cumulative, dropped packets in the forward path will result in the acknowledgement number remaining constant for a time in the reverse direction. Retransmission of a dropped segment can then cause a substantial jump in the acknowledgement number. These jumps in acknowledgement number are bounded by the TCP window, just as for the jumps in sequence number.
由于确认号码是累积的，转发路径中丢弃的分组将导致确认号码在相反方向上保持恒定一段时间。然后，丢弃段的重新传输可能导致确认号大幅增加。确认号中的这些跳转与序列号中的跳转一样，受TCP窗口的限制。
In the acknowledgement case, information about the advertised received window gives a bound to the size of any ACK jump.
在确认情况下，关于广告接收窗口的信息给出了任何ACK跳转大小的界限。
This field is reserved, and it therefore might be expected to be zero. This can no longer be assumed, due to future-proofing. It is only a matter of time before a suggestion for using the flag is made.
此字段是保留的，因此可能预期为零。由于未来的验证，这不再是假设。建议使用国旗只是时间问题。
o ECN-E (Explicit Congestion Notification)
o ECN-E（显式拥塞通知）
'1' to echo CE bit in IP header. It will be set in several consecutive headers (until 'acknowledged' by CWR). If ECN nonces are used, then there will be a 'nonce-sum' (NS) bit in the flags, as well. Again, transparency of the reserved bits is crucial for future-proofing this compression scheme. From an efficiency/compression standpoint, the NS bit will either be unused (always '0') or randomly changing. The nonce sum is the 1-bit sum of the ECT codepoints, as described in [19].
“1”回显IP头中的CE位。它将在几个连续的标题中设置（直到CWR“确认”）。如果使用ECN nonce，那么标志中也会有一个“nonce sum”（NS）位。同样，保留位的透明度对于该压缩方案的未来验证至关重要。从效率/压缩的角度来看，NS位将未使用（始终为“0”）或随机更改。nonce和是ECT码点的1位和，如[19]所述。
o CWR (Congestion Window Reduced)
o 无缝线路（减少拥堵窗口）
'1' to signal congestion window reduced on ECN. It will generally be set in individual packets. The flag will be set once per loss event. Thus, the probability of its being set is proportional to the degree of congestion in the network, but it is less likely to be set than the CE flag.
ECN上信号拥塞窗口的“1”减少。它通常在单独的数据包中设置。该标志将在每个丢失事件中设置一次。因此，其被设置的概率与网络中的拥塞程度成比例，但其被设置的可能性小于CE标志。
o ECE (Echo Congestion Experience)
o ECE（回声阻塞体验）
If 'congestion experienced' is signaled in a received IP header, this is echoed through the ECE bit in segments sent by the receiver until acknowledged by seeing the CWR bit set. Clearly, in periods of high congestion and/or long RTT, this flag will frequently be set to '1'.
如果在接收到的IP报头中发出“遇到拥塞”的信号，则会通过接收器发送的ECE位在段中进行回音，直到通过查看CWR位集进行确认。显然，在高拥塞和/或长RTT期间，此标志将经常设置为“1”。
During connection open (SYN and SYN/ACK packets), the ECN bits have special meaning:
在连接打开期间（SYN和SYN/ACK数据包），ECN位具有特殊含义：
* CWR and ECN-E are both set with SYN to indicate desire to use ECN.
* CWR和ECN-E都设置了SYN，以表示希望使用ECN。
* CWR only is set in SYN-ACK, to agree to ECN.
* 仅在SYN-ACK中设置CWR，以同意ECN。
(The difference in bit-patterns for the negotiation is such that it will work with broken stacks that reflect the value of reserved bits).
（协商的位模式的不同之处在于，它将处理反映保留位值的断堆）。
o URG (Urgent Flag)
o URG（紧急旗）
'1' to indicate urgent data (which is unlikely with any flag other than ACK).
“1”表示紧急数据（除了ACK之外，不太可能使用任何标志）。
o ACK (Acknowledgement)
o 确认（确认）
'1' for all except the initial 'SYN' packet.
“1”表示除初始“SYN”数据包之外的所有数据包。
o PSH (Push Function Field)
o PSH（推送功能字段）
Generally accepted to be randomly '0' or '1'. However, it may be biased more to one value than the other (this is largely caused by the implementation of the stack).
一般认为是随机的“0”或“1”。但是，它可能偏向于一个值而不是另一个值（这主要是由堆栈的实现引起的）。
o RST (Reset Connection)
o RST（重置连接）
'1' to reset a connection (unlikely with any flag other than ACK).
“1”重置连接（不太可能使用ACK以外的任何标志）。
o SYN (Synchronize Sequence Number)
o SYN（同步序列号）
'1' for the SYN/SYN-ACK, only at the start of a connection.
仅在连接开始时，SYN/SYN-ACK的“1”。
o FIN (End of Data: FINished)
o FIN（数据结束：已完成）
'1' to indicate 'no more data' (unlikely with any flag other than ACK).
“1”表示“无更多数据”（除了ACK之外，不太可能使用任何标志）。
Carried as the end-to-end check for the TCP data. See RFC 1144 [22] for a discussion of why this should be carried. A header compression scheme should not rely upon the TCP checksum for robustness, though, and should apply appropriate error-detection mechanisms of its own. The TCP checksum has to be considered to be randomly changing.
作为TCP数据的端到端检查携带。参见RFC 1144[22]，了解为何应进行此操作的讨论。然而，报头压缩方案不应依赖TCP校验和来实现健壮性，而应应用其自身的适当错误检测机制。TCP校验和必须被认为是随机变化的。
This may oscillate randomly between 0 and the receiver's window limit (for the connection).
这可能会在0和接收器窗口限制（用于连接）之间随机振荡。
In practice, the window will either not change or alternate between a relatively small number of values. Particularly when the window is closing (its value is getting smaller), the change in window is likely to be related to the segment size, but it is not clear that this necessarily offers any compression advantage. When the window is opening, the effect of 'Silly-Window Syndrome' avoidance should be remembered. This prevents the window from opening by small amounts that would encourage the sender to clock out small segments.
实际上，窗口不会改变，或者在相对较少的值之间交替。特别是当窗口关闭时（其值越来越小），窗口中的变化可能与段大小有关，但不清楚这是否一定会提供任何压缩优势。当车窗打开时，应记住避免“傻窗综合症”的影响。这可以防止窗口打开过小，这会鼓励发送方将小片段打卡出去。
When thinking about what fields might change in a sequence of TCP segments, one should note that the receiver can generate 'window update' segments in which only the window advertisement changes.
在考虑TCP段序列中哪些字段可能发生更改时，应该注意，接收方可以生成“窗口更新”段，其中只有窗口广告发生更改。
From a compression point of view, the Urgent Pointer is interesting because it offers an example where 'semantically identical' compression is not the same as 'bitwise identical'. This is because the value of the Urgent Pointer is only valid if the URG flag is set.
从压缩的角度来看，紧急指针很有趣，因为它提供了一个示例，其中“语义相同”压缩与“按位相同”压缩不同。这是因为只有设置URG标志时，紧急指针的值才有效。
However, the TCP checksum must be passed transparently, in order to maintain its end-to-end integrity checking property. Since the TCP checksum includes the Urgent Pointer in its coverage, this enforces bitwise transparency of the Urgent Pointer. Thus, the issue of 'semantic' vs. 'bitwise' identity is presented as a note: the Urgent Pointer must be compressed in a way that preserves its value.
但是，TCP校验和必须透明地传递，以保持其端到端完整性检查属性。由于TCP校验和在其覆盖范围中包含紧急指针，因此强制执行紧急指针的位透明性。因此，“语义”与“按位”标识的问题以注释的形式呈现：紧急指针必须以保留其值的方式进行压缩。
If the URG flag is set, then the Urgent Pointer indicates the end of the urgent data and thus can point anywhere in the window. It may be set (and changing) over several segments. Note that urgent data is rarely used, since it is not a particularly clean way of managing out-of-band data.
如果设置了URG标志，则紧急指针指示紧急数据的结束，因此可以指向窗口中的任何位置。可以在多个段上设置（和更改）。请注意，很少使用紧急数据，因为它不是管理带外数据的特别干净的方法。
Options occupy space at the end of the TCP header. All options are included in the checksum. An option may begin on any byte boundary. The TCP header must be padded with zeros to make the header length a multiple of 32 bits.
选项占用TCP标头末尾的空间。所有选项都包含在校验和中。选项可以从任何字节边界开始。TCP标头必须用零填充，以使标头长度为32位的倍数。
Optional header fields are identified by an option kind field. Options 0 and 1 are exactly one octet, which is their kind field. All other options have their one-octet kind field, followed by a one-octet length field, followed by length-2 octets of option data.
可选标题字段由选项种类字段标识。选项0和1正好是一个八位字节，这是它们的类字段。所有其他选项都有一个八位类型字段，后跟一个八位长度字段，后跟选项数据的长度为2个八位字节。
The IANA provides the authoritative list of TCP options. Figure 12 describes the current allocations at the time of publication. Any new option would have a 'kind' value assigned by IANA. The list is available at [20]. Where applicable, the associated RFC is also cited.
IANA提供了TCP选项的权威列表。图12描述了发布时的当前分配。任何新选项都会有IANA指定的“种类”值。该名单可在[20]上查阅。在适用的情况下，还引用了相关的RFC。
+----+-------+------------------------------------+----------+-----+
|Kind|Length | Meaning | RFC | Use |
| |octets | | | |
+----+-------+------------------------------------+----------+-----+
| 0 | - | End of Option List | RFC 793 | * |
| 1 | - | No-Operation | RFC 793 | * |
| 2 | 4 | Maximum Segment Size | RFC 793 | * |
| 3 | 3 | WSopt - Window Scale | RFC 1323 | * |
| 4 | 2 | SACK Permitted | RFC 2018 | * |
| 5 | N | SACK | RFC 2018 | * |
| 6 | 6 | Echo (obsoleted by option 8) | RFC 1072 | |
| 7 | 6 | Echo Reply (obsoleted by option 8) | RFC 1072 | |
| 8 | 10 | TSopt - Time Stamp Option | RFC 1323 | * |
| 9 | 2 | Partial Order Connection Permitted | RFC 1693 | |
| 10 | 3 | Partial Order Service Profile | RFC 1693 | |
| 11 | 6 | CC | RFC 1644 | |
| 12 | 6 | CC.NEW | RFC 1644 | |
| 13 | 6 | CC.ECHO | RFC 1644 | |
| 14 | 3 | Alternate Checksum Request | RFC 1146 | |
| 15 | N | Alternate Checksum Data | RFC 1146 | |
| 16 | | Skeeter | | |
| 17 | | Bubba | | |
| 18 | 3 | Trailer Checksum Option | | |
| 19 | 18 | MD5 Signature Option | RFC 2385 | |
| 20 | | SCPS Capabilities | | |
| 21 | | Selective Negative Acks | | |
| 22 | | Record Boundaries | | |
| 23 | | Corruption experienced | | |
| 24 | | SNAP | | |
| 25 | | Unassigned (released 12/18/00) | | |
| 26 | | TCP Compression Filter | | |
+----+-------+------------------------------------+----------+-----+
+----+-------+------------------------------------+----------+-----+
|Kind|Length | Meaning | RFC | Use |
| |octets | | | |
+----+-------+------------------------------------+----------+-----+
| 0 | - | End of Option List | RFC 793 | * |
| 1 | - | No-Operation | RFC 793 | * |
| 2 | 4 | Maximum Segment Size | RFC 793 | * |
| 3 | 3 | WSopt - Window Scale | RFC 1323 | * |
| 4 | 2 | SACK Permitted | RFC 2018 | * |
| 5 | N | SACK | RFC 2018 | * |
| 6 | 6 | Echo (obsoleted by option 8) | RFC 1072 | |
| 7 | 6 | Echo Reply (obsoleted by option 8) | RFC 1072 | |
| 8 | 10 | TSopt - Time Stamp Option | RFC 1323 | * |
| 9 | 2 | Partial Order Connection Permitted | RFC 1693 | |
| 10 | 3 | Partial Order Service Profile | RFC 1693 | |
| 11 | 6 | CC | RFC 1644 | |
| 12 | 6 | CC.NEW | RFC 1644 | |
| 13 | 6 | CC.ECHO | RFC 1644 | |
| 14 | 3 | Alternate Checksum Request | RFC 1146 | |
| 15 | N | Alternate Checksum Data | RFC 1146 | |
| 16 | | Skeeter | | |
| 17 | | Bubba | | |
| 18 | 3 | Trailer Checksum Option | | |
| 19 | 18 | MD5 Signature Option | RFC 2385 | |
| 20 | | SCPS Capabilities | | |
| 21 | | Selective Negative Acks | | |
| 22 | | Record Boundaries | | |
| 23 | | Corruption experienced | | |
| 24 | | SNAP | | |
| 25 | | Unassigned (released 12/18/00) | | |
| 26 | | TCP Compression Filter | | |
+----+-------+------------------------------------+----------+-----+
Figure 12. Common TCP Options
图12。通用TCP选项
The 'use' column is marked with '*' to indicate options that are most likely to be seen in TCP flows. Also note that RFC 1072 [4] has been obsoleted by RFC 1323 [7], although the original bit usage is defined only in RFC 1072.
“use”列用“*”标记，以指示最有可能在TCP流中看到的选项。还请注意，RFC 1072[4]已被RFC 1323[7]淘汰，尽管原始位使用仅在RFC 1072中定义。
Generally speaking, all option fields have been classified as changing. This section describes the behavior of each option referenced within an RFC, listed by 'kind' indicator.
一般来说，所有选项字段都被归类为“更改”。本节描述RFC中引用的每个选项的行为，这些选项由“种类”指示符列出。
0: End of Option List
0:选项列表结束
This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not at the end of each option, and it need only be used if the end of the options would not otherwise coincide with the end of the TCP header. Defined in RFC 793 [2].
此选项代码表示选项列表的结束。根据数据偏移量字段，这可能与TCP头的结尾不一致。此选项用于所有选项的末尾，而不是每个选项的末尾，并且仅当选项的结尾与TCP标头的结尾不一致时才需要使用。在RFC 793[2]中定义。
There is no data associated with this option, so a compression scheme must simply be able to encode its presence. However, note that since this option marks the end of the list and the TCP options are 4-octet aligned, there may be octets of padding (defined to be '0' in [2]) after this option.
没有与此选项关联的数据，因此压缩方案必须能够简单地对其存在进行编码。但是，请注意，由于此选项标记列表的结尾，并且TCP选项是4个八位字节对齐的，因此此选项后面可能有八位字节的填充（在[2]中定义为“0”）。
1: No-Operation
1：没有操作
This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary RFC 793 [2]. There is no data associated with this option, so a compression scheme must simply be able to encode its presence. This may be done by noting that the option simply maintains a certain alignment and that compression need only convey this alignment. In this way, padding can just be removed.
此选项代码可在选项之间使用，例如，在单词边界上对齐后续选项的开头。无法保证发送方将使用此选项，因此接收方必须准备好处理选项，即使这些选项不是从字边界RFC 793开始[2]。没有与此选项关联的数据，因此压缩方案必须能够简单地对其存在进行编码。这可以通过注意该选项仅保持一定的对齐来实现，并且压缩只需要传递该对齐。这样，填充物就可以被移除。
2: Maximum Segment Size
2：最大段大小
If this option is present, then it communicates the maximum segment size that may be used to send a packet to this end-host. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed RFC 793 [2].
如果存在此选项，则它将传递可用于向该终端主机发送数据包的最大段大小。此字段只能在初始连接请求中发送（即，在设置了SYN控制位的段中）。如果未使用此选项，则RFC 793[2]允许任何段大小。
This option is very common. The segment size is a 16-bit quantity. Theoretically, this could take any value; however there are a number of values that are common. For example, 1460 bytes is very common for TCP/IPv4 over Ethernet (though with the increased prevalence of tunnels, for example, smaller
这种选择非常普遍。段大小为16位数量。理论上，这可以是任何价值；但是，有许多值是通用的。例如，1460字节对于以太网上的TCP/IPv4是非常常见的（尽管随着隧道的普及，例如，更小的网络）
values such as 1400 have become more popular). 536 bytes is the default MSS value. This may allow for common values to be encoded more efficiently.
1400等值已变得更受欢迎）。536字节是默认的MSS值。这可能允许更有效地编码公共值。
3: Window Scale Option (WSopt)
3：窗口比例选项（WSopt）
This option may be sent in a SYN segment by the TCP end-host (1) to indicate that the sending TCP end-host is prepared to perform both send and receive window scaling, and (2) to communicate a scale factor to be applied to its receive window.
此选项可由TCP终端主机（1）在SYN段中发送，以指示发送TCP终端主机准备执行发送和接收窗口缩放，以及（2）传送要应用于其接收窗口的缩放因子。
The scale factor is encoded logarithmically as a power of 2 (presumably to be implemented by binary shifts). Note that the window in the SYN segment itself is never scaled (RFC 1072 [4]). This option may be sent in an initial segment (i.e., in a segment with the SYN bit on and the ACK bit off). It may also be sent in later segments, but only if a Window Scale option was received in the initial segment. A Window Scale option in a segment without a SYN bit should be ignored. The Window field in a SYN segment itself is never scaled (RFC 1323 [7]).
比例因子以2的幂对数编码（可能通过二进制移位实现）。请注意，SYN段中的窗口本身从不缩放（RFC 1072[4]）。该选项可在初始段中发送（即，在SYN位打开且ACK位关闭的段中）。它也可以在以后的段中发送，但仅当在初始段中收到窗口缩放选项时。不带SYN位的段中的窗口比例选项应忽略。SYN段中的窗口字段本身从不缩放（RFC 1323[7]）。
The use of window scaling does not affect the encoding of any other field during the lifetime of the flow. Only the encoding of the window scaling option itself is important. The window scale must be between 0 and 14 (inclusive). Generally, smaller values would be expected (a window scale of 14 allows for a 1Gbyte window, which is extremely large).
在流的生命周期内，窗口缩放的使用不会影响任何其他字段的编码。只有窗口缩放选项本身的编码才重要。窗口比例必须介于0和14之间（包括0和14）。通常，预期值较小（14的窗口比例允许1G字节的窗口，这是非常大的）。
4: SACK-Permitted
4：允许使用麻袋
This option may be sent in a SYN by a TCP that has been extended to receive (and presumably to process) the SACK option once the connection has opened RFC 2018 [12]. There is no data in this option all that is required is for the presence of the option to be encoded.
此选项可由TCP在SYN中发送，该TCP已扩展为在连接打开RFC 2018后接收（并可能处理）SACK选项[12]。该选项中没有数据，只需存在待编码的选项即可。
5: SACK
5：麻袋
This option is to be used to convey extended acknowledgment information over an established connection. Specifically, it is to be sent by a data receiver to inform the data transmitter of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data in later retransmissions to fill the gaps in sequence space between these blocks. At that time, the data receiver acknowledges the data, normally by advancing the left window edge in the
此选项用于通过已建立的连接传递扩展确认信息。具体地说，它将由数据接收器发送，以通知数据发送器已接收并排队的非连续数据块。数据接收器在稍后的重传中等待数据的接收，以填补这些块之间的序列空间中的间隙。此时，数据接收器确认数据，通常是通过在
Acknowledgment Number field of the TCP header. It is important to understand that the SACK option will not change the meaning of the Acknowledgment Number field, whose value will still specify the left window edge, i.e., one byte beyond the last sequence number of fully received data (RFC 2018 [12]).
TCP标头的确认号字段。重要的是要理解SACK选项不会改变确认号字段的含义，该字段的值仍将指定左窗口边缘，即超出完全接收数据的最后序列号一个字节（RFC 2018[12]）。
If SACK has been negotiated (through an exchange of SACK-Permitted options), then this option may occur when dropped segments are noticed by the receiver. Because this identifies ranges of blocks within the receiver's window, it can be viewed as a base value with a number of offsets. The base value (left edge of the first block) can be viewed as offset from the TCP acknowledgement number. There can be up to 4 SACK blocks in a single option. SACK blocks may occur in a number of segments (if there is more out-of-order data 'on the wire'), and this will typically extend the size of or add to the existing blocks.
如果已协商SACK（通过交换SACK允许的选项），则当接收方注意到丢弃的段时，可能会出现此选项。因为这标识了接收器窗口内的块范围，所以可以将其视为具有多个偏移的基值。基本值（第一个块的左边缘）可以视为与TCP确认号的偏移量。一个选项中最多可以有4个SACK块。SACK块可能出现在多个段中（如果“线路上”有更多无序数据），这通常会扩展现有块的大小或添加到现有块中。
Alternative proposals such as DSACK RFC 2883 [17] do not fundamentally change the behavior of the SACK block, from the point of view of the information contained within it.
从SACK块中包含的信息的角度来看，DSACK RFC 2883[17]等替代方案不会从根本上改变SACK块的行为。
6: Echo
6:Echo
This option carries information that the receiving TCP may send back in a subsequent TCP Echo Reply option (see below). A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received in a SYN segment for the connection. When the TCP echo option is used for RTT measurement, it will be included in data segments, and the four information bytes will define the time at which the data segment was transmitted in any format convenient to the sender (see RFC 1072 [4]).
此选项携带接收TCP可能在后续TCP回送回复选项中发回的信息（见下文）。如果在TCP段中接收到Echo选项，则只能在TCP段中发送Echo选项，而在TCP段中接收到Echo选项。当TCP echo选项用于RTT测量时，它将包含在数据段中，四个信息字节将定义数据段以发送方方便的任何格式传输的时间（参见RFC 1072[4]）。
The Echo option is generally not used in practice -- it is obsoleted by the Timestamp option. However, for transparency it is desirable that a compression scheme be able to transport it. (However, there is no benefit in attempting any treatment more sophisticated than viewing it as a generic 'option').
Echo选项在实践中通常不被使用——它已被Timestamp选项淘汰。然而，为了透明，压缩方案能够传输它是可取的。（然而，尝试任何比将其视为通用“选项”更复杂的治疗都没有好处）。
7: Echo Reply
7：回音回复
A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo Reply option. This TCP Echo Reply option must be returned in the next segment (e.g., an ACK segment) that is sent. If more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to echo,
接收包含四个信息字节的TCP回显选项的TCP将在TCP回显回复选项中返回这些相同的字节。此TCP回送回复选项必须在发送的下一段（例如，ACK段）中返回。如果在发送应答段之前收到多个回送选项，TCP必须只选择其中一个回送选项，
ignoring the others; specifically, it must choose the newest segment with the oldest sequence number (see RFC 1072 [4]).
忽视其他人；具体而言，它必须选择最新的段和最旧的序列号（参见RFC 1072[4]）。
The Echo Reply option is generally not used in practice -- it is obsoleted by the Timestamp option. However, for transparency it is desirable that a compression scheme be able to transport it. (However, there is no benefit in attempting any more sophisticated treatment than viewing it as a generic 'option').
Echo-Reply选项在实践中通常不使用——它已被Timestamp选项淘汰。然而，为了透明，压缩方案能够传输它是可取的。（然而，尝试任何更为复杂的治疗方法都不会比将其视为一种通用的“选项”有任何好处）。
8: Timestamps
8：时间戳
This option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echoes a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., a segment containing a SYN bit and no ACK bit), and it may send a TSopt in other segments only if it received a TSopt in the initial segment for the connection (see RFC 1323 [7]). Timestamps are quite commonly used. If timestamp options are exchanged in the connection set-up phase, then they are expected to appear on all subsequent segments. If this exchange does not happen, then they will not appear for the remainder of the flow.
此选项携带两个四字节时间戳字段。时间戳值字段（TSval）包含发送选项的TCP的时间戳时钟的当前值。只有在TCP报头中设置了ACK位时，时间戳回显回复字段（TSecr）才有效；如果有效，它将在Timestamps选项的TSval字段中回显远程TCP发送的时间戳值。当TSecr无效时，其值必须为零。TSecr值通常来自接收到的最新时间戳选项；但是，也有一些例外情况将在下文中解释。TCP可在初始段（即，包含SYN位且无ACK位的段）中发送时间戳选项（TSopt），并且仅当其在连接的初始段中接收到TSopt时，才可在其他段中发送TSopt（参见RFC 1323[7]）。时间戳非常常用。如果在连接设置阶段交换了时间戳选项，则它们将出现在所有后续段上。如果此交换未发生，则在流的其余部分，它们将不会出现。
Because the value being carried is a timestamp, it is logical to expect that the entire value need not be carried. There is no obvious pattern of increments that might be expected, however.
因为所携带的值是一个时间戳，所以期望不携带整个值是合乎逻辑的。然而，没有明显的增长模式是可以预期的。
An important reason for using the timestamp option is to allow detection of sequence space wrap-around (Protection Against Wrapped Sequence-number, or PAWS, see RFC 1323 [7]). It is not expected that this is a serious concern on the links on which TCP header compression would be deployed, but it is important that the integrity of this option be maintained. This issue is discussed in, for example, RFC 3150 [32]. However, the proposed Eifel algorithm [35] makes use of timestamps, so it is currently recommended that timestamps be used for cellular-type links [34].
使用时间戳选项的一个重要原因是允许检测序列空间环绕（针对环绕序列号或PAW的保护，见RFC 1323[7]）。在部署TCP报头压缩的链路上，这并不是一个严重的问题，但保持此选项的完整性很重要。例如，RFC 3150[32]中讨论了该问题。然而，拟议的Eifel算法[35]使用时间戳，因此目前建议将时间戳用于蜂窝式链路[34]。
With regard to compression, note that the range of resolutions for the timestamp suggested in RFC 1323 [7] is quite wide (1ms to 1s per 'tick'). This (along with the perhaps wide variation in RTT) makes it hard to select a set of encodings that will be optimal in all cases.
关于压缩，请注意，RFC 1323[7]中建议的时间戳分辨率范围相当宽（每“滴答”一次为1ms到1s）。这（以及RTT中可能存在的广泛变化）使得很难选择一组在所有情况下都是最优的编码。
9: Partial Order Connection (POC) permitted
9：允许部分订购连接（POC）
This option represents a simple indicator communicated between the two peer transport entities to establish the operation of the POC protocol. See RFC 1693 [9].
此选项表示两个对等传输实体之间通信的简单指示符，以建立POC协议的操作。参见RFC 1693[9]。
The Partial Order Connection option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
偏序连接选项在当前互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。
10: POC service profile
10:POC服务配置文件
This option serves to communicate the information necessary to carry out the job of the protocol -- the type of information that is typically found in the header of a TCP segment. The Partial Order Connection option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
此选项用于传递执行协议作业所需的信息——通常在TCP段的标头中找到的信息类型。偏序连接选项在当前互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。
11: Connection Count (CC)
11：连接计数（CC）
This option is part of the implementation of TCP Accelerated Open (TAO) that effectively bypasses the TCP Three-Way Handshake (3WHS). TAO introduces a 32-bit incarnation number, called a "connection count" (CC), that is carried in a TCP option in each segment. A distinct CC value is assigned to each direction of an open connection. The implementation assigns monotonically increasing CC values to successive connections that it opens actively or passively (see RFC 1644 [8]). This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
此选项是TCP加速开放（TAO）实现的一部分，它有效地绕过了TCP三方握手（3WHS）。TAO引入了一个32位的具体数字，称为“连接计数”（CC），它在每个段的TCP选项中携带。将为打开连接的每个方向指定一个不同的CC值。该实现将单调递增的CC值分配给其主动或被动打开的连续连接（参见RFC 1644[8]）。该选项在当前的互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。
12: CC.NEW
12:CC.NEW
Correctness of the TAO mechanism requires that clients generate monotonically increasing CC values for successive connection initiations. Receiving a CC.NEW causes the server to invalidate its cache entry and to do a 3WHS. See RFC 1644 [8]. This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
TAO机制的正确性要求客户端为连续的连接启动生成单调递增的CC值。接收CC.NEW会导致服务器使其缓存项无效并执行3WHS。见RFC 1644[8]。该选项在当前的互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。
13: CC.ECHO
13:CC.ECHO
When a server host sends a segment, it echoes the connection count from the initial in a CC.ECHO option, which is used by the client host to validate the segment (see RFC 1644 [8]). This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.
当服务器主机发送一个段时，它会在CC.ECHO选项中回显初始值的连接计数，客户端主机使用该选项来验证该段（请参阅RFC 1644[8]）。该选项在当前的互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。
14: Alternate Checksum Request
14：备用校验和请求
This option may be sent in a SYN segment by a TCP to indicate that the TCP is prepared to both generate and receive checksums based on an alternate algorithm. During communication, the alternate checksum replaces the regular TCP checksum in the checksum field of the TCP header. Should the alternate checksum require more than 2 octets to transmit, either the checksum may be moved into a TCP Alternate Checksum Data Option and the checksum field of the TCP header be sent as zero, or the data may be split between the header field and the option. Alternate checksums are computed over the same data as the regular TCP checksum; see RFC 1146 [5].
此选项可由TCP在SYN段中发送，以指示TCP已准备好基于备用算法生成和接收校验和。在通信过程中，备用校验和替换TCP报头校验和字段中的常规TCP校验和。如果备用校验和需要2个以上的八位字节进行传输，则校验和可以移动到TCP备用校验和数据选项中，TCP报头的校验和字段可以作为零发送，或者数据可以在报头字段和选项之间分割。在与常规TCP校验和相同的数据上计算备用校验和；参见RFC 1146[5]。
This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it. It would only occur in connection set-up (SYN) packets. Even if this option were used, it would not affect the handling of the checksum, since this should be carried transparently in any case.
该选项在当前的互联网中几乎没有（或根本没有）用处，因此唯一的要求是报头压缩方案能够对其进行编码。它只会出现在连接设置（SYN）数据包中。即使使用了此选项，也不会影响校验和的处理，因为在任何情况下都应该透明地进行。
15: Alternate Checksum Data
15：备用校验和数据
This field is used only when the alternate checksum that is negotiated is longer than 16 bits. These checksums will not fit in the checksum field of the TCP header and thus at least part of them must be put in an option. Whether the checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the option is determined on a checksum-by-checksum basis. The length of this option will depend on the choice of alternate checksum algorithm for this connection; see RFC 1146 [5].
仅当协商的备用校验和大于16位时，才使用此字段。这些校验和不适合TCP报头的校验和字段，因此必须将其中至少一部分放入选项中。是在TCP标头和选项中的校验和字段之间拆分校验和，还是将整个校验和放置在选项中，取决于逐个校验和的基础。此选项的长度取决于此连接的备用校验和算法的选择；参见RFC 1146[5]。
If an alternative checksum was negotiated in the connection set-up, then this option may appear on all subsequent packets (if needed to carry the checksum data). However, this option is in practice never seen, so the only requirement is that the header compression scheme be able to encode it.
如果在连接设置中协商了备用校验和，则此选项可能出现在所有后续数据包上（如果需要携带校验和数据）。然而，这个选项在实践中从未见过，所以唯一的要求是报头压缩方案能够对其进行编码。
16 - 18:
16 - 18:
These non-RFC option types are not considered in this document.
本文件不考虑这些非RFC选项类型。
19: MD5 Digest
19:MD5摘要
Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to a concatenated block of data [13].
在TCP连接上发送的每个要防止欺骗的段将包含16字节的MD5摘要，该摘要是通过将MD5算法应用于连接的数据块而产生的[13]。
Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digests. A failing comparison must result in the segment's being dropped and must not produce any response back to the sender. Logging the failure is probably advisable.
接收到签名段后，接收方必须通过从相同数据（使用自己的密钥）计算自己的摘要并比较两个摘要来验证该段。比较失败必须导致删除段，并且不能向发送方返回任何响应。记录故障可能是可取的。
Unlike other TCP extensions (e.g., the Window Scale option [7]), the absence of the option in the SYN-ACK segment must not cause the sender to disable its sending of signatures. This negotiation is typically done to prevent some TCP implementations from misbehaving upon receiving options in non-SYN segments. This is not a problem for this option, since the SYN-ACK sent during connection negotiation will not be signed and will thus be ignored. The connection will never be made, and non-SYN segments with options will never be sent. More importantly, the sending of signatures must be under the complete control of the application, not at the mercy of a remote host not understanding the option. MD5 digest information should, like any cryptographically secure data, be incompressible. Therefore the compression scheme must simply transparently carry this option, if it occurs.
与其他TCP扩展（例如，窗口缩放选项[7]）不同，SYN-ACK段中没有该选项不得导致发送方禁用其签名发送。这种协商通常是为了防止某些TCP实现在接收非SYN段中的选项时出现错误行为。此选项没有问题，因为在连接协商期间发送的SYN-ACK不会被签名，因此将被忽略。永远不会建立连接，并且永远不会发送带有选项的非SYN段。更重要的是，签名的发送必须在应用程序的完全控制下进行，而不是任由不了解该选项的远程主机摆布。MD5摘要信息应该像任何加密安全的数据一样，是不可压缩的。因此，如果出现这种情况，压缩方案必须简单透明地携带该选项。
20 - 26;
20 - 26;
Thse non-RFC option types are not considered in this document. This only means that their behavior is not described in detail, as a compression scheme is not expected to be optimised for these options. However, any unrecognised option must be carried by a TCP compression scheme transparently, in order to work efficiently in the presence of new or rare options.
本文件不考虑非RFC选项类型。这只意味着没有详细描述它们的行为，因为预计压缩方案不会针对这些选项进行优化。然而，TCP压缩方案必须透明地携带任何未识别的选项，以便在出现新的或罕见的选项时有效地工作。
The above list covers options known at the time of writing. Other options are expected to be defined. It is important that any future options can be handled by a header compression scheme. The processing of as-yet undefined options cannot be optimised but, at the very least, unknown options should be carried transparently.
上述列表涵盖了撰写本文时已知的选项。预计将定义其他选项。重要的是，将来的任何选项都可以通过头压缩方案处理。无法优化尚未定义的选项的处理，但至少应透明地执行未知选项。
The current model for TCP options is that an option is negotiated in the SYN exchange and used thereafter, if the negotiation succeeds. This leads to some assumptions about the presence of options (being only on packets with the SYN flag set, or appearing on every packet, for example). Where such assumptions hold true, it may be possible to optimise compression of options slightly. However, it is seen as undesirable to be so constrained, as there is no guarantee that option handling and negotiation will remain the same in the future. Also note that a compressor may not process the SYN packets of a flow and cannot, therefore, be assumed to know which options have been negotiated.
TCP选项的当前模型是，在SYN交换中协商一个选项，并在协商成功后使用该选项。这导致了一些关于选项存在的假设（例如，仅在设置了SYN标志的数据包上，或出现在每个数据包上）。如果这些假设成立，则可以稍微优化期权的压缩。然而，这种限制被认为是不可取的，因为无法保证期权处理和谈判在未来会保持不变。还要注意，压缩器可能不处理流的SYN分组，因此不能假定知道哪些选项已经协商。
There may be a small number of cues for 'implicit acknowledgements' in a TCP flow. Even if the compressor only sees the data transfer direction, for example, seeing a packet without the SYN flag set implies that the SYN packet has been received.
TCP流中可能有少量“隐式确认”提示。即使压缩器仅看到数据传输方向，例如，看到没有设置SYN标志的分组也意味着已经接收到SYN分组。
There is a clear requirement for the deployment of compression to be topologically independent. This means that it is not actually possible to be sure that seeing a data packet at the compressor guarantees that the SYN packet has been correctly received by the decompressor (as the SYN packet may have taken an alternative path).
有一个明确的要求，即压缩部署在拓扑上是独立的。这意味着实际上不可能确保在压缩器处看到数据分组可以保证SYN分组已被解压器正确接收（因为SYN分组可能已采取替代路径）。
However, there may be other such cues, which may be used in certain circumstances to improve compression efficiency.
然而，可能存在其他此类提示，这些提示可在某些情况下用于提高压缩效率。
It can be seen that there are two distinct deployments (i) where the forward (data) and reverse (ACK) path are both carried over a common link, and (ii) where the forward (data) and reverse (ACK) path are carried over different paths, with a specific link carrying packets corresponding to only one direction of communication.
可以看出，存在两种不同的部署（i）其中前向（数据）和反向（ACK）路径都通过公共链路承载，以及（ii）其中前向（数据）和反向（ACK）路径通过不同的路径承载，特定链路承载仅对应于一个通信方向的分组。
In the former case, a compressor and decompressor could be colocated. It may then be possible for the compressor and decompressor at each end of the link to exchange information. This could lead to possible optimizations.
在前一种情况下，压缩机和减压器可以共用。然后，链路两端的压缩机和减压器可以交换信息。这可能导致可能的优化。
For example, acknowledgement numbers are generally taken from the sequence numbers in the opposite direction. Since an acknowledgement cannot be generated for a packet that has not passed across the link, this offers an efficient way of encoding acknowledgements.
例如，确认号通常取自相反方向的序列号。由于无法为未通过链路的数据包生成确认，因此这提供了一种对确认进行编码的有效方法。
For a TCP bulk data-transfer, the overhead of the TCP header does not form a large proportion of the data packet (e.g., < 3% for a 1460 octet packet), particularly compared to the typical RTP voice case. Spectral efficiency is clearly an important goal. However, extracting every last bit of compression gain offers only marginal benefit at a considerable cost in complexity. This trade-off, of efficiency and complexity, must be addressed in the design of a TCP compression profile.
对于TCP批量数据传输，TCP报头的开销在数据包中所占比例不大（例如，对于1460个八位组的数据包，其开销小于3%），特别是与典型的RTP语音情况相比。频谱效率显然是一个重要目标。然而，提取每一个压缩增益的最后一位只提供了边际效益，但复杂度却相当高。在设计TCP压缩配置文件时，必须解决效率和复杂性之间的权衡问题。
However, in the acknowledgement direction (i.e., for 'pure' acknowledgement headers), the overhead could be said to be infinite (since there is no data being carried). This is why optimizations for the acknowledgement path may be considered useful.
然而，在确认方向（即，对于“纯”确认报头），开销可以说是无限的（因为没有携带数据）。这就是为什么确认路径的优化可能被认为是有用的。
There are a number of schemes for manipulating TCP acknowledgements to reduce the ACK bandwidth. Many of these are documented in [33] and [32]. Most of these schemes are entirely compatible with header compression, without requiring any particular support. While it is not expected that a compression scheme will be optimised for experimental options, it is useful to consider these when developing header compression schemes, and vice versa. A header compression scheme must be able to support any option (including ones as yet undefined).
有许多方案用于操纵TCP确认以减少ACK带宽。其中许多记录在[33]和[32]中。这些方案中的大多数都与报头压缩完全兼容，不需要任何特定的支持。虽然没有预料到压缩方案将被优化为实验选项，但在开发头压缩方案时考虑这些是有用的，反之亦然。头压缩方案必须能够支持任何选项（包括尚未定义的选项）。
It should be apparent that direct comparisons with the highly 'packet'-based view of RTP compression are hard. RTP header fields tend to change regularly per-packet, and many fields (IPv4 IP ID, RTP sequence number, and RTP timestamp, for example) typically change in a dependent manner. However, TCP fields, such as sequence number tend to change more unpredictably, partly because of the influence of external factors (size of TCP windows, application behavior, etc.). Also, the field values tend to change independently. Overall, this makes compression more challenging and makes it harder to select a set of encodings that can successfully trade off efficiency and robustness.
显然，很难与RTP压缩的高度“基于数据包”的观点进行直接比较。RTP报头字段倾向于每个数据包定期更改，许多字段（例如IPv4 IP ID、RTP序列号和RTP时间戳）通常以依赖的方式更改。然而，TCP字段（如序列号）的变化往往更不可预测，部分原因是外部因素（TCP窗口的大小、应用程序行为等）的影响。此外，字段值往往会独立更改。总的来说，这使得压缩更具挑战性，更难选择一组能够成功权衡效率和健壮性的编码。
It is hard to see what can be done to improve performance for a single, unpredictable, short-lived connection. However, there are commonly cases where there will be multiple TCP connections between the same pair of hosts. As a particular example, consider web browsing (this is more the case with HTTP/1.0 [25] than with HTTP/1.1 [26]).
对于一个单一的、不可预测的、短期的连接，很难看到可以做些什么来提高性能。但是，通常情况下，同一对主机之间会有多个TCP连接。作为一个特定的例子，考虑Web浏览（HTTP／1（25）比HTTP／1.1（26））更为常见。
When a connection closes, either it is the last connection between that pair of hosts or it is likely that another connection will open within a relatively short space of time. In this case, the IP header part of the context (i.e., those fields characterised in Section 2.1) will probably be almost identical. Certain aspects of the TCP context may also be similar.
当一个连接关闭时，要么它是这对主机之间的最后一个连接，要么另一个连接可能会在相对较短的时间内打开。在这种情况下，上下文的IP报头部分（即第2.1节中描述的字段）可能几乎相同。TCP上下文的某些方面也可能类似。
Support for context replication is discussed in more detail in Section 3. Overall, support for sub-context sharing or initializing one context from another offers useful optimizations for a sequence of short-lived connections.
第3节将更详细地讨论对上下文复制的支持。总的来说，支持子上下文共享或从一个上下文初始化另一个上下文为一系列短期连接提供了有用的优化。
Note that, although TCP is connection oriented, it is hard for a compressor to tell whether a TCP flow has finished. For example, even in the 'bi-directional' link case, seeing a FIN and the ACK of the FIN at the compressor/decompressor does not mean that the FIN cannot be retransmitted. Thus, it may be more useful to think about initializing a new context from an existing one, rather than re-using an existing one.
注意，尽管TCP是面向连接的，但压缩器很难判断TCP流是否已完成。例如，即使在“双向”链路情况下，在压缩器/减压器处看到FIN和FIN的ACK并不意味着FIN无法重新传输。因此，考虑从现有上下文初始化新上下文可能比重新使用现有上下文更有用。
As mentioned previously in Section 4.1.3, the IP header can clearly be shared between any transport-layer flows between the same two end-points. There may be limited scope for initialisation of a new TCP header from an existing one. The port numbers are the most obvious starting point.
如前文第4.1.3节所述，IP报头显然可以在相同两个端点之间的任何传输层流之间共享。从现有TCP头初始化新TCP头的范围可能有限。端口号是最明显的起点。
As pointed out earlier, in Section 4.1.3, there is no obvious candidate for a 'master sequence number' in TCP. Moreover, it is noted that such a master sequence number is only required to allow a decompressor to acknowledge packets in bi-directional mode. It can also be seen that such a sequence number would not be required for every packet.
如前所述，在第4.1.3节中，TCP中没有明显的“主序列号”。此外，应注意，仅当允许解压缩器以双向模式确认分组时，才需要这样的主序列号。还可以看出，并非每个数据包都需要这样的序列号。
While the sequence number only needs to be 'sparse', it is clear that there is a requirement for an explicitly added sequence number. There are no obvious ways to guarantee the unique identity of a packet other than by adding such a sequence number (sequence and acknowledgement numbers can both remain the same, for example).
虽然序列号只需要是“稀疏的”，但显然需要显式添加序列号。除了添加这样的序列号（例如，序列号和确认号可以保持相同）之外，没有明显的方法来保证数据包的唯一身份。
As can be seen from the above analysis, most TCP options, such as MSS, WSopt, or SACK-Permitted, may appear only on a SYN segment. Every implementation should (and we expect that most will) ignore unknown options on SYN segments. TCP options will be sent on non-SYN segments only when an exchange of options on the SYN segments has
从上面的分析可以看出，大多数TCP选项（如MSS、WSopt或SACK）可能仅出现在SYN段上。每个实现都应该（我们期望大多数实现都会）忽略SYN段上的未知选项。只有在SYN段上的选项交换已完成时，才会在非SYN段上发送TCP选项
indicated that both sides understand the extension. Other TCP options, such as MD5 Digest or Timestamp, also tend to be sent when the connection is initiated (i.e., in the SYN packet).
表示双方都理解延伸。其他TCP选项，如MD5摘要或时间戳，也倾向于在连接启动时发送（即，在SYN数据包中）。
The total header size is also an issue. The TCP header specifies where segment data starts with a 4-bit field that gives the total size of the header (including options) in 32-bit words. This means that the total size of the header plus option must be less than or equal to 60 bytes. This leaves 40 bytes for options.
标题的总大小也是一个问题。TCP标头指定段数据以4位字段开头的位置，该字段以32位字表示标头（包括选项）的总大小。这意味着header plus选项的总大小必须小于或等于60字节。这将为选项留下40个字节。
Since this document only describes TCP field behavior, it raises no direct security concerns.
由于本文档仅描述TCP字段行为，因此不会引起直接的安全问题。
This memo is intended to be used to aid the compression of TCP/IP headers. Where authentication mechanisms such as IPsec AH [24] are used, it is important that compression be transparent. Where encryption methods such as IPsec ESP [27] are used, the TCP fields may not be visible, preventing compression.
此备忘录旨在帮助压缩TCP/IP标头。在使用IPsec AH[24]等身份验证机制的情况下，压缩必须透明。在使用IPsec ESP[27]等加密方法的情况下，TCP字段可能不可见，从而阻止压缩。
Many IP and TCP RFCs (hopefully all of which have been collated below), together with header compression schemes from RFC 1144 [22], RFC 3544 [36], and RFC 3095 [31], and of course the detailed analysis of RTP/UDP/IP in RFC 3095, have been sources of ideas and knowledge. Further background information can also be found in [28] and [29].
许多IP和TCP RFC（希望所有这些都已在下面进行了整理）以及来自RFC 1144[22]、RFC 3544[36]和RFC 3095[31]的头压缩方案，当然还有RFC 3095中对RTP/UDP/IP的详细分析，都是思想和知识的来源。更多背景信息也可在[28]和[29]中找到。
This document also benefited from discussion on the ROHC mailing list and in various corridors (virtual or otherwise) about many key issues; special thanks go to Qian Zhang, Carsten Bormann, and Gorry Fairhurst.
本文件还得益于ROHC邮件列表和各种走廊（虚拟或其他）关于许多关键问题的讨论；特别感谢钱章、卡斯滕·鲍曼和戈里·费尔赫斯特。
Qian Zhang and Hongbin Liao contributed the extensive analysis of shareable header fields.
钱章和廖宏斌对可共享头字段进行了广泛的分析。
Any remaining misrepresentation or misinterpretation of information is entirely the fault of the authors.
任何剩余的对信息的误传或曲解完全是作者的过错。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] 《传输控制协议》，标准7，RFC 793，1981年9月。
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[3] Nagle，J.，“IP/TCP网络中的拥塞控制”，RFC 896，1984年1月。
[4] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[4] Jacobson，V.和R.Braden，“长延迟路径的TCP扩展”，RFC 1072，1988年10月。
[5] Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990.
[5] Zweig，J.和C.Partridge，“TCP备用校验和选项”，RFC 1146，1990年3月。
[6] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[6] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[7] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7] Jacobson，V.，Braden，B.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[8] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[8] Braden，B，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月。
[9] Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP: Partial Order Service", RFC 1693, November 1994.
[9] Connolly，T.，Amer，P.，和P.Conrad，“TCP的扩展：部分订单服务”，RFC 1693，1994年11月。
[10] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[10] Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[11] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[11] McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[12] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[12] Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[13] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[14] Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[15] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[15] Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[16] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[16] Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[17] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[17] Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[18] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[18] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[19] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[19] Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC3540，2003年6月。
[20] IANA, "IANA", IANA TCP options, February 1998, <http://www.iana.org/assignments/tcp-parameters>.
[20] IANA，“IANA”，IANA TCP选项，1998年2月<http://www.iana.org/assignments/tcp-parameters>.
[21] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[21] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[22] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[22] Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC 1144，1990年2月。
[23] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[23] Almquist，P.，“互联网协议套件中的服务类型”，RFC 1349，1992年7月。
[24] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[24] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[25] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[25] Berners Lee，T.，Fielding，R.，和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[27] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[27] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[26] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[26] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[28] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[28] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[29] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[29] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[30] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[30] Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 27802000年3月。
[31] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[31] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[32] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[32] Dawkins，S.，黑山，G.，Kojo，M.，和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[33] Balakrishnan, Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", RFC 3449, December 2002.
[33] Balakrishnan，Padmanabhan，V.，Fairhurst，G.，和M.Sooriyabandara，“网络路径不对称对TCP性能的影响”，RFC 3449，2002年12月。
[34] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", RFC 3481, February 2003.
[34] Inamura，H.，黑山，G.，路德维希，R.，Gurtov，A.，和F.Khafizov，“第二代（2.5G）和第三代（3G）无线网络上的TCP”，RFC 3481，2003年2月。
[35] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[35] Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[36] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[36] Engan，M.，Casner，S.，Bormann，C.，和T.Koren，“PPP上的IP报头压缩”，RFC 3544，2003年7月。
[37] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[37] Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网设计师的建议”，BCP 89，RFC 3819，2004年7月。
Authors' Addresses
作者地址
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Mark A.West Siemens/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Stephen McCann Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Stephen McCann西门子/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833341
EMail: stephen.mccann@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833341
EMail: stephen.mccann@roke.co.uk
URI: http://www.roke.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。