Are there any SPDY plans?
Do Fastly have any plans to support SPDY at the CDN endpoints?
-
Any update on SPDY/HTTP2 support? It seems like the spec nearing completion so it would be good to understand where you guys stand.
-
Hi, Pestering about HTTP2 support again. I appreciate you would like to do a grand unveil but it would be quite handy for those of us looking to use HTTP2 to have a bit of notice so that we can be ready when it arrives! Cloudflare and Akamai are already offering SPDY support so with those guys we can at least plan ahead.
-
@richardstillft that's a reasonable request :smile: Shoot us an email at support@fastly.com linking to this thread and we'll see what we can do.
-
Gentle bug here nearly one year after OP raised the question.
If it’s of any help, VOX is planning to move all of its properties to a CDN with HTTP/2 http://product.voxmedia.com/2015/8/13/9143805/performance-update-2-electric-boogaloo
-
Hey Thomas, I think the issue here is that there's no HTTP/2 support in Varnish (and likely won't be) so Fastly most likely have to develop this themselves.
It's not an easy task to get this to be spec compliant, but it's probably something that should have been worked on since SPDY was introduced.
There's actually a lot to be said for ditching a CDN if your front end servers support HTTP/2 and your CDN doesn't.
-
[quote="mattm, post:21, topic:193"] Could you expand upon this? I'm new to HTTP/2 and I'm interested to hear why you feel this is the case. [/quote]
HTTP/2 is a big improvement and greatly reduces latency by combining several requests over the same TCP connection without any blocking by the order of the resources. It also prefers SSL/TLS (via browser support), has header compression and is just faster by being a binary protocol.
Overall, it can improve loading times for a site even with just a single server. It's still important to use a CDN though to make sure static assets are still closer to an end-user but there are several CDN's that support HTTP/2 now so it's especially glaring that Fastly is still stuck on HTTP/1, regardless of their foundation built on Varnish.
-
Hey everyone. As @Thomas_Genin pointed out, we’ve been delayed on delivering HTTP/2 beyond what we alluded to previously, and we’ve been slow to update here. I’m sorry. This level of radio silence isn’t acceptable to us, and you all deserve to know the full story.
To start, we’ve been researching or working on HTTP/2 since around the start of this thread. The process began with investigating existing open source options, as @rlx01 and others have mentioned. However in the feasibility research, we did uncover several problems that put up major blockers in that process. To start, many of the libraries in existence aren’t designed with Fastly’s request and network load in mind; this was not something that surprised us. Existing OSS options are built for more normal uses, and we fully anticipated that off-the-shelf options would need to be reworked. However, we ran into another problem that caused a significant reassessment of our protocol approaches overall. HTTP2, in it’s design process, was built and tested under controlled environments. For a research-driven protocol, this is the right thing. In this approach, the protocol benefits from the most long-term focused scoping and specification work possible, ensuring a greater lifetime of adoption and stability. This does place additional complications around implementation (which I’ll address later), but that’s a normal process. However, when we began testing HTTP/2 in real world network simulations, we uncovered several conditions where HTTP/2 performance is comparable-to or below HTTP/1. The tests themselves don’t fit our standards for publishable research (full reproducibility under the scientific method), so we’ve been hesitant to share details until we have data to our standards. But, these findings were enough to cause us to rethink and replan our implementation from the ground up.
The crux of the matter is: if we’ve seen, even in our own early testing, that there are fleeting network conditions where HTTP/2 is inferior to HTTP/1.1, and if we have a burden as a service provider to always provide the fastest network connection to our customer’s end users no matter what, we need to develop an intelligent way to detect network problems and select the best protocol options in real time for any end user automatically. Our number one priority, by an order of magnitude, is network stability. We have to build with this in mind. When we roll out IPv6, when we build HTTP/2 support, when we research QUIC support (which we are, of course), or when we add more features to Varnish, we have to architect and build with stability as a high focus.
So, with these situations in mind, we’re still building HTTP/2 support in a way that’s robust enough to meet our standards, and in a way that can intelligently handle the odd network edge cases that don’t benefit from HTTP/2’s features and functionality. Unfortunately, we are still working, and we don’t have an active beta. We’ve also learned the hard way in threads like this that stating a release date prematurely is a recipe for bad emotions if a project is delayed, so we’re not going to post a timeline until it’s nearly done.
The discerning reader will point out that this thread has been around for a long time, much more so than a well-oiled engineering organization would need to work through the above timeline. As one might reasonably conclude, there were some considerable management and coordination challenges with a large scale project of this undertaking as we grew from a small startup to full-scale growing business. If you’ve been at a company that’s grown from 10 to 50 to 100 to 300+ over the span of a few years, you know what I’m alluding to: processes slow down, new employees don’t have the same institutional knowledge as veterans, and the assumptions around building and shipping code no longer hold. As a result, output drops. I mention this not to make excuses, but to to be transparent about how we got to this point in our lifecycle.
That said, over the past 4-5 months, we’ve been putting in substantial changes to our organizations for engineering happiness and shipping velocity. To not drag out an already long piece with gory details, but we have dedicated teams owning core products in the long term and we have widely adopted (but still flexible) development practices. Across the board, with our application team, our systems teams, and even our teams researching protocols, we’re at a point of velocity that we haven’t seen since the early scrappy startup days, and this should directly impact our ability to get out HTTP/2.
All in all, we’re sorry that things have taken this long, and we’re sorry that we’ve been so slow to fully update our message on this. As Fastly customers, you deserve better. All in all, I hope this paints an honest picture of what happened on the technical and human side to cause us to get to this state. We’ve made changes that should prevent this from happening again in the future, and I hope we can regain your trust over time.
-
[quote="ManiGandham, post:22, topic:193"] It also prefers SSL/TLS (via browser support) [/quote]
Really HTTP 2 / SPDY requires SSL/TLS, this taken from the HTTP2 FAQ:
However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection, and currently no browser supports HTTP/2 unencrypted.
-
@aspires I imagine this is outside of your control but it doesn't look great to finally post something on a thread that hasn't been updated by Fastly in months and then pull it down less than 24 hours later. For all of us who have notifications enabled in the thread, we already all have the full text in our email inbox. Why not just leave it up for this smaller audience?
-
An updated blog post addressing our HTTP/2 timeline has been posted on the blog - you can read more here: https://www.fastly.com/blog/support-http2.
-
Here it is (in limited availability). Sign on up by emailing support@fastly.com :two: :clock2:
https://www.fastly.com/blog/announcing-limited-availability-http2
Please sign in to leave a comment.
Comments
28 comments