特許 6286319 ＨＴＴＰクライアント、ＨＴＴＰサーバおよびＨＴＴＰ通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6286319

(24)【登録日】2018年2月9日

(45)【発行日】2018年2月28日

(54)【発明の名称】ＨＴＴＰクライアント、ＨＴＴＰサーバおよびＨＴＴＰ通信方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20180215BHJP

【ＦＩ】

   G06F13/00 353C

【請求項の数】11

【全頁数】10

(21)【出願番号】特願2014-160363(P2014-160363)

(22)【出願日】2014年8月6日

(65)【公開番号】特開2016-38664(P2016-38664A)

(43)【公開日】2016年3月22日

【審査請求日】2017年1月30日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】峯木 厳

(72)【発明者】

【氏名】長谷川 輝之

【審査官】 小林 義晴

(56)【参考文献】

【文献】 米国特許出願公開第２００２／０１８８７４３（ＵＳ，Ａ１）

【文献】 特表２００４−５３０２３１（ＪＰ，Ａ）

【文献】 大津繁樹，ＨＴＴＰ／２の最新動向，電子情報通信学会誌，日本，一般社団法人電子情報通信学会，２０１４年 ８月 １日，第97巻,第8号，p.727-733

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

HTTPの相対的に上位および下位の各バージョンに対応したHTTPクライアントにおいて、
前記下位バージョンのマイナーバージョンによるHTTP通信を要求するHTTPリクエストメッセージを生成する手段と、
前記HTTPリクエストメッセージを所定のサーバへ送信してHTTPレスポンスメッセージを受信する手段と、
前記マイナーバージョンによるHTTP通信を了解するHTTPレスポンスメッセージに登録されているコンテンツを取得する手段と、
前記マイナーバージョンによるHTTP通信を了解するHTTPレスポンスメッセージに対して前記上位バージョンによる通信を主導する手段とを具備したことを特徴とするHTTPクライアント。

【請求項2】

前記マイナーバージョンは、メジャー番号が下位バージョンと同一でマイナー番号が固有であることを特徴とする請求項１に記載のHTTPクライアント。

【請求項3】

前記上位バーションがHTTP/2.0であり、前記下位バーションがHTTP/1.1であることを特徴とする請求項２に記載のHTTPクライアント。

【請求項4】

前記通信を主導する手段は、前記下位バージョンによるHTTP通信を了解するHTTPレスポンスメッセージに対して前記下位バージョンによる通信を主導することを特徴とする請求項１ないし３のいずれかに記載のHTTPクライアント。

【請求項5】

前記通信を主導する手段は、前記上位バージョンによるHTTP通信を了解するHTTPレスポンスメッセージに対して前記上位バージョンによる通信を主導することを特徴とする請求項１ないし３のいずれかに記載のHTTPクライアント。

【請求項6】

HTTPの相対的に上位および下位の各バージョンに対応したHTTPサーバにおいて、
HTTPクライアントからHTTPリクエストメッセージを受信する手段と、
前記下位バージョンのマイナーバージョンによるHTTP通信を要求するHTTPリクエストメッセージに対して、要求されたコンテンツが登録されて前記マイナーバージョンによる通信を了解するHTTPレスポンストメッセージを生成する手段と、
前記HTTPレスポンストメッセージを前記HTTPクライアントへ返信する手段とを具備したことを特徴とするHTTPサーバ。

【請求項7】

前記マイナーバージョンは、メジャー番号が下位バージョンと同一でマイナー番号が固有であることを特徴とする請求項６に記載のHTTPサーバ。

【請求項8】

前記上位バーションがHTTP/2.0であり、前記下位バーションがHTTP/1.1であることを特徴とする請求項７に記載のHTTPサーバ。

【請求項9】

HTTPの相対的に上位および下位の各バージョンに対応したクライアントおよびサーバによるHTTP通信方法において、
クライアントが、前記下位バージョンのマイナーバージョンによるHTTP通信を要求するHTTPリクエストメッセージを生成してサーバへ送信する手順と、
サーバが、前記下位バージョンのマイナーバージョンによるHTTP通信を要求するHTTPリクエストメッセージに対して、要求されたコンテンツが登録されて前記マイナーバージョンによる通信を了解するHTTPレスポンストメッセージを返信する手順と、
クライアントが、前記マイナーバージョンによるHTTP通信を了解するHTTPレスポンスメッセージに登録されているコンテンツを取得する手順と、
クライアントが、前記マイナーバージョンによるHTTP通信を了解するHTTPレスポンスメッセージに対して前記上位バージョンによる通信を主導する手順とを含むことを特徴とするHTTP通信方法。

【請求項10】

前記マイナーバージョンは、メジャー番号が下位バージョンと同一でマイナー番号が固有であることを特徴とする請求項９に記載のHTTP通信方法。

【請求項11】

前記上位バーションがHTTP/2.0であり、前記下位バーションがHTTP/1.1であることを特徴とする請求項１０に記載のHTTP通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、HTTPによるWebコンテンツ配信に先立って実行されるHTTPのバージョン設定のためのネゴシエーションをコンテンツ配信に活用することで、高速なWebコンテンツ配信を可能にするHTTPクライアント、HTTPサーバおよびHTTP通信方法に関する。

【背景技術】

【0002】

HTTP（Hypertext Transfer Protocol）は、HTMLで記述されたWebコンテンツをサーバからブラウザ（クライアント）にダウンロードするために開発され、主にブラウザからサーバにWebコンテンツを要求（request）する手順と、サーバがブラウザから要求されたWebコンテンツを応答（response）する手順とから構成される。

【0003】

HTTP/1.0では、コンテンツを取得するごとにTCPコネクションの接続・切断が繰り返されるので、特にHTMLファイル中に多数のコンテンツが含まれている場合などに効率が悪くなる。これに対して、HTTP/1.1では主にkeep-alive（キープアライブ）機能により、多数の画像コンテンツを含むWebページの表示などが高速化される。

【0004】

なお、HTTP/1.1では、その初めは同時接続できるコネクション数がHTTP/1.0よりも少なかったため、これを補う技術としてマルチドメイン構成のWebページが開発された。しかしながら、HTTP/1.1によりマルチドメイン構成のWebページをダウンロードしようとするとHTTPの同時リクエストが発生するため、サーバやネットワーク機器の負荷を上昇させるという新たな問題が生じる。

【0005】

このような技術課題を解決するために、HTTPの次世代のバージョンとしてHTTP/2.0が研究されている。このHTTP/2.0では、複数のHTTPを一本のTCPコネクションで実現することで上記の技術課題を解決している。

【0006】

非特許文献には、Webコンテンツ配信においてWeb高速化を実現する背景技術として、TCPコネクションの統合、WebサーバからのPush配信、リクエストの多重送信化、冗長なヘッダの削除、通信データの圧縮の必須化を行うことで、Web高速化を実現するHTTP/2.0が開示されている。

【0007】

HTTP/2.0は、既存のHTTP/1.1が実装されているアプリケーション層の下位層であるセッション層に実装されるため、HTTP/1.1で規定されるメソッドやヘッダといったHTTPそのものに手を加える必要がないという利点がある。

【先行技術文献】

【非特許文献】

【0008】

【非特許文献1】IETF, M. Belshe, R. Peon, M. Thomson, Ed."Hypertext Transfer Protocol version 2" draft-ietf-httpbis-http2-10, Feb. 2014.

【発明の概要】

【発明が解決しようとする課題】

【0009】

非特許文献は、Webアクセス高速化を目的とした通信技術であり、具体的には、クライアントとWebサーバとの間に確立するTCPコネクションを効率的に使用することで、Webコンテンツ配信の速度向上を行うものである。

【0010】

このとき、非特許文献の通信フォーマットは、HTTP/1.1の通信フォーマットと互換性がないため、クライアントおよびWebのいずれもが非特許文献の通信フォーマットに対応していることが必要である。そのため、TCPコネクション確立後に、対象となるWebサーバが非特許文献の通信フォーマットに対応しているかの確認（ネゴシエーション）が必須となり、図９に示した３種類のネゴシエーション手順が議論されている。

【0011】

手順１：TCPコネクション確立後、SSLセッション確立する際にALPNを使用して通信方式を決定する。

【0012】

手順２：TCPコネクション確立後、クライアントからHTTPを用いてリクエストを送信する際に、Upgradeヘッダを用いて非特許文献の通信フォーマットへアップグレードする。

【0013】

手順３：あらかじめ非特許文献を使用することを理解しているサーバへ非特許文献の通信フォーマットによる接続を開始する。

【0014】

手順１では、SSLセッションの確立が必須である。そのため、非特許文献の通信フォーマットに対応していないWebサーバに対しては、HTTP/1.1を用いた通信との比較で、Webサーバ・クライアント間でSSLセッション確立に要する通信が追加で発生してしまう。

【0015】

手順２では、SSLセッションを確立する代わりにHTTP/1.1で定義されるUpgradeヘッダと101ステータスコードを用いてHTTPのアップグレードが行われる。しかしながら、アップグレード手順の発生に伴い、非特許文献の通信フォーマットへ移行するまでに、Webサーバ・クライアント間で１往復分の通信が余計に発生してしまう。

【0016】

手順３では、あらかじめ非特許文献の通信フォーマットに対応したWebサーバであることをクライアントが認識する必要があり、サーバおよびクライアント以外の第三のノード（例えば、DNSなど）に新しい実装が必要となってしまう。

【0017】

本発明の目的は、上記の技術課題を解決し、無駄な通信を発生させることなく、サーバおよびクライアントの協調動作のみで、Webコンテンツの高速配信を可能にするHTTPクライアント、HTTPサーバおよびHTTP通信方法を提供することにある。

【課題を解決するための手段】

【0018】

(1) 本発明のHTTPクライアントは、HTTPの相対的に上位および下位の各バージョンに対応し、下位バージョンのマイナーバージョンによるHTTP通信を要求するリクエストメッセージを生成する手段と、このリクエストメッセージをサーバへ送信してレスポンスメッセージを受信する手段と、マイナーバージョンによるHTTP通信を了解するレスポンスメッセージに登録されているコンテンツを取得する手段と、マイナーバージョンによるHTTP通信を了解するレスポンスメッセージに対して上位バージョンによる通信を主導する手段とを具備した。

【0019】

(2) 本発明のHTTPサーバは、HTTPの相対的に上位および下位の各バージョンに対応し、HTTPクライアントからリクエストメッセージを受信する手段と、下位バージョンのマイナーバージョンによるHTTP通信を要求するリクエストメッセージに対して、要求されたコンテンツが登録されて前記マイナーバージョンによる通信を了解するレスポンストメッセージを生成する手段と、前記レスポンストメッセージをHTTPクライアントへ返信する手段とを具備した。

【0020】

(3) 本発明のHTTP通信方法は、HTTPの相対的に上位および下位の各バージョンに対応したクライアントおよびサーバによる通信方法であって、クライアントが下位バージョンのマイナーバージョンによるHTTP通信を要求するリクエストメッセージを生成してサーバへ送信する手順と、サーバがクライアントへ、要求されたコンテンツが登録されて前記マイナーバージョンによる通信を了解するレスポンストメッセージを返信する手順と、クライアントが、マイナーバージョンによるHTTP通信を了解するレスポンスメッセージに対してHTTPの上位バージョンによる通信を主導する手順とを含む。

【発明の効果】

【0021】

本発明によれば、以下のような効果が達成される。
(1) クライアントがコンテンツ配信を要求するHTTPリクエストメッセージのリクエスト行に、HTTPバージョンとして固有のマイナバージョン"HTTP/1.XX"を記述して送信すると、これを受信したサーバは、要求されたコンテンツの少なくとも一部をHTTPレスポンスメッセージに登録して配信する。したがって、既存のHTTPを改修することなく、ネゴシエーション時にもコンテンツ配信が行えるようになるので、Webコンテンツの高速配信が実現される。

【0022】

(2) クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応であっても従来のHTTP/1.1に対応していれば、HTTP/1.1によるコンテンツ配信が可能になる。

【0023】

(3) クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応であっても従来のHTTP/2.0に対応していれば、HTTP/2.0によるコンテンツ配信が可能になる。

【図面の簡単な説明】

【0024】

【図1】本発明の一実施形態に係るHTTP通信方法を適用したHTTPクライアントおよびHTTPサーバの主要部の構成を示した機能ブロック図である。

【図2】クライアントおよびサーバのいずれもが本発明のHTTP通信方式に対応している場合のHTTP接続手順を示したシーケンスフローである。

【図3】図２のシーケンスで送受されるHTTPリクエストメッセージの一例を示した図である。

【図4】図２のシーケンスで送受されるHTTPレスポンスメッセージの一例を示した図である。

【図5】クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応の場合のHTTP接続手順を示したシーケンスフローである。

【図6】図５のシーケンスで送受されるHTTPレスポンスメッセージの一例を示した図である。

【図7】クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応でHTTP/2.0に対応した場合のHTTP接続手順を示したシーケンスフローである。

【図8】図７のシーケンスで送受されるHTTPレスポンスメッセージの一例を示した図である。

【図9】従来技術のHTTP接続手順を示したシーケンスフローである。

【発明を実施するための形態】

【0025】

以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の一実施形態に係るHTTP通信方法を適用したHTTPクライアント１およびHTTPサーバ２の主要部の構成を示した機能ブロック図であり、ここでは本発明の説明に不要な構成は図示が省略されている。

【0026】

HTTPクライアント１は、HTTPの相対的に下位および上位のメジャーバージョンとして、それぞれHTTP/1.1およびHTTP/2.0に対応する。リクエストメッセージ生成部１０１は、後に詳述するように、HTTP/1.1のマイナーバージョンであって、メジャー番号が「１」でマイナー番号が本発明の固有の「XX」であるHTTP/1.XX（例えば、HTTP/1.2）に準拠した通信をHTTPサーバ２へ要求するためのHTTPリクエストメッセージを生成する。

【0027】

メッセージ送受信部１０２は、前記HTTPリクエストメッセージをHTTP/1.1に準拠した通信によりHTTPサーバ２へ送信し、これに応答してHTTPサーバ２が返信するHTTPレスポンスメッセージを受信する。

【0028】

HTTPサーバ２は、前記HTTPクライアント１と同様に、HTTPの相対的に下位および上位のメジャーバージョンとして、それぞれHTTP/1.1およびHTTP/2.0に対応する。メッセージ送受信部２０１は、HTTPクライアント１から送信されるリクエストメッセージを受信し、これに応答するレスポンスメッセージを返信する。

【0029】

HTTPサーバ２のレスポンスメッセージ生成部２０２はコンテンツ登録部２０２ａを備え、前記マイナーバージョンHTTP/1.XXによるHTTP通信を要求するHTTPリクエストメッセージに応答するレスポンストメッセージを生成する。本実施形態では、後に詳述するように、レスポンストメッセージに対して、前記マイナーバージョンHTTP/1.XXによる通信を了解する旨のメッセージが記述され、更には前記コンテンツ登録部２０２ａにより、要求されたWebコンテンツがコンテンツDB２０４から読み出されてレスポンストメッセージのメッセージボディに登録される。

【0030】

HTTPクライアント１のコンテンツ抽出部１０３は、前記マイナーバージョンHTTP/1.XXによるHTTP通信を了解するHTTPレスポンスメッセージを受信すると、そのメッセージボディに登録されているWebコンテンツを取得する。

【0031】

HTTPクライアント１およびHTTPサーバ２の各通信実行部１０４、２０３は、HTTPの各メジャーバージョンHTTP/1.1、HTTP/2.0およびマイナーバージョンHTTP/1.XXに対応する。前記通信実行部１０４は、前記マイナーバージョンHTTP/1.XXによるHTTP通信を了解するHTTPレスポンスメッセージに対して、HTTPサーバ２の通信実行部２０３と協調してHTTP/2.0による通信を主導し、前記HTTPサーバ２のコンテンツDB２０４から残りのWebコンテンツをHTTP/2.0に準拠した通信により高速に取得する。

【0032】

図２は、クライアントおよびサーバのいずれもが本発明のHTTP通信方式に対応している場合のHTTP接続手順を示したシーケンスフローであり、図３，４はそれぞれ、クライアントからサーバへ送信されるHTTPリクエストメッセージおよびサーバからクライアントへ送信されるHTTPレスポンスメッセージの一例を示している。

【0033】

図２において、時刻t1では、クライアント／サーバ間で３ウェイハンドシェークによる周知の接続処理が行われ、クライアントからサーバへのSYNパケットの送信、サーバからクライアントへのSYN ACKパケットの送信、およびクライアントからサーバへのACKパケットの送信を経て接続が確立される。

【0034】

時刻t2では、クライアントからサーバへHTTPリクエストメッセージが送信される。このHTTPリクエストメッセージでは、図３に示したように、１行目のリクエスト行にHTTPのバージョンとして、メジャー番号が「１」でマイナー番号が本発明の固有の「XX」であるHTTP/1.XX（例えば、HTTP/1.2）が記述され、メジャー番号「１」に対応した最新バージョンのHTTP/1.1に準拠した手順で送信される。

【0035】

当該HTTPリクエストメッセージを受信したサーバでは、リクエスト行に記述されているHTTPバージョンを参照し、ここでは要求されたバージョン"HTTP/1.XX"に自身が対応していると判定されるので、時刻t3において、図４に示したHTTPレスポンスメッセージが送信される。本実施形態では、HTTPレスポンスメッセージの１行目のステータス行に、"HTTP/1.XX"による通信が可能である"旨のメッセージとして「HTTP/1.XX 200 OK」が記述され、さらに要求されたコンテンツ（HTMLファイル）がメッセージボディに記述されている。

【0036】

当該HTTPレスポンスメッセージを受信したクライアントでは、そのステータス行に「HTTP/1.XX 200 OK」が記述されていることから、サーバがHTTP/2.0にも対応していることを認識し、時刻t4において、HTTP/2.0による接続準備として24ByteのMagic codeをサーバへ送信する。

【0037】

時刻t5では、サーバからクライアントへ、初期ウィンドウサイズやストリームの最大同時オープン数などの情報を含むSETTINGSフレームが送信されてHTTP/2.0の初期情報が交換される。時刻t6では、クライアントからサーバへ、HTTP/2.0によるコンテンツ要求が送信されてHTTP/2.0に準拠したコンテンツ配信が継続される。

【0038】

本実施形態によれば、クライアントがコンテンツ配信を要求するHTTPリクエストメッセージのリクエスト行に、HTTPバージョンとして固有のマイナバージョン"HTTP/1.XX"を記述して送信すると、これを受信したサーバは、要求されたコンテンツの少なくとも一部をHTTPレスポンスメッセージに登録して配信する。したがって、既存のHTTPを改修することなく、ネゴシエーション時にもコンテンツ配信が行えるようになるので、Webコンテンツの高速配信が実現される。

【0039】

図５は、クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応の場合のHTTP接続手順を示したシーケンスフローであり、図６は、サーバからクライアントへ送信されるHTTPレスポンスメッセージの一例を示している。

【0040】

時刻t1では３ハンドシェークによる接続処理が実行され、時刻t2では、前記図３と同様に、１行目のリクエスト行にHTTPのバージョンとしてHTTP/1.XXの記述されたHTTPリクエストメッセージが、HTTP/1.1に準拠した手順でクライアントからサーバへ送信される。

【0041】

前記HTTPリクエストメッセージを受信したサーバは、要求されたバージョンHTTP/1.XXに対応していないので、時刻t3において、"HTTP/1.1"による通信が可能である"旨のメッセージとしてHTTP/1.1 200 OKの記述されたHTTPレスポンスメッセージを送信する。クライアントは、前記HTTPレスポンスメッセージすると、時刻t4において、HTTP/1.1によるコンテンツ要求を送信するので、HTTP/1.1に準拠したコンテンツ配信が開始される。

【0042】

このように、本実施形態によれば、クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応の場合でも、従来のHTTP/1.1に対応していれば、HTTP/1.1によるコンテンツ配信が可能になる。

【0043】

図７は、クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応でHTTP/2.0に対応した場合のHTTP接続手順を示したシーケンスフローであり、図８は、サーバからクライアントへ送信されるHTTPレスポンスメッセージの一例を示している。

【0044】

時刻t1では３ハンドシェークによる接続処理が実行され、時刻t2では、前記図３と同様に、１行目のリクエスト行にHTTPのバージョンとしてHTTP/1.XXの記述されたHTTPリクエストメッセージが、HTTP/1.1に準拠した手順でクライアントからサーバへ送信される。

【0045】

前記HTTPリクエストメッセージを受信したサーバは、要求されたバージョンHTTP/1.XXに対応していないので、時刻t3において、アップグレードを要求する旨のメッセージとして、図８に示したように、ステータス行に" 101 Switching Protocols "が記述され、メッセージボディにHTTP/2.0へのアップグレードを要求する旨のメッセージとして" Upgrade : HTTP/2.0 "の記述されたHTTPレスポンスメッセージを送信する。

【0046】

当該HTTPレスポンスメッセージを受信したクライアントでは、サーバが"HTTP/2.0"に対応していることを認識し、時刻t4において、HTTP/2.0による接続準備として24ByteのMagic codeをサーバへ送信する。

【0047】

時刻t5では、サーバからクライアントへ、初期ウィンドウサイズやストリームの最大同時オープン数などの情報を含むSETTINGSフレームが送信されてHTTP/2.0の初期情報が交換される。時刻t6では、クライアントからサーバへ、HTTP/2.0によるコンテンツ要求が送信されてHTTP/2.0に準拠したコンテンツ配信が継続される。

【0048】

本実施形態によれば、クライアントのみが本発明のHTTP通信方式に対応し、サーバが非対応の場合でも、従来のHTTP/2.0に対応していれば、HTTP/2.0によるコンテンツ配信が可能になる。

【符号の説明】

【0049】

１…HTTPクライアント，２…HTTPサーバ，１０１…リクエストメッセージ生成部，１０２…メッセージ送受信部，１０３…コンテンツ抽出部，１０４、２０３…通信実行部，２０１…メッセージ送受信部，２０２…レスポンスメッセージ生成部，２０２ａ…コンテンツ登録部，２０４…コンテンツDB

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】