# http2のコンセプト
http2は何を成し遂げたのでしょうか。HTTPbisはスコープの境界線をどこに引いたのでしょうか。
これらは極めて厳格であり、チームのイノベーションを厳しく制限するものでした。
* HTTPのパラダイムを保持しなければなりません。TCP上でクライアントがサーバーにリクエストを送信する形のプロトコルなのです。
* URLを変更することはできません。新しいスキームを導入することはできません。これらのURLを使うコンテンツは膨大であるため、変更することができないのです。
* HTTP 1サーバーとクライアントはこれからも数十年にわたり存在し続けます。それらをhttp2サーバーにプロキシーする必要があります。
* そして、プロキシーはhttp2の機能をHTTP 1.1クライアントへ1:1で対応させなければなりません。
* プロトコルからオプショナルな部分を削除するか削減する。これは要求ではありませんが、SPDYやGoogleチームからやってきた信条のようなものです。すべてを必須にしてしまえば、今実装できないなため後で罠にはまる、といったようなことが起こりえないのです。
* マイナーバージョンを廃止します。クライアントとサーバーはhttp2に対応するか、対応していないかのどちらかです。プロトコルを拡張あるいは変更したいという要求が出た場合は、それはHTTP 3の出番です。http2にはマイナーバージョンはありません。
## 5.1. http2と既存のURIスキーム
以前に述べた通り、既存のURIスキームは変更することができないので、http2は既存のものを使わなければなりません。これらはHTTP 1.xで今日使われているため、プロトコルをhttp2へアップグレードする、あるいはサーバーに古いプロトコルではなくてhttp2を使ってくださいとお願いする必要があります。
HTTP 1.1はこのためのUpgradeヘッダーという機構を備えています。古いプロトコルでこのようなリクエストを受けた場合、サーバーが新しプロトコルで応答を返すというものです。しかしラウンドトリップのペナルティを受けます。
SPDYチームはラウンドトリップのペナルティを受け入れることができませんでした。彼らはSPDYをTLS上でのみ実装していたので、ネゴシエーションを大幅に簡略化するTLS拡張を開発しました。この拡張、Next Protocol Negotiation（NPN）を使うと、サーバーは、それがサポートするプロトコルをクライアントへ通知し、クライアントがプロトコルを選択することができます。
## 5.2. http2とhttps\://
http2ではTLS上で適切に振る舞うように随所で配慮がなされました。SPDYはTLSが必須でしたし、http2ではTLSを必須にしようという大きな後押しがありました。しかしコンセンサスが得られず、http2ではTLSは必須ではなくなりました。しかしながら今をリードする2つのwebブラウザー、Mozilla FirefoxとGoogle Chromeの開発者はhttp2をTLS上でのみ実装すると明言しました。
TLSを選択する理由には、ユーザーのプライバシーを尊重するということと、新しいプロトコルを導入する際はTLSを使うほうが高い成功率があったという実測結果の存在がありました。80番ポートを通過するものはすべてHTTP 1.1であるという広く信じられている前提があり、中間装置によっては通信を妨害したり遮断したりして、他のプロトコルが機能することを妨げるのです。
TLSを必須にするかどうかは、メーリングリストやミーティングで根強い反対意見が寄せられました。これは善なのか悪なのか、ということです。これは呪われた議題です。HTTPbis参加者に向かってこの質問をするときは注意してください。
同様にhttp2はTLSを使用する場合の必須暗号化スイートのリストを宣言すべきかどうか、あるいは、使用できないものをブラックリストにすべきか、いやいや、TLS"層"に要求することはせず、すべてTLS WGに任せようではないか、といった白熱した議論がかわされました。最終的にはTLS 1.2以上を必須とし、暗号化スイートに制限を付ける、ということになりました。
## 5.3. TLSにおけるhttp2ネゴシエーション
Next Protocol Negotiation（NPN）はTLSサーバーとSPDYをネゴシエートするプロトコルです。それは標準化されていなかったので、IETFで議論した結果、Application Layer Protocol Negotiation（ALPN）が生まれました。ALPNはhttp2で使われることになり、SPDYクライアントとサーバーはNPNを使い続けています。
NPNのほうが最初に登場したこと、またALPNが標準化に時間を取られたこともあって、初期のhttp2クライアントとサーバー実装はhttp2をネゴシエートする時に両方の拡張を使うようになりました。またNPNはSPDYで使用されていて多くのサーバーがSPDYとhttp2を両方サポートすることから、NPNとALPNをこれらのサーバーでサポートすることは理にかなっています。
ALPNとNPNの主たる差異はどちらがプロトコルを選択するかということです。ALPNではクライアントがサーバーに優先度の高い順にソートしたプロトコルのリストを渡し、サーバーがその中から選択しますが、NPNではクライアントが最終的な決定をします。
## 5.4. http2とhttp\://
先に述べたとおり、平文HTTP 1.1においてhttp2をネゴシエートするにはサーバーにUpgradeヘッダーを送信します。サーバーがhttp2をサポートするなら、”101 Switching”ステータスを返し、その接続においては以後http2を使用します。もちろんこのアップグレード手順はネットワークの完全な1ラウンドトリップを必要とします。しかし利点としてはhttp2は永続的接続であり一般的にHTTP 1接続よりも多くの部分を再利用可能です。
いくつかのブラウザーベンダーはこの方法でのhttp2の使用を実装しないと言っていますが、Internet Explorerチームは実装する意思を示していて、またcurlはすでにサポートしています。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://http2-explained.haxx.se/ja/part5.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.