私の直感は、SPDY対応ブラウザがSPDYレスポンスであるかのように扱うということです。しかし、私が見つけられる最も大きなものは、H2応答がHTTP1.1に正常に低下するという安心です。私はH2指向の方法（複数リクエスト、ドメインシャーディングなしなど）でアセットを提供することを検討していますが、私は非H2ブラウザ（Android 4.1のブラウザなど）をサポートする必要があります。すべてのクライアントが少なくともSPDYに準拠していればOKでしょうか？SPDYをサポートするブラウザがHTTP2（H2）応答を受信した場合はどうなりますか？
ボーナスに関する質問：ミキシングプロトコルに関連する問題はありますか？私たちはH2をサポートしていないWebフレームワークを使用していますが、私はCDNから資産のほとんどを提供することを検討しています。 TLSを仮定する。
SPDYまたはHTTP/2が有効になっているブラウザは、TLSで話すプロトコルをネゴシエートするために、TLS拡張機能（古いNPNまたは新しいALPNのいずれか）を使用します。
クライアントは、優先順位の高い順に話すことができるプロトコルのリストを送信します（例：）。サーバーは、そのリストでサポートされている（セキュリティに必要な制約に一致する）リスト内のプロトコルを選択します。
たとえば、h2をサポートしていない古いブラウザの場合は、spdy/3.1,http/1.1が送信され、サーバではh2が選択されません。 サーバーがSPDYをサポートしていない場合、残りの唯一のオプションはhttp/1.1であり、これがHTTP/1.1に対する「グレースフル・デグラデーション」を構成します。
クライアントがSPDY（HTTP/2ではなく）の発言を要求した場合、サーバー上の実装エラーが重大でない限り、サーバーはHTTP/2で応答する可能性はありません。
SPDYはHTTP/2のために段階的に廃止されています。たとえば、最近のChromeバージョンdon't support SPDY anymoreなどです。
異なるドメインにリクエストを行い、サーバーが異なるプロトコルを使用している場合、問題はありません。これはブラウザによって透過的に処理されます。
サーバーがSPDYとHTTP/1.1を話し、CDNがHTTP/2とHTTP/1.1を話すことができる場合は、SPDYとHTTP/2の利点を活用するために3つのプロトコルすべてをサポートするブラウザを使用する必要があります。 ブラウザはサーバーとSPDYをネゴシエートでき、CDNとHTTP/2をネゴシエートし、両方のオリジンのリソースで構成されるページをネゴシエートできます。
しかし、ブラウザーはすぐにSPDYをドロップする（または既にドロップしている）ので、最近のブラウザーでは、サーバーでHTTP/1.1とCDNでHTTP/2と話すことになり、SPDY | HTTP/2の利点サーバー上のリソース