要約

  • RFC 2395は2,048バイトのLZSスライディング窓を一つのデータグラム内に閉じ込め、送信前と受信復号前に履歴を必ず初期化した。
  • 毎回のフラッシュは入力の持ち越しを防ぎ、終了マーカーはパディングとの境界を示したが、配送・完全性・認証の証明ではなかった。
  • 約90バイトという目安とCalgary Corpusの比率は限定された測定であり、変換の合意、実際の使用、サイズ削減、復号成功、アプリケーション成果を一つにはしなかった。

届かなかった一枚を、次の一枚に背負わせない

LZSは直前の2,048バイトから繰り返しを探し、同じ並びをオフセットと長さの短い表現へ置き換える。連続ストリームなら、履歴を長く保つほど候補は増える。しかしIPは、その履歴が期待する配送順を保証しない。

第2データグラムが第1データグラムで作られた辞書を参照していれば、第1だけを失った事故が第2の復号も壊す。第3も同じ履歴を使えば、故障はさらに伸びる。圧縮器が下位層に存在しない約束を追加したことになる。

RFC 2395は、各payloadを圧縮する前に送信履歴をリセットし、圧縮された各payloadを読む前に受信履歴もリセットするよう定めた。窓は一つのデータグラムだけを見る。順序が逆でも、前が失われても、到着した一枚は単独で解ける。

代償は跨パケットの重複を捨てることだった。短いパケットでは特に不利になる。それでも損失範囲を一枚に限定する方が、理想状態だけの比率より価値があると判断された。

RFC 1967とRFC 1974のPPP向けLZSは、履歴番号や同期回復を持ち得る。同じLZSという名前でも状態寿命は同じではない。アルゴリズムが記憶を提供し、適用プロファイルがその権限を決める。

フラッシュは「次回に借りを残さない」という意味だった

履歴を初期化しても、ストリーム圧縮器はより良い符号を待って出力の一部を内部に残すことがある。データグラムでそれを行えば、現在のpayloadが未来のパケットにまたがる。

そこで送信時のフラッシュが必須になった。今の入力は今の出力にすべて含まれなければならない。次のデータグラムに期待して保持してはならない。

ただし、フラッシュが証明するのは符号器内部の完了だけだ。ネットワーク到着、復号器の受理、上位チェック、アプリケーション処理は別である。「全部出した」を「相手が使った」に置き換えることはできない。

終了マーカーが閉じたのはビット列だった

LZSの符号は必ずしもオクテット境界で終わらない。RFC 2395は終了マーカーを定め、その後のビットやバイトをパディングとして区別した。送信payload全体は整数オクテット長を保つ。

このマーカーは構文の終端であって、ハッシュでも署名でもない。送信者、改変の有無、元の意味、処理の成功を保証しない。正しく終わる悪意ある列も作れる。答えるのは「LZS命令がどこで終わるか」だけだ。

RFC 2407の協商空間にLZS変換識別子が置かれたことも、圧縮を暗号機能に変えない。IPCOMP_LZSは復号方法を選ぶための名前であり、認証や機密性ではない。

合意済みでも、圧縮しないパケットは正しい

RFC 2395はISAKMP用のLZS変換IDと手動設定用CPIを示し、追加のLZS固有属性を要求しなかった。それでもIPCompはパケットごとに判断する。圧縮payloadとヘッダーの合計が元より小さくなければ、元の形式をヘッダーなしで送る。

RFC 3173はRFC 2393を置き換えた後もこの非膨張原則を維持した。したがってIPCompヘッダーがないことは協商失敗ではない。ヘッダーがあることも復号成功ではない。合意、選択、符号、復号、利用結果には別の記録が要る。

またLZS自体には適応的な圧縮可能性試験がなかった。実装が過去の結果から試行を省くことはできるが、それはローカル方針であり、共有アルゴリズムの自動判断ではない。

90バイトには実験名が付いていた

Calgary Corpusを使った非公式試験では、およそ90バイト未満で平均的に膨張し得るため、それ以下を試さない選択肢が示された。付録の比率は64バイトで1.18、16,384バイトで2.14だった。

毎回窓を消す以上、長い一枚ほど同じ境界内で反復を見つけやすい。固定費も相対的に小さくなる。しかしCalgary Corpusは暗号文でも、既圧縮画像でも、現代の全通信でもない。90はwire上の定数ではなく、ローカル測定を始めるための手掛かりだった。

RFC 2394のDEFLATE、後のRFC 3051の別辞書方式は、それぞれ異なる実装条件を持つ。RFC 3819も既圧縮・暗号化データへの再圧縮効果が乏しいと注意した。名前ではなく実データを測る必要がある。

採用条件はビット形式だけではなかった

RFC 2395は当時Hi/fnがLZS特許を保有すると述べ、ライセンス形態を説明した。相互運用形式とは別に、実装者の採用判断へ作用する条件だった。

この記述は1998年の歴史資料として扱うべきで、現在の権利者、存続、価格、入手可能性を証明しない。古いRFCは法律状態を自動更新しない。

共有層が定めたのは、リセット、フラッシュ、符号、終端という最小部分だった。閾値、負荷、法的評価、採用はローカル判断に残った。実際のパケットとアプリケーション結果が、その判断を後から検証する。

忘却は制約ではなく、故障範囲の設計だった

状態を増やせば平均効率は上がるかもしれない。しかし下位層が保証しない状態依存は、見えない結合になる。RFC 2395は、圧縮器にネットワークの現実へ従わせた。

監査では、利用可能なアルゴリズム、成立した関連、実行されたリセット、個別パケットの選択、正しい終端、復号結果、アプリケーション成果を分ける。どれも隣の事実を代理できない。

出典