(57)【要約】【課題】  ヘッダリストを用いてヘッダ圧縮するプロトコルを使用する際の、セッション増加に伴うメモリ使用の低減を可能とすることを目的とする。【解決手段】  開始されたセッション以外に、別のセッションが確立されている場合、共通ヘッダリストを取得し、取得した共通ヘッダリストを用いて、受信したデータのヘッダの復号を行う、あるいは、送信するデータのヘッダの符号化を行う。【選択図】  図１
2015103085.tif 000002
【特許請求の範囲】
【請求項１】
開始されたセッション以外に、別のセッションが確立されている場合、共通ヘッダリストを取得する取得手段と、
前記取得した共通ヘッダリストを用いて、受信したデータのヘッダの復号を行う復号手段を有することを特徴とする通信装置。
【請求項２】
開始されたセッション以外に、別のセッションが確立されている場合、共通ヘッダリストを取得する取得手段と、
前記取得した共通ヘッダリストを用いて、送信するデータのヘッダの符号化を行う符号化手段を有することを特徴とする通信装置。
【請求項３】
ヘッダリストに追加すべきデータがある場合、前記共通のヘッダリスト、あるいは、セッション用のヘッダリストに、前記追加すべきデータを追加するヘッダリスト管理手段を有する請求項１又は請求項２に記載の通信装置。
【請求項４】
前記追加すべきデータが、前記共通ヘッダリストにない場合、前記ヘッダリスト管理手段は、セッション用のヘッダリストを生成する請求項３に記載の通信装置。
【請求項５】
前記開始されたセッションが前記共通のヘッダリストを用いているセッションであり、前記共通のヘッダリストのインデックス番号とテーブルに保持されているインデックス番号が同じである場合は、前記ヘッダリスト管理手段は、前記共通のヘッダリストに、前記追加すべきデータを追加する請求項３又は請求項４に記載の通信装置。
【請求項６】
前記開始されたセッションが前記セッション用のヘッダリストを用いているセッションである場合は、前記ヘッダリスト管理手段は、前記セッション用のヘッダリストに、前記追加すべきデータを追加する請求項３乃至５の何れか１項に記載の通信装置。
【請求項７】
前記共通のヘッダリストを用いていたセッションが終了し、かつ、別のセッションない場合、前記共通ヘッダリストを破棄する破棄手段を有する請求項１乃至６の何れか１項に記載の通信装置。
【請求項８】
セッション用のヘッダリストを用いていたセッションが終了した場合、前記セッション用のヘッダリストを破棄する破棄手段を有する請求項１乃至６の何れか１項に記載の通信装置。
【請求項９】
前記取得手段は、開始されたセッションの通信相手と同じ通信相手のセッションがある場合に、共通ヘッダリストを取得する請求項１乃至８の何れか１項に記載の通信装置。
【請求項１０】
前記取得手段は、開始されたセッションの通信相手と同じ通信相手のセッションがない場合に、セッション用のヘッダリストを取得する請求項１乃至９の何れか１項に記載の通信装置。
【請求項１１】
前記追加すべきデータは、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅである請求項１乃至１０の何れか１項に記載の通信装置。
【請求項１２】
セッションを特定する情報、前記セッションで用いているヘッダリストを特定する情報、ヘッダリストで使用しているインデックス番号を特定する情報を含むテーブルを保持する保持手段を有する請求項１乃至１１の何れか１項に記載の通信装置。
【請求項１３】
前記ヘッダを含むデータを受信、あるいは、送信を行う送受信手段を有し、
前記送受信手段は、同じセッション内で、送受信したデータについては、インデックス番号を送受信し、かつ、同じセッション内で、送受信していないデータについては、前記データを送る請求項１乃至１２何れか１項に記載の通信装置。
【請求項１４】
取得手段が、開始されたセッション以外に、別のセッションが確立されている場合、共通ヘッダリストを取得する取得工程と、
復号手段が、前記取得した共通ヘッダリストを用いて、受信したデータのヘッダの復号を行う復号工程を有することを特徴とする通信装置の制御方法。
【請求項１５】
取得手段が、開始されたセッション以外に、別のセッションが確立されている場合、共通ヘッダリストを取得する取得工程と、
符号化手段が、前記取得した共通ヘッダリストを用いて、送信するデータのヘッダの符号化を行う符号化工程を有することを特徴とする通信装置の制御方法。
【請求項１６】
コンピュータを請求項１乃至１３の何れか１項に記載の通信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信データのヘッダ圧縮するための技術に関する。
【背景技術】
【０００２】
一般的に使われているＨＴＴＰのバージョンは１．１であり、ＨＴＴＰ／１．１やＨＴＴＰ１．１と表記される。ＨＴＴＰ１．１は広く普及した通信プロトコルであるが、既知の問題がある。それは、セッションの中でリクエストを出してレスポンスを受け取るまで、次のリクエストを出すことが出来ない点である。また、ＨＴＴＰのヘッダは何度も同じ内容をくり返しているため、クライアントとサーバ間で冗長なデータのやりとりが多い点もある。
【０００３】
そこで、ＨＴＴＰ１．１の問題点を解決するために、ＨＴＴＰの次期バージョンであるＨＴＴＰ２．０の策定が開始された。ＨＴＴＰ２．０では、クライアントとサーバ間でヘッダを送受信する際の冗長なデータを低減するために、ヘッダのデータを圧縮する機能が盛り込まれている。
【０００４】
ヘッダを圧縮する手法として、クライアントとサーバ間のデータのやりとりには差分方式が提案されている（非特許文献１）。差分方式とは、クライアントとサーバ間でデータのやりとりした後、次のやりとりには、それまでにやりとりしたデータと異なる部分だけをやりとりする方式である。さらに、非特許文献１は、ヘッダリストを参照して、ヘッダ情報を別の記号や符号の列に置き換えることで、クライアントとサーバ間でやりとりする情報量を削減している。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｒｐｅｏｎ−ｈｔｔｐｂｉｓ−ｈｅａｄｅｒ−ｃｏｍｐｒｅｓｓｉｏｎ−０３
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１は、ヘッダリストを参照して、ヘッダ情報を記号列に置き換えて、クライアントとサーバ間でやりとりするが、このヘッダリストはセッション毎に管理される。つまり、ある装置で、同時に確立されるセッションが増えると、セッション数分のヘッダテーブルを保持しなければならず、結果として、メモリ使用量が増えてしまうという課題があった。
【０００７】
本発明では、このような事情を鑑みてなされたものであり、ヘッダリストを用いてヘッダ圧縮するプロトコルを使用する際の、セッション増加に伴うメモリ使用の低減を可能とすることを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明の通信装置は、開始されたセッション以外に、別のセッションがある場合、共通ヘッダリストを取得する取得手段と、前記取得した共通ヘッダリストを用いて、受信したデータのヘッダの復号を行う、あるいは、送信するデータのヘッダの符号化を行う復号・符号化手段を有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ヘッダリストを用いてヘッダ圧縮するプロトコルを使用する際の、セッション増加に伴うメモリ使用の低減を可能となる。
【図面の簡単な説明】
【００１０】
【図１】通信装置１００のブロック図
【図２】ＨｅａｄｅｒＤｉｆｆを用いたヘッダ圧縮を説明するための図
【図３】通信装置１００のデータ受信時のフローチャート
【図４】Ｓ３０２の詳細フローチャート
【図５】Ｓ３０６の詳細フローチャート
【図６】Ｓ３０８の詳細フローチャート
【図７】通信装置１００のデータ送信時のフローチャート
【図８】ヘッダリストの例
【図９】テーブルの例
【図１０】本実施形態を説明するための概念図
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施例の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一な構成、同一なステップについては、同じ符号を付して説明する。
【００１２】
＜第１の実施形態＞
本実施形態では、ユーザがＷｅｂブラウザを備えたクライアント端末上において、複数のＷｅｂページを同時に閲覧する事例を考える。ここでは、サーバとクライアント端末はどちらも非特許文献１に記載のＨｅａｄｅｒＤｉｆｆ仕様を元に、ヘッダ情報を圧縮することとする。ＨｅａｄｅｒＤｉｆｆは、クライアントとサーバ間のデータのやりとりには差分方式が用いられる。差分方式は、クライアントとサーバ間でデータのやりとりした後、次のやりとりには、それまでにやりとりしたデータと異なる部分だけをやりとりする。さらに、ヘッダテーブル（ヘッダリスト）を用いて、ヘッダ情報を別の記号や符号の列（インデックス番号）に置き換えて、置き換えられた符号列（インデックス番号）を、送信側に送信する。送信側では、受信側と同じルールで、ヘッダテーブルを作成することで、ヘッダを復号する。同じセッション内で、送受信したヘッダ情報については、インデックス番号を送受信し、かつ、同じセッション内で、送受信していないヘッダ情報については、ヘッダ情報を送る。
【００１３】
図２は、ＨｅａｄｅｒＤｉｆｆを用いたヘッダ圧縮を説明するための図である。
【００１４】
図２（ａ）は、セッションが確立された後、最初に、クライアントから、サーバに、「ＡＡＡ」というヘッダ情報が送信される例を示している。その際、クライアントは、図２（ｃ）のように、ヘッダリストのインデックス番号「１」に、「ＡＡＡ」という値を記録する。尚、ヘッダリストのインデックス番号が、例えば、３７まで使用されていた場合は、ヘッダリストのインデックス番号「３８」に、「ＡＡＡ」という値を記録する。また、ここでは説明のために、「ＡＡＡ」という情報を用いたが、ＨｅａｄｅｒＤｉｆｆでは、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅである。
【００１５】
図２（ｂ）は、サーバが、クライアントから、「ＡＡＡ」というヘッダ情報が受信した例を示している。サーバは、受信した後、クライアントの処理と同様に、図２（ｃ）のヘッダリストを生成する。
【００１６】
図２（ｄ）は、クライアントが、サーバに、再度、「ＡＡＡ」というヘッダ情報を送信する例である。クライアントは、図２（ｃ）のヘッダリストを参照して、「ＡＡＡ」というヘッダ情報があるかを確認する。ヘッダリストに「ＡＡＡ」というヘッダ情報があれば、それに対応するインデックス番号「１」を、サーバに送信する。つまり、「ＡＡＡ」というヘッダ情報を、再度送信するのではなく、インデックス番号「１」を送信することで、情報量を削減している。
【００１７】
図２（ｅ）は、サーバが、クライアントから、インデックス番号「１」を受信した例を示している。サーバは、サーバが保持している図２（ｃ）のヘッダリストから、インデックス番号「１」に対応する「ＡＡＡ」を取得する。
【００１８】
図２では、クライアントからサーバにデータを送信する例を説明したが、サーバからクライアントにデータを送信する場合も同様に処理される。その際、クライアントは、送信用のヘッダリストと受信用のヘッダリストを生成する。
【００１９】
図１（ａ）は、本実施形態における通信装置１００のブロック図である。図１において、１０１は通信装置１００全体を制御するＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）である。１０２は変更を必要としないプログラムやパラメータを格納するＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）である。１０３は外部装置などから供給されるプログラムやデータを一時記憶するＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）である。１０４は保持するデータや供給されたデータを表示するためのインタフェースである。１０５は１０１〜１０４の各ユニットを通信可能に接続するシステムバスである。ユーザからの操作を受けてデータを入力するマウスなどのポインティングデバイスやキーボードなどの入力デバイスとのインタフェース等があってもよい。また通信装置１００に固定して設置されたハードディスクやメモリカード等があってもよい。あるいは通信装置１００から着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ  Ｄｉｓｋ（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む外部記憶装置等があってもよい。さらにインターネットなどのネットワーク回線に接続するためのネットワークインターフェイス等があってもよい。尚、本実施形態における通信装置１００は、サーバと通信を行うクライアント端末であるとする。
【００２０】
図１（ｂ）は、本実施形態における通信装置１００の機能ブロック図である。
【００２１】
セッション管理部２０１は、セッションの開始や終了を検知したり、開始されたセッション以外に、別のセッションが確立しているかを判定する。データ送受信部２０２は、データの受信や送信を行う。また、受信したデータからヘッダを抽出したり、送信するためのデータを生成する。ヘッダ復号・符号化部２０３は、ヘッダリストを用いて、受信したヘッダの復号を行ったり、送信するヘッダの符号化を行う。ヘッダリスト管理部２０４は、ヘッダリスト保持部２０６に保持されているヘッダリストの取得、更新、破棄などを行う。ヘッダリスト保持部２０６には、共通のヘッダリストや、セッション用のヘッダリストが保持される。
【００２２】
テーブル管理部２０５は、テーブル保持部２０７に保持されているテーブルの更新を行う。テーブル保持部２０７に保持されているテーブルは、確立しているセッションを特定するセッション情報、そのセッションで使用しているヘッダリストを特定するヘッダリスト情報、ヘッダリストで使用しているｉｎｄｅｘ番号（インデックス番号）が記録される。セッション情報は、例えば、セッションを特定するセッション名である。ヘッダリスト情報は、例えば、共通のヘッダリストを使用しているのか、セッション用のヘッダリストを使用しているのかを示し、ヘッダリストを特定するためのヘッダリスト名である。ｉｎｄｅｘ番号（インデックス番号）は、使用しているヘッダリストで、そのセッションで、どのｉｎｄｅｘ番号まで使用したかを示す情報である。
【００２３】
図３は、通信装置１００のデータ受信時のフローチャートである。
【００２４】
Ｓ３０１で、セッション管理部２０１が、セッション開始を検知する。Ｓ３０２で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６から、このセッションで使用するヘッダリストを取得する。Ｓ３０３で、データ送受信部２０２が、通信相手（サーバ）からデータを受信する。Ｓ３０４で、データ送受信部２０２が、受信したデータから、ヘッダを抽出する。Ｓ３０５で、抽出したヘッダを、ヘッダ復号・符号化部２０３が、Ｓ３０２で取得したヘッダリストを用いて、復号する。Ｓ３０６で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６に保持されている、このセッションで使用しているヘッダリストを更新する。Ｓ３０７で、セッション管理部２０１が、セッション終了を検知する。Ｓ３０８で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６に保持されている、このセッションに関連するヘッダリストを破棄する。
【００２５】
図４（ａ）は、Ｓ３０２の詳細フローチャートである。
【００２６】
Ｓ４０１で、セッション管理部２０１が、Ｓ３０１で開始したセッション以外に、別のセッションが確立されているかを判定する。Ｓ４０１でＹｅｓの場合は、Ｓ４０２に進み、Ｓ４０１でＮｏの場合は、Ｓ４０４に進む。Ｓ４０２で、ヘッダリスト管理部２０４が、新規に、ヘッダリストを取得する。Ｓ４０２で取得するヘッダリストは、セッションによらず、共通に決められている部分からなるヘッダリストを取得する。例えば、ＨｅａｄｅｒＤｉｆｆは、ヘッダリストのｉｎｄｅｘ番号が０から３７までは予め決められている。これは、セッションによらず、よく使用される部分が予め決めておくことで、ヘッダリストを作る手間を軽減している。ＨｅａｄｅｒＤｉｆｆの場合は、Ｓ４０２で、ヘッダリストのｉｎｄｅｘ番号が０から３７は共通部分であるヘッダリストを取得する。ヘッダリストは、予め装置内（例えば、ヘッダリスト保持部２０６）に保持しておいてもよいし、別の装置から取得してもよい。尚、セッションによらず、予め決められている、共通に用いるヘッダリストがないプロトコルを用いる場合は、Ｓ４０２において、ヘッダリストを取得する必要はない。また、Ｓ４０２で新規に取得されたヘッダリストは、共通のヘッダリストであると設定する。図８（ａ）は、Ｓ４０２が取得したヘッダリストの例である。
【００２７】
Ｓ４０３で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッション名とヘッダリスト名とヘッダリストの使用番号を記録する。図９（ａ）は、テーブルの例である。図９（ａ）は、第１セッションは、共通のヘッダリストを使用し、ヘッダリストのｉｎｄｅｘ番号が３７まで使用されていることを示す。
【００２８】
Ｓ４０４で、ヘッダリスト管理部２０４が、ヘッダリスト保持部２０６から、別のセッションで生成済みの共通ヘッダリストを取得する。図８（ｂ）は、Ｓ４０４が取得したヘッダリストの例である。生成済みの共通ヘッダリストには、別のセッションで、ヘッダリストのｉｎｄｅｘ番号が３８に、ｈｅａｄｅｒ  ｎａｍｅに、「：ｐａｔｈ」、ｈｅａｄｅｒ  ｖａｌｕｅに、「／ｅｘａｍｐｌｅ／ｉｎｄｅｘ．ｈｔｍｌ」が追加されているリストである。
【００２９】
Ｓ４０５で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルには、セッション名とヘッダリスト名とヘッダリストの使用番号を記録する。図９（ｂ）は、テーブルの例である。予め、第２セッションと第３セッションの情報が記録されている場合、Ｓ４０５で、テーブルに、第１セッションを特定する情報、共通のヘッダリストを使用していることを示す情報、ヘッダリストのｉｎｄｅｘ番号が３７まで使用されていること示す情報を追加する。
【００３０】
図５は、Ｓ３０６の詳細フローチャートである。
【００３１】
Ｓ５００で、データ送受信部２０２が、受信したデータのヘッダを用いて、ヘッダリストに追加すべきデータがあるかどうかを判定する。受信したデータのヘッダに、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅがある場合は、追加すべきデータがあると判定する。受信したデータのヘッダに、ｉｎｄｅｘ番号だけの場合は、追加すべきデータがないと判定してもよい。Ｓ５００でＹｅｓの場合は、Ｓ５０１に進み、Ｓ５００でＮｏの場合は、処理を終了する。
【００３２】
Ｓ５０１で、データ送受信部２０２が、受信したデータのヘッダから、追加すべきデータを取得する。具体的には、ヘッダから、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅを取得する。Ｓ５０２で、テーブル管理部２０５が、テーブルを参照して、このセッションで使用しているヘッダリストが、共通のヘッダリストかどうかを判定する。Ｓ５０２でＹｅｓの場合は、Ｓ５０５に進み、Ｓ５０２でＮｏの場合は、Ｓ５０３に進む。
【００３３】
Ｓ５０３で、ヘッダリスト管理部２０４が、セッション用のヘッダリストに、Ｓ５０１で取得した追加すべきデータを追加する。具体的には、ｉｎｄｅｘ番号、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅを、ヘッダリストに追加する。ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅを追加する。Ｓ５０４で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。具体的には、Ｓ５０３において、ｉｎｄｅｘ番号が３８にヘッダリストを追加した場合は、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号を３８に書き換える。
【００３４】
Ｓ５０５で、テーブル管理部２０５が、共通のヘッダリストにおける最後のｉｎｄｅｘ番号と、テーブルに記録されているｉｎｄｅｘ番号が同じかどうかを判定する。具体的には、ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、３７と、テーブルに記録されているｉｎｄｅｘ番号が同じかどうかを判定する。Ｓ５０５でＹｅｓの場合は、Ｓ５０６に進み、Ｓ５０５でＮｏの場合は、Ｓ５０８へ進む。
【００３５】
Ｓ５０６で、ヘッダリスト管理部２０４が、共通のヘッダリストに、Ｓ５０１で取得した追加すべきデータを追加する。具体的には、ｉｎｄｅｘ番号、ヘッダにあるｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅを、ヘッダリストに追加する。ヘッダリストで、ｉｎｄｅｘ番号３７まで既に使用されていたら、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅを追加する。
【００３６】
Ｓ５０７で、テーブル管理部２０５が、対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。具体的には、Ｓ５０６において、ｉｎｄｅｘ番号が３８にヘッダリストを追加した場合は、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号を３８に書き換える。
【００３７】
Ｓ５０８で、テーブル管理部２０５が、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号の次のｉｎｄｅｘ番号に対応する、共通のヘッダリストのｉｎｄｅｘ番号に、Ｓ５０１で取得した追加すべきデータが入っているかを判定する。例えば、テーブルにおける使用しているヘッダリストのｉｎｄｅｘ番号が３７の場合を説明する。この場合、ヘッダリストのｉｎｄｅｘ番号３８のｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅのペアが、追加すべきデータであるｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅのペアと同じであるかを判定する。ｈｅａｄｅｒ  ｎａｍｅとｈｅａｄｅｒ  ｖａｌｕｅのペアと同じである必要があるので、ｈｅａｄｅｒ  ｎａｍｅだけが同じ、あるいは、ｈｅａｄｅｒ  ｖａｌｕｅだけが同じである場合は、Ｓ５０８の判定は、Ｎｏと判定される。Ｓ５０８でＹｅｓの場合は、Ｓ５１１に進み、Ｓ５０８でＮｏの場合は、Ｓ５０９へ進む。
【００３８】
Ｓ５０９で、ヘッダリスト管理部２０４が、セッション用のヘッダリストを生成する。セッション用のヘッダリストの生成は、共通のヘッダリストのうち、テーブルに記載されているｉｎｄｅｘ番号までのデータをコピーし、さらに、Ｓ５０１で取得した追加すべきデータを追加する。図８（ｃ）は、Ｓ５０９が生成したヘッダリストの例である。使用していたヘッダリストが図８（ｂ）のヘッダリストで、ｉｎｄｅｘ番号３８に、追加すべきデータが、ｈｅａｄｅｒ  ｎａｍｅ「ｕｓｅｒ−ａｇｅｎｔ」、ｈｅａｄｅｒ  ｖａｌｕｅ「ｕｓｅｒ−ａｇｅｎｔ」である場合、図８（ｃ）のヘッダリストを生成する。図８（ｂ）のヘッダリストのうち、ｉｎｄｅｘ番号３７までのデータをコピーし、ｉｎｄｅｘ番号３８に、ｈｅａｄｅｒ  ｎａｍｅ「ｕｓｅｒ−ａｇｅｎｔ」、ｈｅａｄｅｒ  ｖａｌｕｅ「ｕｓｅｒ−ａｇｅｎｔ」を追加する。
【００３９】
Ｓ５１０で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリスト名を、セッション用のヘッダテーブルを示す情報に変更し、使用しているヘッダリストのｉｎｄｅｘ番号を変更する。図９（ｃ）は、テーブルの例である。更新前のテーブルが、図９（ｂ）の場合で、Ｓ５０９で、第１セッション用のヘッダリストを生成した場合、図９（ｃ）のように、使用しているヘッダリストを、第１セッション用のヘッダリストを示す情報に変更する。
【００４０】
Ｓ５１１で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。対応するセッション名の、使用しているヘッダリストのｉｎｄｅｘ番号を書き換える。
【００４１】
図６は、Ｓ３０８の詳細フローチャートである。Ｓ６０１で、テーブル管理部２０５が、セッション用のヘッダリストを使用しているかを判定する。Ｓ６０１で、Ｙｅｓの場合は、Ｓ６０２へ進み、Ｓ６０１でＮｏの場合は、Ｓ６０４へ進む。Ｓ６０２で、ヘッダリスト管理部２０４が、セッション用のヘッダリストを破棄する。Ｓ６０３で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッションを終了したセッション名と、セッション用のヘッダリストを用いていることを示す情報、ヘッダリストの使用番号を削除する。Ｓ６０４で、セッション管理部２０１が、別のセッションがあるかどうかを判定する。Ｓ６０４で、Ｙｅｓの場合は、処理を終了し、Ｓ６０４でＮｏの場合は、Ｓ６０５へ進む。Ｓ６０５で、共通のヘッダリストを破棄する。Ｓ６０６で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルに、セッションを終了したセッション名と、共通のヘッダリストを用いていることを示す情報、ヘッダリストの使用番号を削除する。
【００４２】
図７は、通信装置１００のデータ送信時のフローチャートである。Ｓ７０１、Ｓ７０２、Ｓ７０３以外は、図３で説明したステップと同じであるので、説明は省略する。Ｓ７０１で、ヘッダ復号・符号化部２０３が、Ｓ３０２で取得したヘッダリストを用いて、ヘッダ符号化を行う。Ｓ７０２で、データ送受信部２０２が、Ｓ７０１で符号化したヘッダを含めて、送信するデータを生成する。Ｓ７０３で、データ送受信部２０２が、Ｓ７０２で生成したデータを、通信相手（サーバ）に送る。
【００４３】
図１０（ｂ）は、本実施形態を適用した場合の概念図である。セッション１とセッション２では、共通のヘッダリストを用いており、セッション３では、セッション３用のヘッダリストを用いている。図１０（ａ）は、本実施形態を適用する前の概念図である。セッション１、セッション２、セッション３いずれも、セッション毎のヘッダリストを用いている。
【００４４】
＜変形例＞
変形例では、ヘッダリストが同じになる可能性のあるセッションについては、最初は、共通のヘッダリストを用いるが、ヘッダリストが同じにならない可能性のあるセッションについては、最初から、セッション用のヘッダリストを使う例である。
【００４５】
図４（ｂ）は、Ｓ３０２の詳細フローチャートである。Ｓ４０１〜Ｓ４０５は、図４（ａ）と同じであるので、説明は省略する。
【００４６】
Ｓ４０１でＹｅｓの場合は、Ｓ４０６に進み、Ｓ４０６では、セッション管理部２０１が、通信相手が同じセッションがあるかを判定する。具体的には、テーブル保持部２０７に保持しているテーブルを参照し、通信相手が同じであるセッションがあるか判定する。通信相手が同じセッションがある場合は、同じヘッダをやりとりする可能性が高いので、ヘッダリストが同じになる可能性が高い。Ｓ４０６でＹｅｓの場合は、Ｓ４０９に進み、Ｓ４０６でＮｏの場合は、Ｓ４０７に進む。
【００４７】
Ｓ４０７では、ヘッダリスト管理部２０４が、ヘッダリストを取得する。Ｓ４０７が取得するヘッダリストは、Ｓ４０２で取得するヘッダリストと同じであるが、取得したヘッダリストをセッション用のヘッダリストとして設定する。
【００４８】
Ｓ４０８では、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。テーブルには、セッション名と、通信相手、セッション用のヘッダリストを使用していること、ヘッダリストの使用番号を記録する。Ｓ４０９で、ヘッダリスト管理部２０４が、通信相手が同じセッションで用いられている生成済みの共通ヘッダリストを取得する。具体的には、通信相手が、サーバＡの場合は、サーバＡの共通ヘッダリストを取得する。
【００４９】
Ｓ４１０で、テーブル管理部２０５が、テーブル保持部２０７に保持されているテーブルを更新する。セッション名と、通信相手、共通のヘッダリストを使用していること、ヘッダリストの使用番号を記録する。図９（ｄ）は、テーブルの例である。図９（ａ）〜（ｃ）などのテーブルと異なるのは、通信相手が記録されている点と、通信相手毎に共通のヘッダリストを用いる点である。
【００５０】
上記変形例のＳ４０６では、通信相手が同じかどうかで判定を行ったが、通信相手が同じかどうかでなく、ドメインが同じかで判定を行ってもよい。ドメインが同じ場合も、同じヘッダをやりとりする可能性が高いので、ヘッダリストが同じになる可能性が高い。
【００５１】
また、過去にセッション用のヘッダリストを作成したかの履歴と残しておき、Ｓ４０６の代わりに、通信相手が同じであるか、かつ、履歴を用いて、過去にセッション用のヘッダリストを作成しなかったかを判定してもよい。履歴を用いることで、通信相手が同じであっても、ヘッダリストが同じになる可能性が高い場合にのみ、共通ヘッダリストを用いることができる。
【００５２】
変形例によれば、ヘッダリストが同じになる可能性が高くない場合は、予めセッション用のヘッダリストを作成することで、後から、セッション用のヘッダリストを作成する必要がなくなる。また、図５におけるＳ５０５やＳ５０８の判定も不要になるので、処理負荷を軽減できる。
【００５３】
本実施形態では、通信装置１００がクライアント端末である例を説明したが、クライアント端末の代わりに、同様の処理をサーバで行ってもよい。サーバで行った場合は、サーバのメモリ使用が削減可能となる。
【００５４】
本実施形態では、ＨｅａｄｅｒＤｉｆｆ仕様をもとに実施する例を示したが、他の仕様、例えば、Ｄｅｌｔａ２などを用いてもよい。特に、クライアントとサーバ間で、差分方式を用いてデータのやりとりを行い、かつ、ヘッダリストを用いて、ヘッダ圧縮を行うプロトコルであれは適用可能である。
【００５５】
以上の実施形態によれば、ヘッダリストが共通できる場合においては、共通のヘッダリストも用いることで、メモリ使用量を低減することが可能である。
【００５６】
以上の実施形態によれば、クライアントとサーバ間の通信において、ＨＴＴＰ２．０プロトコルで複数セッション同時にヘッダ情報をやりとりする場合、通信装置のメモリ使用量を低減することが可能である。
【００５７】
＜その他の変形例＞
以上本発明にかかる実施形態を説明したが、先に説明したように、通信装置は、通常のパーソナルコンピュータ等の汎用情報処理装置であって、それ上で動作するコンピュータプログラムで実現できるものである。よって、本発明はコンピュータプログラムをその範疇とすることは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ読み取り可能な記憶媒体に格納されており、それをコンピュータの対応するドライブにセットしてシステムにコピーやインストール処理することで実行可能となる。よって、本発明は当然にそのようなコンピュータ可読記憶媒体をもその範疇とすることも明らかである。
【図１】
2015103085.tif 000003
【図２】
2015103085.tif 000004
【図３】
2015103085.tif 000005
【図４】
2015103085.tif 000006
【図５】
2015103085.tif 000007
【図６】
2015103085.tif 000008
【図７】
2015103085.tif 000009
【図８】
2015103085.tif 000010
【図９】
2015103085.tif 000011
【図１０】
2015103085.tif 000012