Edit

Page

Page title:

Page body:

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

* 仕様書

[REFS[
- [2] '''[CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229>'''
-- [6] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-6>
-- [9] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-10.1>
-- [11] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-10.3>
-- [18] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#section-10.5.3>
]REFS]

* プロトコル

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

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

[5] [[差分符号化]]では次の[[プロトコル要素]]が使われます。
[FIG(short list)[
- [CODE(HTTP)@en[[[IM:]]]]
- [CODE(HTTP)@en[[[A-IM:]]]]
- [CODE(HTTP)@en[[[Delta-Base:]]]]
- [CODE(HTTP)@en[[[226]]]]
- [CODE(HTTP)@en[[[Cache-Control: im]]]]
- [CODE(HTTP)@en[[[Cache-Control: retain]]]]
]FIG]

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

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

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

[26] 次の項目も参照。
[FIG(short list)[
- [[実現値]]
- [[実現値操作]]
- [[実体タグ]]
]FIG]

* 差分符号化の一覧

[10] [[差分符号化]]は[[実現値操作]]のうち次のものとされています [SRC[>>9]]。
[FIG(short list)[
- [CODE(HTTP)@en[[[vcdiff]]]]
- [CODE(HTTP)@en[[[gdiff]]]]
- [CODE(HTTP)@en[[[diffe]]]]
]FIG]

* 処理モデル

[12] [[鯖]]は、次の条件を''すべて''満たす時、[[差分符号化]]した[[応答]]を返さなければ[['''なりません''']] [SRC[>>11]]。
[FIG(list)[
- [13] [CODE(HTTP)[[[200]]]] [[応答]]を返すことができる状況である
- [14] [[要求]]の [CODE(HTTP)@en[[[A-IM:]]]] で[[差分符号化]]が指定されている
- [15] [[要求]]の [CODE(HTTP)@en[[[If-None-Match:]]]] で当該[[要求URL]]の[[実現値]]について[[妥当]]な[[実体タグ]]を最低1つは含んでいる
]FIG]

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

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

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

* 歴史

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

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

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

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

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

[901] [CITE@en[120393 – ''''''[''''''RFE'''''']'''''' support Proposed Standard Protocol RFC 3229: Delta encoding in HTTP (compatible extension to HTTP/1.1)]]
( ([TIME[2014-11-23 00:53:57 +09:00]] 版))
<https://bugzilla.mozilla.org/show_bug.cgi?id=120393>

[902] [CITE[Efficiently compressing dynamically generated web content]]
( ([TIME[2014-11-23 00:56:53 +09:00]] 版))
<http://blog.cloudflare.com/efficiently-compressing-dynamically-generated-53805/>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)