Intent to deprecate and remove SPDY/3.1

379 views
Skip to first unread message

Bence Béky

unread,
Feb 12, 2016, 3:33:13 PM2/12/16
to net-dev, blin...@chromium.org

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

unread,
Feb 12, 2016, 3:48:04 PM2/12/16
to Bence Béky, net-dev, blink-dev
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

unread,
Feb 12, 2016, 3:51:40 PM2/12/16
to PhistucK, net-dev, blink-dev
>
> Actually, announcing removal, not deprecation on that date.
> Same for NPN.
>

You are right, sorry about the mistake.

Philip Jägenstedt

unread,
Feb 15, 2016, 4:00:35 AM2/15/16
to Bence Béky, net-dev, blink-dev
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

unread,
Feb 15, 2016, 6:37:17 PM2/15/16
to Philip Jägenstedt, Bence Béky, net-dev, blink-dev
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

unread,
Feb 15, 2016, 7:28:33 PM2/15/16
to Mike Lawther, Philip Jägenstedt, Bence Béky, net-dev, blink-dev
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

unread,
Feb 15, 2016, 7:39:59 PM2/15/16
to Alexey Baranov, Mike Lawther, Philip Jägenstedt, Bence Béky, net-dev, blink-dev
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
 
 

Bence Béky

unread,
Feb 16, 2016, 5:27:20 AM2/16/16
to Philip Jägenstedt, net-dev, blink-dev
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

unread,
Feb 16, 2016, 5:40:22 AM2/16/16
to Bence Béky, net-dev, blink-dev
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

unread,
Feb 16, 2016, 5:54:45 AM2/16/16
to Philip Jägenstedt, net-dev, blink-dev
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

unread,
Feb 16, 2016, 6:47:32 AM2/16/16
to Bence Béky, net-dev, blink-dev
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

unread,
Feb 16, 2016, 6:54:36 AM2/16/16
to Philip Jägenstedt, Bence Béky, net-dev, blink-dev
lgtm2

Chris Harrelson

unread,
Feb 16, 2016, 1:42:28 PM2/16/16
to Jochen Eisinger, Philip Jägenstedt, Bence Béky, net-dev, blink-dev
LGTM3

Joe Medley

unread,
Feb 17, 2016, 10:17:38 AM2/17/16
to Chris Harrelson, Jochen Eisinger, Philip Jägenstedt, Bence Béky, net-dev, blink-dev
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

unread,
Feb 17, 2016, 10:39:55 AM2/17/16
to Joe Medley, Chris Harrelson, Jochen Eisinger, Philip Jägenstedt, Bence Béky, net-dev, blink-dev

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.

Joe Medley

unread,
Feb 17, 2016, 10:56:45 AM2/17/16
to David Benjamin, Chris Harrelson, Jochen Eisinger, Philip Jägenstedt, Bence Béky, net-dev, blink-dev
Thanks!

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

m.s.m.m...@gmail.com

unread,
Mar 29, 2016, 1:42:12 AM3/29/16
to blink-dev, b...@chromium.org, net...@chromium.org


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

Bence Béky

unread,
Apr 14, 2016, 7:01:14 AM4/14/16
to Philip Jägenstedt, net-dev, blink-dev
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

unread,
Apr 14, 2016, 7:45:40 AM4/14/16
to Bence Béky, net-dev, blink-dev
Thanks Bence, that's very helpful! We'll keep you informed if we see any fallout of this removal on our end.

Todd Reifsteck

unread,
Apr 14, 2016, 2:07:48 PM4/14/16
to Philip Jägenstedt, Bence Béky, net-dev, blink-dev

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

unread,
Apr 14, 2016, 4:03:50 PM4/14/16
to Todd Reifsteck, Philip Jägenstedt, net-dev, blink-dev
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

unread,
Apr 26, 2016, 5:25:29 PM4/26/16
to blink-dev, net...@chromium.org
I can't access important documents needed for job application. Please remove. Thank you

benjamin...@ec.vic.edu.au

unread,
Apr 26, 2016, 11:27:56 PM4/26/16
to blink-dev, net...@chromium.org

Bence Béky

unread,
Apr 27, 2016, 7:35:01 AM4/27/16
to dunn...@gmail.com, blink-dev, net-dev
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.
Reply all
Reply to author
Forward
0 new messages