Intent to deprecate and remove SPDY/3.1

[Bence Béky]

Primary emails

eng: b...@chromium.org

PM: si...@chromium.org

Summary

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.

Motivation

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.

Compatibility Risk

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?

Yes please.

[PhistucK]

Yay, ​standard interoperability!

​

On Fri, Feb 12, 2016 at 10:32 PM, Bence Béky <b...@chromium.org> wrote:

Also see Chromium Blog post announcing deprecation on 2016 May 15.

Actually, announcing removal, not deprecation on that date.

Same for NPN.​

☆PhistucK

[Bence Béky]

>
> Actually, announcing removal, not deprecation on that date.
> Same for NPN.
>

You are right, sorry about the mistake.

[Philip Jägenstedt]

The Chromium Blog says "starting on May 15th — the anniversary of theHTTP/2 RFC — Chrome will no longer support SPDY." Is that going to be accomplished by an actual date in the code, or will this trickle through the release channels to reach stable with M52?

--
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.

[Mike Lawther]

Non-owner LGTM. SPDY has served its purpose, time to retire it.

I'd still like to see the answer to Philip's question though.

[Alexey Baranov]

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?

 

16.02.2016, 02:37, "Mike Lawther" <mikel...@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.

[David Benjamin]

On Mon, Feb 15, 2016 at 7:28 PM Alexey Baranov <baran...@yandex-team.ru> wrote:

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?

This thread is just about SPDY. I'll send out a separate Intent mail later this week for NPN with those numbers. They're quite good.

It's worth reiterating that no sites will stop working. Early adopters of SPDY and NPN will take a performance hit if they had not kept up with the development of those experiments. The HTTP/2 and ALPN incarnations now have been standard and available for some time.

David

 

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/63411455582506%40webcorp02d.yandex-team.ru.

[Bence Béky]

Hi Philip,

This will not trickle through channels, but will be controlled
remotely, at the same time or within a short period of time for all
channels. The exact rollout schedule has not been determined yet.

Cheers,

Bence

[Philip Jägenstedt]

Oh, I see. What does that mean for non-Chrome browsers, will SPDY support remain until it's removed from the code base unless some action is taken? And what is the main reason for doing remote shutoff instead of letting it trickle?

[Bence Béky]

Hi.

On Tue, Feb 16, 2016 at 11:40 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> Oh, I see. What does that mean for non-Chrome browsers, will SPDY support
> remain until it's removed from the code base unless some action is taken?

I will disable SPDY/3.1 in the code on trunk at the same time, so
Chromium derivatives will be able to pick it up according to their
release schedule without any specific action on their part.

> And what is the main reason for doing remote shutoff instead of letting it
> trickle?

The reason that matters to me most personally is that since this
potentially involves a performance degradation for some sites, I do
not consider it fair to voluntary Canary, Dev, and Beta users to
expose them to this for months while support on Stable means that
there is still not critical pressure on server deployments to upgrade.

The other reason is that should something go very-very wrong, I could
reenable SPDY/3.1 relatively quickly.

Please let me know if you have any other questions. Cheers,

Bence

[Philip Jägenstedt]

That makes sense, thanks. If you could arrange for it to be disabled
by default starting with M51, that would give roughly the right timing
for Chromium-based browsers like Opera as well, and with just enough
time to revert on the M51 stable branch if disaster strikes when the
change happens around May 15.

LGTM1, it's rare and encouraging to see the first iteration of a
technology be removed in favor of its final form.

Philip

[Jochen Eisinger]

lgtm2

[Chris Harrelson]

LGTM3

[Joe Medley]

Can someone please create a status entry and tracking bug for this.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[David Benjamin]

I believe Bence's out for a bit, so I've gone ahead and filed it for him:
https://www.chromestatus.com/feature/5711167683035136
https://code.google.com/p/chromium/issues/detail?id=587469

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/CAJUhtG8gUFPi7xN6Otq%3DaN5GqDYpU9zuHU7%2B7bn%3D%2BLwRfN8%2Byg%40mail.gmail.com.

[Joe Medley]

Thanks!

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[m.s.m.m...@gmail.com]

2016年2月13日土曜日 5時48分04秒 UTC+9 PhistucK:

[Bence Béky]

Hi Philip,

Just a heads up that SPDY/3.1 has been disabled on M51 just as you requested.  This way Chromium-based browsers will pick up the change in roughly the right timeframe.

Thank you,

Bence

[Philip Jägenstedt]

Thanks Bence, that's very helpful! We'll keep you informed if we see any fallout of this removal on our end.

[Todd Reifsteck]

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.

 

Thanks!

Todd

--

[Bence Béky]

Hi Todd,

I agree that disabling SPDY/3.1 is the right step to incentivize
moving to HTTP/2.

As for NPN, it is scheduled to be disabled at the same time (though it
has not been disabled on trunk yet), see the following thread:
https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/Qroz7eyCzRs.

Cheers,

Bence

[dunn...@gmail.com]

I can't access important documents needed for job application. Please remove. Thank you

[benjamin...@ec.vic.edu.au]

[Bence Béky]

Please file a bug report at https://crbug.com/new.  Make sure to include the version of Chrome you are using (as well as your operating system), the exact error you get, and why you think it is related to SPDY/3.1 deprecation.

Thank you.

--

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/3acbceec-5dfd-49c1-bba7-924f0ab6e0d2%40chromium.org.