(57)【要約】【課題】  装置間でヘッダテーブルの生成方法の整合がとれているか否かを確認するための技術を提供すること。【解決手段】  通信用のヘッダが登録されたテーブルを保持する外部装置から、リクエストヘッダと、該外部装置が求めた、該テーブルに該リクエストヘッダを登録した後の該テーブルの誤り検出用の符号と、を受信する。外部装置との通信用のヘッダが登録されたテーブルに上記受信したリクエストヘッダを登録した後の該テーブルの誤り検出用の符号を求め、該求めた符号と、上記受信した符号と、が一致した場合に、外部装置に対してレスポンスヘッダを送信する。【選択図】  図１
2015230712.tif 000002
【特許請求の範囲】
【請求項１】
通信用のヘッダが登録されたテーブルを保持する外部装置から、リクエストヘッダと、該外部装置が求めた、該テーブルに該リクエストヘッダを登録した後の該テーブルの誤り検出用の符号と、を受信する受信手段と、
前記外部装置との通信用のヘッダが登録されたテーブルに前記受信手段が受信したリクエストヘッダを登録した後の該テーブルの誤り検出用の符号を求め、該求めた符号と、前記受信手段が受信した符号と、が一致した場合に、前記外部装置に対してレスポンスヘッダを送信する通信制御手段と
を備えることを特徴とする通信装置。
【請求項２】
前記通信制御手段は、
前記求めた符号と、前記受信手段が受信した符号と、が一致した場合に、前記外部装置との通信用のヘッダが登録されたテーブルに前記受信手段が受信したリクエストヘッダを登録することで該テーブルを更新することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記通信制御手段は、
前記求めた符号と、前記受信手段が受信した符号と、が一致しなかった場合には、エラー処理を行うことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記外部装置は、
前記リクエストヘッダを前記通信装置に対して送信する手段と、
前記リクエストヘッダを、通信用のヘッダが登録されたテーブルに登録し、該登録の後の該テーブルの誤り検出用の符号を生成し、該符号を前記通信装置に対して送信する送信手段と
を備えることを特徴とする請求項１乃至３の何れか１項に記載の通信装置。
【請求項５】
前記送信手段は、通信用のヘッダが登録されたテーブルへの前記リクエストヘッダの登録が初回ではない場合に、該登録の後の該テーブルの誤り検出用の符号を生成し、該符号を前記通信装置に対して送信することを特徴とする請求項４に記載の通信装置。
【請求項６】
前記通信制御手段は、
前記求めた符号と、前記受信手段が受信した符号と、が一致しなかった場合には、該一致しなかった旨を前記外部装置に対して通知し、
前記外部装置は、
該通知を受けた場合には、前記外部装置が保持するテーブルを、最近の更新の前の状態に戻す手段を備える
ことを特徴とする請求項４又は５に記載の通信装置。
【請求項７】
前記テーブルは、ＨＰＡＣＫに従ってヘッダを登録した、ＨＴＴＰ  ２．０の仕様に従ったテーブルであることを特徴とする請求項１乃至６の何れか１項に記載の通信装置。
【請求項８】
通信装置及び外部装置を有する通信システムであって、
前記外部装置は、
リクエストヘッダを前記通信装置に対して送信する手段と、
前記リクエストヘッダを、通信用のヘッダが登録された第１のテーブルに登録し、該登録の後の該第１のテーブルの誤り検出用の符号を生成し、該符号を前記通信装置に対して送信する手段と
を備え、
前記通信装置は、
前記外部装置から、前記リクエストヘッダと、前記符号と、を受信する受信手段と、
前記外部装置との通信用のヘッダが登録された第２のテーブルに前記受信手段が受信したリクエストヘッダを登録した後の該第２のテーブルの誤り検出用の符号を求め、該求めた符号と、前記受信手段が受信した符号と、が一致した場合に、前記外部装置に対してレスポンスヘッダを送信する通信制御手段と
を備えることを特徴とする通信システム。
【請求項９】
通信装置が行う通信方法であって、
前記通信装置の受信手段が、通信用のヘッダが登録されたテーブルを保持する外部装置から、リクエストヘッダと、該外部装置が求めた、該テーブルに該リクエストヘッダを登録した後の該テーブルの誤り検出用の符号と、を受信する受信工程と、
前記通信装置の通信制御手段が、前記外部装置との通信用のヘッダが登録されたテーブルに前記受信工程で受信したリクエストヘッダを登録した後の該テーブルの誤り検出用の符号を求め、該求めた符号と、前記受信工程で受信した符号と、が一致した場合に、前記外部装置に対してレスポンスヘッダを送信する通信制御工程と
を備えることを特徴とする通信方法。
【請求項１０】
コンピュータを、請求項１乃至７の何れか１項に記載の通信装置の各手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術に関するものである。
【背景技術】
【０００２】
インターネットにおいて、クライアント装置とサーバ装置とは、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルでコンテンツ等のやり取りを行っている。ここで、コンテンツとは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ファイル、ＪａｖａＳｃｒｉｐｔ(登録商標)ファイル、画像ファイル、ＣＳＳ（Ｃａｓｃａｄｉｎｇ  Ｓｔｙｌｅ  Ｓｈｅｅｔｓ）ファイルなどである。
【０００３】
近年、モバイル端末の普及や大容量・リアルタイムコンテンツの普及により、インターネット全体のトラフィック量が増大している。現在使われているＨＴＴＰ  １．１はテキストベースのプロトコルであり、ステートレスな通信を行う。また、冗長なヘッダをやりとりする必要があるという課題がある。
【０００４】
このようなＨＴＴＰ  １．１の課題を解決するため、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）は、ＨＴＴＰ  ２．０（非特許文献１）の策定を開始した。ＨＴＴＰ  ２．０では、ヘッダの冗長性に取り組むため、ヘッダの圧縮機能が取り込まれる予定である。
【０００５】
このヘッダの圧縮手法としてＨＰＡＣＫ（非特許文献２）が提案されている。ＨＰＡＣＫでは差分圧縮方式を用いており、クライアント装置とサーバ装置との間で一度やりとりされたヘッダについて、２度目以降は差分情報のみをやりとりする。また、仕様において、高頻度で利用されるヘッダ名にあらかじめインデックス番号を付与したものを定義している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】”Hypertext Transfer Protocol version 2.0 draft-ietf-httpbis-http2-07”、［online］、［平成26年5月26日検索］、インターネット＜ＵＲＬ：http://tools.ietf.org/html/draft-ietf-httpbis-http2-07＞
【非特許文献２】”HPACK - Header Compression for HTTP/2.0 draft-ietf-httpbis-header-compression-03”、［online］、［平成26年5月26日検索］、インターネット＜ＵＲＬ：http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-03＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＨＰＡＣＫにおいて、サーバ装置は、クライアント装置からのリクエストヘッダ及びクライアント装置へのレスポンスヘッダにインデックス番号を付与し、ヘッダテーブルに保存する。そしてサーバ装置は、このヘッダテーブルに保存したインデックス番号を用いてヘッダを生成することで、ヘッダのサイズを圧縮する。ここで、ヘッダテーブル生成方法が仕様と異なる場合は正しくサーバ装置とクライアント装置の間で通信を行うことは出来ない。しかし、従来技術として、ヘッダテーブル生成方法が正しいか否かを確認する方法がない。
【０００８】
本発明はこのような問題に鑑みてなされたものであり、装置間でヘッダテーブルの生成方法の整合がとれているか否かを確認するための技術を提供する。
【課題を解決するための手段】
【０００９】
本発明の一様態は、通信用のヘッダが登録されたテーブルを保持する外部装置から、リクエストヘッダと、該外部装置が求めた、該テーブルに該リクエストヘッダを登録した後の該テーブルの誤り検出用の符号と、を受信する受信手段と、前記外部装置との通信用のヘッダが登録されたテーブルに前記受信手段が受信したリクエストヘッダを登録した後の該テーブルの誤り検出用の符号を求め、該求めた符号と、前記受信手段が受信した符号と、が一致した場合に、前記外部装置に対してレスポンスヘッダを送信する通信制御手段とを備えることを特徴とする。
【発明の効果】
【００１０】
本発明の構成によれば、装置間でヘッダテーブルの生成方法の整合がとれているか否かを確認することができる。
【図面の簡単な説明】
【００１１】
【図１】コンピュータのハードウェア構成例を示すブロック図。
【図２】通信システムの構成例を示すブロック図。
【図３】クライアント端末装置２００が行う処理のフローチャート。
【図４】ＨＴＴＰリクエストヘッダの構成例を示す図。
【図５】ヘッダテーブル２０６の構成例を示す図。
【図６】ステップＳ３０５における処理の詳細を示すフローチャート。
【図７】シリアライズデータの構成例を示す図。
【図８】ＴＢＬＣＨＫ＿ＦＲＡＭＥの構成例を示す図。
【図９】サーバ装置２５０が行う処理のフローチャート。
【図１０】ステップＳ３０５における処理の詳細を示すフローチャート。
【図１１】サーバ装置２５０が行う処理のフローチャート。
【図１２】クライアント端末装置２００が行う処理のフローチャート。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の１つである。
【００１３】
［第１の実施形態］
先ず、本実施形態に係る通信システムの構成例について、図２のブロック図を用いて説明する。本実施形態では、説明を簡単にするために、図２に示す如く、１台のクライアント端末装置２００と、１台のサーバ装置２５０と、を有する通信システムを例にとり、クライアント端末装置２００及びサーバ装置２５０のそれぞれの動作について説明する。
【００１４】
図２に示す如く、クライアント端末装置２００とサーバ装置２５０とはネットワーク２９９に接続されており、このネットワーク２９９を介して、ＨＴＴＰ  ２．０に従ったデータ通信を行う。
【００１５】
先ず、クライアント端末装置２００の動作について、該クライアント端末装置２００が行う処理のフローチャートを示す図３を用いて説明する。ステップＳ３０１では、ヘッダ生成部２０２は、サーバ装置２５０に対するＨＴＴＰリクエストヘッダを生成する。ステップＳ３０２では、ヘッダ生成部２０２は、ヘッダテーブル２０６の更新が必要か否かを判断する。そしてこの判断の結果、ヘッダテーブル２０６の更新が必要と判断した場合には、処理はステップＳ３０３に進み、更新は必要ないと判断した場合には、処理はステップＳ３０６に進む。
【００１６】
ステップＳ３０３では、ヘッダ生成部２０２は、ステップＳ３０１において生成したＨＴＴＰリクエストヘッダを、ＨＴＴＰ  ２．０の仕様に従って、ヘッダテーブル２０６に登録し、これによりヘッダテーブル２０６を更新する。ヘッダテーブル２０６の更新方法は、ＨＰＡＣＫの仕様に従う。
【００１７】
ここで、ヘッダテーブル２０６の構成例を図５に示す。図５において５０１〜５１２はレコードであり、レコード毎に、Ｉｎｄｅｘ（インデックス）、Ｈｅａｄｅｒ  Ｎａｍｅ（ヘッダ名）、Ｈｅａｄｅｒ  Ｖａｌｕｅ（ヘッダ値）が登録されている。また、レコード５０１〜５１０は、ＨＰＡＣＫのデフォルトヘッダテーブルから変更されていないレコードである。然るに、ヘッダテーブル２０６がＨＰＡＣＫのデフォルトヘッダテーブルである場合、レコード５０１〜５１０には図５に示す如く情報が登録されているものの、レコード５１１〜５１２には未だ何も登録されていないことになる。
【００１８】
ヘッダテーブル２０６がＨＰＡＣＫのデフォルトヘッダテーブルである場合に、ヘッダ生成部２０２が図４（ａ）に示したＨＴＴＰリクエストヘッダを生成したとする。このとき、図４（ａ）のＨＴＴＰリクエストヘッダにおける１行目の「：ｍｅｔｈｏｄ」及び「ＧＥＴ」のセットはすでにレコード５０５に登録されている。また、図４（ａ）のＨＴＴＰリクエストヘッダにおける２行目の「：ｓｃｈｅｍｅ」及び「ｈｔｔｐ」のセットはすでにレコード５０１に登録されている。また、図４（ａ）のＨＴＴＰリクエストヘッダにおける３行目の「：ｐａｔｈ」及び「／」のセットはすでにレコード５０４に登録されている。このように、図４（ａ）のＨＴＴＰリクエストヘッダはすでにヘッダテーブル２０６に登録されていることになるので、この場合、ステップＳ３０２では、ヘッダテーブル２０６の更新は必要ないと判断する。
【００１９】
また、ヘッダテーブル２０６がＨＰＡＣＫのデフォルトヘッダテーブルである場合に、ヘッダ生成部２０２が図４（ｂ）に示したＨＴＴＰリクエストヘッダを生成したとする。図４（ｂ）のＨＴＴＰリクエストヘッダにおいて１行目から３行目はそれぞれ、図４（ａ）のＨＴＴＰリクエストヘッダにおける１行目から３行目と同じである。しかし、図４（ｂ）のＨＴＴＰリクエストヘッダにおける４行目の「ｘ−ｍｙｈｅａｄｅｒ１：」及び「ｍｙｈｅａｄｅｒ１」のセットは、ＨＰＡＣＫのデフォルトヘッダテーブルであるヘッダテーブル２０６（レコード５０１〜５１０）には登録されていない。そこでこの場合、ステップＳ３０２では、ヘッダテーブル２０６の更新が必要と判断し、ステップＳ３０３では、この４行目のセットが、ＨＴＴＰ  ２．０の仕様に従って、ヘッダテーブル２０６（レコード５１１）に登録される。
【００２０】
図４（ｂ）のＨＴＴＰリクエストヘッダの登録後（レコード５１１への登録後）、ヘッダ生成部２０２が図４（ｃ）に示したＨＴＴＰリクエストヘッダを生成したとする。図４（ｃ）のＨＴＴＰリクエストヘッダにおいて１行目から４行目はそれぞれ、図４（ｂ）のＨＴＴＰリクエストヘッダにおける１行目から４行目と同じである。しかし、図４（ｃ）のＨＴＴＰリクエストヘッダにおける５行目の「ｘ−ｍｙｈｅａｄｅｒ２：」及び「ｍｙｈｅａｄｅｒ２」のセットは、ヘッダテーブル２０６（レコード５０１〜５１１）には登録されていない。そこでこの場合、ステップＳ３０２では、ヘッダテーブル２０６の更新が必要と判断し、ステップＳ３０３では、この５行目のセットが、ＨＴＴＰ  ２．０の仕様に従って、ヘッダテーブル２０６（レコード５１２）に登録される。
【００２１】
図３に戻って、次に、ステップＳ３０３で行ったヘッダテーブル２０６の更新が初回であった場合にのみ、処理はステップＳ３０４を介してステップＳ３０６に進み、初回ではない場合には、処理はステップＳ３０４を介してステップＳ３０５に進む。ステップＳ３０５では、誤り検出符号生成部２０４は、ヘッダテーブル２０６を用いて、誤り検出用の符号（以下、誤り検出符号）を生成する。
【００２２】
ステップＳ３０６では、送受信部２０７は、ステップＳ３０１で生成したＨＴＴＰリクエストヘッダを、ネットワーク２９９を介して、サーバ装置２５０に対して送信する。上記のように、ステップＳ３０３で行ったヘッダテーブル２０６の更新が初回であった場合には、誤り検出符号の生成を行わないので、処理負荷が軽減される。しかし、誤り検出符号の生成は更新が初回以外であった場合に行われることに限るものではなく、定期的に行っても良いし、規定の条件が満たされた場合に行っても良い。
【００２３】
ここで、ステップＳ３０５における処理の詳細について、図６のフローチャートを用いて説明する。ステップＳ６０１では、誤り検出符号生成部２０４は、ヘッダテーブル２０６を取得する。
【００２４】
ステップＳ６０２では、誤り検出符号生成部２０４は、ヘッダテーブル２０６を図７に示すようなフォーマットのデータ（シリアライズデータ）に変換する。ここで、全ての文字列はＵＴＦ−８で扱われることとする。領域７０１〜７０５は、ヘッダテーブル２０６におけるレコード毎に設けられる。
【００２５】
領域７０１は、８ビットの値を格納するための領域であり、レコード内のＩｎｄｅｘの値を格納するための領域である。領域７０２は、８ビットの値を格納するための領域であり、レコード内のＨｅａｄｅｒ  Ｎａｍｅの文字数を格納するための領域である。領域７０３は、レコード内のＨｅａｄｅｒ  Ｎａｍｅ（文字列）を格納するための領域である。領域７０４は、８ビットの値を格納するための領域であり、レコード内のＨｅａｄｅｒ  Ｎａｍｅのバイト数を格納するための領域である。領域７０５は、レコード内のＨｅａｄｅｒ  Ｖａｌｕｅ（文字列）を格納するための領域である。
【００２６】
例えばレコード５０１を領域７０１〜７０５に登録する場合、領域７０１には「０」が登録され、領域７０２には「７」が登録され、領域７０３には「：ｓｃｈｅｍｅ」が登録され、領域７０４には「４」が登録され、領域７０５には「ｈｔｔｐ」が登録される。
【００２７】
図５の場合、レコード５０１〜５１２のそれぞれについて領域７０１〜７０５が設けられるので、レコード毎に、対応する領域７０１〜７０５に該レコード内の情報を登録する。そして、レコード毎の領域７０１〜７０５内の情報を全て連結したデータを、シリアライズデータとして生成する。
【００２８】
ステップＳ６０３では、誤り検出符号生成部２０４は、ステップＳ６０２で生成したシリアライズデータから符号（誤り検出符号）を生成する。この符号は、固定長のデータであり、例えば、シリアライズデータをＣＲＣ−３２符号化したものである。
【００２９】
図３に戻って、ステップＳ３０６におけるＨＴＴＰリクエストヘッダの送信後、ステップＳ３０３で行ったヘッダテーブル２０６の更新が初回であった場合にのみ、処理はステップＳ３０７を介してステップＳ３０８に進む。一方、初回ではない場合には、図３のフローチャートに従った処理は終了する。
【００３０】
ステップＳ３０８では、誤り検出符号生成部２０４は、ステップＳ３０５で生成した誤り検出符号を用いてＴＢＬＣＨＫ＿ＦＲＡＭＥを生成する。ＴＢＬＣＨＫ＿ＦＲＡＭＥの構成例を図８に示す。
【００３１】
領域８０１は、フレームタイプを登録するための領域であり、ＨＴＴＰ  ２．０の仕様で定義されている他のフレームと衝突しないものが登録される。領域８０２は、ステップＳ３０５で生成した誤り検出符号を登録するための領域である。然るに、ステップＳ３０８では、領域８０１，８０２のそれぞれに、フレームタイプ及びステップＳ３０５で生成した誤り検出符号を登録することで、ＴＢＬＣＨＫ＿ＦＲＡＭＥを生成する。ステップＳ３０９では、送受信部２０７は、ステップＳ３０８で生成したＴＢＬＣＨＫ＿ＦＲＡＭＥを、ネットワーク２９９を介してサーバ装置２５０に対して送信する。
【００３２】
次に、サーバ装置２５０の動作について、該サーバ装置２５０が行う処理のフローチャートを示す図９を用いて説明する。図９のフローチャートに従った処理は、クライアント端末装置２００が図３のフローチャートに従った処理を行った場合に、サーバ装置２５０が行う処理を示したものである。
【００３３】
ステップＳ９０１では、送受信部２５７は、クライアント端末装置２００から送信されたＨＴＴＰリクエストヘッダを受信する。ステップＳ９０２では、送受信部２５７は、クライアント端末装置２００から送信されたＴＢＬＣＨＫ＿ＦＲＡＭＥを受信する。
【００３４】
ステップＳ９０３では、誤り検出符号生成部２５４は先ず、クライアント端末装置２００用のヘッダテーブル２５６をコピーした複製ヘッダテーブルを生成する。ヘッダテーブル２５６はヘッダテーブル２０６と同様の構成（例えば図５に示す構成）を有するものである。周知の如く、サーバ装置２５０は、通信する相手毎にヘッダテーブル２５６を保持しており、ここでは、クライアント端末装置２００用のヘッダテーブル２５６が使用される。
【００３５】
そして誤り検出符号生成部２５４は、この複製ヘッダテーブルに、ステップＳ９０１で受信したＨＴＴＰリクエストヘッダを登録することで、該複製ヘッダテーブルを更新する。複製ヘッダテーブルへのヘッダ登録方法については、クライアント端末装置２００が行った上記の方法と同じである。
【００３６】
ステップＳ９０４では、誤り検出符号生成部２５４は、ステップＳ９０３において更新した複製ヘッダテーブル（仮想テーブル）の誤り検出符号を生成する。ステップＳ９０５では、検証部２５５は、ステップＳ９０２で受信したＴＢＬＣＨＫ＿ＦＲＡＭＥ内の領域８０２に登録されている誤り検出符号と、ステップＳ９０４で生成した誤り検出符号と、が一致しているか否かを判断する。この判断の結果、一致している場合、即ち、サーバ装置２５０がクライアント端末装置２００用に保持しているヘッダテーブル２５６と、クライアント端末装置２００が保持しているヘッダテーブル２０６と、が一致している場合、処理はステップＳ９０７に進む。一方、一致していない場合には、処理はステップＳ９０６に進む。
【００３７】
ステップＳ９０７では、検証部２５５は、ヘッダテーブル２５６に、ステップＳ９０１で受信したＨＴＴＰリクエストヘッダを登録することで、該ヘッダテーブル２５６を更新する。ヘッダテーブルへのヘッダ登録方法については、クライアント端末装置２００が行った上記の方法と同じである。
【００３８】
ステップＳ９０８では、ヘッダ生成部２５２は、ＨＴＴＰリクエストヘッダに対応するＨＴＴＰレスポンスヘッダを生成する。そして送受信部２５７は、このＨＴＴＰレスポンスヘッダを、ネットワーク２９９を介してクライアント端末装置２００に対して送信する。
【００３９】
一方、ステップＳ９０６では、送受信部２５７は、何らかのエラー処理を実行する。例えば、クライアント端末装置２００に対してエラーを通知しても構わない。また、サーバ装置２５０がクライアント端末装置２００用に保持しているヘッダテーブル２５６と、クライアント端末装置２００が保持しているヘッダテーブル２０６と、が一致していないことを、クライアント端末装置２００に対して通知しても構わない。また例えば、ＨＴＴＰ  ２．０で定められているコネクション切断（クライアント端末装置２００との間の接続を切断する）を行うようにしても構わない。
【００４０】
即ち、本実施形態に係るサーバ装置２５０は、以下に示す構成の一例に過ぎない。即ち、通信用のヘッダが登録されたテーブルを保持する外部装置から、リクエストヘッダと、該外部装置が求めた、該テーブルに該リクエストヘッダを登録した後の該テーブルの誤り検出用の符号と、を受信する。そして、外部装置との通信用のヘッダが登録されたテーブルに、受信したリクエストヘッダを登録した後の該テーブルの誤り検出用の符号を求め、該求めた符号と、受信した符号と、が一致した場合に、外部装置に対してレスポンスヘッダを送信する（通信制御）。
【００４１】
また、本実施形態に係るクライアント端末装置２００は、以下に示す構成の一例に過ぎない。すなわち、リクエストヘッダを通信装置に対して送信し、リクエストヘッダを、通信用のヘッダが登録されたテーブルに登録し、該登録の後の該テーブルの誤り検出用の符号を生成し、該符号を通信装置に対して送信する。
【００４２】
［第２の実施形態］
第１の実施形態では、誤り検出符号の生成には、ヘッダテーブルに含まれている全てのレコードを用いていたが、本実施形態では、誤り検出符号は、更新されたレコード（追加されたレコード）から生成する。以下では、第１の実施形態との差分について重点的に説明し、以下で特に触れない限りは、第１の実施形態と同様であるものとする。
【００４３】
より具体的には、第１の実施形態では、シリアライズデータは、ヘッダテーブルに含まれている全てのレコードについて領域７０１〜７０５に登録した情報を連結したものであった。これに対し、本実施形態では、更新されたレコード（追加されたレコード）について領域７０１〜７０５に登録した情報からシリアライズデータを生成する。
【００４４】
然るに、本実施形態では、上記のステップＳ３０５において、図６のフローチャートに従った処理ではなく、図１０のフローチャートに従った処理を行う点のみが、第１の実施形態と異なる。然るに以下では、この図１０のフローチャートに従った処理について説明する。
【００４５】
ステップＳ１００１では、誤り検出符号生成部２０４は、ヘッダテーブル２０６から、更新されたレコード（追加されたレコード）を取得する。ステップＳ１００２では、ステップＳ１００１で取得したレコード毎に、対応する領域７０１〜７０５に該レコード内の情報を登録する。そして、レコード毎の領域７０１〜７０５内の情報を全て連結したデータを、シリアライズデータとして生成する。
【００４６】
例えば、図５を例にとると、レコード５０１〜５１１が存在している状態で、図４（ｃ）のＨＴＴＰリクエストヘッダをヘッダテーブル２０６に登録した場合、「更新されたレコード（追加されたレコード）」は「レコード５１２」となる。然るにこの場合、ステップＳ１００１ではレコード５１２を取得することになり、ステップＳ１００２では、レコード５１２内の情報を領域７０１〜７０５に登録し、レコード５１２に対する領域７０１〜７０５からシリアライズデータを生成することになる。これにより、第１の実施形態と比べて、シリアライズデータのサイズをより小さくすることが出来るだけでなく、シリアライズデータの生成時間を短縮することも出来る。ステップＳ１００３では、誤り検出符号生成部２０４は、ステップＳ１００２で生成したシリアライズデータから誤り検出符号を生成する。
【００４７】
なお、サーバ装置２５０側でシリアライズデータを生成する場合も同様に、全てのレコードを使用するわけではなく、「更新されたレコード（追加されたレコード）」を用いてシリアライズデータを生成することになる。
【００４８】
［第３の実施形態］
本実施形態では、ステップＳ９０５において互いの符号が一致していない場合には、クライアント端末装置２００及びサーバ装置２５０のそれぞれにおけるヘッダテーブルを元の正常な状態に戻して通信を継続させる。以下では、第１の実施形態との差分について重点的に説明し、以下で特に触れない限りは、第１の実施形態と同様であるものとする。
【００４９】
先ず、サーバ装置２５０の動作について、サーバ装置２５０が行う処理のフローチャートを示す図１１を用いて説明する。なお、図１１に示したそれぞれの処理ステップのうち、図９に示した処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。ステップＳ１１０１では、送受信部２５７は、ＴＢＬＲＥＣＯＶＥＲＹ＿ＦＲＡＭＥを、ネットワーク２９９を介してクライアント端末装置２００に対して送信する。
【００５０】
次に、クライアント端末装置２００の動作について、クライアント端末装置２００が行う処理のフローチャートを示す図１２を用いて説明する。なお、図１２に示したそれぞれの処理ステップのうち、図３に示した処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。
【００５１】
ステップＳ１２０３では、送受信部２０７は、ヘッダテーブル２０６（ステップＳ３０３における更新前のヘッダテーブル２０６）の複製である複製ヘッダテーブルを生成し、複製ヘッダテーブルをクライアント端末装置２００内の不図示のメモリに保存する。
【００５２】
その後、図１２のフローチャートに従った処理を実行する場合、ステップＳ３０１における処理の開始前に、ステップＳ１２０１において送受信部２０７は、ＴＢＬＲＥＣＯＶＥＲＹ＿ＦＲＡＭＥを受信したか否かを判断する。そしてこの判断の結果、受信した場合には、処理はステップＳ１２０２に進み、受信していない場合には、処理はステップＳ３０１に進む。
【００５３】
ステップＳ１２０２では、現時点でのヘッダテーブル２０６に、複製ヘッダテーブルを上書き保存することで、ヘッダテーブル２０６を前回保存したヘッダテーブル２０６（最近の更新の前の状態）に戻す。
【００５４】
このような処理により、サーバ装置２５０とクライアント端末装置２００との間でヘッダテーブルに差異が生じた場合は、両者のヘッダテーブルが一致していた状態に戻すことができ、正常な通信を行うことが可能になる。
【００５５】
なお、上記の実施形態では、ＨＴＴＰ  ２．０に従ったデータ通信を例にとり説明したが、ヘッダの差分情報を用いて通信を行うようなものであれば、ＨＴＴＰ  ２．０以外の規格に従ったデータ通信であっても構わない。
【００５６】
また、上記の実施形態では、１台のクライアント端末装置２００と１台のサーバ装置２５０との間でデータ通信を行う場合におけるそれぞれの装置の動作について説明した。しかし、クライアント端末装置２００及びサーバ装置２５０が１対多の関係であっても、それぞれの装置の動作は同様である。
【００５７】
［第４の実施形態］
図２に示した、サーバ装置２５０及びクライアント端末装置２００内の各機能部（ヘッダテーブル２０６及びヘッダテーブル２５６を除く）は、ハードウェアで構成しても構わないし、ソフトウェア（コンピュータプログラム）で構成しても構わない。
【００５８】
後者の場合、次のようなコンピュータは、クライアント端末装置２００に適用することが出来る。即ち、ヘッダ生成部２０２、誤り検出符号生成部２０４、送受信部２０７の各機能部に対応するコンピュータプログラムを実行するプロセッサと、該コンピュータプログラム及びヘッダテーブル２０６を保持するメモリと、を有するコンピュータである。
【００５９】
また、次のようなコンピュータは、サーバ装置２５０に適用することが出来る。即ち、ヘッダ生成部２５２、送受信部２５７、誤り検出符号生成部２５４、検証部２５５の各機能部に対応するコンピュータプログラムを実行するプロセッサと該コンピュータプログラム及びヘッダテーブル２５６を保持するメモリとを有するコンピュータである。
【００６０】
クライアント端末装置２００及びサーバ装置２５０に適用可能なコンピュータのハードウェア構成例について、図１のブロック図を用いて説明する。もちろん、クライアント端末装置２００及びサーバ装置２５０に適用可能なコンピュータのハードウェア構成例は、図１に示した構成に限るものではなく、様々な構成が考え得る。また、クライアント端末装置２００と、サーバ装置２５０と、で適用するコンピュータの構成は異なっていても良い。
【００６１】
ＣＰＵ１０１は、ＲＯＭ１０２やＲＡＭ１０３に格納されているコンピュータプログラムやデータを用いて処理を実行することで、本コンピュータ全体の動作制御を行うと共に、本コンピュータを適用した装置が行うものとして上述した各処理を実行する。
【００６２】
ＲＯＭ１０２には、本コンピュータの設定データやブートプログラムなど、不揮発性のデータが格納されている。ＲＡＭ１０３は、記憶部１０４からロードされたコンピュータプログラムやデータ、通信部１０６を介して外部装置から受信したデータ、を格納するためのエリアや、ＣＰＵ１０１が各種の処理を実行する際に用いるワークエリアを有する。即ち、ＲＡＭ１０３は、各種のエリアを適宜提供することが出来る。
【００６３】
記憶部１０４は、ハードディスクドライブ装置に代表される大容量情報記憶装置である。記憶部１０４には、ＯＳ（オペレーティングシステム）や、本コンピュータを適用した装置が行うものとして上述した各処理をＣＰＵ１０１に実行させるためのコンピュータプログラムやデータが保存されている。
【００６４】
本コンピュータをクライアント端末装置２００に適用した場合、このコンピュータプログラムには、次のようなコンピュータプログラムが含まれている。すなわち、ヘッダ生成部２０２、誤り検出符号生成部２０４、送受信部２０７の各機能部が行うものとして上述した各処理をＣＰＵ１０１に実行させるためのコンピュータプログラムである。また、本コンピュータをクライアント端末装置２００に適用した場合、このデータには、ヘッダテーブル２０６や、クライアント端末装置２００が既知の情報として取り扱うものとして上述したデータが含まれている。
【００６５】
本コンピュータをサーバ装置２５０に適用した場合、このコンピュータプログラムには、次のようなコンピュータプログラムが含まれている。すなわち、ヘッダ生成部２５２、送受信部２５７、誤り検出符号生成部２５４、検証部２５５の各機能部が行うものとして上述した各処理をＣＰＵ１０１に実行させるためのコンピュータプログラムである。また、本コンピュータをサーバ装置２５０に適用した場合、このデータには、ヘッダテーブル２５６や、サーバ装置２５０が既知の情報として取り扱うものとして上述したデータが含まれている。
【００６６】
記憶部１０４に保存されているコンピュータプログラムやデータは、ＣＰＵ１０１による制御に従って適宜ＲＡＭ１０３にロードされ、ＣＰＵ１０１による処理対象となる。
【００６７】
操作部１０５は、キーボードやマウスなどのユーザインターフェースにより構成されており、本コンピュータのユーザが操作することで、各種の指示をＣＰＵ１０１に対して入力することが出来る。
【００６８】
通信部１０６は、上記のネットワーク２９９上の装置とのデータ通信を行うためのものであり、本コンピュータをクライアント端末装置２００に適用した場合、この通信部１０６は、ネットワーク２９９を介してサーバ装置２５０との間のデータ通信を行う。また、本コンピュータをサーバ装置２５０に適用した場合、この通信部１０６は、ネットワーク２９９を介してクライアント端末装置２００との間のデータ通信を行う。
【００６９】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００７０】
２５７：送受信部  ２５２：ヘッダ生成部  ２５５：検証部  ２５４：誤り検出符号生成部  ２５６：ヘッダテーブル
【図１】
2015230712.tif 000003
【図２】
2015230712.tif 000004
【図３】
2015230712.tif 000005
【図４】
2015230712.tif 000006
【図５】
2015230712.tif 000007
【図６】
2015230712.tif 000008
【図７】
2015230712.tif 000009
【図８】
2015230712.tif 000010
【図９】
2015230712.tif 000011
【図１０】
2015230712.tif 000012
【図１１】
2015230712.tif 000013
【図１２】
2015230712.tif 000014