HTTP/2

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 ]}

FreeBSDとVarnishの開発者であるPoul-Henning Kampは、標準規格が非現実的に短いスケジュールで準備されたため、SPDYプロトコル以外の新しいHTTP/2の基盤が排除され、改善の機会が他にも失われたと主張している。Kampは、プロトコル自体が一貫性がなく、不必要に複雑すぎると批判している。また、プロトコルがプロトコル階層化の原則に違反しているとも述べており、例えば、トランスポート層（TCP）に属するフロー制御を重複させている。さらに、新しいプロトコルではHTTP Cookieを削除すべきだったが、これは破壊的変更であると示唆している。^{[ 49 ]}

当初、ワーキンググループの一部のメンバーは、プロトコルに暗号化要件を導入しようと試みたが、批判に直面した。

批評家は、暗号化には無視できない計算コストがかかり、多くの HTTP アプリケーションは実際には暗号化を必要とせず、プロバイダーも追加のリソースをそれに費やすことを望んでいないと述べた。暗号化の支持者は、この暗号化のオーバーヘッドは実際には無視できると述べている。^{[ 50 ]}ポール・ヘニング・カンプは、政治的な考慮から IETF が Google の SPDY プロトタイプを HTTP/2 として性急に標準化したことを批判した。^{[ 49 ] [ 51 ] [ 52 ]}既存の証明書フレームワーク内での強制暗号化の議題に対する批判は新しいものではなく、オープンソース コミュニティのメンバーに限ったものでもない。シスコの従業員は 2013 年に、現在の証明書モデルはルーターなどの小型デバイスと互換性がないと述べた。現在のモデルでは、証明書ごとに毎年登録して少額ではない料金を免除する必要があるだけでなく、毎年継続的に繰り返さなければならないからである。^{[ 53 ]}結局、ワーキンググループは強制的な暗号化について合意に至らなかったが、^{[ 46 ]}ほとんどのクライアント実装では暗号化が要求されるため、暗号化は事実上の要件となっている。 

HTTP/2 プロトコルは、SMTPなどの他のインターネット プロトコルで長年利用可能であった STARTTLS メカニズムと同様の受動的監視対策である機会的暗号化をサポートしていないことでも批判に直面しました。批評家は、HTTP/2 の提案は、ベスト 現在のプラクティス188のステータスでもある IETF のRFC 7258「遍在的監視は攻撃である」に違反していると述べています。 ^{[ 54 ]} RFC7258/BCP188 は、遍在的監視を攻撃とみなすことを義務付けており、IETF が設計したプロトコルは、受動的監視から保護するための措置 (たとえば、機会的暗号化の使用による) を講じる必要があります。HTTP/2 の機会的暗号化に関する仕様がいくつか提供されており、^{[ 55 ] [ 56 ] [ 57 ]}そのうち draft-nottingham-http2-encryption がワーキング グループの公式作業項目として採用され、2017 年 5 月にRFC 8164が公開されました。  

HTTP/2 の設計では、複数の同時 HTTP トランザクションを許可することで HTTP トランザクション レベルのヘッド オブ ライン ブロッキング問題に効果的に対処していますが、それらのトランザクションはすべて単一の TCP 接続上で多重化されるため、TCP ストリームのパケット レベルのヘッド オブ ライン ブロッキングが発生すると、その接続を介してアクセスされるすべてのトランザクションが同時にブロックされます。HTTP/2 のこのヘッド オブ ライン ブロッキングは現在、設計上の欠陥として広く認識されており、QUICおよびHTTP/3の開発努力の多くは、ヘッド オブ ライン ブロッキングの問題を軽減することに費やされています。^{[ 58 ] [ 59 ]}

以下のウェブサーバーは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 Traffic Server ^{[ 65 ]}
• キャディ^{[ 66 ]}
• Charles ProxyはバージョンCharles 4以降で利用可能です。^{[ 67 ]}
• Citrix NetScaler 11.x ^{[ 68 ]}
• スクリ^{[ 69 ]}
• F5 BIG-IP ローカルトラフィックマネージャー 11.6 ^{[ 70 ]}
• Barracuda Networks WAF (Webアプリケーションファイアウォール) ^{[ 71 ]}
• h2o（HTTP/2サポートのためにゼロから構築）^{[ 72 ]}
• HAProxy 1.8 ^{[ 73 ]}
• 桟橋9.3 ^{[ 74 ]}
• lighttpd 1.4.56 ^{[ 75 ]}
• LiteSpeed Web Server 5.0 ^{[ 76 ]}
• Microsoft IIS (Windows 10、^{[ 77 ]} Windows Server 2016、およびWindows Server 2019 )
• Netty 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 ]}
• Proxygen
• Pulse Secure Virtual Traffic Manager 10.2 ^{[ 86 ]}
• Radware Alteon NG ^{[ 87 ]}
• シマーキャット^{[ 88 ]}
• Vert.x 3.3
• Warp（HaskellのWebサーバー。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 Server Push をサポートした最初の主要な 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にまとめられています。