SPDY/3.1 is the experimental application layer protocol that provides performance improvements over HTTP/1.1 by, for example, connection multiplexing and server push. SPDY/3.1 is superseded by HTTP/2, which was published as an RFC last May.
SPDY/3.1 is currently used for less than 5% of requests Chrome makes. Its successor, HTTP/2 is now supported by major servers and clients, and is used for more than 25% of Chrome requests. The remaining requests are served using HTTP/1.1 or QUIC.
Pulling the plug on SPDY/3.1 is important to move the ecosystem forward: to provide an incentive for server developers to focus on HTTP/2 implementations, and for server administrators to upgrade to HTTP/2 capable servers. The reduction of code complexity and test infrastructure load due to removing SPDY/3.1 code is also non-negligible.
Also see Chromium Blog post announcing deprecation on 2016 May 15.
For servers supporting SPDY/3.1 but not HTTP/2, Chrome right now negotiates SPDY/3.1, but will fall back to HTTP/1.1 after deprecation. This should not have any effect on functionality. The only difference is that users will not benefit from the improved performance that SPDY/3.1 and HTTP/2 provide.
Alternative implementation suggestion for server administrator
Upgrade their servers to support HTTP/2.
Usage information from UMA
Per request metric is Net.HTTPResponseInfo.ConnectionInfo.
Per connection info metric is Net.SSLProtocolNegotiation. Note, however, that
many connections do not show up in Net.SSLProtocolNegotiation either because they are not encrypted or because they do not use either NPN or ALPN;
SPDY/3.1 and HTTP/2 are more heavily multiplexed than HTTP/1.1 connections, so the HTTP/1.1 numbers are biased when compared to SPDY/3.1 and HTTP/2;
HTTP/2 to SPDY/3.1 ratio is lower than the per request ratio, suggesting that HTTP/2 servers typically serve more requests than SPDY/3.1 ones per connection.
Requesting approval to remove too?
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC7btF6C4BVHsk-N%3DaZ3f75k691q3St_1mLf-VAT0aJtzrVUiw%40mail.gmail.com.
It is also said that NPN won't be supported. Does the situation with alpn support changed since the end of 2015 (there was an attempt then to do so)? Is there some data on how many servers use npn with http/2? AFAIK openssl 1.0.2 (supporting alpn) was not ported to ubuntu trusty, and next LTS will be 16.04 - not sure how many Ubuntu deployments will be upgraded to it by May 15th. Wouldn't it be a lot of pain and haste for their operators if they choose to support http/2?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/63411455582506%40webcorp02d.yandex-team.ru.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAJUhtG8gUFPi7xN6Otq%3DaN5GqDYpU9zuHU7%2B7bn%3D%2BLwRfN8%2Byg%40mail.gmail.com.
This is great to hear. A number of major websites have used SPDY/3.1’s existence as a crutch rather than moving to HTTP/2.
Will the removal of SPDY/3.1 also remove NPN?
The Microsoft Edge team has found that a number of properties claim HTTP/2 support but only support NPN and not ALPN.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/3acbceec-5dfd-49c1-bba7-924f0ab6e0d2%40chromium.org.