RFC1144 日本語訳
1144 Compressing TCP/IP Headers for Low-Speed Serial Links. V.Jacobson. February 1990. (Format: TXT=120959, PS=534729, PDF=255616 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Jacobson/1/
Request for Comments: 1144 LBL
February 1990
Jacobson/1/がコメントのために要求するワーキンググループV.をネットワークでつないでください: 1144 LBL1990年2月
Compressing TCP/IP Headers
TCP/IPヘッダーを圧縮します。
for Low-Speed Serial Links
低速連続のリンクに
Status of this Memo
このMemoの状態
This RFC is a proposed elective protocol for the Internet community and requests discussion and suggestions for improvement. It describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティ、要求議論、および改善提案のための提案された選挙のプロトコルです。 それは低速シリーズリンクの上の性能を向上させるためにTCP/IPデータグラムのヘッダーを圧縮するための方法を説明します。 方法の動機、実現、および性能は説明されます。 参照のためにサンプル実現のためのCコードを与えます。 このメモの分配は無制限です。
NOTE: Both ASCII and Postscript versions of this document are available.
The ASCII version, obviously, lacks all the figures and all the
information encoded in typographic variation (italics, boldface,
etc.). Since this information was, in the author's opinion, an
essential part of the document, the ASCII version is at best
incomplete and at worst misleading. Anyone who plans to work
with this protocol is strongly encouraged obtain the Postscript
version of this RFC.
以下に注意してください。 ASCIIとこのドキュメントの補遣版の両方が利用可能です。 ASCII版は明らかに印刷の変化(イタリック、肉太活字など)でコード化されたすべての数字とすべての情報を欠いています。 この情報が作者の意見で、ドキュメントの不可欠の部分であったので、ASCII版は、せいぜい不完全であって、最悪の場合は紛らわしいです。 このプロトコルで働くのを計画しているだれでも強く奨励されます。このRFCの補遣版を得てください。
----------------------------
1. This work was supported in part by the U.S. Department of Energy
under Contract Number DE-AC03-76SF00098.
---------------------------- 1. この仕事はContract Number DE-AC03-76SF00098の下の米国エネルギー省によって一部支持されました。
Contents
コンテンツ
1 Introduction 1
1 序論1
2 The problem 1
2 問題1
3 The compression algorithm 4
3 圧縮アルゴリズム4
3.1 The basic idea . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 基本的な考え方. . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 The ugly details . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 醜い詳細. . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Compressed packet format. . . . . . . . . . . . . . . . . 7
3.2.2 圧縮されたパケット・フォーマット。 . . . . . . . . . . . . . . . . 7
3.2.3 Compressor processing . . . . . . . . . . . . . . . . . . 8
3.2.3 コンプレッサー処理. . . . . . . . . . . . . . . . . . 8
3.2.4 Decompressor processing . . . . . . . . . . . . . . . . . 12
3.2.4 減圧装置処理. . . . . . . . . . . . . . . . . 12
4 Error handling 14
4 エラー処理14
4.1 Error detection . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 誤り検出. . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Error recovery . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 エラー回復. . . . . . . . . . . . . . . . . . . . . . . . 17
5 Configurable parameters and tuning 18
5 構成可能なパラメタと調律18
5.1 Compression configuration . . . . . . . . . . . . . . . . . . 18
5.1 圧縮構成. . . . . . . . . . . . . . . . . . 18
5.2 Choosing a maximum transmission unit . . . . . . . . . . . . . 20
5.2 マキシマム・トランスミッション・ユニット. . . . . . . . . . . . . 20を選ぶこと。
5.3 Interaction with data compression . . . . . . . . . . . . . . 21
5.3 データ圧縮. . . . . . . . . . . . . . 21との相互作用
6 Performance measurements 23
6 パフォーマンス測定23
7 Acknowlegements 25
7 Acknowlegements25
A Sample Implementation 27
サンプル実現27
A.1 Definitions and State Data . . . . . . . . . . . . . . . . . . 28
A.1定義と州のデータ. . . . . . . . . . . . . . . . . . 28
A.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2圧縮. . . . . . . . . . . . . . . . . . . . . . . . . 31
i
i
A.3 Decompression . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3減圧. . . . . . . . . . . . . . . . . . . . . . . . 37
A.4 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 41
A.4初期設定. . . . . . . . . . . . . . . . . . . . . . . . 41
A.5 Berkeley Unix dependencies . . . . . . . . . . . . . . . . . . 41
A.5バークレーUnix依存. . . . . . . . . . . . . . . . . . 41
B Compatibility with past mistakes 43
過去の誤り43とのBの互換性
B.1 Living without a framing `type' byte . . . . . . . . . . . . . 43
縁どりなしで生きるB.1がバイト. . . . . . . . . . . . . 43を'タイプします'。
B.2 Backwards compatible SLIP servers . . . . . . . . . . . . . . 43
B.2の遅れているコンパチブルSLIPサーバ. . . . . . . . . . . . . . 43
C More aggressive compression 45
Cで、より攻撃的な圧縮45
D Security Considerations 46
Dセキュリティ問題46
E Author's address 46
E作者のアドレス46
ii
RFC 1144 Compressing TCP/IP Headers February 1990
ii RFC1144Compressing TCP/IP Headers1990年2月
1 Introduction
1つの序論
As increasingly powerful computers find their way into people's homes, there is growing interest in extending Internet connectivity to those computers. Unfortunately, this extension exposes some complex problems in link-level framing, address assignment, routing, authentication and performance. As of this writing there is active work in all these areas. This memo describes a method that has been used to improve TCP/IP performance over low speed (300 to 19,200 bps) serial links.
ますます強力なコンピュータが人々の家に届くとき、インターネットの接続性をそれらのコンピュータに広げることへの増加している関心があります。 残念ながら、この拡大はリンク・レベル縁どり、アドレス課題、ルーティング、認証、および性能におけるいくつかの複雑な問題を露出します。 この書くこと現在、活発な仕事がこれらのすべての領域にあります。 このメモは低速(300〜1万9200ビーピーエス)の連続のリンクの上のTCP/IP性能を向上させるのに使用された方法を説明します。
The compression proposed here is similar in spirit to the Thinwire-II protocol described in [5]. However, this protocol compresses more effectively (the average compressed header is 3 bytes compared to 13 in Thinwire-II) and is both efficient and simple to implement (the Unix implementation is 250 lines of C and requires, on the average, 90us (170 instructions) for a 20MHz MC68020 to compress or decompress a packet).
ここで提案された圧縮は精神において[5]で説明されたThinwire-IIプロトコルと同様です。 しかしながら、このプロトコルは、道具により効果的(Thinwire-IIで13と比べて、普通の圧縮されたヘッダーは3バイトである)に圧縮して、かつ効率的であって、かつ簡単です(Unix実現は、Cの250の線であり、20MHzのMC68020がパケットを圧縮するか、または減圧するように、平均して、90us(170の指示)を必要とします)。
This compression is specific to TCP/IP datagrams./2/ The author investigated compressing UDP/IP datagrams but found that they were too infrequent to be worth the bother and either there was insufficient datagram-to-datagram coherence for good compression (e.g., name server queries) or the higher level protocol headers overwhelmed the cost of the UDP/IP header (e.g., Sun's RPC/NFS). Separately compressing the IP and the TCP portions of the datagram was also investigated but rejected since it increased the average compressed header size by 50% and doubled the compression and decompression code size.
この圧縮はTCP/IPデータグラムに特定です。作者の/2/は、UDP/IPデータグラムを圧縮しながら調査しましたが、面倒の価値があるようにそれらが珍し過ぎるのがわかりました、そして、良い圧縮(例えば、ネームサーバ質問)のためのデータグラムからデータグラムへの不十分な一貫性があったか、または、より高い平らなプロトコルヘッダーはUDP/IPヘッダー(例えば、SunのRPC/NFS)の費用を圧倒しました。 平均した圧縮されたヘッダーサイズを50%増加させて、圧縮と減圧コードサイズを倍にしたので、別々にデータグラムのIPとTCP部分を圧縮するのは、また、調査されましたが、拒絶されました。
2 The problem
2 問題
Internet services one might wish to access over a serial IP link from home range from interactive `terminal' type connections (e.g., telnet, rlogin, xterm) to bulk data transfer (e.g., ftp, smtp, nntp). Header compression is motivated by the need for good interactive response. I.e., the line efficiency of a protocol is the ratio of the data to header+data in a datagram. If efficient bulk data transfer is the only objective, it is always possible to make the datagram large enough to approach an efficiency of 100%.
人が連続のIPの上でアクセスしたがっているかもしれないインターネットのサービスはホームレンジから対話的な'端末'のタイプ接続(例えば、telnet、rlogin、xterm)からバルク・データ転送(例えば、ftp、smtp、nntp)までリンクされます。 ヘッダー圧縮は良い対話的な応答の必要性によって動機づけられています。 すなわち、プロトコルの線効率はデータ対データグラムのヘッダー+データの比率です。 効率的なバルク・データ転送が唯一の目的であるなら、データグラムを100%の効率にアプローチできるくらい大きくするのはいつも可能です。
Human-factors studies[15] have found that interactive response is perceived as `bad' when low-level feedback (character echo) takes longer
人間の要素研究[15]によって、低レベルであるフィードバック(キャラクタエコー)に時間がかかると対話的な応答が'悪い'として知覚されるのがわかりました。
----------------------------
2. The tie to TCP is deeper than might be obvious. In addition to the
compression `knowing' the format of TCP and IP headers, certain features
of TCP have been used to simplify the compression protocol. In
particular, TCP's reliable delivery and the byte-stream conversation
model have been used to eliminate the need for any kind of error
correction dialog in the protocol (see sec. 4).
---------------------------- 2. TCPへの繋がりは明白であるかもしれないというよりも深いです。 圧縮に加えて、TCPとIPヘッダーの形式を'知ってい'て、TCPのある特徴は、圧縮プロトコルを簡素化するのに使用されました。 特に、TCPの信頼できる配信とバイト・ストリーム会話モデルは、プロトコルでのどんな種類のエラー修正対話の必要性も排除するのに使用されました。(秒に遭遇してください。 4).
Jacobson [Page 1] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[1ページ]RFC1144
than 100 to 200 ms. Protocol headers interact with this threshold three ways:
100〜200個の原稿プロトコルヘッダーをこの敷居で3つの方法で相互作用させるより:
(1) If the line is too slow, it may be impossible to fit both the
headers and data into a 200 ms window: One typed character results
in a 41 byte TCP/IP packet being sent and a 41 byte echo being
received. The line speed must be at least 4000 bps to handle these
82 bytes in 200 ms.
(1) 線が遅過ぎるなら、200msウィンドウにヘッダーとデータの両方に合うのは不可能であるかもしれません: 1つは送られる41バイトのTCP/IPパケットと受け取られる41バイトのエコーにキャラクタ結果をタイプしました。 ライン・スピードは、200原稿のこれらの82バイトを扱うためには少なくとも4000ビーピーエスでなければなりません。
(2) Even with a line fast enough to handle packetized typing echo (4800
bps or above), there may be an undesirable interaction between bulk
data and interactive traffic: For reasonable line efficiency the
bulk data packet size needs to be 10 to 20 times the header size.
I.e., the line maximum transmission unit or MTU should be 500 to
1000 bytes for 40 byte TCP/IP headers. Even with type-of-service
queuing to give priority to interactive traffic, a telnet packet has
to wait for any in-progress bulk data packet to finish. Assuming
data transfer in only one direction, that wait averages half the MTU
or 500 ms for a 1024 byte MTU at 9600 bps.
(2) 大量のデータと対話的な通信の間には、エコーをタイプしながら扱うことができるくらい速くpacketizedされた線(4800年のより多くのビーピーエス)があっても望ましくない相互作用があるかもしれません: 妥当な線効率のために、大量のデータ・パケットサイズは、ヘッダーサイズの10〜20倍である必要があります。 すなわち、線のマキシマム・トランスミッション・ユニットかMTUが40バイトのTCP/IPヘッダーのための500〜1000バイトであるべきです。 サービスのタイプさえ対話的な通信を最優先させるために列を作っていて、telnetパケットは、どんな進行中の大量のデータ・パケットも終わるのを待たなければなりません。 一方向だけにデータ転送を仮定して、その待ちは1024年のバイトのMTUのために9600年のビーピーエスでMTUの半分か500msを平均します。
(3) Any communication medium has a maximum signalling rate, the Shannon
limit. Based on an AT&T study[2], the Shannon limit for a typical
dialup phone line is around 22,000 bps. Since a full duplex, 9600
bps modem already runs at 80% of the limit, modem manufacturers are
starting to offer asymmetric allocation schemes to increase
effective bandwidth: Since a line rarely has equivalent amounts of
data flowing both directions simultaneously, it is possible to give
one end of the line more than 11,000 bps by either time-division
multiplexing a half-duplex line (e.g., the Telebit Trailblazer) or
offering a low-speed `reverse channel' (e.g., the USR Courier
HST)./3/ In either case, the modem dynamically tries to guess which
end of the conversation needs high bandwidth by assuming one end of
the conversation is a human (i.e., demand is limited to <300 bps by
typing speed). The factor-of-forty bandwidth multiplication due to
protocol headers will fool this allocation heuristic and cause these
modems to `thrash'.
(3) どんなコミュニケーション媒体にも、最大の合図レート、シャノン限界があります。 基づいて、2万2000の周りにAT&Tの研究[2]、典型的なダイアルアップ電話回線のためのシャノン限界には、ビーピーエスがあります。 9600年のビーピーエスモデムは、限界の80%で全二重以来モデムメーカーが有効な帯域幅を増加させるように非対称の配分体系を提供し始めていると既に述べます: 線にはデータ流動の同等な量がめったにないので、同時にそれが可能である両方の方向は、半二重回線(例えば、テレビットTrailblazer)をどちらかの時分割多重化による線より多くの11,000ビーピーエスの片端に与えるか、または低速'逆のチャンネル'(例えば、USR Courier HST)を提供に与えます; どちらかの場合における/3/、モデムは会話の片端が人間(すなわち、要求は速度をタイプすることによって、<300ビーピーエスに制限される)であると仮定することによって会話のどの終わりが高帯域を必要とするかをダイナミックに推測しようとします。 プロトコルヘッダーによる40の要素帯域幅乗法は、この配分ヒューリスティックを馬鹿に望んでいて、'打たせる'これらのモデムを原因に望んでいます。
From the above, it's clear that one design goal of the compression should be to limit the bandwidth demand of typing and ack traffic to at most 300 bps. A typical maximum typing speed is around five characters
上記では、高々300ビーピーエスへのタイプとack交通の帯域幅要求を圧縮の1つのデザイン目標がことである制限するのは明確です。 速度をタイプする典型的な最大はおよそ5つのキャラクタです。
----------------------------
3. See the excellent discussion of two-wire dialup line capacity in
[1], chap. 11. In particular, there is widespread misunderstanding of
the capabilities of `echo-cancelling' modems (such as those conforming
to CCITT V.32): Echo-cancellation can offer each side of a two-wire
line the full line bandwidth but, since the far talker's signal adds to
the local `noise', not the full line capacity. The 22Kbps Shannon limit
is a hard-limit on data rate through a two-wire telephone connection.
---------------------------- 3. やつは[1]での2線式のダイヤルアップ回線容量の素晴らしい議論を見てください。 11. 特に、'エコー取り消し'モデム(CCITT V.32に従うものなどの)の能力の広範囲の誤解があります: 2線式の線の各端に実線帯域幅を提供しますが、エコーキャンセルは遠い話し手の信号が地方の'雑音'に加えて以来のいずれの実線にも容量は提供できません。 22Kbpsシャノン限界は2線式の電話接続によるデータ信号速度における困難な限界です。
Jacobson [Page 2] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[2ページ]RFC1144
per second/4/ which leaves a budget 30 - 5 = 25 characters for headers or five bytes of header per character typed./5/ Five byte headers solve problems (1) and (3) directly and, indirectly, problem (2): A packet size of 100--200 bytes will easily amortize the cost of a five byte header and offer a user 95--98% of the line bandwidth for data. These short packets mean little interference between interactive and bulk data traffic (see sec. 5.2).
5 = 25に予算を30に残すsecond/4/に従って、1キャラクタあたりのヘッダーのヘッダーか5バイトキャラクタはタイプしました。/5/の5バイトのヘッダーが直接問題(1)と(3)を解決する、間接的に問題(2)、: 100--200バイトのパケットサイズは、容易に5バイトのヘッダーの費用を清算して、データのために線帯域幅のユーザ95--98%を提供するでしょう。 これらの脆いパケットはほとんど対話的で大量のデータ通信量の間の干渉を意味しません。(秒に遭遇してください。 5.2).
Another design goal is that the compression protocol be based solely on information guaranteed to be known to both ends of a single serial link. Consider the topology shown in fig. 1 where communicating hosts A and B are on separate local area nets (the heavy black lines) and the nets are connected by two serial links (the open lines between gateways C--D and E--F)./6/ One compression possibility would be to convert each TCP/IP conversation into a semantically equivalent conversation in a protocol with smaller headers, e.g., to an X.25 call. But, because of routing transients or multipathing, it's entirely possible that some of the A--B traffic will follow the A-C-D-B path and some will follow the A-E-F-B path. Similarly, it's possible that A->B traffic will flow A-C-D-B and B->A traffic will flow B-F-E-A. None of the gateways can count on seeing all the packets in a particular TCP conversation and a compression algorithm that works for such a topology cannot be tied to the TCP connection syntax.
別のデザイン目標は単一の連続のリンクの両端に知られているために保証されて、圧縮プロトコルが唯一情報に基づいているということです。 交信しているホストAとBが別々の局部ネット(黒い太線)にいて、ネットが2個の連続のリンク(ゲートウェイCの間の開いている線--DとE--F)/6/によって接続される図1に1つの圧縮の可能性がそうであることが示されたトポロジーが、より小さいヘッダーと共にプロトコルにおける意味的に同等な会話にそれぞれのTCP/IPの会話を変換すると考えてください、例えば、X.25呼び出しに。 しかし、ルーティング過渡現象かmultipathingのために、A--Bの或るものが取引するのがA C D-B経路に続いて、或るものがA電子FのB経路に続くのは、完全に可能です。 同様に、それは交通がD-BであるそのA>Bの可能な流れA C D-Bであり、交通がそうするB>A流動はB F電子Aです。 ゲートウェイのどれかは、特定のTCPの会話ですべてのパケットを見るのを頼りにすることができません、そして、そのようなトポロジーに利く圧縮アルゴリズムはTCP接続構文に結ぶことができません。
A physical link treated as two, independent, simplex links (one each direction) imposes the minimum requirements on topology, routing and pipelining. The ends of each simplex link only have to agree on the most recent packet(s) sent on that link. Thus, although any compression scheme involves shared state, this state is spatially and temporally
物理的なリンクは2を扱いました、独立しています、シンプレクスリンク、(1つ、各指示) トポロジー、ルーティング、およびパイプライン処理に必要最小限を課します。 それぞれのシンプレクスリンクの端だけがリンクされる転送された最新のパケットに同意しなければなりません。 したがって、どんな圧縮技術も共有された状態にかかわりますが、この状態は空間的に時間的にかかわります。
----------------------------
4. See [13]. Typing bursts or multiple character keystrokes such as
cursor keys can exceed this average rate by factors of two to four.
However the bandwidth demand stays approximately constant since the TCP
Nagle algorithm[8] aggregates traffic with a <200ms interarrival time
and the improved header-to-data ratio compensates for the increased
data.
5. A similar analysis leads to essentially the same header size limit
for bulk data transfer ack packets. Assuming that the MTU has been
selected for `unobtrusive' background file transfers (i.e., chosen so
the packet time is 200--400 ms --- see sec. 5), there can be at most 5
data packets per second in the `high bandwidth' direction. A reasonable
TCP implementation will ack at most every other data packet so at 5
bytes per ack the reverse channel bandwidth is 2.5 * 5 = 12.5 bytes/sec.
6. Note that although the TCP endpoints are A and B, in this example
compression/decompression must be done at the gateway serial links,
i.e., between C and D and between E and F. Since A and B are using IP,
they cannot know that their communication path includes a low speed
serial link. It is clearly a requirement that compression not break the
IP model, i.e., that compression function between intermediate systems
and not just between end systems.
---------------------------- 4. [13]を見てください。 カーソルキーなどの炸裂か複数のキャラクタキーストロークをタイプすると、この平均相場に2〜4の要素を上回ることができます。 しかしながら、TCPネーグルアルゴリズム[8]が<200ms interarrival時間で交通に集められるので、帯域幅要求はほとんど一定の状態で残っています、そして、ヘッダーからデータへの改良された比は増加するデータを補います。 5. 同様の分析はバルク・データ転送ackパケットのための本質的には同じヘッダーサイズ限界につながります。 MTUが'控え目な'バックグラウンドファイル転送のために選択されたと仮定します。(すなわち、選ばれて、したがって、パケット時間は200--400msです。--- 秒に遭遇してください。 5), '高帯域'方向には1秒あたり5つのデータ・パケットが高々あることができます。 合理的なTCP実現が他のあらゆるデータ・パケットを高々ackするので、1ackあたり5バイトでは、逆のチャンネル帯域幅は2.5*5 = 12.5バイト/秒です。 6. TCP終点がAであり、この例の圧縮/減圧におけるBがゲートウェイですなわち、CとDとの連続のリンクをして、EとF.Since AとBの間でIPを使用しなければなりませんが、それらの通信路が低速シリーズリンクを含んでいるのを知ることができないことに注意してください。 それは圧縮がIPモデルを壊さないという明確に要件、すなわち、エンドシステムだけではなく、中間システムの間のその圧縮機能です。
Jacobson [Page 3] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[3ページ]RFC1144
local and adheres to Dave Clark's principle of fate sharing[4]: The two ends can only disagree on the state if the link connecting them is inoperable, in which case the disagreement doesn't matter.
地方、デーブ・クラークの運命共有[4]の主義を以下を固守します。 それらを接続するリンクが手術不能である場合にだけ、2つの終わりが状態について意見が異なることができます、その場合、不一致は重要ではありません。
3 The compression algorithm
3 圧縮アルゴリズム
3.1 The basic idea
3.1 基本的な考え方
Figure 2 shows a typical (and minimum length) TCP/IP datagram header./7/ The header size is 40 bytes: 20 bytes of IP and 20 of TCP. Unfortunately, since the TCP and IP protocols were not designed by a committee, all these header fields serve some useful purpose and it's not possible to simply omit some in the name of efficiency.
図2は、ヘッダーサイズが40バイトであることをa典型的な(そして、最小の長さ)TCP/IPデータグラムヘッダー/7/に示します: IPの20バイトと20TCP。 残念ながら、TCPとIPプロトコルが委員会によって設計されなかったので、これらのすべてのヘッダーフィールドが何らかの役に立つ目的に役立ちます、そして、効率の名にかけて単にいくつかを省略するのは可能ではありません。
However, TCP establishes connections and, typically, tens or hundreds of packets are exchanged on each connection. How much of the per-packet information is likely to stay constant over the life of a connection? Half---the shaded fields in fig. 3. So, if the sender and receiver keep track of active connections/8/ and the receiver keeps a copy of the header from the last packet it saw from each connection, the sender gets a factor-of-two compression by sending only a small (<= 8 bit) connection identifier together with the 20 bytes that change and letting the receiver fill in the 20 fixed bytes from the saved header.
しかしながら、TCPは関係を樹立します、そして、通常、各接続のときに10か何百ものパケットを交換します。 1パケットあたりの情報のいくらが接続の人生の間、一定のままでありそうですか? 半分---図3の陰影をつけられた分野。 それで、送付者と受信機がアクティブなconnections/8/の動向をおさえて、受信機がそれが各接続から見た最後のパケットからヘッダーのコピーを妨げるなら、変化する20バイトと共に小さい(<は8ビットと等しい)接続識別子だけを送って、受信機に救われたヘッダーから固定20バイトを記入させることによって、送付者は2の要素圧縮を得ます。
One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. But then the header checksum (bytes 10 and 11), which protects individual hops from processing a corrupted IP header, is essentially the only part of the IP header being sent. It seems rather silly to protect the transmission of information that isn't being transmitted. So, the receiver can check the header checksum when the header is actually sent (i.e., in an uncompressed datagram) but, for compressed datagrams, regenerate it locally at the same time the rest of the IP header is being regenerated./9/
どんな妥当なリンク・レベル縁どりプロトコルも、したがって、全長(バイト2と3)が余分であると受信されたメッセージの長さの受信機に言うことに注意することによって、人はバイトをもう少し清掃できます。 しかし、そして、ヘッダーチェックサム(バイト10と11)は本質的には送られるIPヘッダーの唯一の一部です。(それは、崩壊したIPヘッダーを処理するのから個々のホップを保護します)。 伝えられていない情報伝送を保護するのはかなり愚かに思えます。 それで、受信機が実際にヘッダーを送るとき(すなわち、解凍されたデータグラムで)、ヘッダーチェックサムをチェックしますが、IPヘッダーの残りが作り直される予定である同時代に圧縮されたデータグラムのために局所的にそれを作り直すことができる、/9/
----------------------------
7. The TCP and IP protocols and protocol headers are described in [10]
and [11].
8. The 96-bit tuple <src address, dst address, src port, dst port>
uniquely identifies a TCP connection.
9. The IP header checksum is not an end-to-end checksum in the sense
of [14]: The time-to-live update forces the IP checksum to be
recomputed at each hop. The author has had unpleasant personal
experience with the consequences of violating the end-to-end argument in
[14] and this protocol is careful to pass the end-to-end TCP checksum
through unmodified. See sec. 4.
---------------------------- 7. TCP、IPプロトコル、およびプロトコルヘッダーは[10]と[11]で説明されます。 8. 96ビットのtuple<srcアドレス、dstアドレス、srcポート、dstポート>は唯一TCP接続を特定します。 9. IPヘッダーチェックサムは[14]の意味で終わりから終わりへのチェックサムではありません: 生きる時間アップデートによって、IPチェックサムは各ホップでやむを得ず再計算されます。 作者には、[14]で終わりから終わりへの議論に違反する結果の不快な個人的な経験がありました、そして、このプロトコルは変更されないことで終わりから終わりへのTCPチェックサムを通過するように注意しています。 秒に遭遇してください。 4.
Jacobson [Page 4] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[4ページ]RFC1144
This leaves 16 bytes of header information to send. All of these bytes are likely to change over the life of the conversation but they do not all change at the same time. For example, during an FTP data transfer only the packet ID, sequence number and checksum change in the sender->receiver direction and only the packet ID, ack, checksum and, possibly, window, change in the receiver->sender direction. With a copy of the last packet sent for each connection, the sender can figure out what fields change in the current packet then send a bitmask indicating what changed followed by the changing fields./10/
これは、16バイトのヘッダー情報が発信するのを残します。 優にこれらのバイトは会話の人生の間変化しそうですが、それらは皆、同時に、変化しません。 例えばパケットID、一連番号、およびチェックサムだけが変化するFTPデータ転送、送付者->、受信機、指示とパケットID(ack、チェックサム、およびことによると窓)だけが変化する、受信機->、送付者、指示。 各接続のために最後のパケットのコピーを送って、送付者は、職業を替えで次に現在のパケットにおける変化が変化したものを示すビットマスクを送るどんな分野が. /10/に続いたかを理解できます。
If the sender only sends fields that differ, the above scheme gets the average header size down to around ten bytes. However, it's worthwhile looking at how the fields change: The packet ID typically comes from a counter that is incremented by one for each packet sent. I.e., the difference between the current and previous packet IDs should be a small, positive integer, usually <256 (one byte) and frequently = 1. For packets from the sender side of a data transfer, the sequence number in the current packet will be the sequence number in the previous packet plus the amount of data in the previous packet (assuming the packets are arriving in order). Since IP packets can be at most 64K, the sequence number change must be < 2^16 (two bytes). So, if the differences in the changing fields are sent rather than the fields themselves, another three or four bytes per packet can be saved.
送付者が異なる野原を送るだけであるなら、上の計画は平均したヘッダーサイズをおよそ10バイトまで得ます。 しかしながら、それは分野がどう変化するかが価値がある見ることです: IDが各パケットあたり1つ増加されるカウンタから通常来させるパケットは発信しました。 すなわち、現在で前のパケットIDの違いは、小さくて、陽の整数と、通常<256(1バイト)と頻繁に=1であるべきである。 データ転送の送付者側からのパケットに関しては、現在のパケットの一連番号は、前のパケットで前のパケットの一連番号とデータ量になるでしょう(パケットが整然とした状態で到着する予定であると仮定して)。 IPパケットが高々64Kであるかもしれないので、一連番号変化は<2^16(2バイト)であるに違いない。 それで、分野自体よりむしろ職業を替えの違いを送るなら、3バイトか1パケットあたりもう4バイトを節約できます。
That gets us to the five-byte header target. Recognizing a couple of special cases will get us three byte headers for the two most common cases---interactive typing traffic and bulk data transfer---but the basic compression scheme is the differential coding developed above. Given that this intellectual exercise suggests it is possible to get five byte headers, it seems reasonable to flesh out the missing details and actually implement something.
それは5バイトのヘッダー目標に私たちを得ます。 2、3の特別なケースが2つの最も一般的なケースのために私たち3バイトのヘッダーを手に入れると認めます。---交通とバルク・データ転送をタイプするインタラクティブ---しかし、基本的な圧縮技術は上で開発された差分符号化です。 この知的な運動が、5バイトのヘッダーを手に入れるのが可能であると示唆するなら、なくなった詳細を太らせて、実際に何かを実行するのは妥当に思えます。
3.2 The ugly details
3.2 醜い詳細
3.2.1 Overview
3.2.1 概観
Figure 4 shows a block diagram of the compression software. The networking system calls a SLIP output driver with an IP packet to be
図4は圧縮ソフトのブロック図を示しています。 SLIPがIPパケットでドライバーを出力したネットワークシステムコール
----------------------------
10. This is approximately Thinwire-I from [5]. A slight modification
is to do a `delta encoding' where the sender subtracts the previous
packet from the current packet (treating each packet as an array of 16
bit integers), then sends a 20-bit mask indicating the non-zero
differences followed by those differences. If distinct conversations
are separated, this is a fairly effective compression scheme (e.g.,
typically 12-16 byte headers) that doesn't involve the compressor
knowing any details of the packet structure. Variations on this theme
have been used, successfully, for a number of years (e.g., the Proteon
router's serial link protocol[3]).
---------------------------- 10. これは[5]からのおよそThinwire-Iです。 わずかな変更は送付者が現在のパケットから前のパケットを引き算して(16ビットの整数の勢ぞろいとして各パケットを扱います)、次に20ビットのマスクに非ゼロ差がそれらの違いで続いたのを示させる'デルタコード化'をすることです。 異なった会話が切り離されるなら、これはパケット構造のどんな細部も知っているコンプレッサーにかかわらないかなり効果的な圧縮技術(例えば、通常12-16バイトのヘッダー)です。 このテーマの変化は多くの(例えば、Proteonルータ何年もの連続のリンク・プロトコル[3])に首尾よく使用されました。
Jacobson [Page 5] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[5ページ]RFC1144
sent over the serial line. The packet goes through a compressor which checks if the protocol is TCP. Non-TCP packets and `uncompressible' TCP packets (described below) are just marked as TYPE_IP and passed to a framer. Compressible TCP packets are looked up in an array of packet headers. If a matching connection is found, the incoming packet is compressed, the (uncompressed) packet header is copied into the array, and a packet of type COMPRESSED_TCP is sent to the framer. If no match is found, the oldest entry in the array is discarded, the packet header is copied into that slot, and a packet of type UNCOMPRESSED_TCP is sent to the framer. (An UNCOMPRESSED_TCP packet is identical to the original IP packet except the IP protocol field is replaced with a connection number---an index into the array of saved, per-connection packet headers. This is how the sender (re-)synchronizes the receiver and `seeds' it with the first, uncompressed packet of a compressed packet sequence.)
シリアル・ラインを移動しました。 パケットはプロトコルがTCPであるかどうかチェックするコンプレッサーを通ります。 非TCPパケットと'uncompressible'TCPパケット(以下で、説明される)は、TYPE_IPとしてただマークされて、喧嘩早い人に渡されます。 圧縮性のTCPパケットはパケットのヘッダーのアレイで調べられます。 合っている接続を見つけるなら、入って来るパケットを圧縮します、そして、(解凍されます)パケットのヘッダーをアレイにコピーします、そして、タイプCOMPRESSED_TCPのパケットを喧嘩早い人に送ります。 マッチを全く見つけないなら、アレイで最も古いエントリーは捨てます、そして、そのスロットにパケットのヘッダーをコピーします、そして、タイプUNCOMPRESSED_TCPのパケットを喧嘩早い人に送ります。 (UNCOMPRESSED_TCPパケットはオリジナルのIPパケットと同じです、そして、IPプロトコル野原を接続番号に取り替えます。---1接続あたりの救われたパケットのヘッダーのアレイへのインデックス。 これ、どのようにが送付者であるか、(再、)、1(圧縮されたパケット系列の解凍されたパケット)番目で受信機を連動させて、それに'種を蒔きます'。)
The framer is responsible for communicating the packet data, type and boundary (so the decompressor can learn how many bytes came out of the compressor). Since the compression is a differential coding, the framer must not re-order packets (this is rarely a concern over a single serial link). It must also provide good error detection and, if connection numbers are compressed, must provide an error indication to the decompressor (see sec. 4)./11/
喧嘩早い人はパケットデータ、タイプ、および境界を伝えるのに責任があります(したがって、減圧装置は、いくつのバイトがコンプレッサーから出て来たかを学ぶことができます)。 圧縮が差分符号化であるので、喧嘩早い人はパケットを再注文してはいけません(これはめったに単一の連続のリンクに関する心配ではありません)。 それは、また、良い誤り検出を提供しなければならなくて、接続番号が圧縮されるなら、誤り表示を減圧装置に提供しなければなりません。(秒に遭遇してください。 4)./11/
The decompressor does a `switch' on the type of incoming packets: For TYPE_IP, the packet is simply passed through. For UNCOMPRESSED_TCP, the connection number is extracted from the IP protocol field and IPPROTO_TCP is restored, then the connection number is used as an index into the receiver's array of saved TCP/IP headers and the header of the incoming packet is copied into the indexed slot. For COMPRESSED_TCP, the connection number is used as an array index to get the TCP/IP header of the last packet from that connection, the info in the compressed packet is used to update that header, then a new packet is constructed containing the now-current header from the array concatenated with the data from the compressed packet.
減圧装置は入って来るパケットのタイプで'スイッチ'をします: TYPE_IPに関しては、パケットは単に通り抜けます。 UNCOMPRESSED_TCPに関しては、接続番号はIPプロトコル分野から抜粋されて、IPPROTO_TCPは返されて、受信機の救われたTCP/IPヘッダーのアレイと入って来るパケットのヘッダーへのインデックスが索引をつけられたスロットにコピーされるとき、次に、接続番号は使用されています。 COMPRESSED_TCPに関しては、接続番号はその接続から最後のパケットのTCP/IPヘッダーを手に入れるのに配列指数として使用されて、圧縮されたパケットのインフォメーションはそのヘッダーをアップデートするのに使用されて、圧縮されたパケットからのデータで連結されたアレイからの現在、現在のヘッダーを含んでいて、次に、新しいパケットは組み立てられます。
Note that the communication is simplex---no information flows in the decompressor-to-compressor direction. In particular, this implies that the decompressor is relying on TCP retransmissions to correct the saved state in the event of line errors (see sec. 4).
コミュニケーションがシンプレクスであることに注意してください。---情報は全く減圧装置からコンプレッサーへの方向に流れません。 特に、これは、減圧装置が線誤りの場合、救われた状態を修正するためにTCP retransmissionsを当てにしているのを含意します。(秒に遭遇してください。 4).
----------------------------
11. Link level framing is outside the scope of this document. Any
framing that provides the facilities listed in this paragraph should be
adequate for the compression protocol. However, the author encourages
potential implementors to see [9] for a proposed, standard, SLIP
framing.
---------------------------- 11. このドキュメントの範囲の外にリンク・レベル縁どりがあります。 圧縮プロトコルに、このパラグラフで記載された施設を提供するどんな縁どりも適切であるべきです。 しかしながら、作者は、潜在的作成者が提案されて、標準のSLIP縁どりのための[9]を見るよう奨励します。
Jacobson [Page 6] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[6ページ]RFC1144
3.2.2 Compressed packet format
3.2.2 圧縮されたパケット・フォーマット
Figure 5 shows the format of a compressed TCP/IP packet. There is a change mask that identifies which of the fields expected to change per-packet actually changed, a connection number so the receiver can locate the saved copy of the last packet for this TCP connection, the unmodified TCP checksum so the end-to-end data integrity check will still be valid, then for each bit set in the change mask, the amount the associated field changed. (Optional fields, controlled by the mask, are enclosed in dashed lines in the figure.) In all cases, the bit is set if the associated field is present and clear if the field is absent./12/
図5は圧縮されたTCP/IPパケットの書式を示しています。 したがって、受信機がこのTCP接続、変更されていないTCPチェックサムのための最後のパケットの救われたコピーの場所を見つけることができるように実際に変えられたパケット、接続番号を変えると予想された分野では終わりから終わりへのデータ保全チェックがまだ有効になっているでしょう、そしてどれにおいて変化マスクに設定されて、それぞれ噛み付かれた状態で特定する変化マスクがあります、関連分野が変えた量。 (マスクによって制御された任意の分野は図の投げつけられた線で囲まれます。) すべての場合では、関連分野が現在であって明確であるなら、分野が. /12/なしであるなら、ビットは設定されます。
Since the delta's in the sequence number, etc., are usually small, particularly if the tuning guidelines in section 5 are followed, all the numbers are encoded in a variable length scheme that, in practice, handles most traffic with eight bits: A change of one through 255 is represented in one byte. Zero is improbable (a change of zero is never sent) so a byte of zero signals an extension: The next two bytes are the MSB and LSB, respectively, of a 16 bit value. Numbers larger than 16 bits force an uncompressed packet to be sent. For example, decimal 15 is encoded as hex 0f, 255 as ff, 65534 as 00 ff fe, and zero as 00 00 00. This scheme packs and decodes fairly efficiently: The usual case for both encode and decode executes three instructions on a MC680x0.
特にセクション5の調律ガイドラインが従われているなら一連番号におけるデルタなどが通常小さいので、すべての数が実際には8ビットによるほとんどの交通を扱う可変長計画でコード化されます: 1〜255の変化は1バイトで表されます。 ゼロがありそうもないので(ゼロの変化を決して送りません)、1バイトのゼロは拡大を示します、: 次の2バイトは、それぞれ16ビットの価値のMSBとLSBです。 16ビットより大きい数のために、やむを得ず解凍されたパケットを送ります。 例えば、10進15は十六進法0f、ffとしての255、00ff feとしての65534、および00 00 00としてのゼロとしてコード化されます。 この計画は、かなり効率的に荷造りして、解読します: 両方のためのケースがコード化して、解読する普通はMC680x0の3つの指示を実行します。
The numbers sent for TCP sequence number and ack are the difference/13/ between the current value and the value in the previous packet (an uncompressed packet is sent if the difference is negative or more than 64K). The number sent for the window is also the difference between the current and previous values. However, either positive or negative changes are allowed since the window is a 16 bit field. The packet's urgent pointer is sent if URG is set (an uncompressed packet is sent if the urgent pointer changes but URG is not set). For packet ID, the number sent is the difference between the current and previous values. However, unlike the rest of the compressed fields, the assumed change when I is clear is one, not zero.
TCP一連番号とackのために送られた数は現行価値と前のパケットの値の間のdifference/13/(違いが否定的であるか、そして、64K以上を解凍されたパケットに送る)です。 また、窓に送られた数は現在で前の値の違いです。 しかしながら、肯定しているか否定している変化は、窓が16ビットの分野であるので、許容されています。 URGが用意ができているなら(緊急のポインタが変化するなら、解凍されたパケットを送りますが、URGは用意ができていません)、パケットの緊急のポインタを送ります。 パケットIDのために、送られた数は現在で前の値の違いです。 しかしながら、私であるときに、圧縮された分野の残りと異なった、想定された変化は明確であるのが、ゼロではなく、1であるということです。
There are two important special cases:
2つの重要な特別なケースがあります:
(1) The sequence number and ack both change by the amount of data in the
last packet; no window change or URG.
(1) 最後のパケットのデータ量に応じて、一連番号とackはともに変化します。 ウィンドウ変化でないURGがありません。
(2) The sequence number changes by the amount of data in the last
packet, no ack or window change or URG.
(2) データ量に応じて、一連番号は最後のパケット、ack、ウィンドウ変化またはどんなURGでも変化しません。
----------------------------
12. The bit `P' in the figure is different from the others: It is a
copy of the `PUSH' bit from the TCP header. `PUSH' is a curious
anachronism considered indispensable by certain members of the Internet
community. Since PUSH can (and does) change in any datagram, an
information preserving compression scheme must pass it explicitly.
13. All differences are computed using two's complement arithmetic.
---------------------------- 12. 図のビット'P'は他のものと異なっています: それはTCPヘッダーからの'PUSH'ビットのコピーです。 'PUSH'は不可欠であるとインターネットコミュニティの確信しているメンバーによって考えられた好奇心の強い時代錯誤です。 PUSHがどんなデータグラムでも変化できるので(そして、します)、圧縮技術を保存する情報は明らかにそれを通過しなければなりません。 13. すべての違いが、2の補数演算を使用することで計算されます。
Jacobson [Page 7] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[7ページ]RFC1144
(1) is the case for echoed terminal traffic. (2) is the sender side of non-echoed terminal traffic or a unidirectional data transfer. Certain combinations of the S, A, W and U bits of the change mask are used to signal these special cases. `U' (urgent data) is rare so two unlikely combinations are S W U (used for case 1) and S A W U (used for case 2). To avoid ambiguity, an uncompressed packet is sent if the actual changes in a packet are S * W U.
(1)は反響している端末の交通へのケースです。 (2) 非反響している端末の交通か単方向のデータ転送が送付者側がありますか? 変化マスクのSのある組み合わせ、A、W、およびUビットは、これらの特別なケースに合図するのに使用されます。 したがって、2つのありそうもない組み合わせが、'U'(緊急のデータ)はまれであり、S W U(ケース1のために、使用されます)とS A W Uです(ケース2のために、使用されます)。 あいまいさを避けるために、パケットにおける実際の変化がS*W Uであるなら解凍されたパケットを送ります。
Since the `active' connection changes rarely (e.g., a user will type for several minutes in a telnet window before changing to a different window), the C bit allows the connection number to be elided. If C is clear, the connection is assumed to be the same as for the last compressed or uncompressed packet. If C is set, the connection number is in the byte immediately following the change mask./14/
'アクティブな'接続がめったに変化しないので(例えば、ユーザは異なった窓に変化する前に、数分間telnetウィンドウにタイプするでしょう)、Cビットは、接続番号が削除されるのを許容します。 Cが明確であるなら、接続が最後に圧縮されたか、または解凍されたパケットのように同じであると思われます。 Cが設定されるなら、すぐにマスク変化/14/に続いて、バイトには接続番号があります。
From the above, it's probably obvious that compressed terminal traffic usually looks like (in hex): 0B c c d, where the 0B indicates case (1), c c is the two byte TCP checksum and d is the character typed. Commands to vi or emacs, or packets in the data transfer direction of an FTP `put' or `get' look like 0F c c d ... , and acks for that FTP look like 04 c c a where a is the amount of data being acked./15/
上記では、通常、圧縮された端末の交通に似ているのは(十六進法で)、たぶん明白です: 0B c c d(0Bはケース(1)を示して、c cは2バイトTCPチェックサムとdです)はタイプされた文字です。 vi、emacs、または'置かれる'というFTPのデータ転送方向へのパケットへのコマンドか'得てください'が0F c c dに似ています… , そして、そのFTP外観同様の04c c aのためのacksはaがデータ存在の量であるところで. /15/をackedしました。
3.2.3 Compressor processing
3.2.3 コンプレッサー処理
The compressor is called with the IP packet to be processed and the compression state structure for the outgoing serial line. It returns a packet ready for final framing and the link level `type' of that packet.
コンプレッサーは処理されるべきIPパケットと圧縮状態構造で出発しているシリアル・ラインに呼ばれます。 それはそのパケットの'タイプ'を最終的な縁どりの準備ができるパケットとリンク・レベルに返します。
As the last section noted, the compressor converts every input packet into either a TYPE_IP, UNCOMPRESSED_TCP or COMPRESSED_TCP packet. A
最後のセクションが注意したように、コンプレッサーはTYPE_IP、UNCOMPRESSED_TCPまたはCOMPRESSED_TCPパケットにあらゆる入力パケットを変換します。 A
----------------------------
14. The connection number is limited to one byte, i.e., 256
simultaneously active TCP connections. In almost two years of
operation, the author has never seen a case where more than sixteen
connection states would be useful (even in one case where the SLIP link
was used as a gateway behind a very busy, 64-port terminal multiplexor).
Thus this does not seem to be a significant restriction and allows the
protocol field in UNCOMPRESSED_TCP packets to be used for the connection
number, simplifying the processing of those packets.
15. It's also obvious that the change mask changes infrequently and
could often be elided. In fact, one can do slightly better by saving
the last compressed packet (it can be at most 16 bytes so this isn't
much additional state) and checking to see if any of it (except the TCP
checksum) has changed. If not, send a packet type that means
`compressed TCP, same as last time' and a packet containing only the
checksum and data. But, since the improvement is at most 25%, the added
complexity and state doesn't seem justified. See appendix C.
---------------------------- 14. 接続番号はすなわち、1バイト、256の同時に活発なTCP接続に制限されます。 およそ2年間の操作では、作者は16以上の接続州が役に立つ(SLIPリンクがゲートウェイとして非常に忙しくて、64ポートの端末のマルチプレクサーの後ろで使用されたある場合さえにおける)ケースを一度も、見たことがありません。 したがって、これは、重要な制限であるように思えないで、UNCOMPRESSED_TCPパケットのプロトコル分野が接続番号に使用されるのを許容します、それらのパケットの処理を簡素化して。 15. また、変化マスクはまれに変化して、しばしば削除できたのも明白です。 事実上、1つが、最後に圧縮されたパケット(それが高々16バイトであるかもしれないので、これは多くの追加状態ではありません、)を貯蓄して、それ(TCPチェックサムを除いた)のどれかが変化したかどうかを見るためにチェックすることによって、わずかに上手にできます。 そうでなければ、その手段'圧縮されたTCP、前回同様時間'とチェックサムとデータだけを含むパケットをパケットタイプに送ってください。 しかし、改良が高々25%であるので、加えられた複雑さと状態は正当に見えません。 付録Cを見てください。
Jacobson [Page 8] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[8ページ]RFC1144
TYPE_IP packet is an unmodified copy/16/ of the input packet and processing it doesn't change the compressor's state in any way.
TYPE_IPパケットは入力パケットの変更されていないcopy/16/です、そして、それを処理する場合、コンプレッサーの状態は何らかの方法で変化しません。
An UNCOMPRESSED_TCP packet is identical to the input packet except the IP protocol field (byte 9) is changed from `6' (protocol TCP) to a connection number. In addition, the state slot associated with the connection number is updated with a copy of the input packet's IP and TCP headers and the connection number is recorded as the last connection sent on this serial line (for the C compression described below).
UNCOMPRESSED_TCPパケットは入力パケットと同じです、そして、IPプロトコル分野(バイト9)は'6'(プロトコルTCP)から接続番号に変わります。 さらに、入力パケットのIPとTCPヘッダーのコピーで接続番号に関連している州のスロットをアップデートします、そして、最後の接続がこのシリアル・ライン(以下で説明されたC圧縮のための)を転送したので、接続番号は記録しています。
A COMPRESSED_TCP packet contains the data, if any, from the original packet but the IP and TCP headers are completely replaced with a new, compressed header. The connection state slot and last connection sent are updated by the input packet exactly as for an UNCOMPRESSED_TCP packet.
COMPRESSED_TCPパケットはオリジナルのパケットからデータをもしあれば含んでいますが、IPとTCPヘッダーを新しくて、圧縮されたヘッダーに完全に取り替えます。 入力パケットはちょうどUNCOMPRESSED_TCPパケットのように送られた接続州のスロットと最後の接続をアップデートします。
The compressor's decision procedure is:
コンプレッサーの決定手順は以下の通りです。
- If the packet is not protocol TCP, send it as TYPE_IP.
- パケットがプロトコルTCPでないなら、TYPE_IPとしてそれを送ってください。
- If the packet is an IP fragment (i.e., either the fragment offset
field is non-zero or the more fragments bit is set), send it as
TYPE_IP./17/
- パケットがIP断片(すなわち、断片オフセットがさばくどちらかが非ゼロであるか、より多くの断片ビットがセットである)であるなら、TYPE_IP/17/としてそれを送ってください。
- If any of the TCP control bits SYN, FIN or RST are set or if the ACK
bit is clear, consider the packet uncompressible and send it as
TYPE_IP./18/
- TCPコントロールビットのSYN、FINまたはRSTのどれかが用意ができているか、またはACKビットが明確であるなら、パケットがuncompressibleであると考えてください、そして、TYPE_IP/18/としてそれを送ってください。
----------------------------
16. It is not necessary (or desirable) to actually duplicate the input
packet for any of the three output types. Note that the compressor
cannot increase the size of a datagram. As the code in appendix A
shows, the protocol can be implemented so all header modifications are
made `in place'.
17. Only the first fragment contains the TCP header so the fragment
offset check is necessary. The first fragment might contain a complete
TCP header and, thus, could be compressed. However the check for a
complete TCP header adds quite a lot of code and, given the arguments in
[6], it seems reasonable to send all IP fragments uncompressed.
18. The ACK test is redundant since a standard conforming
implementation must set ACK in all packets except for the initial SYN
packet. However, the test costs nothing and avoids turning a bogus
packet into a valid one.
SYN packets are not compressed because only half of them contain a valid
ACK field and they usually contain a TCP option (the max. segment size)
which the following packets don't. Thus the next packet would be sent
uncompressed because the TCP header length changed and sending the SYN
as UNCOMPRESSED_TCP instead of TYPE_IP would buy nothing.
The decision to not compress FIN packets is questionable. Discounting
the trick in appendix B.1, there is a free bit in the header that could
be used to communicate the FIN flag. However, since connections tend to
---------------------------- 16. 3つの出力タイプのどれかのために実際に入力パケットをコピーするのは、必要でなくて(望ましい。)です。 コンプレッサーがデータグラムのサイズを増加させることができないことに注意してください。 付録Aのコードが目立っているようにプロトコルを実行できるので、'適所'ですべてのヘッダー変更をします。 17. 最初の断片だけがTCPヘッダーを含んでいるので、断片オフセットチェックが必要です。 最初の断片は、完全なTCPヘッダーを含むかもしれなくて、その結果、圧縮できました。 しかしながら、完全なTCPヘッダーがコードのかなりのロットに加えて、[6]の議論を考えて、すべてのIP断片を送るのが妥当に思えるので、チェックは解凍しました。 18. 標準の従う実現が初期のSYNパケット以外のすべてのパケットにACKをはめ込まなければならないので、ACKテストは余分です。 しかしながら、テストは、何もかからないで、にせのパケットを有効なものに変えるのを避けます。 有効なACK分野を含んでいるので、SYNパケットは圧縮されません、そして、通常、それらはTCPオプションを含んでいます。(最大である、セグメントサイズ) 以下のパケットがそうしない。 したがって、TYPE_IPの代わりにUNCOMPRESSED_TCPは何も買わないでしょう、TCPヘッダ長が変化したので解凍されて、したがって、SYNを送るのを次のパケットを送るでしょう。 FINパケットを圧縮しないという決定は疑わしいです。 付録B.1のトリックを無視して、空き領域ビットがFIN旗を伝えるのに使用できたヘッダーにあります。 しかしながら、接続以来、傾向があってください。
Jacobson [Page 9] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[9ページ]RFC1144
If a packet makes it through the above checks, it will be sent as either UNCOMPRESSED_TCP or COMPRESSED_TCP:
パケットが上のチェックでそれを作ると、UNCOMPRESSED_TCPかCOMPRESSED_TCPのどちらかとしてそれを送るでしょう:
- If no connection state can be found that matches the packet's source
and destination IP addresses and TCP ports, some state is reclaimed
(which should probably be the least recently used) and an
UNCOMPRESSED_TCP packet is sent.
- 接続状態を全く見つけることができないなら、それはパケットのソース、送付先IPアドレス、およびTCPポートに合っています、そして、何らかの状態を取り戻します、そして、(最も最近でないときに、たぶん使用であるべきです)UNCOMPRESSED_TCPパケットを送ります。
- If a connection state is found, the packet header it contains is
checked against the current packet to make sure there were no
unexpected changes. (E.g., that all the shaded fields in fig. 3 are
the same). The IP protocol, fragment offset, more fragments, SYN,
FIN and RST fields were checked above and the source and destination
address and ports were checked as part of locating the state. So
the remaining fields to check are protocol version, header length,
type of service, don't fragment, time-to-live, data offset, IP
options (if any) and TCP options (if any). If any of these fields
differ between the two headers, an UNCOMPRESSED_TCP packet is sent.
- 接続状態が見つけられるなら、それが含むパケットのヘッダーは、意外な変化が全くなかったのを確実にするために現在のパケットに対してチェックされます。 (例えば、すべて陰影をつけるのが図で3をさばくのは、同じです。) IPプロトコル、断片オフセット、より多くの断片、SYN、FIN、およびRST分野は上でチェックされました、そして、ソース、送付先アドレス、およびポートは状態の場所を見つける一部としてチェックされました。 それで、チェックする残っているフィールドは、バージョン、ヘッダ長、サービスのタイプが断片化しないプロトコルと、生きる時間と、データオフセットと、(もしあれば)のIPオプションと(もしあれば)のTCPオプションです。 これらの分野のどれかが2個のヘッダーの間で異なるなら、UNCOMPRESSED_TCPパケットを送ります。
If all the `unchanging' fields match, an attempt is made to compress the current packet:
すべての'変りません、な'分野が合っているなら、現在のパケットを圧縮するのを試みをします:
- If the URG flag is set, the urgent data field is encoded (note that
it may be zero) and the U bit is set in the change mask.
Unfortunately, if URG is clear, the urgent data field must be
checked against the previous packet and, if it changes, an
UNCOMPRESSED_TCP packet is sent. (`Urgent data' shouldn't change
when URG is clear but [11] doesn't require this.)
- URG旗が設定されるなら、緊急のデータ・フィールドはコード化されます、そして、(それがゼロであるかもしれないことに注意してください)Uビットは変化マスクに設定されます。 残念ながら、URGが明確であるなら、前のパケットに対して緊急のデータ・フィールドをチェックしなければなりません、そして、変化するなら、UNCOMPRESSED_TCPパケットを送ります。 ('緊急のデータ'は、URGがいつ明確であるかを変えるべきではありませんが、[11]はこれを必要としません。)
- The difference between the current and previous packet's window
field is computed and, if non-zero, is encoded and the W bit is set
in the change mask.
- 電流と前のパケットの窓の分野の違いは、計算されて、非ゼロであるならコード化されます、そして、Wビットは変化マスクに設定されます。
- The difference between ack fields is computed. If the result is
less than zero or greater than 2^16 - 1, an UNCOMPRESSED_TCP packet
is sent./19/ Otherwise, if the result is non-zero, it is encoded
and the A bit is set in the change mask.
- ack分野の違いは計算されます。 結果があるなら、ゼロ以上より2^16--1UNCOMPRESSED_TCPパケットを送ります。/19/ Otherwise、結果が非ゼロであるなら、それをコード化します、そして、変化マスクにAビットを設定します。
- The difference between sequence number fields is computed. If the
result is less than zero or greater than 2^16 - 1, an
- 一連番号分野の違いは計算されます。 結果があるならゼロ以上より2^16--1
----------------------------
last for many packets, it seemed unreasonable to dedicate an entire bit
to a flag that would only appear once in the lifetime of the connection.
19. The two tests can be combined into a single test of the most
significant 16 bits of the difference being non-zero.
---------------------------- 多くのパケットにおいて最後であり、接続の生涯一度現れるだけである旗に全体のビットを捧げるのは無理に思えました。 19. 非ゼロである違いの最も重要な16ビットのただ一つのテストに2つのテストを結合できます。
Jacobson [Page 10] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[10ページ]RFC1144
UNCOMPRESSED_TCP packet is sent./20/ Otherwise, if the result is
non-zero, it is encoded and the S bit is set in the change mask.
UNCOMPRESSED_TCPパケットを送ります。/20/ Otherwise、結果が非ゼロであるなら、それをコード化します、そして、変化マスクにSビットを設定します。
Once the U, W, A and S changes have been determined, the special-case encodings can be checked:
U、W、A、およびS変化がいったん断固とするようになると、特別なケースencodingsをチェックできます:
- If U, S and W are set, the changes match one of the special-case
encodings. Send an UNCOMPRESSED_TCP packet.
- U、S、およびWが設定されるなら、変化は特別なケースencodingsの1つに合っています。 UNCOMPRESSED_TCPパケットを送ってください。
- If only S is set, check if the change equals the amount of user data
in the last packet. I.e., subtract the TCP and IP header lengths
from the last packet's total length field and compare the result to
the S change. If they're the same, set the change mask to SAWU (the
special case for `unidirectional data transfer') and discard the
encoded sequence number change (the decompressor can reconstruct it
since it knows the last packet's total length and header length).
- Sだけが設定されるなら、変化が最後のパケットの利用者データの量と等しいかどうかチェックしてください。 すなわち、最後のパケットの全長分野からTCPとIPヘッダ長を引き算してください、そして、S変化と結果を比較してください。 それらが同じであるなら、サウ('単方向のデータ転送'のための特別なケース)に変化マスクを設定してください、そして、コード化された一連番号変化を捨ててください(最後のパケットの全長とヘッダ長を知っているので、減圧装置はそれを再建できます)。
- If only S and A are set, check if they both changed by the same
amount and that amount is the amount of user data in the last
packet. If so, set the change mask to SWU (the special case for
`echoed interactive' traffic) and discard the encoded changes.
- SとAだけが設定されるなら、同じ量に応じてそれらの両方が変化して、その量が最後のパケットの利用者データの量であるかどうかチェックしてください。 そうだとすれば、SWU('反響している対話的な'通信への特別なケース)に変化マスクを設定してください、そして、コード化された変化を捨ててください。
- If nothing changed, check if this packet has no user data (in which
case it is probably a duplicate ack or window probe) or if the
previous packet contained user data (which means this packet is a
retransmission on a connection with no pipelining). In either of
these cases, send an UNCOMPRESSED_TCP packet.
- 何も変化しなかったなら、このパケットで利用者データが全くないかどうか(その場合、それは、たぶん写しackか窓の徹底的調査です)、または前のパケットが利用者データ(このパケットがパイプライン処理のない接続での「再-トランスミッション」であることを意味する)を含んだかどうかチェックしてください。 これらのケースのどちらかでは、UNCOMPRESSED_TCPパケットを送ってください。
Finally, the TCP/IP header on the outgoing packet is replaced with a compressed header:
最終的に、出発しているパケットの上のTCP/IPヘッダーを圧縮されたヘッダーに取り替えます:
- The change in the packet ID is computed and, if not one,/21/ the
difference is encoded (note that it may be zero or negative) and the
I bit is set in the change mask.
- パケットIDにおける変化が計算される、1でないことの/21/、違いはコード化されて(それがゼロかネガであるかもしれないことに注意してください)、Iビットは変化マスクに設定されます。
- If the PUSH bit is set in the original datagram, the P bit is set in
the change mask.
- PUSHビットがオリジナルのデータグラムに設定されるなら、Pビットは変化マスクに設定されます。
- The TCP and IP headers of the packet are copied to the connection
state slot.
- パケットのTCPとIPヘッダーは接続州のスロットにコピーされます。
----------------------------
20. A negative sequence number change probably indicates a
retransmission. Since this may be due to the decompressor having
dropped a packet, an uncompressed packet is sent to re-sync the
decompressor (see sec. 4).
21. Note that the test here is against one, not zero. The packet ID is
typically incremented by one for each packet sent so a change of zero is
very unlikely. A change of one is likely: It occurs during any period
when the originating system has activity on only one connection.
---------------------------- 20. 否定的一連番号変化はたぶん「再-トランスミッション」を示します。 パケットを減圧装置に落として、これが当然であるかもしれないので、減圧装置を再同期させるように解凍されたパケットを送ります。(秒に遭遇してください。 4). 21. ここでのテストがゼロではなく、1つに反対していることに注意してください。 ゼロの変化が非常にありそうもなくて、送って、通常、パケットIDは各パケットあたり1つ増加されます。 1の変化はありそうです: それは由来しているシステムが1つの接続だけに活動を持っているどんな期間も、起こります。
Jacobson [Page 11] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[11ページ]RFC1144
- The TCP and IP headers of the packet are discarded and a new header
is prepended consisting of (in reverse order):
- パケットのTCPとIPヘッダーは捨てられます、そして、新しいヘッダーは(コネ逆のオーダー)から成りながら、prependedされます:
- the accumulated, encoded changes.
- 蓄積されて、コード化された変化。
- the TCP checksum (if the new header is being constructed `in
place', the checksum may have been overwritten and will have to
be taken from the header copy in the connection state or saved
in a temporary before the original header is discarded).
- TCPチェックサム(新しいヘッダーが'適所'で組み立てられているなら、チェックサムが上書きされたかもしれなくて、オリジナルのヘッダーが捨てる前に、接続状態でヘッダーコピーから取らなければならないか、またはaで一時的に救わなければならないでしょう)。
- the connection number (if different than the last one sent on
this serial line). This also means that the the line's last
connection sent must be set to the connection number and the C
bit set in the change mask.
- 接続番号(最後のものがこのシリアル・ラインを転送したより異なるなら)。 また、これは、最後の接続が送った行を接続番号に設定しなければならなくて、Cビットが変化マスクにセットしたことを意味します。
- the change mask.
- 変化マスク。
At this point, the compressed TCP packet is passed to the framer for transmission.
ここに、圧縮されたTCPパケットはトランスミッションのために喧嘩早い人に渡されます。
3.2.4 Decompressor processing
3.2.4 減圧装置処理
Because of the simplex communication model, processing at the decompressor is much simpler than at the compressor --- all the decisions have been made and the decompressor simply does what the compressor has told it to do.
シンプレクスコミュニケーションモデルのために、減圧装置における処理はコンプレッサーよりはるかに簡単です。--- すべての決定をしました、そして、減圧装置は単に、コンプレッサーがするようにそれに言ったことをします。
The decompressor is called with the incoming packet,/22/ the length and type of the packet and the compression state structure for the incoming serial line. A (possibly re-constructed) IP packet will be returned.
減圧装置が入って来るパケットで呼ばれて、/22/はパケットの長さとタイプと入って来るシリアル・ラインへの圧縮状態構造です。 (ことによると再建されています)のIPパケットを返すでしょう。
The decompressor can receive four types of packet: the three generated by the compressor and a TYPE_ERROR pseudo-packet generated when the receive framer detects an error./23/ The first step is a `switch' on the packet type:
減圧装置は4つのタイプのパケットを受けることができます: 喧嘩早い人を受けてください。発生する3がコンプレッサーとTYPE_ERROR疑似パケットでいつを発生させたか、誤りを検出する、/23/、第一歩はパケットタイプの'スイッチ'です:
- If the packet is TYPE_ERROR or an unrecognized type, a `toss' flag
is set in the state to force COMPRESSED_TCP packets to be discarded
until one with the C bit set or an UNCOMPRESSED_TCP packet arrives.
Nothing (a null packet) is returned.
- Cビットがある1つがセットするまでパケットがTYPE_ERRORか認識されていないタイプであるなら、状態に'トス'旗はCOMPRESSED_TCPパケットを捨てさせられるように設定されるか、またはUNCOMPRESSED_TCPパケットが到着します。 何(ヌルパケット)も返しません。
----------------------------
22. It's assumed that link-level framing has been removed by this point
and the packet and length do not include type or framing bytes.
23. No data need be associated with a TYPE_ERROR packet. It exists so
the receive framer can tell the decompressor that there may be a gap in
the data stream. The decompressor uses this as a signal that packets
should be tossed until one arrives with an explicit connection number (C
bit set). See the last part of sec. 4.1 for a discussion of why this is
necessary.
---------------------------- 22. それは、この時点で、リンク・レベル縁どりを取り除いて、パケットと長さがタイプか縁どりバイトを含んでいないと仮定しました。 23. どんなデータもTYPE_ERRORパケットに関連している必要はありません。 したがって、存在している、缶が流れるとデータにはギャップがあるかもしれない減圧装置に言う喧嘩早い人を受けてください。 減圧装置は1つが明白な接続番号と共に到着するまで(Cビットはセットしました)パケットが投げられるべきであるという信号としてこれを使用します。 秒の最後の部分を見てください。 4.1 これが必要である理由に関する議論のために。
Jacobson [Page 12] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[12ページ]RFC1144
- If the packet is TYPE_IP, an unmodified copy of it is returned and
the state is not modified.
- パケットがTYPE_IPであるなら、変更されていないコピーのそれを返します、そして、状態は変更していません。
- If the packet is UNCOMPRESSED_TCP, the state index from the IP
protocol field is checked./24/ If it's illegal, the toss flag is
set and nothing is returned. Otherwise, the toss flag is cleared,
the index is copied to the state's last connection received field, a
copy of the input packet is made,/25/ the TCP protocol number is
restored to the IP protocol field, the packet header is copied to
the indicated state slot, then the packet copy is returned.
- パケットがUNCOMPRESSED_TCPであるなら、IPプロトコル分野からの州のインデックスをチェックします。不法入国者、トス旗がセットと何でないということであるならでも、/24/を返します。 さもなければ、トス旗をきれいにして、状態の最後の接続容認された分野にインデックスをコピーして、入力パケットのコピーを作って、TCPプロトコルが付番する/25/をIPプロトコル分野に返して、示された州のスロットにパケットのヘッダーをコピーして、次に、パケットコピーを返します。
If the packet was not handled above, it is COMPRESSED_TCP and a new TCP/IP header has to be synthesized from information in the packet plus the last packet's header in the state slot. First, the explicit or implicit connection number is used to locate the state slot:
パケットが上で扱われなかったなら、それはCOMPRESSED_TCPです、そして、新しいTCP/IPヘッダーは州のスロットでパケットと最後のパケットのヘッダーで情報から統合されなければなりません。 まず最初に、明白であるか暗黙の接続番号は州のスロットの場所を見つけるのに使用されます:
- If the C bit is set in the change mask, the state index is checked.
If it's illegal, the toss flag is set and nothing is returned.
Otherwise, last connection received is set to the packet's state
index and the toss flag is cleared.
- Cビットが変化マスクに設定されるなら、州のインデックスはチェックされます。 それが不法であるなら、トス旗を設定します、そして、何も返しません。 さもなければ、受けられた最後の接続はパケットの州のインデックスに用意ができています、そして、トス旗はきれいにされます。
- If the C bit is clear and the toss flag is set, the packet is
ignored and nothing is returned.
- Cビットが明確であり、トス旗を設定するなら、パケットを無視します、そして、何も返しません。
At this point, last connection received is the index of the appropriate state slot and the first byte(s) of the compressed packet (the change mask and, possibly, connection index) have been consumed. Since the TCP/IP header in the state slot must end up reflecting the newly arrived packet, it's simplest to apply the changes from the packet to that header then construct the output packet from that header concatenated with the data from the input packet. (In the following description, `saved header' is used as an abbreviation for `the TCP/IP header saved in the state slot'.)
ここに、受けられた最後の接続は適切な州のスロットのインデックスです、そして、圧縮されたパケット(変化マスクとことによると接続は索引をつける)の最初のバイトは消費されました。 州のスロットのTCP/IPヘッダーが結局新たに到着したパケットを反映しなければならないので、パケットから当時のそのヘッダーからの出力パケットが入力パケットからのデータで連結したそのヘッダー構造物までの変化を適用するのは最も簡単です。 (以下の記述では、'救われたヘッダー'は'TCP/IPヘッダーは州のスロットで節約したこと'に略語として使用されます。)
- The next two bytes in the incoming packet are the TCP checksum.
They are copied to the saved header.
- 入って来るパケットの次の2バイトはTCPチェックサムです。 それらは救われたヘッダーにコピーされます。
- If the P bit is set in the change mask, the TCP PUSH bit is set in
the saved header. Otherwise the PUSH bit is cleared.
- Pビットが変化マスクに設定されるなら、TCP PUSHビットは救われたヘッダーに設定されます。 さもなければ、PUSHビットはきれいにされます。
----------------------------
24. State indices follow the C language convention and run from 0 to N
- 1, where 0 < N <= 256 is the number of available state slots.
25. As with the compressor, the code can be structured so no copies are
done and all modifications are done in-place. However, since the output
packet can be larger than the input packet, 128 bytes of free space must
be left at the front of the input packet buffer to allow room to prepend
the TCP/IP header.
---------------------------- 24. 州のインデックスリストは、N--1へC言語コンベンションに続いて、0から走ります。そこでは、0<N<=256が利用可能な州のスロットの数です。 25. コンプレッサーなら、コードは構造化されて、したがって、全くコピーしないで、適所ですべての変更をするということであるかもしれません。 しかしながら、出力パケットが入力パケットより大きい場合があるので、入力パケットバッファの前部にTCP/IPヘッダーのprependに余地を許容するのを128バイトの空きスペースを残さなければなりません。
Jacobson [Page 13] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[13ページ]RFC1144
- If the low order four bits (S, A, W and U) of the change mask are
all set (the `unidirectional data' special case), the amount of user
data in the last packet is calculated by subtracting the TCP and IP
header lengths from the IP total length in the saved header. That
amount is then added to the TCP sequence number in the saved header.
- 安値が変化マスクの4ビット(S、A、W、およびU)を配置するなら、すべてのセット('単方向のデータ'特別なケース)、パケットが計算される最終のIPからTCPとIPヘッダ長を引き算する利用者データの量は救われたヘッダーの全長ですか? そして、その量は救われたヘッダーでTCP一連番号に加えられます。
- If S, W and U are set and A is clear (the `terminal traffic' special
case), the amount of user data in the last packet is calculated and
added to both the TCP sequence number and ack fields in the saved
header.
- S、W、およびUが設定されて、Aが明確であるなら('端末の交通'特別なケース)、最後のパケットの利用者データの量は、救われたヘッダーでTCP一連番号とack分野の両方に計算されて、加えられます。
- Otherwise, the change mask bits are interpreted individually in the
order that the compressor set them:
- さもなければ、変化マスク・ビットがコンプレッサーが設定したオーダーで個別に解釈される、それら:
- If the U bit is set, the TCP URG bit is set in the saved header
and the next byte(s) of the incoming packet are decoded and
stuffed into the TCP Urgent Pointer. If the U bit is clear, the
TCP URG bit is cleared.
- Uビットが設定されるなら、TCP URGビットが救われたヘッダーに設定されて、入って来るパケットの次のバイトは、TCP Urgent Pointerに解読されて、詰められます。 Uビットが明確であるなら、TCP URGビットはきれいにされます。
- If the W bit is set, the next byte(s) of the incoming packet are
decoded and added to the TCP window field of the saved header.
- Wビットが設定されるなら、入って来るパケットの次のバイトは、救われたヘッダーのTCP窓の分野に解読されて、加えられます。
- If the A bit is set, the next byte(s) of the incoming packet are
decoded and added to the TCP ack field of the saved header.
- Aビットが設定されるなら、入って来るパケットの次のバイトは、救われたヘッダーのTCP ack分野に解読されて、加えられます。
- If the S bit is set, the next byte(s) of the incoming packet are
decoded and added to the TCP sequence number field of the saved
header.
- Sビットが設定されるなら、入って来るパケットの次のバイトは、救われたヘッダーのTCP一連番号分野に解読されて、加えられます。
- If the I bit is set in the change mask, the next byte(s) of the
incoming packet are decoded and added to the IP ID field of the
saved packet. Otherwise, one is added to the IP ID.
- Iビットが変化マスクに設定されるなら、入って来るパケットの次のバイトは、救われたパケットのIP ID分野に解読されて、加えられます。 さもなければ、1つはIP IDに加えられます。
At this point, all the header information from the incoming packet has been consumed and only data remains. The length of the remaining data is added to the length of the saved IP and TCP headers and the result is put into the saved IP total length field. The saved IP header is now up to date so its checksum is recalculated and stored in the IP checksum field. Finally, an output datagram consisting of the saved header concatenated with the remaining incoming data is constructed and returned.
ここに、入って来るパケットからのすべてのヘッダー情報が消費されました、そして、データだけが残っています。 救われたIPとTCPヘッダーの長さに残っているデータの長さを加えます、そして、救われたIP全長分野に結果を入れます。 救われたIPヘッダーは、現在、チェックサムがIPチェックサム分野に再計算されて、格納されて、日付を入れるために起きています。 最終的に、残っている受信データで連結された救われたヘッダーから成る出力データグラムを、組み立てて、返します。
4 Error handling
4エラー処理
4.1 Error detection
4.1 誤り検出
In the author's experience, dialup connections are particularly prone to data errors. These errors interact with compression in two different ways:
Jacobson [Page 14] RFC 1144 Compressing TCP/IP Headers February 1990
First is the local effect of an error in a compressed packet. All error detection is based on redundancy yet compression has squeezed out almost all the redundancy in the TCP and IP headers. In other words, the decompressor will happily turn random line noise into a perfectly valid TCP/IP packet./26/ One could rely on the TCP checksum to detect corrupted compressed packets but, unfortunately, some rather likely errors will not be detected. For example, the TCP checksum will often not detect two single bit errors separated by 16 bits. For a V.32 modem signalling at 2400 baud with 4 bits/baud, any line hit lasting longer than 400us. would corrupt 16 bits. According to [2], residential phone line hits of up to 2ms. are likely.
The correct way to deal with this problem is to provide for error detection at the framing level. Since the framing (at least in theory) can be tailored to the characteristics of a particular link, the detection can be as light or heavy-weight as appropriate for that link./27/ Since packet error detection is done at the framing level, the decompressor simply assumes that it will get an indication that the current packet was received with errors. (The decompressor always ignores (discards) a packet with errors. However, the indication is needed to prevent the error being propagated --- see below.)
The `discard erroneous packets' policy gives rise to the second interaction of errors and compression. Consider the following conversation:
+-------------------------------------------+
|original | sent |received |reconstructed |
+---------+--------+---------+--------------+
| 1: A | 1: A | 1: A | 1: A |
| 2: BC | 1, BC | 1, BC | 2: BC |
| 4: DE | 2, DE | --- | --- |
| 6: F | 2, F | 2, F | 4: F |
| 7: GH | 1, GH | 1, GH | 5: GH |
+-------------------------------------------+
(Each entry above has the form `starting sequence number:data sent' or `?sequence number change,data sent'.) The first thing sent is an uncompressed packet, followed by four compressed packets. The third packet picks up an error and is discarded. To reconstruct the fourth packet, the receiver applies the sequence number change from incoming compressed packet to the sequence number of the last correctly received
----------------------------
26. modulo the TCP checksum.
27. While appropriate error detection is link dependent, the CCITT CRC
used in [9] strikes an excellent balance between ease of computation and
robust error detection for a large variety of links, particularly at the
relatively small packet sizes needed for good interactive response.
Thus, for the sake of interoperability, the framing in [9] should be
used unless there is a truly compelling reason to do otherwise.
Jacobson [Page 15] RFC 1144 Compressing TCP/IP Headers February 1990
packet, packet two, and generates an incorrect sequence number for packet four. After the error, all reconstructed packets' sequence numbers will be in error, shifted down by the amount of data in the missing packet./28/
Without some sort of check, the preceding error would result in the receiver invisibly losing two bytes from the middle of the transfer (since the decompressor regenerates sequence numbers, the packets containing F and GH arrive at the receiver's TCP with exactly the sequence numbers they would have had if the DE packet had never existed). Although some TCP conversations can survive missing data/29/ it is not a practice to be encouraged. Fortunately the TCP checksum, since it is a simple sum of the packet contents including the sequence numbers, detects 100% of these errors. E.g., the receiver's computed checksum for the last two packets above always differs from the packet checksum by two.
Unfortunately, there is a way for the TCP checksum protection described above to fail if the changes in an incoming compressed packet are applied to the wrong conversation: Consider two active conversations C1 and C2 and a packet from C1 followed by two packets from C2. Since the connection number doesn't change, it's omitted from the second C2 packet. But, if the first C2 packet is received with a CRC error, the second C2 packet will mistakenly be considered the next packet in C1. Since the C2 checksum is a random number with respect to the C1 sequence numbers, there is at least a 2^-16 probability that this packet will be accepted by the C1 TCP receiver./30/ To prevent this, after a CRC error indication from the framer the receiver discards packets until it receives either a COMPRESSED_TCP packet with the C bit set or an UNCOMPRESSED_TCP packet. I.e., packets are discarded until the receiver gets an explicit connection number.
To summarize this section, there are two different types of errors: per-packet corruption and per-conversation loss-of-sync. The first type is detected at the decompressor from a link-level CRC error, the second at the TCP receiver from a (guaranteed) invalid TCP checksum. The combination of these two independent mechanisms ensures that erroneous packets are discarded.
----------------------------
28. This is an example of a generic problem with differential or delta
encodings known as `losing DC'.
29. Many system managers claim that holes in an NNTP stream are more
valuable than the data.
30. With worst-case traffic, this probability translates to one
undetected error every three hours over a 9600 baud line with a 30%
error rate).
Jacobson [Page 16] RFC 1144 Compressing TCP/IP Headers February 1990
4.2 Error recovery
The previous section noted that after a CRC error the decompressor will introduce TCP checksum errors in every uncompressed packet. Although the checksum errors prevent data stream corruption, the TCP conversation won't be terribly useful until the decompressor again generates valid packets. How can this be forced to happen?
The decompressor generates invalid packets because its state (the saved `last packet header') disagrees with the compressor's state. An UNCOMPRESSED_TCP packet will correct the decompressor's state. Thus error recovery amounts to forcing an uncompressed packet out of the compressor whenever the decompressor is (or might be) confused.
The first thought is to take advantage of the full duplex communication link and have the decompressor send something to the compressor requesting an uncompressed packet. This is clearly undesirable since it constrains the topology more than the minimum suggested in sec. 2 and requires that a great deal of protocol be added to both the decompressor and compressor. A little thought convinces one that this alternative is not only undesirable, it simply won't work: Compressed packets are small and it's likely that a line hit will so completely obliterate one that the decompressor will get nothing at all. Thus packets are reconstructed incorrectly (because of the missing compressed packet) but only the TCP end points, not the decompressor, know that the packets are incorrect.
But the TCP end points know about the error and TCP is a reliable protocol designed to run over unreliable media. This means the end points must eventually take some sort of error recovery action and there's an obvious trigger for the compressor to resync the decompressor: send uncompressed packets whenever TCP is doing error recovery.
But how does the compressor recognize TCP error recovery? Consider the schematic TCP data transfer of fig. 6. The confused decompressor is in the forward (data transfer) half of the TCP conversation. The receiving TCP discards packets rather than acking them (because of the checksum errors), the sending TCP eventually times out and retransmits a packet, and the forward path compressor finds that the difference between the sequence number in the retransmitted packet and the sequence number in the last packet seen is either negative (if there were multiple packets in transit) or zero (one packet in transit). The first case is detected in the compression step that computes sequence number differences. The second case is detected in the step that checks the `special case' encodings but needs an additional test: It's fairly common for an interactive conversation to send a dataless ack packet followed by a data packet. The ack and data packet will have the same sequence numbers yet the data packet is not a retransmission. To prevent sending an unnecessary uncompressed packet, the length of the previous packet should be checked and, if it contained data, a zero
Jacobson [Page 17] RFC 1144 Compressing TCP/IP Headers February 1990
sequence number change must indicate a retransmission.
A confused decompressor in the reverse (ack) half of the conversation is as easy to detect (fig. 7): The sending TCP discards acks (because they contain checksum errors), eventually times out, then retransmits some packet. The receiving TCP thus gets a duplicate packet and must generate an ack for the next expected sequence number[11, p. 69]. This ack will be a duplicate of the last ack the receiver generated so the reverse-path compressor will find no ack, seq number, window or urg change. If this happens for a packet that contains no data, the compressor assumes it is a duplicate ack sent in response to a retransmit and sends an UNCOMPRESSED_TCP packet./31/
5 Configurable parameters and tuning
5.1 Compression configuration
There are two configuration parameters associated with header compression: Whether or not compressed packets should be sent on a particular line and, if so, how many state slots (saved packet headers) to reserve. There is also one link-level configuration parameter, the maximum packet size or MTU, and one front-end configuration parameter, data compression, that interact with header compression. Compression configuration is discussed in this section. MTU and data compression are discussed in the next two sections.
There are some hosts (e.g., low end PCs) which may not have enough processor or memory resources to implement this compression. There are also rare link or application characteristics that make header compression unnecessary or undesirable. And there are many existing SLIP links that do not currently use this style of header compression. For the sake of interoperability, serial line IP drivers that allow header compression should include some sort of user configurable flag to disable compression (see appendix B.2)./32/
If compression is enabled, the compressor must be sure to never send a connection id (state index) that will be dropped by the decompressor. E.g., a black hole is created if the decompressor has sixteen slots and
----------------------------
31. The packet could be a zero-window probe rather than a retransmitted
ack but window probes should be infrequent and it does no harm to send
them uncompressed.
32. The PPP protocol in [9] allows the end points to negotiate
compression so there is no interoperability problem. However, there
should still be a provision for the system manager at each end to
control whether compression is negotiated on or off. And, obviously,
compression should default to `off' until it has been negotiated `on'.
Jacobson [Page 18] RFC 1144 Compressing TCP/IP Headers February 1990
the compressor uses twenty./33/ Also, if the compressor is allowed too few slots, the LRU allocator will thrash and most packets will be sent as UNCOMPRESSED_TCP. Too many slots and memory is wasted.
Experimenting with different sizes over the past year, the author has found that eight slots will thrash (i.e., the performance degradation is noticeable) when many windows on a multi-window workstation are simultaneously in use or the workstation is being used as a gateway for three or more other machines. Sixteen slots were never observed to thrash. (This may simply be because a 9600 bps line split more than 16 ways is already so overloaded that the additional degradation from round-robbining slots is negligible.)
Each slot must be large enough to hold a maximum length TCP/IP header of 128 bytes/34/ so 16 slots occupy 2KB of memory. In these days of 4 Mbit RAM chips, 2KB seems so little memory that the author recommends the following configuration rules:
(1) If the framing protocol does not allow negotiation, the compressor
and decompressor should provide sixteen slots, zero through fifteen.
(2) If the framing protocol allows negotiation, any mutually agreeable
number of slots from 1 to 256 should be negotiable./35/ If number
of slots is not negotiated, or until it is negotiated, both sides
should assume sixteen.
(3) If you have complete control of all the machines at both ends of
every link and none of them will ever be used to talk to machines
outside of your control, you are free to configure them however you
please, ignoring the above. However, when your little eastern-block
dictatorship collapses (as they all eventually seem to), be aware
that a large, vocal, and not particularly forgiving Internet
community will take great delight in pointing out to anyone willing
----------------------------
33. Strictly speaking, there's no reason why the connection id should
be treated as an array index. If the decompressor's states were kept in
a hash table or other associative structure, the connection id would be
a key, not an index, and performance with too few decompressor slots
would only degrade enormously rather than failing altogether. However,
an associative structure is substantially more costly in code and cpu
time and, given the small per-slot cost (128 bytes of memory), it seems
reasonable to design for slot arrays at the decompressor and some
(possibly implicit) communication of the array size.
34. The maximum header length, fixed by the protocol design, is 64
bytes of IP and 64 bytes of TCP.
35. Allowing only one slot may make the compressor code more complex.
Implementations should avoid offering one slot if possible and
compressor implementations may disable compression if only one slot is
negotiated.
---------------------------- 33. 厳密に言うと、接続イドが配列指数として扱われるべきである理由が全くありません。 減圧装置の州がハッシュ表か他の結合しやすい構造に維持されるなら、接続イドがインデックスではなく、キーであり、あまりにわずかな減圧装置スロットがある性能は全体で失敗するよりむしろ途方もないほど下がるだけでしょう。 しかしながら、コードとcpu timeでは結合しやすい構造は実質的により高価です、そして、1スロットあたりのわずかな費用(128バイトのメモリ)を考えて、それは減圧装置とアレイサイズの何らかの(ことによると暗黙)のコミュニケーションでスロットアレイに設計するのが妥当に思えます。 34. プロトコルデザインによって修理された最大のヘッダ長は、IPの64バイトと64バイトのTCPです。 35. 1つのスロットだけを許容するのに、コンプレッサーコードは、より複雑になるかもしれません。 実現は、できれば、1つのスロットを提供するのを避けるべきです、そして、1つのスロットだけが交渉されるなら、コンプレッサー実現は圧縮を無効にするかもしれません。
Jacobson [Page 19] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[19ページ]RFC1144
to listen that you have misconfigured your systems and are not
interoperable.
あなたは、それを聴くために、あなたのシステムをmisconfiguredして、共同利用できません。
5.2 Choosing a maximum transmission unit
5.2 マキシマム・トランスミッション・ユニットを選ぶこと。
From the discussion in sec. 2, it seems desirable to limit the maximum packet size (MTU) on any line where there might be interactive traffic and multiple active connections (to maintain good interactive response between the different connections competing for the line). The obvious question is `how much does this hurt throughput?' It doesn't.
秒の議論から 2 対話的な通信があるかもしれないどんな線の上の最大のパケットサイズ(MTU)と複数の活発な接続(線を競争する異なった接続の間の良い対話的な応答を維持する)を制限するのは望ましく思えます。 明白な疑問はItがそうしない'いくらがこの痛んでいるスループットをしますか?'です。
Figure 8 shows how user data throughput/36/ scales with MTU with (solid line) and without (dashed line) header compression. The dotted lines show what MTU corresponds to a 200 ms packet time at 2400, 9600 and 19,200 bps. Note that with header compression even a 2400 bps line can be responsive yet have reasonable throughput (83%)./37/
エイト環は利用者データthroughput/36/がMTUと共に(実線)と(線を投げつけます)ヘッダー圧縮なしでどう比例するかを示しています。 点線は、どんなMTUが2400、9600、および1万9200ビーピーエスで200msパケット時間に対応するかを示します。 2400年のビーピーエス線さえヘッダー圧縮によって、敏感ですが、妥当なスループット(83%)/37/を持つことができることに注意してください。
Figure 9 shows how line efficiency scales with increasing line speed, assuming that a 200ms. MTU is always chosen./38/ The knee in the performance curve is around 2400 bps. Below this, efficiency is sensitive to small changes in speed (or MTU since the two are linearly related) and good efficiency comes at the expense of good response. Above 2400bps the curve is flat and efficiency is relatively independent of speed or MTU. In other words, it is possible to have both good response and high line efficiency.
図9は線効率が増加するライン・スピードでどう比例するかを示していて. /38/がいつも200ms. MTUに選ばれていると仮定して、性能曲線のひざは2400年頃のビーピーエスです。 これの下では、効率は速度でばら銭に敏感です、そして、(2が直線的であるので、MTUは関係しました)良い効率は良い応答を犠牲にして来ます。 2400年のビーピーエスを超えて、カーブは平坦です、そして、効率は速度かMTUから比較的独立しています。 言い換えれば、良い応答と高い線効率の両方を持っているのは可能です。
To illustrate, note that for a 9600 bps line with header compression there is essentially no benefit in increasing the MTU beyond 200 bytes: If the MTU is increased to 576, the average delay increases by 188% while throughput only improves by 3% (from 96 to 99%).
例証するには、ヘッダー圧縮がそこにある9600年のビーピーエス線へのそれがMTUを200バイトを超えたところまで増加させることにおいて本質的には利益でないことに注意してください: MTUが576まで増加するなら、スループットは3%(96〜99%)向上するだけですが、平均した遅れは188%増加します。
----------------------------
36. The vertical axis is in percent of line speed. E.g., `95' means
that 95% of the line bandwidth is going to user data or, in other words,
the user would see a data transfer rate of 9120 bps on a 9600 bps line.
Four bytes of link-level (framer) encapsulation in addition to the
TCP/IP or compressed header were included when calculating the relative
throughput. The 200 ms packet times were computed assuming an
asynchronous line using 10 bits per character (8 data bits, 1 start, 1
stop, no parity).
37. However, the 40 byte TCP MSS required for a 2400 bps line might
stress-test your TCP implementation.
38. For a typical async line, a 200ms. MTU is simply .02 times the line
speed in bits per second.
---------------------------- 36. パーセントのライン・スピードには縦軸があります。 '例えば、95年'が、線帯域幅の95%が利用者データに行くことを意味するか、または言い換えれば、ユーザは9600年のビーピーエス線の上で9120年のビーピーエスのデータ転送速度を見るでしょう。 相対的なスループットについて計算するとき、TCP/IPか圧縮されたヘッダーに加えた4バイトのリンク・レベル(喧嘩早い人)カプセル化は含まれていました。 200のmsパケット回数が、キャラクタ(8データ・ビット、1つの始め、1つの停止、同等がない)あたり10ビットを使用することで非同期な線を帯びながら、計算されました。 37. しかしながら、TCP MSSが2400年のビーピーエス線に必要とした40バイトはあなたのTCP実現を圧力でテストするかもしれません。 38. 典型的なasync線に、200ms. MTUは単にbpsにおけるライン・スピードの.02倍です。
Jacobson [Page 20] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[20ページ]RFC1144
5.3 Interaction with data compression
5.3 データ圧縮との相互作用
Since the early 1980's, fast, effective, data compression algorithms such as Lempel-Ziv[7] and programs that embody them, such as the compress program shipped with Berkeley Unix, have become widely available. When using low speed or long haul lines, it has become common practice to compress data before sending it. For dialup connections, this compression is often done in the modems, independent of the communicating hosts. Some interesting issues would seem to be: (1) Given a good data compressor, is there any need for header compression? (2) Does header compression interact with data compression? (3) Should data be compressed before or after header compression?/39/
以来、1980年代(Lempel-Ziv[7]などの速くて、効果的なデータ圧縮アルゴリズムとそれらを具体化するバークレーUnixと共に出荷された湿布プログラムなどのプログラム)前半は広く利用可能になっています。 低速か長期線を使用するとき、それを送る前にデータを圧縮するのは一般的な習慣になりました。 電話での接続において、交信しているホストの如何にかかわらずモデムでこの圧縮をしばしばします。 いくつかのおもしろい問題がである:思えるでしょう。 (1) 良いデータコンプレッサーを考えて、何かヘッダー圧縮の必要がありますか? (2) ヘッダー圧縮はデータ圧縮と対話しますか? (3) データはヘッダー圧縮?/39/の前または後に圧縮されるべきですか?
To investigate (1), Lempel-Ziv compression was done on a trace of 446 TCP/IP packets taken from the user's side of a typical telnet conversation. Since the packets resulted from typing, almost all contained only one data byte plus 40 bytes of header. I.e., the test essentially measured L-Z compression of TCP/IP headers. The compression ratio (the ratio of uncompressed to compressed data) was 2.6. In other words, the average header was reduced from 40 to 16 bytes. While this is good compression, it is far from the 5 bytes of header needed for good interactive response and far from the 3 bytes of header (a compression ratio of 13.3) that header compression yielded on the same packet trace.
(1) 調査するために、ユーザの典型的なtelnetの会話の側から抜粋される446のTCP/IPパケットの跡でLempel-Ziv圧縮をしました。 パケットがタイプから生じたので、ほとんどすべてがヘッダーの1データ・バイトと40バイトだけを含みました。 すなわち、テストは本質的にはTCP/IPヘッダーのL-Z圧縮を測定しました。 圧縮比(解凍される対圧縮されたデータの比率)は2.6でした。 言い換えれば、普通のヘッダーは40〜16バイト減少しました。 これは良い圧縮ですが、それは、良い対話的な応答に必要であるヘッダーの5バイトから遠くて、ヘッダー圧縮が同じパケット跡でもたらしたヘッダー(13.3の圧縮比)の3バイトから遠いです。
The second and third questions are more complex. To investigate them, several packet traces from FTP file transfers were analyzed/40/ with and without header compression and with and without L-Z compression. The L-Z compression was tried at two places in the outgoing data stream (fig. 10): (1) just before the data was handed to TCP for encapsulation (simulating compression done at the `application' level) and (2) after the data was encapsulated (simulating compression done in the modem). Table 1 summarizes the results for a 78,776 byte ASCII text file (the Unix csh.1 manual entry)/41/ transferred using the guidelines of the previous section (256 byte MTU or 216 byte MSS; 368 packets total). Compression ratios for the following ten tests are shown (reading left to right and top to bottom):
2番目と3番目の質問は、より複雑です。 それらを調査するために、FTPファイル転送からのいくつかのパケット跡がヘッダー圧縮のあるなしにかかわらずL-Z圧縮のあるなしにかかわらずanalyzed/40/でした。 L-Z圧縮は2つの場所で発信データストリーム(図10)で試みられました: (1) ちょうど以前、要約された(モデムで行われた圧縮をシミュレートして)後にデータはカプセル化('アプリケーション'レベルで行われた圧縮をシミュレートする)と(2)のためにTCPに手渡されました。 テーブル1は前項(256バイトのMTUか216バイトMSS; 368パケット合計)のガイドラインを使用することで移された7万8776バイトのASCIIテキスト・ファイル(Unix csh.1スライド式入力装置)/41/のために結果をまとめます。 以下の10のテストのための圧縮比は示されます(左では、底をつける右と先端に読んで聞かせます):
----------------------------
39. The answers, for those who wish to skip the remainder of this
section, are `yes', `no' and `either', respectively.
40. The data volume from user side of a telnet is too small to benefit
from data compression and can be adversely affected by the delay most
compression algorithms (necessarily) add. The statistics and volume of
the computer side of a telnet are similar to an (ASCII) FTP so these
results should apply to either.
41. The ten experiments described were each done on ten ASCII files
(four long e-mail messages, three Unix C source files and three Unix
manual entries). The results were remarkably similar for different
files and the general conclusions reached below apply to all ten files.
---------------------------- 39. それぞれ答えこのセクションの残りをスキップしたがっている人が'はい'であるので'いいえ'と'どちらか'。 40. telnetのユーザ側からのデータボリュームは、データ圧縮の利益を得ることができないくらい小さく、ほとんどの圧縮アルゴリズムが(必ず)加える遅れで悪影響を受けることができます。 telnetのコンピュータ側の統計とボリュームが(ASCII)FTPと同様であるので、これらの結果はどちらかに適用されるべきです。 41. 10個のASCIIファイル(4つの長いメールメッセージ、3つのUnix Cソースファイル、および3つのUnixスライド式入力装置)でそれぞれ説明された10の実験をしました。 異なったファイルに、結果は著しく同様でした、そして、以下に達した一般的な結論はすべての10個のファイルに適用されます。
Jacobson [Page 21] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[21ページ]RFC1144
- data file (no compression or encapsulation)
- データファイル(圧縮でないカプセル化がありません)
- data -> L--Z compressor
- データ->L--Zコンプレッサー
- data -> TCP/IP encapsulation
- データ->TCP/IPカプセル化
- data -> L--Z -> TCP/IP
- データ->L--Z->TCP/IP
- data -> TCP/IP -> L--Z
- データ->TCP/IP->L--Z
- data -> L--Z -> TCP/IP -> L--Z
- データ->L--Z->TCP/IP->L--Z
- data -> TCP/IP -> Hdr. Compress.
- データ->TCP/IP->Hdr。 圧縮します。
- data -> L--Z -> TCP/IP -> Hdr. Compress.
- データ->L--Z->TCP/IP->Hdr。 圧縮します。
- data -> TCP/IP -> Hdr. Compress. -> L--Z
- データ->TCP/IP->Hdr。 圧縮します。 ->L--Z
- data -> L--Z -> TCP/IP -> Hdr. Compress. -> L--Z
- データ->L--Z->TCP/IP->Hdr。 圧縮します。 ->L--Z
+-----------------------------------------------------+
| | No data | L--Z | L--Z | L--Z |
| |compress. |on data |on wire | on both |
+--------------+----------+--------+--------+---------+
| Raw Data | 1.00 | 2.44 | ---- | ---- |
| + TCP Encap. | 0.83 | 2.03 | 1.97 | 1.58 |
| w/Hdr Comp. | 0.98 | 2.39 | 2.26 | 1.66 |
+-----------------------------------------------------+
+-----------------------------------------------------+ | | データがありません。| L--Z| L--Z| L--Z| | |圧縮します。 |データに関して|ワイヤに関して| 両方に関して| +--------------+----------+--------+--------+---------+ | 生データ| 1.00 | 2.44 | ---- | ---- | | + TCP Encap。 | 0.83 | 2.03 | 1.97 | 1.58 | | Hdrコンピュータで。 | 0.98 | 2.39 | 2.26 | 1.66 | +-----------------------------------------------------+
Table 1: ASCII Text File Compression Ratios
テーブル1: ASCIIテキストファイル圧縮比
The first column of table 1 says the data expands by 19% (`compresses' by .83) when encapsulated in TCP/IP and by 2% when encapsulated in header compressed TCP/IP./42/ The first row says L--Z compression is quite effective on this data, shrinking it to less than half its original size. Column four illustrates the well-known fact that it is a mistake to L--Z compress already compressed data. The interesting information is in rows two and three of columns two and three. These columns say that the benefit of data compression overwhelms the cost of encapsulation, even for straight TCP/IP. They also say that it is slightly better to compress the data before encapsulating it rather than compressing at the framing/modem level. The differences however are
2%、ヘッダーの圧縮されたTCP/IP/42/で要約されるとファースト・ローはLを言います--最初のコラムのテーブル1は、TCP/IPで要約されるとデータが19%(.83の'湿布')広げると言います、そして、それを原寸の半分未満まで縮めて、Z圧縮はこのデータでかなり効果的です。 コラムfourはそれが誤りであるという周知の事実をLに例証します--Z湿布は既にデータを圧縮しました。 興味ある情報がコラム2とthreeの列2とthreeにあります。 これらのコラムは、データ圧縮の利益がまっすぐなTCP/IPのためにさえカプセル化の費用を圧倒すると言います。 また、彼らは、縁どり/モデムレベルにおける圧縮よりむしろそれを要約する前にデータをわずかに圧縮しているほうがよいと言います。 しかしながら、違いはそうです。
----------------------------
42. This is what would be expected from the relative header sizes:
256/216 for TCP/IP and 219/216 for header compression.
---------------------------- 42. これは相対的なヘッダーサイズから予想されることです: TCP/IPのための256/216とヘッダー圧縮のための219/216。
Jacobson [Page 22] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[22ページ]RFC1144
small --- 3% and 6%, respectively, for the TCP/IP and header compressed encapsulations./43/
小さい--- TCP/IPとヘッダーのためにそれぞれ3%と6%圧縮されたカプセル化. /43/
Table 2 shows the same experiment for a 122,880 byte binary file (the Sun-3 ps executable). Although the raw data doesn't compress nearly as well, the results are qualitatively the same as for the ASCII data. The one significant change is in row two: It is about 3% better to compress the data in the modem rather than at the source if doing TCP/IP encapsulation (apparently, Sun binaries and TCP/IP headers have similar statistics). However, with header compression (row three) the results were similar to the ASCII data --- it's about 3% worse to compress at the modem rather than the source./44/
テーブル2は12万2880バイトのバイナリーファイル(実行可能なSun-3ps)のために同じ実験を示しています。 生データは同じではありませんが、ほとんど同じくらい良い湿布、結果はASCIIデータのように質的に同じです。 1回の著しい変化が列twoにあります: TCP/IPカプセル化をするなら、ソースでというよりむしろモデムでデータをおよそ3%圧縮しているほうがよいです(明らかに、Sun2種混合毒ガスとTCP/IPヘッダーには、同様の統計があります)。 しかしながら、ヘッダー圧縮(列three)について、結果はASCIIデータと同様でした。--- それは. ソース/44/よりむしろモデムで圧縮するためにおよそ3%さらに悪いです。
+-----------------------------------------------------+
| | No data | L--Z | L--Z | L--Z |
| |compress. |on data |on wire | on both |
+--------------+----------+--------+--------+---------+
| Raw Data | 1.00 | 1.72 | ---- | ---- |
| + TCP Encap. | 0.83 | 1.43 | 1.48 | 1.21 |
| w/Hdr Comp. | 0.98 | 1.69 | 1.64 | 1.28 |
+-----------------------------------------------------+
+-----------------------------------------------------+ | | データがありません。| L--Z| L--Z| L--Z| | |圧縮します。 |データに関して|ワイヤに関して| 両方に関して| +--------------+----------+--------+--------+---------+ | 生データ| 1.00 | 1.72 | ---- | ---- | | + TCP Encap。 | 0.83 | 1.43 | 1.48 | 1.21 | | Hdrコンピュータで。 | 0.98 | 1.69 | 1.64 | 1.28 | +-----------------------------------------------------+
Table 2: Binary File Compression Ratios
テーブル2: バイナリーファイル圧縮比
6 Performance measurements
6 パフォーマンス測定
An implementation goal of compression code was to arrive at something simple enough to run at ISDN speeds (64Kbps) on a typical 1989
圧縮コードの実現目標は典型的な1989でISDN速度で走るほど何か(64Kbps)簡単なものに到着することでした。
----------------------------
43. The differences are due to the wildly different byte patterns of
TCP/IP datagrams and ASCII text. Any compression scheme with an
underlying, Markov source model, such as Lempel-Ziv, will do worse when
radically different sources are interleaved. If the relative
proportions of the two sources are changed, i.e., the MTU is increased,
the performance difference between the two compressor locations
decreases. However, the rate of decrease is very slow --- increasing
the MTU by 400% (256 to 1024) only changed the difference between the
data and modem L--Z choices from 2.5% to 1.3%.
44. There are other good reasons to compress at the source: Far fewer
packets have to be encapsulated and far fewer characters have to be sent
to the modem. The author suspects that the `compress data in the modem'
alternative should be avoided except when faced with an intractable,
vendor proprietary operating system.
---------------------------- 43. 違いはTCP/IPデータグラムとASCIIテキストのむやみやたらに異なったバイトパターンのためです。 根本的に異なったソースがはさみ込まれるとき、Lempel-Zivなどの基本的なマルコフ情報源モデルがあるどんな圧縮技術もよりひどくするでしょう。 2つのソースの相対的比率を変えるなら、すなわち、MTUは増加しています、2回のコンプレッサー位置の減少の性能差。 しかしながら、減少の速度は非常に遅いです。--- MTUを400%(256〜1024)増加させると、データとモデムLの違いは変化しただけです--2.5%から1.3%までのZ選択。 44. ソースで圧縮する他のもっともな理由があります: はるかに少ないパケットをカプセルに入れらなければなりません、そして、はるかに少ないキャラクタをモデムに送らなければなりません。 作者は、手に負えなくて、業者独占であるオペレーティングシステムが直面されているときに時を除いて、'モデムの湿布データ'代替手段が避けられるべきであると疑います。
Jacobson [Page 23] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[23ページ]RFC1144
+---------------------------------------+
| | Average per-packet |
| Machine | processing time (us.) |
| | |
| | Compress | Decompress |
+---------------+----------+------------+
|Sparcstation-1 | 24 | 18 |
| Sun 4/260 | 46 | 20 |
| Sun 3/60 | 90 | 90 |
| Sun 3/50 | 130 | 150 |
| HP9000/370 | 42 | 33 |
| HP9000/360 | 68 | 70 |
| DEC 3100 | 27 | 25 |
| Vax 780 | 430 | 300 |
| Vax 750 | 800 | 500 |
| CCI Tahoe | 110 | 140 |
+---------------------------------------+
+---------------------------------------+ | | 平均したパケット| | マシン| 処理時間(私たち) | | | | | | 湿布| 減圧してください。| +---------------+----------+------------+ |Sparcstation-1| 24 | 18 | | Sun4/260| 46 | 20 | | Sun3/60| 90 | 90 | | Sun3/50| 130 | 150 | | HP9000/370| 42 | 33 | | HP9000/360| 68 | 70 | | 3100年12月| 27 | 25 | | バックス780| 430 | 300 | | バックス750| 800 | 500 | | CCIタホ| 110 | 140 | +---------------------------------------+
Table 3: Compression code timings
テーブル3: 圧縮コードタイミング
workstation. 64Kbps is a byte every 122us so 120us was (arbitrarily) picked as the target compression/decompression time./45/
ワークステーション。 64Kbpsによる120usがあって、1バイト、あらゆる122usが目標圧縮/減圧として(任意に)時間/45/を選んだということです。
As part of the compression code development, a trace-driven exerciser was developed. This was initially used to compare different compression protocol choices then later to test the code on different computer architectures and do regression tests after performance `improvements'. A small modification of this test program resulted in a useful measurement tool./46/ Table 3 shows the result of timing the compression code on all the machines available to the author (times were measured using a mixed telnet/ftp traffic trace). With the exception of the Vax architectures, which suffer from (a) having bytes in the wrong order and (b) a lousy compiler (Unix pcc), all machines essentially met the 120us goal.
圧縮コード開発の一部として、跡の駆動の馬を運動させる馬丁は開発されました。 これは初めは、後でその時異なったコンピュータ・アーキテクチャでコードをテストして、性能'改良'の後に回帰テストをするために異なった圧縮プロトコル選択を比較するのにおいて使用されていました。 このテストプログラムの小さい変更は役に立つ測定ツールをもたらしました。/46/テーブル3は作者にとって、利用可能なすべてのマシンの上に圧縮コードを調節するという結果を示しています(回は混ぜられたtelnet/ftp交通跡を使用することで測定されました)。 バックス構造を除いて、すべてのマシンが本質的には120us目標を達成しました。(構造は(a) 間違った順序でバイトを持って、(b) ひどいコンパイラ(unix pcc)に苦しみます)。
----------------------------
45. The time choice wasn't completely arbitrary: Decompression is
often done during the inter-frame `flag' character time so, on systems
where the decompression is done at the same priority level as the serial
line input interrupt, times much longer than a character time would
result in receiver overruns. And, with the current average of five byte
frames (on the wire, including both compressed header and framing), a
compression/decompression that takes one byte time can use at most 20%
of the available time. This seems like a comfortable budget.
46. Both the test program and timer program are included in the
ftp-able package described in appendix A as files tester.c and timer.c.
---------------------------- 45. 時間選択は完全に任意であったというわけではありません: インターフレーム'旗'キャラクタ時間、しばしばそう減圧をします、システムで上減圧がシリアル・ライン入力割込みと同じ優先順位でされる、キャラクタ時間が受信機超過をもたらすだろうよりはるかに長い回。 そして、5バイトのフレーム(ワイヤの上に圧縮されたヘッダーと縁どりの両方を含んでいる)の現在の平均と共に、1バイトの時間がかかる圧縮/減圧は使用可能時間の20%を高々使用できます。 これは快適な予算のように見えます。 46. ともに、テストプログラムとタイマプログラムは付録Aでファイルのtester.cとtimer.cと説明されたftpできるパッケージに含まれています。
Jacobson [Page 24] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[24ページ]RFC1144
7 Acknowlegements
7 Acknowlegements
The author is grateful to the members of the Internet Engineering Task Force, chaired by Phill Gross, who provided encouragement and thoughtful review of this work. Several patient beta-testers, particularly Sam Leffler and Craig Leres, tracked down and fixed problems in the initial implementation. Cynthia Livingston and Craig Partridge carefully read and greatly improved an unending sequence of partial drafts of this document. And last but not least, Telebit modem corporation, particularly Mike Ballard, encouraged this work from its inception and has been an ongoing champion of serial line and dial-up IP.
The author is grateful to the members of the Internet Engineering Task Force, chaired by Phill Gross, who provided encouragement and thoughtful review of this work. Several patient beta-testers, particularly Sam Leffler and Craig Leres, tracked down and fixed problems in the initial implementation. Cynthia Livingston and Craig Partridge carefully read and greatly improved an unending sequence of partial drafts of this document. And last but not least, Telebit modem corporation, particularly Mike Ballard, encouraged this work from its inception and has been an ongoing champion of serial line and dial-up IP.
References
References
[1] Bingham, J. A. C. Theory and Practice of Modem Design. John Wiley
& Sons, 1988.
[1] Bingham, J. A. C. Theory and Practice of Modem Design. John Wiley & Sons, 1988.
[2] Carey, M. B., Chan, H.-T., Descloux, A., Ingle, J. F., and Park,
K. I. 1982/83 end office connection study: Analog voice and
voiceband data transmission performance characterization of the
public switched network. Bell System Technical Journal 63, 9 (Nov.
1984).
[2] Carey, M. B., Chan, H.-T., Descloux, A., Ingle, J. F., and Park, K. I. 1982/83 end office connection study: Analog voice and voiceband data transmission performance characterization of the public switched network. Bell System Technical Journal 63, 9 (Nov. 1984).
[3] Chiappa, N., 1988. Private communication.
[3] Chiappa, N., 1988. Private communication.
[4] Clark, D. D. The design philosophy of the DARPA Internet
protocols. In Proceedings of SIGCOMM '88 (Stanford, CA, Aug.
1988), ACM.
[4] Clark, D. D. The design philosophy of the DARPA Internet protocols. In Proceedings of SIGCOMM '88 (Stanford, CA, Aug. 1988), ACM.
[5] Farber, D. J., Delp, G. S., and Conte, T. M. A Thinwire Protocol
for connecting personal computers to the Internet. Arpanet Working
Group Requests for Comment, DDN Network Information Center, SRI
International, Menlo Park, CA, Sept. 1984. RFC-914.
[5] Farber, D. J., Delp, G. S., and Conte, T. M. A Thinwire Protocol for connecting personal computers to the Internet. Arpanet Working Group Requests for Comment, DDN Network Information Center, SRI International, Menlo Park, CA, Sept. 1984. RFC-914.
[6] Kent, C. A., and Mogul, J. Fragmentation considered harmful. In
Proceedings of SIGCOMM '87 (Aug. 1987), ACM.
[6] Kent, C. A., and Mogul, J. Fragmentation considered harmful. In Proceedings of SIGCOMM '87 (Aug. 1987), ACM.
[7] Lempel, A., and Ziv, J. Compression of individual sequences via
variable-rate encoding. IEEE Transactions on Information Theory
IT-24, 5 (June 1978).
[7] Lempel, A., and Ziv, J. Compression of individual sequences via variable-rate encoding. IEEE Transactions on Information Theory IT-24, 5 (June 1978).
[8] Nagle, J. Congestion Control in IP/TCP Internetworks. Arpanet
Working Group Requests for Comment, DDN Network Information Center,
SRI International, Menlo Park, CA, Jan. 1984. RFC-896.
[8] Nagle, J. Congestion Control in IP/TCP Internetworks. Arpanet Working Group Requests for Comment, DDN Network Information Center, SRI International, Menlo Park, CA, Jan. 1984. RFC-896.
[9] Perkins, D. Point-to-Point Protocol: A proposal for
multi-protocol transmission of datagrams over point-to-point links.
Arpanet Working Group Requests for Comment, DDN Network Information
Center, SRI International, Menlo Park, CA, Nov. 1989. RFC-1134.
[9] Perkins, D. Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over point-to-point links. Arpanet Working Group Requests for Comment, DDN Network Information Center, SRI International, Menlo Park, CA, Nov. 1989. RFC-1134.
Jacobson [Page 25] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 25] RFC 1144 Compressing TCP/IP Headers February 1990
[10] Postel, J., Ed. Internet Protocol Specification. SRI
International, Menlo Park, CA, Sept. 1981. RFC-791.
[10] Postel, J., Ed. Internet Protocol Specification. SRI International, Menlo Park, CA, Sept. 1981. RFC-791.
[11] Postel, J., Ed. Transmission Control Protocol Specification. SRI
International, Menlo Park, CA, Sept. 1981. RFC-793.
[11] Postel, J., Ed. Transmission Control Protocol Specification. SRI International, Menlo Park, CA, Sept. 1981. RFC-793.
[12] Romkey, J. A Nonstandard for Transmission of IP Datagrams Over
Serial Lines: Slip. Arpanet Working Group Requests for Comment,
DDN Network Information Center, SRI International, Menlo Park, CA,
June 1988. RFC-1055.
[12] Romkey, J. A Nonstandard for Transmission of IP Datagrams Over Serial Lines: Slip. Arpanet Working Group Requests for Comment, DDN Network Information Center, SRI International, Menlo Park, CA, June 1988. RFC-1055.
[13] Salthouse, T. A. The skill of typing. Scientific American 250, 2
(Feb. 1984), 128--135.
[13] Salthouse, T. A. The skill of typing. Scientific American 250, 2 (Feb. 1984), 128--135.
[14] Saltzer, J. H., Reed, D. P., and Clark, D. D. End-to-end arguments
in system design. ACM Transactions on Computer Systems 2, 4 (Nov.
1984).
[14] Saltzer, J. H., Reed, D. P., and Clark, D. D. End-to-end arguments in system design. ACM Transactions on Computer Systems 2, 4 (Nov. 1984).
[15] Shneiderman, B. Designing the User Interface. Addison-Wesley,
1987.
[15] Shneiderman, B. Designing the User Interface. Addison-Wesley, 1987.
Jacobson [Page 26] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 26] RFC 1144 Compressing TCP/IP Headers February 1990
A Sample Implementation
A Sample Implementation
The following is a sample implementation of the protocol described in this document.
The following is a sample implementation of the protocol described in this document.
Since many people who might have the deal with this code are familiar with the Berkeley Unix kernel and its coding style (affectionately known as kernel normal form), this code was done in that style. It uses the Berkeley `subroutines' (actually, macros and/or inline assembler expansions) for converting to/from network byte order and copying/comparing strings of bytes. These routines are briefly described in sec. A.5 for anyone not familiar with them.
Since many people who might have the deal with this code are familiar with the Berkeley Unix kernel and its coding style (affectionately known as kernel normal form), this code was done in that style. It uses the Berkeley `subroutines' (actually, macros and/or inline assembler expansions) for converting to/from network byte order and copying/comparing strings of bytes. These routines are briefly described in sec. A.5 for anyone not familiar with them.
This code has been run on all the machines listed in the table on page 24. Thus, the author hopes there are no byte order or alignment problems (although there are embedded assumptions about alignment that are valid for Berkeley Unix but may not be true for other IP implementations --- see the comments mentioning alignment in sl_compress_tcp and sl_decompress_tcp).
This code has been run on all the machines listed in the table on page 24. Thus, the author hopes there are no byte order or alignment problems (although there are embedded assumptions about alignment that are valid for Berkeley Unix but may not be true for other IP implementations --- see the comments mentioning alignment in sl_compress_tcp and sl_decompress_tcp).
There was some attempt to make this code efficient. Unfortunately, that may have made portions of it incomprehensible. The author apologizes for any frustration this engenders. (In honesty, my C style is known to be obscure and claims of `efficiency' are simply a convenient excuse.)
There was some attempt to make this code efficient. Unfortunately, that may have made portions of it incomprehensible. The author apologizes for any frustration this engenders. (In honesty, my C style is known to be obscure and claims of `efficiency' are simply a convenient excuse.)
This sample code and a complete Berkeley Unix implementation is available in machine readable form via anonymous ftp from Internet host ftp.ee.lbl.gov (128.3.254.68), file cslip.tar.Z. This is a compressed Unix tar file. It must be ftped in binary mode.
This sample code and a complete Berkeley Unix implementation is available in machine readable form via anonymous ftp from Internet host ftp.ee.lbl.gov (128.3.254.68), file cslip.tar.Z. This is a compressed Unix tar file. It must be ftped in binary mode.
All of the code in this appendix is covered by the following copyright:
All of the code in this appendix is covered by the following copyright:
/*
* Copyright (c) 1989 Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms are
* permitted provided that the above copyright notice and this
* paragraph are duplicated in all such forms and that any
* documentation, advertising materials, and other materials
* related to such distribution and use acknowledge that the
* software was developed by the University of California,
* Berkeley. The name of the University may not be used to
* endorse or promote products derived from this software
* without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS
* OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE
* IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A
* PARTICULAR PURPOSE.
*/
/* * Copyright (c) 1989 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are * permitted provided that the above copyright notice and this * paragraph are duplicated in all such forms and that any * documentation, advertising materials, and other materials * related to such distribution and use acknowledge that the * software was developed by the University of California, * Berkeley. The name of the University may not be used to * endorse or promote products derived from this software * without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS * OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE * IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A * PARTICULAR PURPOSE. */
Jacobson [Page 27] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 27] RFC 1144 Compressing TCP/IP Headers February 1990
A.1 Definitions and State Data
A.1 Definitions and State Data
#define MAX_STATES 16 /* must be >2 and <255 */ #define MAX_HDR 128 /* max TCP+IP hdr length (by protocol def) */
#define MAX_STATES 16 /* must be >2 and <255 */ #define MAX_HDR 128 /* max TCP+IP hdr length (by protocol def) */
/* packet types */
#define TYPE_IP 0x40
#define TYPE_UNCOMPRESSED_TCP 0x70
#define TYPE_COMPRESSED_TCP 0x80
#define TYPE_ERROR 0x00 /* this is not a type that ever appears on
* the wire. The receive framer uses it to
* tell the decompressor there was a packet
* transmission error. */
/*
* Bits in first octet of compressed packet
*/
/* packet types */ #define TYPE_IP 0x40 #define TYPE_UNCOMPRESSED_TCP 0x70 #define TYPE_COMPRESSED_TCP 0x80 #define TYPE_ERROR 0x00 /* this is not a type that ever appears on * the wire. The receive framer uses it to * tell the decompressor there was a packet * transmission error. */ /* * Bits in first octet of compressed packet */
/* flag bits for what changed in a packet */
/* flag bits for what changed in a packet */
#define NEW_C 0x40 #define NEW_I 0x20 #define TCP_PUSH_BIT 0x10
#define NEW_C 0x40 #define NEW_I 0x20 #define TCP_PUSH_BIT 0x10
#define NEW_S 0x08 #define NEW_A 0x04 #define NEW_W 0x02 #define NEW_U 0x01
#define NEW_S 0x08 #define NEW_A 0x04 #define NEW_W 0x02 #define NEW_U 0x01
/* reserved, special-case values of above */ #define SPECIAL_I (NEW_S|NEW_W|NEW_U) /* echoed interactive traffic */ #define SPECIAL_D (NEW_S|NEW_A|NEW_W|NEW_U) /* unidirectional data */ #define SPECIALS_MASK (NEW_S|NEW_A|NEW_W|NEW_U)
/* reserved, special-case values of above */ #define SPECIAL_I (NEW_S|NEW_W|NEW_U) /* echoed interactive traffic */ #define SPECIAL_D (NEW_S|NEW_A|NEW_W|NEW_U) /* unidirectional data */ #define SPECIALS_MASK (NEW_S|NEW_A|NEW_W|NEW_U)
/*
* "state" data for each active tcp conversation on the wire. This is
* basically a copy of the entire IP/TCP header from the last packet together
* with a small identifier the transmit & receive ends of the line use to
* locate saved header.
*/
struct cstate {
struct cstate *cs_next; /* next most recently used cstate (xmit only) */
u_short cs_hlen; /* size of hdr (receive only) */
u_char cs_id; /* connection # associated with this state */
u_char cs_filler;
union {
char hdr[MAX_HDR];
struct ip csu_ip; /* ip/tcp hdr from most recent packet */
} slcs_u;
};
#define cs_ip slcs_u.csu_ip
/* * "state" data for each active tcp conversation on the wire. This is * basically a copy of the entire IP/TCP header from the last packet together * with a small identifier the transmit & receive ends of the line use to * locate saved header. */ struct cstate { struct cstate *cs_next; /* next most recently used cstate (xmit only) */ u_short cs_hlen; /* size of hdr (receive only) */ u_char cs_id; /* connection # associated with this state */ u_char cs_filler; union { char hdr[MAX_HDR]; struct ip csu_ip; /* ip/tcp hdr from most recent packet */ } slcs_u; }; #define cs_ip slcs_u.csu_ip
Jacobson [Page 28] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 28] RFC 1144 Compressing TCP/IP Headers February 1990
#define cs_hdr slcs_u.csu_hdr
#define cs_hdr slcs_u.csu_hdr
/*
* all the state data for one serial line (we need one of these per line).
*/
struct slcompress {
struct cstate *last_cs; /* most recently used tstate */
u_char last_recv; /* last rcvd conn. id */
u_char last_xmit; /* last sent conn. id */
u_short flags;
struct cstate tstate[MAX_STATES]; /* xmit connection states */
struct cstate rstate[MAX_STATES]; /* receive connection states */
};
/* * all the state data for one serial line (we need one of these per line). */ struct slcompress { struct cstate *last_cs; /* most recently used tstate */ u_char last_recv; /* last rcvd conn. id */ u_char last_xmit; /* last sent conn. id */ u_short flags; struct cstate tstate[MAX_STATES]; /* xmit connection states */ struct cstate rstate[MAX_STATES]; /* receive connection states */ };
/* flag values */ #define SLF_TOSS 1 /* tossing rcvd frames because of input err */
/* flag values */ #define SLF_TOSS 1 /* tossing rcvd frames because of input err */
/*
* The following macros are used to encode and decode numbers. They all
* assume that `cp' points to a buffer where the next byte encoded (decoded)
* is to be stored (retrieved). Since the decode routines do arithmetic,
* they have to convert from and to network byte order.
*/
/* * The following macros are used to encode and decode numbers. They all * assume that `cp' points to a buffer where the next byte encoded (decoded) * is to be stored (retrieved). Since the decode routines do arithmetic, * they have to convert from and to network byte order. */
/*
* ENCODE encodes a number that is known to be non-zero. ENCODEZ checks for
* zero (zero has to be encoded in the long, 3 byte form).
*/
#define ENCODE(n) { \
if ((u_short)(n) >= 256) { \
*cp++ = 0; \
cp[1] = (n); \
cp[0] = (n) >> 8; \
cp += 2; \
} else { \
*cp++ = (n); \
} \
}
#define ENCODEZ(n) { \
if ((u_short)(n) >= 256 || (u_short)(n) == 0) { \
*cp++ = 0; \
cp[1] = (n); \
cp[0] = (n) >> 8; \
cp += 2; \
} else { \
*cp++ = (n); \
} \
}
/* * ENCODE encodes a number that is known to be non-zero. ENCODEZ checks for * zero (zero has to be encoded in the long, 3 byte form). */ #define ENCODE(n) { \ if ((u_short)(n) >= 256) { \ *cp++ = 0; \ cp[1] = (n); \ cp[0] = (n) >> 8; \ cp += 2; \ } else { \ *cp++ = (n); \ } \ } #define ENCODEZ(n) { \ if ((u_short)(n) >= 256 || (u_short)(n) == 0) { \ *cp++ = 0; \ cp[1] = (n); \ cp[0] = (n) >> 8; \ cp += 2; \ } else { \ *cp++ = (n); \ } \ }
/*
* DECODEL takes the (compressed) change at byte cp and adds it to the
/* * DECODEL takes the (compressed) change at byte cp and adds it to the
Jacobson [Page 29] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 29] RFC 1144 Compressing TCP/IP Headers February 1990
* current value of packet field 'f' (which must be a 4-byte (long) integer
* in network byte order). DECODES does the same for a 2-byte (short) field.
* DECODEU takes the change at cp and stuffs it into the (short) field f.
* 'cp' is updated to point to the next field in the compressed header.
*/
#define DECODEL(f) { \
if (*cp == 0) {\
(f) = htonl(ntohl(f) + ((cp[1] << 8) | cp[2])); \
cp += 3; \
} else { \
(f) = htonl(ntohl(f) + (u_long)*cp++); \
} \
}
#define DECODES(f) { \
if (*cp == 0) {\
(f) = htons(ntohs(f) + ((cp[1] << 8) | cp[2])); \
cp += 3; \
} else { \
(f) = htons(ntohs(f) + (u_long)*cp++); \
} \
}
#define DECODEU(f) { \
if (*cp == 0) {\
(f) = htons((cp[1] << 8) | cp[2]); \
cp += 3; \
} else { \
(f) = htons((u_long)*cp++); \
} \
}
* current value of packet field 'f' (which must be a 4-byte (long) integer * in network byte order). DECODES does the same for a 2-byte (short) field. * DECODEU takes the change at cp and stuffs it into the (short) field f. * 'cp' is updated to point to the next field in the compressed header. */ #define DECODEL(f) { \ if (*cp == 0) {\ (f) = htonl(ntohl(f) + ((cp[1] << 8) | cp[2])); \ cp += 3; \ } else { \ (f) = htonl(ntohl(f) + (u_long)*cp++); \ } \ } #define DECODES(f) { \ if (*cp == 0) {\ (f) = htons(ntohs(f) + ((cp[1] << 8) | cp[2])); \ cp += 3; \ } else { \ (f) = htons(ntohs(f) + (u_long)*cp++); \ } \ } #define DECODEU(f) { \ if (*cp == 0) {\ (f) = htons((cp[1] << 8) | cp[2]); \ cp += 3; \ } else { \ (f) = htons((u_long)*cp++); \ } \ }
Jacobson [Page 30] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 30] RFC 1144 Compressing TCP/IP Headers February 1990
A.2 Compression
A.2 Compression
This routine looks daunting but isn't really. The code splits into four approximately equal sized sections: The first quarter manages a circularly linked, least-recently-used list of `active' TCP connections./47/ The second figures out the sequence/ack/window/urg changes and builds the bulk of the compressed packet. The third handles the special-case encodings. The last quarter does packet ID and connection ID encoding and replaces the original packet header with the compressed header.
This routine looks daunting but isn't really. The code splits into four approximately equal sized sections: The first quarter manages a circularly linked, least-recently-used list of `active' TCP connections./47/ The second figures out the sequence/ack/window/urg changes and builds the bulk of the compressed packet. The third handles the special-case encodings. The last quarter does packet ID and connection ID encoding and replaces the original packet header with the compressed header.
The arguments to this routine are a pointer to a packet to be compressed, a pointer to the compression state data for the serial line, and a flag which enables or disables connection id (C bit) compression.
The arguments to this routine are a pointer to a packet to be compressed, a pointer to the compression state data for the serial line, and a flag which enables or disables connection id (C bit) compression.
Compression is done `in-place' so, if a compressed packet is created, both the start address and length of the incoming packet (the off and len fields of m) will be updated to reflect the removal of the original header and its replacement by the compressed header. If either a compressed or uncompressed packet is created, the compression state is updated. This routines returns the packet type for the transmit framer (TYPE_IP, TYPE_UNCOMPRESSED_TCP or TYPE_COMPRESSED_TCP).
Compression is done `in-place' so, if a compressed packet is created, both the start address and length of the incoming packet (the off and len fields of m) will be updated to reflect the removal of the original header and its replacement by the compressed header. If either a compressed or uncompressed packet is created, the compression state is updated. This routines returns the packet type for the transmit framer (TYPE_IP, TYPE_UNCOMPRESSED_TCP or TYPE_COMPRESSED_TCP).
Because 16 and 32 bit arithmetic is done on various header fields, the incoming IP packet must be aligned appropriately (e.g., on a SPARC, the IP header is aligned on a 32-bit boundary). Substantial changes would have to be made to the code below if this were not true (and it would probably be cheaper to byte copy the incoming header to somewhere correctly aligned than to make those changes).
Because 16 and 32 bit arithmetic is done on various header fields, the incoming IP packet must be aligned appropriately (e.g., on a SPARC, the IP header is aligned on a 32-bit boundary). Substantial changes would have to be made to the code below if this were not true (and it would probably be cheaper to byte copy the incoming header to somewhere correctly aligned than to make those changes).
Note that the outgoing packet will be aligned arbitrarily (e.g., it could easily start on an odd-byte boundary).
Note that the outgoing packet will be aligned arbitrarily (e.g., it could easily start on an odd-byte boundary).
u_char
sl_compress_tcp(m, comp, compress_cid)
struct mbuf *m;
struct slcompress *comp;
int compress_cid;
{
register struct cstate *cs = comp->last_cs->cs_next;
register struct ip *ip = mtod(m, struct ip *);
register u_int hlen = ip->ip_hl;
register struct tcphdr *oth; /* last TCP header */
register struct tcphdr *th; /* current TCP header */
u_char sl_compress_tcp(m, comp, compress_cid) struct mbuf *m; struct slcompress *comp; int compress_cid; { register struct cstate *cs = comp->last_cs->cs_next; register struct ip *ip = mtod(m, struct ip *); register u_int hlen = ip->ip_hl; register struct tcphdr *oth; /* last TCP header */ register struct tcphdr *th; /* current TCP header */
----------------------------
47. The two most common operations on the connection list are a `find'
that terminates at the first entry (a new packet for the most recently
used connection) and moving the last entry on the list to the head of
the list (the first packet from a new connection). A circular list
efficiently handles these two operations.
---------------------------- 47. The two most common operations on the connection list are a `find' that terminates at the first entry (a new packet for the most recently used connection) and moving the last entry on the list to the head of the list (the first packet from a new connection). A circular list efficiently handles these two operations.
Jacobson [Page 31] RFC 1144 Compressing TCP/IP Headers February 1990
Jacobson [Page 31] RFC 1144 Compressing TCP/IP Headers February 1990
register u_int deltaS, deltaA; /* general purpose temporaries */
register u_int changes = 0; /* change mask */
u_char new_seq[16]; /* changes from last to current */
register u_char *cp = new_seq;
register u_int deltaS, deltaA; /* general purpose temporaries */ register u_int changes = 0; /* change mask */ u_char new_seq[16]; /* changes from last to current */ register u_char *cp = new_seq;
/*
* Bail if this is an IP fragment or if the TCP packet isn't
* `compressible' (i.e., ACK isn't set or some other control bit is
* set). (We assume that the caller has already made sure the packet
* is IP proto TCP).
*/
if ((ip->ip_off & htons(0x3fff)) || m->m_len < 40)
return (TYPE_IP);
/* * Bail if this is an IP fragment or if the TCP packet isn't * `compressible' (i.e., ACK isn't set or some other control bit is * set). (We assume that the caller has already made sure the packet * is IP proto TCP). */ if ((ip->ip_off & htons(0x3fff)) || m->m_len < 40) return (TYPE_IP);
th = (struct tcphdr *) & ((int *) ip)[hlen];
if ((th->th_flags & (TH_SYN | TH_FIN | TH_RST | TH_ACK)) != TH_ACK)
return (TYPE_IP);
th = (struct tcphdr *) & ((int *) ip)[hlen]; if ((th->th_flags & (TH_SYN | TH_FIN | TH_RST | TH_ACK)) != TH_ACK) return (TYPE_IP);
/*
* Packet is compressible -- we're going to send either a
* COMPRESSED_TCP or UNCOMPRESSED_TCP packet. Either way we need to
* locate (or create) the connection state. Special case the most
* recently used connection since it's most likely to be used again &
* we don't have to do any reordering if it's used.
*/
if (ip->ip_src.s_addr != cs->cs_ip.ip_src.s_addr ||
ip->ip_dst.s_addr != cs->cs_ip.ip_dst.s_addr ||
*(int *) th != ((int *) &cs->cs_ip)[cs->cs_ip.ip_hl]) {
/**パケットは圧縮性です--私たちは*COMPRESSED_TCPかUNCOMPRESSED_TCPパケットを送るつもりです。 いずれにせよ私たちが*に必要である、場所を見つける、(作成、)、接続状態。 それが使用されているなら最も多くの*が最近どんな再命令もするのにそれが再び最も使用されそうであって以来の接続と私たちが持っていない*を使用した特別なケース。 */、(>ip_src.s_addr!=Cs->をipしている_Cs_ip.ip src.s_addr| | >ip_dst.s_addr!=Cs->をipしている_Cs_ip.ip dst.s_addr| | *(int*)、第=((int*)とCs_がipするCs->)、[Cs、-、>Cs_ip.ip_hl)
/*
* Wasn't the first -- search for it.
*
* States are kept in a circularly linked list with last_cs
* pointing to the end of the list. The list is kept in lru
* order by moving a state to the head of the list whenever
* it is referenced. Since the list is short and,
* empirically, the connection we want is almost always near
* the front, we locate states via linear search. If we
* don't find a state for the datagram, the oldest state is
* (re-)used.
*/
register struct cstate *lcs;
register struct cstate *lastcs = comp->last_cs;
/**は1番目ではありませんでした--それを捜し求めてください。 * * *リストの終わりを示して、州は回覧に繋がっているリストに最後の_Csで維持されます。 *それが参照をつけられるときはいつも、状態をリストのヘッドに動かすことによって、リストは閉じ込められたlru*オーダーです。 *以来リストは短いです、そして、私たちが欲しい接続がほとんどいつも*の近くに経験して、あります。前部、私たちはリニアサーチで州の場所を見つけます。 *私たちであるならデータグラムのための状態、最も古い状態が*であると確かめないでください、(再、)、使用されています。 */レジスタstruct cstate*lcs。 レジスタstruct cstate*lastcs=コンピュータ->は_Csを持続します。
do {
lcs = cs;
cs = cs->cs_next;
if (ip->ip_src.s_addr == cs->cs_ip.ip_src.s_addr
&& ip->ip_dst.s_addr == cs->cs_ip.ip_dst.s_addr
&& *(int *) th == ((int *) &cs->cs_ip)[cs->cs_ip.ip_hl])
goto found;
等しい..Cs..Cs..等しい..Cs..Cs..次..Cs..Cs..Cs..Cs..Cs..Cs..Cs..Cs..見つける
Jacobson [Page 32] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[32ページ]RFC1144
} while (cs != lastcs);
(Cs!=lastcs)である間。
/*
* Didn't find it -- re-use oldest cstate. Send an
* uncompressed packet that tells the other side what
* connection number we're using for this conversation. Note
* that since the state list is circular, the oldest state
* points to the newest and we only need to set last_cs to
* update the lru linkage.
*/
comp->last_cs = lcs;
hlen += th->th_off;
hlen <<= 2;
goto uncompressed;
/**はそれを見つけませんでした--再使用の最も古いcstate。 私たちがこの会話にどんな*接続番号を使用しているかを反対側に言う*解凍されたパケットを送ってください。 *州のリストが円形であるので最も古い州*が最も新しいのを示して、私たちが*へのセット最終_Csにlruリンケージをアップデートするだけでよいことに注意してください。 */コンピュータ->は_Cs=lcsを持続します。 hlen+=、第-、>、第_下に。 hlen<<=2。 gotoは解凍しました。
found:
/* Found it -- move to the front on the connection list. */
if (lastcs == cs)
comp->last_cs = lcs;
else {
lcs->cs_next = cs->cs_next;
cs->cs_next = lastcs->cs_next;
lastcs->cs_next = cs;
}
}
/*
* Make sure that only what we expect to change changed. The first
* line of the `if' checks the IP protocol version, header length &
* type of service. The 2nd line checks the "Don't fragment" bit.
* The 3rd line checks the time-to-live and protocol (the protocol
* check is unnecessary but costless). The 4th line checks the TCP
* header length. The 5th line checks IP options, if any. The 6th
* line checks TCP options, if any. If any of these things are
* different between the previous & current datagram, we send the
* current datagram `uncompressed'.
*/
oth = (struct tcphdr *) & ((int *) &cs->cs_ip)[hlen];
deltaS = hlen;
hlen += th->th_off;
hlen <<= 2;
設立します: /*はそれを見つけました--接続リストの上の前部に動いてください。 */は(lastcs=Cs)コンピュータ->最終_Csであるならlcsと等しいです。 ほか、_次の>Cs=Cs->をlcsしているCs_次;、Cs、->Cs_次は_次に、>をlastcsしているCsと等しいです; 次の>Cs_をlastcsしている=Cs /**は、私たちが、何だけを変えると予想するか変化したのを確実にします。 'if'の最初*の線はサービスのIPプロトコルバージョン、ヘッダ長、および*タイプをチェックします。 2番目の線は「断片化しないでください」というビットをチェックします。 * 3番目の線は生きる時間とプロトコルをチェックします(プロトコル*チェックは、不要ですが、costlessです)。 4番目の線はTCP*ヘッダ長をチェックします。 5番目の線はもしあればIPオプションをチェックします。 6*番目の線はもしあればTCPオプションをチェックします。 これらのもののどれかが前の、そして、現在のデータグラムの間で異なった*であるなら、私たちは'解凍された'*現在のデータグラムを送ります。 */oth=(struct tcphdr*)、および((int*)とCs_がipするCs->)[hlen]。 deltaSはhlenと等しいです。 hlen+=、第-、>、第_下に。 hlen<<=2。
if (((u_short *) ip)[0] != ((u_short *) &cs->cs_ip)[0] ||
((u_short *) ip)[3] != ((u_short *) &cs->cs_ip)[3] ||
((u_short *) ip)[4] != ((u_short *) &cs->cs_ip)[4] ||
th->th_off != oth->th_off ||
(deltaS > 5 && BCMP(ip + 1, &cs->cs_ip + 1, (deltaS - 5) << 2)) ||
(th->th_off > 5 && BCMP(th + 1, oth + 1, (th->th_off - 5) << 2)))
goto uncompressed;
if (((u_short *) ip)[0] != ((u_short *) &cs->cs_ip)[0] || ((u_short *) ip)[3] != ((u_short *) &cs->cs_ip)[3] || ((u_short *) ip)[4] != ((u_short *) &cs->cs_ip)[4] || th->th_off != oth->th_off || (deltaS > 5 && BCMP(ip + 1, &cs->cs_ip + 1, (deltaS - 5) << 2)) || (th->th_off > 5 && BCMP(th + 1, oth + 1, (th->th_off - 5) << 2))) goto uncompressed;
/*
* Figure out which of the changing fields changed. The receiver
/**は、分野が変化のどれを変えたかを理解します。 受信機
Jacobson [Page 33] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[33ページ]RFC1144
* expects changes in the order: urgent, window, ack, seq.
*/
if (th->th_flags & TH_URG) {
deltaS = ntohs(th->th_urp);
ENCODEZ(deltaS);
changes |= NEW_U;
} else if (th->th_urp != oth->th_urp)
/*
* argh! URG not set but urp changed -- a sensible
* implementation should never do this but RFC793 doesn't
* prohibit the change so we have to deal with it.
*/
goto uncompressed;
* オーダーにおける変化を予想します: 緊急であることで、ackにseqに窓を付けてください。 */、(第-、>、第_旗とTH_URG)、deltaSがntohsと等しい、(第-、>、_urp) ; ENCODEZ(deltaS); 変化| 第=NEW_U;、ほか、(第-、>、_urp!がoth->と第等しい、_urp) /**第argh! URGはセットしませんでしたが、urpは変化しました--実現がこれにもかかわらず、RFC793を決してするべきでない分別がある*、私たちがそれに対処しなければならなくて、*は変化を禁止しませんか? */gotoは解凍しました。
if (deltaS = (u_short) (ntohs(th->th_win) - ntohs(oth->th_win))) {
ENCODE(deltaS);
changes |= NEW_W;
}
if (deltaA = ntohl(th->th_ack) - ntohl(oth->th_ack)) {
if (deltaA > 0xffff)
goto uncompressed;
ENCODE(deltaA);
changes |= NEW_A;
}
if (deltaS = ntohl(th->th_seq) - ntohl(oth->th_seq)) {
if (deltaS > 0xffff)
goto uncompressed;
ENCODE(deltaS);
changes |= NEW_S;
}
/*
* Look for the special-case encodings.
*/
switch (changes) {
if (deltaS = (u_short) (ntohs(th->th_win) - ntohs(oth->th_win))) { ENCODE(deltaS); changes |= NEW_W; } if (deltaA = ntohl(th->th_ack) - ntohl(oth->th_ack)) { if (deltaA > 0xffff) goto uncompressed; ENCODE(deltaA); changes |= NEW_A; } if (deltaS = ntohl(th->th_seq) - ntohl(oth->th_seq)) { if (deltaS > 0xffff) goto uncompressed; ENCODE(deltaS); changes |= NEW_S; } /* * Look for the special-case encodings. */スイッチ(変化)
case 0:
/*
* Nothing changed. If this packet contains data and the last
* one didn't, this is probably a data packet following an
* ack (normal on an interactive connection) and we send it
* compressed. Otherwise it's probably a retransmit,
* retransmitted ack or window probe. Send it uncompressed
* in case the other side missed the compressed version.
*/
if (ip->ip_len != cs->cs_ip.ip_len &&
ntohs(cs->cs_ip.ip_len) == hlen)
break;
ケース0: 何も変えなかった/**。 このパケットがデータと1がそうしない最後の*を含んでいるなら、これはたぶん*ack(対話的な接続に正常な)に続くデータ・パケットです、そして、私たちは圧縮された*をそれに送ります。 さもなければ、たぶん、aが再送されて、*がackか窓の探測装置を再送したということです。 *反対側が圧縮されたバージョンを逃すといけなかったので解凍されて、それを送ってください。 */、(_>ip_len!=Cs->をipしているCs ip.ip_len、ntohs(Cs_ip.ip_がlenするCs->)=hlen) 壊れてください。
/* (fall through) */
/*(通り抜けて落ちます)*/
case SPECIAL_I:
ケースSPECIAL_I:
Jacobson [Page 34] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[34ページ]RFC1144
case SPECIAL_D:
/*
* Actual changes match one of our special case encodings --
* send packet uncompressed.
*/
goto uncompressed;
SPECIALをケースに入れてください: /**実際の変化は私たちの特別なケースencodingsの1つに合っています--*解凍されたパケットを送ってください。 */gotoは解凍しました。
case NEW_S | NEW_A:
if (deltaS == deltaA &&
deltaS == ntohs(cs->cs_ip.ip_len) - hlen) {
/* special case for echoed terminal traffic */
changes = SPECIAL_I;
cp = new_seq;
}
break;
ケースNEW_S| 新しい: (deltaS=deltaA、deltaS=は(Cs_ip.ip_がlenするCs->)をntohsします--hlen) cpがseqに新しい_と等しいという反響している端末の交通*/変化=SPECIAL_Iのための/*特別なケースは壊れます;。
case NEW_S:
if (deltaS == ntohs(cs->cs_ip.ip_len) - hlen) {
/* special case for data xfer */
changes = SPECIAL_D;
cp = new_seq;
}
break;
}
deltaS = ntohs(ip->ip_id) - ntohs(cs->cs_ip.ip_id);
if (deltaS != 1) {
ENCODEZ(deltaS);
changes |= NEW_I;
}
if (th->th_flags & TH_PUSH)
changes |= TCP_PUSH_BIT;
/*
* Grab the cksum before we overwrite it below. Then update our
* state with this packet's header.
*/
deltaA = ntohs(th->th_sum);
BCOPY(ip, &cs->cs_ip, hlen);
NEW_Sをケースに入れてください: (deltaS=は(Cs_ip.ip_がlenするCs->)をntohsします--hlen)なら、cpがseqに新しい_と等しいというデータxfer*/変化のための/*特別なケース=SPECIALは壊れます。 deltaSはntohs(ip>のip_イド)と等しいです--ntohsする、(Cs、-、>Cs_ip.ip_イド)、。 (デルタ!=1)である、ENCODEZ(デルタ)。 変化|= _新しい私。 (第-、>、_TH_PUSH) 旗と第変化|= TCP_プッシュ_に噛み付きました。 私たちがそれを以下に上書きする前に/**はcksumをつかみます。 そして、このパケットのヘッダーと共に私たちの*状態をアップデートしてください。 */deltaA=がntohsされる、(第-、>、第_合計)、。 BCOPY(ip、およびCs_がipするCs->はhlenされます)。
/*
* We want to use the original packet as our compressed packet. (cp -
* new_seq) is the number of bytes we need for compressed sequence
* numbers. In addition we need one byte for the change mask, one
* for the connection id and two for the tcp checksum. So, (cp -
* new_seq) + 4 bytes of header are needed. hlen is how many bytes
* of the original packet to toss so subtract the two to get the new
* packet size.
*/
deltaS = cp - new_seq;
cp = (u_char *) ip;
if (compress_cid == 0 || comp->last_xmit != cs->cs_id) {
comp->last_xmit = cs->cs_id;
私たちの圧縮されたパケットとしてオリジナルのパケットを使用したいと思う/**。 (cp--*新しい_seq) 私たちが圧縮された系列*に必要とするバイト数は数ですか? さらに、私たちは変化マスクのための1バイト、接続イドのためのもの*、およびtcpチェックサムのための2を必要とします。 それで、+ ヘッダーの(cp--*新しい_seq)4バイトが必要です。hlenはしたがって、投げるオリジナルのパケットのいくつのバイト*が新しい*パケットサイズを得るために2を引き算するかということです。 */deltaSはcpと等しいです--新しい_seq cpはipと等しいです(u_炭*)。 (_Cid=0を圧縮してください| | コンピュータ->が_xmit!=Cs->を持続する、Cs_イド)、コンピュータ->が_xmitに=Cs->を持続する、Cs_イド。
Jacobson [Page 35] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[35ページ]RFC1144
hlen -= deltaS + 4;
cp += hlen;
*cp++ = changes | NEW_C;
*cp++ = cs->cs_id;
} else {
hlen -= deltaS + 3;
cp += hlen;
*cp++ = changes;
}
m->m_len -= hlen;
m->m_off += hlen;
*cp++ = deltaA >> 8;
*cp++ = deltaA;
BCOPY(new_seq, cp, deltaS);
return (TYPE_COMPRESSED_TCP);
hlen -= deltaS+4。 cp+=hlen。 *+ + =が変えるcp| 新しい_C。 *cp++がCs->と等しい、Cs_イド。 ほか、hlen -= deltaS+3。 cp+=hlen。 *+ + =が変えるcp。 m、-、>m_len -= hlen。 m、-+の>m_はhlenと等しいです。 *cp++はdeltaA>>8と等しいです。 *cp++はdeltaAと等しいです。 BCOPY(新しい_seq、cp、deltaS)。 (TYPE_COMPRESSED_TCP)を返してください。
uncompressed:
/*
* Update connection state cs & send uncompressed packet
* ('uncompressed' means a regular ip/tcp packet but with the
* 'conversation id' we hope to use on future compressed packets in
* the protocol field).
*/
BCOPY(ip, &cs->cs_ip, hlen);
ip->ip_p = cs->cs_id;
comp->last_xmit = cs->cs_id;
return (TYPE_UNCOMPRESSED_TCP);
}
解凍される: /**は、接続州のCsをアップデートして、解凍されたパケット*を送ります('解凍'はレギュラーのip/tcpパケットを意味しますが、*'会話イド'で、私たちは、*で将来の圧縮されたパケットの上でプロトコル分野を使用することを望んでいます)。 */BCOPY(ip、およびCs_がipするCs->はhlenされます)。 >ip_p=Cs->をipしているCs_イド。 コンピュータ->が_xmitに=Cs->を持続する、Cs_イド。 (TYPE_UNCOMPRESSED_TCP)を返してください。 }
Jacobson [Page 36] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[36ページ]RFC1144
A.3 Decompression
A.3減圧
This routine decompresses a received packet. It is called with a pointer to the packet, the packet length and type, and a pointer to the compression state structure for the incoming serial line. It returns a pointer to the resulting packet or zero if there were errors in the incoming packet. If the packet is COMPRESSED_TCP or UNCOMPRESSED_TCP, the compression state will be updated.
このルーチンは容認されたパケットを減圧します。 それはパケット、パケット長、およびタイプへのポインタ、および圧縮状態構造へのポインタで入って来るシリアル・ラインに呼ばれます。 誤りが入って来るパケットにあったなら、それは結果として起こるパケットかゼロにポインタを返します。 パケットがCOMPRESSED_TCPかUNCOMPRESSED_TCPであるなら、圧縮状態をアップデートするでしょう。
The new packet will be constructed in-place. That means that there must be 128 bytes of free space in front of bufp to allow room for the reconstructed IP and TCP headers. The reconstructed packet will be aligned on a 32-bit boundary.
新しいパケットは適所で組み立てられるでしょう。 それは、再建されたIPとTCPヘッダーの余地を許容するために128バイトの空きスペースがbufpの正面にあるに違いないことを意味します。 再建されたパケットは32ビットの境界で並べられるでしょう。
u_char *
sl_uncompress_tcp(bufp, len, type, comp)
u_char *bufp;
int len;
u_int type;
struct slcompress *comp;
{
register u_char *cp;
register u_int hlen, changes;
register struct tcphdr *th;
register struct cstate *cs;
register struct ip *ip;
u_炭*のsl_は__tcp(bufp、len、タイプ、コンピュータ)u炭*bufpを解凍します。 int len。 u_intタイプ。 struct slcompress*コンピュータ。 u_炭*のcpを登録してください; 変化; u_int hlenを登録してくださいといって、struct tcphdr*を登録してください、第;struct cstate*Csを登録してください; レジスタstruct ip*ip
switch (type) {
切り替わってください(タイプしてください)。
case TYPE_ERROR:
default:
goto bad;
TYPE_ERRORをケースに入れてください: デフォルト: goto悪い。
case TYPE_IP:
return (bufp);
TYPE_IPをケースに入れてください: 戻ってください(bufp)。
case TYPE_UNCOMPRESSED_TCP:
/*
* Locate the saved state for this connection. If the state
* index is legal, clear the 'discard' flag.
*/
ip = (struct ip *) bufp;
if (ip->ip_p >= MAX_STATES)
goto bad;
TYPE_UNCOMPRESSED_TCPをケースに入れてください: /**はこの接続のための救われた状態の場所を見つけます。 状態*インデックスが法的であるなら、'捨ててください'という旗をきれいにしてください。 */ipはbufpと等しいです(struct ip*)。 (ip>ip_pの>=マックス_STATES)がひどくgotoするなら。
cs = &comp->rstate[comp->last_recv = ip->ip_p];
comp->flags &= ~SLF_TOSS;
/*
* Restore the IP protocol field then save a copy of this
* packet header. (The checksum is zeroed in the copy so we
* don't have to zero it each time we process a compressed
Cs=とコンピュータ->rstate[コンピュータ->はip_recv=>ip_pを持続します]。 コンピュータ->が弛む、=~SLF_TOSS。 /**はIPプロトコル分野を回復して、次に、この*パケットのヘッダーのコピーを保存してください。 (チェックサムのゼロがそのようにコピーで合わせられている、私たち、私たちが圧縮されたaを処理するたびに*はそれのゼロに合う必要はありません。
Jacobson [Page 37] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[37ページ]RFC1144
* packet.
*/
ip->ip_p = IPPROTO_TCP;
hlen = ip->ip_hl;
hlen += ((struct tcphdr *) & ((int *) ip)[hlen])->th_off;
hlen <<= 2;
BCOPY(ip, &cs->cs_ip, hlen);
cs->cs_ip.ip_sum = 0;
cs->cs_hlen = hlen;
return (bufp);
* パケット。 */ip>ip_pはIPPROTO_TCPと等しいです。 hlenはip>のip_hlと等しいです。 hlen+=((struct tcphdr*)と(int*)ip)[hlen)->、第_下に。 hlen<<=2。 BCOPY(ip、およびCs_がipするCs->はhlenされます)。 Cs_ip.ip_がまとめるCs->は0と等しいです。 Cs>Cs_hlenな=hlen。 戻ってください(bufp)。
case TYPE_COMPRESSED_TCP:
break;
}
/* We've got a compressed packet. */
cp = bufp;
changes = *cp++;
if (changes & NEW_C) {
/*
* Make sure the state index is in range, then grab the
* state. If we have a good state index, clear the 'discard'
* flag.
*/
if (*cp >= MAX_STATES)
goto bad;
TYPE_COMPRESSED_TCPをケースに入れてください: 壊れてください。 } 私たちが圧縮されたパケットを得た/*。 */cpはbufpと等しいです。 変化は*cp++と等しいです。 (変化とNEW_C)である、/**は、州のインデックスが範囲にあるのを確実にして、次に、*状態をつかみます。 私たちに良い州のインデックスがあるなら、'破棄'*旗をきれいにしてください。 */は(*cp>=マックス_STATES)であるならひどくgotoされます。
comp->flags &= ~SLF_TOSS;
comp->last_recv = *cp++;
} else {
/*
* This packet has an implicit state index. If we've had a
* line error since the last time we got an explicit state
* index, we have to toss the packet.
*/
if (comp->flags & SLF_TOSS)
return ((u_char *) 0);
}
/*
* Find the state then fill in the TCP checksum and PUSH bit.
*/
cs = &comp->rstate[comp->last_recv];
hlen = cs->cs_ip.ip_hl << 2;
th = (struct tcphdr *) & ((u_char *) &cs->cs_ip)[hlen];
th->th_sum = htons((*cp << 8) | cp[1]);
cp += 2;
if (changes & TCP_PUSH_BIT)
th->th_flags |= TH_PUSH;
else
th->th_flags &= ~TH_PUSH;
コンピュータ->が弛む、=~SLF_TOSS。 コンピュータ->は_recv=*cp++を持続します。 ほか{ 内在している州がこのパケットで索引をつける/**。 最後の時間明白な状態*インデックスを得て以来*線誤りがあるなら、私たちはパケットを投げなければなりません。 */、(コンピュータ->が弛む、SLF_TOSS) ((u_炭*)0)を返してください。 } /**は、次に、状態がTCPチェックサムとPUSHビットが中詰めであることがわかります。 */Cs=とコンピュータ->rstate[コンピュータ->は_recvを持続します]。 hlenがCsと等しい、-、>Cs_ip.ip_hl<<2。 第=(struct tcphdr*)、および((u_炭*)とCs_がipするCs->)[hlen]。 第-、>、_=htons(*cp<<8)を第まとめてください。| cp[1])。 cp+=2。 (変化とTCP_PUSH_BIT)である、第-、>、_は第弛みます。|= 第_押してください。 ほか、第-、>、第_は弛んで、~TH_PUSHと等しいです。
/*
/*
Jacobson [Page 38] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[38ページ]RFC1144
* Fix up the state's ack, seq, urg and win fields based on the
* changemask.
*/
switch (changes & SPECIALS_MASK) {
case SPECIAL_I:
{
register u_int i = ntohs(cs->cs_ip.ip_len) - cs->cs_hlen;
th->th_ack = htonl(ntohl(th->th_ack) + i);
th->th_seq = htonl(ntohl(th->th_seq) + i);
}
break;
* *changemaskに基づく状態のack、seq、urg、および勝利分野を修理してください。 */ switch (changes & SPECIALS_MASK) { case SPECIAL_I: { register u_int i = ntohs(cs->cs_ip.ip_len) - cs->cs_hlen; th->th_ack = htonl(ntohl(th->th_ack) + i); th->th_seq = htonl(ntohl(th->th_seq) + i); } break;
case SPECIAL_D:
th->th_seq = htonl(ntohl(th->th_seq) + ntohs(cs->cs_ip.ip_len)
- cs->cs_hlen);
break;
SPECIALをケースに入れてください: 第-、>、_seqがhtonlと第等しい、(ntohl、(第-、>、_seq) +は(Cs_ip.ip_がlenするCs->)をntohsします第--、Cs_がhlenするCs->)、。 壊れてください。
default:
if (changes & NEW_U) {
th->th_flags |= TH_URG;
DECODEU(th->th_urp)
} else
th->th_flags &= ~TH_URG;
if (changes & NEW_W)
DECODES(th->th_win)
if (changes & NEW_A)
DECODEL(th->th_ack)
if (changes & NEW_S)
DECODEL(th->th_seq)
break;
}
/* Update the IP ID */
if (changes & NEW_I)
DECODES(cs->cs_ip.ip_id)
else
cs->cs_ip.ip_id = htons(ntohs(cs->cs_ip.ip_id) + 1);
デフォルト: (変化とNEW_U)である、第-、>、第_は弛みます| TH_URGと等しいです;、DECODEU、(第-、>、第_urp)、ほか、第-、>、第_は弛んで、~TH_URGと等しいです。 (変化とNEW_W)DECODESである、(第-、>、第_勝利)、(変化とNEW)DECODELである、(第-、>、第_ack)、(変化とNEW_S)DECODELである、(第-、>、_seq) 第壊れてください。 } /*が(変化とNEW_I)DECODESであるならIP ID*/をアップデートする、(Cs、-、>Cs_ip.ip_イド) Cs_ip.ip_イド=がhtonsするほかのCs->、(ntohs、(Cs、-、>Cs_ip.ip_イド) + 1)。
/*
* At this point, cp points to the first byte of data in the packet.
* If we're not aligned on a 4-byte boundary, copy the data down so
* the IP & TCP headers will be aligned. Then back up cp by the
* TCP/IP header length to make room for the reconstructed header (we
* assume the packet we were handed has enough space to prepend 128
* bytes of header). Adjust the lenth to account for the new header
* & fill in the IP total length.
*/
len -= (cp - bufp);
if (len < 0)
/*
* we must have dropped some characters (crc should detect
* this but the old slip framing won't)
*ここの/*、パケットにおける、データのcpポイントから最初のバイト。 * 私たちが4バイトの境界で並べられないなら、*IPとTCPヘッダーが並べられるためにデータを写してください。 次に、*TCP/IPヘッダ長でcpを支援して、再建されたヘッダーに席を譲ってください、(私たち、*私たちが手渡されたパケットはヘッダーのprepend128*バイトまで十分な場所があると仮定してください、) 全長をlenthを調整して、新しいヘッダー*を説明して、IPでいっぱいにしてください。 */len-=(cp--bufp)。 **(len<0)/であるなら、私たちは何人かのキャラクタを落としたに違いありません。(crcはこれにもかかわらず、古いメモ用紙縁どりが検出しない*を検出するはずです)
Jacobson [Page 39] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[39ページ]RFC1144
*/
goto bad;
*/goto悪い。
if ((int) cp & 3) {
if (len > 0)
OVBCOPY(cp, (int) cp & ~3, len);
cp = (u_char *) ((int) cp & ~3);
}
cp -= cs->cs_hlen;
len += cs->cs_hlen;
cs->cs_ip.ip_len = htons(len);
BCOPY(&cs->cs_ip, cp, cs->cs_hlen);
((int)cpと3)がcpが(u_炭*)と等しいという((int)cpと~3)(len>0)OVBCOPY(cp、(int)cp、および~3、はlenされる)であるなら-=Cs->をcpするなら、Cs_はhlenされます。 Cs_がhlenするlen+=Cs->。 Cs>Cs_ip.ip_lenな=は(len)をhtonsします。 BCOPY(Cs_がipするCs->、cp、Cs_がhlenするCs->)。
/* recompute the ip header checksum */
{
register u_short *bp = (u_short *) cp;
for (changes = 0; hlen > 0; hlen -= 2)
changes += *bp++;
changes = (changes & 0xffff) + (changes >> 16);
changes = (changes & 0xffff) + (changes >> 16);
((struct ip *) cp)->ip_sum = ~changes;
}
return (cp);
ヘッダー..チェックサム..レジスタ..短い..短い..変化..変化..変化..等しい..変化..変える..変える..等しい..変化..変える..合計..変える..返す
bad:
comp->flags |= SLF_TOSS;
return ((u_char *) 0);
}
悪い: コンピュータ->は弛みます。|= SLF_トス。 ((u_炭*)0)を返してください。 }
Jacobson [Page 40] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[40ページ]RFC1144
A.4 Initialization
A.4初期設定
This routine initializes the state structure for both the transmit and receive halves of some serial line. It must be called each time the line is brought up.
このルーチンが両方のために州の構造を初期化する、半分のいくつかのシリアル・ラインを送受信してください。 線が持って来られるたびにそれを呼ばなければなりません。
void
sl_compress_init(comp)
struct slcompress *comp;
{
register u_int i;
register struct cstate *tstate = comp->tstate;
sl_湿布_イニット(コンピュータ)struct slcompress*コンピュータを欠如させてください。 u_int iを登録してください; tstateにstruct cstate*tstate=コンピュータ->を登録してください。
/*
* Clean out any junk left from the last time line was used.
*/
bzero((char *) comp, sizeof(*comp));
/*
* Link the transmit states into a circular list.
*/
for (i = MAX_STATES - 1; i > 0; --i) {
tstate[i].cs_id = i;
tstate[i].cs_next = &tstate[i - 1];
}
tstate[0].cs_next = &tstate[MAX_STATES - 1];
tstate[0].cs_id = 0;
comp->last_cs = &tstate[0];
/*
* Make sure we don't accidentally do CID compression
* (assumes MAX_STATES < 255).
*/
comp->last_recv = 255;
comp->last_xmit = 255;
}
/**は線が使用された最後の時から残っているどんなくずも一掃します。 */bzero(炭*)コンピュータ、sizeof(*コンピュータ)。 /**リンク、循環リストの中に州を伝えてください。 *(i=マックス_STATES--1(i>0)--i)tstate[i].cs_イド=i; tstate[i].cs_次の=とtstate[i--1];tstate[0].cs_次の=とtstate[マックス_STATES--1]のための/。 tstate[0].cs_イド=0。 コンピュータ->最後の_Cs=とtstate[0]。 /**は、私たちが偶然圧縮*(マックス_STATESが<255であると仮定します)をCIDにしないのを確実にします。 */コンピュータ>最終_recv=255。 コンピュータ>最終_xmit=255。 }
A.5 Berkeley Unix dependencies
A.5バークレーUnixの依存
Note: The following is of interest only if you are trying to bring the sample code up on a system that is not derived from 4BSD (Berkeley Unix).
以下に注意してください。 あなたが4BSD(バークレーUnix)から得られないシステムの上でサンプルコードを持って来ようとしている場合にだけ、以下は興味があります。
The code uses the normal Berkeley Unix header files (from /usr/include/netinet) for definitions of the structure of IP and TCP headers. The structure tags tend to follow the protocol RFCs closely and should be obvious even if you do not have access to a 4BSD system./48/
コードはIPとTCPヘッダーの構造の定義に、正常なバークレーUnixヘッダーファイル(/usr/から、/netinetを含める)を使用します。 構造タグは、密接にプロトコルRFCsに続く傾向があって、あなたがa4BSDシステム/48/に近づく手段を持たないでも、明白であるべきです。
----------------------------
48. In the event they are not obvious, the header files (and all the
Berkeley networking code) can be anonymous ftp'd from host
---------------------------- 48. 出来事では、それらが明白でない、ヘッダーファイル(そして、すべてのバークレーネットワークコード)がアノニマスFTPであるかもしれない、ホストから、そうするでしょう。
Jacobson [Page 41] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[41ページ]RFC1144
The macro BCOPY(src, dst, amt) is invoked to copy amt bytes from src to dst. In BSD, it translates into a call to bcopy. If you have the misfortune to be running System-V Unix, it can be translated into a call to memcpy. The macro OVBCOPY(src, dst, amt) is used to copy when src and dst overlap (i.e., when doing the 4-byte alignment copy). In the BSD kernel, it translates into a call to ovbcopy. Since AT&T botched the definition of memcpy, this should probably translate into a copy loop under System-V.
マクロBCOPY(src、dst、amt)は、srcからdstまでamtバイトをコピーするために呼び出されます。 BSDでは、それはbcopyへの呼び出しに翻訳されます。 System-V Unixを走らせている不運がありましたら、memcpyへの呼び出しにそれを翻訳できます。 srcとdstが重なるとき(すなわち、4バイトの整列コピーをするとき)、マクロOVBCOPY(src、dst、amt)は、コピーするのに使用されます。 BSDカーネルでは、それはovbcopyへの呼び出しに翻訳されます。 AT&Tがmemcpyの定義についてやりそこなったので、これはたぶんSystem-Vの下のコピー輪に翻訳されるべきです。
The macro BCMP(src, dst, amt) is invoked to compare amt bytes of src and dst for equality. In BSD, it translates into a call to bcmp. In System-V, it can be translated into a call to memcmp or you can write a routine to do the compare. The routine should return zero if all bytes of src and dst are equal and non-zero otherwise.
マクロBCMP(src、dst、amt)は、平等のためにamtバイトのsrcとdstを比較するために呼び出されます。 BSDでは、それはbcmpへの呼び出しに翻訳されます。 System-Vでは、memcmpへの呼び出しにそれを翻訳できるか、またはするルーチンを書くことができる、比較してください。 そうでなければ、すべてのバイトのsrcとdstが等しい、そして、非ゼロに合わせるなら、ルーチンはゼロを返すべきです。
The routine ntohl(dat) converts (4 byte) long dat from network byte
order to host byte order. On a reasonable cpu this can be the no-op
macro:
#define ntohl(dat) (dat)
通常のntohl(dat)はネットワークバイトオーダーからホストバイトオーダーまで長さ(4バイト)のdatを変換します。 妥当なcpuでは、これはオプアートがないマクロであるかもしれません: #ntohl(dat)を定義してください。(dat)
On a Vax or IBM PC (or anything with Intel byte order), you will have to define a macro or routine to rearrange bytes.
バックスかIBM PC(または、インテルバイトオーダーがある何でも)の上では、あなたは、バイトを再配列するためにマクロかルーチンを定義しなければならないでしょう。
The routine ntohs(dat) is like ntohl but converts (2 byte) shorts instead of longs. The routines htonl(dat) and htons(dat) do the inverse transform (host to network byte order) for longs and shorts.
ntohs(dat)の代わりにntohlにもかかわらず、転向者(2バイト)半ズボンに似ているルーチンは切望します。 ルーチンのhtonl(dat)とhtons(dat)は長さと半ズボンのために逆さの変換をします(ネットワークバイトオーダーに、接待します)。
A struct mbuf is used in the call to sl_compress_tcp because that routine needs to modify both the start address and length if the incoming packet is compressed. In BSD, an mbuf is the kernel's buffer management structure. If other systems, the following definition should be sufficient:
入って来るパケットが圧縮されるならそのルーチンが、開始アドレスと長さの両方を変更する必要があるので、struct mbufは呼び出しにsl_湿布_tcpに使用されます。 BSDでは、mbufはカーネルのバッファ経営組織です。 他のシステムであるなら、以下の定義は十分であるべきです:
struct mbuf {
u_char *m_off; /* pointer to start of data */
int m_len; /* length of data */
};
struct mbuf、データ*/の; データ*/int m_lenの始まりへの/*ポインタ;/*長さのu_炭*のm_。
#define mtod(m, t) ((t)(m->m_off))
#mtod(m、t)を定義してください。((t)、(m->、m、_下に)
---------------------------- ucbarpa.berkeley.edu, files pub/4.3/tcp.tar and pub/4.3/inet.tar.
---------------------------- ucbarpa.berkeley.edu、ファイルパブ/4.3/tcp.tarとパブ/4.3/inet.tar。
Jacobson [Page 42] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[42ページ]RFC1144
B Compatibility with past mistakes
過去の誤りとのBの互換性
When combined with the modern PPP serial line protocol[9], the use of header compression is automatic and invisible to the user. Unfortunately, many sites have existing users of the SLIP described in [12] which doesn't allow for different protocol types to distinguish header compressed packets from IP packets or for version numbers or an option exchange that could be used to automatically negotiate header compression.
現代のPPPシリアル・ラインプロトコル[9]に結合されると、ユーザにとって、ヘッダー圧縮の使用は、自動であって、目に見えません。 残念ながら、多くのサイトで、自動的にヘッダー圧縮を交渉するのに使用できた異なったプロトコルタイプがIPパケットとヘッダーの圧縮されたパケットを区別するのを許容しない[12]かバージョン番号かオプション取引のためにSLIPの既存のユーザについて説明します。
The author has used the following tricks to allow header compressed SLIP to interoperate with the existing servers and clients. Note that these are hacks for compatibility with past mistakes and should be offensive to any right thinking person. They are offered solely to ease the pain of running SLIP while users wait patiently for vendors to release PPP.
作者はヘッダーの圧縮されたSLIPが既存のサーバとクライアントと共に共同利用するのを許容する以下のトリックを使用しました。 これらが過去の誤りとの互換性のためのハッキングであり、正しいどんな考え深い人にとっても、不快であるべきであることに注意してください。 唯一ユーザが、業者がPPPをリリースするのを我慢強く待っている間、走行SLIPの痛みを緩和するためにそれらを提供します。
B.1 Living without a framing `type' byte
縁どり'タイプ'バイトなしで生きるB.1
The bizarre packet type numbers in sec. A.1 were chosen to allow a `packet type' to be sent on lines where it is undesirable or impossible to add an explicit type byte. Note that the first byte of an IP packet always contains `4' (the IP protocol version) in the top four bits. And that the most significant bit of the first byte of the compressed header is ignored. Using the packet types in sec. A.1, the type can be encoded in the most significant bits of the outgoing packet using the code
秒の奇妙なパケット形式数 A.1は、'パケットタイプ'が明白なタイプバイトを加えるのが望ましくないか、または不可能である線に送られるのを許容するために選ばれました。 IPパケットの最初のバイトが4ビットの先端にいつも'4'(IPプロトコルバージョン)を保管していることに注意してください。 そして、圧縮されたヘッダーの最初のバイトのその最も重要なビットは無視されます。 パケットを使用するのは秒のときにタイプされます。 A.1、出発しているパケットの最も重要なビットでコードを使用することでタイプをコード化できます。
p->dat[0] |= sl_compress_tcp(p, comp);
p->、dat[0]|= sl_湿布_tcp(p、コンピュータ)。
and decoded on the receive side by
解読される、側を受け取ります。
if (p->dat[0] & 0x80)
type = TYPE_COMPRESSED_TCP;
else if (p->dat[0] >= 0x70) {
type = TYPE_UNCOMPRESSED_TCP;
p->dat[0] &=~ 0x30;
} else
type = TYPE_IP;
status = sl_uncompress_tcp(p, type, comp);
(p->dat[0]と0x80)であるなら、=TYPE_COMPRESSED_TCPをタイプしてください。 ほか、(dat[0]>=0x70) タイプ=_TYPE_UNCOMPRESSED TCP; p->dat[0]と=~0x30;がほかのタイプするp->はTYPE_IPと等しいです。 sl状態=_は_tcp(p、タイプ、コンピュータ)を解凍します。
B.2 Backwards compatible SLIP servers
B.2の遅れているコンパチブルSLIPサーバ
The SLIP described in [12] doesn't include any mechanism that could be used to automatically negotiate header compression. It would be nice to
[12]で説明されたSLIPは自動的にヘッダー圧縮を交渉するのに使用できたどんなメカニズムも含んでいません。 それは良いでしょう。
Jacobson [Page 43] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[43ページ]RFC1144
allow users of this SLIP to use header compression but, when users of the two SLIP varients share a common server, it would be annoying and difficult to manually configure both ends of each connection to enable compression. The following procedure can be used to avoid manual configuration.
しかし、圧縮を可能にするために手動でそれぞれの接続の両端を構成するのが2SLIP varientsのユーザが一般的なサーバを共有して、煩わしくて、難しいだろうというときに、ヘッダー圧縮を使用するこのSLIPのユーザを許容します。 手動の構成を避けるのに以下の手順を用いることができます。
Since there are two types of dial-in clients (those that implement compression and those that don't) but one server for both types, it's clear that the server will be reconfiguring for each new client session but clients change configuration seldom if ever. If manual configuration has to be done, it should be done on the side that changes infrequently --- the client. This suggests that the server should somehow learn from the client whether to use header compression. Assuming symmetry (i.e., if compression is used at all it should be used both directions) the server can use the receipt of a compressed packet from some client to indicate that it can send compressed packets to that client. This leads to the following algorithm:
両方のタイプのためのダイヤルインのクライアント(圧縮を実行するものとそうしないそれら)にもかかわらず、1つのサーバの2つのタイプがあるので、サーバがそれぞれの新しいクライアントセッションのための再構成であることは明確ですが、かつてなら、クライアントはめったに構成を変えません。手動の構成が完了していなければならないなら、まれに変化する側でそれをするべきです。--- クライアント。 これは、サーバが、クライアントからヘッダー圧縮を使用するかどうかどうにか学ぶべきであると示唆します。 対称を仮定する、(すなわち、圧縮が全く使用されて、それが使用されるべきであるということであるなら、両方の指示) サーバは、圧縮されたパケットをそのクライアントに送ることができるのを示すのにクライアントから圧縮されたパケットの領収書を使用できます。 これは以下のアルゴリズムに通じます:
There are two bits per line to control header compression: allowed and on. If on is set, compressed packets are sent, otherwise not. If allowed is set, compressed packets can be received and, if an UNCOMPRESSED_TCP packet arrives when on is clear, on will be set./49/ If a compressed packet arrives when allowed is clear, it will be ignored.
ヘッダー圧縮を制御するために、1線あたり2ビットがあります: 許容されていてオンです。 オンであるなら、設定されて、圧縮されて、パケットは、送られて、そうでなければ、そうしていません。 _設定されて、圧縮されて、許容するなら、パケットを受け取ることができます、そして、オンであるときに、UNCOMPRESSEDであるなら、TCPパケットは到着します。明確であり、意志に設定される、許容されていると圧縮されたパケットが到着するなら/49/が明確である、それは無視されるでしょう。
Clients are configured with both bits set (allowed is always set if on is set) and the server starts each session with allowed set and on clear. The first compressed packet from the client (which must be a UNCOMPRESSED_TCP packet) turns on compression for the server.
オンであるなら、いつもセットがあります。クライアントがセットした両方のビットによって構成される、(許容、セット)そして、許容セットでオンの各セッションがクリアするサーバ始め。 クライアント(UNCOMPRESSED_TCPパケットであるに違いない)からの最初の圧縮されたパケットはサーバのための圧縮をつけます。
----------------------------
49. Since [12] framing doesn't include error detection, one should be
careful not to `false trigger' compression on the server. The
UNCOMPRESSED_TCP packet should checked for consistency (e.g., IP
checksum correctness) before compression is enabled. Arrival of
COMPRESSED_TCP packets should not be used to enable compression.
---------------------------- 49. [12] 縁どりが誤り検出を含んでいないので、サーバでどんな'偽の引き金'圧縮にも慎重であるはずがありません。圧縮が可能にされる前に_TCPパケットがそうするべきであるUNCOMPRESSEDは一貫性(例えば、IPチェックサムの正当性)がないかどうかチェックしました。 圧縮を可能にするのにCOMPRESSED_TCPパケットの到着を使用するべきではありません。
Jacobson [Page 44] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[44ページ]RFC1144
C More aggressive compression
Cで、より攻撃的な圧縮
As noted in sec. 3.2.2, easily detected patterns exist in the stream of compressed headers, indicating that more compression could be done. Would this be worthwhile?
秒では、有名です。 3.2.2 より多くの圧縮ができたのを示して、容易に検出されたパターンは圧縮されたヘッダーの流れで存在しています。 これ価値があるでしょうか?
The average compressed datagram has only seven bits of header./50/ The framing must be at least one bit (to encode the `type') and will probably be more like two to three bytes. In most interesting cases there will be at least one byte of data. Finally, the end-to-end check---the TCP checksum---must be passed through unmodified./51/
平均した圧縮されたデータグラムには、ヘッダー少なくとも1つが噛み付かれたなら('タイプ'をコード化する)縁どりがそうしなければならない/50/の7ビットしかありません、そして、たぶん、さらに2〜3バイトに似るでしょう。 ほとんどのおもしろい場合には、少なくとも1バイトのデータがあるでしょう。 最終的に終わりから終わりへのチェック---TCPチェックサム---変更されていなく通り抜けなければならない、/51/
The framing, data and checksum will remain even if the header is completely compressed out so the change in average packet size is, at best, four bytes down to three bytes and one bit --- roughly a 25% improvement in delay./52/ While this may seem significant, on a 2400 bps line it means that typing echo response takes 25 rather than 29 ms. At the present stage of human evolution, this difference is not detectable.
ヘッダーが平均したパケットサイズにおける変化がせいぜい4バイトである3バイトとあるビットまでの外に完全に圧縮されても、縁どり、データ、およびチェックサムは残るでしょう。--- これが重要に見えるかもしれない間のおよそ遅れ/52/での25%の改良であり、人類の進化の現段階でありエコー応答をタイプして、29原稿Atよりむしろ25を取るそれが意味する2400年のビーピーエス線ではこの違いは検出可能ではありません。
However, the author sheepishly admits to perverting this compression scheme for a very special case data-acquisition problem: We had an instrument and control package floating at 200KV, communicating with ground level via a telemetry system. For many reasons (multiplexed communication, pipelining, error recovery, availability of well tested implementations, etc.), it was convenient to talk to the package using TCP/IP. However, since the primary use of the telemetry link was data acquisition, it was designed with an uplink channel capacity <0.5% the downlink's. To meet application delay budgets, data packets were 100 bytes and, since TCP acks every other packet, the relative uplink bandwidth for acks is a/200 where `a' is the total size of ack packets. Using the scheme in this paper, the smallest ack is four bytes which would imply an uplink bandwidth 2% of the downlink. This wasn't
しかしながら、作者は、非常に特別なケースデータ取得問題でこの圧縮技術を曲解することを内気に認めます: 地表面で遠隔測定システムで交信して、私たちは200KVに器具とコントロールパッケージを浮かばせました。 種々の理由で(コミュニケーション、パイプライン処理、エラー回復、よくテストされた実現の有用性などを多重送信する)、TCP/IPを使用するパッケージと話すのは便利でした。 しかしながら、それは、遠隔測定法のリンクの第一の使用がデータ取得であったので、アップリンクチャネル容量<で0.5%設計されました。ダウンリンクのもの そして、データ・パケットがアプリケーション遅れ予算に間に合うためには100バイトであった、TCP acks、他のあらゆるパケット、acksのための相対的なアップリンク帯域幅は'a'がackパケットの総サイズであるa/200です。 この紙で計画を使用して、最も小さいackはダウンリンクのアップリンク帯域幅2%を含意する4バイトです。 これはそうではありませんでした。
----------------------------
50. Tests run with several million packets from a mixed traffic load
(i.e., statistics kept on a year's traffic from my home to work) show
that 80% of packets use one of the two special encodings and, thus, the
only header is the change mask.
51. If someone tries to sell you a scheme that compresses the TCP
checksum `Just say no'. Some poor fool has yet to have the sad
experience that reveals the end-to-end argument is gospel truth. Worse,
since the fool is subverting your end-to-end error check, you may pay
the price for this education and they will be none the wiser. What does
it profit a man to gain two byte times of delay and lose peace of mind?
52. Note again that we must be concerned about interactive delay to be
making this argument: Bulk data transfer performance will be dominated
by the time to send the data and the difference between three and four
byte headers on a datagram containing tens or hundreds of data bytes is,
practically, no difference.
---------------------------- 50. 数100万のパケットで複雑なトラヒック負荷(すなわち、統計は我が家からの1年間の交通のときに働くために保たれた)から走ったテストは、2の特別なencodingsとその結果、唯一のヘッダーの使用1が変化マスクであることをその80%のパケットに示します。 51. 'いいえとただ言ってください'だれかがTCPチェックサムを圧縮する計画をあなたに販売しようとするなら。 貧しい馬鹿には、終わりから終わりへの議論が絶対的真理であることを明らかにする悲しい経験がまだありません。 よりひどく、馬鹿が終わりから終わりへのあなたのエラーチェックを打倒しているので、あなたはこの教育の価格を支払うことができます、そして、彼らは、より賢明にならないでしょう。 それは、どう遅れの利得の2バイトの倍に男性の利益になって、心の平静を失いますか? 52. 私たちがこの議論に作っている対話的な遅れに関して心配していなければならないことにもう一度注意してください: バルク・データ転送性能は10を含むデータグラムか何百データ・バイトで3〜4バイトのヘッダーをデータと違いに送るのが、実際に違いでないまでに支配されるでしょう。
Jacobson [Page 45] RFC 1144 Compressing TCP/IP Headers February 1990
1990年2月にTCP/IPヘッダーを圧縮するジェーコブソン[45ページ]RFC1144
possible so we used the scheme described in footnote 15: If the first bit of the frame was one, it meant `same compressed header as last time'. Otherwise the next two bits gave one of the types described in sec. 3.2. Since the link had excellent forward error correction and traffic made only a single hop, the TCP checksum was compressed out (blush!) of the `same header' packet types/53/ so the total header size for these packets was one bit. Over several months of operation, more than 99% of the 40 byte TCP/IP headers were compressed down to one bit./54/
可能したがって、私たちが脚注15で説明された計画を使用したのを: フレームの最初のビットが1であったなら、それは'最後の時間と同じ圧縮されたヘッダー'を意味しました。 さもなければ、次の2ビットは秒のときに説明されたタイプのひとりに与えました。 3.2. リンクには素晴らしい前進型誤信号訂正があって、交通が単一のホップだけを作ったので、TCPチェックサムが'同じヘッダー'パケットtypes/53/の外(赤くしてください!)に圧縮されたので、これらのパケットのための総ヘッダーサイズはあるビットでした。 数カ月の操作の上に、40バイトのTCP/IPヘッダーの99%以上は1ビット/54/まで圧縮されました。
D Security Considerations
Dセキュリティ問題
Security considerations are not addressed in this memo.
セキュリティ問題はこのメモに記述されません。
E Author's address
E作者のアドレス
Address: Van Jacobson
Real Time Systems Group
Mail Stop 46A
Lawrence Berkeley Laboratory
Berkeley, CA 94720
アドレス: ヴァンジェーコブソンReal Time Systemsはメール停止46Aローレンスバークレイ研究所バークレー、カリフォルニア 94720を分類します。
Phone: Use email (author ignores his phone)
以下に電話をしてください。 メールを使用してください。(作者は彼の電話を無視します)
EMail: van@helios.ee.lbl.gov
メール: van@helios.ee.lbl.gov
----------------------------
53. The checksum was re-generated in the decompressor and, of course,
the `toss' logic was made considerably more aggressive to prevent error
propagation.
54. We have heard the suggestion that `real-time' needs require
abandoning TCP/IP in favor of a `light-weight' protocol with smaller
headers. It is difficult to envision a protocol that averages less than
one header bit per packet.
---------------------------- 53. 減圧装置でチェックサムを作り直しました、そして、もちろん、'トス'論理を誤り伝播を防ぐためにかなり攻撃的にしました。 54. 私たちは'リアルタイムで'の必要性が、より小さいヘッダーとの'軽量'のプロトコルを支持してTCP/IPを捨てるのを必要とするという提案を聞きました。 1パケットあたり1ヘッダービット未満を平均するプロトコルを思い描くのは難しいです。
Jacobson [Page 46]
ジェーコブソン[46ページ]
一覧
スポンサーリンク
