What happens when a browser that supports SPDY receives an HTTP2 (H2) response?

被刻印的时光 ゝ 提交于 2019-12-05 18:57:46

Browsers that are SPDY or HTTP/2 enabled use a TLS extension (either the older NPN or the new ALPN) to negotiate the protocol they speak over TLS.

The client sends the list of protocols that it is capable to speak in order of preference (e.g. h2,spdy/3.1,http/1.1), and the server picks one protocol among those in that list that it also supports (and that match security required constraints).

For example, if you have an older browser that does not support h2, it will send spdy/3.1,http/1.1, and the server will never pick h2 (even if it supports it). If the server does not support SPDY, the only option left is http/1.1, and this is what constitutes the "graceful degradation" to HTTP/1.1.

There is never the possibility that if the client requested to speak SPDY (and not HTTP/2), the server replies with HTTP/2, unless gross implementation errors on the server.

SPDY is being phased out in favor of HTTP/2. For example, recent Chrome versions don't support SPDY anymore.

There are no complications when you you make requests to different domains, and the servers speak different protocols: this is handled transparently by the browsers.

If your server can speak SPDY and HTTP/1.1, and the CDN can speak HTTP/2 and HTTP/1.1, then you have to use a browser that supports all 3 protocols to leverage the SPDY and HTTP/2 benefits. The browser can negotiate SPDY with your server, and negotiate HTTP/2 with the CDN, and the page composed of resources from both origins.

However, browsers will soon drop (or have already dropped) SPDY, so with recent browsers you may end up speaking HTTP/1.1 with your server and HTTP/2 with the CDN, thereby losing the SPDY|HTTP/2 benefits for resources on your server.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!