Yesterday's best-practices are today's HTTP/2 anti-patterns
docs.google.com
docs.google.com
In practice, if you already have an SSL server, just add the "spdy" to the listen line like "listen 443 ssl spdy;", restart and you are done[1].
Then making it proxy request is just one location definition with "proxy_pass"[2].
[1]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html
chadaustin already mentioned nginx, which seems to be the most popular choice.
This is alos one of the examples for H2O:
… and Apache Traffic Server just shipped support in v5.3.0, which might be of interest if you want to setup a generic front-end layer for a ton of backend services:
https://cwiki.apache.org/confluence/display/TS/What%27s+New+...
One thing I haven't looked into is whether any of these will try to use server push for content which has is referenced by <link rel=preload> in an HTML page. That could be very useful for render-blocking CSS/JS.
If the answers are in the slides, forgive me - using the iPad the Google slide software breaks the back button and is too annoying to read beyond a few slide pages. Debugging and implementing older protocols seem to be easier, as they were text based.
Many do, yes.
> Will there be v2-only servers in near future?
Yes.
> Debugging and implementing older protocols seem to be easier, as they were text based.
Implementing text protocols seems to be easier, but writing an implementation that can handle the wide variety of both compliant and slightly non-compliant traffic is an exercise in frustration.
This is not helped by the fact that people see the text protocol and think that it's easy to implement, so they go and write their own HTTP/1.1 server and leave it on the internet. Their server is probably not quite spec-compliant, so everyone else is left trying to interop with it.
Binary protocols are hard to debug by eye, but they aren't hard to write parsers for.
Implementing a text based protocol (SMTP, POP3, HTTP0.x/1.x) for a client application is certainly easier and less documentation is required. Knowing the clusterfk of the binary Office document formats, the newer text based ones re far easier to parse (be it XML or plain text doesn't matter). Be it binary or text based, one has to write a parser anyway. Only with text based protocol one could also use Regex or string match during, which is quite useful for non-production development/testing.
I read about "prioritisation" of data as a hint for the server, and less caching of data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritise certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns.
When you're parsing text, all kinds of crazy stuff can happen. You need to resize buffers as you read data, you need to know the escaping rules of each field, you need to know about line continuations, you have to know the text encoding, and many many other things.
Binary data in the abstract form has three elements: tag/type (may be inferred from position), data length (may be inferred from tag) and optional data itself. There are various ways to compose that information, but that's it otherwise. Binary protocols may be harder to read for people (you can just use wireshark dissectors though), but writing a correct and bug free de/encoder for one is massively simpler than for a text one.
By design, every text protocol will require more documentation than binary, because you need to include information about data escaping and encoding.
If you want to see this in practice, implement a client for something which does support both options. I recommend memcache.
Whether parsing binary is easier or harder than parsing text depends almost completely on the grammar of the language being parsed; and let's not forget, text is, of course, a type of binary format.
If I have to do ad-hoc parsing or generation, I prefer a text format, because I have lots of tools that understand text. If I need to do production-quality work, I prefer a binary format, because I need to be complete. But if I'm integrating multiple heterogeneous systems, I want a format that is trivial to inspect and test; that may mean a well-specified text format, like JSON or XML.
I'm fairly sanguine about HTTP/2 because it's at a lower level. If I were in the business of writing HTTP clients or servers on a regular basis (rather than using existing libraries), I'd be more concerned. I only do a telnet HTTP/1.0 session every 4 months or so.
But again, I have to disagree about parsing text ever being easier than binary. Basically for the same protocol, passing the same data and implemented in a sane way, the text protocol is the same as binary + variable length metadata + data escaping + value conversion + text encoding of metadata. I'm happy to challenge anyone with the following: it's not possible to create a simpler text protocol than a well designed binary protocol. (looking only at encoding/decoding, not debugging side)
Where by simpler I mean, less likely to get exploited, less ambiguous, shorter to document (when concatenating with docs of all encoding protocols you depend on, like JSON or XML)
Huh? That's irrelevant, surely? It doesn't speak to your assertion. The best binary formats don't necessarily need "parsing" at all; it could be a simple matter of mapping into memory and adjusting offsets, like an OS loader. I don't think there's any debate that binary formats can be designed so that they are far easier to load than text. We're not talking about the design of protocols here (in this subthread). We're talking about writing parsers.
Parsing an obscure binary format is harder than parsing a simple text format.
I'm not sure where do obscure binary formats come in. Http2 had a choice of slightly complicated binary, or more complicated text. Office had lots of programmers, even more money and simply didn't care. It's a completely different situation than http2.
So finally: why the obscure binary format? Http2's choice is good text or good binary really.
The Office "binary format" is simply the objects as they exist in-memory serialized to the disk. Doing it this way was a design decision made when machines were a lot more resource constrained, and fair enough, perhaps it could be revisited, but it was made for sensible reasons by people smarter than you.
I'm sold. What would be the easiest way to makes this happen for someone like me with a pretty vanilla LAMP server?
I don't know where you saw that nginx commercial has HTTP/2 (it's not mentioned on the nginx feature matrix[1]), but their announcement[2] stated that both open and commercial versions would be getting HTTP/2 support by end of year.
If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative (though I've not heard of anyone actually doing this yet).
If you use WebSockets because you actually want a bidirectional message-oriented transport protocol, well then you'll keep using WebSockets. :)
One thing to keep in mind with HTTP/2 server push is that a server can only send a push in response to a client request. So this isn't a drop-in "real-time push" mechanism. To implement the equivalent of real-time push would likely require client/server to keep a stream within the connection in the "open" state whereby the server can send continue to send data frames on that.
One thing to keep in mind with HTTP/2 server push is that a server can only
send a push in response to a client request.
Websockets are still important if you need something like real-time input-event streaming (e.g. for an online game); a properly-structured binary protocol sent over a websocket will be much lower-overhead than the equivalent HTTP/2 frames.
It's not like Back/Forward browser buttons are overrode to behave and previous/next for the slide presentation.
Remember those horrible embedded Flash presentations that you couldn't directly link to a particular slide within the blob? Yeah, that "breaks the Web". Back/Forward is supposed to go back to the previous page the user was on (which is a "slide" in this case).
Using Chrome 43.0.2357.81 (64-bit) / OS X.
In the scrolling case, I still don't see how it's "overriding the browser buttons", but rather having a JavaScript that advances to the next page on scroll.
In the scrolling scenario, my actual back and forward browser buttons behaved as expected — just for the pages (slides) I visited. No more, no less.
Going to a new tab in Chrome, navigating to <https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD..., and clicking my browser's "back" button takes me back to the New Tab Page, so I'm not sure I'm seeing the behaviour you're describing.
There should be a "share" button that spites out the URL with the hash-tag of the current slide - similar to Youtube where you can click on the "share" button below the video to link to a specific time in the video, e.g. https://youtu.be/I26EwcssMbY?t=1m37s
You could argue that every link should open in a new tab by default and only replace the contents of the current tab in special cases, instead of the other way around. In the past 20 years we've been 'trained' to have different expectations, because of the design of the first websites, browsers and the resource limitations of those days. However, the designs and abilities of all of those have changed and it may be worthwhile to reconsider the current default.
If you find yourself having to interact with these a lot, which I do, you might find it useful to click on the cogwheel icon at the bottom of the screen and select 'Open in editor'. That gives you a completely different and IMO much easier to read view of the same document:
https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD...
Firstly, the presentation seems to start by arguing that round-trip latency has much more of an impact on perceived performance than bandwidth, but then argues for several techniques whose principle advantage is saving small amounts of bandwidth. So how much improvement will these new techniques really offer over current best practices for "an average web site"?
Secondly, the presentation seems to argue that simplifying front-end development processes by avoiding things like resource concatenation is a big advantage of HTTP/2, yet despite repeatedly emphasizing the need for the server to provide just the right responses to make HTTP/2 work well, it almost completely ignores the inevitable challenges of actually configuring and maintaining a server to take advantage of all of these new techniques in a real, production environment, with rapidly evolving site structure and content, numerous contributors, etc.
Essentially, this seems to be advocacy for dumping tried, tested, universal "workarounds" for the limitations of HTTP/1.1 in favour of new techniques that work well with HTTP/2 and only HTTP/2, but as an industry we have relatively little experience in what actually works well or doesn't with HTTP/2 and we have relatively few tools and relatively little infrastructure available that support it right now. And crucially, making the shift is not by any means a neutral activity; it is actively and severely harmful to several of the most important tried-and-tested techniques we've used up to now.
Finally, there is the simple matter of trust or, if you want to be kinder, future-proofing. The presentation notes that Google are deprecating SPDY from early 2016. That is the supposed HTTP replacement that was the New Shiny... yesterday, I think, or maybe it was the day before. When arguing for fundamental and irreversible changes in the basic development process and infrastructure set-up, you lose all credibility when your so-called standards fall out of favour faster than a GUI or DB library from Microsoft, and when your own browser frequently breaks due to questionable caching and related behaviour.
It's certainly true that HTTP/1.1 isn't perfect and there are practical ways it could be improved, but I don't think this presentation makes a strong case for adopting HTTP/2 as the way forward.
[1] YMMV if you actually do work for Google/Facebook/Amazon, and you really do have practically unlimited resources available to maintain both your sites and your servers, and you really are making/losing significant amounts of money with every byte/millisecond difference.
SPDY was never meant to be "the supposed HTTP replacement". It was clear from the start that it was an experiment, designed to research alternative protocols and inform the design of some future hypothetical HTTP/2.0 - which it did, since they actually used SPDY as its base.
And, hopefully, Google's experimentations in other protocols and domains will challenge those controlling the status quo to adapt to the times as well. Not holding my breath but it would be nice.
But changing an existing production site so it no longer uses techniques like spriting and concatenation will damage performance if anything degrades the communications to HTTP/1.1.
One point of standardizing HTTP/2 was to let the more conservative among us start to use it now.
I'm not sure anyone who is switching to HTTP/2 today could reasonably be called "conservative". There are few production-level servers available yet, and some of the big potential performance wins due to the multiplexing, prioritisation and server push aspects -- the things that in theory could render those spriting and concatenation techniques obsolete -- are barely even mentioned right now outside of the standards documentation and related announcements. I just spent a few minutes searching to see how you'd actually configure a web server to implement customised server push for maximum performance, and I literally didn't find a single explanation, nor for that matter a single server even advertising the capability.
> It's certainly true that HTTP/1.1 isn't perfect and there are practical ways it could be improved, but I don't think this presentation makes a strong case for adopting HTTP/2 as the way forward.
Well, I read it more as a "If you are planning to use HTTP/2, here are ways in which you might want to alter how you plan out your service", not "You should use HTTP/2, now here's the stuff you need to go change so you can do so." Alternatively it can see it as "here's the performance hacks you no longer have to do with HTTP/2 because it has good mechanisms for this built in." In any case, I didn't get a strong vibe about how we need to abandon HTTP 1.1.
1: http://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_dif...
That may always have been the intent, but I'm not sure that was clear to those outside the Google bubble.
For example, there were numerous articles and blog posts and conference talks around the time that SPDY became a serious proposition with a similar tone to the HTTP/2 commentary we are seeing today. No doubt there were exceptions, but much of that advocacy didn't exactly come with "big red box on the first slide" warnings that SPDY was an experiment, and readers/viewers should only use it in production if they had the resources available to update things again in the relatively near future.
I do appreciate that the big news for HTTP/2 is that it has reached a more formal level of standardisation, but in the modern Web industry when browsers do whatever they want every six weeks anyway, that isn't worth as much as it used to be.
Even today, there are few production-grade tools around that actually support HTTP/2 in anything close to its final form, including a lot of the projects that do support SPDY. Phasing out browser-side support for the latter as soon as early 2016 seems like a typically aggressive Google drive to shift the web to a new technology it favours, at the expense of forcing everyone to adjust/upgrade their existing working deployments. I'm very uncomfortable about how readily they are willing to do that in their browser these days, but I don't think the permanent-beta mentality has any place in server/network infrastructure at all.
I'm happy for you that you got those kinds of results just from the switch to SPDY. None of the experiments I've seen did that well, but of course the benefits for these new protocols will depend on the specifics for each individual site.
Just to be clear, my main concern here isn't so much the protocol itself as the effect it has on all the infrastructure that is built around it and the implications for compatibility and long-term stability.
For example, there have been calls for various kinds of compression/encryption to be required. Then CRIME happened, and it turned out that using gzip compression within an encrypted stream wasn't such a good idea after all. What if the new standards had baked in that kind of security flaw?
There is also a whole industry of network monitoring tools used for intrusion protection, virus scanning, fault diagnostics, and many other useful applications. How many of those tools will work with these new protocols?
What about cache/proxy tools? Just as there are still few options for production-level servers that cope with HTTP/2, there is also a whole range of intermediary tools that serve useful purposes but don't currently have HTTP/2 counterparts.
For everyone else, it's optional. 2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it.
From an implementor's POV, 2 is easier to implement than 1. The new feature complexity is balanced by having sane parsing rules.
And remember: We've (the Internet) have been using SPDY for a couple years now. That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc.
I'm not sure not spending time and money supporting a proprietary protocol created by an organisation with a reputation for dropping anything it doesn't like any more at short notice qualifies anyone as "incompetent".
can strip out the HTTP/2 indicators and force their users back to 1.
At which point anyone whose site was designed to be friendly to HTTP/2 in the ways described in the presentation will perform dramatically worse than it does under HTTP/1.1 if nothing is changed.
2 has mandatory TLS in browsers (that's how the browser vendors are making it), so random proxies and so on just remain ignorant to it.
And you don't see a problem with that?
We've (the Internet) have been using SPDY for a couple years now.
Which Internet? A few high profile sites have been using it, but who else? Several major browsers haven't even supported SPDY until quite recently. Most don't support HTTP/2 fully yet. And in my search earlier, literally no-one was even talking about how to use some of the new capabilities to best effect server-side, never mind demonstrating server-side software that can actually do it.
That's a very long beta period and gave everyone plenty of time to play around, raise objections, write software, etc.
You must be joking.
The kind of network monitoring and security devices I was talking about have 5-7 figure price tags in US dollars, sales cycles measured in months, purchasing cycles measured in years, and working lifetimes potentially measured in decades. Two years to understand, integrate, fully test, advertise, provide for evaluation, and ultimately sell support for a new protocol is nothing in this industry.
Among the projects I have recently worked on, I think three different major web servers were used, a couple of different reverse proxies for load balancing, and assorted other proxies for caching and the like. As far as I'm aware, exactly none of them fully supports HTTP/2 as of today. And just to be absolutely clear, I'm talking about a collection of software that runs probably 90% of all web sites that exist today, if not more. Perhaps you would argue that the developers of all of these tools are also incompetent, in which case I refer the honourable gentleman to the answer I gave a few moments ago.
It's true that there are some organisations that don't rely on mainstream networking hardware and standard software stacks any more. They really do literally design and build their own network infrastructure and write a lot of their own software stack instead of buying from the big brands. However, it's also true that I could probably count the number of such organisations in the entire world on my fingers. For everyone else, these issues do matter.
Edit: Here's a handy survey of the adoption of HTTP/2 by various significant tools as of a couple of months ago. It seems broadly in line with my own experience.
http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-...
I'm not sure what you're point is when you say you couldn't find many products with HTTP/2 support now. So what? They will come to market over time. Meanwhile, SPDY has more support, and is available in free software like nginx.
I don't see a problem with TLS being required, and I don't really care for proxies being in the middle. Again, people that want this behavior can opt in by installing a cert and be MITM'd, and if a vendor can't get HTTP2 support, they can easily strip it until they do (and we'd hope this caching proxy is close to the user, so the perf penalty for downgrading is less).
And, for a site, supporting users on crappy proxies that force a downgrade is little different than supporting older browsers that don't have SPDY or HTTP2. So they'll make a choice. What's the big deal? Who is being hurt? How could this possibly work any other way? At some point, no matter the procedure, the final version of HttpVNext would have been completed. And vendors not paying attention would be in the exact same place.
Anyone who for whatever reason is using HTTP/1.1 will have a much worse experience if sites start making the kinds of changes recommended in this presentation to work better with HTTP/2 today.
If the entire GET request fits into pkt0 then there is a noticeable improvement in round-trips.
1: http://www.isi.edu/nsnam/DIRECTED_RESEARCH/DR_WANIDA/DR/imag...
You do have to try quite hard (or be careless with things like cookies) to get the size of a single request above the MTU for typical Internet usage. Chances are that in practice you are going to be requesting an HTML resource first, then probably prioritising some CSS, then JS, and then other resources like image or multimedia content. And for the responses in each case, the size will usually be dominated by the payload rather than the headers anyway. So it seems likely that in such an environment you'll be more limited initially by the response time for the HTML and the main CSS resources anyway, or by general packet loss on an unreliable network.
By the time you've got those initial resources, parsed them, and started requesting the supporting content, you've probably warmed up the TCP connection enough for slow start not to make much difference any more. Beyond that point, effects like multiplexing, prioritisation and server push seem to have more potential for increasing real world performance by reducing or eliminating certain round-trips at the HTTP layer. (This assumes that the browser and server do actually take full advantage of these new options; there seems very little discussion so far about how we might achieve this in general.)
http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...
* one tcp connection per request
* Server push functionality / server initiated streams
* current implementations means http/2 works over tls _only_ - neither Firefox nor chrome currently support non encrypted connections. This does keep things simpler with things like proxies in the middle I presume also.
* tls implementations must now support sni also so basically http/2 is now a forcing function for supporting sni which is awesome.
The listing itself is somewhat muddled ... "Twitter" is an entry, linking to the Twitter homepage, presumably that's responsible for most of this traffic? I found https://github.com/twitter/netty-http2 and https://github.com/twitter/hpack on Twitter's GitHub.