JP2015509293A - メッセージを符号化及び復号化する方法及びデバイス - Google Patents

メッセージを符号化及び復号化する方法及びデバイス Download PDF

Info

Publication number
JP2015509293A
JP2015509293A JP2014540413A JP2014540413A JP2015509293A JP 2015509293 A JP2015509293 A JP 2015509293A JP 2014540413 A JP2014540413 A JP 2014540413A JP 2014540413 A JP2014540413 A JP 2014540413A JP 2015509293 A JP2015509293 A JP 2015509293A
Authority
JP
Japan
Prior art keywords
information
indexed
header
index
binary
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014540413A
Other languages
English (en)
Other versions
JP6021930B2 (ja
Inventor
ロマン ベルソール,
ロマン ベルソール,
ユアン ファブレ,
ユアン ファブレ,
エルベ リューラン,
エルベ リューラン,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Publication of JP2015509293A publication Critical patent/JP2015509293A/ja
Application granted granted Critical
Publication of JP6021930B2 publication Critical patent/JP6021930B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3084Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3088Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing the use of a dictionary, e.g. LZ78
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

情報項目を含む各メッセージを符号化又は復号する方法及びデバイスである。符号化方法は、ローカルインデックステーブルにおいて既にインデックス化されている前記初期リストの情報項目と関連付けられたインデックスの第1のリスト、及び、前記ローカルインデックステーブルにおいてまだインデックス化されていない前記初期リストの他の情報項目のリテラル値の第2のリストを判定するステップと、その第1のリストのインデックスを符号化するステップと、前記第2のリストの前記リテラル値の少なくともシリアル化バイナリ表現をバイナリ圧縮するステップと、第1のリスト及び前記第2のリストを共に連結して前記情報項目の符号化ビットストリームを得るステップとを備える。そして、メッセージが複数の接続を介して送信されるとき、接続間でグローバルテーブルを共有して、情報のインデックス化された項目を記憶する。そして各接続ごとのローカルインデックステーブルが、共有グローバルテーブルのエントリに関するインデックスと関連付けられる。【選択図】 図3

Description

本発明は、メッセージを符号化及び復号化する方法、並びに対応する符号化デバイス及び復号化デバイスに関する。
本発明は、ネットワーク通信の分野、特に通信ネットワークを介してメッセージを送出する際に使用されるデータ圧縮の分野に属する。
送出対象のメッセージには、多くの場合、符号器において圧縮され且つ復号器において伸張される情報の項目のリスト又はグループがある。例えばこれは、HTTP(ハイパーテキスト転送プロトコルの略である)ペイロードが圧縮されるHTTP及びHTTPヘッダが圧縮されるSPDYプロトコルの場合である。
SPDYは、周知のHTTPの改良を意図するプロトコルである。本発明を例示するために以下においてSPDYプロトコルを参照するが、本発明は他の構成に適用されてもよい。特に、本発明は、情報項目のリストが圧縮される多数のデータ送信プロトコル、例えば上述のHTTPプロトコル及びSPDYプロトコルに適用されてもよい。
HTTPは、一般にウェブページを要求及び送出するために使用され、クライアント/サーバアーキテクチャに基づく。クライアント/サーバアーキテクチャにおいて、クライアントは、要求、すなわちHTTP要求をサーバに送出し、サーバは、応答、すなわちHTTP応答によりクライアントの要求に応答する。
要求及び応答は、種々のパート、特に非圧縮HTTPヘッダ及び圧縮HTTPペイロードを含むメッセージである。
図1は、HTTP要求及び次にHTTP応答に連続的に一覧表示される6個のHTTPヘッダの一例を示す。
HTTPヘッダは、名前(図1における太文字)と、それに対応する値から構成される。
例えば「Host:en.wikipedia.org」において、Hostはヘッダ名であり、その値は「en.wikipedia.org」である。このヘッダは、要求されたリソースのホスト(例えば、http://en.wikipedia.org/wiki/HTTPにおいて使用可能なHTTPを記述するWikipediaのページ)を示すために使用される。HTTPヘッダは当業者には周知であるため、本明細書では更に詳細に説明しない。
HTTPの第1のバージョンにおいては、TCP/IP接続は、HTTP要求/応答の送受信毎に確立された。
SPDYは、いくつかの方法でHTTPを向上させるプロトコルである。
第1に、SPDYは、いくつかのHTTPの要求及び応答を一意のTCP/IP接続を介して送出できるようにすることにより、そこでHTTP送信の集合を規定する。このように、ウェブページの全ての構成要素(HTML文書、画像、JavaScript等)が同一のTCP/IP接続を共有することにより、ウェブページのロードを高速化され得る。
第2に、SPDYは、Zlibデフレートアルゴリズム(「zip」形式を通しても知られている)を使用して、共有されたTCP/IP接続を介して送受信されたHTTPヘッダの圧縮を実現する。このようなバイナリ圧縮によりネットワーク負荷を軽減する。
デフレートアルゴリズムは、バイナリ表現の重複ストリングを探索し(スライディングウィンドウを使用して)てそれをそのバックリファレンスで置換し、且つバックリファレンスの記号をハフマン符号で置換することにより、HTTPヘッダのシリアル化バイナリ表現の圧縮を実行する。
HTTPヘッダのシリアル化バイナリ表現は、HTTPヘッダのシリアル化の結果、ビット(又はバイト)のストリームとして得られる。
SPDYにより取得された圧縮ゲインは受け入れ可能となっている。
しかし、速度性能は不適切であると観察され、メモリ消費が不都合なほどに高くなる恐れがある。
不適切な速度性能は、多数のヘッダにより得られる潜在的に大きなサイズのシリアル化バイナリ表現に起因する。
HTTPサーバが同時に複数のクライアントに対して複数の接続を処理する場合、メモリ消費が高くなる恐れがある。特に接続数が増加する場合、すなわち1つの符号器又は圧縮器が各接続に割り当てられ、且つ専用のメモリ領域が符号器又は圧縮器毎に確保される場合、種々の接続を介して送信されたメモリのヘッダを個別に符号化するには大量のメモリが必要である。
例えば復号器側でメモリリソースの少ない制限されたデバイスと比較して、メモリ消費が高くなる恐れがある。
このような状況において、メモリコスト及び処理コストを実質的に削減しつつ同様の小型化を実現する情報項目(例えば、HTTPヘッダ)のリストを圧縮する新しい方法が必要である。実施形態において、そのような新しい方法は、高い圧縮性能を維持するためにデフレート等のバイナリ圧縮に準拠すべきである。
論文「A Proposal for Shared Dictionary Compression over HTTP」(J. Butler他、2008年)は、クロスペイロード冗長を、共有辞書を参照した冗長要素を置き換えることで、符号化するために使用される辞書を開示する。しかし、復号器は、少量のメモリを使用では、多数の符号化要素を迅速に復号化できない。
本発明は、上述の問題のうちの1つ以上に対処するために提案されるものである。
本発明の第1の態様では、情報の項目の初期リストを含むメッセージをビットストリームに符号化する方法であって、
ローカルインデックステーブルにおいて既にインデックス化されている初期リストの情報項目と関連付けられたインデックスの第1のグループ及び前記ローカルインデックステーブルにおいてまだインデックス化されていない初期リストの他の情報項目のリテラル値の第2のグループを判定するステップと、
第1のグループのインデックスを符号化するステップと、
第2のグループのリテラル値の少なくともシリアル化バイナリ表現をバイナリ圧縮するステップと、
第1のグループ及び第2のグループを共に連結して情報項目の符号化ビットストリームを取得するステップとを備える方法が提供される。
本発明は、HTTPヘッダの冗長性が高い場合、例えばSPDYの速さの2倍にまで処理速度を実質的に向上させる。更に本発明は、メモリ消費を改善させ得る。
これは、インデックス化ステップに基づいて従来のバイナリ圧縮及びグループ化の前に項目をインデックス化することで実現される。インデックス化により、符号器において限定されたメモリ使用量で非常に高速な冗長探索が可能になる一方で、復号器において、復号化は、情報項目がより高速に構築されることでより効率的になる。
これは、インデックス技術が非常に注目された冗長探索に基づくのに対し、デフレート等のバイナリ圧縮は、より低速な総当たり全数冗長探索を使用するためである。
従って、インデックスが同一のサブパート内でグループ化される符号化ビットストリームを提供することは、少数の符号化データを構文解析しつつ多数の情報項目、すなわちヘッダを復号化する復号器において処理を高速化する。
本発明の第2の態様は、第2の部分と連結された第1の部分を含む符号化データをビットストリームから取得するステップと、
第1の部分を復号化して、ローカルインデックステーブルにおいて既にインデックス化されている情報項目と関連付けられたインデックスの第1のグループを取得するステップと、
第2の部分をバイナリ伸張して、前記ローカルインデックステーブルにおいてまだインデックス化されていない情報項目に対応するリテラル値の第2のグループのシリアル化バイナリ表現を取得するステップと、
第1のグループのインデックスによりインデックス化情報項目及び第2のグループから文字通り復号化された情報項目から構成された復号化リストを提供するステップとを備える符号化メッセージを復号化する方法が提供される。
この方法は、上述の方法と同様の利点を提供するが、復号器においては提供しない。尚、第1のグループ及び第2のグループの情報項目、例えばHTTPヘッダは同時のものである。
本発明の第3の態様によると、情報の項目のリストを含むメッセージを符号化して複数の接続を介して送出する方法であって、
メッセージが属する接続専用のローカルインデックステーブルを使用してメッセージの情報項目のリストを符号化するステップを備え、
グローバルテーブルは、接続の間で共有され、情報の項目を含み、各接続のローカルインデックステーブルは、インデックスを共有グローバルテーブルのエントリに対する参照と関連付ける方法が提供される。
本発明のこの態様はメモリ消費を最適化する。これは、データ(本明細書においては情報項目)の大部分を格納するグローバルテーブルが、各情報項目を1回だけ格納できるようにする全ての接続の間で共有される一方で、インデックスが接続毎に最短のインデックスを提供する各接続に特有だからである。従って、グローバルテーブルにより、接続の間でインデックステーブルのメモリコストを共有することが可能になる。
逆に、本発明の第4の態様によると、複数の接続を介して受信された情報の項目の符号化リストを含む符号化メッセージを復号化する方法であって、
符号化メッセージが属する接続専用のローカルインデックステーブルを使用して符号化メッセージの情報項目の符号化リストを復号化するステップを備え、
グローバルテーブルは、全ての接続により共有され、情報の項目を含み、各接続のローカルインデックステーブルは、インデックスを共有グローバルテーブルのエントリに対する参照と関連付ける方法が提供される。
この方法は、上述の符号化方法と同様の利点を提供するが、復号器においては提供しない。
本発明の選択的な特徴は、添付の従属請求項において更に規定される。以下において、符号化又は圧縮に対してある特定の特徴を説明する時、符号器における対応する特徴が本発明の復号化又は伸張に対しても使用されてもよいことは、当業者により容易に理解されるだろう。
本発明の一実施形態によると、他の情報項目の少なくとも1つは、ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで符号化され、他の情報項目のリテラル値は、他の情報項目により取られた値と参照として既にインデックス化及び使用されている情報項目により取られた値との差分を示す。これは、後続のヘッダを符号化するために必要とされるデータの量を減少するための、ヘッダ(例えば、ヘッダ名)の間の部分的な冗長に基づく以下において規定されるようなデルタ符号化である。
特定の一実施形態において、他の情報項目に対応するシリアル化バイナリ表現のバイナリサブパートは、他の情報項目のリテラル値に加えて、参照として既にインデックス化及び使用されている情報項目のインデックスを含む。これは、デルタ復号化のために必要とされる情報を有する復号器を提供するためである。
特定の特徴によると、方法は、ローカルインデックステーブルにおいて既にインデックス化されている情報項目を、既にインデックス化されている情報を参照することで符号化された他の情報項目で置き換える(substitute)するステップを更に備える。この提供により、符号化が進行するにつれローカルインデックステーブルの増加は減少する。従って、それによりメモリを効率的に管理する。
本発明の別の実施形態によると、他の情報項目の1つに対応するシリアル化バイナリ表現のバイナリサブパートは、他の情報項目のリテラル値に加えて、他の情報項目がローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで符号化されるか否かを規定する第1の1ビットフラグと、他の情報項目が更なるインデックス化のためにローカルインデックステーブルに追加されなければならないか否かを規定する第2のバイナリインデックスフラグとを含む。従って、符号化ヘッダに対するこのバイナリ設計は、符号器と復号器との間で効率的なインデックスの同期を提供する。
特に、第2のバイナリフラグは、他の情報項目が、新しいエントリとして又は参照として既にインデックス化及び使用されている情報項目の置き換えによりローカルインデックステーブルに追加されなければならないかを規定するためのビットを含んでもよい。これは、置き換えインデックス化方式により効率的にメモリを管理しつつ、効率的なインデックスの同期に貢献する。
本発明の実施形態の特定の特徴によると、バイナリサブパートは、他の情報項目により取られた値と参照として既にインデックス化及び使用されている情報項目により取られた値との間の共通部分の長さを規定するためのバイナリフィールドを含む。これは、ヘッダの値の部分を符号化する効率的な方法であり、その符号化は、既にインデックス化されているヘッダを参照する(すなわち、部分的に)ことで行われる。これは、共通部分を規定することは、一般に、その共通部分を構成する値を明示的に又は文字通りに示すことと比較してビットを節約するからである。例えば共通部分は、比較される2つの値を形成する第1の文字(アルファベット又は数字)であってもよい。
特定の特徴によると、バイナリサブパートは、項目名テーブルにおける他の情報項目の名前に対応するインデックスを規定するためのバイナリフィールドを含む。名前テーブルがいくつかのインデックステーブルの間で容易に共有されうるため、一般に、名前テーブルを使用することでメモリが節約される。
本発明の一実施形態において、インデックスの第1のグループは、符号化ビットストリームにおけるリテラル値の第2のグループに先行する。復号器において、これは、インデックスを符号化する第1の部分は、ビットストリームの第2の部分(リテラル値の)に先行する。
この構成により、復号器により復号化する少数の符号化データを含む多数の情報項目、例えばSPDYにおけるHTTPヘッダにアクセスする。これは、各インデックス化情報項目を示す大部分のデータがローカルインデックステーブルに格納され、且つビットストリームにおいて符号化されないためである。
別の実施形態において、連結するステップは、連結された第1のグループ及び第2のグループのシリアル化バイナリ表現を生成し、バイナリ圧縮するステップは、シリアル化バイナリ表現全体を圧縮する。インデックスに対する冗長がシリアル化バイナリ表現でより多く発生するため、バイナリ圧縮のためのより短いスライディングウィンドウが使用されてもよい。より短いスライディングウィンドウは、メモリの節約(より少ないビットのバッファリング)及び処理速度の向上(より少ないビットの探索)を意味する。
更に別の実施形態において、情報の項目は、HTTPメッセージのHTTPヘッダである。これは、例えばSPDYの場合である。
特に、HTTPヘッダは、少なくともHTTP名及びHTTP値から構成され、第1のグループのインデックス化HTTPヘッダは、HTTP名をインデックス化するインデックス及びリテラルHTTP値を含む。これは、HTTPヘッダ名(一般に、連続したHTTPメッセージにおいて使用される)の間の高い冗長性を利用し、それらの値は、あるメッセージから別のメッセージに高度に変動してもよい。同一の方法は、名前及び値から構成されたあらゆる情報項目に対して使用されてもよい。
特定の特徴によると、HTTPヘッダは、少なくともHTTP名及びHTTP値から構成され、この方法は、インデックスレベルフラグをHTTPヘッダと関連付けるステップを有し、前記インデックスレベルフラグが、HTTPヘッダに依存して、HTTPヘッダがローカルインデックステーブルにおける対応する情報項目と同一のHTTP名及びHTTP値を有することを示す第1の完全なインデックス化状態、又はHTTPヘッダがローカルインデックステーブルにおける対応する情報項目と同一のHTTP名であるが異なるHTTP値を有することを示す第2の部分的なインデックス化状態を取ることを更に備える。これにより、徐々に変動するいくつかのHTTPヘッダの高い冗長性の利用が可能になる。例えば、いくつかのメッセージが単一の秒内で送出されてもよいため、毎秒更新された時間HTTPヘッダをインデックス化することが有利であってもよい。その後、後続の秒のメッセージに対して、フラグの部分的なインデックス化状態が使用される。
特に、HTTPヘッダは、第1のグループのインデックス化HTTPヘッダであってもよい。
特定の特徴によると、インデックス化HTTPヘッダに対するインデックスレベルフラグが第2の部分的なインデックス化状態である場合、インデックス化HTTPヘッダの異なるHTTP値は、異なるHTTP値とローカルインデックステーブルにおける対応する情報項目のHTTP値との差分を使用して符号化される。
本発明の別の実施形態において、この方法は、ローカルインデックステーブル内で第2のグループの少なくとも1つの情報項目を新しいインデックスと関連付けることにより、そのローカルインデックステーブルを更新するステップを更に備える。これにより、同一の情報項目の新しい出現がインデックス化されうるようにローカルインデックステーブルの供給が可能になる。
特に、この方法は、符号化ストリームにおいて、前記更新中に新しいインデックスと関連付けられる第2のグループのバイナリ圧縮された各情報項目とインデックスフラグを関連付けるステップを更に備えてもよい。これにより、復号器が認識していないかもしれないインデックス化戦略を復号器に示すことが可能になる。
別の特定の特徴によると、この方法は、第2のグループの情報の項目の出現の頻度を判定するステップと、判定された頻度に依存してローカルインデックステーブルにおいて情報の項目をインデックス化することを決定するステップとを更に備えてもよい。この提供により、最も多く出現する項目だけがインデックス化され、それにより、ローカルインデックステーブルを格納するために使用されたメモリとインデックスの使用による処理速度の向上との妥協が最適化される。
本発明の更に別の実施形態において、ローカルインデックステーブルは、前記インデックスと関連付けられた情報の項目を含むグローバルテーブルのエントリに対する参照と各インデックスを関連付ける。これにより、メッセージが送信されるいくつかの接続のために同一のグローバルテーブルの共有が可能になる。このような状況において、ローカルインデックステーブルは接続毎に使用される。
特定の特徴によると、ローカルインデックステーブルは、グローバルテーブルを参照することでインデックス化された情報の少なくとも1つの項目及びローカルインデックステーブル内でのみインデックス化された情報の少なくとも1つの項目を含む。いくつかの接続により共有されるある特定の情報項目又は非常に頻繁なある特定の情報項目(共有グローバルテーブルを参照することで格納されうる)を特定の接続専用のある特定の情報項目(その接続専用のローカルインデックステーブル内に格納されてもよい)と区別する改良されたインデックス化戦略が実現されてもよい。
特に、この方法は、情報の項目の出現の頻度を判定するステップと、判定された頻度に依存してローカルインデックステーブルにおいてのみ、又はグローバルテーブルを参照することで情報の前記項目をインデックス化することを決定するステップを更に備えてもよい。
別の特定の特徴によると、グローバルテーブルは、複数の圧縮器(複数の接続に対応する)の間で共有され、前記複数の圧縮器により処理されたメッセージからの情報の項目を含む。そして各圧縮器が、共有グローバルテーブルを参照することで、自身が処理するメッセージからの情報の項目をインデックス化するためにそのローカルインデックステーブルを有する。この提供は、グローバルテーブルが圧縮器の間で共有されるのに対し、ローカルインデックステーブルは各圧縮器に特有であることを明示的に示す。
更に別の特定の特徴によると、第1のグループ及び第2のグループを判定するステップは、初期リストの情報項目に対応するエントリをグローバルテーブルにおいて探索するステップと、発見されたエントリに対する参照をローカルインデックステーブルにおいて探索するステップとを含む。そのような探索は、共有グローバルテーブルの使用に適応される。
本発明の別の実施形態によると、この方法は、前記判定するステップ、前記連結するステップ及び前記バイナリ圧縮するステップを使用する情報項目の初期リストの第1の符号化、又は項目リテラル値のシリアル化バイナリ表現のバイナリ圧縮のみを使用する情報項目の初期リストの第2の符号化のどちらかを選択するステップ(すなわち、インデックス化を起動すること又は起動しないこと)を更に備え、
ここで第1の符号化のバイナリ圧縮のために使用されたスライディングバイナリウィンドウは、第2の符号化のバイナリ圧縮のために使用されたスライディングバイナリウィンドウより小さい。
この構成により、メモリの使用は、情報項目のインデックスを使用する場合に減少される。これは、インデックス化により、シリアル化バイナリ表現内の冗長がより多く発生するために、これらの冗長を検出するのはより短いスライディングウィンドウで十分だからである。
本発明の更に別の実施形態によると、グローバルテーブルは、複数のネットワーク接続の間で共有され、対応する複数のそれぞれのローカルインデックステーブルにより参照され、
そして、この方法は、符号化中のある時点において、現在の接続を前記共有グローバルテーブルから新しい(共有)グローバルテーブルに移行するステップを更に備える。
グローバルテーブルの移行によりメモリが節約される。これは、メッセージが送受信され且つ情報項目がインデックス化される時、インデックス化情報項目の数が共有グローバルテーブルにおいて増加するためである。移行により、そのテーブルからの未使用のインデックスの消去が可能になることで、メモリを節約する。
それは、本発明の上述の第3の態様の特徴及びその選択的な特徴が本発明の上述の第1の態様において実現されてもよいことを意味する。逆に、本発明の第1の態様及びその選択的な機能において上述した符号化処理は、複数のネットワーク接続のいくつか又は全てにより実現されてもよい。
特定の特徴によると、新しいグローバルテーブルが、現在共有されているグローバルテーブルに関連する少なくとも1つの基準(例えば、そのテーブルの寿命)に依存して、新しい接続に対する要求を受信することで作成されてもよい。その後、この新しい接続を作成する時点で、その新しい接続に対する新しいクリーンなグローバルテーブルに作用するかが決定される。新しいクリーンなグローバルテーブルは、前の共有グローバルテーブルの消去バージョンである。
特に、この方法は、現在共有されているグローバルテーブル及び新しいグローバルテーブルの双方を格納するために使用されたメモリの量に基づいて、現在共有されているグローバルテーブルからエントリを除去するステップを更に備えてもよい。これにより、現在のグローバルテーブルが廃棄及び削除される前に、新しいグローバルテーブル及び現在のグローバルテーブルの双方を使用する際のメモリ制約に準拠することが可能になる。
別の特定の特徴によると、現在の接続を移行するステップは、現在の接続を終了する要求の受信をトリガとされる。
特に、現在の接続を移行するステップは、現在の接続により使用されたエントリを現在共有されているグローバルテーブルから除去するステップと、除去されたこれらのエントリを新しいグローバルテーブルに追加するステップと、その後前記現在共有されているグローバルテーブルをメモリから削除するステップとを含む。この提供は、既存のインデックスが、メモリ空間を解放つつ現在の接続に対して維持されることを保証する。
本発明の更に別の実施形態によると、グローバルテーブルは、複数のネットワーク接続の間で共有され、対応する複数のそれぞれのローカルインデックステーブルにより参照され、共有グローバルテーブルにおける各インデックス化情報項目は、そのインデックス化情報項目を使用して接続数をカウントする接続カウンタと関連付けられ、
この方法は、インデックス化情報項目の接続カウンタに基づいてメモリ節約動作を実行するステップを更に備える。
接続カウンタの使用により、共有グローバルテーブルのエントリ(すなわち、インデックス化情報項目)がいずれの接続によっても使用されなくなる時を容易に検出することが可能になる。このような状況において、このエントリがテーブルから削除されることにより、メモリ空間を解放してもよい。
特に、メモリ節約動作は、対応する接続カウンタがゼロの場合に共有グローバルテーブルからインデックス化情報項目を除去するステップを含む。
別の特定の特徴によると、メモリ節約動作は、閾値より小さい値の接続カウンタと関連付けられたインデックス化情報項目を使用する現在の接続をリセットするステップを含む。削除するためにエントリ(インデックス化情報項目)を使用する接続が依然としてあるかもしれないが、この提供は、メモリ空間を解放することを目的とする。これらの接続をリセットすることにより、それらの対応するインデックステーブルがリセットするとゼロから再構築されるため、依然として削除されたエントリのインデックス化を可能にする。
本発明の更に別の実施形態によると、このい方法は、メモリを解放する要求を受信したことに応じて、ローカルインデックステーブルにおいてインデックス化情報項目の数を保存するステップと、グローバルテーブルをフラッシュするステップSと、保存した数から始まるインデックスを使用してローカルインデックステーブルにおいて新しい情報項目をインデックス化するステップを備えてもよい。この提供により、符号器及び復号器の双方においてインデックス化機構との互換性を維持しつつ、メモリ空間を解放することが可能になる。
本発明の別の特定の実施形態によると、リテラル値のシリアル化バイナリ表現は、初期リストでのそれらの相対順序に従って前記値を維持する。これは、情報項目の初期の順序が復号器によるレンダリングにとって重要である場合に実現されてもよい。
特に、ビットストリームは、初期リスト内に情報項目の順序を格納する追加情報を含んでもよい。これにより、復号器は、情報項目が処理される前にそれらの元の順序に従ってそれらを配置することが可能になる。
本発明の更に別の実施形態によると、メッセージは情報の項目の第2の初期リストを含み、符号化方法は、第2の初期リストの情報項目のリテラル値のシリアル化バイナリ表現を提供するステップと、第1のグループ及び第2のグループから結果として得られた情報項目の符号化ビットストリームとそれを連結するステップとを備える。従って、本実施形態は、ヘッダを迅速に取得するために復号器がバイナリ部分を直接読み出せるビットストリームを提供した。従って、優先順位ヘッダは、取得されるそれへの迅速なアクセスを保証するためにそのようなリストを使用してビットストリームに含まれてもよい。
特定の特徴によると、第2の初期リストに対するシリアル化バイナリ表現は、結果として得られるビットストリームにおいて符号化ビットストリームに先行する。この場合も、特にビットストリームがストリーミングを通して送出される場合、これは上述の(優先順位)ヘッダを可能な限り早く取得するためである。
次に、より具体的には復号化方法に関していくつかの実施形態の特徴を紹介する。
一実施形態によると、前記ローカルインデックステーブルにおいてまだインデックス化されていない情報項目の少なくとも1つは、ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで復号化され、第2のグループにおける対応するリテラル値は、まだインデックス化されていない情報により取られた値と参照として既にインデックス化及び使用されている情報項目により取られた値との差分を示す、この場合も、これは復号器から見られたようなデルタ符号化である。
特に、まだインデックス化されていない情報項目に対応するシリアル化バイナリ表現のバイナリサブパートは、まだインデックス化されていない情報項目のリテラル値に加えて、参照として既にインデックス化及び使用されている情報項目のインデックスを含んでもよい。従って、復号器は、ヘッダを完全に再構成できる。
特定の特徴によると、この方法は、既にインデックス化されている情報項目を参照することで復号化されると、ローカルインデックステーブルにおいて既にインデックス化されている情報項目をまだインデックス化されていない情報項目で置き換えるステップを更に備える。この提供により、復号化が進行するにつれローカルインデックステーブルの増加は減少する。従って、それによりメモリを効率的に管理する。
本発明の別の実施形態によると、まだインデックス化されていない情報項目の1つに対応するシリアル化バイナリ表現のバイナリサブパートは、まだインデックス化されていない情報項目のリテラル値に加えて、まだインデックス化されていない情報項目がローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで復号化されるか否かを規定する第1の1ビットフラグと、まだインデックス化されていない情報項目が更なるインデックス化のためにローカルインデックステーブルに追加されなければならないか否かを規定する第2のバイナリインデックスフラグとを含む、
特に、第2のバイナリフラグは、まだインデックス化されていない情報項目が、新しいエントリとして又は参照として既にインデックス化及び使用されている情報項目の置き換えによりローカルインデックステーブルに追加されなければならないかを規定するためのビットを含んでもよい。
特定の特徴によると、バイナリサブパートは、まだインデックス化されていない前記情報項目により取られた値と参照として既にインデックス化及び使用されている前記情報項目により取られた値との間の共通部分の長さを規定するためのバイナリフィールドを含む。
別の特定の特徴によると、バイナリサブパートは、項目名テーブルにおいてまだインデックス化されていない情報項目の名前に対応するインデックスを規定するためのバイナリフィールドを含む。
これらの提供は、復号器において、符号器に対して上述したような同様の利点、特にインデックス標識がビットストリームにおいてバイナリ規定されるために効率的なインデックスの同期を提供する利点を提供する。
依然としてビットストリームの復号化に関する更に別の実施形態によると、前記ビットストリームから取得された符号化データは、第1の部分及び第2の部分と連結された第3の部分を含み、第3の部分は、追加リストの情報項目のリテラル値のシリアル化バイナリ表現である。
特定の特徴によると、第3の部分は、ビットストリームにおいて第1の部分及び第2の部分に先行する。
これらの提供は、例えばいくつかのヘッダが伸張に依存しないためにビットストリームにおいて早く配置され且つ容易な復号器であるため、復号器がそれらに迅速にアクセスすることに貢献する。
本発明の第5の態様によると、情報の項目の初期リストを含むメッセージをビットストリームに符号化する符号化デバイスであって、
ローカルインデックステーブルにおいて既にインデックス化されている初期リストの情報項目と関連付けられたインデックスの第1のグループ及び前記ローカルインデックステーブルにおいてまだインデックス化されていない初期リストの他の情報項目のリテラル値の第2のグループを判定する判定手段と、
第1のグループのインデックスを符号化する符号器と、
第2のグループのリテラル値の少なくともシリアル化バイナリ表現をバイナリ圧縮する圧縮器と、
第1のグループ及び第2のグループを共に連結して情報項目の符号化ビットストリームを取得する連結モジュールとを備える符号化デバイスが提供される。
本発明の第6の態様によると、符号化メッセージを復号化する復号化デバイスであって、
第2の部分と連結された第1の部分を含む符号化データをビットストリームから取得する取得手段と、
第1の部分を復号化して、ローカルインデックステーブルにおいて既にインデックス化されている情報項目と関連付けられたインデックスの第1のグループを取得する復号器と、
第2の部分をバイナリ伸張して、前記ローカルインデックステーブルにおいてまだインデックス化されていない情報項目に対応するリテラル値の第2のグループのシリアル化バイナリ表現を取得する伸張器と、
第1のグループのインデックスによりインデックス化情報項目及び第2のグループから文字通り復号化された情報項目から構成された復号化リストを提供する出力部とを備える復号化デバイスが提供される。
本発明の第7の態様によると、情報の項目のリストを含むメッセージを符号化して複数の接続を介して送出する符号化デバイスであって、
接続の間で共有され且つ情報の項目を含むグローバルテーブルと、
各々がインデックスを共有グローバルテーブルのエントリに対する参照と関連付ける複数の接続に対応する複数のローカルインデックステーブルと、
メッセージが属する接続専用のローカルインデックステーブルを使用してメッセージの情報項目のリストを符号化する符号器とを備える符号化デバイスが提供される。
本発明の第8の態様によると、複数の接続を介して受信された情報の項目の符号化リストを含む符号化メッセージを復号化する復号化デバイスであって、
接続の間で共有され且つ情報の項目を含むグローバルテーブルと、
各々がインデックスを共有グローバルテーブルのエントリに対する参照と関連付ける複数の接続に対応する複数のローカルインデックステーブルと、
符号化メッセージが属する接続専用のローカルインデックステーブルを使用して符号化メッセージの情報項目の前記符号化リストを復号化する復号器とを備える復号化デバイスが提供される。
本発明の別の態様は、装置のマイクロプロセッサ又はコンピュータシステムにより実行された時に、上述したようなステップを装置に実行させるプログラムを格納する非一時的なコンピュータ可読媒体に関する。
符号化デバイス及び復号化デバイス、並びに非一時的なコンピュータ可読記憶媒体は、符号化又は復号化の方法、特にHTTPメッセージのHTTPヘッダ等のメッセージにおける項目のリストを符号化する際に処理速度を向上させ且つメモリ消費を減少する方法に関連して先に及び以下において説明されるものに類似する特徴及び利点を有してもよい。
本発明の他の態様は、添付の図7;図9;図7及び9;図7及び11;図7及び12;図7,9及び11;図7、9及び12に示され、記述された符号化の方法に関する。
本発明の他の態様は、添付の図8;図10;図8及び10;図8及び11;図8及び12;図8,10及び11;図8、10及び12に示され、記述された復号化の方法に関する。
本発明に係る方法の少なくとも一部は、コンピュータにより実現されてもよい。従って、本発明は、全てがハードウェアの実施形態及び全てがソフトウェアの実施形態(ファームウェア、常駐ソフトウェア、マイクロコード等を含む)、あるいは一般に本明細書において全て「回路」、「モジュール」又は「システム」と呼ばれてもよいソフトウェアの態様とハードウェアの態様とを組み合わせる一実施形態の形式をとってもよい。更に本発明は、コンピュータ使用可能プログラムコードを媒体に取り入れる表現のあらゆる有形の媒体において実施されたコンピュータプログラムの形式をとってもよい。
本発明は、ソフトウェアで実現されうるため、有形のキャリア媒体又は一時的なキャリア媒体等のあらゆる適切なキャリア媒体をプログラム可能な装置に提供するコンピュータ可読コードとして実施されてよい。有形のキャリア媒体は、例えばフロッピディスク、CD−ROM、ハードディスクドライブ、磁気テープデバイス又は固体メモリ素子等の記憶媒体を含んでもよい。一時的なキャリア媒体は、信号、例えば電気信号、電子信号、光信号、音響信号、磁気信号、あるいはマイクロ波又はRF信号等の電磁信号を含んでもよい。
次に、本発明の実施形態を単なる一例として且つ以下の図面を参照して説明する。
図1は、HTTP要求及びHTTP応答のそれぞれに対して6個のHTTPヘッダを示す図。 図2は、本発明の原理が実現されるSPDYの一例を示す図。 図3は、本発明に係るSPDY接続の2つの連続したHTTP応答に対するデフレート圧縮に加えてヘッダインデックス化の一例を示す図。 図4は、それぞれ個別に且つグローバルテーブルを参照して構築されたローカルインデックステーブルの2つの異なる実現例を示す図。 図5は、図4の2つの方法に従ってローカルインデックステーブルを格納するために使用されたメモリ空間を示すグラフ。 図6は、本発明の実施形態が実現されうる処理装置の構成要素を示すブロック図。 図7は、本発明の一実施形態に係るHTTPヘッダの符号化処理の一般的なステップを示すフローチャート。 図8は、本発明の一実施形態に係るHTTPヘッダの復号化処理の一般的なステップを示すフローチャート。 図9は、本発明の第2の実施形態に係る共有グローバルテーブルに基づいてHTTPヘッダの符号化処理の一般的なステップを示すフローチャート。 図10は、本発明の第2の実施形態に係る共有グローバルテーブルに基づいてHTTPヘッダの復号化処理の一般的なステップを示すフローチャート。 図11は、現在の接続を現在の共有グローバルテーブルから新しい共有グローバルテーブルに移行するステップを示すフローチャート。 図12は、接続の寿命に従って共有グローバルテーブルを最適化するステップを示すフローチャート。 図13は、本発明を使用して取得可能な種々の符号化ビットストリームを概略的に示す図。 図14〜図18は、本発明の種々の実施形態に係るヘッダを符号化するバイナリ表現を示す図であり、図14は、インデックステーブルからインデックスを使用して符号化されたヘッダに対するバイナリ表現を示す図であり、図15は、文字通り符号化されるヘッダに対するバイナリ表現を示す図であり、図16及び図17は、それぞれインデックス化なしでデルタ符号化されるヘッダに対するバイナリ表現及びインデックス化してデルタ符号化されるヘッダに対するバイナリ表現を示す図であり、図18は、文字通り符号化されるヘッダ値に対するバイナリ表現を部分的に示す図である。
図1を参照すると、本明細書ではHTTPヘッダである情報項目の第1の部分は、以下において説明されるようなデフレート圧縮を使用してインデックス化及び/又は圧縮される。そして、情報項目の第2の部分は、リテラル値のシリアル化バイナリ表現に変換され、インデックス化も圧縮もされずにビットストリームに入力される。
情報項目の第1の部分全体が圧縮される場合、情報項目の第2の部分は、以下において説明されるように、完全に又は部分的にインデックス化されるものの非圧縮のヘッダのシリアル化バイナリ表現を更に含んでもよい。
第2の部分に対する圧縮の欠如は、復号器(例えば、HTTPプロキシサーバ)がいくつかのHTTPヘッダに容易に且つ迅速にアクセスするのに有利である。圧縮されない情報項目から構成された追加の初期リストのヘッダは、例えばヘッダ名に基づいて事前定義済みのリストにおいて規定されうる。例えば、ヘッダ「HTTP Method」、「HTTP Version」及び「Status」(不図示)は、そのような追加の初期リストの一部になりうるという利点がある。
以下において、図14〜図18を参照してヘッダに対するバイナリ表現を説明する。
符号化ビットストリームにおいて、追加の初期リストのシリアル化バイナリ表現は、一度符号化及び/又は圧縮されると、特に先立って、情報項目の第1の部分に対応する符号化及び圧縮されたビットストリームと連結されてもよい。
図2の左部分は、3つの接続を有し、且つ3つのクライアントに対してHTTPヘッダの個別のデフレート圧縮(ZIP1、ZIP2及びZIP3)を実行するサーバ(図2a)、並びにHTTPメッセージを受信するために3つの接続を有し且つ個別の伸張を実行するクライアント(図2c)に対する従来のSPDYを示す。
図2の右部分は、本発明の一実施形態を示す。すなわち、3つの個別のデフレートステップ(ZIP1、ZIP2及びZIP3)の前に、ヘッダインデックス化は共有グローバルテーブルに基づいて実行される(図2b)。対応するヘッダインデックス化は、復号器において実行される(図2d)。
前のインデックス化によって、より少ない数のバイトがデフレートを使用して圧縮又は伸張されるため、これによりデフレートステップの減少が可能になる。また、ヘッダインデックス化のために接続により共有されたグローバルテーブルにより、インデックスメモリコストを更に共有できるようになる。
図3は、SPDY接続の2つの連続したHTTP応答に対するデフレート圧縮に加えてヘッダインデックス化を示す。インデックス化又は圧縮対象でないヘッダの第2の部分が提供される場合、これはヘッダの第1の部分を考慮する。図3aは、第1の応答に対する状況を示し、図3bは、後で発生する第2の応答に対する状況を示す。
各応答の4つのHTTPヘッダは、図3の上部に示される。
SPDY接続における第1の応答に関して、ヘッダがまだ処理及びインデックス化されていないため、前の応答との類似性は発見されない。従って、全ての4つのHTTPヘッダは、標準的なSPDY符号化により文字通り符号化される。すなわち、各HTTPヘッダの名前は、最初に文字通り符号化されるかあるいはヘッダ名テーブルを参照してインデックス化され、その後、その値が文字通り符号化される。図15及び図18を参照して、そのような符号化のバイナリ表現の一例を以下において説明する。
次にプロセッサは、デフレート圧縮を符号化ストリーム(すなわち、シリアル化バイナリストリーム)に適用して、HTTP応答においてネットワークを介して送信される圧縮ヘッダストリームを取得する。
同時に、4つのHTTPヘッダは、後でインデックスを再利用するために処理済みのヘッダのリストに格納される。このリストは、場合によっては(いくつかの実施形態において)上述のグローバルテーブルを参照するローカルインデックステーブルである。この例において、SPDY接続のためのローカルインデックステーブルは、各HTTPヘッダを特定のインデックスと関連付ける。
SPDY接続において第1の応答より後で発生する第2の応答に関して、4つのHTTPヘッダが更に処理される。そのうちの3つは、第1の応答の最初の3つのヘッダと全く同一であり、既にローカルインデックステーブルに格納されている。
例えば図3に示されるようにそれぞれ0、1及び2である対応する3つのインデックスは、ローカルインデックステーブルから検索され、最初の3つのHTTPヘッダを符号化する。これは、インデックスの第1のリスト又はグループを構成する。図14を参照して、各符号化インデックスのバイナリ表現の一例を以下において説明する。
次に、残りのHTTPヘッダは、インデックスとして符号化され得ないために、SPDY符号化を使用して文字通り符号化される。これは、リテラル値の第2のリスト又はグループを構成し、次に、そのシリアル化バイナリヘッダストリームは、第2の応答においてネットワークを介して送出される前にデフレート圧縮を使用して圧縮され、第1のリスト又はグループと連結される。
以下の場合、第1のリスト及び第2のリストを参照するが、上述したようにグループも参照されうる。
再度、圧縮ヘッダの送出と同時に、ローカルインデックステーブルは、文字通り符号化されたヘッダを新しいインデックス(インデックス4)に一致させる新しいエントリを追加することで更新されるため、後続の応答において冗長を効率的に(そのインデックスを用いて)符号化するために使用可能である。
以下において説明される実施形態において、第2のリストを形成する残りのHTTPヘッダの各々は、ローカルインデックステーブルにおいて既にインデックス化されているヘッダを参照することにより、デルタ符号化、すなわち符号化される。この例において、テーブルの第4のエントリ(3に等しいインデックスを含む)は、同一のヘッダ名(すなわち、「Date」)を有するため、このエントリに対する参照が使用可能であり、残りのHTTPヘッダにより取られた値とこのエントリにより取られた値との差分が文字通り符号化される。従って、結果として得られるバイナリ表現は、使用されたインデックス及び差分のリテラル値を含む。図16〜図18を参照して、そのようなバイナリ表現の一例を以下において挙げる。
一変形例において、残りのHTTPヘッダにより取られた値は、差分の代わりに直接文字通り符号化されてよい。
デルタ符号化が使用される状況において、符号化ヘッダを新しいインデックスに一致させる新しいエントリを追加する一変形例は、ちょうど符号化された残りのHTTPヘッダと共に参照として使用されたエントリを置き換えることで構成されてもよい。2種類の更新(増分又は置き換えによる)のどちらにするかを判断する基準は、例えばヘッダ名に基づく統計的に規定された戦略に基づいてもよい。
従って、図16〜図18のバイナリ表現は、残りのHTTPヘッダが新しいエントリとして又は参照として既にインデックス化及び使用されているヘッダの置き換えによりローカルインデックステーブルに追加されなければならないかを規定するためのビットを含む。
図3bの上述の例から明らかなように、ヘッダインデックス化により、デフレート圧縮されるビットの量が減少するために、SPDY符号化を介して処理を向上できる。これらのヘッダ間に高い冗長性がある場合、後続のHTTPメッセージのHTTPヘッダに対して処理速度を最大2倍向上させることも可能である。
当然、LZW又はBZIP2等のデフレート以外の普遍的な可逆圧縮技術は、例示する目的で本明細書において利用されたデフレート圧縮の代わりに使用可能である。また、本発明は、メッセージにおける情報項目のあらゆるリストに適用され、HTTPヘッダが一例として示される。
また、バイナリストリームを小さくして圧縮する本発明に係るヘッダインデックス化のために、各接続のデフレートスライディングウィンドウが小さくされることにより、メモリ(より少ないバイトのバッファリング)及び速度(より少ないバイトの探索)の双方を節約できてもよい。これは、更なるメモリコストが非常に少ないヘッダインデックス化方法がその状況において速度を向上し続けるが、より大きなスライディングウィンドウのサイズに対して達成された圧縮率を更に維持できるようにするためである。
例えば、スライディングウィンドウのサイズがメッセージのHTTPヘッダを示すために使用されたバイトの数より小さくなる場合、一部の冗長がデフレート圧縮により検出されないため、結果として圧縮が低下する。例示するために、同一のヘッダAが2つの連続したメッセージに現れる場合、ヘッダAは、第1のメッセージの符号化中に現在のスライディングウィンドウに追加されるが、第2のメッセージのヘッダAの符号化を開始する前にスライディングウィンドウから除去されてもよい(ウィンドウが短すぎる場合)。従って、より少ない冗長が実際に検索されることにより、圧縮効率の低下を招く恐れがある。
しかし、インデックス化ヘッダがインデックステーブルに引き続き維持されるため、これはヘッダインデックス化により補償される。従って、依然として冗長を検出できる。
また、ヘッダインデックス化により、復号器においてHTTPヘッダにより高速にアクセスすることが可能になる。これは、インデックスにより、構文解析されて符号化ビットストリームからアクセスされ、対応するHTTPヘッダ(ローカルインデックステーブルに格納された)を取得するために復号化される必要のあるビット又はバイトが殆どないためである。これは、インデックスの第1のリストが符号化ビットストリームにおいてリテラル値の第2のリストに先行する場合に特に当てはまる。
これらの速度及び圧縮の利点に加えて、いくつかの同時の接続のためにローカルインデックステーブルを効率的に実現することにより、メモリを節約できる。
図4aは、第1の接続(上方の「#1」)及び第2の接続(下方の「#2」)に対するローカルインデックステーブルの実現例の第1の例を示す。HTTPメッセージの符号化中に遭遇される各HTTPヘッダの全体は、メッセージが属する接続専用のローカルインデックステーブルに追加される。この結果、同一のHTTPヘッダを2回格納することになり(例えば、「Status:200 OK」)、且つ全体のメモリコストが155バイトになるだろう。
図4bは、同一のインデックスのメモリコスト削減の実現例を示す。上述したようなグローバルテーブルは、HTTPヘッダを格納し且つそれらを参照(A、B等)と関連付けるために使用される。従って、ローカルインデックステーブルは、インデックスをグローバルテーブルの参照と関連付けるだけである。図4aの155バイトのコストと比較して結果として得られる132バイトのコストにより示されるように、これによりメモリコストが実質的に削減される。
メモリ空間は約23バイト節約される。
参照は図4のグローバルテーブル内に格納されるが、変形例は、各々がHTTPヘッダのみを格納するグローバルテーブルのエントリに対するポインタをローカルインデックステーブル内に格納することを含んでもよい。
図5は、接続数に依存してこれらの2つの方法に対して使用されたメモリ空間における差分(個別のインデックステーブル対グローバルテーブルに対する参照)を示す。接続数(すなわちローカルインデックステーブルの)が増加するにつれ、グローバルテーブルを使用することでメモリがより節約されることは、図5から明らかである。これは、より多くの接続があるほど、単一のストリングがいくつかの接続により使用されるために、いくつかのローカルインデックステーブルにおいてインデックス化されることがより多いためである。
ローカルインデックステーブルが個別に又はグローバルテーブルを参照して実現されるかに関係なく、格納のためのメモリにおける対応するコストは、実質的に、全ての接続のためにデフレートスライディングウィンドウを小さくすることで達成されたメモリの節約により補償される。
図6は、本発明の少なくとも1つの実施形態を実現するように構成された送信機又は受信機、あるいは双方の機能性を組み込むデバイスである処理装置600を概略的に示す。処理装置600は、マイクロコンピュータ、ワークステーション又は光ポータブルデバイス等のデバイスとすることができる。装置600は、好ましくは以下のものが接続されている通信バス613を含む。
− CPUで示されるマイクロプロセッサ等の中央処理装置611;
− 本発明を実現するためのコンピュータプログラムを格納するROMで示される読み出し専用メモリ607;
− 本発明の実施形態の方法の実行可能なコード、並びに本発明の実施形態に係る方法を実現するために必要な変数及びパラメータを記録するように構成されたレジスタを格納するRAMで示されるランダムアクセスメモリ612;そして、
− 処理対象のデジタルデータが送信される通信ネットワーク603に接続された通信インタフェース602である。
選択的に、装置600は、以下の構成要素を更に含んでもよい。
− 本発明の1つ以上の実施形態の方法を実現するためのコンピュータプログラム及び本発明の1つ以上の実施形態の実現例の間に使用又は生成されたデータを格納するハードディスク等のデータ格納手段604;
− ディスク606からデータを読み出すかあるいはデータを前記ディスクに書き込むように構成されるディスク606に対するディスクドライブ605;そして
− キーボード610又は他のあらゆるポインティング手段を使用してユーザによりデータを表示し且つ/あるいはグラフィカルインタフェースとして機能する画面609。
装置600は、各々がマルチメディアデータを装置600に供給するように入出力カード(不図示)に接続される種々の周辺装置、例えばデジタルカメラ600又はマイク608等に接続されうる。
通信バスは、装置600に含まれるかあるいは接続された種々の要素間で通信及び相互運用性を提供する。バスの表現は限定されておらず、特に中央処理装置は、命令を装置600のいずれかの要素に直接又は装置600の別の要素を使用して通信するように動作可能である。
ディスク606は、例えばコンパクトディスク(CD−ROM)、書き換え可能又は書き換え不可能な、ZIPディスク又はメモリカード等のあらゆる情報媒体及び概括的な言葉で、マイクロコンピュータ又はマイクロプロセッサにより読み出され、装置に一体化されるかあるいは一体化されず、場合によっては取り外し可能であり、且つ実行することで本発明に係る方法を実現できるようにする1つ以上のプログラムを格納するように構成されうる情報格納手段により置換されうる。
実行可能なコードは、読み出し専用メモリ607、ハードディスク604、あるいは例えば上述したようなディスク606等の取り外し可能デジタル媒体上に格納される。一変形例によると、プログラムの実行可能なコードは、実行される前にハードディスク604等の装置600の格納手段のうちの1つに格納されるために、インタフェース602を介して通信ネットワーク603を使用して受信されうる。
中央処理装置611は、命令が上述の格納手段のうちの1つに格納される本発明に係る1つ又は複数のプログラムのソフトコードの命令又は部分の実行を制御及び指示するように構成される。電源投入時、不揮発性メモリに、例えばハードディスク604上にあるいは読み出し専用メモリ607に格納される1つ又は複数のプログラムは、1つ又は複数のプログラムの実行可能なコード、並びに本発明を実現するために必要な変数及びパラメータを格納するレジスタを含むランダムアクセスメモリ612に転送される。
本実施形態において、装置は、本発明を実現するためにソフトウェアを使用するプログラム可能な装置である。しかし、あるいは本発明は、ハードウェア(例えば、特定用途向け集積回路、すなわちASICの形態)で実現されてもよい。
次に、図7〜図12を参照して、本発明に係る符号化方法及び復号化方法の種々の実施形態を説明する。ネットワークノードは、符号化機能及び復号化機能の一方又は双方を組み込むことができる。
ノードが符号器及び復号器の双方として動作する場合、同一の接続内での符号化及び復号化のそれぞれに対する2つの別個のローカルインデックステーブルを使用することが好ましくなる。同様に、以下において説明されるような2つのグローバルテーブル及び2つの(余分な)ヘッダ名テーブルが使用されてもよい。これは、一般に、HTTP要求のヘッダがHTTP応答のヘッダとは異なるためである。その後、各ローカルインデックステーブルは、同一の接続のために他から独立して処理される。
しかし、特に同一の接続の要求及び応答内で多数のHTTPヘッダが類似することが観察される場合、符号化タスク及び復号化タスクのために単一のローカルインデックステーブルを使用することが依然として可能であることは、当業者には理解されるであろう。
図7は、本発明の一実施形態に係るHTTPヘッダの符号化処理の一般的なステップを示すフローチャートである。SPDYに従ってHTTPメッセージを処理する際に複数のHTTPヘッダが符号化されなければならないことは、本明細書において想起される。HTTPヘッダ以外のあらゆる種類の情報項目に対しても実現できる。
説明される処理では、1つの接続しか考慮しないものとする。当然、同一の処理は、他の接続のために動作する他の符号器により同時に実行されてもよい。HTTPヘッダの初期の順序が復号器にとって重大及び重要でないヘッダの符号化も参照する。そのような初期の順序が復号器により維持される(すなわち、本発明が送信のために場合によってはこの順序を変更してもよいために検索される)べきである場合、本発明は、ストリーム内で、ヘッダの初期の順序を格納する追加情報(例えば、追加ヘッダ)を提供してもよい。例えばこの追加情報は、初期の順序内のインデックス化ヘッダの各々の厳密な位置を規定してもよく、他のヘッダ(すなわち、インデックス化なしの)は、相対的な初期の順序を維持したまま文字通り符号化される。
本明細書において、インデックス化及び/又はバイナリ圧縮されるヘッダが考慮される。符号化ビットストリームに挿入される前にバイナリ表現にシリアル化されるだけのヘッダは、図14〜図18を参照して以下において説明されるバイナリ表現を使用して上述したように処理される。
ステップ700〜730間のループにより示されるように、符号化対象のメッセージの各HTTPヘッダ上で繰り返すことにより、処理を開始する。
ヘッダ毎に、ヘッダが既にインデックス化されているか否かを判定するために、現在の接続専用のローカルインデックステーブルにおいて探索が行われる(ステップ710)。
図4aのようなテーブルを使用する場合、この探索は、HTTPヘッダが既にローカルインデックステーブルに存在するか否かを判定することから構成されてもよい。
図4bに示されるようなグローバルテーブルを使用する場合、この探索は、ヘッダに対応するグローバルテーブルにおけるエントリを探索することと、ローカルインデックステーブルにおいて発見されたエントリに対する参照を探索することとを含む。
ヘッダが既にインデックス化されている場合、そのインデックスは、ローカルインデックステーブルから検索され且つ第1のリストに格納される(ステップ720)。この第1のリスト(又はグループ)は、ローカルインデックステーブルにおいて既にインデックス化されているメッセージヘッダのインデックスを含むように構築される。
一方、ヘッダがまだインデックス化されていない場合、第1のステップ740が実行され、ヘッダがローカルインデックステーブルにおいてインデックス化されなければならないか否かが判断され、且つ肯定的な判断の場合にはローカルインデックステーブルにおいてそのヘッダをインデックス化する(場合によっては適宜グローバルテーブルを参照して)ように実行される。そのような判断に対する基準は、例えば事前定義済みの最大メモリ空間と比較して、符号器において使用可能なメモリ空間に基づいてもよい。ローカルインデックステーブル(及び上述したように且つ以下において説明されるように含まれた他のあらゆるテーブル)が事前定義済みの最大メモリ空間に到達するまで、全てのヘッダはインデックス化されてもよい。そのような判断(すなわち、ヘッダがインデックス化されなければならないか否か)を示す情報は、図15〜図17に示されるように符号化ヘッダのバイナリ表現で提供される。これは、ローカルインデックステーブルを構築する際に復号器が符号器と同期されることを保証するためである。
より具体的な戦略は、処理されるヘッダのインデックスを閾値(例えば、256個の文字)を下回るサイズを有するヘッダのみに制限してもよい。
その後、第2のステップ750において、ヘッダが符号化される。2つの可能性が考えられる。
探索は、処理されている現在のヘッダと同一のヘッダ名を有するエントリに対するローカルインデックステーブル(場合によってはグローバルテーブルを含む)において実行される。そのようなエントリが発見される場合(いくつかのエントリが発見される場合、最も類似する値を有するエントリが選択される)、そのようなエントリは、現在のヘッダをデルタ符号化するために参照として使用される。換言すると、現在のヘッダは、ローカルインデックステーブルにおいて選択されたエントリのインデックス(参照)及び選択されたエントリにより取られた値と現在のヘッダにより取られた値との差分を含むデータの集合に符号化される。
図16及び図17を参照して以下において示されるように、差分は、当該2つの値の間の共通部分(例えば、2つのストリングの間の第1の同じ文字数)を示す第1のデータと、値の残りの部分のリテラル値(すなわち、共通部分より小さい現在のヘッダの値)を含む第2のデータとから構成されてもよい。2つの値が数(整数、フロート等)である場合、差分は、2つの値の間の数の差分を示す値のみで構成されてもよい。
そのようなエントリが発見されない例において又はデルタ符号化が実現される場合、現在のヘッダは文字通り符号化される。
次に、デフレート等の圧縮アルゴリズムは、データ又はリテラル値の集合のバイナリ表現に適用される(ステップ760)。以下において説明される図15〜図18は、種々の例のバイナリ表現を示す。
ステップ740は、ローカルインデックステーブル内で、少なくとも1つの文字通り符号化されたヘッダを新しいインデックスと関連付けるか又はデルタ符号化されたヘッダを新しいインデックスと関連付けることにより、あるいはデルタ符号化のために参照として使用された既にインデックス化されているヘッダの置換でそのローカルインデックステーブルを更新する。
増分インデックス化モードにおいて(すなわち、新しいエントリの加算により)、符号化ヘッダは、ローカルインデックステーブルに付加され、そのインデックスは、符号化ヘッダがローカルインデックステーブルに付加された前に既にテーブルにあるヘッダ数に等しい。
置き換えインデックス化モードにおいては(すなわち、参照として使用されたエントリの置換では)、符号化ヘッダは、ローカルインデックステーブルにおいて既にインデックス化されているヘッダに対する参照を含み、ローカルインデックステーブルにおいてヘッダを置換する。
ステップ740で現在符号化されているヘッダをインデックス化することを決定するデルタ符号化の場合、符号器は、増分インデックス化及び置き換えインデックス化のどちらにするかも判断しなければならない。そのような判断は、例えばヘッダ名に基づく統計的に規定された戦略に基づいてよい。
そのような判断(すなわち、増分インデックス化又は置き換えインデックス化)を示す情報は、図16及び図17に示されるようなデルタ符号化されたヘッダのバイナリ表現で提供される。これは、ローカルインデックステーブルを構築する際に復号器が符号器と同期されることを保証するためである。
ステップ760でデフレートコンテキストが各処理済みヘッダの間で維持されるため、符号化の結果は、ステップ750の発生時に判定された(場合によっては、デルタ符号化の場合には参照ヘッダのインデックス及び共通部分の定義に付与された)全てのリテラル値のシリアル化バイナリ表現に対してデフレート圧縮を適用することと同一である。その場合、リテラル値(インデックス及び共通部分の定義に付与された)が第2のリストに格納されてもよく、且つループ700〜730を終了する場合にデフレート圧縮がその第2のリストのシリアル化バイナリ表現に対して実行されてもよいことは、当業者により理解されるだろう。その第2のリストのシリアル化バイナリ表現は、ステップ750に従って処理された各ヘッダのバイナリ表現の連結であってもよい。図15〜図18を参照して、各ヘッダに対するそのようなバイナリ表現を以下において説明する。
ステップ700〜750により全てのヘッダが処理されると、次のステップは、ステップ720の発生時に構築された第1のリストのインデックスを符号化することから構成される。そのような符号化は、インデックスのバイナリ表現を取得することから構成されてもよい。インデックスは、単一の値又は値の範囲として符号化される(すなわち、バイナリ表現に変換される)。図14を参照して、ヘッダを符号化するインデックスに対するバイナリ表現の一例を以下において説明する。
デフレート等の圧縮技術は、バイナリ表現に対しても使用可能である。その場合、第1のリストに対するシリアル化バイナリ表現及び第2のリストに対するシリアル化バイナリ表現は、共に連結されてよく、バイナリ圧縮することは、結果として得られるシリアル化バイナリ表現全体を圧縮するためにそれに対して実行されてもよい。
一旦符号化されると、第1のリストのシリアル化バイナリ表現はステップ770にて送出される。一変形例においてインデックスヘッダセクションの終端にフラグを立てるように専用のコードが規定されてもよいが、一般に、インデックス化ヘッダ数が最初に符号化されてから各インデックスが符号化されうる。
次に、圧縮された第2のリストのシリアル化バイナリ表現がステップ780で更に送出される。
例えば、ヘッダインデックスの第1のリストは、リテラル値の第2のリストと連結されてもよいため、結果として得られるリストは、ステップ770及び780の双方を実行するように送出される(適切な符号化及び圧縮の後で)。
この処理(及び対応する復号化処理)は、ローカルインデックステーブル内での構築及び探索に対するコストがデフレート圧縮を各インデックス化ヘッダに適用しないことによる節約による補償より多いため節約される。
当然、インデックス化されるヘッダが多いほど、処理はより節約される。また、ローカルインデックステーブルを格納するために使用されたメモリがデフレートスライディングウィンドウを小さくすることで補償されてもよいため、更なるメモリ消費が制限される。
図4a及び図4bの例において、HTTPヘッダ全体は、ローカルインデックステーブルにおいて単一のエントリとしてインデックス化される。しかし、インデックス化ステップ740を実行する場合、例えばヘッダ全体、ヘッダの一部をインデックス化するか、あるいは基準に応じてヘッダを全くインデックス化しない場合、他のインデックス化戦略又は決定規則が実現されてもよい。
あるインデックス化戦略によると、ヘッダ名は、ヘッダ値とは別にインデックス化されてもよい。特に、一般にヘッダ名がその値より冗長であるため、ヘッダ名インデックス化(すなわち、ヘッダ名のインデックス化)は、一般にヘッダ値インデックス(すなわち、ヘッダ値をインデックス化すること)より好まれる。例えば、「Date」HTTPヘッダ値は、ある期間にわたり進化し且つインデックス化されなくてもよいという利点がある一方で、「Date」HTTPヘッダ名は、経時変化しないままであるためにインデックス化されてもよい。「Age」ヘッダ又は「Content−Length」ヘッダ等のその特性に従う他のHTTPヘッダに対して、同様の検討事項が使用されてよい。
ヘッダ名インデックス化を好む場合、HTTPヘッダは、HTTP名及びリテラルHTTP値をインデックス化するインデックスに符号化されてもよい。これは、上述したようなデルタ符号化である。
以下において説明されるように差分値が文字通り符号化されるため、デルタ符号化は、第2のリストを形成するヘッダに適用されることが好ましい。別の実施形態において、第1のリストを形成するヘッダがインデックスを使用して符号化されるため、デルタ符号化はそれらに適用される。
知られているように、メモリは、ローカルインデックステーブル(及び使用される場合にはグローバルテーブル)を構築するための制約を構成してもよい。従って、特にヘッダ表現を格納するために割り当てられたテーブルエントリ数及びメモリサイズを制限することにより、インデックステーブルにより使用されたメモリサイズを制限することが決定されてもよい。一般にインデックステーブルは、512バイト又は1024バイトのバッファに制限されうる。その場合、ステップ740で新しいヘッダ(又はその一部)をインデックス化するか否かの判断は、既に使用されている割り当てられたメモリの割合に基づいて行われてよい。
そのように制限されたバッファサイズにより、更なるメモリコストが制限され、一般に結果は、小さなバイナリ表現を有するヘッダ、すなわち一般に64個より少ない文字を有するヘッダのみをステップ740でインデックス化することで改善される。
その方法の改良点は、大きなバイナリ表現を有するヘッダを漸次インデックス化することを含んでもよい。換言すると、ヘッダのいくつかの出現が発生し且つ処理される時、そのヘッダは漸次インデックス化される。
例えば、大きなバイナリ表現を有するそのヘッダが遭遇される第1の時間、実際には最初のN個の文字(例えば、N=64)のみがインデックステーブルに格納され、インデックスと関連付けられる。その第1の出現に対して、残りの文字は文字通り符号化される。同一のヘッダ(第2の出現)が遭遇される第2の時間、ヘッダ全体が十分な回数発生する場合にそれが格納されるまで、インデックステーブルは、例えば同一のインデックスに対して格納するための文字の数(例えば、2N)を増加することで更新される。
別の戦略によると、インデックスフラグは、バイナリ圧縮された各リテラルヘッダと関連付けられて、それがローカルインデックステーブルにおいてインデックス化されなければならないことを示してもよい。従って、復号器は、自身がまだ認識していないあらゆる独自のインデックス化戦略を通知されてよい。例えば、ヘッダのリテラル符号化は、ヘッダをインデックステーブルに追加するかを復号器に知らせるフラグを含む。
独自の戦略は、インデックス化対象のヘッダ名の事前コンパイルリスト(ヘッダ名テーブル)又はインデックス化対象でないヘッダ名の事前コンパイルリストの符号器による知識等の種々の状況を範囲に含んでもよい。
例えばリストは、いくつかの接続の間で共有可能なヘッダを含んでよい。一般にクッキーに関連するヘッダは、いくつかの接続の間で共有されなくてもよく且つインデックス化されなくてもよいという利点がある。「Set−Cookie」ヘッダは、その値が変化することが予想されるためにインデックス化されなくてもよいという利点がある。いずれにせよ、インデックス化されないヘッダは、一般に、デフレート圧縮ステップ760により効率的に圧縮される。
別のインデックス化戦略は、いくつかのヘッダがある期間にわたり限られた妥当性を有することに基づいてもよい。例えばこれは、メッセージが送出される日付を含むが精度は二の次の「Date」ヘッダの場合である。
コンピュータが1秒間に多くのメッセージを送出できるため、そのような日付に基づくヘッダをインデックス化することは効率的でありうる。しかし、これは、同一秒数内に生成された少数のメッセージに対してのみ有用となる。いくつかのメッセージは、ウェブページに関連する全てのリソース(スタイル、JavaScript、画像...)を取り込むクライアント又はクライアントに応答する際のサーバにより迅速に出されうる。
ある期間にわたり限られた妥当性をサポートするために、新しいヘッダは、インデックス化されたデルタとしてフラグを立てられてもよい。これは、インデックスに加えて、インデックスに対応するヘッダに対する差分(例において秒で)に関する情報与えることを意味する。これは既に上述されている。
その場合、インデックスレベルフラグは、HTTPヘッダと関連付けられる。前記インデックスレベルフラグは、HTTPヘッダに依存して、HTTPヘッダがローカルインデックステーブルにおいて対応する情報項目と同一のHTTP名及びHTTP値を有することを示す第1の完全なインデックス化状態、又はHTTPヘッダがローカルインデックステーブルにおいて対応する情報項目と同一のHTTP名であるが異なるHTTP値を有することを示す第2の部分的なインデックス化状態を取る。値の差分は、更に文字通り符号化及び送信されてもよい。
上述したように、これは、第1のリストのヘッダ又は第2のリストのヘッダに適用されてもよい。
従って、「部分的なインデックス化状態」は、ヘッダ値の差分が文字通り復号化されなければならないことを復号器に示す。
図7の上述の例において更に説明されるように、インデックス化ヘッダは、符号化ビットストリーム内で文字通り且つデルタ符号化されたヘッダに先行する。これはいくつかの利点を提供する。
例えばいくつかのヘッダは、ネットワークノードがHTTP要求のURL値のような正当な処理エンティティにメッセージを配布するために非常に重要だろう。また、HTTPキャッシングヘッダはプロキシに対して有用である。一般にこれらのヘッダは、非常に冗長であるため、迅速にインデックス化される。最初にインデックス化ヘッダを提供することにより、殆どの場合、ネットワークノードは、デフレート伸張及びヘッダストリング構文解析の技術を使用する必要なく最も重要なヘッダに迅速にアクセスできる。また、インデックス化ヘッダを復号化することは、ビットストリームからいくつかのバイトを検索することで実行されうる。それにより、ビットストリームの小さな部分にアクセスすることで多数の復号化ヘッダを取得することが可能になる。
しかし、変形例が使用されてよい。例えば、必要とされるバッファリングを制限するために、文字通り且つデルタ符号化されたヘッダは、最初にデフレートストリーム及び次に送出されるインデックス化ヘッダとして送出されうる。その場合、特定のコードが文字通り且つデルタ符号化されたヘッダセクションを終了することにより、復号器は、インデックス符号化されたヘッダセクションに迅速に切り替わることができる。
上述したように、インデックス化又は圧縮(例えば、デフレート)されないヘッダの第3の集合は、インデックス化ヘッダ及び文字通り且つデルタ符号化されたヘッダの前に符号化ビットストリームに更に挿入されてもよい。ローカルインデックステーブル又はバイナリデフレート伸張における探索が必要とされないため、これは、復号器に対するいくつかのヘッダへの容易で迅速なアクセスを提供するためである。
図7は、インデックス符号化がリテラル/デルタ符号化とは別にされる処理の一例を更に示す。これにより圧縮を改善できるが、それは、インデックス及び/又はリテラル値に対して少量のバッファリングしか更に必要としない。一変形例によると、ヘッダは、処理されるとすぐに符号化及び送出されてもよい。
最後に、フラグは、ヘッダがインデックステーブルに追加されなければならないことを復号器に示すために、文字通り且つデルタ符号化された各ヘッダの一部として符号化されうる。代替例は、符号器及び復号器の双方が、インデックス化規則を厳密に認識しているために、インデックス化決定情報を通信する必要なくインデックステーブルを同期させたままにすることである。
図13は、本発明を使用して取得可能な種々の符号化ビットストリームを概略的に示す。
図13aにおいて、ビットストリームは、第1のリストのインデックスのシリアル化バイナリ表現を含む第1のバイナリ部分1310と、第2のリストのヘッダの(デフレート)圧縮されたシリアル化バイナリ表現を含む第2のバイナリ部分1320とを含む。本実施形態において、第1のリストのインデックスのシリアル化バイナリ表現は、(デフレート)圧縮されなくてもよい。当然、一変形例によると、第1のバイナリ部分及び第2のバイナリ部分は反転されてもよい。
図13bにおいて、ビットストリームは、第1のリストのインデックスの(デフレート)圧縮されたシリアル化バイナリ表現を含む第1のバイナリ部分1310’と、第2のリストのヘッダの(デフレート)圧縮されたシリアル化バイナリ表現を含む第2のバイナリ部分1320とを含む。2つのリストに対するシリアル化バイナリ表現は、(デフレート)圧縮される前に連結される。当然、一変形例によると、第1のバイナリ部分及び第2のバイナリ部分は反転されてもよい。
図13c及び図13dの例は図13a及び図13bの例に類似するが、(デフレート)圧縮又はインデックス化されないヘッダのシリアル化バイナリ表現を含む第1のバイナリ部分及び第2のバイナリ部分に連結された更なるバイナリ部分1300を有する。当然、一変形例によると、更なるバイナリ部分は、第1のバイナリ部分及び第2のバイナリ部分と比較してビットストリームにおいて別の場所を取ってもよい。
図8は、本発明の一実施形態に係るHTTPヘッダの復号化処理の一般的なステップを示すフローチャートである。特に、図8は、図7の符号化処理に対応する復号化処理である。
これは、復号器が符号器と同様に動作することを意味する。例えば符号器及び復号器の双方は、使用される場合に同一のローカルインデックステーブル及び同一のグローバルテーブルを有するように同一のインデックス化戦略を使用する。
符号化処理と同様に、複数のヘッダは復号化する際に処理されなければならない。図8の例において、符号化インデックス化ヘッダは、文字通り且つデルタ符号化されたヘッダに先行して取得される。
予備のステップ(不図示)は、シリアル化されているだけの、すなわち符号化又はバイナリ圧縮されていないヘッダを含むビットストリームの第1の部分を構文解析すること及び読み出すことから構成されてもよい。この予備のステップは、メッセージヘッダリストに追加されたヘッダの第1の集合を提供する。
図8の第1のステップは、ステップ800及び810によりインデックス化ヘッダを復号化することから構成される。
アルゴリズムは、復号化対象の残りのインデックス化ヘッダがあるかを確認することでステップ800で開始する。このテストは、ヘッダ数を復号化すること、あるいは復号化対象の残りのヘッダがあるかを知らせるコード又はフラグを復号化することに基づいてもよい。
インデックス化ヘッダが復号化される度に、復号器は、ローカルインデックステーブルを使用してビットストリームからヘッダインデックスを復号化する(ステップ810)。ヘッダインデックスは、図14に示されるようにバイナリ表現から読み出されてもよい。ヘッダは、ビットストリームから復号化されたそのインデックスを使用してインデックステーブルから検索される。
その後、復号化ヘッダはメッセージヘッダリストに追加される。
ヘッダの構文解析(ヘッダ名とヘッダ値の分離、専用の構造におけるヘッダ値の構文解析)が実際には必要とされないため、この復号化ステップは高速且つ単純である。従って、復号化速度は向上する。
全てのインデックス化ヘッダが復号化されると、ビットストリームの文字通り/デルタ符号化されたセクションは、デフレートアルゴリズムを使用して伸張され(ステップ820)、取得されたバイナリストリームは、構文解析されて文字通り又はデルタ符号化されたヘッダの各々を処理する(ステップ830〜860)。
復号化は、伸張バイナリストリームから復号化するためにバイナリデータが残るかを確認することで開始する(ステップ830)。
その場合、次の符号化ヘッダは、ヘッダ名及びその値を検索することで伸張バイナリストリームから復号化される(ステップ820)。図15〜図17に示されるような符号化ヘッダのバイナリ表現のフラグは、符号化ヘッダがデルタ復号化されなければならないか(すなわち、ローカルインデックステーブルにおいて既にインデックス化されているヘッダを部分的に参照することで)、あるいは文字通り復号化されなければならないかを復号器が判定するのを支援する。
デルタ符号化される場合、ヘッダは、ローカルインデックステーブルにおいて参照からヘッダ名を検索すること及び差分値を取得することにより復号化される。
構文解析又は復号化されると、取得されたヘッダは、メッセージヘッダリストに追加される。
その後テストが実行され、この取得されたヘッダがインデックス化されなければならないか否かを確認する(ステップ850)。復号器は、生成されたビットストリーム情報に基づいて符号器により決定されたインデックス化戦略を実現する。符号器がインデックスフラグをビットストリームに追加した特定の場合において(図15〜図17の対応するフラグを参照)、そのフラグは、ビットストリームにおいて復号器により探索され、増分インデックス化と置き換えインデックス化のどちらかのインデックス化モードに従って復号化ヘッダがインデックス化されなければならないか否かを判定する。
復号化ヘッダは、インデックス化されなければならない場合、新しいエントリ(増分インデックス化)として又はデルタ復号化において参照として使用されたエントリ(置き換えインデックス化)の置換でローカルインデックステーブルに追加される(ステップ860)。
復号化ヘッダがインデックス化されなくてもよい場合又はこのインデックス化ステップ860の後で、復号化対象の後続のバイナリデータがステップ830で考慮される。
全てのヘッダが復号化されると、完全なメッセージヘッダリストは、それを処理するアプリケーションに提供される(ステップ870)。当然、ヘッダの順序が符号化ビットストリームにおいて規定されている場合、メッセージヘッダリストは、アプリケーションに提供される前に前記順序に従って再順序付けされる。
上述したように、いくつかのインデックス化戦略により、ある特定のヘッダ表現をグローバルテーブルを通して復号器又は符号器である同一のネットワークノードの種々の接続の間で共有できるようになる。これにより、制限された処理コストで種々の接続により使用されたローカルインデックステーブルのメモリコストを削減できるようになる。すなわち、グローバルヘッダテーブルは、接続のプールに対して規定され、全てのインデックス化ヘッダを格納してもよい。次に、接続毎に、特定のインデックステーブルは、その所定の接続のためにインデックス化されている厳密なヘッダに対する参照を格納する。
図4bは、対応する2つの接続のために共有グローバルテーブル及び2つのローカルインデックステーブルによるそのような戦略を示す。
次に、図9を参照して、共有グローバルテーブルに基づく符号化処理を説明する。
共有グローバルテーブルの使用に反して、デフレートバッファが継続的に更新されるため、いくつかの接続の間でデフレートバッファを共有するのは困難である。
このような状況において、メモリコストを共有するために共有グローバルテーブルを使用することにより、デフレートウィンドウを小さくすることで、インデックステーブルを通して非常に良好な圧縮率を維持しつつ、速度のゲイン及びメモリの節約を達成することが可能になる。
図7と比較して、ヘッダインデックス化ステップ740及びヘッダインデックス検索ステップ(ステップ710及び720)において、異なる方法が採られる。
詳細には、符号化処理は、符号化対象のヘッダを検索することで開始する(ステップ900)。
次にヘッダは、共有グローバルテーブルにおいて探索される(ステップ905)。高速に探索する従来の探索機構が使用されてもよい。
ヘッダは、発見されない場合にリテラルヘッダとして又はデルタ符号化を使用して符号化される(ステップ920〜940)。すなわち、ヘッダは、インデックスが判断される場合に共有グローバルテーブルに追加され(ステップ920)、その共有グローバルテーブルに格納されたヘッダ表現に対する参照は、当該接続(本明細書において処理されているヘッダを含むメッセージが属する接続−ステップ930)専用のローカルインデックステーブルに追加される。その後、ヘッダは、符号化され(参照ヘッダを使用して文字通り又はデルタ)、文字通り且つデルタ符号化されたヘッダの第2のリストにおいてデフレート圧縮される(ステップ935及び940)。
ヘッダが共有グローバルテーブルにおいて発見される場合、関連ヘッダ参照(すなわち、共有グローバルテーブルにおけるグローバルインデックス)は、ステップ950で検索される。この参照により、接続専用のローカルインデックステーブル内のその参照の存在をチェックすることで、当該接続のためにヘッダが既に符号化されているかを高速に確認できる(ステップ955)。
ヘッダは、接続のためにまだ符号化されていない場合、インデックス化が判断される場合に接続専用のローカルインデックステーブルにおいてインデックス化され(ステップ930)、適宜文字通り又はデルタ符号化され、文字通り且つデルタ符号化されたヘッダの第2のリストにおいて圧縮される(ステップ935及び940)。
ヘッダが接続のために既に符号化されている場合、ヘッダインデックスは、接続専用のローカルインデックステーブルから検索され、インデックスの第1のリストに格納される(ステップ960)。
全てのヘッダが処理されると、第1のリストのインデックスは、シリアル化バイナリ符号化表現に符号化され、連結された第1のリスト及び第2のリスト(すなわち、それらのシリアル化バイナリ表現)は、ステップ770及び780と同様に送出される(ステップ980及び990)。特に、ステップ940のデフレート圧縮は、ステップ970の後で、文字通り且つデルタ符号化された全てのヘッダのシリアル化バイナリ表現に対して一度だけ選択的に実行されてもよい。
図9の一変形例において、ステップ905で行われた探索は、接続専用のローカルインデックステーブル内でのみ実行されてよい。その場合、ヘッダインデックスは、接続専用のローカルインデックステーブルから直接検索される。例えば、ローカルインデックステーブルが、共有グローバルテーブルに対するポインタを使用してそのグローバルテーブルに実際に格納されるヘッダに対する参照のみを含む場合、これは、ローカルインデックステーブル内で探索されたヘッダに対するポインタを探索することで実行されてもよい。ポインタが発見されない場合、探索されたヘッダが共有グローバルテーブルに既に存在しているか否か、従って探索されたヘッダがローカルインデックステーブルに挿入される際にそのグローバルテーブルに挿入されるか否かを判定する必要がある。その結果、ステップ905のこの変形例は、ヘッダがローカルインデックステーブルに挿入される場合は常に共有グローバルテーブルにおいて更なる探索を必要とする。
特にそのグローバルテーブルを小さくする必要がある場合、この代替例は、共有グローバルテーブルの管理に対して影響を及ぼす。その場合、エントリは、グローバルテーブルから容易に除去されないだろう。1つの可能性は、図11のグローバルテーブルの移行を参照して以下において説明されるように、あるグローバルテーブルから別のグローバルテーブルに切り替えてある時点で古いグローバルテーブルを除去すること、又は図12のグローバルテーブルの最適化を参照して以下において説明されるように、しっかりと同期された共有グローバルテーブル及びローカルインデックステーブルを維持することである。
別の変形例において、共有グローバルテーブルは、共有可能なヘッダだけが実際にグローバルテーブルに格納されるように管理されてもよい。これは、グローバルテーブルにおけるヘッダがいくつかの接続を介して再利用される場合にのみメモリが節約されるためである。
特に、頻繁に共有可能なヘッダのみがそのグローバルテーブルに実際に格納されうる。例えば共有可能なヘッダは、HTTP標準に基づいて復号器及び符号器の双方により事前に判定され且つ認識されてもよい。それらは、以下において規定される専用ヘッダ以外のヘッダであってもよい。これにより、共有可能に格納される価値のあるヘッダを用いてメモリの使用を最適化することが可能になる。
管理の種々のレベルは、他のヘッダ(すなわち、共有されるものとして判定されない)に対して適用されてもよい。
例えば、専用ヘッダ(例えば、クッキー又は機密データ、「Host」又は「Referer」等の接続専用のデータ等)は、文字通り符号化されてからデフレート圧縮されてもよい。
別の例において、2レベルインデックス化機構が使用されることにより、頻繁であり且つ共有されるヘッダが共有グローバルテーブルに格納される一方で、頻繁であるが共有されない(すなわち、専用の)ヘッダは、接続専用のローカルインデックステーブルに格納される。他のヘッダはインデックス化されない。その場合、ローカルインデックステーブルは、グローバルテーブルを参照することでインデックス化されたヘッダと、ローカルインデックステーブル内でのみインデックス化されたヘッダとを含む。また、ローカルインデックステーブルにおいてのみ又はグローバルテーブルを参照することでヘッダをインデックス化することを決定することは、本実施形態において判定されたそのヘッダの頻度に依存する。
専用の共有可能な且つ/又は頻繁なヘッダは、符号器(及び必要であれば復号器)に提供された事前定義済みのリスト自体において規定されてもよい。
図10は、共有グローバルテーブルに基づいて対応する復号化を示すフローチャートである。図7の適応例である図9と同様に、図10の処理も図8の適応例である。
しかし、新たにインデックス化された全てのヘッダに対してグローバルテーブルにおいて更なる探索が実行され、これが復号器においてコストがかかりうるため、図10の処理は、図8の処理よりも多くの処理を必要とする。これは、共有グローバルテーブルを使用して又は使用せずに1つのヘッダ探索のみが必要とされる符号器における処理とは対照的である。これにより、処理速度を犠牲にしてメモリを節約できる。これらの欠点を緩和するために、インデックス化基準は、いくつかのヘッダ、例えば共有可能なヘッダ及び/又は上述したようにいくつかの接続において最も頻繁なヘッダのみをインデックス化するように限定されてもよい。
インデックス化ヘッダは、一般にビットストリームに最初に入れられるために最初に復号化される(ステップ1000及び1010、シリアル化されているだけの、すなわち符号化又はバイナリ圧縮はされていないヘッダを取得するあらゆる予備のステップに関係なく)。復号器は、ビットストリームからヘッダインデックスを復号化する。ヘッダインデックスは、図14に示されるようにバイナリ表現から読み出されてもよい。次にヘッダインデックスは、復号化ヘッダインデックスにより接続専用のローカルインデックステーブルにおいて直接ヘッダを発見するか、あるいは接続専用のローカルインデックステーブルにおいてグローバルテーブル及び復号化ヘッダインデックスと関連付けられた参照を使用してヘッダを発見する。その後、復号化ヘッダはメッセージヘッダリストに格納される。
これは、接続専用のローカルインデックステーブルがヘッダ表現又はグローバルテーブルに格納されるその表現に対する参照を格納できるためである。グローバルテーブルは、ストリングとして又は構文解析された表現でヘッダを直接格納してもよい。
次に、文字通り/デルタ符号化されたヘッダは、ステップ1020〜1090により復号化される。
ビットストリームは、バイナリストリームを取得するために最初にデフレートを使用して伸張される(ステップ1020)。
その後、より多くのデータが使用不可能になるまで(テスト1030)、伸張バイナリストリームは、図15〜図18に示されるバイナリ表現に従ってそれを構文解析するように処理される。バイナリデータが使用可能である限り、ヘッダは最初に構文解析される。フラグは、符号化ヘッダがデルタ復号化又は文字通り復号化されなければならないかを判定するために読み出される/ヘッダ名及びヘッダ値は、参照ヘッダを使用して取得され(デルタ符号化の場合)、結果として得られる復号化ヘッダは、メッセージヘッダリストに追加される(ステップ1050)。
ステップ850と同様に、ヘッダをインデックス化するための戦略は、例えばバイナリ表現で対応するフラグを読み出すことでステップ1060で判定される。
ヘッダがインデックス化されなくてもよい場合、復号化処理は別のヘッダを継続する(ステップ1030に戻る)。
ヘッダがインデックス化されなくてはならない場合、ステップ1070でヘッダが既にグローバルテーブルにあるかがテストされる。
ヘッダは、まだグローバルテーブルにない場合、ステップ1080で新しいエントリとして又は使用された参照ヘッダの置換でグローバルテーブルに追加され、これは、その新しいヘッダと関連付けられた参照が作成されることを意味する。特に、殆どの場合、ヘッダは新しいエントリとして追加される。
ヘッダが既にグローバルテーブルにある場合又はステップ1080の後で、ヘッダは、対応するインデックスをグローバルテーブルヘッダエントリに対する参照と関連付けることにより、ステップ1090で接続専用のローカルインデックステーブルに追加される。
全てのバイナリデータが処理されると、復号化ヘッダ(すなわち、場合によっては符号器によりビットストリームにおいて規定された順序に従って再順序付けされたメッセージヘッダリスト全体)は、例えばアプリケーションへの出力として提供される(ステップ1040)。
図11及び図12を参照して以下において説明される本発明の特定の実施形態において、共有グローバルテーブルの使用の最適化は、メモリ消費を減少する目的で行われる。
共有グローバルテーブルがいくつかの接続の寿命にまたがるため、そこにおけるいくつかのヘッダは、所定の接続が解除される場合に関係がなくなるだろう。
共有グローバルテーブルは、使用されるヘッダ数が実際には増加しないかもしれないが増大し続ける。従って、共有グローバルテーブルにおけるヘッダが既存の接続に関連したままであることを保証し、且つ現在の接続とはもう関係ないグローバルテーブルヘッダから除去する必要性がある。図11及び図12の最適化は、符号器においてこの問題に対処する。当然、同様の最適化が対応する復号器において行われるべきである。
図11は、現在の接続を現在のグローバルテーブルから新しいグローバルテーブルに移行するステップを示すフローチャートである。新しいグローバルテーブルは、現在のグローバルテーブルとは異なり使用されていないヘッダがない。
この処理は、所定の時間においてある共有グローバルテーブルから別のグローバルテーブルに切り替えることに基づく。すなわち、ある時点において、共有グローバルテーブルが作成され、全ての新しい接続が新しい共有グローバルテーブルを使用する一方で、古い接続は、初期の共有グローバルテーブルを用いたままである。古い共有グローバルテーブルは、小さい数に減少する接続数を有し、その時間において、残りの接続は新しい共有グローバルテーブルに移行される。古い共有グローバルテーブルは、削除されてメモリ空間を解放する。
この方法は、グローバルテーブルにより使用されたメモリ全体がある期間にわたり増大し続けないことを保証する。
図11の処理は、ローカルインデックステーブル及び現在の共有グローバルテーブルに基づいてメッセージを符号化するネットワークノードにより受信されたネットワーク事象を待つことにより、ステップ1100で開始する。全ての現在の接続は、同一の現在の共有グローバルテーブルAにリンクされると仮定され、それは、それらの接続専用のローカルインデックステーブルが全てそのグローバルテーブルAを示すことを意味する。
入力ネットワーク事象が新しい接続である場合(ステップ1110でのテスト)、現在の共有グローバルテーブルがリフレッシュされる必要があるか否かが最初に確認される(ステップ1115)。リフレッシュ基準は、種々の情報、すなわち現在のグローバルテーブルの寿命及び/又はグローバルテーブルが作成されてから解除された接続数等に基づいてもよい。また、現在のグローバルテーブルが既に移行段階にある(以下において説明されるように、新しいグローバルテーブルが既に作成されていることを意味する)場合、現在のグローバルテーブルをリフレッシュする必要はない。
グローバルテーブルがリフレッシュされる必要がある場合、新しいグローバルテーブルBがステップ1120で作成される。それは、現在共有されているグローバルテーブルに関連する少なくとも1つの基準に依存して、新しい接続に対する要求を受信すると新しいグローバルテーブルが作成されることを意味する。このグローバルテーブルBは、空のテーブルとして初期されてよく、あるいは一般に使用されるヘッダで事前に満たされてよい。次に、新しい接続(受信される事象に対応する)は、ステップ1125でその新しいグローバルテーブルにリンクされ、それは、対応する接続専用のローカルインデックステーブルがインデックスをその新しいグローバルテーブルB(現在のグローバルテーブルAではなく)に対する参照と関連付けることを意味する。
受信したネットワーク事象が、移行が進行している間の新しい接続(ステップ1110でのテスト)又は接続の終了(ステップ1130でのテスト)である場合、ヘッダが処理される必要があるか否かがステップ1150で確認される。2つのグローバルテーブルA及びBが同時に存在している場合、移行は進行中である。
ヘッダが処理される(ステップ1150で「no」を出力する)必要がない場合、受信したネットワーク事象に捧げられた処理は、ステップ1100に戻ることで新しいネットワーク事象を待つ前にステップ1175で実行される。
ヘッダが処理されなければならない場合、そのヘッダは、接続専用のローカルインデックステーブルに基づいて符号化され(インデックスは、既に存在している場合に接続がリンクされるグローバルテーブルを使用して検索される)、リンクされたグローバルテーブル及び接続専用のローカルインデックステーブルは、処理済みのヘッダが挿入される必要がある場合に更新される(ステップ1155)。
選択的なステップ(ステップ1160)は、グローバルテーブルA及びBにより使用された合計メモリを被覆するために実行されてもよい。すなわち、処理済みのヘッダがインデックス化されてテーブルに追加されると合計メモリが所定の閾値を上回る場合(テスト1160)、いくつかのエントリは、メモリ消費を減少するためにグローバルテーブルAから除去されてもよい(ステップ1170)。除去可能なエントリの例は、最も古いエントリ、最も頻繁に使用されないエントリ等である。当然、エントリがグローバルテーブルから除去される場合、グローバルテーブルに対する参照が存在しないため、ローカルインデックステーブルにおける対応するエントリも除去されなければならない。
その後、次のネットワーク事象を待つステップ1100に戻る。
受信したネットワーク事象が接続事象の終了であり且つ移行が進行中である(ステップ1130で検出された)場合、少数の接続だけが現在のグローバルテーブルAにリンクされるか否かがステップ1135で確認される。少数は、例えば接続中の5%より少ない所定の数の接続を意味するのが有利である。
このような場合、これらの全ての接続(グローバルテーブルAにリンクされた)は、新しいグローバルテーブルBに移行される(ステップ1140)。すなわち、これは、現在のグローバルテーブルAから現在の接続により使用されたエントリを除去することと、除去されたこれらのエントリを新しいグローバルテーブルBに追加することと、それから前記現在共有されているグローバルテーブルをメモリから削除することとを含む。当然、移行されたこれらの接続のローカルインデックステーブルは、ここで削除されたグローバルテーブルAの削除されたエントリではなく、新しいグローバルテーブルBに移行されたエントリを示すように更に更新されなければならない。これらのエントリの重複を回避しつつ、除去されたエントリをBに追加してもよい。すなわち、除去されたエントリは、Bに既に存在している場合にはそこに追加されないが、移行された接続のローカルインデックステーブルは、ここでこの既に存在しているエントリを示すように更新される。
処理のこの部分において、現在の接続を移行することは、現在の接続を終了する要求を受信するとそのようにトリガされる。
この処理の利点は、移行段階処理が、時間的に制限され、ネットワークノードが使用可能な処理機能を有する場合に実行されてもよいことである。特に、ステップ1140は非同期に実行されてもよい。
次に、図12を参照して異なる方法を説明する。図12において、グローバルテーブルを作成及び削除するのではなく、現在のグローバルテーブルは、現在の接続と同期され続け、すなわち、グローバルテーブルにおける全てのヘッダは現在の接続により使用される(すなわち、ローカルインデックステーブルにより参照される)。現在のグローバルテーブルが長期間にわたり接続と自然に同期されたままでない危険性がある場合、そのような方法は図11の方法にとって好ましい。
図12の方法において、グローバルテーブルにおける各インデックス化ヘッダは、そのインデックス化ヘッダを使用して接続数をカウントする接続カウンタと関連付けられ、メモリ節約動作は、インデックス化ヘッダの接続カウンタに基づいて実行される。特に、メモリ節約動作は、対応する接続カウンタがゼロであるグローバルテーブルから何らかのインデックス化ヘッダを除去することを含む。これは、グローバルテーブルが現在の接続により使用されるヘッダのみを格納することを保証する。従って、グローバルテーブルは現在の接続の状態と同期される。
処理は、ネットワークノードにより受信されたネットワーク事象を待つことでステップ1235で開始してもよい。
受信した事象に基づいて、新しいヘッダが処理されなければならないか否かがステップ1200で最初に確認される。
新しいヘッダが処理されなければならない場合、新しいヘッダがインデックス化されるべきか否かがステップ1210で確認される。
新しいヘッダがインデックス化されるべきである場合、その表現がグローバルテーブルに既にあるか否かがステップ1220で確認される。
その表現が既に存在している場合、グローバルテーブルにおけるそのヘッダのエントリと関連付けられたカウンタは、ステップ1230で増分される。カウンタは、対応するヘッダを使用する接続数を反映するために使用される。このような状況において、それは「接続カウンタ」と命名される。
その表現が存在しない場合、ヘッダはグローバルテーブルに追加され、その接続カウンタは、1だけ増分される(ステップ1230)前に0に初期化される(ステップ1225)。
ステップ1230の後で、次のネットワーク事象を待つステップ1235に戻る。
受信した事象が処理対象の新しいヘッダではない場合、それが接続の終了事象であるか否かが確認される(ステップ1240でのテスト)。
それが接続の終了事象である場合、接続は、そのように停止されている(対応するローカルインデックステーブルが近い将来削除されることを意味する)。停止された接続専用のローカルインデックステーブルにおいてインデックス化された全てのヘッダは、削除の前に処理される。
そのローカルインデックステーブルにおけるエントリ毎に(テスト1250)、グローバルテーブルにおける対応する接続カウンタは、ステップ1255で1だけ減分される。「対応する接続カウンタ」は、グローバルテーブルにおいてローカルインデックステーブルの当該エントリに示された参照を有するエントリと関連付けられたカウンタである。
接続カウンタが0になる場合(テスト1260)、ヘッダ表現は、ステップ1265でグローバルテーブルから除去されてメモリ空間を解放する。
ローカルインデックステーブルの全てのエントリが処理されると、ステップ1235に戻る。
受信したネットワーク事象は、処理対象のヘッダ又は接続の終了事象でもない場合、ステップ1235に戻る前にステップ1270で専用の処理により慣例的に処理される。
図12の処理により、グローバルテーブルとローカルインデックステーブル(すなわち、現在の接続)とをしっかりと同期できる。接続カウンタがグローバルテーブルのヘッダ毎に最新の状態を維持されるため、これは、ネットワーク通信の間に同期に行われなければならない処理及び何らかの更なるメモリ消費を犠牲にして進む。
グローバルテーブルの使用を最適化するこれらの処理に加えて、更なる最適化処理があってもよい。
例えば、ネットワークノードがメモリ空間を解放する必要があってもよい。その場合、グローバルテーブルは、削除、すなわちグローバルテーブルを小さくするための適切なエントリを発見するために走査されてもよい。1つの方法は、閾値より小さい値の接続カウンタと関連付けられたインデックス化ヘッダを使用する現在の接続をリセットすることを含む。上述したものと同一の接続カウンタが使用される。接続カウンタが小さい値を有する全てのヘッダを判定すると、対応する接続(判定されたヘッダを使用する接続)はリセットされる。これにより、インデックス化ヘッダを有さない真新しい接続を開くようにクライアントに強制することを犠牲にして、グローバルテーブルから全ての低カウンタヘッダを除去できる。
当然、ヘッダをグローバルテーブルから強制的に除去するために、接続カウンタ単独以外の基準が使用されてもよい。例えば基準は、グローバルテーブルにおいてエントリ毎に規定された作成日又は最終利用日(日付は完全な日付である必要はないが、例えば0〜15分の時間を測定できるようにする1分の範囲に対応する4ビットの整数である規則的に増加された短縮整数であってよい)に基づいてもよい。従って、最も古いヘッダのみが除去される。
別の更なる最適化処理は、メモリを解放する要求を受信すると、ローカルインデックステーブルにおいてインデックス化されたヘッダ数(すなわち、一般に既に使用されているインデックスの最大数)をメモリに保存することと、グローバルテーブルを削除することと、保存した数から始まるインデックスを使用してローカルインデックステーブルにおいて新しいヘッダをインデックス化することとを含んでもよい。当然、これは、削除されたグローバルテーブルにリンクされた接続に対応する全てのローカルインデックステーブルに対して実行されてもよい。
従って、各ローカルインデックステーブルは、過去のエントリ数を維持し、第1のインデックスとしてその数を使用して新しいエントリ(すなわち、ヘッダ)をインデックス化する。これにより、新しいヘッダインデックスをテーブルをインデックス化する符号器に準拠したままにできる。
特に、復号器は、過去のエントリ数から始まる新しいインデックスを検出できるため、グローバルテーブルの同一の削除を実行するように強制されない。しかし、復号器は、符号器と同一の削除戦略を実現でき、これは、それら双方が同時にメモリを解放し且つ同一の削除を実行する要求を受信することを意味する。
一変形例において、復号器は、フラグをビットストリームに追加して、それがメモリを解放した時を復号器に示してもよい。これにより、復号器は、復号化処理において同時にそのメモリ(グローバルテーブル)もフラッシュできるようになる。
上述の処理は、情報項目(SPDYの場合にはHTTPヘッダ)をインデックス化することに基づく。
しかし、プロセッサは、いずれか又は全てのネットワーク接続に対するこのヘッダインデックス化を有効又は無効にすることを決定してもよい。この決定をどの基準に基づかせるかは、速度又は圧縮の向上に関連してもよい。
圧縮の向上に関して、ヘッダインデックス化方法(すなわち、インデックスの使用)は、デフレート圧縮率の計算に基づいて有効にされてもよい。
例えば、現在の接続の第1の要求及び第2の要求のヘッダに対して達成された圧縮率が計算されてもよい。次に、第2の要求に対する圧縮率(率H2)が第1の要求の圧縮率(率H1)よりそれほど高くない場合、ヘッダインデックス化はかなりの圧縮率の向上をもたらす。80%は率H2/H1がヘッダインデックス化をトリガするのに適切な閾値である(H2/H1≧80%の場合)ことが観察されている。
これは、おそらくコンテキスト(スライディングウィンドウ)が小さすぎるために、第1の要求から構築されたデフレート圧縮コンテキストが第2の要求に対して効率的に使用されないように見えるためであったからである。
速度の向上に関して、接続において送受信されたメッセージの数は、速度性能に密接に関連するように見える。
これを示すために、単一のメッセージが接続において送受信される場合、ローカルインデックステーブルを構築するコストは、少ない場合であっても、そのインデックステーブルを使用することで補償されない。
送受信されるメッセージの数が増加するとすぐに、インデックステーブルが益々使用されるようになり、その結果速度ゲインが得られる。一般にヘッダインデックス化は、6個以上のメッセージを含む送受信に対してかなりの速度の向上をもたらし、11個以上のメッセージを含む送受信に対して2倍の速度の向上をもたらす。
次にネットワークノードは、接続毎のメッセージの数に対する統計を計算することを決定してもよく、全てのネットワーク化ノードに対する平均数又はネットワークノード毎の平均数に基づいて、ヘッダインデックス化を使用するか否かが決定されてもよい。
次に、図14〜図18を参照して、ヘッダに対するバイナリ表現が符号化される(文字通り、デルタ符号化、インデックス)方法に依存するそれらの例を説明する。
図14は、ローカルインデックステーブルからのインデックスを使用して符号化される第1のリストのヘッダに対するバイナリ表現を示す。
第1のバイトは、ヘッダがインデックスを使用して完全に符号化されることを規定するために「1」に設定された第1のビットを含む。バイトの残りの7ビットは、インデックス値が0〜126(「000 0000」〜「111 1110」のビット値)を含むかを規定するために使用される。
インデックス値が126より大きい場合、7ビットは、127、すなわち「111 1111」に設定される。また、後続のバイトは、インデックス値−127(127〜382のインデックスを符号化する「0000 0000」〜「1111 1111」のビット値)を規定するために使用される。
本実施形態において、インデックス値は382より大きくなり得ない。当然、例えば別の更なるバイトが使用されることを規定するために更なるバイトに対して1つの特定の値を使用することにより、他の実現例は382より大きいインデックス値を許可してもよい。
図15は、文字通り符号化される第2のリストのヘッダに対するバイナリ表現を示す。示されるバイトは、そのようなリテラル符号化が使用されることを規定し且つヘッダ名を符号化するために使用される。図18で以下において示されるようにヘッダ値を文字通り符号化する1つ以上のバイトは、バイト(場合によってはいくつかのバイト)に後続する。
示されたバイトの第1のビットは、ヘッダが図14のようなインデックスを使用して符号化されないことを規定するために「0」に設定される。
第2のビットは、デルタ符号化が使用されるか否かを規定するために使用される(図16及び図17を参照して以下のデルタ符号化を参照)。図15がリテラル符号化に対応する時、この第2のビットは「0」に設定される。
第3のビットは、符号化されているヘッダが更なるインデックス化のためにローカルインデックステーブルにおいてインデックス化されなければならないか否かを規定するために使用される。同一のビットは、図16及び図17)のデルタ符号化の場合に同一の機能に対して使用される。
符号器がヘッダをインデックス化しないことを決定する場合(ステップ740を参照)、この第3のビットは「0」に設定される。符号器がヘッダをインデックス化することを決定する場合、この第3のビットは、ヘッダがローカルインデックステーブルに追加されなければならないことを復号器に示す「1」に設定される。
残りの5ビットは、(ビット3〜7)は、ヘッダ名を符号化するために使用される。
一実施形態において、ヘッダ名を符号化するために、周知のHTTPヘッダ名を含むHTTPヘッダ名のリストが使用される。最も頻繁なヘッダは、より効率的に符号化されうるように最もインデックス化されていない割り当てられる。このリストは、静的であり、符号器と復号器との間で共有される。すなわち、新しいヘッダ名をこのリストに追加できない。新しくヘッダ名はサーバからダウンロードされてもよい。
一実施形態において、周知のヘッダ名に加えて余分なヘッダ名が使用されてもよいため、余分なヘッダ名を含む別のリスト(すなわち、余分なヘッダ名のリスト)が更に規定される。このリストは最初は空であるが、符号器は、自由にそこにヘッダ名を追加する。その結果、余分なHTTPヘッダ名は、所定の接続上に2回以上現れる場合、1回だけ文字通り符号化されて、次に余分なヘッダ名のリストのエントリに対する参照として符号化されるべきである。
ヘッダ名に対するインデックス化規則は、符号器及び復号器の双方から認識され、同期を保証する。
残りの5ビットは、以下のいくつかの値を取ってもよい。
例において「0 0000」「1 1100」である値の範囲は、インデックスが0〜28に含まれる場合に既知のヘッダ名のインデックスを符号化するために使用される;
例において「1 1101」である値は、既知のヘッダ名のインデックスが28より大きいかを示すために使用される。その場合、現在のバイトに後続する1つ又はいくつかの更なるバイト(不図示)は、インデックス−29を符号化するために追加される;
例において「1 1110」である値は、新しい余分なヘッダ名が文字通り符号化されることを示すために使用される。その場合、現在のバイトに後続する1つ又はいくつかの更なるバイト(不図示)は、新しい余分なヘッダ名を文字通り符号化するために追加される。すなわち、その長さが最初に符号化され、次にその値が符号化される。その様な値を検出すれば、新しい余分なヘッダ名が余分なヘッダ名のリストに追加されなければならないことを復号器が認識できる;
この例において「1 1111」である値は、ヘッダ名が余分なヘッダ名のリストにおいて既にインデックス化されている余分なヘッダ名のインデックスを使用して符号化される。その場合、現在のバイトに後続する1つ又はいくつかの更なるバイト(不図示)は、余分なヘッダ名のリストにそのような余分なヘッダ名のインデックスを含む。
図16及び図17は、デルタ符号化される第2のリストのヘッダに対するバイナリ表現を示す。図16は、更なるインデックス化のためにデルタ符号化されたヘッダをインデックス化しないことが決定される場合に対応する。図17は、更なるインデックス化のためにデルタ符号化されたヘッダをインデックス化することが決定される場合に対応する。
示されるバイトは、そのようなデルタ符号化が使用されることを規定し、且つデルタ符号化のために参照として使用される既にインデックス化されているヘッダのインデックスを符号化するために使用される。図18で以下において示されるようなヘッダ値フレームを使用してヘッダ値を符号化し、特にヘッダ値と参照ヘッダにより取られた値との間の共通部分を規定し、且つ値の間の差分を文字通り符号化するために、1つ以上のバイトはバイト(場合によってはいくつかのバイト)に後続する。
図15を参照して上述したように、バイトの第1のビットは、ヘッダが図14のようなインデックスを使用して符号化されないことを規定するために「0」に設定され、第2のビットは、デルタ符号化が使用されることを規定するために「1」に設定される。
図16において、ヘッダを符号化するためにインデックスが要求されないため、第3のビットは「0」に設定される。
その場合、残りの5ビット(ビット3〜7)は、デルタ符号化のために参照として使用された参照ヘッダのインデックスを符号化するために使用される。それらは、以下のいくつかの値を取ってもよい。
例において「0 0000」〜「1 1110」である値の範囲は、インデックスが0〜30に含まれる場合に参照ヘッダのインデックスを符号化するために使用される;
例において「1 1111」である値は、参照ヘッダのインデックスが30より大きいことを示すために使用される。その場合、現在のバイトに後続する1つ又はいくつかの更なるバイト(不図示)は、参照ヘッダ−31のインデックスを含む。
ヘッダ値を符号化する1つ以上のバイトは、このような1つ又は複数のバイトに後続する。
一実施形態において、第1のバイト(又は必要であればより多くのバイト)は、符号化されているヘッダ値及び参照ヘッダにより取られたヘッダ値により共有された共通のプレフィックスの長さを含む。共通のプレフィックスは、2つの値の間の同様に開始する文字の数であってもよい。0〜127の長さが1バイト上に符号化されるのに対し、128〜32896の長さは2バイト上に符号化される。
図18で以下において示されるように2つの値の間の差分を文字通り符号化する1つ以上のバイト(すなわち、共通のプレフィックスが符号化されているヘッダ値から破棄されている間の残りのデータ)は、共通のプレフィックスの長さを規定するためのバイトに後続する。
2つの値(符号化されているヘッダ値及び参照ヘッダにより取られたヘッダ値)が数である別の実施形態において、2つの値の間の数の差分だけが、図18のヘッダ値フレームのみを使用して文字通り符号化されうる(共通のプレフィックスの長さを規定するためのバイトは使用されていない)。
図16とは異なり、図17において、ヘッダを符号化するためにインデックスが要求されるため、第3のビットは「1」に設定される。
その場合、第4のビットは、符号器により決定されるようなインデックス化モード、すなわち増分インデックス化と置き換えインデックス化との間のを規定するために使用される。例えば第4のビットは、増分インデックス化が決定されている場合には「0」に設定され、置き換えインデックス化が決定されている場合には「1」に設定される。
本実施形態において、第3のビットと第4のビットとの組合せは、符号化されているヘッダのインデックス化を規定するためのバイナリフラグを与える。
残りの4ビット(ビット4〜7)は、デルタ符号化のために参照として使用された参照ヘッダのインデックスを符号化するために使用される。それらは、以下のいくつかの値を取ってもよい。
例において「0000」〜「1110」である値の範囲は、インデックスが0〜14に含まれる場合に参照ヘッダのインデックスを符号化するために使用される;
例において「1111」である値は、参照ヘッダのインデックスが14より大きいことを示すために使用される。その場合、現在のバイトに後続する1つ又はいくつかの更なるバイト(不図示)は、参照ヘッダ−15のインデックスを含む。
図16の場合と同様に、ヘッダ値を符号化する1つ以上のバイトは、このような1つ又は複数のバイトに後続する。
一実施形態において、第1のバイト(又は必要であればより多くのバイト)は、符号化されているヘッダ値及び参照ヘッダにより取られたヘッダ値により共有された共通のプレフィックスの長さを含む。共通のプレフィックスは、2つの値の間の同様に開始する文字の数であってもよい。0〜127の長さが1バイト上に符号化されるのに対し、128〜32896の長さは2バイト上に符号化される。
図18で以下において示されるように2つの値の間の差分を文字通り符号化する1つ以上のバイト(すなわち、共通のプレフィックスが符号化されているヘッダ値から破棄されている間の残りのデータ)は、共通のプレフィックスの長さを規定するためのバイトに後続する。
2つの値(符号化されているヘッダ値及び参照ヘッダにより取られたヘッダ値)が数である別の実施形態において、2つの値の間の数の差分だけが、図18のヘッダ値フレームのみを使用して文字通り符号化されうる(共通のプレフィックスの長さを規定するためのバイトは使用されていない)。
図18は、文字通り符号化される第2のリストのヘッダ値(上述したように異なる値を含む)に対するバイナリ表現を部分的に示す。
ヘッダ値は、最初にそれらの長さを示し、次にそれらの値を示すことで文字通り符号化される。デルタインデックス化の場合、デルタ値はヘッダ値と同様に符号化される。しかし、相補的なデータは、ヘッダ値全体がこのデルタ値から取得されうる方法を示す(例えば、共通部分の定義バイトを使用して)。
符号化対象の値の長さは、1バイト又は2バイトに規定される。
図18に示されるような第1のバイトの第1のビットは、長さが1バイト(「0」に設定された第1のビット)又は2バイト(「1」に設定された第1のビット)上に符号化されるかを示す。
第1のビットが「0」である場合、ヘッダ値の長さは、バイトの残りの7ビット(0〜127の長さ)上に符号化される。第1のビットが「1」である場合、ヘッダ値の長さ−128は、次の15ビット(128〜32,896の長さ)上に符号化される。
次に値は、以下のバイト(不図示、すなわちその数はヘッダ値の長さに依存する)上に符号化される。
特定の実施形態を参照して本発明を上述したが、本発明は特定の実施形態に限定されず、本発明の範囲内にある変更は当業者には明らかとなるだろう。単なる一例として与えられ且つ添付の特許請求の範囲により判定されるような本発明の範囲を限定することを意図しない上述の例示的な実施形態を参照することにより、多くの更なる変更及び変形が当業者に提案されるだろう。特に、種々の実施形態とは異なる特徴が適宜交換されてもよい。

Claims (56)

  1. 情報の項目の初期リストを含むメッセージをビットストリームに符号化する方法であって、
    ローカルインデックステーブルにおいて既にインデックス化されている前記初期リストの情報項目と関連付けられたインデックスの第1のグループ及び前記ローカルインデックステーブルにおいてまだインデックス化されていない前記初期リストの他の情報項目のリテラル値の第2のグループを判定するステップと、
    前記第1のグループの前記インデックスを符号化するステップと、
    前記第2のグループの前記リテラル値の少なくともシリアル化バイナリ表現をバイナリ圧縮するステップと、
    前記第1のグループ及び前記第2のグループを共に連結して前記情報項目の符号化ビットストリームを得るステップと、
    を備えることを特徴とする方法。
  2. 前記他の情報項目の少なくとも1つは、前記ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで符号化され、
    前記他の情報項目の前記リテラル値は、前記他の情報項目により取られた値と参照として既にインデックス化及び使用されている前記情報項目により取られた値との差分を示すことを特徴とする請求項1に記載の符号化方法。
  3. 前記他の情報項目に対応する前記シリアル化バイナリ表現のバイナリサブパートは、前記他の情報項目の前記リテラル値に加えて、参照として既にインデックス化及び使用されている前記情報項目のインデックスを含むことを特徴とする請求項2に記載の符号化方法。
  4. 前記ローカルインデックステーブルにおいて既にインデックス化されている前記情報項目を、既にインデックス化されている前記情報を参照することで符号化された前記他の情報項目で置き換えるステップを有することを特徴とする請求項2又は3に記載の符号化方法。
  5. 前記他の情報項目の1つに対応する前記シリアル化バイナリ表現のバイナリサブパートは、前記他の情報項目の前記リテラル値に加えて、前記他の情報項目が前記ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで符号化されるか否かを規定する第1の1ビットフラグと、前記他の情報項目が更なるインデックス化のために前記ローカルインデックステーブルに追加されなければならないか否かを規定する第2のバイナリインデックスフラグとを含むことを特徴とする請求項1に記載の符号化方法。
  6. 前記第2のバイナリフラグは、前記他の情報項目が、新しいエントリとして又は参照として既にインデックス化及び使用されている前記情報項目の置き換えにより前記ローカルインデックステーブルに追加されなければならないかを規定するためのビットを含むことを特徴とする請求項5に記載の符号化方法。
  7. 前記バイナリサブパートは、前記他の情報項目により取られた値と参照として既にインデックス化及び使用されている前記情報項目により取られた値との間の共通部分の長さを規定するためのバイナリフィールドを含むことを特徴とする請求項3又は6に記載の符号化方法。
  8. 前記バイナリサブパートは、項目名テーブルにおける前記他の情報項目の名前に対応するインデックスを規定するためのバイナリフィールドを含むことを特徴とする請求項5に記載の符号化方法。
  9. インデックスの前記第1のグループは、前記符号化ビットストリームにおいてリテラル値の前記第2のグループに先行することを特徴とする請求項1に記載の符号化方法。
  10. 前記連結するステップは、前記連結された第1のグループ及び第2のグループのシリアル化バイナリ表現を生成し、前記バイナリ圧縮するステップは、前記シリアル化バイナリ表現全体を圧縮することを特徴とする請求項1に記載の符号化方法。
  11. 情報の前記項目は、HTTPメッセージのHTTPヘッダであることを特徴とする請求項1記載の符号化方法。
  12. HTTPヘッダは、少なくともHTTP名及びHTTP値から構成され、前記第1のグループのインデックス化HTTPヘッダは、HTTP名をインデックス化するインデックス及び前記リテラルHTTP値を含むことを特徴とする請求項11に記載の符号化方法。
  13. HTTPヘッダは、少なくともHTTP名及びHTTP値から構成され、前記方法は、インデックスレベルフラグをHTTPヘッダと関連付けるステップを有し、前記インデックスレベルフラグが、前記HTTPヘッダに依存して、前記HTTPヘッダが前記ローカルインデックステーブルにおける前記対応する情報項目と同一のHTTP名及びHTTP値を有することを示す第1の完全なインデックス化状態、又は前記HTTPヘッダが前記ローカルインデックステーブルにおける前記対応する情報項目と同一のHTTP名であるが異なるHTTP値を有することを示す第2の部分的なインデックス化状態を取ることを更に備えることを特徴とする請求項11に記載の符号化方法。
  14. 前記HTTPヘッダは、前記第1のグループのインデックス化HTTPヘッダであることを特徴とする請求項13に記載の符号化方法。
  15. インデックス化HTTPヘッダに対する前記インデックスレベルフラグが前記第2の部分的なインデックス化状態である場合、前記インデックス化HTTPヘッダの前記異なるHTTP値は、前記異なるHTTP値と前記ローカルインデックステーブルにおける前記対応する情報項目の前記HTTP値との差分を使用して符号化されることを特徴とする請求項13に記載の符号化方法。
  16. 前記ローカルインデックステーブル内で前記第2のグループの少なくとも1つの情報項目を新しいインデックスと関連付けることにより、そのローカルインデックステーブルを更新するステップを更に備えることを特徴とする請求項1に記載の符号化方法。
  17. 前記符号化ストリームにおいて、前記更新中に新しいインデックスと関連付けられる前記第2のグループのバイナリ圧縮された各情報項目とインデックスフラグを関連付けるステップを更に備えることを特徴とする請求項16に記載の符号化方法。
  18. 前記第2のグループの情報の項目の出現の頻度を判定することと、前記判定された頻度に依存して前記ローカルインデックステーブルにおいて情報の前記項目をインデックス化することを決定するステップとを更に備えることを特徴とする請求項16に記載の符号化方法。
  19. 前記ローカルインデックステーブルは、各インデックスと関連付けられた情報の前記項目を含む前記グローバルテーブルのエントリに対する参照と前記インデックスを関連付けることを特徴とする請求項1に記載の符号化方法。
  20. 前記ローカルインデックステーブルは、前記グローバルテーブルを参照することでインデックス化された情報の少なくとも1つの項目及び前記ローカルインデックステーブル内でのみインデックス化された情報の少なくとも1つの項目を含むことを特徴とする請求項19に記載の符号化方法。
  21. 情報の項目の出現の頻度を判定するステップと、前記判定された頻度に依存して前記ローカルインデックステーブルにおいてのみ又は前記グローバルテーブルを参照することで情報の前記項目をインデックス化することを決定するステップとを更に備えることを特徴とする請求項20に記載の符号化方法。
  22. 前記グローバルテーブルは、複数の圧縮器の間で共有され、前記複数の圧縮器により処理されたメッセージからの情報の項目を含み、各圧縮器が、前記共有グローバルテーブルを参照することで、自身が処理するメッセージからの情報の項目をインデックス化するためにそのローカルインデックステーブルを有することを特徴とする請求項19記載の符号化方法。
  23. 前記第1のグループ及び前記第2のグループを判定するステップは、前記初期リストの前記情報項目に対応するエントリを前記グローバルテーブルにおいて探索するステップと、発見された前記エントリに対する参照を前記ローカルインデックステーブルにおいて探索するステップとを含むことを特徴とする請求項19に記載の符号化方法。
  24. 前記グローバルテーブルは、複数のネットワーク接続の間で共有され、対応する複数のそれぞれのローカルインデックステーブルにより参照され、
    前記方法は、前記符号化中のある時点において、現在の接続を前記共有グローバルテーブルから新しいグローバルテーブルに移行するステップを更に備えることを特徴とする請求項19に記載の符号化方法。
  25. 前記新しいグローバルテーブルは、前記現在共有されているグローバルテーブルに関連する少なくとも1つの基準に依存して、新しい接続に対する要求を受信すると作成されることを特徴とする請求項24に記載の符号化方法。
  26. 現在共有されているグローバルテーブル及び新しいグローバルテーブルの双方を格納するために使用されたメモリの量に基づいて、前記現在共有されているグローバルテーブルからエントリを除去するステップを更に備えることを特徴とする請求項24に記載の符号化方法。
  27. 現在の接続を移行するステップは、現在の接続を終了する要求を受信するとトリガされることを特徴とする請求項24に記載の符号化方法。
  28. 現在の接続を移行するステップは、前記現在の接続により使用されたエントリを前記現在共有されているグローバルテーブルから除去するステップと、除去されたこれらのエントリを前記新しいグローバルテーブルに追加するステップと、その後前記現在共有されているグローバルテーブルをメモリから削除するステップとを含むことを特徴とする請求項24に記載の符号化方法。
  29. 前記グローバルテーブルは、複数のネットワーク接続の間で共有され、対応する複数のそれぞれのローカルインデックステーブルにより参照され、前記共有グローバルテーブルにおける各インデックス化情報項目は、そのインデックス化情報項目を使用して接続数をカウントする接続カウンタと関連付けられ、
    前記符号化方法は、前記インデックス化情報項目の接続カウンタに基づいてメモリ節約動作を実行するステップを更に備えることを特徴とする請求項19に記載の符号化方法。
  30. 前記メモリ節約動作は、前記対応する接続カウンタがゼロの場合に前記共有グローバルテーブルから前記インデックス化情報項目を除去するステップを含むことを特徴とする請求項29に記載の符号化方法。
  31. 前記メモリ節約動作は、閾値より小さい値の接続カウンタと関連付けられたインデックス化情報項目を使用する前記現在の接続をリセットするステップSを含むことを特徴とする請求項29に記載の符号化方法。
  32. メモリを解放の要求の受信に応じて、前記ローカルインデックステーブルにおいてインデックス化情報項目の数を保存するステップと、前記グローバルテーブルをフラッシュするステップと、前記保存した数から始まるインデックスを使用して前記ローカルインデックステーブルにおいて新しい情報項目をインデックス化するステップとを更に備えることを特徴とする請求項19に記載の符号化方法。
  33. 前記判定するステップ及び前記連結するステップ及び前記バイナリ圧縮するステップを使用して情報項目の前記初期リストの第1の符号化、又は、前記項目リテラル値のシリアル化バイナリ表現のバイナリ圧縮のみを使用する情報項目の前記初期リストの第2の符号化のどちらかを選択するステップを更に備え、
    前記第1の符号化の前記バイナリ圧縮のために使用されたスライディングバイナリウィンドウは、前記第2の符号化の前記バイナリ圧縮のために使用されたスライディングバイナリウィンドウより小さいことを特徴とする請求項1に記載の符号化方法。
  34. 前記リテラル値の前記シリアル化バイナリ表現は、前記初期リストでのそれらの相対順序に従って前記値を維持することを特徴とする請求項1に記載の符号化方法。
  35. 前記ビットストリームは、前記初期リスト内に前記情報項目の前記順序を格納する追加情報を含むことを特徴とする請求項1に記載の符号化方法。
  36. 前記メッセージは情報の項目の第2の初期リストを含み、
    前記符号化方法は、前記第2の初期リストの前記情報項目のリテラル値のシリアル化バイナリ表現を提供するステップと、前記第1のグループ及び前記第2のグループから結果として得られた前記情報項目の前記符号化ビットストリームとそれを連結するステップとを備えることを特徴とする請求項1に記載の符号化方法。
  37. 前記第2の初期リストに対する前記シリアル化バイナリ表現は、前記結果として得られるビットストリームにおいて前記符号化ビットストリームに先行することを特徴とする請求項36に記載の符号化方法。
  38. 符号化メッセージの復号化方法であって、
    第2の部分と連結された第1の部分を含む符号化データをビットストリームから取得するステップと、
    前記第1の部分を復号化して、ローカルインデックステーブルにおいて既にインデックス化されている情報項目と関連付けられたインデックスの第1のグループを取得するステップと、
    前記第2の部分をバイナリ伸張して、前記ローカルインデックステーブルにおいてまだインデックス化されていない情報項目に対応するリテラル値の第2のグループのシリアル化バイナリ表現を取得するステップと、
    前記第1のグループの前記インデックスによりインデックス化された前記情報項目及び前記第2のグループから文字通り復号化された前記情報項目から構成された復号化リストを提供するステップと、
    を備えることを特徴とする方法。
  39. 前記ローカルインデックステーブルにおいてまだインデックス化されていない前記情報項目の少なくとも1つは、前記ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで復号化され、
    前記第2のグループにおける対応するリテラル値は、まだインデックス化されていない前記情報により取られた値と参照として既にインデックス化及び使用されている前記情報項目により取られた値との差分を示すことを特徴とする請求項38に記載の復号化方法。
  40. まだインデックス化されていない前記情報項目に対応する前記シリアル化バイナリ表現のバイナリサブパートは、まだインデックス化されていない前記情報項目の前記リテラル値に加えて、参照として既にインデックス化及び使用されている前記情報項目のインデックスを含むことを特徴とする請求項39に記載の復号化方法。
  41. 既にインデックス化されている前記情報項目を参照することで復号化されると、前記ローカルインデックステーブルにおいて既にインデックス化されている前記情報項目を、まだインデックス化されていない前記情報項目で置き換えるステップを備えることを特徴とする請求項39又は40に記載の復号化方法。
  42. まだインデックス化されていない前記情報項目の1つに対応する前記シリアル化バイナリ表現のバイナリサブパートは、まだインデックス化されていない前記情報項目の前記リテラル値に加えて、まだインデックス化されていない前記情報項目が前記ローカルインデックステーブルにおいて既にインデックス化されている情報項目を参照することで復号化されるか否かを規定する第1の1ビットフラグと、まだインデックス化されていない前記情報項目が更なるインデックス化のために前記ローカルインデックステーブルに追加されなければならないか否かを規定する第2のバイナリインデックスフラグとを含むことを特徴とする請求項38に記載の復号化方法。
  43. 前記第2のバイナリフラグは、まだインデックス化されていない前記情報項目が、新しいエントリとして又は参照として既にインデックス化及び使用されている前記情報項目の置き換えにより前記ローカルインデックステーブルに追加されなければならないかを規定するためのビットを含むことを特徴とする請求項42に記載の復号化方法。
  44. 前記バイナリサブパートは、まだインデックス化されていない前記情報項目により取られた値と参照として既にインデックス化及び使用されている前記情報項目により取られた値との間の共通部分の長さを規定するためのバイナリフィールドを含むことを特徴とする請求項40又は43記載の復号化方法。
  45. 前記バイナリサブパートは、項目名テーブルにおいてまだインデックス化されていない前記情報項目の名前に対応するインデックスを規定するためのバイナリフィールドを含むことを特徴とする請求項42に記載の復号化方法。
  46. 前記ビットストリームから取得された前記符号化データは、前記第1の部分及び前記第2の部分と連結された第3の部分を含み、
    前記第3の部分は、追加リストの情報項目のリテラル値のシリアル化バイナリ表現であることを特徴とする請求項38に記載の復号化方法。
  47. 前記第3の部分は、前記ビットストリームにおいて前記第1の部分及び前記第2の部分に先行することを特徴とする請求項46に記載の復号化方法。
  48. 複数の接続を介して送出することになる情報の項目のリストを含むメッセージを符号化する方法であって、
    前記メッセージが属する前記接続専用のローカルインデックステーブルを使用してメッセージの情報項目の前記リストを符号化するステップを備え、
    グローバルテーブルは、前記接続の間で共有され、情報の項目を含み、各接続の前記ローカルインデックステーブルは、インデックスを前記共有グローバルテーブルのエントリに対する参照と関連付けることを特徴とする符号化方法。
  49. 複数の接続を介して受信された情報の項目の符号化リストを含む符号化メッセージを復号化する方法であって、
    前記符号化メッセージが属する前記接続専用のローカルインデックステーブルを使用して符号化メッセージの情報項目の前記符号化リストを復号化するステップを備え、
    グローバルテーブルは、前記全ての接続により共有され、情報の項目を含み、各接続の前記ローカルインデックステーブルは、インデックスを前記共有グローバルテーブルのエントリに対する参照と関連付けることを特徴とする復号化方法。
  50. 情報の項目の初期リストを含むメッセージをビットストリームに符号化する符号化デバイスであって、
    ローカルインデックステーブルにおいて既にインデックス化されている前記初期リストの情報項目と関連付けられたインデックスをグループ化する第1のグループ及び前記ローカルインデックステーブルにおいてまだインデックス化されていない前記初期リストの他の情報項目のリテラル値の第2のグループを判定する判定手段と、
    前記第1のグループの前記インデックスを符号化する符号器と、
    前記第2のグループの前記リテラル値の少なくともシリアル化バイナリ表現をバイナリ圧縮する圧縮器と、
    前記第1のグループ及び前記第2のグループを共に連結して前記情報項目の符号化ビットストリームを取得する連結モジュールと、
    を備えることを特徴とする符号化デバイス。
  51. 符号化メッセージを復号化する復号化デバイスであって、
    第2の部分と連結された第1の部分を含む符号化データをビットストリームから取得する取得手段と、
    前記第1の部分を復号化して、ローカルインデックステーブルにおいて既にインデックス化されている情報項目と関連付けられたインデックスの第1のグループを取得する復号器と、
    前記第2の部分をバイナリ伸張して、前記ローカルインデックステーブルにおいてまだインデックス化されていない情報項目に対応するリテラル値の第2のグループのシリアル化バイナリ表現を取得する伸張器と、
    前記第1のグループの前記インデックスによりインデックス化された前記情報項目及び前記第2のグループから文字通り復号化された前記情報項目から構成された復号化リストを提供する出力部と、
    を備えることを特徴とする復号化デバイス。
  52. 複数の接続を介して送出することになる情報の項目のリストを含むメッセージを符号化する符号化デバイスであって、
    前記接続の間で共有され且つ情報の項目を含むグローバルテーブルと、
    各々がインデックスを前記共有グローバルテーブルのエントリに対する参照と関連付ける前記複数の接続に対応する複数のローカルインデックステーブルと、
    メッセージが属する前記接続専用の前記ローカルインデックステーブルを使用して前記メッセージの情報項目の前記リストを符号化する符号器と、
    を備えることを特徴とする符号化デバイス。
  53. 複数の接続を介して受信された情報の項目の符号化リストを含む符号化メッセージを復号化する復号化デバイスであって、
    前記接続の間で共有され且つ情報の項目を含むグローバルテーブルと、
    各々がインデックスを前記共有グローバルテーブルのエントリに対する参照と関連付ける前記複数の接続に対応する複数のローカルインデックステーブルと、
    符号化メッセージが属する前記接続専用の前記ローカルインデックステーブルを使用して前記符号化メッセージの情報項目の前記符号化リストを復号化する復号器と、
    を備えることを特徴とする復号化デバイス。
  54. 装置のマイクロプロセッサ又はコンピュータシステムにより実行された時に、請求項1乃至49のいずれか1項に記載の前記ステップを前記装置に実行させるプログラムを格納することを特徴とする非一時的なコンピュータ可読媒体。
  55. 添付図面の図7;図9;図7及び9;図7及び11;図7及び12;図7,9及び11;図7、9及び12にて示され、実質的に記述された符号化の方法。
  56. 添付図面の図8;図10;図8及び10;図8及び11;図8及び12;図8,10及び11;図8、10及び12に示され、実質的に記述された復号化の方法。
JP2014540413A 2011-12-02 2012-11-05 メッセージを生成及び復号化する方法及びデバイス Active JP6021930B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IBPCT/IB2011/055441 2011-12-02
PCT/IB2011/055441 WO2013079999A1 (en) 2011-12-02 2011-12-02 Methods and devices for encoding and decoding messages
PCT/EP2012/071863 WO2013079277A1 (en) 2011-12-02 2012-11-05 Methods and devices for encoding and decoding messages

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2016158089A Division JP6169233B2 (ja) 2011-12-02 2016-08-10 通信装置及びその制御方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2015509293A true JP2015509293A (ja) 2015-03-26
JP6021930B2 JP6021930B2 (ja) 2016-11-09

Family

ID=47222035

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2014540413A Active JP6021930B2 (ja) 2011-12-02 2012-11-05 メッセージを生成及び復号化する方法及びデバイス
JP2016158089A Active JP6169233B2 (ja) 2011-12-02 2016-08-10 通信装置及びその制御方法及びプログラム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2016158089A Active JP6169233B2 (ja) 2011-12-02 2016-08-10 通信装置及びその制御方法及びプログラム

Country Status (4)

Country Link
US (2) US10051090B2 (ja)
EP (1) EP2786495B1 (ja)
JP (2) JP6021930B2 (ja)
WO (2) WO2013079999A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015103085A (ja) * 2013-11-26 2015-06-04 キヤノン株式会社 通信装置およびその制御方法

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301015A (zh) * 2011-12-20 2021-08-24 华为技术有限公司 网际协议头置换映射关系的获取方法及网络节点
US20140149605A1 (en) * 2012-11-26 2014-05-29 Saravana Annamalaisami Systems and methods for dictionary based compression
WO2014162250A2 (en) * 2013-04-04 2014-10-09 Pradeep Varma Method for enabling independent compilation of program and a system therefor
GB2516641B (en) * 2013-07-26 2015-12-16 Canon Kk Method and server device for exchanging information items with a plurality of client entities
JP2015230712A (ja) * 2014-06-06 2015-12-21 キヤノン株式会社 通信装置、通信方法、通信システム
JP6363897B2 (ja) * 2014-07-10 2018-07-25 キヤノン株式会社 通信装置および通信方法、ならびに通信システム
US9384226B1 (en) * 2015-01-30 2016-07-05 Dropbox, Inc. Personal content item searching system and method
US10754859B2 (en) * 2016-10-28 2020-08-25 Microsoft Technology Licensing, Llc Encoding edges in graph databases
CN109117288B (zh) * 2018-08-15 2022-04-12 无锡江南计算技术研究所 一种低延迟旁路的消息优化方法
US11595502B2 (en) * 2020-10-15 2023-02-28 Pensando Systems Inc. Methods and systems for layer 7 hardware assist and CPU task offloads
CN118677573B (zh) * 2024-08-21 2024-10-29 湖北中科能能源技术有限公司 一种发电站远程监测管理方法及系统

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05181641A (ja) * 1991-12-27 1993-07-23 Fujitsu Ltd データ圧縮・復元装置
JPH11168390A (ja) * 1997-12-03 1999-06-22 Fujitsu Ltd データ圧縮装置及びデータ復元装置,データ圧縮方法及びデータ復元方法,データ圧縮/復元用辞書作成装置並びにデータ圧縮プログラム又はデータ復元プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2002163248A (ja) * 2000-11-24 2002-06-07 Fujitsu Ltd 構造化文書圧縮装置および構造化文書復元装置並びに構造化文書処理システム
JP2002197001A (ja) * 2000-12-27 2002-07-12 Fujitsu Ltd クライアント・サーバ型のシステムにおける情報の通信方法
JP2004514366A (ja) * 2000-11-16 2004-05-13 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 静的な情報知識を用いたバイナリー圧縮方法
JP2005284903A (ja) * 2004-03-30 2005-10-13 Matsushita Electric Ind Co Ltd 文書符号化装置、文書復号化装置、文書符号化方法及び文書復号化方法
JP2006100973A (ja) * 2004-09-28 2006-04-13 Nomura Research Institute Ltd データ圧縮装置、及びデータ伸長装置
JP2009065674A (ja) * 2007-09-07 2009-03-26 Samsung Electronics Co Ltd データ圧縮装置および方法
JP2010258787A (ja) * 2009-04-24 2010-11-11 Mitsubishi Electric Corp シグナリング圧縮装置、シグナリング伸長装置およびシグナリング圧縮伸長装置
WO2011075738A1 (en) * 2009-12-18 2011-06-23 Qualcomm Incorporated Http optimization, multi-homing, mobility and priority

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6069999A (en) * 1991-04-18 2000-05-30 Microsoft Corporation Method for compressing and decompressing font data
JPH0869400A (ja) * 1994-08-30 1996-03-12 Sony Corp 圧縮データ記録方法
US6049545A (en) * 1997-10-03 2000-04-11 Alcatel Usa Sourcing, L.P. System and method for message communications in a distributed telecommunications switch
JP2001086001A (ja) * 1999-09-14 2001-03-30 Mega Chips Corp データ伝達システム
JP3366303B2 (ja) * 1999-11-24 2003-01-14 エヌイーシーインフロンティア株式会社 バーコードリーダおよびその誤読検出方法。
DE102004034004A1 (de) * 2004-07-14 2006-02-09 Siemens Ag Verfahren zum Codieren eines XML-Dokuments, sowie Verfahren zum Decodieren, Verfahren zum Codieren und Decodieren, Codiervorrichtung, Decodiervorrichtung und Vorrichtung zum Codieren und Decodieren
JP4775846B2 (ja) * 2006-03-20 2011-09-21 株式会社日立製作所 物理リンクの割当てを制御するコンピュータシステム及び方法
WO2008001422A1 (fr) * 2006-06-26 2008-01-03 Panasonic Corporation Système de communication radio et dispositif de communication radio
US7810026B1 (en) * 2006-09-29 2010-10-05 Amazon Technologies, Inc. Optimizing typographical content for transmission and display
US20080155016A1 (en) * 2006-12-22 2008-06-26 Tsai Wei K Content procurement architecture
KR101454167B1 (ko) * 2007-09-07 2014-10-27 삼성전자주식회사 데이터 압축 및 복원 장치 및 방법
US20100274913A1 (en) * 2008-01-18 2010-10-28 Takeshi Ando Wireless access system, wireless access method and access point apparatus
FR2933793B1 (fr) * 2008-07-11 2013-07-05 Canon Kk Procedes de codage et de decodage, par referencement, de valeurs dans un document structure, et systemes associes.
JP5131239B2 (ja) * 2009-03-31 2013-01-30 富士通株式会社 Ipアドレス割当制御プログラム、ipアドレス割当制御装置およびipアドレス割当制御方法
US8589970B2 (en) * 2009-05-14 2013-11-19 Hitachi Consumer Electronics Co., Ltd. Content transmitter and receiver apparatus and content transmitting and receiving method
WO2011067769A1 (en) * 2009-12-03 2011-06-09 Infogin Ltd. Shared dictionary compression over http proxy
WO2011152052A1 (ja) * 2010-06-02 2011-12-08 パナソニック株式会社 通信制御装置およびパケットフィルタリング方法
US9203684B1 (en) * 2010-07-14 2015-12-01 Google Inc. Reduction of web page load time using HTTP header compression
JP5545141B2 (ja) * 2010-09-09 2014-07-09 富士ゼロックス株式会社 データ中継システム、中継装置、およびプログラム
US20120147971A1 (en) * 2010-12-08 2012-06-14 Qualcomm Incorporated Codeword adaptation for variable length coding
US8832374B1 (en) * 2011-11-14 2014-09-09 Union Supply Company, Inc. Providing electronic content to residents of controlled-environment facilities
WO2013138179A1 (en) * 2012-03-13 2013-09-19 Google Inc. System and method for providing a binary representation of a web page

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05181641A (ja) * 1991-12-27 1993-07-23 Fujitsu Ltd データ圧縮・復元装置
JPH11168390A (ja) * 1997-12-03 1999-06-22 Fujitsu Ltd データ圧縮装置及びデータ復元装置,データ圧縮方法及びデータ復元方法,データ圧縮/復元用辞書作成装置並びにデータ圧縮プログラム又はデータ復元プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2004514366A (ja) * 2000-11-16 2004-05-13 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 静的な情報知識を用いたバイナリー圧縮方法
JP2002163248A (ja) * 2000-11-24 2002-06-07 Fujitsu Ltd 構造化文書圧縮装置および構造化文書復元装置並びに構造化文書処理システム
JP2002197001A (ja) * 2000-12-27 2002-07-12 Fujitsu Ltd クライアント・サーバ型のシステムにおける情報の通信方法
JP2005284903A (ja) * 2004-03-30 2005-10-13 Matsushita Electric Ind Co Ltd 文書符号化装置、文書復号化装置、文書符号化方法及び文書復号化方法
JP2006100973A (ja) * 2004-09-28 2006-04-13 Nomura Research Institute Ltd データ圧縮装置、及びデータ伸長装置
JP2009065674A (ja) * 2007-09-07 2009-03-26 Samsung Electronics Co Ltd データ圧縮装置および方法
JP2010258787A (ja) * 2009-04-24 2010-11-11 Mitsubishi Electric Corp シグナリング圧縮装置、シグナリング伸長装置およびシグナリング圧縮伸長装置
WO2011075738A1 (en) * 2009-12-18 2011-06-23 Qualcomm Incorporated Http optimization, multi-homing, mobility and priority

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
H.RUELLAN, J.FUJISAWA, R.BELLESSORT, Y.FABLET: "Header Diff:A compact HTTP header representation for HTTP/2.0", [ONLINE], JPN7015003384, February 2013 (2013-02-01), ISSN: 0003393831 *
R.PEON, H.RUELLAN: "HTTP Header Compression draft-ietf-httpbis-header-compression-00", [ONLINE], JPN7015003385, 25 June 2013 (2013-06-25), ISSN: 0003393832 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015103085A (ja) * 2013-11-26 2015-06-04 キヤノン株式会社 通信装置およびその制御方法

Also Published As

Publication number Publication date
US20180191871A1 (en) 2018-07-05
EP2786495A1 (en) 2014-10-08
US11122150B2 (en) 2021-09-14
JP6021930B2 (ja) 2016-11-09
JP2016201847A (ja) 2016-12-01
EP2786495B1 (en) 2020-01-08
JP6169233B2 (ja) 2017-07-26
US20140355627A1 (en) 2014-12-04
WO2013079999A1 (en) 2013-06-06
WO2013079277A1 (en) 2013-06-06
US10051090B2 (en) 2018-08-14

Similar Documents

Publication Publication Date Title
JP6169233B2 (ja) 通信装置及びその制御方法及びプログラム
US8698657B2 (en) Methods and systems for compressing and decompressing data
US9680500B2 (en) Staged data compression, including block level long range compression, for data streams in a communications system
US9471646B2 (en) Method and server device for exchanging information items with a plurality of client entities
US9363309B2 (en) Systems and methods for compressing packet data by predicting subsequent data
US10846218B2 (en) Methods, devices and systems for compressing and decompressing data
US8572218B2 (en) Transport data compression based on an encoding dictionary patch
AU721734B2 (en) A lempel-ziv data compression technique utilizing a dictionary pre-filled with frequent letter combinations, words and/or phrases
US7051126B1 (en) Hardware accelerated compression
JP4533454B2 (ja) 階層セグメント表現を含む記憶および伝送時のデータ圧縮に関するコンテント・ベースのセグメント化方式
US20150006475A1 (en) Data deduplication in a file system
US20130018932A1 (en) System and method for long range and short range data compression
CN108702160B (zh) 用于压缩和解压缩数据的方法、设备和系统
JP2009531976A (ja) セットアソシアティブキャッシュマッピング技術に基づく高速データ圧縮
US10735025B2 (en) Use of data prefixes to increase compression ratios
US7764202B2 (en) Lossless data compression with separated index values and literal values in output stream
US10897270B2 (en) Dynamic dictionary-based data symbol encoding
EP2530843A2 (en) Dictionary based data compression
EP2779467B1 (en) Staged data compression, including block-level long-range compression, for data streams in a communications system
GB2510198A (en) Method and device for encoding a header in a message using an indexing table
GB2510174A (en) Encoding message headers using an in-memory indexing table
US20100127901A1 (en) Data structure management for lossless data compression

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151204

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160627

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160810

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161004

R151 Written notification of patent or utility model registration

Ref document number: 6021930

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151