WO2015186286A1 - 通信装置、通信方法 - Google Patents

通信装置、通信方法 Download PDF

Info

Publication number
WO2015186286A1
WO2015186286A1 PCT/JP2015/001976 JP2015001976W WO2015186286A1 WO 2015186286 A1 WO2015186286 A1 WO 2015186286A1 JP 2015001976 W JP2015001976 W JP 2015001976W WO 2015186286 A1 WO2015186286 A1 WO 2015186286A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
error detection
detection data
header information
communication
Prior art date
Application number
PCT/JP2015/001976
Other languages
English (en)
French (fr)
Inventor
友輔 渡部
Original Assignee
キヤノン株式会社
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 キヤノン株式会社 filed Critical キヤノン株式会社
Publication of WO2015186286A1 publication Critical patent/WO2015186286A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units

Definitions

  • the present invention relates to communication technology.
  • a client device and a server device exchange contents with a communication protocol called HTTP (Hypertext Transfer Protocol).
  • HTTP Hypertext Transfer Protocol
  • the content includes an HTML (HyperText Markup Language) file, a JavaScript (registered trademark) file, an image file, a CSS (Cascading Style Sheets) file, and the like.
  • HTTP 1.1 currently used is a text-based protocol and performs stateless communication. There is also a problem that redundant headers need to be exchanged.
  • HTTP 2.0 In order to solve such problems of HTTP 1.1, IETF (Internet Engineering Task Force) has started formulating HTTP 2.0 (Non-Patent Document 1). HTTP 2.0 will include a header compression function to address header redundancy.
  • HPACK Non-Patent Document 2
  • HPACK a differential compression method is used, and only the difference information is exchanged for the second and subsequent headers once exchanged between the client device and the server device.
  • a header name that is used frequently is assigned an index number in advance.
  • the server device assigns an index number to the request header from the client device and the response header to the client device, and stores them in the header table. And a server apparatus compresses the size of a header by producing
  • the header table generation method is different from the specification, communication between the server device and the client device cannot be performed correctly.
  • the present invention has been made in view of such problems, and provides a technique for confirming whether or not the header table generation method is consistent between apparatuses.
  • a reception unit that receives a request including header information and first error detection data generated based on the header information from another communication device, and the reception unit receives the request.
  • Generation means for generating second error detection data based on the header information included in the request; the first error detection data received by the reception means; and the second error detection data generated by the generation means.
  • Comparison means for comparing data for error detection, storage control means for storing the header information in a header table in accordance with a result of comparison by the comparison means, and the header information stored by the storage control means Communication means for communicating with the other communication device based on the header table.
  • the block diagram which shows the hardware structural example of a computer.
  • the block diagram which shows the structural example of a communication system.
  • the flowchart of the process which the client terminal device 200 performs. , , The figure which shows the structural example of an HTTP request header.
  • the figure which shows the structural example of TBLCHK_FRAME The flowchart of the process which the server apparatus 250 performs.
  • the client terminal device 200 and the server device 250 are connected to a network 299, and perform data communication according to HTTP 2.0 via the network 299.
  • step S ⁇ b> 301 the header generation unit 202 generates an HTTP request header for the server device 250.
  • step S302 the header generation unit 202 determines whether or not the header table 206 needs to be updated. As a result of this determination, if it is determined that the header table 206 needs to be updated, the process proceeds to step S303. If it is determined that no update is necessary, the process proceeds to step S306.
  • step S303 the header generation unit 202 registers the HTTP request header generated in step S301 in the header table 206 according to the specification of HTTP 2.0, and thereby updates the header table 206.
  • the updating method of the header table 206 follows the specification of HPACK.
  • FIG. 5 a configuration example of the header table 206 is shown in FIG.
  • reference numerals 501 to 512 denote records, and an Index (index), Header Name (header name), and Header Value (header value) are registered for each record.
  • Records 501 to 510 are records that have not been changed from the default header table of HPACK. However, when the header table 206 is a default header table of HPACK, information is registered in the records 501 to 510 as shown in FIG. 5, but nothing is registered in the records 511 to 512 yet. .
  • the header generation unit 202 generates the HTTP request header shown in FIG. 4A when the header table 206 is a default header table of HPACK.
  • the set of “: method” and “GET” on the first line in the HTTP request header of FIG. 4A is already registered in the record 505.
  • the set of “: scheme” and “http” on the second line in the HTTP request header of FIG. 4A is already registered in the record 501.
  • the set of “: path” and “/” on the third line in the HTTP request header of FIG. 4A is already registered in the record 504.
  • the header generation unit 202 has generated the HTTP request header shown in FIG. 4B when the header table 206 is a default header table of HPACK.
  • the first to third lines in the HTTP request header in FIG. 4B are the same as the first to third lines in the HTTP request header in FIG. 4A, respectively.
  • the set of “x-myheader1:” and “myheader1” on the fourth line in the HTTP request header of FIG. 4B is not registered in the header table 206 (records 501 to 510) which is the default header table of HPACK. Therefore, in this case, in step S302, it is determined that the header table 206 needs to be updated.
  • the set of the fourth row is registered in the header table 206 (record 511) in accordance with the HTTP 2.0 specification. .
  • the header generation unit 202 After registration of the HTTP request header in FIG. 4B (after registration in the record 511), the header generation unit 202 generates the HTTP request header shown in FIG. 4C.
  • the first to fourth lines in the HTTP request header in FIG. 4C are the same as the first to fourth lines in the HTTP request header in FIG. 4B, respectively.
  • the set of “x-myheader2:” and “myheader2” on the fifth line in the HTTP request header of FIG. 4C is not registered in the header table 206 (records 501 to 511). Therefore, in this case, in step S302, it is determined that the header table 206 needs to be updated.
  • the set of the fifth row is registered in the header table 206 (record 512) in accordance with the HTTP 2.0 specification. .
  • step S ⁇ b> 306 via step S ⁇ b> 304 only when the update of the header table 206 performed in step S ⁇ b> 303 is the first time.
  • the process proceeds to step S305 via S304.
  • step S305 the error detection code generation unit 204 uses the header table 206 to generate a code for error detection (hereinafter, error detection code).
  • step S306 the transmission / reception unit 207 transmits the HTTP request header generated in step S301 to the server apparatus 250 via the network 299.
  • the error detection code is not generated, so the processing load is reduced.
  • the generation of the error detection code is not limited to being performed when the update is performed other than the first time, and may be performed periodically or when a prescribed condition is satisfied.
  • step S601 the error detection code generation unit 204 acquires the header table 206.
  • step S602 the error detection code generation unit 204 converts the header table 206 into data (serialized data) having a format as shown in FIG. Here, all character strings are handled by UTF-8. Areas 701 to 705 are provided for each record in the header table 206.
  • the area 701 is an area for storing an 8-bit value, and is an area for storing an Index value in the record.
  • An area 702 is an area for storing an 8-bit value, and is an area for storing the number of characters of Header Name in the record.
  • An area 703 is an area for storing Header Name (character string) in the record.
  • An area 704 is an area for storing an 8-bit value, and is an area for storing the number of bytes of Header Name in the record.
  • An area 705 is an area for storing a header value (character string) in the record.
  • step S603 the error detection code generation unit 204 generates a code (error detection code) from the serialized data generated in step S602.
  • This code is fixed-length data, and is, for example, CRC-32 encoded serialized data.
  • step S308 after the transmission of the HTTP request header in step S306, the process proceeds to step S308 via step S307 only when the update of the header table 206 performed in step S303 is the first time. On the other hand, if it is not the first time, the process according to the flowchart of FIG. 3 ends.
  • step S308 the error detection code generation unit 204 generates TBLCHK_FRAME using the error detection code generated in step S305.
  • a configuration example of TBLCHK_FRAME is shown in FIG.
  • the area 801 is an area for registering a frame type, and an area that does not collide with other frames defined in the specification of HTTP 2.0 is registered.
  • An area 802 is an area for registering the error detection code generated in step S305.
  • TBLCHK_FRAME is generated by registering the frame type and the error detection code generated in step S305 in each of the regions 801 and 802.
  • the transmission / reception unit 207 transmits the TBLCHK_FRAME generated in step S308 to the server apparatus 250 via the network 299.
  • FIG. 9 showing a flowchart of processing performed by the server apparatus 250.
  • the process according to the flowchart of FIG. 9 shows the process performed by the server apparatus 250 when the client terminal apparatus 200 performs the process according to the flowchart of FIG.
  • step S901 the transmission / reception unit 257 receives the HTTP request header transmitted from the client terminal device 200.
  • step S902 the transmission / reception unit 257 receives TBLCHK_FRAME transmitted from the client terminal device 200.
  • step S903 the error detection code generation unit 254 first generates a duplicate header table obtained by copying the header table 256 for the client terminal device 200.
  • the header table 256 has the same configuration as the header table 206 (for example, the configuration shown in FIG. 5).
  • the server apparatus 250 holds a header table 256 for each party to communicate with, and here, the header table 256 for the client terminal apparatus 200 is used.
  • the error detection code generation unit 254 updates the duplicate header table by registering the HTTP request header received in step S901 in the duplicate header table.
  • the header registration method in the duplicate header table is the same as the above method performed by the client terminal device 200.
  • step S904 the error detection code generation unit 254 generates an error detection code of the duplicate header table (virtual table) updated in step S903.
  • step S905 the verification unit 255 determines whether or not the error detection code registered in the area 802 in TBLCHK_FRAME received in step S902 matches the error detection code generated in step S904. As a result of this determination, if they match, that is, the header table 256 held by the server apparatus 250 for the client terminal apparatus 200 and the header table 206 held by the client terminal apparatus 200 match. If yes, the process proceeds to step S907. On the other hand, if they do not match, the process proceeds to step S906.
  • step S907 the verification unit 255 updates the header table 256 by registering the HTTP request header received in step S901 in the header table 256.
  • the header registration method in the header table is the same as the above method performed by the client terminal device 200.
  • step S908 the header generation unit 252 generates an HTTP response header corresponding to the HTTP request header. Then, the transmission / reception unit 257 transmits this HTTP response header to the client terminal device 200 via the network 299.
  • step S906 the transmission / reception unit 257 executes some error processing. For example, an error may be notified to the client terminal device 200. Further, the client terminal apparatus 200 is informed that the header table 256 held by the server apparatus 250 for the client terminal apparatus 200 and the header table 206 held by the client terminal apparatus 200 do not match. You can be notified. Further, for example, connection disconnection (disconnection with the client terminal device 200) defined in HTTP 2.0 may be performed.
  • the server apparatus 250 is merely an example of the configuration shown below. That is, from an external device holding a table in which a header for communication is registered, a request header, an error detection code of the table after the request header is registered in the table, which is obtained by the external device, Receive. Then, the error detection code of the table after registering the received request header is obtained in the table in which the header for communication with the external device is registered, and the obtained code matches the received code. In this case, a response header is transmitted to the external device (communication control).
  • the client terminal device 200 is merely an example of the configuration shown below. That is, the request header is transmitted to the communication device, the request header is registered in the table in which the communication header is registered, a code for error detection of the table after the registration is generated, and the code is Send to the communication device.
  • the error detection code is an updated record (an added record). ).
  • the serialized data is obtained by concatenating information registered in the areas 701 to 705 for all the records included in the header table.
  • serialized data is generated from information registered in the areas 701 to 705 for the updated record (added record).
  • the present embodiment is different from the first embodiment only in that the process according to the flowchart of FIG. 10 is performed instead of the process according to the flowchart of FIG. In the following, however, processing according to the flowchart of FIG. 10 will be described.
  • step S1001 the error detection code generation unit 204 acquires an updated record (added record) from the header table 206.
  • the information in the record is registered in the corresponding areas 701 to 705 for each record acquired in step S1001. Then, data obtained by concatenating all the information in the areas 701 to 705 for each record is generated as serialized data.
  • step S1001 the HTTP request header of FIG. 4C is registered in the header table 206 in a state where records 501 to 511 exist, “updated record (added record)” is “Record 512”.
  • the record 512 is acquired in step S1001, and in step S1002, the information in the record 512 is registered in the areas 701 to 705, and serialized data is generated from the areas 701 to 705 for the record 512. .
  • the error detection code generation unit 204 generates an error detection code from the serialized data generated in step S1002.
  • serialized data is generated using “updated records (added records)”.
  • step S905 if the codes do not match in step S905, the header table in each of the client terminal device 200 and the server device 250 is returned to the original normal state to continue communication.
  • the first embodiment differences from the first embodiment will be described mainly, and unless otherwise noted, the same as the first embodiment.
  • step S1101 the transmission / reception unit 257 transmits TBLRECOVERY_FRAME to the client terminal device 200 via the network 299.
  • FIG. 12 showing a flowchart of processing performed by the client terminal device 200.
  • the same processing steps as the processing steps shown in FIG. 3 are denoted by the same step numbers, and description thereof will be omitted.
  • step S1203 the transmission / reception unit 207 generates a duplicate header table that is a duplicate of the header table 206 (the header table 206 before being updated in step S303), and stores the duplicate header table in a memory (not illustrated) in the client terminal device 200. To do.
  • the transmission / reception unit 207 determines whether or not the TBLRECOVERY_FRAME is received in step S1201 before the process in step S301 is started. If the result of this determination is that it has been received, the process proceeds to step S1202, and if it has not been received, the process proceeds to step S301.
  • step S1202 the duplicate header table is overwritten and saved in the current header table 206 to return the header table 206 to the previously saved header table 206 (the state before the latest update).
  • HTTP 2.0 data communication according to HTTP 2.0 has been described as an example. However, if communication is performed using difference information in the header, it conforms to a standard other than HTTP 2.0. Data communication may be used.
  • each device when data communication is performed between one client terminal device 200 and one server device 250 has been described. However, even if the client terminal device 200 and the server device 250 have a one-to-many relationship, the operation of each device is the same.
  • Each functional unit (except for the header table 206 and the header table 256) in the server device 250 and the client terminal device 200 shown in FIG. 2 may be configured by hardware or software (computer program). It doesn't matter.
  • the following computer can be applied to the client terminal device 200. That is, the computer includes a processor that executes computer programs corresponding to the functional units of the header generation unit 202, the error detection code generation unit 204, and the transmission / reception unit 207, and a memory that stores the computer program and the header table 206. .
  • the following computer can be applied to the server apparatus 250. That is, a computer having a processor that executes computer programs corresponding to the functional units of the header generation unit 252, the transmission / reception unit 257, the error detection code generation unit 254, and the verification unit 255, and a memory that holds the computer program and the header table 256. It is.
  • a hardware configuration example of a computer applicable to the client terminal device 200 and the server device 250 will be described with reference to the block diagram of FIG.
  • the hardware configuration example of the computer applicable to the client terminal device 200 and the server device 250 is not limited to the configuration shown in FIG. 1, and various configurations can be considered. Further, the configuration of the computer applied between the client terminal device 200 and the server device 250 may be different.
  • the CPU 101 executes processes using computer programs and data stored in the ROM 102 and the RAM 103, thereby controlling the operation of the entire computer and performing each process described above as being performed by an apparatus to which the computer is applied. Execute.
  • the ROM 102 stores non-volatile data such as setting data and a boot program of the computer.
  • the RAM 103 is an area for storing computer programs and data loaded from the storage unit 104, data received from an external device via the communication unit 106, and a work area used when the CPU 101 executes various processes. Have. That is, the RAM 103 can provide various areas as appropriate.
  • the storage unit 104 is a large-capacity information storage device represented by a hard disk drive device.
  • the storage unit 104 stores a computer program and data for causing the CPU 101 to execute the processes described above as performed by an OS (operating system) and a device to which the present computer is applied.
  • OS operating system
  • the computer program includes the following computer program. That is, this is a computer program for causing the CPU 101 to execute the processes described above as performed by the function units of the header generation unit 202, the error detection code generation unit 204, and the transmission / reception unit 207.
  • this data includes the header table 206 and the data described above as what the client terminal device 200 handles as known information.
  • the computer program includes the following computer program. That is, this is a computer program for causing the CPU 101 to execute the processes described above as performed by the function units of the header generation unit 252, the transmission / reception unit 257, the error detection code generation unit 254, and the verification unit 255. Further, when this computer is applied to the server device 250, this data includes the header table 256 and the data described above as what the server device 250 handles as known information.
  • the computer program and data stored in the storage unit 104 are appropriately loaded into the RAM 103 under the control of the CPU 101 and are processed by the CPU 101.
  • the operation unit 105 is configured by a user interface such as a keyboard or a mouse, and various instructions can be input to the CPU 101 by the user of the computer.
  • the communication unit 106 performs data communication with the devices on the network 299.
  • the communication unit 106 is connected to the server device 250 via the network 299. Data communication with is performed.
  • the communication unit 106 performs data communication with the client terminal device 200 via the network 299.
  • the present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program This process can be realized. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.
  • a circuit for example, ASIC
  • Transmission / reception unit 252 Header generation unit 255: Verification unit 254: Error detection code generation unit 256: Header table

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

　装置間でヘッダテーブルの生成方法の整合がとれているか否かを確認するための技術を提供すること。　他の通信装置から、ヘッダ情報を含むリクエストと、ヘッダ情報に基づいて生成される第１誤り検出用データと、を受信する。リクエストに含まれるヘッダ情報に基づいて第２誤り検出用データを生成する。第１誤り検出用データと第２誤り検出用データとを比較する。該比較の結果に応じて、ヘッダ情報をヘッダテーブルに格納させる。ヘッダ情報が格納されたヘッダテーブルに基づいて他の通信装置と通信を行う。

Description

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

Claims (20)

  1. 　他の通信装置から、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を受信する受信手段と、
    　前記受信手段により受信された前記リクエストに含まれるヘッダ情報に基づいて第２誤り検出用データを生成する生成手段と、
    　前記受信手段により受信された前記第１誤り検出用データと、前記生成手段により生成された前記第２誤り検出用データと、を比較する比較手段と、
    　前記比較手段による比較の結果に応じて、前記ヘッダ情報をヘッダテーブルに格納させる格納制御手段と、
    　前記格納制御手段によって前記ヘッダ情報が格納された前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信手段と
    　を有することを特徴とする通信装置。
  2. 　前記リクエストはHTTPリクエストであることを特徴とする請求項１に記載の通信装置。
  3. 　前記第１及び第２誤り検出用データが一致すると前記比較手段が判定する場合、前記格納制御手段は、前記ヘッダ情報を前記ヘッダテーブルに格納し、前記第１及び第２誤り検出用データが一致しないと前記比較手段が判定する場合、前記格納制御手段は、前記ヘッダ情報を前記ヘッダテーブルに格納しないことを特徴とする請求項１に記載の通信装置。
  4. 　前記ヘッダテーブルは、前記ヘッダ情報とインデックス情報とが対応づけられたテーブルであり、
    　前記通信手段は、前記他の通信装置からのリクエストに含まれるインデックス情報に基づいて前記ヘッダテーブルから特定されるヘッダ情報に応じたレスポンスを前記他の通信装置に対して送信することを特徴とする請求項１に記載の通信装置。
  5. 　前記第１及び第２誤り検出用データが一致しないと前記比較手段が判定する場合、エラー処理を実行するエラー処理手段をさらに有することを特徴とする請求項１に記載の通信装置。
  6. 　前記第１及び第２誤り検出用データが一致しないと前記比較手段が判定する場合、前記エラー処理手段は、前記第１及び第２誤り訂正用データが一致しないことを前記他の通信装置に対して通知することを特徴とする請求項５に記載の通信装置。
  7. 　前記第１及び第２誤り訂正用データが一致しないと前記比較手段が判定する場合、前記エラー処理手段は、前記通信装置と前記他の通信装置との間で確立済みのTCPコネクションを切断することを特徴とする請求項５に記載の通信装置。
  8. 　前記第１及び第２誤り検出用データは、前記ヘッダテーブルに格納される複数のヘッダ情報を用いて生成されることを特徴とする請求項１に記載の通信装置。
  9. 　前記第１誤り検出用データは、前記ヘッダテーブルに格納される複数のヘッダ情報のうち、更新対象のヘッダ情報を用いて生成され、前記生成手段は、前記通信手段により受信されたヘッダ情報のうち、前記ヘッダテーブルに未格納のヘッダ情報を用いて前記第２誤り検出用データを生成することを特徴とする請求項１に記載の通信装置。
  10. 　前記第１及び第２誤り検出用データが一致しないと前記比較手段が判定する場合、前記通信手段は、前記他の通信装置が保持するヘッダテーブルを、前記第１誤り検出用データに対応する前記ヘッダ情報に基づく更新前のヘッダテーブルに変更させるためのテーブルリカバリフレームを前記他の通信装置に対して送信することを特徴とする請求項１に記載の通信装置。
  11. 　他の通信装置に対して、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を送信する送信手段と、
    　前記ヘッダ情報をヘッダテーブルに格納させる格納制御手段と、
    　前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信手段と、
    　前記送信手段により送信された前記第１誤り検出用データと、前記他の通信装置が前記ヘッダ情報に基づいて生成した第２誤り検出用データと、の比較結果に応じた通知を、前記他の通信装置から取得する取得手段と、
    　前記取得手段により取得された通知に応じて、前記通信手段による前記他の通信装置との通信を制御する制御手段と
    　を有することを特徴とする通信装置。
  12. 　前記第１及び第２誤り検出用データが一致しない状況に対応する通知を前記取得手段が取得した場合、前記制御手段は、前記通信装置と前記他の通信装置との間で確立済みのTCPコネクションを切断することを特徴とする請求項１１に記載の通信装置。
  13. 　前記第１及び第２誤り検出用データが一致しない状況に対応する通知を前記取得手段が取得した場合、前記制御手段は、前記ヘッダテーブルを、前記第１誤り検出用データに対応する前記ヘッダ情報に基づく更新前のヘッダテーブルに変更することを特徴とする請求項１１に記載の通信装置。
  14. 　他の通信装置から、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を受信する受信工程と、
    　前記受信工程で受信された前記リクエストに含まれるヘッダ情報に基づいて第２誤り検出用データを生成する生成工程と、
    　前記受信工程で受信された前記第１誤り検出用データと、前記生成工程で生成された前記第２誤り検出用データと、を比較する比較工程と、
    　前記比較工程での比較の結果に応じて、前記ヘッダ情報をヘッダテーブルに格納させる格納制御工程と、
    　前記格納制御工程で前記ヘッダ情報が格納された前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信工程と
    　を有することを特徴とする通信方法。
  15. 　前記第１及び第２誤り検出用データが一致すると前記比較工程において判定される場合、前記格納制御工程では、前記ヘッダ情報が前記ヘッダテーブルに格納され、前記第１及び第２誤り検出用データが一致しないと前記比較工程において判定される場合、前記格納制御工程では、前記ヘッダ情報が前記ヘッダテーブルに格納されないことを特徴とする請求項１４に記載の通信方法。
  16. 　他の通信装置に対して、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を送信する送信工程と、
    　前記ヘッダ情報をヘッダテーブルに格納させる格納制御工程と、
    　前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信工程と、
    　前記送信工程で送信された前記第１誤り検出用データと、前記他の通信装置が前記ヘッダ情報に基づいて生成した第２誤り検出用データと、の比較結果に応じた通知を、前記他の通信装置から取得する取得工程と、
    　前記取得工程で取得された通知に応じて、前記通信工程における前記他の通信装置との通信を制御する制御工程と
    　を有することを特徴とする通信方法。
  17. 　前記第１及び第２誤り検出用データが一致しない状況に対応する通知が前記取得工程で取得された場合、前記制御工程では、前記ヘッダテーブルが、前記第１誤り検出用データに対応する前記ヘッダ情報に基づく更新前のヘッダテーブルに変更されることを特徴とする請求項１６に記載の通信方法。
  18. 　コンピュータに、
    　他の通信装置から、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を受信する受信工程と、
    　前記受信工程で受信された前記リクエストに含まれるヘッダ情報に基づいて第２誤り検出用データを生成する生成工程と、
    　前記受信工程で受信された前記第１誤り検出用データと、前記生成工程で生成された前記第２誤り検出用データと、を比較する比較工程と、
    　前記比較工程での比較の結果に応じて、前記ヘッダ情報をヘッダテーブルに格納させる格納制御工程と、
    　前記格納制御工程で前記ヘッダ情報が格納された前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信工程と
    　を実行させることを特徴とするプログラム。
  19. 　前記第１及び第２誤り検出用データが一致すると前記比較工程において判定される場合、前記格納制御工程では、前記ヘッダ情報が前記ヘッダテーブルに格納され、前記第１及び第２誤り検出用データが一致しないと前記比較工程において判定される場合、前記格納制御工程では、前記ヘッダ情報が前記ヘッダテーブルに格納されないことを特徴とする請求項１８に記載のプログラム。
  20. 　コンピュータに、
    　他の通信装置に対して、ヘッダ情報を含むリクエストと、前記ヘッダ情報に基づいて生成される第１誤り検出用データと、を送信する送信工程と、
    　前記ヘッダ情報をヘッダテーブルに格納させる格納制御工程と、
    　前記ヘッダテーブルに基づいて前記他の通信装置と通信を行う通信工程と、
    　前記送信工程で送信された前記第１誤り検出用データと、前記他の通信装置が前記ヘッダ情報に基づいて生成した第２誤り検出用データと、の比較結果に応じた通知を、前記他の通信装置から取得する取得工程と、
    　前記取得工程で取得された通知に応じて、前記通信工程における前記他の通信装置との通信を制御する制御工程と
    　を実行させることを特徴とするプログラム。
PCT/JP2015/001976 2014-06-06 2015-04-08 通信装置、通信方法 WO2015186286A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-118134 2014-06-06
JP2014118134A JP2015230712A (ja) 2014-06-06 2014-06-06 通信装置、通信方法、通信システム

Publications (1)

Publication Number Publication Date
WO2015186286A1 true WO2015186286A1 (ja) 2015-12-10

Family

ID=54766373

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/001976 WO2015186286A1 (ja) 2014-06-06 2015-04-08 通信装置、通信方法

Country Status (2)

Country Link
JP (1) JP2015230712A (ja)
WO (1) WO2015186286A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135362A (ja) * 2000-08-17 2002-05-10 Matsushita Electric Ind Co Ltd ヘッダ圧縮装置およびヘッダ圧縮方法
WO2013079277A1 (en) * 2011-12-02 2013-06-06 Canon Kabushiki Kaisha Methods and devices for encoding and decoding messages

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002135362A (ja) * 2000-08-17 2002-05-10 Matsushita Electric Ind Co Ltd ヘッダ圧縮装置およびヘッダ圧縮方法
WO2013079277A1 (en) * 2011-12-02 2013-06-06 Canon Kabushiki Kaisha Methods and devices for encoding and decoding messages

Also Published As

Publication number Publication date
JP2015230712A (ja) 2015-12-21

Similar Documents

Publication Publication Date Title
JP5753597B2 (ja) データ同期プロトコル
EP2363995B1 (en) Methods for optimizing a web content proxy server and devices thereof
US9471646B2 (en) Method and server device for exchanging information items with a plurality of client entities
US9338258B2 (en) Methods and network devices for communicating data packets
CN106462611B (zh) 网络访问性能增强
CN106878460B (zh) 通信处理方法及装置
CN104094554A (zh) 无服务器名称指示(sni)的隐式ssl证书管理
JP2002268937A (ja) データ転送装置、データ転送方法及びプログラム
US20080319994A1 (en) Method for registering a template message, generating an update message, regenerating and providing an application request, computer arrangement, computer program and computer program product
WO2022179353A1 (zh) 域名解析方法、装置及计算机设备
WO2006001137A1 (ja) データ通信システム、サーバ装置及びデータ通信方法並びにそのプログラム
CN113992738A (zh) 基于微服务网关的反向代理方法、装置、设备及存储介质
EP2787454A1 (en) Methods for optimizing a web content proxy server and devices thereof
CN108874472B (zh) 一种用户头像的优化显示方法及系统
US9137289B2 (en) Facilitating a stateless transmission of data in an information technology system
US11838207B2 (en) Systems for session-based routing
JP2010079523A (ja) セッションデータ共有方法
WO2015186286A1 (ja) 通信装置、通信方法
JP6364727B2 (ja) 情報処理システム、分散処理方法、及び、プログラム
CN111125142B (zh) 一种数据更新方法及系统
US11546405B2 (en) Methods for exposing mainframe data as a web service and devices thereof
CN117082124B (zh) 数据传送方法、装置、设备、介质及产品
JP5637351B2 (ja) サーバ・クライアント・システム、サーバ装置、待機サーバ装置およびクライアント装置
JP2017134539A (ja) 中継装置、ルータ、配信システム、中継方法及び中継プログラム
JP6300497B2 (ja) 通信装置およびその制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15802400

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15802400

Country of ref document: EP

Kind code of ref document: A1