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
Comment #1
attiks CreditAttribution: attiks commentedYes please, would be a huge performance improvement
Comment #2
skyredwangd.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;
Comment #4
bertboerland CreditAttribution: bertboerland commentednote, worth watching https://www.youtube.com/watch?v=0EB7zh_7UE4
Comment #5
isntall CreditAttribution: isntall commentedComment #6
isntall CreditAttribution: isntall commentedSPDY 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.
Comment #7
isntall CreditAttribution: isntall commentedComment #8
bertboerland CreditAttribution: bertboerland commentednow the http/2 is final can we migrate and show that we are the first major open source cms site running on /2?
Comment #9
dddave CreditAttribution: dddave commentedMaking active to provoke a response. Btw the boss is also "on" it https://twitter.com/Dries/status/568438125392998400
Comment #10
basic CreditAttribution: basic commentedThis is up to Fastly or Edgecast, whoever has it first. Lets keep it postponed until we have support from one of our CDNs.
Comment #11
bertboerland CreditAttribution: bertboerland commented@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/
Comment #12
skyredwangI 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.
Comment #13
basic CreditAttribution: basic commented@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.
Comment #14
bertboerland CreditAttribution: bertboerland commentedthanks @basic for following up :-) and ineed @skyredwang http pipelining does make cdn's less attractive
Comment #15
basic CreditAttribution: basic commentedTime will tell, I imagine most major CDNs are in similar spots.
Comment #16
andypostfirefox 36 released with 2.0 support https://www.mozilla.org/en-US/firefox/36.0/releasenotes/
Comment #17
serg2 CreditAttribution: serg2 commentedJust 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.
Comment #18
bertboerland CreditAttribution: bertboerland at Wunder commentednow d.o is on fastly, time to follow https://community.fastly.com/t/are-there-any-spdy-plans/193/11 :-)
Comment #19
bertboerland CreditAttribution: bertboerland at Wunder commentedhttps://www.cloudflare.com/http2/ already does...
Comment #20
mlhess CreditAttribution: mlhess as a volunteer commentedFor an update on this:
https://www.fastly.com/blog/support-http2
Comment #21
drummhttps://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.
Comment #22
drummapi.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.
Comment #23
drummAll subdomains have been updated to the http/2 endpoint.
Comment #24
skyredwangI can confirm, it works
drumm++
@drumm, China has lost its connection to *.d.o for months, can we chat about it on IRC?
Comment #25
drummSure, 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?