JP2016018502A - 通信装置および通信方法、ならびに通信システム - Google Patents

通信装置および通信方法、ならびに通信システム Download PDF

Info

Publication number
JP2016018502A
JP2016018502A JP2014142637A JP2014142637A JP2016018502A JP 2016018502 A JP2016018502 A JP 2016018502A JP 2014142637 A JP2014142637 A JP 2014142637A JP 2014142637 A JP2014142637 A JP 2014142637A JP 2016018502 A JP2016018502 A JP 2016018502A
Authority
JP
Japan
Prior art keywords
communication
communication device
http
header table
compression
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
JP2014142637A
Other languages
English (en)
Other versions
JP2016018502A5 (ja
JP6363897B2 (ja
Inventor
幸夫 沼上
Yukio Numagami
幸夫 沼上
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
Priority to JP2014142637A priority Critical patent/JP6363897B2/ja
Priority to US14/790,138 priority patent/US9596326B2/en
Publication of JP2016018502A publication Critical patent/JP2016018502A/ja
Publication of JP2016018502A5 publication Critical patent/JP2016018502A5/ja
Application granted granted Critical
Publication of JP6363897B2 publication Critical patent/JP6363897B2/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/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • H04L43/067Generation of reports using time frame reporting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】メッセージヘッダの圧縮の際に参照するテーブルを通信装置間の接続状況に応じて選択することでテーブルの再利用を可能とし、テーブルの新規作成を軽減する。【解決手段】通信装置において、他の通信装置に送信するメッセージヘッダを圧縮用のテーブルを参照して圧縮するが、他の通信装置に送信するメッセージヘッダまたは他の通信装置から受信したメッセージヘッダに基づいて該テーブルは更新される。S1502で、他の通信装置とのネットワークを介した接続状況を判断し、接続中であると判断された他の通信装置については、S1508で当該通信装置に対応するテーブルを参照する。【選択図】 図10

Description

本発明は、メッセージ通信を行う際にメッセージヘッダを圧縮する通信装置および通信方法に関する。
インターネット標準技術として一般に広く利用されているプロトコル(通信規約)の一つに、HTTP(Hyper Text Transfer Protocol)がある。現在、インターネット標準化団体(IETF:Internet Engineering Task Force)において、HTTPの新しいバージョン(HTTP/2.0)の標準化策定が進められている(非特許文献1参照)。
HTTP/2.0の新しい機能として、HTTPヘッダ圧縮機能がある。HTTPヘッダ圧縮機能は、HTTPヘッダテーブルと呼ばれる一種の辞書を利用してHTTPヘッダ情報をデータ圧縮し、サーバ・クライアント間においてHTTPヘッダ情報の差分のみを送受信する(非特許文献2参照)。これにより、サーバ・クライアント間で送受信されるHTTP通信メッセージのデータサイズを削減することが可能になる。
M.Balshe、他3名、"Hypertext Transfer Protocol version 2"、[online]、April 23,2014、インターネット<URL:http://www.ietf.org/id/draft-ietf-httpbis-http2-03.txt> R.Peon、H.Ruellan、"HTTP Header Compression for HTTP/2",[online]、April 03,2014、インターネット<URL:http://www.ietf.org/id/draft-ietf-httpbis-header-compression-00.txt>
しかしながら、上記のHTTPヘッダ圧縮機能は、HTTP通信を開始する度に、HTTPヘッダテーブルを新規に作成していた。そのため、サーバ・クライアントとも、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延が増大するという課題があった。
本発明は上記課題に鑑み、メッセージヘッダの圧縮機能において参照するテーブルを通信装置間の接続状況に応じて選択することでテーブルの再利用を可能とし、テーブルの新規作成を軽減することを目的とする。
上記の目的を達成するための一手段として、本発明に係る通信装置は以下の構成を備える。すなわち、他の通信装置に送信するメッセージヘッダを圧縮用のテーブルを参照して圧縮する圧縮手段と、他の通信装置に送信するメッセージヘッダまたは他の通信装置から受信したメッセージヘッダに基づいて前記テーブルを更新する更新手段と、他の通信装置とのネットワークを介した接続状況を判断する判断手段と、を有し、前記圧縮手段は、前記判断手段で接続中であると判断された他の通信装置については、当該通信装置に対応する前記テーブルを参照することを特徴とする。
本発明によれば、メッセージヘッドの圧縮機能において参照するテーブルを通信装置間の接続状況に応じて選択することでテーブルの再利用を可能とし、テーブルの新規作成を軽減することができる。
第1実施形態に係る通信システムおよび第1の通信装置の構成例を示す図、 第1の通信装置の機能モジュール構成例を示すブロック図、 第1の通信装置が、第2の通信装置との通信接続から通信切断までのメッセージ例を示すシーケンス図、 第1の通信装置によるHTTP通信の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTP通信接続の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTPリクエストの送信、及びHTTPレスポンスの受信の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTP通信切断、無線LAN通信接続および切断の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTPヘッダテーブルの選択、該選択したHTTPヘッダテーブルの確認および通知の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTPヘッダテーブル削除の際のメッセージ例を示すシーケンス図、 第1の通信装置によるHTTPヘッダテーブル選択の動作手順を示すフローチャート、 第1の通信装置による通信関係判断の動作手順を示すフローチャート、 第1の通信装置による、HTTPヘッダテーブルの確認および通知の動作手順、および第2の通信装置によるHTTPヘッダ選択通知を受信する動作手順を示すフローチャート、 第1の通信装置によるHTTPリクエスト送信、およびHTTPレスポンス受信の動作手順を示すフローチャート、 第2の通信装置によるHTTPリクエスト受信、およびHTTPレスポンス送信の動作手順を示すフローチャート、 第1の通信装置によるHTTPヘッダテーブルの記憶または削除の動作手順を示すフローチャート、 第1の通信装置による通信イベント検知の動作手順を示すフローチャート、 第2実施形態に係る第1の通信装置による通信接続から通信切断までのメッセージの例を示すシーケンス図、 第2実施形態に係る第1の通信装置による通信関係判断、および通信イベント検知の動作手順を示すフローチャート、 第3実施形態に係る通信システムの構成例、および第1の通信装置によるネットワーク参加/離脱時のメッセージ例を示すシーケンス図、 第3実施形態に係る第1の通信装置による通信関係判断、および通信イベント検知の動作手順を示すフローチャート、 第4実施形態に係る第1の通信装置による通信関係判断の動作手順を示すフローチャート、 第5実施形態に係る第1の通信装置によるHTTPヘッダテーブル選択の動作手順を示すフローチャート、 第5実施形態に係る第1の通信装置による通信関係判断の動作手順を示すフローチャート、 HTTPヘッダテーブルの具体例を示す図、 第5実施形態に係る固有HTTPヘッダテーブルの具体例を示す図、である。
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
<第1実施形態>
●システム構成
図1(a)は、本実施形態に係る通信システムの構成例を示す図である。
第1の通信装置10は、本発明におけるクライアントとしての通信装置であり、IEEE802.11に則った無線LAN(Local Area Network)通信機能を有する。第1の通信装置10の具体例としては、デジタルカメラ、デジタルビデオカメラ、携帯電話、スマートフォン、PC、ノートPC、サーバ、などである。なお本実施形態では無線LAN通信機能を用いる例を示すが、これに限らず、Bluetooth(登録商標)、ZigBee(登録商標)、RFID、などの他の無線LAN通信機能を利用しても良い。また、Ethernet(登録商標)などの有線LAN通信機能、または無線LAN通信機能と有線LAN通信機能の組合せを利用しても良い。
第2の通信装置20は、本発明におけるサーバとしての通信装置であり、第1の通信装置10と直接無線LAN接続を行う。なお本実施形態では、第1の通信装置10と第2の通信装置20とが直接無線LAN接続を行う例を示すが、これに限らず、無線アクセスポイントを経由して接続しても良い。第1の通信装置10と第2の通信装置20とが、HTTP/2.0規格に則ったHTTP通信を行う。
次に、本実施形態に係る通信装置の構成要素を詳細に説明する。図1(b)は、本実施形態に係る第1の通信装置10のハードウェア構成例を示すブロック図である。なお、第2の通信装置20も第1の通信装置10と同じ構成であるため、ここでは第1の通信装置10のみについて説明する。第1の通信装置10は、CPU(Central Processing Unit)201、ROM(Read Only Memory)202、RAM(Random Access Memory)203、補助記憶装置204、を備える。第1の通信装置10はさらに、表示部205、操作部206、通信部207、アンテナ208、を備える。CPU201は、第1の通信装置10の全体を制御する。ROM202は、変更を必要としないプログラムやパラメータを格納する。RAM203は、補助記憶装置204などから供給されるプログラムやデータを一時記憶する。補助記憶装置204は、画像コンテンツや映像コンテンツなどのデータを記憶する。表示部205は、ユーザが第1の通信装置10を操作するためのGUI(Graphical User Interface)を表示する。操作部206は、ユーザが第1の通信装置10を操作するための入力インタフェースである。通信部207は、アンテナ208を制御し、無線アクセスポイント30、または第2の通信装置20との無線LAN通信を行う。
●機能モジュール構成
図2は、本実施形態に係る第1の通信装置10の機能モジュール構成例を示すブロック図である。なお、第2の通信装置20も第1の通信装置10と同じ構成であるため、ここでは第1の通信装置10のみについて説明する。
制御部301は、第1の通信装置10が備える個々の機能モジュール全体を制御する。無線LAN通信制御部302は通信部207を制御し、無線アクセスポイント(不図示)、または第2の通信装置20との無線LAN通信方式の通信制御を行う。表示制御部303は表示部205を制御し、第1の通信装置10におけるGUIの表示制御を行う。操作制御部304は操作部206を制御し、第1の通信装置10におけるユーザからの操作入力制御を行う。記憶制御部305はRAM203または補助記憶装置204を制御し、処理データ、または画像コンテンツや映像コンテンツなどのデータを記憶または削除する。
TCP/IP通信制御部306は、無線LAN通信制御部302を利用して、第2の通信装置20との間でTCP(Transmission Control Protocol)/IP(Internet Protocol)方式の通信制御を行う。なお本実施形態ではTCP/IP通信を利用する例を示すが、これに限らず、UDP(User Datagram Protocol)を利用しても良い。
HTTP通信制御部307は、TCP/IP通信制御部306を利用して、第2の通信装置20との間でHTTP/2.0方式の通信制御を行う。また、HTTP通信制御部307は、第2の通信装置20との間でTLS(Transport Layer Security)を利用したHTTP(HTTP Security)方式の通信制御も行う。
ディスカバリ制御部308は、TCP/IP通信制御部306またはHTTP通信制御部307を利用して、無線LAN上の通信装置のディスカバリ(発見)制御を行う。具体的にはディスカバリ制御部308は、無線LAN上の第2の通信装置20を発見する機能を備える。また、ディスカバリ制御部308は、無線LAN上の第2の通信装置20に、第1の通信装置10の参加または離脱を通知する機能を備える。本実施形態においてディスカバリ制御部308は、UPnP(Universal Plug and Play)規格にて利用されているSSDP(Simple Service Discovery Protocol)方式を利用する。なおディスカバリ制御部308はSSDPに限らず、他のディスカバリ方式を利用しても良い。他のディスカバリ方式としては例えば、mDNS(multicast Domain Name Service)、Bonjour(登録商標)、SDP(Service Discovery Protocol)、などが挙げられる。
認証・認可制御部309は、HTTP通信制御部307を利用して、第2の通信装置20との間でユーザや第1の通信装置10に関する認証・認可処理を制御する。本実施形態において認証・認可制御部309は、HTTP認証(Basic認証・Digest認証)方式を利用する。なお、認証・認可制御部309は、OAuth 2.0、OpenID、OpenID Connect、SAML(Security Assertion Markup Language)など他の認証・認可方式を利用しても良い。
サービス制御部310は、HTTP通信制御部307を利用して、第2の通信装置20に対するサービスの提供、または第2の通信装置20が提供するサービスの利用を制御する。

本実施形態においてサービス制御部310は、DLNA(Digital Living Network Alliance)、UPnP、及びWebサービス方式のそれぞれを利用する。
なおサービス制御部310ではこの例に限らず、他のサービス制御方式を利用しても良い。
例えば、SOAP(Simple Object Access Protocol)、REST(Representational State Transfer)、AtomPub(Atom Publishing Protocol)、等がある。
●通信関係判断
次に、第2の通信装置20との通信関係の有無の判断に関するモジュールを説明する。通信関係判断部311は、後述する通信状態判断部312、通信履歴判断部313、通信方式判断部314、のいずれか、または複数を利用して、第2の通信装置20とのネットワークを介した接続状況としての通信関係の有無を判断する。
通信状態判断部312は、第2の通信装置20との通信状態に基づき、第2の通信装置20との通信関係の有無を判断する。この判断は、以下のような通信状態に基づいて行われる。
まず、無線LAN通信制御部302を利用して、第2の通信装置20との無線LAN通信状態に基づき、通信関係の有無を判断する。例えば、無線LAN(Wi-Fi)接続の開始・終了、無線LAN通信時の認証完了、ビーコンの検出・不検出、無線LAN接続形態(インフラモード、アドホックモード)、等に基づき判断する。その他、Wi-Fi Direct接続の開始・終了、無線LAN通信エラー、等に基づき判断してもよい。
また、TCP/IP通信制御部306を利用して、第2の通信装置20とのTCP/IP通信状態に基づき、通信関係の有無を判断する。例えば、TCP接続・切断、誤り発生状態、遅延状態、パケット再送状態、データ転送量、フロー制御状態、回線品質、TCP/IP通信エラー、等に基づき判断する。
また、HTTP通信制御部307を利用して、第2の通信装置20とのHTTP通信状態に基づき、通信関係の有無を判断する。例えば、HTTP通信の開始(HEADERS+PRIORITYフレーム)・終了(GOAWAYフレーム)、同時HTTP通信数(マルチセッション数)、HTTP通信エラー、等に基づき判断する。
また、ディスカバリ制御部308を利用して、第2の通信装置20との無線LAN上のディスカバリ状態に基づき、通信関係の有無を判断する。例えば、第1の通信装置10の無線LANへの参加・離脱、第2の通信装置20の無線LAN上の発見・参加・離脱、等に基づき判断する。
また、認証・認可制御部309を利用して、第2の通信装置20との認証・認可状態に基づき、通信関係の有無を判断する。例えば、認証・認可の開始・終了、ユーザのログイン・ログアウト、認証済・未認証、認可承認済・未承認、認証有効期限内・期限切れ、アクセストークン有効・無効、アクセストークン有効期限内・期限切れ、等に基づき判断する。
また、サービス制御部310を利用して、第2の通信装置20とのサービス提供・利用状態に基づき、通信関係の有無を判断する。例えば、サービス提供の開始・終了、サービス利用の開始・終了、等に基づき判断する。
通信状態判断部312はまた、上記の複数の通信状態の組み合わせに基づいて、通信関係の有無を判断しても良い。
通信履歴判断部313は、第2の通信装置20との通信履歴に基づき、第2の通信装置20との通信関係の有無を判断する。この判断は、以下のような通信履歴に基づいて行われる。
まず、無線LAN通信制御部302を利用して、第2の通信装置20との無線LAN通信履歴に基づき、通信関係の有無を判断する。例えば、第2の通信装置20とのこれまでの無線LAN接続・切断の有無、接続形態(インフラ・アドホック、Wi-Fi Direct、Wi-Fi Directの永続的・一時的グループ)、等に基づき判断する。
また、TCP/IP通信制御部306を利用して、第2の通信装置20とのTCP/IP通信履歴に基づき、通信関係の有無を判断する。例えば、第2の通信装置20のドメイン名、ホスト名、IPアドレス、ポート番号、第2の通信装置20とのこれまでのTCP/IP接続・切断の有無、等に基づき判断する。
また、HTTP通信制御部307を利用して、第2の通信装置20とのHTTP通信履歴に基づき、通信関係の有無を判断する。例えば、第2の通信装置20のURI、送信したHTTPリクエストの内容、受信したHTTPレスポンスの内容、HTTP通信(セッション)ID、HTTPストリームID、Cookie、等に基づき判断する。
また、ディスカバリ制御部308を利用して、第2の通信装置20との無線LAN上のディスカバリ履歴に基づき、通信関係の有無を判断する。例えば、第1の通信装置10の無線LANへの参加・離脱の有無・回数・日時、第2の通信装置20の無線LAN上の発見・参加・離脱の有無・回数・日時、等に基づき判断する。
また、認証・認可制御部309を利用して、第2の通信装置20との認証・認可履歴に基づき、通信関係の有無を判断する。例えば、認証・認可・ログイン・ログアウトの有無・回数・日時、ID・パスワード等の認証情報・認可情報、承認した回数、等に基づき判断する。それ以外にも、発行したアクセストークンのID・権限範囲・数・有効期間、無効にしたアクセストークン、等に基づき判断してもよい。
また、サービス制御部310を利用して、第2の通信装置20とのサービス提供・利用履歴に基づき、通信関係の有無を判断する。例えば、提供・利用したサービスの種別・内容、サービス提供・利用の有無、などを判断する。
また、上記の通信種別に関わらず、第2の通信装置20とのこれまでの通信接続・切断の有無、通信回数、通信日時、通信成功・失敗、エラー種別、などを判断する。
通信履歴判断部313はまた、上記の複数の通信履歴の組み合わせに基づいて、通信関係の有無を判断しても良い。
通信方式判断部314は、第2の通信装置20との通信方式に基づき、第2の通信装置20との通信関係の有無を判断する。この判断は、以下のような通信方式に基づいて行われる。
まず、無線LAN通信制御部302を利用して、第2の通信装置20との無線LAN通信方式に基づき、通信関係の有無を判断する。例えば、第2の通信装置20との無線ダイレクト通信の有無、WPS(Wi-Fi Protected Setup)通信の有無、等に基づき判断する。それ以外にも、Wi-Fi Direct通信の有無、Wi-Fi Direct Service通信の有無、Wi-Fi Miracast通信の有無、等に基づき判断しても良い。
また、TCP/IP通信制御部306を利用して、第2の通信装置20とのTCP/IP通信方式に基づき、通信関係の有無を判断する。例えば、VPN(Virtual Private Network)通信の有無、IPsec(Security Architecuture for Internet Protocol)通信の有無、等に基づき判断する。
また、HTTP通信制御部307を利用して、第2の通信装置20とのHTTP通信方式に基づき、通信関係の有無を判断する。例えば、HTTPS(TLS)通信の有無、PROXY通信の有無、等に基づき判断する。
また、ディスカバリ制御部308を利用して、第2の通信装置20との無線LAN上のディスカバリ方式に基づき、通信関係の有無を判断する。例えば、SSDPの有無、mDNSの有無、Bonjourの有無、SDPの有無、等に基づき判断する。
また、認証・認可制御部309を利用して、第2の通信装置20との認証・認可方式に基づき、通信関係の有無を判断する。例えば、HTTP認証(Basic認証、Digest認証)の有無、OAuth 2.0の有無、OpenIDの有無、OpenID Connectの有無、SAMLの有無、等に基づき判断する。
また、サービス制御部310を利用して、第2の通信装置20とのサービス提供・利用方式に基づき、通信関係の有無を判断する。例えば、DLNAの有無、UPnPの有無、SOAPの有無、RESTの有無、AtomPubの有無、等に基づき判断する。
通信履歴判断部313はまた、上記の複数の通信方式の組み合わせに基づいて、通信関係の有無を判断しても良い。
●HTTPヘッダ圧縮
次に、HTTPヘッダ圧縮に関するモジュールを説明する。HTTPヘッダ圧縮部315は、後述するHTTPヘッダテーブル選択部320が選択したHTTPヘッダテーブルに基づいて、HTTP/2.0方式におけるHTTPヘッダ圧縮処理を行う。クライアントである第1の通信装置10において、HTTPヘッダ圧縮部315は、HTTP通信制御部307が生成したHTTPリクエストメッセージ中のメッセージヘッダであるHTTPヘッダを圧縮する。同様に、第1の通信装置10のHTTPヘッダ圧縮部315は、HTTP通信制御部307が第2の通信装置20から受信したHTTPレスポンスメッセージ中の圧縮されたHTTPヘッダを展開する。一方、サーバである第2の通信装置20において、HTTPヘッダ圧縮部315は、HTTP通信制御部307が生成したHTTPレスポンスメッセージ中のHTTPヘッダを圧縮する。同様に、第2の通信装置20のHTTPヘッダ圧縮部315は、HTTP通信制御部307が第2の通信装置10から受信したHTTPリクエストメッセージ中の圧縮されたHTTPヘッダを展開する。
HTTPヘッダテーブル生成部316は、HTTP/2.0方式において規定された初期のHTTPヘッダテーブルを作成する。本実施形態における初期のHTTPヘッダテーブルの具体例については、図24(a)を用いて後述する。
HTTPヘッダテーブル更新部317は、HTTP通信制御部307及びHTTPヘッダ圧縮部315において送信及び圧縮したHTTPリクエストヘッダに基づいて、HTTPヘッダテーブル(リクエストヘッダテーブル)を更新する。同様に、HTTP通信制御部307及びHTTPヘッダ圧縮部315において受信及び展開したHTTPレスポンスヘッダに基づいて、HTTPヘッダテーブル(レスポンスヘッダテーブル)を更新する。
HTTPヘッダテーブル記憶部318は、記憶制御部305を利用してHTTPヘッダテーブルを記憶する。本実施形態では、HTTPヘッダテーブル生成部316で生成され、第2の通信装置20とのHTTP通信にて利用したHTTPヘッダテーブルや、HTTPヘッダテーブル受信部323により受信したHTTPヘッダテーブルを記憶する。なお、HTTPヘッダテーブル選択部320には、例えば当該第2の通信装置20とは異なる他の通信装置との通信に係るヘッダテーブルも保持可能である。
HTTPヘッダテーブル削除部319は、記憶制御部305を利用してHTTPヘッダテーブルを削除する。本実施形態では、第2の通信装置20とのHTTP通信にて利用したHTTPヘッダテーブルや、HTTPヘッダテーブル記憶部318に記憶されたHTTPヘッダテーブルを削除する。
HTTPヘッダテーブル選択部320は、通信関係判断部311を利用して、HTTPヘッダ圧縮部315で利用するHTTPヘッダテーブルを選択する。例えば、第2の通信装置20との通信関係が有ると判断された場合、第2の通信装置20との通信関係に対応したHTTPヘッダテーブルを選択する。一方、該通信関係が無いと判断された場合、HTTPヘッダテーブル生成部316により生成された初期のHTTPヘッダテーブルを選択する。なおHTTPヘッダテーブル選択部320では、HTTPヘッダテーブル記憶部318からの選択を行う。
HTTPヘッダテーブル確認部321は、HTTP通信制御部307を利用して、第1の通信装置10が保持するHTTPヘッダテーブルと同じHTTPヘッダテーブルを、第2の通信装置20が保持しているか否かを確認する。この確認は、HTTPヘッダテーブルのデータに基づき算出されるCRC(Cyclic Redundancy Check)が同じであるか否かに基づき判断する。なお、HTTPヘッダテーブルの確認方法はこれに限らず、HTTPヘッダテーブル受信部323を利用して第2の通信装置20からHTTPヘッダテーブルのデータを受信して、データが同じであるか否かを判断しても良い。なお、第2の通信装置20が同じHTTPヘッダテーブルを保持しているか否かが判断できれば、他のどのような方法を用いても良く、後述する固有HTTPヘッダテーブル管理部324を利用して判断してもよい。
HTTPヘッダテーブル送信部322は、TCP/IP通信制御部306またはHTTP通信制御部307を利用して、第2の通信装置20にHTTPヘッダテーブルを送信する。HTTPヘッダテーブル受信部323は、TCP/IP通信制御部306またはHTTP通信制御部307を利用して、第2の通信装置20からHTTPヘッダテーブルを受信する。
固有HTTPヘッダテーブル管理部324は、記憶制御部305を利用して、第1の通信装置10が対応している通信方式に対応した固有HTTPヘッダテーブルを管理する。固有HTTPヘッダテーブルは、所定の通信方式に最適化されたHTTPヘッダテーブルであり、所定の通信方式で利用される所定のHTTPヘッダ名、及びHTTPヘッダ値が、予めHTTPヘッダテーブルに設定される。なお、固有HTTPヘッダテーブル管理部324は、第1の通信装置10が対応している複数の通信方式に対応した複数の固有HTTPヘッダテーブルを管理しても良い。
ここで図24(a)に、本実施形態に係るHTTPヘッダテーブルの具体的なデータ構成例を示す。図24(a)においてHTTPヘッダテーブル3400は、HTTPリクエストのヘッダ圧縮に利用するHTTPリクエストヘッダテーブル3410と、HTTPレスポンスのヘッダ圧縮に利用するHTTPレスポンスヘッダテーブル3420から構成される。HTTPリクエストヘッダテーブル3410は、該テーブル中の番号を示すインデックス3411、HTTPリクエストヘッダ名3412、HTTPリクエストヘッダ値3413、から構成される。HTTPレスポンスヘッダテーブル3420も、HTTPリクエストヘッダテーブル3410と同様に、該テーブル中の番号を示すインデックス3421、HTTPレスポンスヘッダ名3422、HTTPレスポンスヘッダ値3423、から構成される。
なお、本実施形態ではHTTPヘッダテーブル3400が、HTTPリクエストヘッダテーブル3410とレスポンスヘッダテーブル3420の2つのテーブルから構成される例を示したが、これらが1つのテーブルとして一元管理することも可能である。
●通信シーケンス
以下、本実施形態における第1の通信装置10と第2の通信装置20との間における通信シーケンスについて、詳細に説明する。
●通信接続から切断(メインストリーム)
図3は、第1の通信装置10が、第2の通信装置20との通信接続から通信切断までを行う際のメッセージの例を示すシーケンス図である。本実施形態において、第1の通信装置10は、第2の通信装置20との無線LAN通信の通信状態に基づいて通信関係を判断する。
まずM501で第1の通信装置10が第2の通信装置20と無線LAN通信接続を行う。この通信接続の詳細なシーケンスについては、図7(b)を用いて後述する。
M502で第1の通信装置10が、第2の通信装置20との間で利用するHTTPヘッダテーブルを選択する。このテーブル選択の詳細なシーケンスについては、図8(a)を用いて後述する。M502では第1の通信装置10が、第2の通信装置20との通信関係が有と判断するが、第2の通信装置20とのHTTP通信を未だ実施していないため、ここではHTTPヘッダテーブルを新規に作成する。
M503で第1の通信装置10が、M502で選択したHTTPヘッダテーブルを利用して第2の通信装置20との間でHTTP通信を行う。このHTTP通信に係る詳細なシーケンスについては、図4を用いて後述する。M503ではHTTP通信接続、HTTPリクエスト送信・レスポンス受信、HTTP通信切断、の一連の処理を行う。
M504で第1の通信装置10が、M503でのHTTP通信切断を受けて、第2の通信装置20との間で利用したHTTPヘッダテーブルを削除するか否かを判断する。このテーブル削除の詳細なシーケンスについては、図9を用いて後述する。M504では第1の通信装置10が、第2の通信装置20との通信関係が有と判断し、第2の通信装置20との間で利用したHTTPヘッダテーブルを記憶する。さらに第2の通信装置20も、第1の通信装置10との通信関係が有と判断し、第1の通信装置10との間で利用したHTTPヘッダテーブルを記憶する。
M505で第1の通信装置10が、第2の通信装置20との間で利用するHTTPヘッダテーブルを選択する。このテーブル選択の詳細なシーケンスについては、図8(a)を用いて後述する。M505では第1の通信装置10が、第2の通信装置20との通信関係が有と判断し、かつM503で第2の通信装置20との間で利用したHTTPヘッダテーブルが存在するため、このHTTPヘッダテーブルを選択する。
M506で第1の通信装置10が、M505で選択したHTTPヘッダテーブルを利用して、第2の通信装置20との間でHTTP通信を行う。このHTTP通信に係る詳細なシーケンスはM503と同様に、図4に示す。
M507で第1の通信装置10が、M506でのHTTP通信切断を受けて、第2の通信装置20との間で利用したHTTPヘッダテーブルの削除を判断する。このテーブル削除のシーケンスはM504と同様に、図9に示す。M507で第1の通信装置10は、第2の通信装置20との通信関係が有と判断し、第2の通信装置20との間で利用したHTTPヘッダテーブルを記憶する。さらに第2の通信装置20も、第1の通信装置10との通信関係が有と判断し、第1の通信装置10との間で利用したHTTPヘッダテーブルを記憶する。
M508で第1の通信装置10が、第2の通信装置20との無線LAN通信切断を行う。この通信切断に係る詳細なシーケンスについては、図7(c)を用いて後述する。
M509で第1の通信装置10が、M508での無線LAN通信切断を受けて、第2の通信装置20との間で利用したHTTPヘッダテーブルの削除を判断する。このテーブル削除のシーケンスはM504と同様に、図9に示す。M509で第1の通信装置10は、第2の通信装置20との通信関係が無いと判断し、第2の通信装置20との間で利用したHTTPヘッダテーブルを削除する。さらに第2の通信装置20も、第1の通信装置10との通信関係が無いと判断し、第1の通信装置10との間で利用したHTTPヘッダテーブルを削除する。
●HTTP通信シーケンス(M503,M506)
図4は、本実施形態に係る第1の通信装置10が、第2の通信装置20とHTTP通信を行う際のメッセージの例を示すシーケンス図であり、上記M503、M506の詳細を示すものである。
まずM601で第1の通信装置10が第2の通信装置20とHTTP通信接続を行う。この通信接続の詳細なシーケンスについては、図5を用いて後述する。
M602で第1の通信装置1が、第2の通信装置20との間で、HTTPリクエストの送信、及びHTTPレスポンスの受信を行う。このHTTPリクエスト・レスポンスの詳細なシーケンスについては、図6を用いて後述する。
M603で第1の通信装置10が、第2の通信装置20とのHTTP通信切断を行う。この通信切断の詳細なシーケンスについては、図7(a)を用いて後述する。
●HTTP通信接続シーケンス(M601)
図5は、第1の通信装置10が第2の通信装置20とHTTP通信接続を行う際のメッセージの例を示すシーケンス図であり、上記M601の詳細を示すものである。
まずM701(M702〜M704)で第1の通信装置10が第2の通信装置20とTCP通信接続を行う。詳細には、M702で第1の通信装置10が第2の通信装置20にTCP接続要求(SYNフレーム)を送信する。そしてM703で第2の通信装置20が第1の通信装置10にTCP接続要求応答(SYN/ACKフレーム)を送信する。そしてM704で第1の通信装置10が第2の通信装置20に応答(ACKフレーム)を送信する。
次にM705(M706〜M715)で第1の通信装置10が、第2の通信装置20とTLS通信接続を行う。詳細には、M706で第1の通信装置10が、第2の通信装置20に利用可能な暗号化、圧縮アルゴリズムの一覧を送信する(Client Hello)。M707で第2の通信装置20が、第1の通信装置10に決定した暗号化、圧縮アルゴリズムを送信する(Server Hello)。M708で第2の通信装置20が、第1の通信装置10にルート証明書、サーバ証明書を送信する(Server Certificate)。M709で第2の通信装置20が、第1の通信装置10にサーバ鍵情報を送信する(Server Key Exchange)。M710で第2の通信装置20が、第1の通信装置10に一連の処理の完了を送信する(Server Hello Done)。そして、M711で第1の通信装置10が、第2の通信装置20に鍵情報(プリマスターシークレット)を送信する(Client Key Exchange)。M712で第1の通信装置10が、第2の通信装置20に暗号化アルゴリズムの準備完了を送信する(Change Cipher Spec)。M713で第1の通信装置10が、第2の通信装置20に鍵交換と認証処理の完了を送信する(Finished)。M714で第2の通信装置20が、第1の通信装置10に暗号化アルゴリズムの準備完了を送信する(Change Cipher Spec)。M715で第2の通信装置20が、第1の通信装置10に鍵交換と認証処理の成功を送信する(Finished)。
●HTTPリクエスト・レスポンスシーケンス(M602)
図6は、第1の通信装置10が第2の通信装置20とHTTPリクエストの送信、及びHTTPレスポンスの受信を行う際のメッセージの例を示すシーケンス図であり、上記M602の詳細を示すものである。
まずM801で第1の通信装置10が、第2の通信装置20に送信するHTTPリクエストを作成する。この際、第1の通信装置10はHTTPリクエストヘッダテーブルを利用してHTTPリクエストヘッダを圧縮する。このHTTPリクエストヘッダのうち、HTTPリクエストヘッダテーブルの記載に対応する部分については圧縮されるが、該テーブルに記載されていない新規部分については、圧縮されずにヘッダに追加される。
次にM802で第1の通信装置10が、M801で作成したHTTPリクエストヘッダに基づき、HTTPリクエストヘッダテーブルを更新する。すなわち、M801でHTTPリクエストヘッダを作成する際に、圧縮できない新規部分があれば、その対応分をHTTPリクエストヘッダテーブルに追加する。
次にM803(M804〜M806)で第1の通信装置10が第2の通信装置20にHTTP/2.0方式によるHTTPリクエストを送信する。詳細には、M804で第1の通信装置10が第2の通信装置20にHTTPリクエストライン、及びHTTPリクエストヘッダを示すHEADERS+PRIORITYフレームを送信する。そしてM805〜M806で第1の通信装置10が第2の通信装置20にHTTPリクエストボディを示すDATAフレームを送信する。このとき第1の通信装置10は、最終のDATAフレーム(この例ではM806)にFINALフラグを付与する。
そしてM807(M808)で第2の通信装置20が、第1の通信装置10に対するHTTPヘッダテーブルが存在しない場合に、M808でHTTPヘッダテーブルを新規に作成する。
そしてM809では第2の通信装置20が第1の通信装置10から受信したHTTPリクエスト中のHTTPリクエストヘッダに基づき、新規部分があればHTTPリクエストヘッダテーブルを更新する。
そしてM810で第2の通信装置20が、第1の通信装置10に送信するHTTPレスポンスを作成する。この際、第2の通信装置20はHTTPレスポンスヘッダテーブルを利用してHTTPレスポンスヘッダを圧縮する。そしてM811で第2の通信装置20が、M810で作成したHTTPレスポンスヘッダに基づき、HTTPレスポンスヘッダテーブルを更新する。このHTTPレスポンスヘッダについても、上記M801,M802で説明したHTTPリクエストヘッダの場合と同様に、新規部分については圧縮されず、該圧縮されない内容に応じてHTTPレスポンスヘッダテーブルが更新される。
次にM812(M813〜M815)で第2の通信装置20が、第1の通信装置10にHTTP/2.0方式によるHTTPレスポンスを送信する。詳細には、M813で第2の通信装置20が第1の通信装置10にHTTPステータスライン、及びHTTPレスポンスヘッダを示すHEADERSフレームを送信する。そしてM814〜M815で第2の通信装置20が、第1の通信装置10にHTTPレスポンスボディを示すDATAフレームを送信するが、最終のDATAフレーム(この例ではM815)にはFINALフラグを付与する。
次にM816で第1の通信装置10が、第2の通信装置20から受信したHTTPレスポンス中のHTTPレスポンスヘッダに基づき、新規部分があればHTTPレスポンスヘッダテーブルを更新する。
●HTTP通信切断シーケンス(M603)
図7(a)は、第1の通信装置10が第2の通信装置20とHTTP通信切断を行う際のメッセージの例を示すシーケンス図であり、上記M603の詳細を示すものである。
まずM901で第1の通信装置10が、第2の通信装置20にHTTP/2.0におけるGOAWAYフレームを送信する。次にM902(M903〜M905)で第1の通信装置10が、第2の通信装置20とTCP通信切断を行う。詳細には、M903で第1の通信装置10が、第2の通信装置20にTCP切断要求(FINフレーム)を送信する。そしてM904で第2の通信装置20が、第1の通信装置10にTCP切断要求応答(FIN/ACKフレーム)を送信する。そしてM905で第1の通信装置10が、第2の通信装置20に応答(ACKフレーム)を送信する。
●無線LAN通信接続シーケンス(M501)
図7(b)は、第1の通信装置10が第2の通信装置20と無線LAN通信接続を行う際のメッセージの例を示すシーケンス図であり、上記M501の詳細を示すものである。
まずM1001で第1の通信装置10が、ユーザによる無線LAN通信接続指示を検知する。ここで、ユーザによる無線LAN通信接続指示は例えば、WPSのプッシュボタン押として発生するが、これに限らず、Wi-Fi Direct接続指示など他の無線LAN通信接続指示であっても良い。
次にM1002で第2の通信装置20が、第1の通信装置10に対して、ユーザによる無線LAN通信接続指示を検知する。この検知方法はM1001と同様である。
次にM1003で第1の通信装置10が、第2の通信装置20の無線LAN通信を発見し、M1004で第1の通信装置10が、第2の通信装置20との間で無線パラメータの交換を行う。そしてM1005で第1の通信装置10が、第2の通信装置20との間に無線LAN通信接続を確立する。
●無線LAN通信切断シーケンス(M508)
図7(c)は、第1の通信装置10が第2の通信装置20との無線LAN通信切断を行う際のメッセージの例を示すシーケンス図であり、上記M508の詳細を示すものである。
まずM1101で第1の通信装置10が、ユーザによる無線LAN通信切断指示を検知する。そしてM1102で第1の通信装置10が、第2の通信装置20に無線LAN通信切断要求を送信し、M1103で第2の通信装置20が、第1の通信装置10に無線LAN通信切断応答を送信する。
●HTTPヘッダテーブル選択シーケンス(M502,M505)
図8(a)は、第1の通信装置10が第2の通信装置20との間でHTTPヘッダテーブルを選択する際のメッセージの例を示すシーケンス図であり、上記M502,M505の詳細を示すものである。
まずM1201で第1の通信装置10が、第2の通信装置20との通信関係を判断する。
M1201により、第2の通信装置20との通信関係が有り、かつ第2の通信装置20に対するHTTPヘッダテーブルが存在すると判断された場合、M1202(M1203〜M1204)の処理を行う。すなわち、M1203で第1の通信装置10が、第2の通信装置20との通信関係に対応するHTTPヘッダテーブルを選択する。そしてM1204で第1の通信装置10が、第2の通信装置20との間で選択したHTTPヘッダテーブルの確認、及び通知を行う。このHTTPヘッダテーブルの確認・通知の詳細については、図8(b)を用いて後述する。
またM1201により、第1の通信装置10と第2の通信装置20との通信関係が無い、または第2の通信装置20に対するHTTPヘッダテーブルが存在しないと判断された場合、M1205(M1206)で初期テーブルを生成する。すなわちM1206で第1の通信装置10が、HTTP/2.0方式において規定された初期のHTTPヘッダテーブルを新規に作成する。
●HTTPヘッダテーブル確認・通知シーケンス(M1204)
図8(b)は、第1の通信装置10が第2の通信装置20との間で選択したHTTPヘッダテーブルを確認、及び通知する際のメッセージの例を示すシーケンス図であり、上記M1204の詳細を示すものである。
まずM1301で第1の通信装置10が、第2の通信装置20に対してHTTPヘッダテーブル情報取得要求を送信し、M1302で第2の通信装置20が、第1の通信装置10に対してHTTPヘッダテーブル情報を送信する。そしてM1303で第1の通信装置10が、M1302で取得したHTTPヘッダテーブル情報に基づき、選択したHTTPヘッダテーブルが一致するか確認する。つまり、第1の通信装置10で選択したHTTPヘッダテーブルと同一のHTTPヘッダテーブルを、第2の通信装置20が保持しているかを確認する。
そしてM1304で第1の通信装置10が、第2の通信装置20に、選択したHTTPヘッダテーブルを通知する。するとM1305で第2の通信装置20が、第1の通信装置10から通知されたHTTPヘッダテーブルを選択し、M1306で第2の通信装置20が、第1の通信装置10に、該選択したHTTPヘッダテーブルの通知応答を送信する。
●HTTPヘッダテーブル削除シーケンス(M504,M507,M509)
図9は、第1の通信装置10が第2の通信装置20との間で利用したHTTPヘッダテーブルを削除する際のメッセージの例を示すシーケンス図であり、上記M504,M507,M509の詳細を示すものである。
まずM1401で第1の通信装置10が、第2の通信装置20との通信イベントを検知する。ここでの通信イベントとは例えば、HTTP通信切断、無線LAN通信切断、などである。
そしてM1402で第1の通信装置10が、第2の通信装置20との通信関係を判断する。M1402により、第2の通信装置20との通信関係が有ると判断された場合、M1403(M1404)の処理を行う。すなわち、M1404で第1の通信装置10が、第2の通信装置20とのHTTP通信で利用したHTTPヘッダテーブルを記憶する。一方、M1402により第2の通信装置20との通信関係が無い、と判断された場合、M1405(M1406)の処理を行う。すなわち、M1406で第1の通信装置10が、第2の通信装置20とのHTTP通信で利用したHTTPヘッダテーブルを削除する。
次にM1407で第2の通信装置20が、第1の通信装置10との通信イベントを検知する。ここでの通信イベントも例えば、HTTP通信切断、無線LAN通信切断、などである。
そしてM1408で第2の通信装置20が、第1の通信装置10との通信関係を判断する。M1408により、第1の通信装置10との通信関係が有ると判断された場合、M1409(M1410)の処理を行う。すなわち、M1410で第2の通信装置20が、第1の通信装置10とのHTTP通信で利用したHTTPヘッダテーブルを記憶する。一方、M1408により第1の通信装置10との通信関係が無いと判断された場合、M1411(M1412)の処理を行う。すなわち、M1412で第2の通信装置20が、第1の通信装置10とのHTTP通信で利用したHTTPヘッダテーブルを削除する。
●通信処理
以下、本実施形態における第1の通信装置10と第2の通信装置20との間の通信処理について、図2に示す機能モジュール構成を用いて詳細に説明する。
●HTTPヘッダテーブル選択処理
図10は、第1の通信装置10が第2の通信装置20との間でHTTPヘッダテーブルを選択する動作手順を示すフローチャートである。
まずS1501でHTTPヘッダテーブル選択部320が、HTTP通信制御部307を利用して、通信対象となる装置(以下、対象装置)を特定する。ここでの対象装置は第2の通信装置20である。次にS1502で通信関係判断部311が、対象装置との接続状況としての通信関係の有無を判断する。この判断処理の詳細については図11を用いて後述する。
対象装置との通信関係が有ると判断された場合(S1503;YES)はS1504に進むが、通信関係が無いと判断された場合(S1503;NO)はS1509に進む。ここで通信関係が無いとはすなわち、対象装置とのHTTP通信接続が未だなされていない旨を示す。
S1504でHTTPヘッダテーブル選択部320が、HTTPヘッダテーブル記憶部318に対象装置との上記通信関係におけるHTTPヘッダテーブルが存在するか否かを判断する。該HTTPヘッダテーブルが存在する場合(S1504;YES)はS1505に進むが、存在しない場合(S1504;NO)はS1509に進む。
S1505でHTTPヘッダテーブル選択部320が、HTTPヘッダテーブル記憶部318から対象装置との上記通信関係におけるHTTPヘッダテーブルを取得する。そしてS1506でHTTPヘッダテーブル確認部321は、S1505で取得したHTTPヘッダテーブルを、対象装置との間で確認、及び通知する。このHTTPヘッダテーブルの確認・通知処理の詳細については、図12を用いて後述する。S1506の確認及び通知に成功した場合(S1507;YES)はS1508に進むが、失敗した場合(S1507;NO)はS1509に進む。
S1508ではHTTPヘッダテーブル選択部320が、S1505で取得したHTTPヘッダテーブルを、HTTPヘッダ圧縮部315における対象装置とのHTTPヘッダ圧縮にて利用するものとして選択し、処理を終了する。
S1509ではHTTPヘッダテーブル生成部316が、HTTP/2.0方式において規定された初期のHTTPヘッダテーブルを新規に生成する。そしてHTTPヘッダテーブル選択部320が、該新規生成されたHTTPヘッダテーブルを、HTTPヘッダ圧縮部315における対象装置とのHTTPヘッダ圧縮にて利用するものとして選択し、処理を終了する。
●通信関係の判断処理(S1502)
図11は、第1の通信装置10において第2の通信装置20との通信関係の有無を判断する処理を示すフローチャートであり、上記S1502の詳細を示すものである。
まずS1601で通信状態判断部312が、対象装置と無線LAN通信接続中であるか否かを判断する。対象装置との無線LAN通信接続中の場合(S1601;YES)はS1602に進むが、接続中でない場合(S1601;NO)はS1603に進む。
S1602で通信関係判断部311は、通信状態判断部312の判断結果を受けて、対象装置との通信関係が有ると判断し、処理を終了する。一方、S1603では通信関係判断部311は、通信状態判断部312の判断結果を受けて、対象装置との通信関係が無いと判断し、処理を終了する。
●HTTPヘッダテーブル確認・通知処理(S1506;第1の通信装置)
図12(a)は、第1の通信装置10において、第2の通信装置20との間で選択したHTTPヘッダテーブルを確認、及び通知する処理を示すフローチャートであり、上記S1506の詳細を示すものである。
まずS1701でHTTPヘッダテーブル確認部321が、対象装置にHTTPヘッダテーブル情報取得要求を送信する。ここでHTTPヘッダテーブル情報とは、HTTPヘッダテーブルのデータに基づいて算出されるCRCなど、HTTPヘッダテーブルが一致しているか否かを判断可能な情報である。
次にS1702でHTTPヘッダテーブル確認部321が、対象装置からHTTPヘッダテーブル情報を受信した場合(S1702;YES)はS1703に進み、受信できなかった場合(S1702;NO)はS1707に進む。
S1703でHTTPヘッダテーブル確認部321が、上記S1505で取得したHTTPヘッダテーブルと、S1702で受信した対象装置のHTTPヘッダテーブル情報に基づくHTTPヘッダテーブルとが一致しているか否か判断する。一致していると判断した場合(S1703;YES)はS1704に進むが、一致していないと判断した場合(S1703;NO)はS1707に進む。
S1704でHTTPヘッダテーブル確認部321が対象装置に、上記S1505で取得したHTTPヘッダテーブル選択を通知する。この通知において送信する情報は、HTTPヘッダテーブルを識別可能な情報であれば何でも良い。
そしてS1705でHTTPヘッダテーブル確認部321が、対象装置からHTTPヘッダテーブル選択通知応答を受信したか否かを判断する。受信した場合(S1705;YES)はS1706に進むが、受信できなかった場合(S1705;NO)はS1707に進む。
S1706でHTTPヘッダテーブル確認部321は、対象装置から受信したHTTPヘッダテーブル選択通知応答が成功であるか否かを判断する。成功の場合(S1706;YES)は処理を終了するが、失敗の場合(S1706;NO)はS1707に進む。
S1707ではHTTPヘッダテーブル確認部321が、HTTPヘッダテーブルの確認が失敗したとして、処理を終了する。
●HTTPヘッダテーブル確認・通知処理(S1506;第2の通信装置)
図12(b)は、第2の通信装置20において、第1の通信装置10からHTTPヘッダテーブル選択の通知を受信する処理を示すフローチャートであり、上記S1506の詳細を示すものである。
まずS1801でHTTPヘッダテーブル確認部321が、第1の通信装置10からHTTPヘッダテーブル選択の通知を受信する。
そしてS1802でHTTPヘッダテーブル確認部321が、HTTPヘッダテーブル記憶部318にS1801の通知で指定されたHTTPヘッダテーブルが存在しているか否かを判断する。存在している場合(S1802;YES)はS1803に進むが、存在していない場合(S1802;NO)はS1805に進む。
S1803でHTTPヘッダテーブル選択部320が、S1801の通知で指定されたHTTPヘッダテーブルを、第1の通信装置10とのHTTPヘッダ圧縮用として選択する。そしてS1804でHTTPヘッダテーブル確認部321が、HTTPヘッダテーブル選択通知応答を"成功"として送信し、処理を終了する。一方、S1805ではHTTPヘッダテーブル確認部321が、HTTPヘッダテーブル選択通知応答を"失敗"として送信し、処理を終了する。
●HTTPリクエスト処理(図6;第1の通信装置)
図13は、第1の通信装置10において、第2の通信装置20にHTTPリクエストを送信し、第2の通信装置20からHTTPレスポンスを受信する処理を示すフローチャートである。
まずS1901でHTTPヘッダ圧縮部315が、上記S1505で取得された対象装置とのHTTPヘッダテーブルを利用して、HTTPリクエストヘッダを圧縮する。そしてS1902でHTTP通信制御部307が、該圧縮したHTTPリクエストヘッダを含めたHTTPリクエストを作成する。そしてS1903でHTTP通信制御部307が、対象装置にHEADERS+PRIORITYフレームを送信する。このフレームには、S1901で圧縮したHTTPリクエストヘッダの情報が含まれている。
次にS1904でHTTP通信制御部307が、S1902で作成したHTTPリクエスト中にHTTPリクエストボディが有るか否かを判定する。HTTPリクエストボディが有る場合(S1904;YES)はS1905に進むが、ない場合(S1904;NO)はS1906に進む。S1905ではHTTP通信制御部307が、対象装置にDATAフレームを送信する。このフレームには、S1902で作成したHTTPリクエストボディの情報が含まれている。HTTP通信制御部307は、HTTPリクエストボディデータのサイズ分、DATAフレームを繰り返し送信するが、最後のDATAフレームにはFINALフラグを設定する。
S1906ではHTTP通信制御部307が、対象装置へのHTTPリクエストの送信に成功したか否かを判定し、成功した場合(S1906;YES)はS1907に進むが、失敗した場合(S1906;NO)はS1914に進む。
S1907ではHTTP通信制御部307が、対象装置からHTTPレスポンスのHEADERSフレームを受信したか否かを判定し、受信した場合(S1907;YES)はS1908に進むが、受信しなかった場合(S1907;NO)はS1914に進む。S1908ではHTTPヘッダ圧縮部315が、受信したHEADERSフレームに含まれる圧縮されたHTTPレスポンスヘッダを、対象装置とのHTTPヘッダテーブルを利用して展開する。
そしてS1909でHTTP通信制御部307が、対象装置から受信するHTTPレスポンスにHTTPレスポンスボディが有るか否かを判定し、有る場合(S1909;YES)はS1910に進むが、ない場合(S1909;NO)はS1911に進む。S1910ではHTTP通信制御部307が、対象装置からDATAフレームを受信する。このフレームには、HTTPレスポンスボディの情報が含まれている。HTTP通信制御部307は、HTTPレスポンスボディデータのサイズ分、DATAフレームを繰り返し受信する。
そしてS1911でHTTP通信制御部307が、対象装置からのHTTPレスポンスの受信に成功したか否かを判定し、成功した場合(S1911;YES)はS1912に進むが、失敗した場合(S1911;NO)はS1914に進む。S1912ではHTTPヘッダテーブル更新部317が、S1901及びS1902で作成したHTTPリクエストヘッダに基づき、対象装置とのHTTPリクエストヘッダテーブルを更新する。さらにS1913でHTTPヘッダテーブル更新部317が、S1907で受信したHTTPレスポンスヘッダに基づき、対象装置とのHTTPレスポンスヘッダテーブルを更新して、処理を終了する。
S1914ではHTTP通信制御部307が、対象装置とのHTTP通信に失敗したとして処理を終了する。
●HTTPレスポンス処理(図6;第2の通信装置)
図14は、第2の通信装置20において、第1の通信装置10からHTTPリクエストを受信し、第1の通信装置10にHTTPレスポンスを送信する処理を示すフローチャートである。なお同処理において、対象装置とは第1の通信装置10である。
まずS2001でHTTP通信制御部307は、対象装置からHTTPリクエストのHEADERS+PRIORITYフレームを受信したか否かを判定する。HEADERS+PRIORITYフレームを受信した場合(S2001;YES)はS2002に進むが、受信しなかった場合(S2001;NO)はS2016に進む。
S2002ではHTTPヘッダテーブル選択部320が、対象装置とのHTTPヘッダテーブルを選択済みであるか否かを判定し、選択済みの場合(S2002;YES)はS2004に進むが、選択済みでない場合(S2002;NO)はS2003に進む。S2003ではHTTPヘッダテーブル生成部316が、HTTP/2.0方式において規定された初期のHTTPヘッダテーブルを新規生成する。このときHTTPヘッダテーブル選択部320が、該新規生成されたHTTPヘッダテーブルを、HTTPヘッダ圧縮部315における対象装置とのHTTPヘッダ圧縮用として選択する。
S2004でHTTPヘッダ圧縮部315は、受信したHEADERS+PRIORITYフレームに含まれる圧縮されたHTTPリクエストヘッダを、対象装置とのHTTPヘッダテーブルを利用して展開する。
次にS2005でHTTP通信制御部307が、対象装置から受信するHTTPリクエストにHTTPリクエストボディが有るか否かを判定し、有る場合(S2005;YES)はS2006に進むが、無い場合(S2005;NO)はS2007に進む。S2006ではHTTP通信制御部307が、対象装置からDATAフレームを受信する。このフレームには、HTTPリクエストボディの情報が含まれている。HTTP通信制御部307は、HTTPリクエストボディデータのサイズ分、DATAフレームを繰り返し受信する。
S2007でHTTP通信制御部307は、対象装置からのHTTPリクエストの受信に成功したか否かを判定し、成功した場合(S2007;YES)はS2008に進むが、失敗した場合(S2007;NO)はS2016に進む。
S2008でHTTPヘッダ圧縮部315は、上記S1803またはS2003で選択した対象装置とのHTTPヘッダテーブルを利用して、HTTPレスポンスヘッダを圧縮する。そしてS2009でHTTP通信制御部307が、S2008で圧縮したHTTPレスポンスヘッダを含めたHTTPレスポンスを作成し、S2010でHTTP通信制御部307が、対象装置にHEADERSフレームを送信する。このフレームには、S2008で圧縮したHTTPレスポンスヘッダの情報が含まれている。
そしてS2011でHTTP通信制御部307が、S2009で作成したHTTPレスポンス中にHTTPレスポンスボディが有るか否かを判定し、有る場合(S2011;YES)はS2012に進むが、無い場合(S2011;NO)はS2013に進む。S2012ではHTTP通信制御部307が、対象装置にDATAフレームを送信する。このフレームには、S2009で作成したHTTPレスポンスボディの情報が含まれている。HTTP通信制御部307は、HTTPレスポンスボディデータのサイズ分、DATAフレームを繰り返し送信するが、最後のDATAフレームにFINALフラグを設定する。
そしてS2013でHTTP通信制御部307が、対象装置へのHTTPレスポンスの送信に成功したか否かを判定し、成功した場合(S2013;YES)はS2014に進むが、失敗した場合(S2013;NO)はS2016に進む。S2014ではHTTPヘッダテーブル更新部317が、S2001で受信したHTTPリクエストヘッダに基づき、対象装置とのHTTPリクエストヘッダテーブルを更新する。そしてS2015でHTTPヘッダテーブル更新部317が、上記S2008及びS2009で作成したHTTPレスポンスヘッダに基づき、対象装置とのHTTPレスポンスヘッダテーブルを更新して処理を終了する。
S2016ではHTTP通信制御部307が、対象装置とのHTTP通信に失敗したとして処理を終了する。
●HTTPヘッダテーブル削除処理(図9)
図15は、第1の通信装置10において、第2の通信装置20との間で利用したHTTPヘッダテーブルを記憶、または削除する処理を示すフローチャートである。
まずS2101でHTTPヘッダテーブル選択部320が、通信関係判断部311を利用して、HTTPヘッダテーブルの記憶、または削除を判断する通信イベントを検知する。この検知処理の詳細については図16を用いて後述する。
次にS2102でHTTPヘッダテーブル選択部320が、S2101で検知した通信イベントが記憶・削除判断対象のイベントであるか否かを判定する。対象イベントである場合(S2102;YES)はS2103に進むが、対象イベントでない場合(S2102;NO)は処理を終了する。S2103ではHTTPヘッダテーブル選択部320が、HTTPヘッダテーブルの記憶または削除の対象となる対象装置を特定する。なお、ここでの対象装置は第2の通信装置20である。そしてS2104で通信関係判断部311が、対象装置との通信関係の有無を判断するが、この判断処理の詳細は上記S1502と同様に、図11を用いて説明した通りである。
次にS2105でHTTPヘッダテーブル選択部320が、HTTPヘッダテーブル記憶部318に対象装置との上記通信関係におけるHTTPヘッダテーブルが存在するか否かを判断する。HTTPヘッダテーブルが存在する場合(S2105;YES)はS2106に進むが、存在しない場合(S2105;NO)は処理を終了する。
S2106で通信関係判断部311は、対象装置との通信関係の有無を判断し、有ると判断した場合(S2106;YES)はS2107に進むが、無いと判断した場合(S2106;NO)はS2108に進む。S2107ではHTTPヘッダテーブル記憶部318が、対象装置との上記通信関係におけるHTTPヘッダテーブルをHTTPヘッダテーブル記憶部318に記憶したままとして処理を終了する。一方、S2108ではHTTPヘッダテーブル削除部319が、対象装置との上記通信関係におけるHTTPヘッダテーブルを削除して、処理を終了する。
●通信イベント検知処理(S2101)
図16は、第1の通信装置10において、第2の通信装置20との間で利用したHTTPヘッダテーブルの記憶または削除を判断する通信イベントを検知する処理を示すフローチャートである。
まずS2201で、通信関係判断部311が通信イベントを検知する。このとき通信関係判断部311は、無線LAN通信制御部302、TCP/IP通信制御部306、HTTP通信制御部307、ディスカバリ制御部308、認証・認可制御部309、サービス制御部310、のいずれかを利用する。
そしてS2202で通信関係判断部311が、検知した通信イベントが対象装置とのHTTP通信切断のイベントであるか否かを判定する。HTTP通信切断である場合(S2202;YES)はS2203に進むが、HTTP通信切断でない場合(S2202;NO)はS2204に進む。S2203ではHTTPヘッダテーブル選択部320が、検知した通信イベントが記憶・削除判断対象通信イベントであると設定して、処理を終了する。
S2204では通信関係判断部311が、検知した通信イベントが対象装置との無線LAN通信切断のイベントであるか否かを判定する。無線LAN通信切断である場合(S2204;YES)はS2203に進み、無線LAN通信切断でない場合(S2204;NO)はS2205に進む。そしてS2205ではHTTPヘッダテーブル選択部320が、検知した通信イベントが記憶・削除判断非対象通信イベントであると設定して、処理を終了する。
●HTTPヘッダテーブル
以下、本実施形態に係るHTTPヘッダテーブルの更新について、具体例を用いて説明する。図24(a)は、本実施形態に係る初期のHTTPヘッダテーブルの具体例を示す図である。同図においてHTTPリクエストヘッダテーブル3410には、初期レコードとして、インデックス3411が0〜37番までの、HTTPリクエストヘッダ名3412及びHTTPリクエストヘッダ値3413が設定される。同様にHTTPレスポンスヘッダテーブル3420には、初期レコードとして、インデックス3421が0〜34番までの、HTTPレスポンスヘッダ名3422及びHTTPレスポンスヘッダ値3423が設定される。
図24(b)は、本実施形態で更新されたHTTPヘッダテーブルの具体例を示す図である。同図においてHTTPリクエストヘッダテーブル3510には、インデックス3511が0〜37番までの初期レコードに加えて、38番のレコード(ヘッダ名:x-my-header、ヘッダ値:first)が追加されている。同様にHTTPレスポンスヘッダテーブル3520には、インデックス3521が0〜34番までの初期レコードに加えて、35番のレコード(ヘッダ名:x-my-header、ヘッダ値:first)が追加されている。
以上、説明したように本実施形態によれば、第1の通信装置10は、第2の通信装置20とのHTTP通信において利用するHTTPヘッダテーブルを、第2の通信装置20との通信関係に応じて適切に選択する。そのため、第1の通信装置10は、第2の通信装置20とのHTTP通信を開始する毎に、HTTPヘッダテーブルを新規に作成する必要がなくなり、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延が軽減する。
また、図15に示したように第1の通信装置10は、第2の通信装置20との通信関係が有ると判断した場合に、第2の通信装置20との間で利用したHTTPヘッダテーブルを記憶する。それゆえ、第1の通信装置10は、第2の通信装置20との通信が継続され、HTTP通信が再度実施される可能性が高い場合に、HTTPヘッダテーブルを記憶しておくことで、HTTPヘッダテーブルの再利用を可能にする。これによって、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延がさらに軽減する。
一方、図15に示したように第1の通信装置10は、第2の通信装置20との通信関係が無いと判断した場合に、第2の通信装置20との間で利用したHTTPヘッダテーブルを削除する。それゆえ、第1の通信装置10は、第2の通信装置20との通信が継続されず、HTTP通信が再度実施される可能性が低い場合に、記憶していたHTTPヘッダテーブルを削除することが可能になる。これによって、再利用されないHTTPヘッダテーブルを無駄に記憶する必要がなくなり、記憶領域の消費を削減することができる。さらに、HTTPヘッダテーブル選択部320における、適切なHTTPヘッダテーブル選択に係る処理負荷、及び選択に伴う通信遅延をさらに軽減することができる。
また、図16のS2202で通信関係判断部311が、HTTP通信制御部307を利用してHTTP通信切断を検知する例を示したが、本発明におけるHTTP通信切断検知はこの例に限らない。例えば、第1の通信装置10と第2の通信装置において、HTTP通信中に、電源断、無線LAN通信断等が発生した場合、HTTP通信切断の通信イベントを検知することができない可能性がある。その場合、本来は削除されるべきHTTPヘッダテーブルが削除されず、記憶領域を無駄に消費してしまう。このような事態に対応するために、通信関係判断部311は、HTTP通信制御部307を利用してHTTP通信接続を検知しても良い。この場合すなわち、通信開始時に図15の処理を実行して、再利用されないHTTPヘッダテーブルを削除するか否かの判断を行うことで、記憶領域の消費をさらに削減することができる。さらに、HTTPヘッダテーブル選択部320における処理負荷、及び選択に伴う通信遅延をさらに軽減することができる。
また、図8(b)において第1の通信装置10は、第2の通信装置20との間で選択したHTTPヘッダテーブルの確認及び通知を、HTTP通信シーケンス前に実施する例を示したが、本発明はこの例に限らず、HTTP通信シーケンス中に実施しても良い。例えば第1の通信装置10は、選択したHTTPヘッダテーブルの情報を、図6のM804におけるHEADERS+PRIORITYフレーム中に指定して、第2の通信装置20に通知しても良い。これにより、第1の通信装置10と第2の通信装置20の間で、図8(b)に示すHTTPヘッダテーブルの確認・通知シーケンスが削減できるため、第1の通信装置10及び第2の通信装置20の通信速度が向上し、消費電力が軽減する。
また、図10のS1504でHTTPヘッダテーブル選択部320が、HTTPヘッダテーブル記憶部318が記憶した、対象装置に対応する複数のHTTPヘッダテーブルの中から1つを選択するようにしても良い。その場合、HTTPヘッダテーブル記憶部318は、図15のS2107において、対象装置との間で利用したHTTPヘッダテーブルに関連付けて、該HTTPヘッダテーブルを利用した状況における通信関係の情報を記憶しておく。この通信関係の情報とは、通信履歴(日付、時刻、IPアドレス、パケットデータ、通信内容、通信状態、接続関係など)のように、各々の通信関係が識別可能な情報であれば良い。これにより、HTTPヘッダテーブル選択部320は、第2の通信装置20との間で利用するHTTPヘッダテーブルの中から、最も適したものを選択することが可能となり、ヘッダ圧縮の効率が上がる。
また、図11に示したように通信状態判断部312が、HTTP通信及び無線LAN通信状態に基づいて通信関係の有無を判断する例を示したが、本発明はこの例に限らず、該判断を以下のように行うことも可能である。
例えば、通信状態判断部312が、TCP/IP通信制御部306を利用して、第2の通信装置20とのTCP/IP通信状態に基づいて、通信関係の有無を判断しても良い。このとき、TCP接続中は通信関係が有ると判断し、TCP切断時は通信関係が無いと判断する。また、後述する第3実施形態で示すように、ディスカバリ制御部308を利用して、第2の通信装置20との無線LAN上のディスカバリ状態に基づいて通信関係の有無を判断しても良い。
また、認証・認可制御部309を利用して、第2の通信装置20との認証・認可状態に基づいて、通信関係の有無を判断しても良い。例えば、ユーザのログイン中、認可済、認可承認済、認証有効期限内、アクセストークン有効、アクセストークン有効期限内、などの状態であれば、通信関係が有ると判断する。一方、ユーザのログアウト、未認証、認可未承認、認証有効期限切れ、アクセストークン無効、アクセストークン有効期限切れ、などの状態であれば、通信関係が無いと判断する。
また、サービス制御部310を利用して、第2の通信装置20とのサービス提供・利用状態に基づいて、通信関係の有無を判断しても良い。このとき、サービス提供の開始、サービス利用の開始であれば通信関係が有ると判断し、サービス提供の終了、サービス利用の終了であれば通信関係が無いと判断する。
また、通信状態判断部312では、これら複数の通信状態の組み合わせに基づいて通信関係の有無を判断しても良い。
<第2実施形態>
以下、本発明に係る第2実施形態について説明する。第2実施形態においては、複数のHTTP通信(HTTPマルチセッション)の通信状態に基づいて通信関係を判断することを特徴とする。第2実施形態における通信システム構成や機能モジュール構成については、上述した第1実施形態と同様であるため説明を省略する。
●通信シーケンス(メインストリーム)
以下、第2実施形態における第1の通信装置10と第2の通信装置20との間における通信シーケンスについて、詳細に説明する。
図17は、第2実施形態における、第1の通信装置10が第2の通信装置20との通信接続から通信切断までを行う際のメッセージの例を示すシーケンス図である。第2実施形態において、第1の通信装置10は、複数のHTTP通信(HTTPマルチセッション)の通信状態に基づいて通信関係を判断する。つまり、第1の通信装置10は、第2の通信装置20との第1のHTTP通信中に、第2の通信装置20との第2のHTTP通信を開始した場合、第1のHTTP通信の通信状態に基づいて通信関係を判断する。
まずM2301で第1の通信装置10が第2の通信装置20との第1のHTTP通信接続を行う。この通信接続の詳細なシーケンスは、第1実施形態で示した図4のM601〜M602(第1のHTTP通信接続、HTTPリクエスト送信・レスポンス受信)と同様である。
M2302で第1の通信装置10が、第2の通信装置20との第2のHTTP通信で利用するHTTPヘッダテーブルを選択する。このテーブル選択の詳細なシーケンスは、第1実施形態で示した図8(a)と同様であるが、M1201における通信関係の判断を、第2の通信装置20との第1のHTTP通信接続の有無によって判断する。M2302では第1の通信装置10が、第2の通信装置20との通信関係が有ると判断する。さらに、第1の通信装置10には、第2の通信装置20との第1のHTTP通信で利用しているHTTPヘッダテーブルが存在する。
M2303で第1の通信装置10が、M2302で選択した、第1のHTTP通信で利用しているHTTPヘッダテーブルを利用して、第2の通信装置20との第2のHTTP通信を行う。このHTTP通信に係る詳細なシーケンスは図4と同様であり、第2のHTTP通信接続、HTTPリクエスト送信・レスポンス受信、第2のHTTP通信切断、の一連の処理を行う。
M2304で第1の通信装置10が、M2303での第2のHTTP通信切断を受けて、第2の通信装置20との第2のHTTP通信で利用したHTTPヘッダテーブルを削除するか否かを判断する。このテーブル削除の詳細なシーケンスは、第1実施形態で示した図9と同様である。M2304では、第1のHTTP通信は継続中(HTTP通信切断していない)として、第2の通信装置20との通信関係が有ると判断し、第2の通信装置20との間で利用したHTTPヘッダテーブルを記憶する。さらに第2の通信装置20も、第1の通信装置10との通信関係が有ると判断し、第1の通信装置10との間で利用したHTTPヘッダテーブルを記憶する。
M2305で第1の通信装置10が、第2の通信装置20との第1のHTTP通信切断を行う。この通信切断の詳細なシーケンスは、図4のM603(第1のHTTP通信切断)と同様である。
M2306で第1の通信装置10が、M2305での第1のHTTP通信切断を受けて、第2の通信装置20との第2のHTTP通信で利用したHTTPヘッダテーブルの削除を判断する。このテーブル削除のシーケンスは、図9と同様である。M2306で第1の通信装置10は、第2の通信装置20との通信関係が無いと判断し、第2の通信装置20との第1のHTTP通信および第2のHTTP通信で利用したHTTPヘッダテーブルを削除する。さらに第2の通信装置20も、第1の通信装置10との通信関係が無いと判断し、第1の通信装置10との第1のHTTP通信および第2のHTTP通信で利用したHTTPヘッダテーブルを削除する。
●通信関係の判断処理
図18(a)は、第2実施形態の第1の通信装置10において、第2の通信装置20との通信関係の有無を判断する処理を示すフローチャートである。
まずS2401で通信状態判断部312が、対象装置と第1のHTTP通信接続中であるか否かを判断する。対象装置との第1のHTTP通信接続中の場合(S2401;YES)はS2402に進むが、接続中でない場合(S2401;NO)はS2403に進む。
以降は図11と同様に、S2402で通信関係判断部311が対象装置との通信関係が有ると判断し、S2403では無いと判断する。
●通信イベント検知処理
図18(b)は、第2実施形態の第1の通信装置10において、第2の通信装置20との間で利用したHTTPヘッダテーブルの記憶または削除を判断する通信イベントを検知する処理を示すフローチャートである。
まずS2501で、図16のS2201と同様に通信イベントを検知する。
そしてS2502で通信関係判断部311が、検知した通信イベントが対象装置との第2のHTTP通信切断のイベントであるか否かを判定する。第2のHTTP通信切断である場合(S2502;YES)はS2503に進むが、第2のHTTP通信切断でない場合(S2502;NO)はS2504に進む。S2503では図16のS2203と同様に、検知した通信イベントが記憶・削除判断対象通信イベントであると設定する。
S2504では通信関係判断部311が、検知した通信イベントが対象装置との第1のHTTP通信切断のイベントであるか否かを判定する。第1のHTTP通信切断である場合(S2504;YES)はS2503に進み、第1のHTTP通信切断でない場合(S2504;NO)はS2505に進む。そしてS2505では図16のS2205と同様に、検知した通信イベントが記憶・削除判断非対象通信イベントであると設定する。
以上、説明したように第2実施形態によれば、第1の通信装置10は、第2の通信装置20との第2のHTTP通信において利用するHTTPヘッダテーブルとして、第1のHTTP通信において利用しているHTTPヘッダテーブルを選択する。そのため、第1の通信装置10は、第2の通信装置20との複数のHTTP通信を開始する毎に、HTTPヘッダテーブルを新規に作成する必要がなくなり、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延が軽減する。
<第3実施形態>
以下、本発明に係る第3実施形態について説明する。第3実施形態においては、無線LAN上のネットワーク参加・離脱に関する通信状態に基づいて通信関係を判断することを特徴とする。第3実施形態における通信システム構成や機能モジュール構成について、上述した第1実施形態または第2実施形態と同様の要素については説明を省略する。
●システム構成
図19(a)は、第3実施形態に係る通信システムの構成例を示す図である。第1の通信装置10および第2の通信装置20については、第1実施形態と同様である。
無線アクセスポイント30は、第1の通信装置10及び第2の通信装置20における無線LAN通信を中継する無線アクセスポイントである。なお第3実施形態では第1の通信装置10と第2の通信装置20が無線LAN通信を行うために無線アクセスポイント30を利用する例を示すが、無線LANルータなどを利用しても良い。また、第1の通信装置10と第2の通信装置20が有線LAN通信を行うのであれば、無線アクセスポイント30に代えて有線LANハブ、有線LANスイッチ、有線LANルータ、などを利用しても良い。
●通信シーケンス(ネットワーク参加/離脱)
第3実施形態における第1の通信装置10が、第2の通信装置20との通信接続から通信切断までを行う際のメッセージの例を示すシーケンスは、図3と同様である。第3実施形態において第1の通信装置10は、無線LAN上のネットワーク参加・離脱に関する通信状態に基づいて、通信関係を判断する。
図19(b)は、第3実施形態の第1の通信装置10が、無線LAN上のネットワークに参加する際のメッセージの例を示すシーケンス図である。
M2701で第2の通信装置20が、無線アクセスポイント30との間で無線LAN通信接続を行い、M2702で第2の通信装置20が、無線LAN上にネットワーク参加を通知する。第3実施形態ではネットワーク参加の通知として、SSDP:aliveメッセージを送信する。
次にM2703で第1の通信装置10が、無線アクセスポイント30との間で無線LAN通信接続を行い、M2704で第1の通信装置10が、無線LAN上にネットワーク参加を通知する。するとM2705で第2の通信装置20が、第1の通信装置10のネットワーク参加の通知を受信し、第1の通信装置10を発見する。
次にM2706で第1の通信装置10が、無線LAN上に装置発見の要求を送信する。第3実施形態では装置発見の要求として、SSDP:M-SEARCHメッセージを送信する。するとM2707で第2の通信装置20は、M2706で受信した装置発見の要求に対して、装置発見の応答を送信する。第3実施形態では装置発見の応答として、SSDP:M-SEARCHに対する応答メッセージを送信する。そしてM2708で第1の通信装置10が、第2の通信装置20の装置発見の応答を受信し、第2の通信装置20を発見する。
次にM2709で第1の通信装置10が、第2の通信装置20に対して、機器情報およびサービス情報の取得を要求する。ここでの機器情報およびサービス情報とは、UPnPにおけるデバイスディスクリプション、及びサービスディスクリプションである。そしてM2710で第2の通信装置20が、第1の通信装置10からの機器情報およびサービス情報の取得の要求に対して、第2の通信装置20に関する機器情報、及びサービス情報を送信する。
図19(c)は、第3実施形態の第1の通信装置10が、無線LAN上のネットワークから離脱する際のメッセージの例を示すシーケンス図である。
M2801で第1の通信装置10が、無線LAN上にネットワーク離脱を通知する。第3実施形態ではネットワーク離脱の通知として、SSDP:byebyeメッセージを送信する。するとM2802で第2の通信装置20が、第1の通信装置10のネットワーク離脱の通知を受信し、第1の通信装置10のネットワーク離脱を検知する。そしてM2803で第1の通信装置10が、無線アクセスポイント30との間で無線LAN通信切断を行う。
●通信関係の判断処理
図20(a)は、第3実施形態の第1の通信装置10において、第2の通信装置20との通信関係の有無を判断する処理を示すフローチャートである。
まずS2901で通信状態判断部312が、ディスカバリ制御部308を利用して、第1の通信装置10がネットワークから離脱しているか否かを判断する。離脱している場合(S2901;YES)はS2904に進み、離脱していない場合(S2901;NO)はS2902に進む。
次にS2902で通信状態判断部312が、ディスカバリ制御部308を利用して、対象装置がネットワークから離脱しているか否かを判断する。離脱している場合(S2902;YES)はS2904に進み、離脱していない場合(S2902;NO)はS2903に進む。
以降は図11と同様に、S2903で通信関係判断部311が対象装置との通信関係が有ると判断し、S2904では無いと判断する。
●通信イベント検知処理
図20(b)は、第3実施形態の第1の通信装置10において、第2の通信装置20との間で利用したHTTPヘッダテーブルの記憶または削除を判断する通信イベントを検知する処理を示すフローチャートである。
まずS3001で、図16のS2201と同様に、通信イベントを検知する。
そしてS3002で通信関係判断部311が、検知した通信イベントが対象装置とのHTTP通信切断のイベントであるか否かを判定する。HTTP通信切断のイベントである場合(S3002;YES)はS3003に進むが、HTTP通信切断のイベントでない場合(S3002;NO)はS3004に進む。S3003ではHTTPヘッダテーブル選択部320が、検知した通信イベントが記憶・削除判断対象通信イベントであると設定する。
S3004では通信関係判断部311が、検知した通信イベントがネットワーク離脱のイベントであるか否かを判定する。ネットワーク離脱である場合(S3004;YES)はS3003に進み、ネットワーク離脱でない場合(S3004;NO)はS3005に進む。そしてS3005ではHTTPヘッダテーブル選択部320が、検知した通信イベントが記憶・削除判断非対象通信イベントであると設定する。
以上、説明したように第3実施形態によれば、第1の通信装置10は、第2の通信装置20とのHTTP通信において利用するHTTPヘッダテーブルを、無線LAN上のネットワーク参加・離脱に関する通信関係に応じて適切に選択する。そのため、第1の通信装置10は、第2の通信装置20とのHTTP通信を開始する毎に、HTTPヘッダテーブルを新規に作成する必要がなくなり、同一ネットワーク上に存在している間はHTTPヘッダテーブルの再利用が可能となる。これにより、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延が軽減する。
なお、第3実施形態では図20(b)のS3004に示すように、通信関係判断部311がディスカバリ制御部308を利用してネットワーク離脱を検知する例を示したが、本発明はこの例に限らない。例えば、第1の通信装置10または第2の通信装置20が無線LAN上のネットワーク参加中に、電源断、無線LAN通信断等が発生した場合には、ネットワーク離脱の通信イベントを検知できない可能性がある。これに対し、通信関係判断部311がディスカバリ制御部308を利用して、ネットワーク参加を検知しても良い。こうすることで、削除すべきHTTPヘッダテーブルを確実に削除して記憶領域の無駄な消費を削減し、HTTPヘッダテーブル選択部320における処理負荷、及び選択に伴う通信遅延をさらに軽減することができる。
また、第3実施形態の第1の通信装置10において、第2の通信装置20との間で選択したHTTPヘッダテーブルの確認、および通知を、ネットワーク参加、離脱、あるいは装置発見シーケンス中に実施しても良い。これにより、第1の通信装置10と第2の通信装置20の間で図8(b)に示すシーケンスが削減できるため、第1の通信装置10および第2の通信装置20の通信速度が向上し、消費電力が軽減する。
<第4実施形態>
以下、本発明に係る第4実施形態について説明する。第4実施形態においては、通信履歴に基づいて通信関係を判断することを特徴とする。第4実施形態における通信システム構成や機能モジュール構成について、上述した第1〜第3実施形態と同様の要素については説明を省略する。
第4実施形態における第1の通信装置10が、第2の通信装置20との通信接続から通信切断までを行う際のメッセージの例を示すシーケンスは、図3と同様である。第4実施形態において第1の通信装置10は、第2の通信装置20との通信履歴に基づいて通信関係を判断する。
●通信関係の判断処理
図21は、第4実施形態の第1の通信装置10において、第2の通信装置20との通信関係の有無を判断する処理を示すフローチャートである。
まずS3101で通信履歴判断部313が、対象装置とのHTTP通信履歴に基づく判定を行う。対象装置との通信履歴がある場合(S3101;YES)はS3102に進むが、通信履歴がない場合(S3101;NO)はS3105に進む。
S3102では通信履歴判断部313が、対象装置とのTCP/IP通信履歴に基づく判定を行う。すなわち通信履歴判断部313が、対象装置のドメイン・ホストが以前と同一であるか否かを判定し、同一である場合(S3102;YES)はS3103に進むが、同一でない場合(S3102;NO)はS3105に進む。
S3103では通信履歴判断部313が、対象装置とのHTTP通信履歴に基づく判定を行う。ここでは通信履歴判断部313が、対象装置との以前のHTTP通信が有効期間内かつ有効回数内である場合(S3103;YES)はS3104に進むが、そうでない場合(S3103;NO)はS3105に進む。
以降は図11と同様に、S3104で通信関係判断部311が対象装置との通信関係が有ると判断し、S3105では無いと判断する。
以上、説明したように第4実施形態によれば、第1の通信装置10は、第2の通信装置20とのHTTP通信において利用するHTTPヘッダテーブルを、第2の通信装置20との通信履歴に応じて適切に選択する。そのため、第1の通信装置10は、第2の通信装置20とのHTTP通信を開始する毎に、HTTPヘッダテーブルを新規に作成する必要がなくなり、同一ネットワーク上に存在している間はHTTPヘッダテーブルの再利用が可能となる。これにより、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延が軽減する。
また、第4実施形態では通信履歴判断部313がHTTP通信履歴とTCP/IP通信履歴に基づいて通信関係の有無を判断する例を示したが、本発明はこの例に限らない。例えば、通信履歴判断部313は、第2の通信装置20との無線LAN通信履歴に基づいて通信関係の有無を判断しても良い。例えば無線LAN接続の履歴や、特定の無線LAN接続形態(例えば、Wi-Fi Directの永続的グループ接続)の履歴がある場合に、通信関係が有ると判断する。また、第2の通信装置20とのディスカバリ履歴に基づいて判断しても良い。例えば、無線LAN上でのネットワークにて参加・発見の履歴が有り、かつ参加・発見した日時・回数が有効範囲内である場合に、通信関係が有ると判断する。また、第2の通信装置20との認証・認可履歴に基づいて判断しても良い。例えば、ユーザのログイン成功、認証成功、認可承認成功、等の履歴がある場合に、通信関係が有ると判断する。また、第2の通信装置20とのサービス提供・利用履歴に基づいて判断しても良い。例えば、提供・利用したサービスの種別・内容が同一である場合に、通信関係が有ると判断する。
<第5実施形態>
以下、本発明に係る第5実施形態について説明する。第5実施形態においては、通信方式に基づいて通信関係を判断することを特徴とする。第5実施形態における通信システム構成や機能モジュール構成について、上述した第1〜第4実施形態と同様の要素については説明を省略する。
第5実施形態における第1の通信装置10が、第2の通信装置20との通信接続から通信切断までを行う際のメッセージの例を示すシーケンスは、図3と同様である。第5実施形態において第1の通信装置10は、第2の通信装置20との通信方式に基づいて通信関係を判断する。
●HTTPヘッダテーブル選択処理
図22は、第1の通信装置10が第2の通信装置20との間でHTTPヘッダテーブルを選択する動作手順を示すフローチャートである。
まずS3201でHTTPヘッダテーブル選択部320が、HTTP通信制御部307を利用して対象装置(ここでは第2の通信装置20)を特定する。次にS3202で通信関係判断部311が、対象装置との通信関係の有無を判断する。この判断処理の詳細については図23を用いて後述する。
対象装置との通信関係が有ると判断された場合(S3203;YES)はS3204に進むが、無いと判断された場合(S3203;NO)はS3209に進む。
S1504でHTTPヘッダテーブル選択部320が、HTTPヘッダテーブル記憶部318に対象装置との上記通信関係におけるHTTPヘッダテーブルが存在するか否かを判断する。該HTTPヘッダテーブルが存在する場合(S1504;YES)はS1505に進むが、存在しない場合(S1504;NO)はS1509に進む。
S3204でHTTPヘッダテーブル選択部320が、固有HTTPヘッダテーブル管理部324を利用して、対象装置との上記通信関係における所定の通信方式に対応する固有HTTPヘッダテーブルが存在するか否かを判断する。該固有HTTPヘッダテーブルが存在する場合(S3204;YES)はS3205に進むが、存在しない場合(S3204;NO)はS3209に進む。
S3205でHTTPヘッダテーブル選択部320が、固有HTTPヘッダテーブル管理部324を利用して、対象装置との上記通信関係における所定の通信方式に対応する固有HTTPヘッダテーブルを取得する。そしてS3206でHTTPヘッダテーブル確認部321は、S3205で取得した固有HTTPヘッダテーブルを、対象装置との間で確認、及び通知する。このHTTPヘッダテーブルの確認・通知処理の詳細については、上記図12を用いて説明した第1実施形態と同様である。
S3206の確認及び通知に成功した場合(S3207;YES)はS3208に進むが、失敗した場合(S3207;NO)はS3209に進む。
S3208ではHTTPヘッダテーブル選択部320が、S3205で取得した固有HTTPヘッダテーブルを、HTTPヘッダ圧縮部315における対象装置とのHTTPヘッダ圧縮用として選択し、処理を終了する。
S3209ではHTTPヘッダテーブル生成部316が、HTTP/2.0方式において規定された初期のHTTPヘッダテーブルを新規に生成する。そしてHTTPヘッダテーブル選択部320が、該新規生成したHTTPヘッダテーブルを、HTTPヘッダ圧縮部315における対象装置とのHTTPヘッダ圧縮用として選択し、処理を終了する。
●通信関係の判断処理(S3202)
図23は、第5実施形態の第1の通信装置10において第2の通信装置20との通信関係の有無を判断する処理を示すフローチャートであり、上記S3202の詳細を示すものである。
まずS3301で通信方式判断部314が、サービス制御部310を利用して、対象装置のサービス提供方式に基づき通信関係を判断する。すなわち、サービス制御部310が対象装置のサービス提供方式に対応可能である場合(S3301;YES)はS3302に進むが、対応していない場合(S3301;NO)はS3303に進む。
S3302では通信関係判断部311が、通信方式判断部314の判断結果を受けて、対象装置との通信関係が有ると判断し、処理を終了する。一方、S3303では通信関係判断部311が、通信方式判断部314の判断結果を受けて、対象装置との通信関係が無いと判断し、処理を終了する。
●固有HTTPヘッダテーブル
図25は、第5実施形態に係る固有HTTPヘッダテーブルの具体例を示す図であり、通信方式としてDLNAに対応した固有HTTPヘッダテーブルの例である。同図においてHTTPリクエストヘッダテーブル3610には、インデックス3611が0〜37番までの初期レコードに加えて、38〜42番のレコードが追加されている。これらの追加レコードは、DLNAにおいて規定、または共通に利用されるHTTPリクエストヘッダである。
同様にHTTPレスポンスヘッダテーブル3620には、インデックス3621が0〜34番までの初期レコードに加えて、35〜37番のレコードが追加されている。これらの追加レコードは、DLNAにおいて規定、または共通に利用されるHTTPレスポンスヘッダである。
以上、説明したように第5実施形態によれば、第1の通信装置10は、第2の通信装置20とのHTTP通信において利用するHTTPヘッダテーブルとして、第2の通信装置20との所定の通信方式に対応する固有HTTPヘッダテーブルを選択する。そのため、第1の通信装置10は、第2の通信装置20とのHTTP通信を開始する毎に、HTTPヘッダテーブルを新規に作成する必要はなく、所定の通信方式に最適化された固有HTTPヘッダテーブルを利用することができる。これにより、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延をさらに軽減することが可能となる。
また、第5実施形態では、通信方式判断部314がサービス制御部310を利用して、対象装置のサービス提供方式に基づいて通信関係の有無を判断する例を示したが、本発明はこの例に限らない。例えば、第2の通信装置20との無線LAN通信方式に基づいて、通信関係の有無を判断しても良い。このとき通信方式判断部314は、無線LAN通信方式が無線ダイレクト方式、Wi-Fi Direct方式、Wi-Fi Direct Service方式、Wi-Fi Miracast方式、等である場合に、通信関係が有ると判断する。また、第2の通信装置20とのTCP/IP通信方式に基づいて判断しても良く、VPN方式、IPsec方式、などの場合に、通信関係が有ると判断する。また、第2の通信装置20とのディスカバリ方式に基づいて判断しても良く、SSDP方式、mDNS方式、Bonjour方式、SDP方式、などの場合に、通信関係が有ると判断する。また、認証・認可方式に基づいて判断しても良く、HTTP認証(Basic認証、Digest認証)方式、OAuth2.0方式、OpenID方式、OpenID Connect方式、SAML方式、などの場合に通信関係が有ると判断する。
また、第5実施形態ではHTTPヘッダテーブル選択部320が、第2の通信装置20との所定の通信方式に対応する1つの固有HTTPヘッダテーブルを選択する例を示したが、本発明はこの例に限らない。例えば、第1の通信装置10が、第2の通信装置20と複数の所定の通信方式に基づいてHTTP通信を行う場合、これら通信方式に対応する複数の固有HTTPヘッダテーブルを選択し、組み合わせて利用しても良い。これにより、様々な通信方式に最適化されたHTTPヘッダテーブルを利用することが可能となり、HTTPヘッダテーブル作成に係る処理負荷、及び作成時間に伴う通信遅延をさらに軽減することが可能となる。
<その他の実施形態>
上述した各実施形態は、その複数を組み合わせて実現することが可能である。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。また、そのプログラムをコンピュータ可読な記録媒体に記録して提供してもよい。
10:第1の通信装置、20:第2の通信装置、311:通信関係判断部、312:通信状態判断部、313:通信履歴判断部、314:通信方式判断部、315:HTTPヘッダ圧縮部、317:HTTPヘッダテーブル更新部

Claims (15)

  1. 他の通信装置に送信するメッセージヘッダを圧縮用のテーブルを参照して圧縮する圧縮手段と、
    他の通信装置に送信するメッセージヘッダまたは他の通信装置から受信したメッセージヘッダに基づいて前記テーブルを更新する更新手段と、
    他の通信装置とのネットワークを介した接続状況を判断する判断手段と、を有し、
    前記圧縮手段は、前記判断手段で接続中であると判断された他の通信装置については、当該通信装置に対応する前記テーブルを参照することを特徴とする通信装置。
  2. 初期テーブルを作成する作成手段、をさらに有し、
    前記圧縮手段は、前記判断手段で前記他の通信装置との接続が未だであると判断された他の通信装置については、前記作成手段で作成された初期テーブルを圧縮用のテーブルとして参照することを特徴とする請求項1に記載の通信装置。
  3. 前記判断手段で接続が切断されたと判断された他の通信装置に対応する前記テーブルを削除する削除手段、をさらに有することを特徴とする請求項1または2に記載の通信装置。
  4. 前記判断手段は、他の通信装置が参加しているネットワークに自装置が参加している場合に他の通信装置と接続中であると判断し、前記ネットワークから自装置が離脱した場合に他の通信装置との接続が切断されたと判断することを特徴とする請求項1乃至3のいずれか1項に記載の通信装置。
  5. 前記判断手段は、他の通信装置との間でマルチセッションによる通信が継続中である場合に前記他の通信装置と接続中であると判断し、前記他の通信装置との間のすべてのセッションが切断された場合に前記他の通信装置との接続が切断されたと判断することを特徴とする請求項1乃至4のいずれか1項に記載の通信装置。
  6. 前記圧縮手段は、他の通信装置との通信履歴に応じて、前記圧縮に用いるテーブルを選択することを特徴とする請求項1乃至5のいずれか1項に記載の通信装置。
  7. 前記圧縮手段は、他の通信装置との通信方式に応じて、前記圧縮に用いるテーブルを選択することを特徴とする請求項1乃至6のいずれか1項に記載の通信装置。
  8. 前記圧縮手段は、他の通信装置が提供するサービスの通信方式が自装置で対応可能である場合に、該他の通信装置に対応する前記テーブルを選択することを特徴とする請求項7に記載の通信装置。
  9. 他の通信装置でメッセージヘッダの圧縮に利用されるテーブルの情報を取得する取得手段、をさらに備え、
    前記圧縮手段は、前記判断手段で接続中であると判断された他の通信装置について、当該通信装置に対応するテーブルの情報が前記取得手段で取得されたテーブルの情報と一致していれば、該テーブルを参照することを特徴とする請求項1乃至8のいずれか1項に記載の通信装置。
  10. 前記圧縮手段で参照される他の通信装置に対応するテーブルの情報を、前記他の通信装置に通知する通知手段、をさらに有することを特徴とする請求項9に記載の通信装置。
  11. 前記圧縮手段は、HTTPヘッダ圧縮を行うことを特徴とする請求項1乃至10のいずれか1項に記載の通信装置。
  12. 第1の通信装置と、他の複数の通信装置との間で通信を行う通信システムであって、前記第1の通信装置が、
    他の通信装置に送信するメッセージヘッダを圧縮用のテーブルを参照して圧縮する圧縮手段と、
    他の通信装置に送信するメッセージヘッダまたは他の通信装置から受信したメッセージヘッダに基づいて前記テーブルを更新する更新手段と、
    他の通信装置とのネットワークを介した接続状況を判断する判断手段と、を有し、
    前記圧縮手段は、前記判断手段で接続中であると判断された他の通信装置については、当該通信装置に対応する前記テーブルを参照する
    ことを特徴とする通信システム。
  13. 他の通信装置に送信するメッセージヘッダを圧縮用のテーブルを参照して圧縮する圧縮ステップと、
    他の通信装置に送信するメッセージヘッダまたは他の通信装置から受信したメッセージヘッダに基づいて前記テーブルを更新する更新ステップと、
    他の通信装置とのネットワークを介した接続状況を判断する判断ステップと、を有し、
    前記圧縮ステップでは、接続中であると判断された他の通信装置については、当該通信装置に対応する前記テーブルを参照することを特徴とする通信方法。
  14. コンピュータ装置で実行されることにより、該コンピュータ装置を請求項1乃至11のいずれか1項に記載の通信装置の各手段として機能させるためのプログラム。
  15. 請求項14に記載のプログラムを記憶したことを特徴とするコンピュータ可読な記憶媒体。
JP2014142637A 2014-07-10 2014-07-10 通信装置および通信方法、ならびに通信システム Active JP6363897B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014142637A JP6363897B2 (ja) 2014-07-10 2014-07-10 通信装置および通信方法、ならびに通信システム
US14/790,138 US9596326B2 (en) 2014-07-10 2015-07-02 Communication apparatus, communication method, and non-transitory computer-readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014142637A JP6363897B2 (ja) 2014-07-10 2014-07-10 通信装置および通信方法、ならびに通信システム

Publications (3)

Publication Number Publication Date
JP2016018502A true JP2016018502A (ja) 2016-02-01
JP2016018502A5 JP2016018502A5 (ja) 2017-08-17
JP6363897B2 JP6363897B2 (ja) 2018-07-25

Family

ID=55068478

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014142637A Active JP6363897B2 (ja) 2014-07-10 2014-07-10 通信装置および通信方法、ならびに通信システム

Country Status (2)

Country Link
US (1) US9596326B2 (ja)
JP (1) JP6363897B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018030289A1 (ja) * 2016-08-08 2018-02-15 株式会社エヌティーアイ Ssl通信システム、クライアント、サーバ、ssl通信方法、コンピュータプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10291682B1 (en) * 2016-09-22 2019-05-14 Juniper Networks, Inc. Efficient transmission control protocol (TCP) reassembly for HTTP/2 streams
CN106357829B (zh) * 2016-11-24 2019-09-06 北京友道互联电子商务有限公司 一种基于http的信息过滤叠加方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005252855A (ja) * 2004-03-05 2005-09-15 Nec Electronics Corp ヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法
US20110231577A1 (en) * 2009-11-30 2011-09-22 Ramin Rezaiifar Methods and Apparatus for Improving Header Compression
WO2013079277A1 (en) * 2011-12-02 2013-06-06 Canon Kabushiki Kaisha Methods and devices for encoding and decoding messages

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027731A1 (en) * 2003-07-30 2005-02-03 Daniel Revel Compression dictionaries
US9148366B2 (en) * 2011-04-11 2015-09-29 Qualcomm Innovation Center, Inc. Interactive header compression in peer-to-peer communications
GB2496385B (en) * 2011-11-08 2014-03-05 Canon Kk Methods and network devices for communicating data packets
JP6454076B2 (ja) 2014-03-20 2019-01-16 キヤノン株式会社 中継装置、通信装置、それらの制御方法、システム、及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005252855A (ja) * 2004-03-05 2005-09-15 Nec Electronics Corp ヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法
US20110231577A1 (en) * 2009-11-30 2011-09-22 Ramin Rezaiifar Methods and Apparatus for Improving Header Compression
WO2013079277A1 (en) * 2011-12-02 2013-06-06 Canon Kabushiki Kaisha Methods and devices for encoding and decoding messages

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018030289A1 (ja) * 2016-08-08 2018-02-15 株式会社エヌティーアイ Ssl通信システム、クライアント、サーバ、ssl通信方法、コンピュータプログラム
JP2018026631A (ja) * 2016-08-08 2018-02-15 株式会社 エヌティーアイ Ssl通信システム、クライアント、サーバ、ssl通信方法、コンピュータプログラム

Also Published As

Publication number Publication date
US20160014242A1 (en) 2016-01-14
JP6363897B2 (ja) 2018-07-25
US9596326B2 (en) 2017-03-14

Similar Documents

Publication Publication Date Title
US10117206B2 (en) Method for synchronizing content among terminals and terminals
US20230224803A1 (en) Provisioning a device in a network
KR102053829B1 (ko) 보안 nan 데이터 링크 설정
EP3440853B1 (en) Managed object to provision a device according to one of plural provisioning techniques
EP3755024B1 (en) Message processing method, system, and user plane function device
JP6385205B2 (ja) 通信装置、通信装置の制御方法およびプログラム
US8935765B2 (en) Method to enable mobile devices to rendezvous in a communication network
CN111064742B (zh) 一种基于网络代理实现内网访问的方法、装置及相关设备
CN109257392B (zh) 一种命令处理方法、装置、服务器和存储介质
JP6363897B2 (ja) 通信装置および通信方法、ならびに通信システム
JP6548445B2 (ja) 通信装置、通信方法及びプログラム
US20150043421A1 (en) Wireless relay apparatus, communication system, and communication method
WO2021164458A1 (zh) 通信方法和相关装置及计算机可读存储介质
CN112740790B (zh) 一种用于侧链资源控制的方法、装置、系统、计算机设备和存储介质
US9554278B2 (en) Relay apparatus, relay method, relay system, and non-transitory computer-readable storage medium
JP7250587B2 (ja) 通信装置、制御方法、および、プログラム
CN116368833A (zh) 针对边缘计算服务的安全连接的建立和认证的方法和系统
JP2010166410A (ja) Ip電話端末装置、vpnサーバ装置、ip電話サーバ装置およびこれらを用いたip電話システム
JP6369094B2 (ja) 情報共有システム
WO2016127583A1 (zh) 认证处理方法及装置
Sitorus et al. Establishment of Wi-Fi Display session between source and sink device in wireless Android screencasting
JP6662124B2 (ja) 通信装置、履歴情報管理方法及び履歴情報管理プログラム
JP4561626B2 (ja) 情報処理装置およびその制御方法ならびにコンピュータプログラム
KR101230209B1 (ko) 핫스팟 네트워크들을 위한 공통 데이터 모델 및 안전한 온라인 서명을 위한 방법
JP2017011618A (ja) 通信装置、通信方法、プログラム、及び通信システム

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170706

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170706

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180525

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: 20180601

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180629

R151 Written notification of patent or utility model registration

Ref document number: 6363897

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151