| 国際標準 | RFC9113の翻訳 |
|---|---|
| 開発者 | 国際電気通信連合 |
| 紹介された | 2015年5月14日 |
| 代替品 | HTTP/3 |
| Webサイト | 出典: http://www.github.io/ |
HTTP/2(当初はHTTP/2.0と名付けられていた)は、ワールドワイドウェブで使用されるHTTPネットワークプロトコルの大幅な改訂版です。これは、元々Googleによって開発された、以前の実験的なSPDYプロトコルから派生したものです。[1] [2] HTTP/2 は、インターネット技術タスクフォース(IETF)の HTTP ワーキンググループ (httpbis とも呼ばれ、"bis" は "twice" の意味) によって開発されました。 [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日に公開されました。[8]
標準化の取り組みは、Chrome、Opera、Firefox、Internet Explorer 11、Safari、Amazon Silk、Edgeブラウザによってサポートされました。ほとんどの主要ブラウザは、2015年末までにHTTP/2のサポートを追加しました。[9]使用されているウェブブラウザの約97%(および「追跡されたデスクトップ」ウェブブラウザの100%)にこの機能があります。[9] 2023年7月現在[アップデート]、上位1000万のウェブサイトのうち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 では、サーバーがコンテンツを「プッシュ」できます。つまり、クライアントが要求したよりも多くのクエリに対してデータで応答できます。これにより、サーバーは、ブラウザーが最初の応答を確認するのを待たずに、追加のリクエスト サイクルのオーバーヘッドなしで、Web ブラウザーが Web ページをレンダリングするために必要なデータを提供できます。[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]
開発のマイルストーン
暗号化
HTTP/2は、HTTP URI(TLS暗号化なし、 h2cで略される構成)とHTTPS URI(TLS 1.2以降が必要なALPN拡張[45]を使用したTLS経由、 h2で略される構成)の両方に対して定義されています。
標準規格自体は暗号化の使用を義務付けていないものの、[46]すべての主要なクライアント実装(Firefox、[47] Chrome、Safari、Opera、IE、Edge)は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の提案は、ベストカレントプラクティス188のステータスも持つIETF自身のRFC 7258「Pervasive Monitoring Is an Attack」に違反していると述べています。[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はバージョン4以降のCharles Proxyです。[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 Webサーバーは、.NET Core 2.2.0-preview 1以降でHTTP/2をサポートしています。[84]
- OpenLiteSpeed 1.3.11および1.4.8 [85]
- プロキシジェン
- パルスセキュア仮想トラフィックマネージャー10.2 [86]
- ラドウェアアルテオン NG [87]
- シマーキャット[88]
- ヴァート.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 Working Group . 2015 年2 月 11 日閲覧。
- ^ abc "HTTP (httpbis)". Internet Engineering Task Force Datatracker. 2024年1月6日時点のオリジナルよりアーカイブ。
- ^ 「IETF HTTPワーキンググループ」httpwg.org 。 2019年12月15日閲覧。
- ^ ab 「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 : 高性能ブラウザネットワーキングからの抜粋(2015年5月、初版)。カリフォルニア州セバストポル: O'Reilly Media。pp. 211–224。ISBN 9781491932483. OCLC 1039459460.
- ^ 「SPDY: より高速な Web のための実験的プロトコル」。Chromiumプロジェクト。
- ^ Chris Bentzel、Bence Béky (2015 年 2 月 9 日)。「Hello HTTP/2, Goodbye SPDY」。Chromiumブログ。
更新: Chrome のリリース サイクルに合わせるため、Chrome 51 のリリースで SPDY と NPN のサポートが削除されます。
- ^ 「Chrome 51 での API の非推奨と削除」。TL
;DR: HTTP/2 のサポートは広く普及しているため、SPDY/3.1 のサポートは廃止できます。
- ^ Shadrin, Nick (2016 年 6 月 7 日)。「Google Chrome ユーザー向け HTTP/2 のサポート | NGINX」。NGINX。2017年7月 10 日閲覧。
- ^ ab Nottingham, Mark (2014 年 6 月 7 日). 「RFC2616 is Dead」 . 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日). 「Rechartering 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 日閲覧。
- ^ 「Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard from The IESG on 2014-12-31」インターネット エンジニアリング タスク フォース。2014 年。2015 年1 月 1 日閲覧。
- ^ 「IESG アジェンダ: 2015-01-22」。IETF。2015年1月15日時点のオリジナルよりアーカイブ。 2015年1月15日閲覧。
- ^ IESG (2015 年 2 月 17 日)。「プロトコルアクション: 'Hypertext Transfer Protocol version 2' から Proposed Standard (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 は Phoning It In (Bad protocol, bad politics)」。 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」. ietf-http-wg@w3.org (メーリング リスト) . 2015 年1 月 12 日閲覧。
- ^ Lear, Eliot (2013 年 8 月 25 日). 「強制暗号化は演劇である」. ietf-http-wg@w3.org (メーリング リスト) . 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」. ietf-http-wg@w3.org (メーリング リスト) . 2015 年1 月 12 日閲覧。
- ^ Paul Hoffman. 「HTTP-2 向け最小限の認証なし暗号化 (MUE): draft-hoffman-httpbis-minimal-unauth-enc-01」。インターネット エンジニアリング タスク フォース。
- ^ Mark Nottingham、Martin Thomson。「HTTP URI の Opportunistic Encryption: 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 ブログ。
- ^ 「/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日閲覧。
- ^ 「Charles 4 には HTTP/2 があります」。Public Object。2016年 8 月 2 日。2020 年10 月 12 日閲覧。
- ^ 「レガシー Web アプリケーションに HTTP/2 パフォーマンスをもたらす 3 つの簡単な手順」。2015 年 9 月 22 日。
- ^ 「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 (現在)」。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 日閲覧。
- ^ 「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)
