SPDY is protocol created by Google to overcome the problems of HTTP/1.1 (pipelining) and the absence of HTTP/2.0, a way to tunnel all traffic through one pipe/socket without additional TCP overhead (handshakes etc). Right now it is supported in modern version of all minus one browsers (http://en.wikipedia.org/wiki/SPDY#Browser_support_and_usage) and it is the base of HTTP/2.0

Even if it was only for chrome/chromium browsers, still a very easy and cheap way to make d.o a lot faster without many if any risks. The downers are, it uses HTTPS so a certificate (we already have that), but this also makes it nearly impossible to troubleshoot from a command line right now. In due time, better tools will come, but right now not many good tools are there. facebook and all 8.google.com services including youtube use SPDY and we should really do this, easy to setup and test and to deploy once the thumbs are up. There are SPDY modules for NGINX and Apache, so enabling this doesn't lock us in on either one of them.

I have done some SPDY implmentations and can help, but really it is a no brainer.

Comments

attiks’s picture

Yes please, would be a huge performance improvement

skyredwang’s picture

Title: install spdy on d.o » SPDY on d.o

d.o's server is Nginx and now it uses SSL. So adding SPDY support is only marginal work. SPDY will also benefit mobile speed as well (smartphone required).

Below are the steps to take.

1. Install OpenSSL 1.0.1 or greater with NPN support
2. Make sure the existing Nginx has SPDY support (It might require re-compilation)
3. change one line of configuration from something like

listen 123.456.789.000:443 ssl;

to

listen 123.456.789.000:443 ssl spdy;

Component: Webserver » Servers
bertboerland’s picture

Issue summary: View changes
isntall’s picture

Issue summary: View changes
isntall’s picture

SPDY would be a good perfomance boost, though I'm unsure how SPDY would interact with the EdgeCast CDN; probably wouldn't be used and thus do nothing.
According the YouTube video posted by @bertboerland EdgeCast doesn't support SPDY at this time.
If this changes we should implement SPDY.

isntall’s picture

Status: Active » Postponed
bertboerland’s picture

Title: SPDY on d.o » HTTP/2 on drupal.org (was: SPDY on d.o)

now the http/2 is final can we migrate and show that we are the first major open source cms site running on /2?

dddave’s picture

Status: Postponed » Active

Making active to provoke a response. Btw the boss is also "on" it https://twitter.com/Dries/status/568438125392998400

basic’s picture

Status: Active » Postponed

This is up to Fastly or Edgecast, whoever has it first. Lets keep it postponed until we have support from one of our CDNs.

bertboerland’s picture

@basic, wouldnt it be better that those who pay these CDN's (the DA) will talk to the suppliers about theirs plans for support?

btw https://istlsfastyet.com/

skyredwang’s picture

I don't know how exactly CDN provider decides on pricing. But, there is a case that the efficiency HTTP/2 brings can decrease the short term revenue a provider can earn. In other words, they might want to delay the support as much as possible.

basic’s picture

@bertboerland https://docs.fastly.com/guides/faqs/does-fastly-support-the-spdy-protoco... claims support once the standard has solidified (which it has) and browser support is available (which should happen pretty soon). If months pass and the support still isn't there we can start pestering them.

That said, EdgeCast is the current CDN for Drupal.org and their timeline is currently unknown -- I have a support request in to them to see if they can make any clarifications. If Fastly has support first it may make a good argument for switching providers.

bertboerland’s picture

thanks @basic for following up :-) and ineed @skyredwang http pipelining does make cdn's less attractive

basic’s picture

We do have our DEV team hard at work on supporting HTTP 2.0, however, I do not have road map of when the protocol will be fully supported. Please let us know if you have anymore questions or concerns that we can address for you.

Time will tell, I imagine most major CDNs are in similar spots.

andypost’s picture

serg2’s picture

Just general info.

According to CanIUse.Com over 50% of users are now on a browser which supports HTTP/2.

For most servers it does look as though the simplest way to support HTTP/2 will be to use NGINX as a proxy similar to as described in #2046731-2: HTTP/2 on drupal.org (was: SPDY on d.o). NGINX intends to roll out support during 2015(possibly even in 1.9.3) . Those who do not want to wait that long have some options already Nghttp2 is possibly the simplest setup but many other are available: https://github.com/http2/http2-spec/wiki/Implementations.

Latency is normally lower over HTTP/2 and extra lookups heavily penalised so it will be interesting to see how CDNs and the cloud (vs single location servers) are effected by the move to HTTP/2.

bertboerland’s picture

bertboerland’s picture

mlhess’s picture

drumm’s picture

Status: Postponed » Needs review

https://www.fastly.com/blog/http2-now-general-availability

I went ahead and set this up for drupal.org, which is only the redirect to www.drupal.org, while doing another DNS change.

drumm’s picture

Assigned: Unassigned » drumm

api.drupal.org and assoc.drupal.org have their DNS updated to point to Fastly's new endpoints. These should switch over to http/2 over the next day as DNS caches are refreshed.

drumm’s picture

Status: Needs review » Fixed

All subdomains have been updated to the http/2 endpoint.

skyredwang’s picture

I can confirm, it works
drumm++

@drumm, China has lost its connection to *.d.o for months, can we chat about it on IRC?

drumm’s picture

Sure, myself or mixologic are online during reasonable times for US time zones. Are you able to access https://www.fastly-debug.com? Do you have any ideas on how we might be blocked?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.