| 国際標準 | RFC 9113 |
|---|---|
| 開発者 | IETF |
| 紹介された | 2015年5月14日 (2015-05-14) |
| 代替 | HTTP/3 |
| Webサイト | https://http2.github.io/ |
HTTP/2(当初はHTTP/2.0という名前でした)は、ワールド ワイド ウェブで使用されるHTTPネットワーク プロトコルのメジャー リビジョンです。これは、元々 Googleによって開発された、以前の実験的なSPDYプロトコルから派生したものです。[1] [2] HTTP/2 は、インターネット技術タスク フォース(IETF)の HTTP ワーキング グループ (httpbis とも呼ばれ、"bis" はラテン語で "2 回" を意味します)によって開発されました。 [3] [4] [5] HTTP/2 は、1997 年にRFC 2068で標準化された HTTP/1.1 以来、最初の新しいバージョンの HTTP です。ワーキング グループは、2014 年 12 月に HTTP/2 を標準案として検討するためにインターネット技術運営グループ(IESG) に提示し、 [6] [7] IESG は 2015 年 2 月 17 日に標準案として公開することを承認しました最初のHTTP/2仕様は2015年5月14日にRFC 7540として公開されました。[8]
この標準化の取り組みは、Chrome、Opera、Firefox、Internet Explorer 11、Safari、Amazon Silk、Edgeブラウザによってサポートされました。2015年末までに、ほとんどの主要ブラウザがHTTP/2のサポートを追加しました。[9]使用されているウェブブラウザの約97%(および「追跡されたデスクトップ」ウェブブラウザの100%)がこの機能を備えています。[9] 2023年7月現在[update]、上位1,000万のウェブサイトのうち36%(50%強でピークに達した後)がHTTP/2をサポートしています。[10]
その後継はHTTP/3であり、HTTP/2で確立された概念に基づいて構築された主要な改訂版です。[2] [11] [9] [12]
目標
ワーキンググループの憲章には、いくつかの目標と懸念事項が記載されている。[4]
- クライアントとサーバーが HTTP/1.1、2.0、またはその他の非 HTTP プロトコルの使用を選択できるようにするネゴシエーション メカニズムを作成します。
- HTTP/1.1 との高度な互換性を維持します (たとえば、メソッド、ステータス コード、URI、ほとんどのヘッダー フィールドなど)。
- 次の点を考慮して、待ち時間を短縮し、 Web ブラウザでのページの読み込み速度を向上させます。
- HTTPヘッダーのデータ圧縮
- HTTP/2 サーバープッシュ
- リクエストの優先順位付け
- 単一のTCP接続で複数のリクエストを多重化する( HTTP 1.x のHTTP トランザクション レベルのヘッドオブライン ブロッキングの問題を修正)
- デスクトップ Web ブラウザー、モバイル Web ブラウザー、Web API、さまざまな規模のWeb サーバー、プロキシ サーバー、リバース プロキシサーバー、ファイアウォール、コンテンツ配信ネットワークなど、HTTP の一般的な既存のユース ケースをサポートします。
HTTP/1.1との違い
これらの変更は既存のウェブアプリケーションの動作に変更を加える必要はなく、新しいアプリケーションは新機能を利用して速度を向上させることができます。[13] HTTP/2は、メソッド、ステータスコード、ヘッダーフィールド、URIなど、HTTP/1.1の高レベルセマンティクスをすべてそのまま残しています。新しいのは、クライアントとサーバー間でデータがフレーム化され、転送される方法です。[13]
効率的なウェブサイトは、画像やスクリプトなどのリソースを縮小(コード量を削減し、小さなコード片をバンドルにまとめるが、機能を損なうことはない)することで、ページ全体のレンダリングに必要なリクエスト数を最小限に抑えています。しかし、縮小は必ずしも便利でも効率的でもなく、ページと縮小されたリソースを取得するために別々のHTTP接続が必要になる場合があります。HTTP/2では、サーバーがコンテンツを「プッシュ」、つまりクライアントが要求したよりも多くのクエリに対してデータを返すことが可能になります。これにより、サーバーは、ブラウザが最初のレスポンスを確認するのを待つことなく、追加のリクエストサイクルのオーバーヘッドなしに、ウェブブラウザがウェブページをレンダリングするために必要なデータを提供できます。[14]
HTTP/2の最初のドラフト(SPDYのコピー)では、リクエストとレスポンスの多重化によってHTTP 1のヘッドオブラインブロッキング問題(HTTPパイプライン使用時でも)の一部を回避すること、ヘッダー圧縮、リクエストの優先順位付けなどにより、さらなるパフォーマンス向上が図られています。[15]しかし、HTTP/2は単一のTCP接続上で実行されるため、TCPパケットが送信中に失われたり遅延したりすると、ヘッドオブラインブロッキングが発生する可能性があります。[16] HTTP/2は、データストリーミングのためのより効率的な独自のメカニズムを提供するため、HTTP/1.1のチャンク転送エンコーディングメカニズムをサポートしなくなりました。[17]
歴史
SPDYの起源とその後のSPDYとの違い
SPDY (「スピーディー」と発音)は、 Googleが主導する研究プロジェクトによって開発された、HTTPを代替するプロトコルでした。[18]主にレイテンシの削減に焦点を当てたSPDYは、同じTCPパイプを使用しながらも異なるプロトコルを使用することで、このレイテンシの削減を実現しています。SPDYを作成するためにHTTP/1.1に加えられた基本的な変更には、「FIFO制限のない真のリクエストパイプライン、クライアントとサーバーの開発を簡素化するメッセージフレーミングメカニズム、強制圧縮(ヘッダーを含む)、優先度スケジューリング、さらには双方向通信」が含まれていました。[19]
HTTPワーキンググループは、GoogleのSPDYプロトコル、MicrosoftのHTTP Speed+Mobility提案(SPDYベース)[18] 、およびNetwork-Friendly HTTP Upgrade [20]を検討しました。 2012年7月、Facebookは各提案に対するフィードバックを提供し、HTTP/2をSPDYベースにすることを推奨しました。[21] HTTP/2の最初のドラフトは2012年11月に公開され、SPDYの直接コピーに基づいていました。[22]
HTTP/1.1とSPDYの最大の違いは、SPDYにおける各ユーザーアクションに「ストリームID」が付与される点です。つまり、ユーザーとサーバーを接続するTCPチャネルは1つだけです。SPDYは、「2種類のフレームを持つ、解析しやすいバイナリプロトコル」を使用して、リクエストを制御リクエストとデータリクエストに分割します。[19] [23] SPDYはHTTPと比べて明らかな改善を示し、新しいページの読み込み速度は11%から47%向上しました。[24]
HTTP/2の開発は、SPDYを出発点としました。両プロトコル間の詳細な違いは数多くありますが、最も注目すべきは、HTTP/2がSPDYの動的なストリームベースの圧縮ではなく、固定のハフマンコードベースのヘッダー圧縮アルゴリズムを使用していることです。これにより、 CRIME攻撃などの圧縮オラクル攻撃の可能性を低減できます。[23]
2015年2月9日、GoogleはChromeでSPDYのサポートを削除し、HTTP/2のサポートに移行する計画を発表しました。[25]これはChrome 51から有効になりました。[26] [27]
開発のマイルストーン
| 日付 | マイルストーン[4] |
|---|---|
| 2007年12月20日[28] [29] | HTTP/1.1 改訂版インターネット ドラフト |
| 2008年1月23日[30] | HTTPセキュリティプロパティのインターネットドラフト |
| 2012年初頭[31] | HTTP 2.0 の提案募集 |
| 2012年10月14日~11月25日[32] [33] | HTTP/1.1 改訂ワーキンググループ最終呼びかけ |
| 2012年11月28日[34] [35] | HTTP 2.0 の最初の WG ドラフト (draft-mbelshe-httpbis-spdy-00 に基づく) |
| 保持/排除 | HTTP セキュリティ プロパティに関するワーキング グループ最終呼びかけ |
| 2013年9月[36] [37] | HTTP/1.1 改訂版をIESGに提出し、標準案として検討する |
| 2014年2月12日[38] | IESGはHTTP/1.1改訂版を標準案として公開することを承認した |
| 2014年6月6日[28] [39] | HTTP/1.1 リビジョンをRFC 7230、7231、7232、7233、7234、7235 として公開 |
| 2014年8月1日~2014年9月1日[7] [40] | HTTP/2ワーキンググループ最終呼びかけ |
| 2014年12月16日[6] | HTTP/2 を IESG に提出し、標準提案として検討する |
| 2014年12月31日~2015年1月14日[41] | IETF HTTP/2 最終呼びかけ |
| 2015年1月22日[42] | IESGテレチャットでHTTP/2を標準案として検討 |
| 2015年2月17日[43] | IESGはHTTP/2を標準案として公開することを承認した |
| 2015年5月14日[44] | HTTP/2をRFC 7540 として公開する |
| 2020年2月 | RFC 8740: HTTP/2 と TLS 1.3 |
| 2022年6月 | RFC 9113: さらなる改良 |
| 2024年4月 | CONTINUATION フレームに関する DOS の問題 https://kb.cert.org/vuls/id/421644 |
暗号化
HTTP/2は、HTTP URI(TLS暗号化なし、 h2cと略される構成)とHTTPS URI(TLS 1.2以降が必要なALPN拡張[45]を使用したTLS経由、 h2と略される構成)の両方に対して定義されています。
標準規格自体は暗号化の使用を必須としていないものの、[46]主要なクライアント実装(Chrome、Edge、Firefox、[47] Internet Explorer、Opera、Safari)はすべて、TLS経由のHTTP/2のみをサポートすると表明しており、事実上暗号化が必須となっている。[48]
批判
開発プロセス
FreeBSDとVarnishの開発者であるPoul-Henning Kamp氏は、この標準規格が非現実的なほど短い期間で策定されたため、新しいHTTP/2の基盤としてSPDYプロトコル以外のものがなく、結果として他の改善の機会を逃したと主張している。Kamp氏は、プロトコル自体が一貫性に欠け、不必要で圧倒的な複雑さを抱えていると批判している。また、このプロトコルはプロトコル階層化原則に違反しており、例えばトランスポート層(TCP)に属するフロー制御を重複させている点も指摘している。さらに、新しいプロトコルではHTTP Cookieを削除すべきだったと示唆し、互換性を破る変更を導入すべきだったと指摘している。[49]
暗号化
当初、ワーキンググループの一部のメンバー(誰?)がプロトコルに暗号化要件を導入しようと試みましたが、批判を受けました。
批評家は、暗号化には無視できないコンピューティング コストがかかり、多くの HTTP アプリケーションは実際には暗号化を必要とせず、プロバイダーは追加のリソースを費やすことを望んでいないと述べています。暗号化の支持者は、この暗号化のオーバーヘッドは実際には無視できるほど小さいと述べています。[50] Poul-Henning Kamp は、政治的な配慮から Google の SPDY プロトタイプを HTTP/2 として急いで標準化したとして IETF を批判しました。[49] [51] [52]既存の証明書フレームワーク内での暗号化の強制という議題に対する批判は新しいものではなく、オープンソース コミュニティのメンバーに特有のものでもありません。シスコの従業員は 2013 年に、現在の証明書モデルでは証明書ごとに毎年の登録と少額ではない料金の免除が必要になるだけでなく、毎年継続的に繰り返さなければならないため、ルータなどの小型デバイスと互換性がないと述べています。[53]結局、ワーキンググループは強制的な暗号化について合意に達しなかったが、[46]ほとんどのクライアント実装では暗号化が必須であるため、暗号化は事実上の要件となっている。
HTTP/2プロトコルは、STARTTLSメカニズムに類似した受動的な監視対策である日和見暗号化をサポートしていないことでも批判にさらされた。このメカニズムはSMTPなどの他のインターネットプロトコルで以前から利用可能であった。批評家は、HTTP/2の提案はIETF自身のRFC 7258「Pervasive Monitoring Is an Attack(広範囲にわたる監視は攻撃である)」に違反していると主張している。RFC 7258はBest Current Practice 188のステータスも持っている。 [54] RFC7258/BCP188は、広範囲にわたる監視を攻撃と見なすことを義務付けており、IETFが設計するプロトコルは受動的な監視に対する保護策(例えば、日和見暗号化の使用を通じて)を講じるべきである。HTTP/2の日和見暗号化に関する多くの仕様が提供されており、[55] [56] [57]そのうちdraft-nottingham-http2-encryptionがワーキンググループの公式作業項目として採用され、 2017年5月にRFC 8164が公開された。
TCPヘッドオブラインブロッキング
HTTP/2の設計は、複数のHTTPトランザクションの同時実行を可能にすることで、HTTPトランザクションレベルのヘッドオブラインブロッキング問題に効果的に対処していますが、これらのトランザクションはすべて単一のTCP接続上で多重化されるため、TCPストリームのパケットレベルのヘッドオブラインブロッキングは、その接続を介してアクセスされるすべてのトランザクションを同時にブロックしてしまいます。HTTP/2におけるこのヘッドオブラインブロッキングは現在、設計上の欠陥であると広く認識されており、QUICとHTTP/3の開発努力の多くは、ヘッドオブラインブロッキング問題の軽減に注力されてきました。[58] [59]
サーバー側のサポート
サーバーソフトウェア
次の Web サーバーは HTTP/2 をサポートしています。
- Apache httpd 2.4.12はモジュールmod_h2を介してHTTP/2をサポートしていますが[60] 、このモジュールをサポートするには、サーバーのソースコードに適切なパッチを適用する必要があります。Apache 2.4.17以降、すべてのパッチはApacheのメインソースツリーに含まれていますが、モジュール自体はmod_http2に改名されました[61] 。SPDYの旧バージョンはモジュールmod_spdyを介してサポートされていましたが[62]、mod_spdyモジュールの開発は停止しています[63] 。
- Apache Tomcat 8.5(設定変更が必要)[64]
- Apacheトラフィックサーバー[65]
- キャディ[66]
- Charles Proxyバージョン Charles 4 以降。[67]
- Citrix NetScaler 11.x [68]
- スクリ[69]
- F5 BIG-IP ローカルトラフィックマネージャ 11.6 [70]
- バラクーダネットワークスWAF(ウェブアプリケーションファイアウォール)[71]
- h2o(HTTP/2サポートのためにゼロから構築)[72]
- HAProxy 1.8 [73]
- ジェティ9.3 [74]
- lighttpd 1.4.56 [75]
- LiteSpeedウェブサーバー5.0 [76]
- Microsoft IIS (Windows 10、[77] Windows Server 2016、Windows Server 2019 )
- ネッティ4.1 [78]
- nghttpd (HTTP/2のみを実装)
- nginx 1.9.5 [79]は2015年9月22日にリリースされ、 2018年2月20日のバージョン1.13.9以降、モジュールngx_http_v2_moduleとHTTP/2 Server Pushを使用しています。[80]
- Node.js 8.13.0 [81] (Node.js 5.0 [82]には別のモジュールが用意されており、Node 8.4ではHTTP/2の実験的な組み込みサポートが導入されました。[83])
- ASP.NET Core用のKestrelウェブサーバーは、.NET Core 2.2.0-preview 1以降、HTTP/2をサポートしています。[84]
- OpenLiteSpeed 1.3.11および1.4.8 [85]
- プロキシゲン
- パルスセキュア仮想トラフィックマネージャー10.2 [86]
- ラドウェアアルテオン NG [87]
- シマーキャット[88]
- Vert.x 3.3
- Warp ( Haskellウェブサーバー、Yesodではデフォルトで使用される)
- ワイルドフライ9
- 特使代理
コンテンツ配信ネットワーク
- Akamai は、HTTP/2 とHTTP/2 サーバー プッシュをサポートした最初の大手 CDN です。
- Microsoft Azureは HTTP/2 をサポートしています。
- PageCDNはHTTP/2を標準でサポートしており、CDNダッシュボードでHTTP/2サーバープッシュを設定するためのユーザーインターフェースを提供しています。[89]
- CDN77 は nginx を使用して HTTP/2 をサポートします(2015 年 8 月 20 日)。
- Cloudflareは、サポートされていないブラウザのフォールバックとして、SPDYを使用したnginxを使用してHTTP/2をサポートし、セキュリティとパフォーマンスのすべてのサービスを維持しています。[90] Cloudflareは、HTTP/2サーバープッシュをサポートした最初の大手CDNでした。[91]
- AWS CloudFrontは2016年9月7日からHTTP/2 [92]をサポートしています。
- Fastlyはサーバープッシュを含むHTTP/2をサポートしています。[93]
- Imperva Incapsula CDNはHTTP/2をサポートしています。[94]実装にはWAFとDDoS緩和機能のサポートも含まれています。
- KeyCDNはnginxを使用してHTTP/2をサポートします(2015年10月6日)。HTTP/2テストは、サーバーがHTTP/2をサポートしているかどうかを確認するためのテストページです。
- BrandSSL は HTTP/2 をサポートしています。
- Voxilityは2016年7月からnginxを使用したHTTP/2をサポートしています。この実装はクラウドDDoS緩和サービスのサポートに含まれています。[95]
- StackPath はHTTP/2 をサポートしています。
実装
- その他の実装は GitHub HTTP/2 wiki に集められています。
参照
- gRPC
- HTTPパイプライン
- HTTPリクエストとレスポンスメッセージ
- HTTP/3
- クイック
- スプディ
- ウェブソケット
- ウェブサーバー
- ウェブブラウザ
- ウェブブラウザの比較 § プロトコルサポート
参考文献
- ^ Bright, Peter (2015年2月18日). 「HTTP/2が完成、数週間以内にブラウザーに登場」Ars Technica . 2019年3月30日時点のオリジナルよりアーカイブ。
- ^ ab Cimpanu, Catalin (2018年11月12日). 「HTTP-over-QUIC、HTTP/3に名称変更」ZDNet . 2018年11月19日閲覧。
- ^ Thomson, M.; Belshe, M.; Peon, R. (2014年11月29日). 「Hypertext Transfer Protocol version 2: draft-ietf-httpbis-http2-16」. Ietf Datatracker . HTTPbisワーキンググループ. 2015年2月11日閲覧。
- ^ abc “HTTP (httpbis)”. Internet Engineering Task Force Datatracker. 2024年1月6日時点のオリジナルよりアーカイブ。
- ^ 「IETF HTTPワーキンググループ」httpwg.org . 2019年12月15日閲覧。
- ^ ab "history for draft-ietf-httpbis-http2-16". IETF . 2015年1月3日閲覧。
2014年12月16日 IESGの状態が「Publication Requested」に変更されました。
- ^ ab Raymor, Brian (2014年8月6日). 「待ってください – HTTP/2ワーキンググループ最終呼び出し開始!」Microsoft Open Technologies. 2014年10月6日時点のオリジナルよりアーカイブ。2018年10月17日閲覧。
- ^ Belshe, M.; Peon, R.; Thomson, M. (2015年5月). Thomson, M (編). "RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)". IETF. doi : 10.17487/RFC7540 . 2015年5月14日閲覧。
- ^ abc 「HTTP/2」は使えますか?HTML5、CSS3などのテーブルをサポートします」。canIuse.com 。2023年4月3日閲覧。
- ^ 「ウェブサイトにおけるHTTP/2の利用状況」。ワールドワイドウェブ技術調査。W3Techs 。 2023年7月10日閲覧。
- ^ Bishop, Mike (2019年7月9日). 「Hypertext Transfer Protocol Version 3 (HTTP/3)」. Ietf Datatracker . 2019年7月31日閲覧。
- ^ Cimpanu, Catalin (2019年9月26日). 「Cloudflare、Google Chrome、FirefoxがHTTP/3のサポートを追加」ZDNet . 2019年9月27日閲覧。
- ^ ab Ilya Grigorik. 「第12章 HTTP 2.0」.高性能ブラウザネットワーキング. O'Reilly Media, Inc.
HTTP/2はHTTPのアプリケーションセマンティクスを一切変更しません。
- ^ Pratt, Michael. 「Apiux」. apiux.com . 2014年3月19日閲覧。
- ^ Dio Synodinos (2012年11月). 「HTTP 2.0 ファーストドラフト公開」. InfoQ.com . C4Media Inc.
- ^ Javier Garza (2017年10月). 「HTTP/2はヘッドオブラインブロッキング(HOL)問題をどのように解決するのか」
- ^ ベルシェ, マイク; トムソン, マーティン; ペオン, ロベルト (2015年5月). トムソン, M. (編). 「ハイパーテキスト転送プロトコル バージョン2 (HTTP/2)」. tools.ietf.org . doi : 10.17487/RFC7540 . 2017年11月17日閲覧.
HTTP/2は、メッセージペイロードを伝送するためにDATAフレームを使用します。[RFC7230]のセクション4.1で定義されている「チャンク」転送エンコーディングは、HTTP/2では使用してはいけません。
- ^ ab Sebastian Anthony (2012年3月28日). 「S&M vs. SPDY: MicrosoftとGoogle、HTTP 2.0の将来をめぐって争う」ExtremeTech.
- ^ ab Grigorik, Ilya. 「HTTP 1.1 の先にある世界: Google の SPDY」
- ^ Willy Tarreau、Amos Jeffries、Adrien de Croy、Poul-Henning Kamp (2012年3月29日). 「ネットワークフレンドリーなHTTPアップグレードの提案」.ネットワークワーキンググループ.インターネットエンジニアリングタスクフォース.
- ^ Doug Beaver (2012年7月15日). 「HTTP2 Expression of Interest」(メーリングリスト). W3C.
- ^ Dio Synodinos (2012年11月30日). 「HTTP/2 ファーストドラフト公開」. InfoQ.
- ^ ab Ilya, Grigorik (2015). HTTP/2 : a new excerpt from high performance browser networking (May 2015, First ed.). Sebastopol, California: O'Reilly Media. pp. 211– 224. ISBN 9781491932483. OCLC 1039459460.
- ^ 「SPDY: より高速なウェブのための実験的プロトコル」。Chromiumプロジェクト。
- ^ Chris Bentzel、Bence Béky (2015年2月9日). 「Hello HTTP/2, Goodbye SPDY」. Chromium Blog .
更新:Chromeのリリースサイクルに合わせるため、Chrome 51のリリースでSPDYとNPNのサポートが削除されます。
- ^ 「Chrome 51 での API の廃止と削除」。
要約: HTTP/2 のサポートは広く普及しているため、SPDY/3.1 のサポートは廃止できます。
- ^ Shadrin, Nick (2016年6月7日). 「Google Chromeユーザー向けHTTP/2サポート | NGINX」. NGINX . 2017年7月10日閲覧。
- ^ Nottingham, Mark (2014年6月7日). 「RFC2616は死んだ」 . 2014年9月20日閲覧。
- ^ 「HTTP/1.1 パート1:URI、接続、およびメッセージ解析:draft-ietf-httpbis-p1-messaging-00」。2007年12月20日。 2014年9月20日閲覧。
- ^ 「HTTPセキュリティ要件:draft-ietf-httpbis-security-properties-00.txt」2008年1月23日。 2014年9月20日閲覧。
- ^ Nottingham, Mark (2012年1月24日). 「HTTPbisの再憲章」 . 2014年9月20日閲覧。
- ^ Nottingham, Mark (2012年10月14日). 「HTTP/1.1 p1およびp2ワーキンググループ最終勧告」 . 2014年9月20日閲覧。
- ^ Nottingham, Mark (2012年10月23日). 「Second Working Group Last Call for HTTP/1.1 p4 to p7」 . 2014年9月20日閲覧。
- ^ 「SPDYプロトコル:draft-ietf-httpbis-http2-00」。HTTPbisワーキンググループ。2012年11月28日。 2014年9月20日閲覧。
- ^ Nottingham, Mark (2012年11月30日). 「HTTP/2の最初のドラフト」 . 2014年9月20日閲覧。
- ^ Fielding, Roy T.; Reschke, Julian (2014年6月6日). 「Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing」. 2014年8月13日時点のオリジナルよりアーカイブ。 2014年9月20日閲覧。
- ^ 「最終改訂版: <draft-ietf-httpbis-p1-messaging-24.txt> (ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング) の標準提案」IESG. 2013年10月21日. 2014年9月20日閲覧。
- ^ 「プロトコルアクション: 『ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング』から標準提案 (draft-ietf-httpbis-p1-messaging-26.txt) へ」ietf-announce (メーリングリスト). IESG. 2014年2月12日. 2015年1月18日閲覧。
- ^ RFCエディターチーム(2014年6月6日)「RFC 7230 ハイパーテキスト転送プロトコル(HTTP/1.1):メッセージ構文とルーティング」ietf-announce(メーリングリスト) . 2015年1月18日閲覧。
- ^ Nottingham, Mark (2014年8月1日). 「ワーキンググループ最終提案: draft-ietf-httpbis-http2-14 および draft-ietf-httpbis-header-compression-09」. HTTPワーキンググループ. 2014年9月7日閲覧。
- ^ 「最終決定: <draft-ietf-httpbis-http2-16.txt> (ハイパーテキスト転送プロトコル バージョン 2) IESG による 2014 年 12 月 31 日の標準提案」。インターネット技術タスクフォース。2014 年。2015年1 月 1 日閲覧。
- ^ “IESG Agenda: 2015-01-22”. IETF. 2015年1月15日時点のオリジナルよりアーカイブ。2015年1月15日閲覧。
- ^ IESG (2015年2月17日). 「プロトコルアクション: 『ハイパーテキスト転送プロトコル バージョン2』から標準提案 (draft-ietf-httpbis-http2-17.txt)」. httpbis (メーリングリスト) . 2015年2月18日閲覧。
- ^ RFCエディターチーム(2015年5月14日)。「RFC 7540 ハイパーテキスト転送プロトコルバージョン2(HTTP/2)について」。ietf -announce(メーリングリスト)。
- ^ Friedl, S.; Popov, A.; Langley, A.; Stephan, E. (2014年7月). 「RFC 7301 - トランスポート層セキュリティ(TLS)アプリケーション層プロトコルネゴシエーション拡張」. IETF. doi : 10.17487/RFC7301 .
- ^ ab 「HTTP/2 よくある質問」IETF HTTPワーキンググループ. 2014年9月8日閲覧。
- ^ “Networking/http2”. MozillaWiki . 2014年9月7日閲覧。
- ^ 「HTTP/2 実装状況」。mnotのブログ。
- ^ ab Kamp, Poul-Henning (2015年1月6日). 「HTTP/2.0 – IETFは電話で話を聞いている(悪いプロトコル、悪い政治). ACM Queue . 第13巻第2号. pp. 10– 12. doi : 10.1145/2732266.2716278 . ISSN 1542-7730.
- ^ Grigorik, Ilya. 「TLSはまだ高速か?」2015年12月30日閲覧。
- ^ Kamp, Poul-Henning (2015). 「Http/2.0」. Communications of the ACM . 58 (3): 40. doi : 10.1145/2717515 . S2CID 20337779.
- ^ Kamp, Poul-Henning (2015年1月7日). 「Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard」[email protected] (メーリングリスト) . 2015年1月12日閲覧。
- ^ Lear, Eliot (2013年8月25日). 「強制暗号化は演劇である」. [email protected] (メーリングリスト) . 2015年1月26日閲覧。
- ^ Murenin, Constantine A. (2015年1月9日). 「Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard」. [email protected] (メーリングリスト) . 2015年1月12日閲覧。
- ^ Paul Hoffman. 「HTTP-2向け最小限の認証なし暗号化(MUE):draft-hoffman-httpbis-minimal-unauth-enc-01」インターネット技術タスクフォース。
- ^ Mark Nottingham、Martin Thomson。「HTTP URIの便宜的暗号化:draft-nottingham-http2-encryption-03」。インターネット技術タスクフォース。
- ^ Mark Nottingham、Martin Thomson。「HTTPのOpportunistic Security: draft-ietf-httpbis-http2-encryption-01」。IETFデータトラッカー。インターネット技術タスクフォース。
- ^ Huston, Geoff (2019年3月4日). 「QUICの概要」www.circleid.com . 2019年8月2日閲覧。
- ^ Gal, Shauli (2017年6月22日). 「HTTP/2とHOLブロッキングの全体像」Medium . 2019年8月3日閲覧。
- ^ 「Apache httpd用http/2モジュール」 。 2015年7月28日閲覧。
- ^ 「Apache 2.4.17リリースの変更ログ」 。 2017年8月22日閲覧。
- ^ Matthew Steele (2014年6月19日). 「mod_spdy は Apache プロジェクトになりました」. Google Developers Blog .
- ^ "/httpd/mod_spdy のログ". svn.apache.org . 2017年2月3日閲覧。
- ^ 「Apache Tomcat Migration」 。 2016年7月29日閲覧。
- ^ 「Apache Traffic Server ダウンロード」. trafficserver.apache.org . 2015年9月21日.
- ^ Server、Caddy Web (2016年3月23日). 「Caddy 2 - 自動HTTPS対応の究極のサーバー」. caddyserver.com . 2020年8月8日閲覧。
- ^ 「チャールズ4世はHTTP/2に対応」Public Object . 2016年8月2日. 2020年10月12日閲覧。
- ^ “3 Simple Steps to Bring HTTP/2 Performance to Legacy Web Applications”. 2015年9月22日. 2015年9月25日時点のオリジナルよりアーカイブ。 2018年11月19日閲覧。
- ^ 「Sucuri += HTTP/2 — HTTP/2サポートの発表」Sucuri . 2015年11月27日. 2015年12月5日閲覧。
- ^ Robert Haynes. 「SPDYにさよなら、HTTP/2にこんにちは」F5 Networks . 2015年9月18日閲覧。
- ^ Risov Chakrabortty (2016年7月5日). 「Barracuda Web Application Firewallに追加された新機能」. Barracuda Networks.
- ^ 「H2O - 最適化されたHTTP/2サーバー」h2o.examp1e.net。
- ^ 「HAProxy 1.8の新機能」haproxy.com、2017年11月。 2018年2月9日閲覧。
- ^ 「Jetty 変更ログ」. Eclipse Foundation. 2015年5月28日. 2015年5月28日閲覧。
- ^ 「機能 #2813: HTTP/2 プロトコルのサポート」、Lighttpd
- ^ 「LSWS 5.0 リリース – HTTP/2、ESI、LiteMage Cache をサポート」2015年4月17日。
- ^ Rob Trace、David Walp (2014年10月8日). 「HTTP/2:待望の続編」. MSDN IEBlog . Microsoft Corporation.
- ^ “Netty.news: Netty 4.1.0.Final リリース”. netty.io . 2016年6月1日閲覧。
- ^ "nginx changelog". www.nginx.com . 2015年9月22日.
- ^ “nginx 1.14.2 での変更点”. nginx.org . 2018年12月4日. 2019年9月27日閲覧。
- ^ Foundation, Node js (2018年11月20日). 「Node v8.13.0 (LTS)」. Node.js. 2019年6月5日閲覧。
- ^ “Node http2”. www.github.com . 2016年7月26日.
- ^ “Node v8.4.0 (Current)”. nodejs.org . 2017年8月15日.
- ^ 「ASP.NET Core 2.2.0-preview1: Kestrel の HTTP/2」 。 2021年4月6日閲覧。
- ^ “OpenLiteSpeed 1.4.5 変更ログ”. LiteSpeed Technologies, Inc. 2015年2月26日. 2015年2月26日時点のオリジナルよりアーカイブ。2015年2月26日閲覧。
- ^ 「Pulse Virtual Traffic Manager」. 2017年8月22日.
- ^ 「Radware、統合型HTTP/2ゲートウェイと先進のFastviewテクノロジーを組み合わせ、Webサーバープラットフォームの高速化を実現」2015年7月20日。
- ^ “www.shimmercat.com”. 2016年3月23日. 2022年3月31日時点のオリジナルよりアーカイブ。2016年3月23日閲覧。
- ^ 「なぜPageCDNなのか、そしてそれはどんな問題を解決してくれるのか?」PageCDN . 2020年1月11日閲覧。
- ^ 「HTTP/2が登場!SPDYはもう終わり?まだこれから」CloudFlare . 2015年12月5日閲覧。
- ^ Krasnov, Vlad (2016年4月28日). 「HTTP/2 サーバープッシュのサポートを発表」. CloudFlare . 2016年5月18日閲覧。
- ^ 「Amazon CloudFront が HTTP/2 をサポート」Amazon Web Services, Inc. 2016年9月8日閲覧。
- ^ 「HTTP/2の限定提供を発表」2016年6月30日. 2017年8月22日閲覧。
- ^ 「HTTP/2が登場:知っておくべきこと」 。 2015年11月1日閲覧。
- ^ 「HTTP/2はサイバー攻撃のリスクが高まるのか?」Information Age誌、2016年8月3日。 2019年2月4日閲覧。
外部リンク
- 公式サイト
- GitHubの HTTP/2
- RFC 7540 – ハイパーテキスト転送プロトコル バージョン 2 (HTTP/2)
- RFC 7541 – HPACK: HTTP/2 のヘッダー圧縮
- HTTP/2 の説明 ( Daniel Stenberg )
- SPDY プロトコル (draft-mbelshe-httpbis-spdy-00)
- HTTP スピード + モビリティ (draft-Montenegro-httpbis-speed-mobility-01)
- ネットワークフレンドリーな HTTP アップグレードの提案 (draft-tarreau-httpbis-network-friendly-00)