Network Working Group R. Friend
Request for Comments: 3943 Hifn
Category: Informational November 2004
Network Working Group R. Friend
Request for Comments: 3943 Hifn
Category: Informational November 2004
Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
使用Lempel-Ziv-Stac（LZS）的传输层安全（TLS）协议压缩
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol.
传输层安全（TLS）协议（RFC 2246）包括用于协商无损数据压缩方法的选择作为TLS握手协议的一部分，然后应用与所选方法相关联的算法作为TLS记录协议的一部分的特征。TLS定义了一种标准压缩方法，该方法指定通过记录协议交换的数据不会被压缩。本文档描述了与用于TLS的Lempel-Ziv-Stac（LZS）无损数据压缩算法相关的附加压缩方法。本文件还定义了LZS算法在TLS记录协议中的应用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Specification of Requirements. . . . . . . . . . . . . . 3
2. Compression Methods. . . . . . . . . . . . . . . . . . . . . . 3
2.1. LZS CompresionMethod . . . . . . . . . . . . . . . . . . 4
2.2. Security Issues with Single History Compression. . . . . 4
3. LZS Compression. . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Background of LZS Compression . . . . . . . . . . . . . 4
3.2. LZS Compression History and Record Processing . . . . . 5
3.3. LZS Compressed Record Format . . . . . . . . . . . . . . 6
3.4. TLSComp Header Format . . . . . . . . . . . . . . . . . 6
3.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . 6
3.5. LZS Compression Encoding Format . . . . . . . . . . . . 7
3.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Sending Compressed Records . . . . . . . . . . . . . . . . . . 8
4.1. Transmitter Process. . . . . . . . . . . . . . . . . . . 9
4.2. Receiver Process . . . . . . . . . . . . . . . . . . . . 9
4.3. Anti-expansion Mechanism . . . . . . . . . . . . . . . . 10
5. Internationalization Considerations . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Specification of Requirements. . . . . . . . . . . . . . 3
2. Compression Methods. . . . . . . . . . . . . . . . . . . . . . 3
2.1. LZS CompresionMethod . . . . . . . . . . . . . . . . . . 4
2.2. Security Issues with Single History Compression. . . . . 4
3. LZS Compression. . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Background of LZS Compression . . . . . . . . . . . . . 4
3.2. LZS Compression History and Record Processing . . . . . 5
3.3. LZS Compressed Record Format . . . . . . . . . . . . . . 6
3.4. TLSComp Header Format . . . . . . . . . . . . . . . . . 6
3.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . 6
3.5. LZS Compression Encoding Format . . . . . . . . . . . . 7
3.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Sending Compressed Records . . . . . . . . . . . . . . . . . . 8
4.1. Transmitter Process. . . . . . . . . . . . . . . . . . . 9
4.2. Receiver Process . . . . . . . . . . . . . . . . . . . . 9
4.3. Anti-expansion Mechanism . . . . . . . . . . . . . . . . 10
5. Internationalization Considerations . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, CompressionMethod.null, which specifies that data exchanged via the record protocol will not be compressed. Although this single compression method helps ensure that TLS implementations are interoperable, the lack of additional standard compression methods has limited the ability to develop interoperative implementations that include data compression.
传输层安全（TLS）协议（RFC 2246，[2]）包括用于协商作为TLS握手协议的一部分的无损数据压缩方法的选择，然后应用与所选方法相关联的算法作为TLS记录协议的一部分的特征。TLS定义了一种标准压缩方法CompressionMethod.null，它指定通过记录协议交换的数据不会被压缩。尽管这种单一的压缩方法有助于确保TLS实现是可互操作的，但缺乏额外的标准压缩方法限制了开发包括数据压缩在内的互操作实现的能力。
TLS is used extensively to secure client-server connections on the World Wide Web. Although these connections can often be characterized as short-lived and exchanging relatively small amounts of data, TLS is also being used in environments where connections can be long-lived and the amount of data exchanged can extend into thousands or millions of octets. For example, TLS is now increasingly being used as an alternative Virtual Private Network (VPN) connection. Compression services have long been associated with IPSec and PPTP VPN connections, so extending compression services to TLS VPN connections preserves the user experience for any VPN connection. Compression within TLS is one way to help reduce the bandwidth and latency requirements associated with exchanging large amounts of data while preserving the security services provided by TLS.
TLS广泛用于保护万维网上的客户机-服务器连接。尽管这些连接通常可以被描述为短命的，并且交换的数据量相对较小，但TLS也被用于连接寿命较长且交换的数据量可以扩展到数千或数百万个八位字节的环境中。例如，TLS现在越来越多地被用作替代虚拟专用网络（VPN）连接。压缩服务长期以来一直与IPSec和PPTP VPN连接相关联，因此将压缩服务扩展到TLS VPN连接可以保留任何VPN连接的用户体验。TLS内的压缩是帮助减少与交换大量数据相关的带宽和延迟要求的一种方法，同时保留TLS提供的安全服务。
This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS. This document specifies the application of Lempel-Ziv-Stac (LZS) compression, a lossless compression algorithm, to TLS record payloads. This specification also assumes a thorough understanding of the TLS protocol [2].
本文档描述了与TLS使用的无损数据压缩算法相关的附加压缩方法。本文件规定了Lempel-Ziv-Stac（LZS）压缩（一种无损压缩算法）在TLS记录有效载荷中的应用。本规范还假设全面了解TLS协议[2]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
As described in section 6 of RFC 2246 [2], TLS is a stateful protocol. Compression methods used with TLS can be either stateful (the compressor maintains its state through all compressed records) or stateless (the compressor compresses each record independently), but there seems to be little known benefit in using a stateless compression method within TLS. The LZS compression method described in this document is stateful.
如RFC 2246[2]第6节所述，TLS是一种有状态协议。TLS使用的压缩方法可以是有状态的（压缩器通过所有压缩记录保持其状态）或无状态的（压缩器独立压缩每个记录），但在TLS中使用无状态压缩方法似乎没有什么好处。本文档中描述的LZS压缩方法是有状态的。
Compression algorithms can occasionally expand, rather than compress, input data. The worst-case expansion factor of the LZS compression method is only 12.5%. Thus, TLS records of 15K bytes can never exceed the expansion limits described in section 6.2.2 of RFC 2246 [2]. If TLS records of 16K bytes expand to an amount greater than 17K bytes, then the uncompressed version of the TLS record must be transmitted, as described below.
压缩算法有时会扩展而不是压缩输入数据。LZS压缩方法的最坏情况膨胀系数仅为12.5%。因此，15K字节的TLS记录永远不能超过RFC 2246[2]第6.2.2节中描述的扩展限制。如果16K字节的TLS记录扩展到17K字节以上，则必须传输TLS记录的未压缩版本，如下所述。
The LZS CompressionMethod is a 16-bit index and is negotiated as described in RFC 2246 [2] and RFC 3749 [3]. The LZS CompressionMethod is stored in the TLS Record Layer connection state as described in RFC 2246 [2].
LZS压缩方法是一种16位索引，按照RFC 2246[2]和RFC 3749[3]中的描述进行协商。LZS压缩方法存储在TLS记录层连接状态中，如RFC 2246[2]所述。
IANA has assigned 64 as compression method identifier for applying LZS compression to TLS record payloads.
IANA已指定64作为压缩方法标识符，用于将LZS压缩应用于TLS记录有效载荷。
Sharing compression histories between or among more than one TLS session may potentially cause information leakage between the TLS sessions, as pathological compressed data can potentially reference data prior to the beginning of the current record. LZS implementations guard against this situation. However, to avoid this potential threat, implementations supporting TLS compression MUST use separate compression histories for each TLS session. This is not a limitation of LZS compression but is an artifact for any compression algorithm.
在多个TLS会话之间或在多个TLS会话之间共享压缩历史可能导致TLS会话之间的信息泄漏，因为病理压缩数据可能引用当前记录开始之前的数据。LZS实现可以防止这种情况。然而，为了避免这种潜在的威胁，支持TLS压缩的实现必须为每个TLS会话使用单独的压缩历史记录。这不是LZS压缩的限制，而是任何压缩算法的伪影。
Furthermore, the LZS compression history (as well as any compression history) contains plaintext. Specifically, the LZS history contains the last 2K bytes of plaintext of the TLS session. Thus, when the TLS session terminates, the implementation SHOULD treat the history as it does any plaintext (e.g., free memory, overwrite contents).
此外，LZS压缩历史（以及任何压缩历史）包含纯文本。具体来说，LZS历史记录包含TLS会话的最后2K字节的明文。因此，当TLS会话终止时，实现应该像对待任何明文一样对待历史（例如，可用内存、覆盖内容）。
Starting with a sliding window compression history, similar to LZ1 [8], a new, enhanced compression algorithm identified as LZS was developed. The LZS algorithm is a general-purpose lossless compression algorithm for use with a wide variety of data types. Its encoding method is very efficient, providing compression for strings as short as two octets in length.
从滑动窗口压缩历史开始，类似于LZ1[8]，开发了一种新的增强压缩算法，称为LZS。LZS算法是一种通用无损压缩算法，可用于多种数据类型。它的编码方法非常有效，为长度短至两个八位字节的字符串提供压缩。
The LZS algorithm uses a sliding window of 2,048 bytes. During compression, redundant sequences of data are replaced with tokens that represent those sequences. During decompression, the original sequences are substituted for the tokens in such a way that the original data is exactly recovered. LZS differs from lossy compression algorithms, such as those often used for video compression, that do not exactly reproduce the original data. The details of LZS compression can be found in section 3.5 below.
LZS算法使用2048字节的滑动窗口。在压缩过程中，冗余的数据序列被替换为表示这些序列的标记。在解压期间，原始序列被替换为令牌，从而精确地恢复原始数据。LZS不同于有损压缩算法，例如通常用于视频压缩的有损压缩算法，后者不能精确地再现原始数据。LZS压缩的详细信息见下文第3.5节。
This standard specifies "stateful" compression -- that is, maintaining the compression history between records within a particular TLS compression session. Within each separate compression history, the LZS CompressionMethod can maintain compression history information when compressing and decompressing record payloads. Stateful compression provides a higher compression ratio to be achieved on the data stream, as compared to stateless compression (resetting the compression history between every record), particularly for small records.
该标准规定了“有状态”压缩——即在特定TLS压缩会话中维护记录之间的压缩历史。在每个单独的压缩历史中，LZS CompressionMethod可以在压缩和解压缩记录有效负载时维护压缩历史信息。与无状态压缩（重置每个记录之间的压缩历史）相比，有状态压缩在数据流上提供了更高的压缩比，特别是对于小记录。
Stateful compression requires both a reliable link and sequenced record delivery to ensure that all records can be decompressed in the same order they were compressed. Since TLS and lower-layer protocols provide reliable, sequenced record delivery, compression history information MAY be maintained and exploited when the LZS CompressionMethod is used.
有状态压缩需要可靠的链接和有序的记录传递，以确保所有记录都可以按压缩顺序进行解压缩。由于TLS和较低层协议提供可靠、有序的记录传递，因此在使用LZS压缩方法时，可以维护和利用压缩历史信息。
Furthermore, there MUST be a separate LZS compression history associated with each open TLS session. This not only provides enhanced security (no potential information leakage between sessions via a shared compression history), but also enables superior compression ratio (bit bandwidth on the connection) across all open TLS sessions with compression. A shared history would require resetting the compression (and decompression) history when switching between TLS sessions, and a single history implementation would require resetting the compression (and decompression) history between each record.
此外，必须有与每个开放TLS会话相关联的单独LZS压缩历史记录。这不仅提供了增强的安全性（通过共享的压缩历史记录，会话之间没有潜在的信息泄漏），而且还可以在所有开放的TLS会话中实现更高的压缩比（连接上的位带宽）。在TLS会话之间切换时，共享历史记录需要重置压缩（和解压缩）历史记录，而单个历史记录实现需要重置每个记录之间的压缩（和解压缩）历史记录。
The sender MUST reset the compression history prior to compressing the first TLS record of a TLS session after TLS handshake completes. It is advantageous for the sender to maintain the compression history for all subsequent records processed during the TLS session. This results in the greatest compression ratio for a given data set. In either case, this compression history MUST NOT be used for any other open TLS session, to ensure privacy between TLS sessions.
在TLS握手完成后压缩TLS会话的第一个TLS记录之前，发送方必须重置压缩历史记录。发送方维护TLS会话期间处理的所有后续记录的压缩历史记录是有利的。这将导致给定数据集的最大压缩比。在任何一种情况下，此压缩历史记录都不得用于任何其他打开的TLS会话，以确保TLS会话之间的隐私。
The sender MUST "flush" the compressor each time it transmits a compressed record. Flushing means that all data going into the compressor is included in the output, i.e., no data is retained in the hope of achieving better compression. Flushing ensures that each compressed record payload can be decompressed completely. Flushing is necessary to prevent a record's data from spilling over into a later record. This is important for synchronizing compressed data with the authenticated and encrypted data in a TLS record. Flushing is handled automatically in most LZS implementations.
发送方必须在每次传输压缩记录时“刷新”压缩机。冲洗意味着进入压缩机的所有数据都包含在输出中，即不保留任何数据，以期实现更好的压缩。刷新可确保每个压缩记录有效负载都可以完全解压缩。刷新是必要的，以防止记录的数据溢出到以后的记录中。这对于将压缩数据与TLS记录中经过身份验证和加密的数据同步非常重要。在大多数LZS实现中，刷新是自动处理的。
When the TLS session terminates, the implementation SHOULD dispose of the memory resources associated with the related TLS compression history. That is, the compression history SHOULD be handled as the TLS key material is handled.
当TLS会话终止时，实现应处置与相关TLS压缩历史相关联的内存资源。也就是说，压缩历史应在处理TLS关键材料时进行处理。
The LZS CompressionMethod also features "decompressing" uncompressed data in order to maintain the history if the "compressed" data actually expanded. The LZS CompressionMethod record format facilitates identifying whether records contain compressed or uncompressed data. The LZS decoding process accommodates decompressing either compressed or uncompressed data.
LZS CompressionMethod还具有“解压缩”未压缩数据的功能，以便在“压缩”数据实际扩展时维护历史记录。LZS CompressionMethod记录格式有助于识别记录包含压缩数据还是未压缩数据。LZS解码过程可以对压缩或未压缩的数据进行解压缩。
Prior to compression, the uncompressed data (TLSPlaintext.fragment) is composed of a plaintext TLS record. After compression, the compressed data (TLSCompressed.fragment) is composed of an 8-bit TLSComp header followed by the compressed (or uncompressed) data.
在压缩之前，未压缩的数据（TLSPlaintext.fragment）由纯文本TLS记录组成。压缩后，压缩数据（TLSCompressed.fragment）由8位TLSComp头和压缩（或未压缩）数据组成。
The one-octet header has the following structure:
一个八位字节头具有以下结构：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Flags |
| |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Flags |
| |
+-+-+-+-+-+-+-+-+
The format of the 8-bit Flags TLSComp field is as follows:
8位标志TLSComp字段的格式如下：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | Res | Res | Res | Res | Res | RST | C/U |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | Res | Res | Res | Res | Res | RST | C/U |
+-----+-----+-----+-----+-----+-----+-----+-----+
Res-Reserved
保留的
Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node.
保留供将来使用。必须设置为零。接收节点必须忽略。
RST-Reset Compression History
RST重置压缩历史记录
The RST bit is used to inform the decompressing peer that the compression history in this TLS session was reset prior to the data contained in this TLS record being compressed. When the RST bit is set to "1", a compression history reset is performed; when RST is set to "0", a compression history reset is not performed.
RST位用于通知解压缩对等方，在压缩此TLS记录中包含的数据之前，已重置此TLS会话中的压缩历史记录。当RST位设置为“1”时，执行压缩历史重置；当RST设置为“0”时，不执行压缩历史重置。
This bit MUST be set to a value of "1" for the first compressed TLS transmitted record of a TLS session. This bit may also be used by the transmitter for other exception cases when the compression history must be reset.
对于TLS会话的第一个压缩TLS传输记录，必须将该位设置为值“1”。当必须重置压缩历史记录时，变送器也可将该位用于其他异常情况。
C/U-Compressed/Uncompressed Bit
C/U压缩/未压缩位
The C/U indicates whether the data field contains compressed or uncompressed data. A value of 1 indicates compressed data (often referred to as a compressed record), and a value of 0 indicates uncompressed data (or an uncompressed record).
C/U指示数据字段是包含压缩数据还是未压缩数据。值1表示压缩数据（通常称为压缩记录），值0表示未压缩数据（或未压缩记录）。
The LZS compression method, encoding format, and application examples are described in RFC 1967 [6], RFC 1974 [5], and RFC 2395 [4].
RFC 1967[6]、RFC 1974[5]和RFC 2395[4]中描述了LZS压缩方法、编码格式和应用示例。
Some implementations of LZS allow the sending compressor to select from among several options to provide varying compression ratios, processing speeds, and memory requirements. Other implementations of LZS provide optimal compression ratio at byte-per-clock speeds.
LZ的一些实现允许发送压缩器从几个选项中进行选择，以提供不同的压缩比、处理速度和内存需求。LZ的其他实现以字节/时钟速度提供最佳压缩比。
The receiving LZS decompressor automatically adjusts to the settings selected by the sender. Also, receiving LZS decompressors will update the decompression history with uncompressed data. This facilitates never obtaining less than a 1:1 compression ratio in the session and never transmitting with expanded data.
接收LZS解压器自动调整到发送方选择的设置。此外，接收LZS解压器将使用未压缩的数据更新解压历史记录。这有助于在会话中从不获得小于1:1的压缩比，并且从不使用扩展数据进行传输。
The input to the payload compression algorithm is TLSPlaintext data destined to an active TLS session with compression negotiated. The output of the algorithm is a new (and hopefully smaller) TLSCompressed record. The output payload contains the input payload's data in either compressed or uncompressed format. The input and output payloads are each an integral number of bytes in length.
有效负载压缩算法的输入是发送到活动TLS会话并协商压缩的TLSPlaintext数据。算法的输出是一个新的（希望更小）TLS压缩记录。输出有效负载包含压缩或未压缩格式的输入有效负载数据。输入和输出有效负载的长度均为整数字节。
The output payload is always prepended with the TLSComp header. If the uncompressed form is used, the output payload is identical to the input payload, and the TLSComp header reflects uncompressed data.
输出有效负载始终在TLSComp头的前面。如果使用未压缩表单，则输出有效负载与输入有效负载相同，并且TLSComp头反映未压缩的数据。
If the compressed form is used, encoded as defined in ANSI X3.241 [7], and the TLSComp header reflects compressed data. The LZS encoded format is repeated here for informational purposes ONLY.
如果使用压缩格式，按照ANSI X3.241[7]中的定义进行编码，并且TLSComp标头反映压缩数据。此处重复LZS编码格式仅供参考。
<Compressed Stream> := [<Compressed String>*] <End Marker>
<Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<Compressed Stream> := [<Compressed String>*] <End Marker>
<Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<b> := 1 | 0
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<b> := 1 | 0
<Length> := 00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13 ...
<Length>：=00=2 1111 0110=14 01=3 1111 0111=15 10=4 1111 1000=16 1100=5 1111 1001=17 1101=6 1111 1010=18 1110=7 1111 1011=19 1111 0000=8 1111 1100=20 1111 0001=9 1111 1101=21 1111 0010=10 1111 1111 1110=22 1111 0011=11 1111 1111 1111 0000=23 1111 0100=12 1111 1111 0001=24 1111 0101=13。。。
A datagram payload compressed with LZS always ends with the last compressed data byte (also known as the <end marker>), which is used to disambiguate padding. This allows trailing bits, as well as bytes, to be considered padding.
使用LZS压缩的数据报有效负载始终以最后一个压缩数据字节（也称为<end marker>）结束，该字节用于消除填充歧义。这允许将尾随位以及字节视为填充。
The size of a compressed payload MUST be in whole octet units.
压缩有效负载的大小必须以整个八位字节为单位。
All TLS records processed with a TLS session state that includes LZS compression are processed as follows. The reliable and efficient transport of LZS compressed records in the TLS session depends on the following processes.
使用包含LZS压缩的TLS会话状态处理的所有TLS记录的处理如下。TLS会话中LZS压缩记录的可靠和高效传输取决于以下过程。
The compression operation results in either compressed or uncompressed data. When a TLS record is received, it is assigned to a particular TLS context that includes the LZS compression history buffer. It is processed according to ANSI X3.241-1994 to form compressed data or used as is to form uncompressed data. For the first record of the session, or for exception conditions, the compression history MUST be cleared. In performing the compression operation, the compression history MUST be updated when either a compressed record or an uncompressed record is produced. Uncompressed TLS records MAY be sent at any time. Uncompressed TLS records MUST be sent if compression causes enough expansion to make the data compression TLS record size exceed the MTU defined in section 6.2.2 in RFC 2246. The output of the compression operation is placed in the fragment field of the TLSCompressed structure (TLSCompressed.fragment).
压缩操作产生压缩或未压缩的数据。当接收到TLS记录时，会将其分配给包含LZS压缩历史缓冲区的特定TLS上下文。根据ANSI X3.241-1994对其进行处理以形成压缩数据或按原样使用以形成未压缩数据。对于会话的第一条记录或异常情况，必须清除压缩历史记录。在执行压缩操作时，必须在生成压缩记录或未压缩记录时更新压缩历史记录。可以随时发送未压缩的TLS记录。如果压缩导致足够的扩展，使数据压缩TLS记录大小超过RFC 2246第6.2.2节中定义的MTU，则必须发送未压缩的TLS记录。压缩操作的输出放在TLSCompressed结构（TLSCompressed.fragment）的fragment字段中。
The TLSComp header byte is located just prior to the first byte of the compressed TLS record in TLSCompressed.fragment. The C/U bit in the TLSComp header is set according to whether the data field contains compressed or uncompressed data. The RST bit in the TLSComp header is set to "1" if the compression history was reset prior to compressing the TLSplaintext.fragment that is composed of a TLSCompressed.fragment. Uncompressed data MUST be transmitted (and the C/U bit set to 0) if the "compressed" (expanded) data exceeded 17K bytes.
TLSComp头字节位于TLSCompressed.fragment中压缩TLS记录的第一个字节之前。TLSComp标头中的C/U位根据数据字段包含压缩数据还是未压缩数据进行设置。如果在压缩由TLSCompressed.fragment组成的TLSplaintext.fragment之前重置了压缩历史记录，则TLSComp标头中的RST位设置为“1”。如果“压缩”（扩展）数据超过17K字节，则必须传输未压缩数据（C/U位设置为0）。
Prior to decompressing the first compressed TLS record in the TLS session, the receiver MUST reset the decompression history. Subsequent records are decompressed in the order received. The receiver decompresses the Payload Data field according to the encoding specified in section 3.5 above.
在TLS会话中解压缩第一个压缩的TLS记录之前，接收器必须重置解压缩历史记录。随后的记录按收到的顺序解压缩。接收器根据上文第3.5节中规定的编码对有效载荷数据字段进行解压缩。
If the received datagram is not compressed, the receiver does not need to perform decompression processing, and the Payload Data field of the datagram is ready for processing by the next protocol layer.
如果接收到的数据报未被压缩，则接收器不需要执行解压缩处理，并且数据报的有效载荷数据字段准备好由下一协议层进行处理。
After a TLS record is received from the peer and decrypted, the RST and C/U bits MUST be checked.
从对等方接收TLS记录并解密后，必须检查RST和C/U位。
If the C/U bit is set to "1", the resulting compressed data block MUST be decompressed according to section 3.5 above.
如果C/U位设置为“1”，则必须根据上述第3.5节对产生的压缩数据块进行解压缩。
If the C/U bit is set to "0", the specified decompression history MUST be updated with the received uncompressed data.
如果C/U位设置为“0”，则必须使用接收到的未压缩数据更新指定的解压缩历史记录。
If the RST bit is set to "1", the receiving decompression history MAY be reset to an initial state prior to decompressing the TLS record. (However, due to the characteristics of the Hifn LZS algorithm, a decompression history reset is not required). After reset, any compressed or uncompressed data contained in the record is processed.
如果RST位设置为“1”，则接收解压历史可重置为解压TLS记录之前的初始状态。（但是，由于Hifn LZS算法的特点，不需要重置解压缩历史记录）。重置后，将处理记录中包含的任何压缩或未压缩数据。
During compression, there are two workable options for handling records that expand:
在压缩过程中，有两个可行的选项用于处理扩展的记录：
1) Send the expanded data (as long as TLSCompressed.length is 17K or less) and maintain the history, thus allowing loss of current bandwidth but preserving future bandwidth on the link.
1) 发送扩展数据（只要TLSCompressed.length为17K或更小），并维护历史记录，从而允许丢失当前带宽，但保留链路上的未来带宽。
2) Send the uncompressed data and do not clear the compression history; the decompressor will update its history, thus conserving the current bandwidth and future bandwidth on the link.
2) 发送未压缩数据，不清除压缩历史记录；解压器将更新其历史记录，从而保存链路上的当前带宽和未来带宽。
The second option is the preferred option and SHOULD be implemented.
第二个选项是首选选项，应予以实施。
There is a third option:
还有第三种选择：
3) Send the uncompressed data and clear the history, thus conserving current bandwidth but allowing possible loss of future bandwidth on the link.
3) 发送未压缩的数据并清除历史记录，从而节省当前带宽，但允许将来链路上的带宽可能丢失。
This option SHOULD NOT be implemented.
不应实施此选项。
The compression method identifiers specified in this document are machine-readable numbers. As such, issues of human internationalization and localization are not introduced.
本文档中指定的压缩方法标识符是机器可读的数字。因此，没有引入人的国际化和本地化问题。
Section 2 of RFC 3749 [3] describes a registry of compression method identifiers to be maintained by the IANA and to be assigned within three zones.
RFC 3749[3]第2节描述了IANA维护的压缩方法标识符注册表，并在三个区域内分配。
IANA has assigned an identifier for the LZS compression method from the RFC 2434 Specification Required IANA pool, as described in sections 2 and 5 of RFC 3749 [3].
IANA已从RFC 2434规范要求的IANA池中为LZS压缩方法分配了标识符，如RFC 3749[3]第2节和第5节所述。
The IANA-assigned compression method identifier for LZS is 64 decimal (0x40).
IANA为LZ分配的压缩方法标识符为64位小数（0x40）。
This document does not introduce any topics that alter the threat model addressed by TLS. The security considerations described throughout RFC 2246 [2] apply here as well.
本文件不介绍任何改变TLS所述威胁模型的主题。RFC 2246[2]中描述的安全注意事项也适用于此处。
However, combining compression with encryption can sometimes reveal information that would not have been revealed without compression. Data that is the same length before compression might be a different length after compression, so adversaries that observe the length of the compressed data might be able to derive information about the corresponding uncompressed data. Some symmetric encryption ciphersuites do not hide the length of symmetrically encrypted data at all. Others hide it to some extent but not fully. For example, ciphersuites that use stream cipher encryption without padding do not hide length at all; ciphersuites that use Cipher Block Chaining (CBC) encryption with padding provide some length hiding, depending on how the amount of padding is chosen. Use of TLS compression SHOULD take into account that the length of compressed data may leak more information than the length of the original uncompressed data.
然而，将压缩与加密相结合有时会泄露没有压缩就无法泄露的信息。压缩前长度相同的数据在压缩后可能长度不同，因此观察压缩数据长度的对手可能能够获得有关相应未压缩数据的信息。某些对称加密密码套件根本不隐藏对称加密数据的长度。其他人在某种程度上隐瞒了这一点，但没有完全隐瞒。例如，使用无填充的流密码加密的密码套件根本不隐藏长度；使用带填充的密码块链接（CBC）加密的密码套件提供了一些长度隐藏，具体取决于填充量的选择方式。使用TLS压缩时应考虑到压缩数据的长度可能比原始未压缩数据的长度泄漏更多的信息。
Another security issue to be aware of is that the LZS compression history contains plaintext. In order to prevent any kind of information leakage outside the system, when a TLS session with compression terminates, the implementation SHOULD treat the compression history as it does plaintext -- that is, care should be taken not to reveal the compression history in any form or to use it again. This is described in sections 2.2 and 3.2 above.
另一个需要注意的安全问题是LZS压缩历史记录包含纯文本。为了防止任何类型的信息泄漏到系统之外，当压缩的TLS会话终止时，实现应该像对待明文一样对待压缩历史——也就是说，应该注意不要以任何形式显示压缩历史或再次使用压缩历史。上述第2.2节和第3.2节对此进行了说明。
This information leakage concept can be extended to the situation of sharing a single compression history across more than one TLS session, as addressed in section 2.2 above.
如上文第2.2节所述，此信息泄漏概念可以扩展到跨多个TLS会话共享单个压缩历史的情况。
Other security issues are discussed in RFC 3749 [3].
RFC 3749[3]中讨论了其他安全问题。
The concepts described in this document were derived from RFC 1967 [6], RFC 1974 [5], RFC 2395 [4], and RFC 3749 [3]. The author acknowledges the contributions of Scott Hollenbeck, Douglas Whiting, and Russell Dietz, and help from Steve Bellovin, Russ Housley, and Eric Rescorla.
本文件中描述的概念源自RFC 1967[6]、RFC 1974[5]、RFC 2395[4]和RFC 3749[3]。作者感谢Scott Hollenbeck、Douglas Whiting和Russell Dietz的贡献，以及Steve Bellovin、Russ Housley和Eric Rescorla的帮助。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Hollenbeck, S. "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[3] Hollenbeck，S.“传输层安全协议压缩方法”，RFC 3749，2004年5月。
[4] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[4] Friend，R.和R.Monsour，“使用LZS的IP有效载荷压缩”，RFC 2395，1998年12月。
[5] Friend, R. and W. Simpson, "PPP Stac LZS Compression Protocol", RFC 1974, August 1996.
[5] Friend，R.和W.Simpson，“PPP Stac LZS压缩协议”，RFC 1974，1996年8月。
[6] Schneider, K. and R. Friend, "PPP LZS-DCP Compression Protocol (LZS-DCP)", RFC 1967, August 1996.
[6] Schneider，K.和R.Friend，“PPP LZS-DCP压缩协议（LZS-DCP）”，RFC 1967，1996年8月。
[7] American National Standards Institute, Inc., "Data Compression Method for Information Systems," ANSI X3.241-1994, August 1994.
[7] 美国国家标准协会，“信息系统的数据压缩方法”，ANSI X3.241-1994，1994年8月。
[8] Lempel, A. and J. Ziv, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, September 1977.
[8] Lempel，A.和J.Ziv，“顺序数据压缩的通用算法”，IEEE信息论学报，第IT-23卷，第3期，1977年9月。
Author's Address
作者地址
Robert Friend Hifn 5973 Avenida Encinas Carlsbad, CA 92008 US
Robert Friend Hifn 5973美国加利福尼亚州卡尔斯巴德大道，邮编92008
EMail: rfriend@hifn.com
EMail: rfriend@hifn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。