差分符号化

差分符号化 (HTTP)

[1] 差分符号化 (delta encoding) は、 複数の実現値差分を求め転送することによってキャッシュ項目を更新させる仕組みです。

仕様書

プロトコル

[3] RFC 3229HTTP の標準のキャッシュの更新の仕組み (条件付き要求) は 100% (200) と 0% (304) の転送しかなく、実際には部分的な更新のことが多いため効率的ではないとして、 差分のみを転送する仕組みを提案していました。

[4] ただし同 RFC はそのために差分のみならず範囲要求圧縮も統合した実現値操作なる概念を導入するよう HTTPプロトコルに過大に手を入れるものでした。

[5] 差分符号化では次のプロトコル要素が使われます。

[7] RFC 3229差分符号化法として diff -ediff -e + gzipvcdiff を紹介しつつ、特定の方法を推奨するものではなく、とはいえ A-IM: が長くなるのは好ましくないことから一定期間後に推奨形式を決めるべき >>6 と述べていました。

[8] しかし現在までそのような決定は行われていないようです。

[17] 差分符号化は、2入力の実現値操作です >>18

[26] 次の項目も参照。

差分符号化の一覧

[10] 差分符号化実現値操作のうち次のものとされています >>9

処理モデル

[12] は、次の条件をすべて満たす時、差分符号化した応答を返さなければなりません >>11

[16] 差分符号化された応答は、 226 状態符号を使わなければなりません >>11

[19] キャッシュにおける処理については、226 を参照。

[20] 内容符号化との関係については、内容符号化を参照。

歴史

[21] 差分符号化を含む実現値操作は、関連仕様の RFC 3230 と共に、 RFC 3229 として出版されました。

[22] 同時期に開発されていた差分符号化法である VCDIFF も少し遅れて RFC 3284 として出版されています。

[23] しかしこれらはその当初の規定の範囲ではほとんど実装されませんでした。 VCDIFF特許問題により忌避されたこと、 実現値操作の仕組みが複雑なこと、 差分の生成のために過去の基底実現値を (すべてでは無いにせよ、十分多く、 十分長期間) 保持し続けなければならないこと (キャッシュも。)、 といった課題に対して、差分によって転送量を削減することによる費用対効果が本当にあったのかは、 時点でも疑問が残ります。

[24] 頃の Web 2.0 時代、 フィードページングの指定手法として注目されることになります。 これは要求A-IM: feed と指定することにより、 フィードに含まれるエントリーのうち If-None-Match: で指定された時点より後のもののみを応答に含めることを求めるものでした。 A-IM: feed

[25] この手法はフィードリーダーフィードを提供するには比較的広く実装されました。 しかしフィードに特化した方式であり、その他の汎用的な実装には広まってゆきませんでした。 そのため、 Web 2.0 ブームの終焉により、実装も利用頻度も減少していると思われます。

[901] 120393 – [RFE] support Proposed Standard Protocol RFC 3229: Delta encoding in HTTP (compatible extension to HTTP/1.1) ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=120393

[902] Efficiently compressing dynamically generated web content ( ( 版)) http://blog.cloudflare.com/efficiently-compressing-dynamically-generated-53805/