我的直覺是，具有SPDY功能的瀏覽器會將其視爲SPDY響應。但是，我能找到的最多的是確保H2響應將優雅地降低到HTTP1.1。我正在考慮以面向H2的方式（多個請求，沒有域分片等）來服務資產，但我確實需要支持一些非H2瀏覽器（例如Android 4.1的瀏覽器）。如果所有客戶都至少符合SPDY標準，我還可以嗎？當支持SPDY的瀏覽器收到HTTP2（H2）響應時會發生什麼情況？
獎金問題：混合協議是否存在任何複雜問題？我們正在使用不支持H2的Web框架，但我正在考慮爲CDN提供大部分資產。假設TLS。
啓用SPDY或HTTP/2的瀏覽器使用TLS擴展（舊的NPN或新的ALPN）來協商他們通過TLS說話的協議。
客戶端發送它能夠按優先順序發言的協議列表（例如h2,spdy/3.1,http/1.1），並且服務器在該列表中那些在它也支持（並且匹配安全需要的約束）的列表中選擇一個協議。例如，如果您的舊瀏覽器不支持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，那麼您必須使用支持所有3種協議的瀏覽器來利用SPDY和HTTP/2的優點。 瀏覽器可以與您的服務器協商SPDY，並與CDN協商HTTP/2，以及由兩個來源的資源組成的頁面。但是，瀏覽器很快就會放棄（或已經放棄）SPDY，所以在最近的瀏覽器中，最終可能會使用服務器和HTTP/2與CDN講HTTP/1.1，從而失去SPDY | HTTP/2的好處爲您的服務器上的資源。