JP6300497B2

JP6300497B2 - 通信装置およびその制御方法

Info

Publication number: JP6300497B2
Application number: JP2013244121A
Authority: JP
Inventors: 睦池田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-11-26
Filing date: 2013-11-26
Publication date: 2018-03-28
Anticipated expiration: 2033-11-26
Also published as: JP2015103085A

Description

本発明は、通信データのヘッダ圧縮するための技術に関する。

一般的に使われているＨＴＴＰのバージョンは１．１であり、ＨＴＴＰ／１．１やＨＴＴＰ１．１と表記される。ＨＴＴＰ１．１は広く普及した通信プロトコルであるが、既知の問題がある。それは、セッションの中でリクエストを出してレスポンスを受け取るまで、次のリクエストを出すことが出来ない点である。また、ＨＴＴＰのヘッダは何度も同じ内容をくり返しているため、クライアントとサーバ間で冗長なデータのやりとりが多い点もある。

そこで、ＨＴＴＰ１．１の問題点を解決するために、ＨＴＴＰの次期バージョンであるＨＴＴＰ２．０の策定が開始された。ＨＴＴＰ２．０では、クライアントとサーバ間でヘッダを送受信する際の冗長なデータを低減するために、ヘッダのデータを圧縮する機能が盛り込まれている。

ヘッダを圧縮する手法として、クライアントとサーバ間のデータのやりとりには差分方式が提案されている（非特許文献１）。差分方式とは、クライアントとサーバ間でデータのやりとりした後、次のやりとりには、それまでにやりとりしたデータと異なる部分だけをやりとりする方式である。さらに、非特許文献１は、ヘッダリストを参照して、ヘッダ情報を別の記号や符号の列に置き換えることで、クライアントとサーバ間でやりとりする情報量を削減している。

ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｒｐｅｏｎ−ｈｔｔｐｂｉｓ−ｈｅａｄｅｒ−ｃｏｍｐｒｅｓｓｉｏｎ−０３

非特許文献１は、ヘッダリストを参照して、ヘッダ情報を記号列に置き換えて、クライアントとサーバ間でやりとりするが、このヘッダリストはセッション毎に管理される。つまり、ある装置で、同時に確立されるセッションが増えると、セッション数分のヘッダテーブルを保持しなければならず、結果として、メモリ使用量が増えてしまうという課題があった。

本発明では、このような事情を鑑みてなされたものであり、ヘッダリストを用いてヘッダ圧縮するプロトコルを使用する際の、セッション増加に伴うメモリ使用の低減を可能とすることを目的とする。

上記課題を解決するために、本発明の通信装置は、他の通信装置との間で通信のためのセッションを確立する確立手段と、前記確立手段により新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理のために用いられるヘッダリストを、複数のセッションで共通して用いられるヘッダリストとするか否かを決定する決定手段と、前記確立手段により前記新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理を、前記決定手段による決定に応じて、前記複数のセッションで共通して用いられるヘッダリストを用いて行う伸張手段とを有することを特徴とする。

本発明によれば、ヘッダリストを用いてヘッダ圧縮するプロトコルを使用する際の、セッション増加に伴うメモリ使用の低減を可能となる。

通信装置１００のブロック図ＨｅａｄｅｒＤｉｆｆを用いたヘッダ圧縮を説明するための図通信装置１００のデータ受信時のフローチャートＳ３０２の詳細フローチャートＳ３０６の詳細フローチャートＳ３０８の詳細フローチャート通信装置１００のデータ送信時のフローチャートヘッダリストの例テーブルの例本実施形態を説明するための概念図

以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施例の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一な構成、同一なステップについては、同じ符号を付して説明する。

＜第１の実施形態＞
本実施形態では、ユーザがＷｅｂブラウザを備えたクライアント端末上において、複数のＷｅｂページを同時に閲覧する事例を考える。ここでは、サーバとクライアント端末はどちらも非特許文献１に記載のＨｅａｄｅｒＤｉｆｆ仕様を元に、ヘッダ情報を圧縮することとする。ＨｅａｄｅｒＤｉｆｆは、クライアントとサーバ間のデータのやりとりには差分方式が用いられる。差分方式は、クライアントとサーバ間でデータのやりとりした後、次のやりとりには、それまでにやりとりしたデータと異なる部分だけをやりとりする。さらに、ヘッダテーブル（ヘッダリスト）を用いて、ヘッダ情報を別の記号や符号の列（インデックス番号）に置き換えて、置き換えられた符号列（インデックス番号）を、送信側に送信する。送信側では、受信側と同じルールで、ヘッダテーブルを作成することで、ヘッダを復号する。同じセッション内で、送受信したヘッダ情報については、インデックス番号を送受信し、かつ、同じセッション内で、送受信していないヘッダ情報については、ヘッダ情報を送る。

図２は、ＨｅａｄｅｒＤｉｆｆを用いたヘッダ圧縮を説明するための図である。

図２（ａ）は、セッションが確立された後、最初に、クライアントから、サーバに、「ＡＡＡ」というヘッダ情報が送信される例を示している。その際、クライアントは、図２（ｃ）のように、ヘッダリストのインデックス番号「１」に、「ＡＡＡ」という値を記録する。尚、ヘッダリストのインデックス番号が、例えば、３７まで使用されていた場合は、ヘッダリストのインデックス番号「３８」に、「ＡＡＡ」という値を記録する。また、ここでは説明のために、「ＡＡＡ」という情報を用いたが、ＨｅａｄｅｒＤｉｆｆでは、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅである。

図２（ｂ）は、サーバが、クライアントから、「ＡＡＡ」というヘッダ情報が受信した例を示している。サーバは、受信した後、クライアントの処理と同様に、図２（ｃ）のヘッダリストを生成する。

図２（ｄ）は、クライアントが、サーバに、再度、「ＡＡＡ」というヘッダ情報を送信する例である。クライアントは、図２（ｃ）のヘッダリストを参照して、「ＡＡＡ」というヘッダ情報があるかを確認する。ヘッダリストに「ＡＡＡ」というヘッダ情報があれば、それに対応するインデックス番号「１」を、サーバに送信する。つまり、「ＡＡＡ」というヘッダ情報を、再度送信するのではなく、インデックス番号「１」を送信することで、情報量を削減している。

図２（ｅ）は、サーバが、クライアントから、インデックス番号「１」を受信した例を示している。サーバは、サーバが保持している図２（ｃ）のヘッダリストから、インデックス番号「１」に対応する「ＡＡＡ」を取得する。

図２では、クライアントからサーバにデータを送信する例を説明したが、サーバからクライアントにデータを送信する場合も同様に処理される。その際、クライアントは、送信用のヘッダリストと受信用のヘッダリストを生成する。

図１（ａ）は、本実施形態における通信装置１００のブロック図である。図１において、１０１は通信装置１００全体を制御するＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ（ＣＰＵ）である。１０２は変更を必要としないプログラムやパラメータを格納するＲｅａｄＯｎｌｙＭｅｍｏｒｙ（ＲＯＭ）である。１０３は外部装置などから供給されるプログラムやデータを一時記憶するＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ（ＲＡＭ）である。１０４は保持するデータや供給されたデータを表示するためのインタフェースである。１０５は１０１〜１０４の各ユニットを通信可能に接続するシステムバスである。ユーザからの操作を受けてデータを入力するマウスなどのポインティングデバイスやキーボードなどの入力デバイスとのインタフェース等があってもよい。また通信装置１００に固定して設置されたハードディスクやメモリカード等があってもよい。あるいは通信装置１００から着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔＤｉｓｋ（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む外部記憶装置等があってもよい。さらにインターネットなどのネットワーク回線に接続するためのネットワークインターフェイス等があってもよい。尚、本実施形態における通信装置１００は、サーバと通信を行うクライアント端末であるとする。

図１（ｂ）は、本実施形態における通信装置１００の機能ブロック図である。

セッション管理部２０１は、セッションの開始や終了を検知したり、開始されたセッション以外に、別のセッションが確立しているかを判定する。データ送受信部２０２は、データの受信や送信を行う。また、受信したデータからヘッダを抽出したり、送信するためのデータを生成する。ヘッダ復号・符号化部２０３は、ヘッダリストを用いて、受信したヘッダの復号を行ったり、送信するヘッダの符号化を行う。ヘッダリスト管理部２０４は、ヘッダリスト保持部２０６に保持されているヘッダリストの取得、更新、破棄などを行う。ヘッダリスト保持部２０６には、共通のヘッダリストや、セッション用のヘッダリストが保持される。

テーブル管理部２０５は、テーブル保持部２０７に保持されているテーブルの更新を行う。テーブル保持部２０７に保持されているテーブルは、確立しているセッションを特定するセッション情報、そのセッションで使用しているヘッダリストを特定するヘッダリスト情報、ヘッダリストで使用しているｉｎｄｅｘ番号（インデックス番号）が記録される。セッション情報は、例えば、セッションを特定するセッション名である。ヘッダリスト情報は、例えば、共通のヘッダリストを使用しているのか、セッション用のヘッダリストを使用しているのかを示し、ヘッダリストを特定するためのヘッダリスト名である。ｉｎｄｅｘ番号（インデックス番号）は、使用しているヘッダリストで、そのセッションで、どのｉｎｄｅｘ番号まで使用したかを示す情報である。

図３は、通信装置１００のデータ受信時のフローチャートである。

Ｓ３０１で、セッション管理部２０１が、セッション開始を検知する。Ｓ３０２で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６から、このセッションで使用するヘッダリストを取得する。Ｓ３０３で、データ送受信部２０２が、通信相手（サーバ）からデータを受信する。Ｓ３０４で、データ送受信部２０２が、受信したデータから、ヘッダを抽出する。Ｓ３０５で、抽出したヘッダを、ヘッダ復号・符号化部２０３が、Ｓ３０２で取得したヘッダリストを用いて、復号する。Ｓ３０６で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６に保持されている、このセッションで使用しているヘッダリストを更新する。Ｓ３０７で、セッション管理部２０１が、セッション終了を検知する。Ｓ３０８で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６に保持されている、このセッションに関連するヘッダリストを破棄する。

図４（ａ）は、Ｓ３０２の詳細フローチャートである。

Ｓ４０１で、セッション管理部２０１が、Ｓ３０１で開始したセッション以外に、別のセッションが確立されているかを判定する。Ｓ４０１でＹｅｓの場合は、Ｓ４０２に進み、Ｓ４０１でＮｏの場合は、Ｓ４０４に進む。Ｓ４０２で、ヘッダリスト管理部２０４が、新規に、ヘッダリストを取得する。Ｓ４０２で取得するヘッダリストは、セッションによらず、共通に決められている部分からなるヘッダリストを取得する。例えば、ＨｅａｄｅｒＤｉｆｆは、ヘッダリストのｉｎｄｅｘ番号が０から３７までは予め決められている。これは、セッションによらず、よく使用される部分が予め決めておくことで、ヘッダリストを作る手間を軽減している。ＨｅａｄｅｒＤｉｆｆの場合は、Ｓ４０２で、ヘッダリストのｉｎｄｅｘ番号が０から３７は共通部分であるヘッダリストを取得する。ヘッダリストは、予め装置内（例えば、ヘッダリスト保持部２０６）に保持しておいてもよいし、別の装置から取得してもよい。尚、セッションによらず、予め決められている、共通に用いるヘッダリストがないプロトコルを用いる場合は、Ｓ４０２において、ヘッダリストを取得する必要はない。また、Ｓ４０２で新規に取得されたヘッダリストは、共通のヘッダリストであると設定する。図８（ａ）は、Ｓ４０２が取得したヘッダリストの例である。

Ｓ４０３で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッション名とヘッダリスト名とヘッダリストの使用番号を記録する。図９（ａ）は、テーブルの例である。図９（ａ）は、第１セッションは、共通のヘッダリストを使用し、ヘッダリストのｉｎｄｅｘ番号が３７まで使用されていることを示す。

Ｓ４０４で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６から、別のセッションで生成済みの共通ヘッダリストを取得する。図８（ｂ）は、Ｓ４０４が取得したヘッダリストの例である。生成済みの共通ヘッダリストには、別のセッションで、ヘッダリストのｉｎｄｅｘ番号が３８に、ｈｅａｄｅｒｎａｍｅに、「：ｐａｔｈ」、ｈｅａｄｅｒｖａｌｕｅに、「／ｅｘａｍｐｌｅ／ｉｎｄｅｘ．ｈｔｍｌ」が追加されているリストである。

Ｓ４０５で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルには、セッション名とヘッダリスト名とヘッダリストの使用番号を記録する。図９（ｂ）は、テーブルの例である。予め、第２セッションと第３セッションの情報が記録されている場合、Ｓ４０５で、テーブルに、第１セッションを特定する情報、共通のヘッダリストを使用していることを示す情報、ヘッダリストのｉｎｄｅｘ番号が３７まで使用されていること示す情報を追加する。

図５は、Ｓ３０６の詳細フローチャートである。

Ｓ５００で、データ送受信部２０２が、受信したデータのヘッダを用いて、ヘッダリストに追加すべきデータがあるかどうかを判定する。受信したデータのヘッダに、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅがある場合は、追加すべきデータがあると判定する。受信したデータのヘッダに、ｉｎｄｅｘ番号だけの場合は、追加すべきデータがないと判定してもよい。Ｓ５００でＹｅｓの場合は、Ｓ５０１に進み、Ｓ５００でＮｏの場合は、処理を終了する。

Ｓ５０１で、データ送受信部２０２が、受信したデータのヘッダから、追加すべきデータを取得する。具体的には、ヘッダから、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅを取得する。Ｓ５０２で、テーブル管理部２０５が、テーブルを参照して、このセッションで使用しているヘッダリストが、共通のヘッダリストかどうかを判定する。Ｓ５０２でＹｅｓの場合は、Ｓ５０５に進み、Ｓ５０２でＮｏの場合は、Ｓ５０３に進む。

Ｓ５０３で、ヘッダリスト管理部２０４が、セッション用のヘッダリストに、Ｓ５０１で取得した追加すべきデータを追加する。具体的には、ｉｎｄｅｘ番号、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅを、ヘッダリストに追加する。ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅを追加する。Ｓ５０４で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。具体的には、Ｓ５０３において、ｉｎｄｅｘ番号が３８にヘッダリストを追加した場合は、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号を３８に書き換える。

Ｓ５０５で、テーブル管理部２０５が、共通のヘッダリストにおける最後のｉｎｄｅｘ番号と、テーブルに記録されているｉｎｄｅｘ番号が同じかどうかを判定する。具体的には、ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、３７と、テーブルに記録されているｉｎｄｅｘ番号が同じかどうかを判定する。Ｓ５０５でＹｅｓの場合は、Ｓ５０６に進み、Ｓ５０５でＮｏの場合は、Ｓ５０８へ進む。

Ｓ５０６で、ヘッダリスト管理部２０４が、共通のヘッダリストに、Ｓ５０１で取得した追加すべきデータを追加する。具体的には、ｉｎｄｅｘ番号、ヘッダにあるｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅを、ヘッダリストに追加する。ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅを追加する。

Ｓ５０７で、テーブル管理部２０５が、対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。具体的には、Ｓ５０６において、ｉｎｄｅｘ番号が３８にヘッダリストを追加した場合は、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号を３８に書き換える。

Ｓ５０８で、テーブル管理部２０５が、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号の次のｉｎｄｅｘ番号に対応する、共通のヘッダリストのｉｎｄｅｘ番号に、Ｓ５０１で取得した追加すべきデータが入っているかを判定する。例えば、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号が３７の場合を説明する。この場合、ヘッダリストのｉｎｄｅｘ番号３８のｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅのペアが、追加すべきデータであるｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅのペアと同じであるかを判定する。ｈｅａｄｅｒｎａｍｅとｈｅａｄｅｒｖａｌｕｅのペアと同じである必要があるので、ｈｅａｄｅｒｎａｍｅだけが同じ、あるいは、ｈｅａｄｅｒｖａｌｕｅだけが同じである場合は、Ｓ５０８の判定は、Ｎｏと判定される。Ｓ５０８でＹｅｓの場合は、Ｓ５１１に進み、Ｓ５０８でＮｏの場合は、Ｓ５０９へ進む。

Ｓ５０９で、ヘッダリスト管理部２０４が、セッション用のヘッダリストを生成する。セッション用のヘッダリストの生成は、共通のヘッダリストのうち、テーブルに記載されているｉｎｄｅｘ番号までのデータをコピーし、さらに、Ｓ５０１で取得した追加すべきデータを追加する。図８（ｃ）は、Ｓ５０９が生成したヘッダリストの例である。使用していたヘッダリストが図８（ｂ）のヘッダリストで、ｉｎｄｅｘ番号３８に、追加すべきデータが、ｈｅａｄｅｒｎａｍｅ「ｕｓｅｒ−ａｇｅｎｔ」、ｈｅａｄｅｒｖａｌｕｅ「ｕｓｅｒ−ａｇｅｎｔ」である場合、図８（ｃ）のヘッダリストを生成する。図８（ｂ）のヘッダリストのうち、ｉｎｄｅｘ番号３７までのデータをコピーし、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒｎａｍｅ「ｕｓｅｒ−ａｇｅｎｔ」、ｈｅａｄｅｒｖａｌｕｅ「ｕｓｅｒ−ａｇｅｎｔ」を追加する。

Ｓ５１０で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリスト名を、セッション用のヘッダテーブルを示す情報に変更し、使用しているヘッダリストのｉｎｄｅｘ番号を変更する。図９（ｃ）は、テーブルの例である。更新前のテーブルが、図９（ｂ）の場合で、Ｓ５０９で、第１セッション用のヘッダリストを生成した場合、図９（ｃ）のように、使用しているヘッダリストを、第１セッション用のヘッダリストを示す情報に変更する。

Ｓ５１１で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。

図６は、Ｓ３０８の詳細フローチャートである。Ｓ６０１で、テーブル管理部２０５が、セッション用のヘッダリストを使用しているかを判定する。Ｓ６０１で、Ｙｅｓの場合は、Ｓ６０２へ進み、Ｓ６０１でＮｏの場合は、Ｓ６０４へ進む。Ｓ６０２で、ヘッダリスト管理部２０４が、セッション用のヘッダリストを破棄する。Ｓ６０３で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッションを終了したセッション名と、セッション用のヘッダリストを用いていることを示す情報、ヘッダリストの使用番号を削除する。Ｓ６０４で、セッション管理部２０１が、別のセッションがあるかどうかを判定する。Ｓ６０４で、Ｙｅｓの場合は、処理を終了し、Ｓ６０４でＮｏの場合は、Ｓ６０５へ進む。Ｓ６０５で、共通のヘッダリストを破棄する。Ｓ６０６で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッションを終了したセッション名と、共通のヘッダリストを用いていることを示す情報、ヘッダリストの使用番号を削除する。

図７は、通信装置１００のデータ送信時のフローチャートである。Ｓ７０１、Ｓ７０２、Ｓ７０３以外は、図３で説明したステップと同じであるので、説明は省略する。Ｓ７０１で、ヘッダ復号・符号化部２０３が、Ｓ３０２で取得したヘッダリストを用いて、ヘッダ符号化を行う。Ｓ７０２で、データ送受信部２０２が、Ｓ７０１で符号化したヘッダを含めて、送信するデータを生成する。Ｓ７０３で、データ送受信部２０２が、Ｓ７０２で生成したデータを、通信相手（サーバ）に送る。

図１０（ｂ）は、本実施形態を適用した場合の概念図である。セッション１とセッション２では、共通のヘッダリストを用いており、セッション３では、セッション３用のヘッダリストを用いている。図１０（ａ）は、本実施形態を適用する前の概念図である。セッション１、セッション２、セッション３いずれも、セッション毎のヘッダリストを用いている。

＜変形例＞
変形例では、ヘッダリストが同じになる可能性のあるセッションについては、最初は、共通のヘッダリストを用いるが、ヘッダリストが同じにならない可能性のあるセッションについては、最初から、セッション用のヘッダリストを使う例である。

図４（ｂ）は、Ｓ３０２の詳細フローチャートである。Ｓ４０１〜Ｓ４０５は、図４（ａ）と同じであるので、説明は省略する。

Ｓ４０１でＹｅｓの場合は、Ｓ４０６に進み、Ｓ４０６では、セッション管理部２０１が、通信相手が同じセッションがあるかを判定する。具体的には、テーブル保持部２０７に保持しているテーブルを参照し、通信相手が同じであるセッションがあるか判定する。通信相手が同じセッションがある場合は、同じヘッダをやりとりする可能性が高いので、ヘッダリストが同じになる可能性が高い。Ｓ４０６でＹｅｓの場合は、Ｓ４０９に進み、Ｓ４０６でＮｏの場合は、Ｓ４０７に進む。

Ｓ４０７では、ヘッダリスト管理部２０４が、ヘッダリストを取得する。Ｓ４０７が取得するヘッダリストは、Ｓ４０２で取得するヘッダリストと同じであるが、取得したヘッダリストをセッション用のヘッダリストとして設定する。

Ｓ４０８では、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルには、セッション名と、通信相手、セッション用のヘッダリストを使用していること、ヘッダリストの使用番号を記録する。Ｓ４０９で、ヘッダリスト管理部２０４が、通信相手が同じセッションで用いられている生成済みの共通ヘッダリストを取得する。具体的には、通信相手が、サーバＡの場合は、サーバＡの共通ヘッダリストを取得する。

Ｓ４１０で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。セッション名と、通信相手、共通のヘッダリストを使用していること、ヘッダリストの使用番号を記録する。図９（ｄ）は、テーブルの例である。図９（ａ）〜（ｃ）などのテーブルと異なるのは、通信相手が記録されている点と、通信相手毎に共通のヘッダリストを用いる点である。

上記変形例のＳ４０６では、通信相手が同じかどうかで判定を行ったが、通信相手が同じかどうかでなく、ドメインが同じかで判定を行ってもよい。ドメインが同じ場合も、同じヘッダをやりとりする可能性が高いので、ヘッダリストが同じになる可能性が高い。

また、過去にセッション用のヘッダリストを作成したかの履歴と残しておき、Ｓ４０６の代わりに、通信相手が同じであるか、かつ、履歴を用いて、過去にセッション用のヘッダリストを作成しなかったかを判定してもよい。履歴を用いることで、通信相手が同じであっても、ヘッダリストが同じになる可能性が高い場合にのみ、共通ヘッダリストを用いることができる。

変形例によれば、ヘッダリストが同じになる可能性が高くない場合は、予めセッション用のヘッダリストを作成することで、後から、セッション用のヘッダリストを作成する必要がなくなる。また、図５におけるＳ５０５やＳ５０８の判定も不要になるので、処理負荷を軽減できる。

本実施形態では、通信装置１００がクライアント端末である例を説明したが、クライアント端末の代わりに、同様の処理をサーバで行ってもよい。サーバで行った場合は、サーバのメモリ使用が削減可能となる。

本実施形態では、ＨｅａｄｅｒＤｉｆｆ仕様をもとに実施する例を示したが、他の仕様、例えば、Ｄｅｌｔａ２などを用いてもよい。特に、クライアントとサーバ間で、差分方式を用いてデータのやりとりを行い、かつ、ヘッダリストを用いて、ヘッダ圧縮を行うプロトコルであれは適用可能である。

以上の実施形態によれば、ヘッダリストが共通できる場合においては、共通のヘッダリストも用いることで、メモリ使用量を低減することが可能である。

以上の実施形態によれば、クライアントとサーバ間の通信において、ＨＴＴＰ２．０プロトコルで複数セッション同時にヘッダ情報をやりとりする場合、通信装置のメモリ使用量を低減することが可能である。

＜その他の変形例＞
以上本発明にかかる実施形態を説明したが、先に説明したように、通信装置は、通常のパーソナルコンピュータ等の汎用情報処理装置であって、それ上で動作するコンピュータプログラムで実現できるものである。よって、本発明はコンピュータプログラムをその範疇とすることは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ読み取り可能な記憶媒体に格納されており、それをコンピュータの対応するドライブにセットしてシステムにコピーやインストール処理することで実行可能となる。よって、本発明は当然にそのようなコンピュータ可読記憶媒体をもその範疇とすることも明らかである。

Claims

他の通信装置との間で通信のためのセッションを確立する確立手段と、
前記確立手段により新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理のために用いられるヘッダリストを、複数のセッションで共通して用いられるヘッダリストとするか否かを決定する決定手段と、
前記確立手段により前記新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理を、前記決定手段による決定に応じて、前記複数のセッションで共通して用いられるヘッダリストを用いて行う伸張手段とを有することを特徴とする通信装置。
他のセッションが確立済みであるかを前記確立手段による新たなセッションの確立に応じて判定する判定手段を有し、
前記決定手段は、前記他のセッションが確立済みであると前記判定手段により判定された場合、前記新たなセッションと前記他のセッションとでヘッダリストを共通して用いて伸張処理を行うことを決定することを特徴とする請求項１に記載の通信装置。
前記決定手段は、前記他のセッションが確立済みでないと前記判定手段により判定された場合、前記新たなセッションのための新規のヘッダリストを用いて伸張処理を行うことを決定することを特徴とする請求項２に記載の通信装置。
前記確立手段により確立されたセッションに基づいて他の通信装置へ送信されるべきヘッダを、前記ヘッダリストを用いて圧縮する圧縮手段を有することを特徴とする請求項１乃至３のうち、何れか１項に記載の通信装置。
前記ヘッダリストは、前記確立手段により確立された１又は複数のセッションに基づく通信済みのヘッダのデータと、インデックスとを対応付けた情報であることを特徴とする請求項１乃至４のうち、何れか１項に記載の通信装置。
前記確立手段により確立されたセッションに基づいて受信したデータに基づいて、前記ヘッダリストにデータを追加すべきか判定する追加判定手段と、
前記追加判定手段による判定結果に従って前記ヘッダリストにデータを追加する追加手段とを有することを特徴とする請求項１乃至５のうち、何れか１項に記載の通信装置。
前記追加判定手段は、前記確立手段により確立されたセッションに基づいて受信したデータのヘッダにヘッダ名が含まれている場合、前記当該ヘッダに関するデータを前記ヘッダリストに追加すべきと判定することを特徴とする請求項６に記載の通信装置。
前記追加判定手段は、前記確立手段により確立されたセッションに基づいて受信したデータのヘッダが前記ヘッダリストに登録されていない場合、当該ヘッダに関するデータを追加すべきと判定することを特徴とする請求項６又は７に記載の通信装置。
前記確立手段により確立されたセッションが終了された場合、前記ヘッダリストを破棄する破棄手段を有することを特徴とする請求項１乃至８のうち、何れか１項に記載の通信装置。
他の通信装置との間で通信のためのセッションを確立する確立工程と、
前記確立工程により新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理のために用いられるヘッダリストを、複数のセッションで共通して用いられるヘッダリストとするか否かを決定する決定工程と、
前記確立工程により前記新たに確立されたセッションに基づいて受信される圧縮済みヘッダの伸張処理を、前記決定工程による決定に応じて、前記複数のセッションで共通して用いられるヘッダリストを用いて行う伸張工程と、
を有することを特徴とする通信装置の制御方法。
コンピュータを請求項１乃至９のうち、何れか１項に記載の通信装置の各手段として動作させるためのプログラム。