21 ms·

HTTP 2.0

434 points by abhshkdz 13y ago

abhshkdz 13y ago
Source code & issues tracker: https://github.com/http2/http2-spec https://github.com/http2/http2-spec Wiki: http://tools.ietf.org/wg/httpbis/ http://tools.ietf.org/wg/httpbis/
samwillis 13y ago
I understand the motivation to going to a binary protocol for a SPDY inspired HTTP 2.0 but I would have liked to see an ascii based protocol similar to what jgrahamc proposed last year [0]. I thought it was a much cleaner protocol to read and understand, and much more in tune with what the web is supposed to be. Why not keep the clever binary stuff separate in SPDY, endorse it though the IETF and keep HTTP ascii? [0] http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-pr...
- steveklabnik 13y ago
  There were so many people just calling for rubber-stamping SPDY as HTTP 2.0 without any changes that frankly, I feel lucky that we're getting revisions at all. The editor of the draft is a good guy, and I trust him to make good changes. I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web talks to each other with very little questioning, but this is the place that we're at nowadays. For better or worse, the big vendors guide the standards process. I'd like to see more involvement from the little guys, but that has its own set of challenges.
  - aroch 13y ago
    >I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web talks to each other with very little questioning I don't think there's very little questioning...in anycase, Google's goal is to deliver ads to you in the most efficient and fastest way possible. The more you browse the web the more Google makes; it's in their interest to develop SPDY/HTTP2.0. So what is wrong with them doing it? IEFT spec drafts are public and they're audited (as SPDY has been). Also, most of the specs that we love and rely on today came from "big vendors", its nice and all to say you want the little guy to be a part (and they should be) but it takes quite a bit of man power to develop, draft and finally get ratified a spec.
    - _delirium 13y ago
      Also, most of the specs that we love and rely on today came from "big vendors" The core internet protocols we rely on, though, mostly didn't. If you look at the authors of RFCs specifying the widely used standards, nearly all of them were at research institutions: Steve Crocker was at UCLA then ARPA; Vint Cerf was at UCLA, then Stanford, then ARPA; Bob Kahn was at ARPA; Jon Postel was at UCLA then USC; Paul Mockapetris was at UC Irvine; Abhay Bhushan was at MIT; Tim Berners-Lee was at CERN then MIT. Not sure if that's good or bad, but it seems to have been uncommon until recently for internet protocols to come from vendors. edit: I did think of one important one, IPv6. Steve Deering was at Stanford, then Xerox PARC, then Cisco, and IPv6 came out during his Xerox/Cisco period. Bob Hinden was at Ipsilon Networks, then Nokia.
      - cpr 13y ago
        Don't forget Dave Clark, who at MIT, and is the chief architect of TCP itself.
      - brokenparser 13y ago
        it seems to have been uncommon until recently for internet protocols to come from vendors Sorry, that's been going on for quite a while now. Cases in point: http://tools.ietf.org/html/rfc3768 http://tools.ietf.org/html/rfc3768 http://tools.ietf.org/html/rfc5077 http://tools.ietf.org/html/rfc5077 http://tools.ietf.org/html/rfc2637 http://tools.ietf.org/html/rfc2637 http://tools.ietf.org/html/rfc2281 http://tools.ietf.org/html/rfc2281 (these are just examples, there are many more citing Cisco, Microsoft, Nokia, Google, etc.)
    - steveklabnik 13y ago
      > IEFT [sic] spec drafts are public and they're audited (as SPDY has been). Absolutely. But there's more than one kind of control. I don't think enough programmers understand the effects of social control. If the standards are all public and audited, but only employees of Apple, Google, and Microsoft have the time and energy to keep up with discussions, well... And, of course, I'm not imply that _only_ that is true, I just fear that big organizations are dominating the discussion. I have more free time than the vast majority of programmers, are subscribed to the HTTP 2.0 mailing list, and find it hard to keep up.
  - tptacek 13y ago
    What does Google's involvement in advertising have to do with the design of the SPDY protocol? Can you make a substantive criticism of SPDY based on Google's advertising incentives, or is this just innuendo?
    - steveklabnik 13y ago
      Soley on their advertising incentives: no. It's a rhetorical flourish. That said, I _do_ think it's extra important to pay attention to what Google does, for two reasons: 1. They're the largest entity on the Internet. This means their incentives are different than smaller players. 2. They _are_ an advertising company. Advertising companies make money by showing ads. They make more money by showing targeted ads. You target ads by collecting data on people. I think people often forget Google's purpose in the world, and are simply dazzled by 'whoah cool stuff.' I appreciate some of Google's more interesting and ambitious initiatives, but get very scared when people start accepting any entity's actions without question. Specifically when that entity has large financial incentive to collect data about people. There are, of course, many technical criticisms of SPDY, but none that rely specifically on the advertising angle.
      - vanderZwan 13y ago
        While I agree with keeping a healthy skepticism of Google, I have a bit of difficulty with this wording: > I think people often forget Google's purpose in the world The fact that Google makes money through showing ads doesn't mean it's their purpose.
        tptacek 13y ago
        I think it's fair to argue that a company's purpose is best illustrated by its revenue streams. Reasonable people can disagree depending on the circumstances.
        alexsb92 13y ago
        In some cases, a company could transcend its initial purpose, but still keep it around as a/the revenue stream as a means to the new end. Not many/any new and further out there Google initiatives have made it to wide scale public adoption, so it's yet unclear whether Google would be such a company, but it could very well turn out to be one.
  - 9h1d9j809s 13y ago
    > I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web First, to call Google an advertising company makes no sense. It's a tech company. You don't call a newspaper an advertising company either. Second, there were people involved in designing this, not just an anonymous corporation. You can actually see their names in the proposals. It's a good design, that's why it has been adopted.
    - steveklabnik 13y ago
      > First How does Google make money again? Newspaper companies are advertising companies, especially given the quality of the news lately. ;) > Second Absolutely, and I don't mean to denigrate their technical efforts. I'm glad people want to move the web forward. I'm just recommending caution. > It's a good design, that's why it has been adopted. Many poor designs have garnered wide adoption in the past, this is not inherently true.
      - lazyloop 13y ago
        Wide adoption of SPDY also seems like quite an overstatement, a few big players have been trying it, but the only number we have so far is 339 SSL certificates used with SPDY-enabled servers in may 2012. http://news.netcraft.com/archives/2012/05/02/may-2012-web-server-survey.html http://news.netcraft.com/archives/2012/05/02/may-2012-web-se...
    - md224 13y ago
      A Google recruiter actually told me that Google is "basically an advertising company." Then again, he was recruiting for an AdWords-related position, so his viewpoint may have been skewed.
  - smutticus 13y ago
    > For better or worse, the big vendors guide the standards process. It costs money to have people on staff who write IETF drafts and haggle them up to RFCs. Hopefully the standard isn't too degraded by the needs of Google in this instance and everyone benefits.
    - steveklabnik 13y ago
      Absolutely. I'm not saying that it doesn't. I share your hope, but I'm not super optimistic in the general case.
  - youngtaff 13y ago
    Oh come on don't let paranoia encourage you to throw the baby out with the bath water… The way Mark Nottingham ran the original CFP for HTTP 2 and the eventual adoption of SPDY as a starting point was very fair - it's all there in the IETF archives for anyone to see. From memory there were only two other proposals (from Microsoft and someone else) The reason Google were able to get a new protocol up and running is because they have both heavily used web properties and a browser. They're also willing to carry out experiments in public. As it stands HTTP 2.0 will be good for the little guys too, based on the testing I've done little guys will see an improvement in performance without needing to do all the merging that destroys cache lifetimes. 3rd party-content is the fly in the ointment to the performance improvements so we'll need to be much more careful about the performance of the 3rd party sites we include. N.B. Apart from using their products I have no affiliation with Google
- nodata 13y ago
  Point him towards the github repo!
- nileshtrivedi 13y ago
  Genuine question: Is it really that big of an issue? We still have to use tools (telnet/curl) to inspect text-based protocols. We don't examine raw bytes by hand, do we? In other words, isn't every protocol ultimately a binary one and the issue here is only a matter of degree?
  - voidlogic 13y ago
    It probably already exists, but you could write a telnet that simply displays ASCII and hex side-by-side. I used something like this when I used to reverse engineer laboratory device control protocols (but it was a hardware implementation: http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agilent-4957A_R.png http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agil...) Not to mention wireshark...
    - holalala 13y ago
      tool already capable of doing it is socat. ex: socat -v -x - tcp:google.com:80 add >/dev/null if you want do discard plain text output. also works over ssl: $ socat -v -x - openssl:google.com:443,verify=0
  - tptacek 13y ago
    An argument that it's a fake issue: the fact that best-practices compliant HTTP applications already tend to run under HTTPS, and that understanding what's happening at an HTTPS level in operationally-relevant ways (namely: are we performant enough? and are we secure enough?) already requires parsing of that binary protocol.
  - nmcfarl 13y ago
    I think it is. We have a large amount of tooling in existence to inspect text based formats. Binary format inspection requires new tooling to be written and deployed. This is a major barrier. I may be a bit old-school, but I learned HTTP via telnet, a tool definitely not written to inspect HTTP, and I still use it when I’m trying to debug things. Not having to install tooling is still something I take advantage of. Obviously binary formats can and do succeed, and with sufficient backing tools will be written and deployed. But if HTTP hadn’t been so easily inspect-able I don’t think it would have been nearly as successful the 1st time around, when the benefits of the protocol where less well known. And I do think some of the "culture of the protocol" will be lost moving to binary°. It just isn’t as hacker-friendly or at least newbie-hacker-friendly and that sends a message. - ° Of course this is already happening with HTTPS, so this is probably not a winnable fight. And the benefits of binary formats are significant, so it might not even be a fight I want to win. Still something is being lost here.
- voidlogic 13y ago
  >I would have liked to see an ascii based protocol I disagree I think HTTP should have been a simple binary protocol from the start and HTML should have required compilation into a binary format. How much work would have it really been? htmlcmp foo.html providing foo.bhtml. No whitespace, No end tags, one or two byte tags, etc. Strictness in the reference HTML compiler implementation could have saved the web from all the stuff outside the actual standard that browsers (and other tooling) now have to support (so they don't "break" the web). I'm not suggesting anything as crazy as the flash binary format (I wrote a Java flash player once...), but when I started to write things like proxy servers and HTML minifers I was blown away by the extreme inefficiency of HTTP/HTML. This is a step in the "right" direction IMHO.
  - samwillis 13y ago
    I believe that the "world wide web" took off for two reasons. It was completely free and it was incredibly easy for ANYONE to make a website. If you needed to "compile" all HTML it would have discouraged a lot of casual experimentation. Not everyone understands what a compiler is. Just as an example I started playing around with HTML when I was about 12 (in 1998), it was easy and I got instant results. A year or so later I tried to learn Perl and quickly gave up because I couldn't get my first script to run. It was another year before I tried to "program" again and became hooked. HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way.
    - voidlogic 13y ago
      >HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way. The web is big enough today that we can afford to make it more efficient since we have so many professionals that don't require the kind of implicit hand-holding provided by the original implementations. Back then everyone was a newbie and there were no web professionals.
      - samwillis 13y ago
        I think we need to be careful about claiming its more efficient. There seemed to be significant disagreement about how much more efficient SPDY was last year from the various different benchmarks. From memory the consensus seemed to be that its only 5-10% quicker. Does anyone have any more up to day benchmarks? I hate the idea that you would have to be a "web profesional" in order to get started today. We should embrace and keep the culture the web was built on.
- josteink 13y ago
  > understand the motivation to going to a binary protocol for a SPDY inspired HTTP 2.0 but I would have liked to see an ascii based protocol You're not alone. I've opened an issue on the subject [0]. Feel free to add weight to it. [0] https://github.com/http2/http2-spec/issues/169 https://github.com/http2/http2-spec/issues/169
  - klodolph 13y ago
    That's a childish way of asking for what you want: (1) opening an issue in the wrong forum and (2) failing to familiarize yourself with the previous discussion threads. You know this is a controversial topic, please act more maturely in the future. Any time a bug report is linked in Hacker News the community ends up spamming the tracker with our enlightened opinions. Show some restraint.
    - josteink 13y ago
      > (1) opening an issue in the wrong forum and (2) failing to familiarize yourself with the previous discussion threads OK. Fair enough, but I did look for an existing issue on the matter. There were none. > You know this is a controversial topic, please act more maturely in the future. Personally, I find attempting to lock down open internet-protocols by transforming them into some sort of binary obscurity rude and against everything the internet was built on. I don't think everyone is aware about that happening right now. and I see nothing wrong with attempting to bring focus to the issue if that is what needed. Seeing how this draft still outlines a binary-protocol, this clearly still is in need of attention. Just because some Google-heads somewhere decided that by completely ignoring everything the internet has taught us so far, and in the name of pre-mature optimization can shave off 2ms on their page-load doesn't mean the internet should pander to their interests. If anything is controversial it is how this is all being done without any documentation showing us what benefits we get from the costs associated with a binary protocol. That is amazing. Completely and utterly amazing. But OK. Let's say I listen to your guidance: Where would be a good place to raise this issue? Where would I take my "childish" issues to ensure they get the attention they so much deserve?
- peterwwillis 13y ago
  This idea is bad for a couple reasons. First, ASCII is inefficient. People don't interpret HTTP, computers do. Web servers and browsers. People only look at HTTP when they want to troubleshoot without any tools. With real tools, you can find out what's broken much quicker. And there's plenty of things you can miss without a real HTTP interpreter. Most hackers prefer to think of themselves as wizards that can spy 0's and 1's and tell you what the weather is. It doesn't make for a better protocol, though. Second, we can already break HTTP responses up in multiple parts, using a novel idea called "multipart". It sucks and nobody has used it since HTML/JS found new ways of providing content. http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html Third, it's a hack. If you want to improve the protocol, improve the protocol, don't just hack onto it to make it do what you want. I could make a horse and buggy go 60mph, but would it be a good idea? How about just designing a better buggy that is intended to go 60mph? Fourth, fixed-length records are the wave of the future! It solves crazy problems like header injection and request integrity checking. Moreover, it makes for simpler, more efficient parsing of requests. Fifth, redundancies introduced from the beginning of time need to go away, like terminating every record with "\r\n", or passing the same headers on every single damn request when once should be just fine for a stream of requests. Little inefficiencies like this don't go away if you just hack onto the same old protocol forever. Sixth, the flow control improvements can make different applications more efficient by both not having to hold state of where and when traffic is coming and improving flow across disparate network hops. Seventh, as to a general question "why use binary when we can compress stuff", what is smaller: a string of bits, or a compressed string of digits? Add to this that every header could have a 32-bit identifier (4 bytes) and you've got more efficient compression than gzip. Of course, most people would argue that you don't save enough time or bandwidth or cpu cycles to make a difference, but it would make for easier-to-write parsers, which would make working with the protocol in general more attractive. But then you have your binary-detractor-wizard-hackers and the whole conversation becomes an infinite loop.
  - deleted 13y ago
    [deleted]
  - romaniv 13y ago
    The same arguments can be applied to HTML, CSS, JSON, RSS and so on. I fail to see the crucial difference between those and HTTP. Or would you say the web as a whole should be binary? Fifth, redundancies introduced from the beginning of time need to go away I wholeheartedly agree with this, but it doesn't automatically warrant binary encoding. Human readability is a huge bonus in any protocol or format. Not because normally people read those protocols, but because people read ASCII and therefore they have good tools to work with ASCII.
- H3g3m0n 13y ago
  There is no reason why someone couldn't build a tool to send/receive binary responses and print them out as text. We have wireshark anyway. Just need a cli translator or a program that lists all the possible valid inputs for a given connection state and lets you select one (and allows for raw input just in case you want to try and break something). For most cases you will probably be able to get the old HTTP protocol anyway. The only potential issue would be for people who are implementing the HTTP 2.0 protocol itself, just about everyone else in the world will be using a webserver or at least a library. In fact raising the bar to prevent people developing their own HTTP 2.0 implementations would probably be a good thing, it would cut down on the number bug riddled implementations. In any case I don't think it makes sense to slow down the whole internet just for a few developers. Binary could also see the possibility of hardware implementations. Think webserver on a chip.
- abionic 13y ago
  no matter what all says, it's all because Google researched on SPDY
- charonn0 13y ago
  I agree. HTTP, like many core internet protocols was designed to work with any client setup, even someone sitting at a telnet terminal sending hand-rolled HTTP requests. FTP is just the same, and SMTP, etc. While very few people these days will actually wind up using telnet to access network resources, it is a very successful design and one which ought not be abandoned without considerable thought.
- bitwize 13y ago
  HTTP 1.x was fine for the early 1990s. It's 2013 and Windows has won. Unix is dead. Maybe you have a nice Ubuntu box and that's fine. I'm talking philosophically. Modern developers favor the performance and functionality advantages that large applications, deep APIs, and binary communication protocols provide over the transparency advantages that small, highly focused tools, orthogonal APIs, and human-readable communication protocols provide.
  - olentangy 13y ago
    Unix is dead? Aren't Mac OS X, iOS, and Android basically unix OSes? I'd say Unix won.
    - bitwize 13y ago
      The essence of Unix is not in the name of Unix, nor in the code of Unix, said Master Foo. And then Chuck Norris roundhouse-kicked him in the face. Point being that if by Unix you mean an OS running a Unix-inspired kernel, then yes, Unix won. But if by Unix you mean the design patterns and philosophical principles that have long inhered to Unix development, then Unix is, if not dead, then on its last legs and soon to be discredited. The "Unix philosophy" has long favored small, easily composable tools each with a specific purpose, orthogonal APIs which were as small as possible, and textual transmission formats which are easy for humans to read and write. There were exceptions (X, Emacs), but these exceptions tended to support and play well with the Unix philosophy even if they didn't 100% espouse it. By contrast we may propose a Windows philosophy which favors large, do-everything applications over small tools (because that's how people are accustomed to using PCs starting from the DOS days when only one program could be up at a time), heavyweight frameworks and oftentimes entire inner platforms (because in a world where time-to-market is paramount, developers shouldn't have to think very hard to begin cranking out apps for the new technology of the week), and binary file formats (because the damn thing has to run in 640k, a text parser won't fit). Look at the platforms you mentioned. Mac OS X, iOS, and Android are all app-centric, not tool-centric. You can treat Mac OS X as a Unix box if you want, but it's hard to do so with the other two. Furthermore, when you write an app for these platforms you are not targeting the Unix kernel or libraries but an inner platform built on top of them. Which brings us to binary file formats -- like HTTP 2.0. The Windows philosophy has won.
antirez 13y ago
Congrats to Google for ruining the internet standards in an official way, without strong proofs of big significant improvements over the simpler past protocol.
- tptacek 13y ago
  Don't confuse the cart and the horse. The IETF standardization process has never been less relevant than it is today. The reality of deployment of a "next-generation HTTP" involves two things, neither of which the IETF has any say in: (a) whether anyone can improve HTTP as it runs between a mainstream browser (or some as-yet unforeseen browser replacement) and a content serving backend in a way meaningful enough to drive adoption, and (b) buy-in from the major browser owners. That's the way it's supposed to work; the horse is meant to drag the cart. The RFC database is littered with cart-led insurgencies that went nowhere. If binary HTTP is one of those, it'll join them as a historical curiosity.
  - antirez 13y ago
    My fear is that now that Google controls a significant part of HTTP traffic, plus the client side of the story (Chrome + Android), it is in a condition to force things in one way or the other...
    - tptacek 13y ago
      I suppose that's a valid concern, but note that Google's control over the protocol was already pretty strong by dint of running Google.
    - reidrac 13y ago
      Do you think Google is now in a better position to force things in one way or another than Microsoft was in the 90s?
      - hugi 13y ago
        It's in a similar position. And see how that ended up with Microsoft — we're still suffering the consequences.
RyanZAG 13y ago
Only implementations of the final, published RFC can identify themselves as "HTTP/2.0". Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". Here we go again - as with -webkit in css, expect 'HTTP/2.0 DRAFT' or similar to be the new http 2.0.
- dragonwriter 13y ago
  I think in the real world its not "HTTP/2.0 DRAFT" but "SPDY".
deleted 13y ago
[deleted]
sktrdie 13y ago
Can anybody summarize the main differences between this and the older versions of HTTP?
- jeffasinger 13y ago
  Binary protocol, every connection is TLS, and multiple requests can be put over the same TCP connection and answered in any order. I didn't read this super carefully, but this is basically Google's SPDY protocol.
  - ctz 13y ago
    I don't think every connection is TLS. This is obviously a critical mistake, given HTTPS stripping is possibly the biggest weakness in current web transport security.
    - deleted 13y ago
      [deleted]
    - twoodfin 13y ago
      There have been several debates about making TLS mandatory in HTTP 2.0 on the ietf-http-wg mailing list. Here's a link to a NetFlix engineer's comment in the most recent one I could find: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0494.html http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/... In short: While TLS is a really good idea for just about every user-facing site on the web, there are many applications where some combination of the administrative burden, need for intermediaries and performance cost make TLS sufficiently undesirable to preclude adoption of a spec that required it.
- joosters 13y ago
  Binary protocol. Header compression. Multiple concurrent 'streams' (or requests) over the same TCP connection.
  - sktrdie 13y ago
joosters 13y ago
At first glance, the spec appears to be re-implementing a TCP stack inside a TCP connection...
- wmf 13y ago
  Yes, the reason is that starting a new stream multiplexed inside an already-open TCP connection is faster than starting a new TCP connection. Attempts to improve TCP itself are slowed down by slow uptake of new Windows versions.
  - joosters 13y ago
    That's not true. HTTP/2.0 (or at least the successor to HTTP/1.1) has been discussed for over a decade, there have been many OS releases since then! Inventing a whole new protocol to overcome a TCP deficiency is IMO a terrible motive...
    - pritambaral 13y ago
      These guys have something to say about that: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm... A new protocol that runs on UDP precisely to side-step slow TCP changes.
      - nly 13y ago
        That's great, but it means it'll always be a userland library rather than a OS supported networking protocol... which means the API will never be a defacto standard akin to the BSD sockets API. The reference implementation is also in obtuse looking C++... which will hinder bindings to other languages. In short, don't expect to see this outside of Android or Chrome. On the plus side, this is exactly what UDP was for in the first place.
  - bcoates 13y ago
    What efforts are these? That sounds much more interesting than mucking around with HTTP micro-optimizations.
joeyh 13y ago
"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" Ah, so every HTTP 2.0 connection has PRISM in it.
- bbanyc 13y ago
  It started out as "FOO ... BAR" but that made the header an odd number of bytes long. In the previous draft it was "FOO ... BA". It was briefly "STA ... RT" which made too much sense to use.
- Trufa 13y ago
  I'm worried about the amount of reddit like comments in HN.
xcnm3 13y ago
Given the close relationship between Google and the NSA, I suggest they are removed from the IETF until further notice. I would trust Microsoft more than the snake oil Google produces. No surprise they've opted for a binary protocol rather than ASCII, anything to reduce transparency
- tootie 13y ago
  Microsoft has been just as cooperative with the NSA as Google. They have access to Bing and Skype.
- cromwellian 13y ago
  What close relationship between Google and the NSA are you referring to?
  - xcnm3 13y ago
    Google providing direct access to their servers and infrastructure. Every Google service was open to the NSA; GMail, Google Drive, Google Talk, you name it.
    - cromwellian 13y ago
      And the evidence for this is?
      - xcnm3 13y ago
        Please read the leaked information from Edward Snowden. I don't wish to paraprase the last few weeks of news for someone.
        cromwellian 13y ago
        It's a rhetorical question. None of the leaks provide any evidence that Google actively cooperates with the NSA in any way. No evidence of equipment at Google data centers, no evidence of any kind of remote access for the NSA, other than the already existing legal channels. The claim that Google had foreknowledge of PRISM, or worked with the NSA to build some kind of firehose for them is unsupportable given what we know, and is pure speculation on your part. Thus, the claim of close cooperation with the NSA is frankly, ad hominem.
antitrust 13y ago
This makes it easier for web application designers, but is less optimal for those publishing static pages, which are actually the mainstay of the web. Further, it's less user-explorable, which further distances the web from access by the everyday tinkerer as opposed to the professional with lots of time to explore.
ge0rg 13y ago
I really disliked the following part: A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the connection header. [..] Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections. (Section 3.4) That means, whenever you open a new TCP connection to a http2 server, you must start with HTTP/1.1 and perform the Upgrade negotiation anew. Making the spec require HTTP2 support on all servers of a cluster if at least one server supports it would have been much better, performance-wise. The only reason I see why they kept it is transparent proxies (if your browser is using an explicit proxy, it should be able to figure out if the proxy supports HTTP2).
- peterwwillis 13y ago
  Browsers already send HTTP/1.1 by default, which would be rejected by HTTP/1.0 servers. HTTP/2.0 would be rejected by HTTP/1.1 servers and the browser could retry, or it can try for the Upgrade. Either way, with time, we can change the browser to behave differently based on the number of servers supporting that protocol, the same as with HTTP/1.1.
  - ge0rg 13y ago
    Yes, but storing "supports HTTP2" for a given server for a given time after connecting to that server and negotiating the upgrade would also do the job. One of the problems with HTTP 1.x is that it is stateless - every time you want something from a server, you treat it as if it is the first time you talk to it. I understand this is by design, but as a consequence we are transmitting all the same headers to the server all the time... which can be mitigated with HTTP2, except that we still need to do that (send all headers) and the HTTP2 upgrade, every time we open a new TCP socket to that server.
Sephr 13y ago
You still can't self-sign certificates and rely on certificate pinning for transport security without domain verification. With all of the security concerns people have with governments logging all unencrypted internet traffic, I was hoping HTTP 2.0 would require or at least optionally allow self-signed cert TLS for every http: connection (with no UI indication to the user that they are secure) and require CA-signed cert TLS for https: We're also still stuck with DEFLATE, which is vastly inferior to modern compression formats like LZMA.
- samwillis 13y ago
  Encryption is only half the problem, authentication is the other. Self signed certificates don't authenticate the web server and allowing them would open the web up to MITM attacks. What we need is some form or decentralised certificate authority, i have no idea how that could work though. HTTP allready supports LZMA, its just the browser and web servers that dont. If a browser sent the header: Accept-Encoding: compress, gzip, lzma instead of: Accept-Encoding: compress, gzip and the server supported it, it would "just work". Unfortunately none of the major browsers or server have implemented it.
  - Sephr 13y ago
    Unencrypted HTTP is already open to MITM attacks. What I proposed was using self-signed certificates in conjunction with certificate pinning, which means that as long as your first connection to a website isn't MITMed, later connections cannot be MITMed or snooped on. As for the compression, I was referring to LZMA for header compression. I am well aware of implementation efforts of LZMA in Firefox and Chrome.
  - skrause 13y ago
    What we need is some form or decentralised certificate authority, i have no idea how that could work though. DNSSEC could be used to distribute certificates: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
    - 13y ago
ancarda 13y ago
Hmm... I have a few scripts that do something like: header($_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request'); Since I'm using SERVER_PROTOCOL, if I upgraded Nginx and it started to send HTTP/2.0 traffic to the server, would I need to rewrite this line? How would I send a specific status code using the new binary protocol?
- iso-8859-1 13y ago
  Just use header("Status: 400 Bad Request");
lnanek2 13y ago
Well this is clever: " HTTP/2.0 enables a server to pre-emptively send (or "push") multiple associated resources to a client in response to a single request. This feature becomes particularly helpful when the server knows the client will need to have those resources available in order to fully process the originally requested resource. " If someone asks for your HTML, might as well send them the CSS, JS, and images it is going to use. Would cut down on requests. Only thing more efficient than compression, is not having to ask in the first place.
- jimktrains2 13y ago
  Couldn't we already do this with multipart requests that no one uses?
- duaneb 13y ago
  It also complicates caching: do you cache the response by request, or cache the resources individually by update time (or whatever)?
cientifico 13y ago
Hope http 2.0 is the new ipv6 !
popee 13y ago
HTTP/2.0 should be SIP because of similarities and also integrated session management. Not some application layer binary protocol to spy on people even faster. Yeah baby :-)
ddalex 13y ago
Is this a proposal to reimplement (badly) TCP inside of HTTP ? So we'll have a TCP stack running on top of a TCP stack ? Those who don't learn history are doomed to repeat it. I predict that this will lead to unexpected performance problems due to collisions in Tx window size between TCP windows and HTTP 2.0 frames.
Aloisius 13y ago
Oh wonderful, it appears to use SPDY-like header compression. Why don't we just create a new compression algorithm and predefine common HTML tags and words to improve compression of the response body too! But we shouldn't base it on any known compression scheme and only use it for the case where the content length is less than 220,498 bytes but more than 8,494 bytes to optimize the behavior of today's more common MTU settings for PPPoE in Scandinavian countries minus of course the most common size of compressed headers today. It will be particularly optimized for the kind of responses Google sends back to minimize their own server load and common adwords will of course be included in the predefined list of compressed tokens. /sarcasm What happened to simple protocols? Seriously, per-hop flow control (which works best with which of the dozen version of TCPv4 or TCPv6 flow control?)? TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly ridiculous specialized compression for headers which ignores the role of HTTP proxies? QoS? Why not just implement the whole protocol over a raw IP connection and stop pretending like we're operating in layer 4+? I get that multiplexing is difficult without flow control, but good lord does this thing look overdesigned for what few benefits it offers over HTTP/1.1.
- tptacek 13y ago
  Recapitulating a comment from downthread, but, look at DNS for an example of how the IETF botches compression in its "simple" protocols. Not that compression isn't fraught (look at TLS), but I see its use as a sign of maturity.
- angersock 13y ago
  Well, we had a nice thing for a while, and now it's time to fuck that all up. The wheel turns. Look on the bright side--if everyone decides the public Internet is too insecure, maybe we can convince them to keep using the old standards on darknets?
- nly 13y ago
  I can't help thinking some of the pain could be resolved if we had a reliable datagram protocol between UDP and TCP. Delimiting a TCP stream to create a messaging protocol is already suboptimal and error prone, and it's the root cause of the head-of-line blocking problem experienced by HTTP ('fixed' in SPDY).
stormbrew 13y ago
I still feel like this is just being rammed through far far too fast. SPDY might well be the right way to go, but it's only been deployed for a small number of very large sites for a couple of years at this point. It was a foregone conclusion when the schedule was announced for http2.0 that it would be spdy, because only spdy has demonstrable value in production. There was no time for anyone to come up with or evaluate an alternative. But on the other hand, there hasn't been near enough time to demonstrate that spdy is good for the whole internet, which is what blessing it with the http protocol name implies. And I just don't see why it should be rammed through. SPDY has a connection upgrade path, that afaik is largely unchanged for http2.0 anyways.
- drivebuy 13y ago
  > because only spdy has demonstrable value in production. What demonstrable value? Google has never compared it to pipelining and when Microsoft did so they found it about the same and sometimes slower. There is next to zero value in SPDY over pipelining across several connections. It's just complicated for no good reason.
  - stormbrew 13y ago
    I think you're seeing a defence of spdy in my post that isn't really there. By value I mean simply that it is at least functional. Any alternative proposal, given the short proposal cycle, would not even have that.
yalogin 13y ago
Totally superficial but why do I have to type http every time? Why can't it be h and hs (for https). Quicker to type.
neuroscr 13y ago
Most of the complaints are around the ascii vs binary. Can we just make it accept both and move on?
jlarocco 13y ago
Going to binary seems kind of silly at this point. HTML is text. Javascript is text. XML is text. JSON is text. SVG is text. CSS is text. Is it really worth the complication to save a few bytes on HTTP headers when you're just going to shovel out inefficient text data in most cases anyway? I don't understand why they're trying to shove this down everybody's throat as a new version of HTTP. There are a ton of ports besides 80. The better thing to do, IMO, would be to make a new protocol on some other port and add it to their browsers.
- josteink 13y ago
  According to the shills employed by or rooting for Google, here on HN and elsewhere on the internet, it's not silly: It is paramount. See, it allows the request for www.google.com, including all of Google's tracking cookies, to fit inside one TCP-frame, causing a 5ms improvement in load time, and Google has evidence that this means they make more money. Never mind the open, exploratory nature of the internet and how text-based protocols was what made the internet into what it is today. We're going to throw away all that which the internet has taught us about that because Google says we should. This thing is fucked up beyond belief. Edit: found a link to the IETF discussion about this: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0254.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/... It admits in plain sight that the only thing they care about with HTTP 2.0 is solving Google's massive-scale issues at the cost of everyone else: > I finally admitted it was a dead end. At the moment the challenges consist in feeding requests as fast as possible over high latency connections and processing them as fast as possible on load balancers A good, open, self-documenting protocol didn't suit Google, so let's throw it away. It's a "dead end", after all. Jesus christ these people need a bitch-slapping. More emails on the subject can be found here: http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=The+use+of+binary+data+in+any+part+of+HTTP+2.0+is+not+good&index-grp=Public_FULL&index-type=t&type-index=ietf-http-wg http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-...

434 points by abhshkdz 13y ago

Source code & issues tracker: https://github.com/http2/http2-spec https://github.com/http2/http2-spec Wiki: http://tools.ietf.org/wg/httpbis/ http://tools.ietf.org/wg/httpbis/

samwillis 13y ago

I understand the motivation to going to a binary protocol for a SPDY inspired HTTP 2.0 but I would have liked to see an ascii based protocol similar to what jgrahamc proposed last year [0]. I thought it was a much cleaner protocol to read and understand, and much more in tune with what the web is supposed to be. Why not keep the clever binary stuff separate in SPDY, endorse it though the IETF and keep HTTP ascii? [0] http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-pr...

steveklabnik 13y ago
There were so many people just calling for rubber-stamping SPDY as HTTP 2.0 without any changes that frankly, I feel lucky that we're getting revisions at all. The editor of the draft is a good guy, and I trust him to make good changes. I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web talks to each other with very little questioning, but this is the place that we're at nowadays. For better or worse, the big vendors guide the standards process. I'd like to see more involvement from the little guys, but that has its own set of challenges.
- aroch 13y ago
  >I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web talks to each other with very little questioning I don't think there's very little questioning...in anycase, Google's goal is to deliver ads to you in the most efficient and fastest way possible. The more you browse the web the more Google makes; it's in their interest to develop SPDY/HTTP2.0. So what is wrong with them doing it? IEFT spec drafts are public and they're audited (as SPDY has been). Also, most of the specs that we love and rely on today came from "big vendors", its nice and all to say you want the little guy to be a part (and they should be) but it takes quite a bit of man power to develop, draft and finally get ratified a spec.
  - _delirium 13y ago
    Also, most of the specs that we love and rely on today came from "big vendors" The core internet protocols we rely on, though, mostly didn't. If you look at the authors of RFCs specifying the widely used standards, nearly all of them were at research institutions: Steve Crocker was at UCLA then ARPA; Vint Cerf was at UCLA, then Stanford, then ARPA; Bob Kahn was at ARPA; Jon Postel was at UCLA then USC; Paul Mockapetris was at UC Irvine; Abhay Bhushan was at MIT; Tim Berners-Lee was at CERN then MIT. Not sure if that's good or bad, but it seems to have been uncommon until recently for internet protocols to come from vendors. edit: I did think of one important one, IPv6. Steve Deering was at Stanford, then Xerox PARC, then Cisco, and IPv6 came out during his Xerox/Cisco period. Bob Hinden was at Ipsilon Networks, then Nokia.
    - cpr 13y ago
      Don't forget Dave Clark, who at MIT, and is the chief architect of TCP itself.
    - brokenparser 13y ago
      it seems to have been uncommon until recently for internet protocols to come from vendors Sorry, that's been going on for quite a while now. Cases in point: http://tools.ietf.org/html/rfc3768 http://tools.ietf.org/html/rfc3768 http://tools.ietf.org/html/rfc5077 http://tools.ietf.org/html/rfc5077 http://tools.ietf.org/html/rfc2637 http://tools.ietf.org/html/rfc2637 http://tools.ietf.org/html/rfc2281 http://tools.ietf.org/html/rfc2281 (these are just examples, there are many more citing Cisco, Microsoft, Nokia, Google, etc.)
  - steveklabnik 13y ago
    > IEFT [sic] spec drafts are public and they're audited (as SPDY has been). Absolutely. But there's more than one kind of control. I don't think enough programmers understand the effects of social control. If the standards are all public and audited, but only employees of Apple, Google, and Microsoft have the time and energy to keep up with discussions, well... And, of course, I'm not imply that _only_ that is true, I just fear that big organizations are dominating the discussion. I have more free time than the vast majority of programmers, are subscribed to the HTTP 2.0 mailing list, and find it hard to keep up.
- tptacek 13y ago
  What does Google's involvement in advertising have to do with the design of the SPDY protocol? Can you make a substantive criticism of SPDY based on Google's advertising incentives, or is this just innuendo?
  - steveklabnik 13y ago
    Soley on their advertising incentives: no. It's a rhetorical flourish. That said, I _do_ think it's extra important to pay attention to what Google does, for two reasons: 1. They're the largest entity on the Internet. This means their incentives are different than smaller players. 2. They _are_ an advertising company. Advertising companies make money by showing ads. They make more money by showing targeted ads. You target ads by collecting data on people. I think people often forget Google's purpose in the world, and are simply dazzled by 'whoah cool stuff.' I appreciate some of Google's more interesting and ambitious initiatives, but get very scared when people start accepting any entity's actions without question. Specifically when that entity has large financial incentive to collect data about people. There are, of course, many technical criticisms of SPDY, but none that rely specifically on the advertising angle.
    - vanderZwan 13y ago
      While I agree with keeping a healthy skepticism of Google, I have a bit of difficulty with this wording: > I think people often forget Google's purpose in the world The fact that Google makes money through showing ads doesn't mean it's their purpose.
      - tptacek 13y ago
        I think it's fair to argue that a company's purpose is best illustrated by its revenue streams. Reasonable people can disagree depending on the circumstances.
        alexsb92 13y ago
        In some cases, a company could transcend its initial purpose, but still keep it around as a/the revenue stream as a means to the new end. Not many/any new and further out there Google initiatives have made it to wide scale public adoption, so it's yet unclear whether Google would be such a company, but it could very well turn out to be one.
- 9h1d9j809s 13y ago
  > I think it's pretty ludicrous that so many people are willing to let an advertising company basically re-write the way that every computer on the web First, to call Google an advertising company makes no sense. It's a tech company. You don't call a newspaper an advertising company either. Second, there were people involved in designing this, not just an anonymous corporation. You can actually see their names in the proposals. It's a good design, that's why it has been adopted.
  - steveklabnik 13y ago
    > First How does Google make money again? Newspaper companies are advertising companies, especially given the quality of the news lately. ;) > Second Absolutely, and I don't mean to denigrate their technical efforts. I'm glad people want to move the web forward. I'm just recommending caution. > It's a good design, that's why it has been adopted. Many poor designs have garnered wide adoption in the past, this is not inherently true.
    - lazyloop 13y ago
      Wide adoption of SPDY also seems like quite an overstatement, a few big players have been trying it, but the only number we have so far is 339 SSL certificates used with SPDY-enabled servers in may 2012. http://news.netcraft.com/archives/2012/05/02/may-2012-web-server-survey.html http://news.netcraft.com/archives/2012/05/02/may-2012-web-se...
  - md224 13y ago
    A Google recruiter actually told me that Google is "basically an advertising company." Then again, he was recruiting for an AdWords-related position, so his viewpoint may have been skewed.
- smutticus 13y ago
  > For better or worse, the big vendors guide the standards process. It costs money to have people on staff who write IETF drafts and haggle them up to RFCs. Hopefully the standard isn't too degraded by the needs of Google in this instance and everyone benefits.
  - steveklabnik 13y ago
    Absolutely. I'm not saying that it doesn't. I share your hope, but I'm not super optimistic in the general case.
- youngtaff 13y ago
  Oh come on don't let paranoia encourage you to throw the baby out with the bath water… The way Mark Nottingham ran the original CFP for HTTP 2 and the eventual adoption of SPDY as a starting point was very fair - it's all there in the IETF archives for anyone to see. From memory there were only two other proposals (from Microsoft and someone else) The reason Google were able to get a new protocol up and running is because they have both heavily used web properties and a browser. They're also willing to carry out experiments in public. As it stands HTTP 2.0 will be good for the little guys too, based on the testing I've done little guys will see an improvement in performance without needing to do all the merging that destroys cache lifetimes. 3rd party-content is the fly in the ointment to the performance improvements so we'll need to be much more careful about the performance of the 3rd party sites we include. N.B. Apart from using their products I have no affiliation with Google
nodata 13y ago
Point him towards the github repo!
nileshtrivedi 13y ago
Genuine question: Is it really that big of an issue? We still have to use tools (telnet/curl) to inspect text-based protocols. We don't examine raw bytes by hand, do we? In other words, isn't every protocol ultimately a binary one and the issue here is only a matter of degree?
- voidlogic 13y ago
  It probably already exists, but you could write a telnet that simply displays ASCII and hex side-by-side. I used something like this when I used to reverse engineer laboratory device control protocols (but it was a hardware implementation: http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agilent-4957A_R.png http://www.atecorp.com/ATECorp/media/ProductImages/R/HP-Agil...) Not to mention wireshark...
  - holalala 13y ago
    tool already capable of doing it is socat. ex: socat -v -x - tcp:google.com:80 add >/dev/null if you want do discard plain text output. also works over ssl: $ socat -v -x - openssl:google.com:443,verify=0
- tptacek 13y ago
  An argument that it's a fake issue: the fact that best-practices compliant HTTP applications already tend to run under HTTPS, and that understanding what's happening at an HTTPS level in operationally-relevant ways (namely: are we performant enough? and are we secure enough?) already requires parsing of that binary protocol.
- nmcfarl 13y ago
  I think it is. We have a large amount of tooling in existence to inspect text based formats. Binary format inspection requires new tooling to be written and deployed. This is a major barrier. I may be a bit old-school, but I learned HTTP via telnet, a tool definitely not written to inspect HTTP, and I still use it when I’m trying to debug things. Not having to install tooling is still something I take advantage of. Obviously binary formats can and do succeed, and with sufficient backing tools will be written and deployed. But if HTTP hadn’t been so easily inspect-able I don’t think it would have been nearly as successful the 1st time around, when the benefits of the protocol where less well known. And I do think some of the "culture of the protocol" will be lost moving to binary°. It just isn’t as hacker-friendly or at least newbie-hacker-friendly and that sends a message. - ° Of course this is already happening with HTTPS, so this is probably not a winnable fight. And the benefits of binary formats are significant, so it might not even be a fight I want to win. Still something is being lost here.
voidlogic 13y ago
>I would have liked to see an ascii based protocol I disagree I think HTTP should have been a simple binary protocol from the start and HTML should have required compilation into a binary format. How much work would have it really been? htmlcmp foo.html providing foo.bhtml. No whitespace, No end tags, one or two byte tags, etc. Strictness in the reference HTML compiler implementation could have saved the web from all the stuff outside the actual standard that browsers (and other tooling) now have to support (so they don't "break" the web). I'm not suggesting anything as crazy as the flash binary format (I wrote a Java flash player once...), but when I started to write things like proxy servers and HTML minifers I was blown away by the extreme inefficiency of HTTP/HTML. This is a step in the "right" direction IMHO.
- samwillis 13y ago
  I believe that the "world wide web" took off for two reasons. It was completely free and it was incredibly easy for ANYONE to make a website. If you needed to "compile" all HTML it would have discouraged a lot of casual experimentation. Not everyone understands what a compiler is. Just as an example I started playing around with HTML when I was about 12 (in 1998), it was easy and I got instant results. A year or so later I tried to learn Perl and quickly gave up because I couldn't get my first script to run. It was another year before I tried to "program" again and became hooked. HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way.
  - voidlogic 13y ago
    >HTML and HTTP were successful because they were incredibly easy to understand. I wish we could keep it that way. The web is big enough today that we can afford to make it more efficient since we have so many professionals that don't require the kind of implicit hand-holding provided by the original implementations. Back then everyone was a newbie and there were no web professionals.
    - samwillis 13y ago
      I think we need to be careful about claiming its more efficient. There seemed to be significant disagreement about how much more efficient SPDY was last year from the various different benchmarks. From memory the consensus seemed to be that its only 5-10% quicker. Does anyone have any more up to day benchmarks? I hate the idea that you would have to be a "web profesional" in order to get started today. We should embrace and keep the culture the web was built on.
josteink 13y ago
> understand the motivation to going to a binary protocol for a SPDY inspired HTTP 2.0 but I would have liked to see an ascii based protocol You're not alone. I've opened an issue on the subject [0]. Feel free to add weight to it. [0] https://github.com/http2/http2-spec/issues/169 https://github.com/http2/http2-spec/issues/169
- klodolph 13y ago
  That's a childish way of asking for what you want: (1) opening an issue in the wrong forum and (2) failing to familiarize yourself with the previous discussion threads. You know this is a controversial topic, please act more maturely in the future. Any time a bug report is linked in Hacker News the community ends up spamming the tracker with our enlightened opinions. Show some restraint.
  - josteink 13y ago
    > (1) opening an issue in the wrong forum and (2) failing to familiarize yourself with the previous discussion threads OK. Fair enough, but I did look for an existing issue on the matter. There were none. > You know this is a controversial topic, please act more maturely in the future. Personally, I find attempting to lock down open internet-protocols by transforming them into some sort of binary obscurity rude and against everything the internet was built on. I don't think everyone is aware about that happening right now. and I see nothing wrong with attempting to bring focus to the issue if that is what needed. Seeing how this draft still outlines a binary-protocol, this clearly still is in need of attention. Just because some Google-heads somewhere decided that by completely ignoring everything the internet has taught us so far, and in the name of pre-mature optimization can shave off 2ms on their page-load doesn't mean the internet should pander to their interests. If anything is controversial it is how this is all being done without any documentation showing us what benefits we get from the costs associated with a binary protocol. That is amazing. Completely and utterly amazing. But OK. Let's say I listen to your guidance: Where would be a good place to raise this issue? Where would I take my "childish" issues to ensure they get the attention they so much deserve?
peterwwillis 13y ago
This idea is bad for a couple reasons. First, ASCII is inefficient. People don't interpret HTTP, computers do. Web servers and browsers. People only look at HTTP when they want to troubleshoot without any tools. With real tools, you can find out what's broken much quicker. And there's plenty of things you can miss without a real HTTP interpreter. Most hackers prefer to think of themselves as wizards that can spy 0's and 1's and tell you what the weather is. It doesn't make for a better protocol, though. Second, we can already break HTTP responses up in multiple parts, using a novel idea called "multipart". It sucks and nobody has used it since HTML/JS found new ways of providing content. http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html Third, it's a hack. If you want to improve the protocol, improve the protocol, don't just hack onto it to make it do what you want. I could make a horse and buggy go 60mph, but would it be a good idea? How about just designing a better buggy that is intended to go 60mph? Fourth, fixed-length records are the wave of the future! It solves crazy problems like header injection and request integrity checking. Moreover, it makes for simpler, more efficient parsing of requests. Fifth, redundancies introduced from the beginning of time need to go away, like terminating every record with "\r\n", or passing the same headers on every single damn request when once should be just fine for a stream of requests. Little inefficiencies like this don't go away if you just hack onto the same old protocol forever. Sixth, the flow control improvements can make different applications more efficient by both not having to hold state of where and when traffic is coming and improving flow across disparate network hops. Seventh, as to a general question "why use binary when we can compress stuff", what is smaller: a string of bits, or a compressed string of digits? Add to this that every header could have a 32-bit identifier (4 bytes) and you've got more efficient compression than gzip. Of course, most people would argue that you don't save enough time or bandwidth or cpu cycles to make a difference, but it would make for easier-to-write parsers, which would make working with the protocol in general more attractive. But then you have your binary-detractor-wizard-hackers and the whole conversation becomes an infinite loop.
- deleted 13y ago
  [deleted]
- romaniv 13y ago
  The same arguments can be applied to HTML, CSS, JSON, RSS and so on. I fail to see the crucial difference between those and HTTP. Or would you say the web as a whole should be binary? Fifth, redundancies introduced from the beginning of time need to go away I wholeheartedly agree with this, but it doesn't automatically warrant binary encoding. Human readability is a huge bonus in any protocol or format. Not because normally people read those protocols, but because people read ASCII and therefore they have good tools to work with ASCII.
H3g3m0n 13y ago
There is no reason why someone couldn't build a tool to send/receive binary responses and print them out as text. We have wireshark anyway. Just need a cli translator or a program that lists all the possible valid inputs for a given connection state and lets you select one (and allows for raw input just in case you want to try and break something). For most cases you will probably be able to get the old HTTP protocol anyway. The only potential issue would be for people who are implementing the HTTP 2.0 protocol itself, just about everyone else in the world will be using a webserver or at least a library. In fact raising the bar to prevent people developing their own HTTP 2.0 implementations would probably be a good thing, it would cut down on the number bug riddled implementations. In any case I don't think it makes sense to slow down the whole internet just for a few developers. Binary could also see the possibility of hardware implementations. Think webserver on a chip.
abionic 13y ago
no matter what all says, it's all because Google researched on SPDY
charonn0 13y ago
I agree. HTTP, like many core internet protocols was designed to work with any client setup, even someone sitting at a telnet terminal sending hand-rolled HTTP requests. FTP is just the same, and SMTP, etc. While very few people these days will actually wind up using telnet to access network resources, it is a very successful design and one which ought not be abandoned without considerable thought.
bitwize 13y ago
HTTP 1.x was fine for the early 1990s. It's 2013 and Windows has won. Unix is dead. Maybe you have a nice Ubuntu box and that's fine. I'm talking philosophically. Modern developers favor the performance and functionality advantages that large applications, deep APIs, and binary communication protocols provide over the transparency advantages that small, highly focused tools, orthogonal APIs, and human-readable communication protocols provide.
- olentangy 13y ago
  Unix is dead? Aren't Mac OS X, iOS, and Android basically unix OSes? I'd say Unix won.
  - bitwize 13y ago
    The essence of Unix is not in the name of Unix, nor in the code of Unix, said Master Foo. And then Chuck Norris roundhouse-kicked him in the face. Point being that if by Unix you mean an OS running a Unix-inspired kernel, then yes, Unix won. But if by Unix you mean the design patterns and philosophical principles that have long inhered to Unix development, then Unix is, if not dead, then on its last legs and soon to be discredited. The "Unix philosophy" has long favored small, easily composable tools each with a specific purpose, orthogonal APIs which were as small as possible, and textual transmission formats which are easy for humans to read and write. There were exceptions (X, Emacs), but these exceptions tended to support and play well with the Unix philosophy even if they didn't 100% espouse it. By contrast we may propose a Windows philosophy which favors large, do-everything applications over small tools (because that's how people are accustomed to using PCs starting from the DOS days when only one program could be up at a time), heavyweight frameworks and oftentimes entire inner platforms (because in a world where time-to-market is paramount, developers shouldn't have to think very hard to begin cranking out apps for the new technology of the week), and binary file formats (because the damn thing has to run in 640k, a text parser won't fit). Look at the platforms you mentioned. Mac OS X, iOS, and Android are all app-centric, not tool-centric. You can treat Mac OS X as a Unix box if you want, but it's hard to do so with the other two. Furthermore, when you write an app for these platforms you are not targeting the Unix kernel or libraries but an inner platform built on top of them. Which brings us to binary file formats -- like HTTP 2.0. The Windows philosophy has won.

antirez 13y ago

Congrats to Google for ruining the internet standards in an official way, without strong proofs of big significant improvements over the simpler past protocol.

tptacek 13y ago
Don't confuse the cart and the horse. The IETF standardization process has never been less relevant than it is today. The reality of deployment of a "next-generation HTTP" involves two things, neither of which the IETF has any say in: (a) whether anyone can improve HTTP as it runs between a mainstream browser (or some as-yet unforeseen browser replacement) and a content serving backend in a way meaningful enough to drive adoption, and (b) buy-in from the major browser owners. That's the way it's supposed to work; the horse is meant to drag the cart. The RFC database is littered with cart-led insurgencies that went nowhere. If binary HTTP is one of those, it'll join them as a historical curiosity.
- antirez 13y ago
  My fear is that now that Google controls a significant part of HTTP traffic, plus the client side of the story (Chrome + Android), it is in a condition to force things in one way or the other...
  - tptacek 13y ago
    I suppose that's a valid concern, but note that Google's control over the protocol was already pretty strong by dint of running Google.
  - reidrac 13y ago
    Do you think Google is now in a better position to force things in one way or another than Microsoft was in the 90s?
    - hugi 13y ago
      It's in a similar position. And see how that ended up with Microsoft — we're still suffering the consequences.

RyanZAG 13y ago

Only implementations of the final, published RFC can identify themselves as "HTTP/2.0". Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". Here we go again - as with -webkit in css, expect 'HTTP/2.0 DRAFT' or similar to be the new http 2.0.

dragonwriter 13y ago
I think in the real world its not "HTTP/2.0 DRAFT" but "SPDY".

deleted 13y ago

[deleted]

sktrdie 13y ago

Can anybody summarize the main differences between this and the older versions of HTTP?

jeffasinger 13y ago
Binary protocol, every connection is TLS, and multiple requests can be put over the same TCP connection and answered in any order. I didn't read this super carefully, but this is basically Google's SPDY protocol.
- ctz 13y ago
  I don't think every connection is TLS. This is obviously a critical mistake, given HTTPS stripping is possibly the biggest weakness in current web transport security.
  - deleted 13y ago
    [deleted]
  - twoodfin 13y ago
    There have been several debates about making TLS mandatory in HTTP 2.0 on the ietf-http-wg mailing list. Here's a link to a NetFlix engineer's comment in the most recent one I could find: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0494.html http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/... In short: While TLS is a really good idea for just about every user-facing site on the web, there are many applications where some combination of the administrative burden, need for intermediaries and performance cost make TLS sufficiently undesirable to preclude adoption of a spec that required it.
joosters 13y ago
Binary protocol. Header compression. Multiple concurrent 'streams' (or requests) over the same TCP connection.
- sktrdie 13y ago

joosters 13y ago

At first glance, the spec appears to be re-implementing a TCP stack inside a TCP connection...

wmf 13y ago
Yes, the reason is that starting a new stream multiplexed inside an already-open TCP connection is faster than starting a new TCP connection. Attempts to improve TCP itself are slowed down by slow uptake of new Windows versions.
- joosters 13y ago
  That's not true. HTTP/2.0 (or at least the successor to HTTP/1.1) has been discussed for over a decade, there have been many OS releases since then! Inventing a whole new protocol to overcome a TCP deficiency is IMO a terrible motive...
  - pritambaral 13y ago
    These guys have something to say about that: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm... A new protocol that runs on UDP precisely to side-step slow TCP changes.
    - nly 13y ago
      That's great, but it means it'll always be a userland library rather than a OS supported networking protocol... which means the API will never be a defacto standard akin to the BSD sockets API. The reference implementation is also in obtuse looking C++... which will hinder bindings to other languages. In short, don't expect to see this outside of Android or Chrome. On the plus side, this is exactly what UDP was for in the first place.
- bcoates 13y ago
  What efforts are these? That sounds much more interesting than mucking around with HTTP micro-optimizations.

joeyh 13y ago

"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" Ah, so every HTTP 2.0 connection has PRISM in it.

bbanyc 13y ago
It started out as "FOO ... BAR" but that made the header an odd number of bytes long. In the previous draft it was "FOO ... BA". It was briefly "STA ... RT" which made too much sense to use.
Trufa 13y ago
I'm worried about the amount of reddit like comments in HN.

xcnm3 13y ago

Given the close relationship between Google and the NSA, I suggest they are removed from the IETF until further notice. I would trust Microsoft more than the snake oil Google produces. No surprise they've opted for a binary protocol rather than ASCII, anything to reduce transparency

tootie 13y ago
Microsoft has been just as cooperative with the NSA as Google. They have access to Bing and Skype.
cromwellian 13y ago
What close relationship between Google and the NSA are you referring to?
- xcnm3 13y ago
  Google providing direct access to their servers and infrastructure. Every Google service was open to the NSA; GMail, Google Drive, Google Talk, you name it.
  - cromwellian 13y ago
    And the evidence for this is?
    - xcnm3 13y ago
      Please read the leaked information from Edward Snowden. I don't wish to paraprase the last few weeks of news for someone.
      - cromwellian 13y ago
        It's a rhetorical question. None of the leaks provide any evidence that Google actively cooperates with the NSA in any way. No evidence of equipment at Google data centers, no evidence of any kind of remote access for the NSA, other than the already existing legal channels. The claim that Google had foreknowledge of PRISM, or worked with the NSA to build some kind of firehose for them is unsupportable given what we know, and is pure speculation on your part. Thus, the claim of close cooperation with the NSA is frankly, ad hominem.

antitrust 13y ago

This makes it easier for web application designers, but is less optimal for those publishing static pages, which are actually the mainstay of the web. Further, it's less user-explorable, which further distances the web from access by the everyday tinkerer as opposed to the professional with lots of time to explore.

ge0rg 13y ago

I really disliked the following part: A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the connection header. [..] Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections. (Section 3.4) That means, whenever you open a new TCP connection to a http2 server, you must start with HTTP/1.1 and perform the Upgrade negotiation anew. Making the spec require HTTP2 support on all servers of a cluster if at least one server supports it would have been much better, performance-wise. The only reason I see why they kept it is transparent proxies (if your browser is using an explicit proxy, it should be able to figure out if the proxy supports HTTP2).

peterwwillis 13y ago
Browsers already send HTTP/1.1 by default, which would be rejected by HTTP/1.0 servers. HTTP/2.0 would be rejected by HTTP/1.1 servers and the browser could retry, or it can try for the Upgrade. Either way, with time, we can change the browser to behave differently based on the number of servers supporting that protocol, the same as with HTTP/1.1.
- ge0rg 13y ago
  Yes, but storing "supports HTTP2" for a given server for a given time after connecting to that server and negotiating the upgrade would also do the job. One of the problems with HTTP 1.x is that it is stateless - every time you want something from a server, you treat it as if it is the first time you talk to it. I understand this is by design, but as a consequence we are transmitting all the same headers to the server all the time... which can be mitigated with HTTP2, except that we still need to do that (send all headers) and the HTTP2 upgrade, every time we open a new TCP socket to that server.

Sephr 13y ago

You still can't self-sign certificates and rely on certificate pinning for transport security without domain verification. With all of the security concerns people have with governments logging all unencrypted internet traffic, I was hoping HTTP 2.0 would require or at least optionally allow self-signed cert TLS for every http: connection (with no UI indication to the user that they are secure) and require CA-signed cert TLS for https: We're also still stuck with DEFLATE, which is vastly inferior to modern compression formats like LZMA.

samwillis 13y ago
Encryption is only half the problem, authentication is the other. Self signed certificates don't authenticate the web server and allowing them would open the web up to MITM attacks. What we need is some form or decentralised certificate authority, i have no idea how that could work though. HTTP allready supports LZMA, its just the browser and web servers that dont. If a browser sent the header: Accept-Encoding: compress, gzip, lzma instead of: Accept-Encoding: compress, gzip and the server supported it, it would "just work". Unfortunately none of the major browsers or server have implemented it.
- Sephr 13y ago
  Unencrypted HTTP is already open to MITM attacks. What I proposed was using self-signed certificates in conjunction with certificate pinning, which means that as long as your first connection to a website isn't MITMed, later connections cannot be MITMed or snooped on. As for the compression, I was referring to LZMA for header compression. I am well aware of implementation efforts of LZMA in Firefox and Chrome.
- skrause 13y ago
  What we need is some form or decentralised certificate authority, i have no idea how that could work though. DNSSEC could be used to distribute certificates: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
  - 13y ago

ancarda 13y ago

Hmm... I have a few scripts that do something like: header($_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request'); Since I'm using SERVER_PROTOCOL, if I upgraded Nginx and it started to send HTTP/2.0 traffic to the server, would I need to rewrite this line? How would I send a specific status code using the new binary protocol?

iso-8859-1 13y ago
Just use header("Status: 400 Bad Request");

lnanek2 13y ago

Well this is clever: " HTTP/2.0 enables a server to pre-emptively send (or "push") multiple associated resources to a client in response to a single request. This feature becomes particularly helpful when the server knows the client will need to have those resources available in order to fully process the originally requested resource. " If someone asks for your HTML, might as well send them the CSS, JS, and images it is going to use. Would cut down on requests. Only thing more efficient than compression, is not having to ask in the first place.

jimktrains2 13y ago
Couldn't we already do this with multipart requests that no one uses?
duaneb 13y ago
It also complicates caching: do you cache the response by request, or cache the resources individually by update time (or whatever)?

cientifico 13y ago

Hope http 2.0 is the new ipv6 !

popee 13y ago

HTTP/2.0 should be SIP because of similarities and also integrated session management. Not some application layer binary protocol to spy on people even faster. Yeah baby :-)

ddalex 13y ago

Is this a proposal to reimplement (badly) TCP inside of HTTP ? So we'll have a TCP stack running on top of a TCP stack ? Those who don't learn history are doomed to repeat it. I predict that this will lead to unexpected performance problems due to collisions in Tx window size between TCP windows and HTTP 2.0 frames.

Aloisius 13y ago

Oh wonderful, it appears to use SPDY-like header compression. Why don't we just create a new compression algorithm and predefine common HTML tags and words to improve compression of the response body too! But we shouldn't base it on any known compression scheme and only use it for the case where the content length is less than 220,498 bytes but more than 8,494 bytes to optimize the behavior of today's more common MTU settings for PPPoE in Scandinavian countries minus of course the most common size of compressed headers today. It will be particularly optimized for the kind of responses Google sends back to minimize their own server load and common adwords will of course be included in the predefined list of compressed tokens. /sarcasm What happened to simple protocols? Seriously, per-hop flow control (which works best with which of the dozen version of TCPv4 or TCPv6 flow control?)? TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly ridiculous specialized compression for headers which ignores the role of HTTP proxies? QoS? Why not just implement the whole protocol over a raw IP connection and stop pretending like we're operating in layer 4+? I get that multiplexing is difficult without flow control, but good lord does this thing look overdesigned for what few benefits it offers over HTTP/1.1.

tptacek 13y ago
Recapitulating a comment from downthread, but, look at DNS for an example of how the IETF botches compression in its "simple" protocols. Not that compression isn't fraught (look at TLS), but I see its use as a sign of maturity.
angersock 13y ago
Well, we had a nice thing for a while, and now it's time to fuck that all up. The wheel turns. Look on the bright side--if everyone decides the public Internet is too insecure, maybe we can convince them to keep using the old standards on darknets?
nly 13y ago
I can't help thinking some of the pain could be resolved if we had a reliable datagram protocol between UDP and TCP. Delimiting a TCP stream to create a messaging protocol is already suboptimal and error prone, and it's the root cause of the head-of-line blocking problem experienced by HTTP ('fixed' in SPDY).

stormbrew 13y ago

I still feel like this is just being rammed through far far too fast. SPDY might well be the right way to go, but it's only been deployed for a small number of very large sites for a couple of years at this point. It was a foregone conclusion when the schedule was announced for http2.0 that it would be spdy, because only spdy has demonstrable value in production. There was no time for anyone to come up with or evaluate an alternative. But on the other hand, there hasn't been near enough time to demonstrate that spdy is good for the whole internet, which is what blessing it with the http protocol name implies. And I just don't see why it should be rammed through. SPDY has a connection upgrade path, that afaik is largely unchanged for http2.0 anyways.

drivebuy 13y ago
> because only spdy has demonstrable value in production. What demonstrable value? Google has never compared it to pipelining and when Microsoft did so they found it about the same and sometimes slower. There is next to zero value in SPDY over pipelining across several connections. It's just complicated for no good reason.
- stormbrew 13y ago
  I think you're seeing a defence of spdy in my post that isn't really there. By value I mean simply that it is at least functional. Any alternative proposal, given the short proposal cycle, would not even have that.

yalogin 13y ago

Totally superficial but why do I have to type http every time? Why can't it be h and hs (for https). Quicker to type.

neuroscr 13y ago

Most of the complaints are around the ascii vs binary. Can we just make it accept both and move on?

jlarocco 13y ago

Going to binary seems kind of silly at this point. HTML is text. Javascript is text. XML is text. JSON is text. SVG is text. CSS is text. Is it really worth the complication to save a few bytes on HTTP headers when you're just going to shovel out inefficient text data in most cases anyway? I don't understand why they're trying to shove this down everybody's throat as a new version of HTTP. There are a ton of ports besides 80. The better thing to do, IMO, would be to make a new protocol on some other port and add it to their browsers.

josteink 13y ago
According to the shills employed by or rooting for Google, here on HN and elsewhere on the internet, it's not silly: It is paramount. See, it allows the request for www.google.com, including all of Google's tracking cookies, to fit inside one TCP-frame, causing a 5ms improvement in load time, and Google has evidence that this means they make more money. Never mind the open, exploratory nature of the internet and how text-based protocols was what made the internet into what it is today. We're going to throw away all that which the internet has taught us about that because Google says we should. This thing is fucked up beyond belief. Edit: found a link to the IETF discussion about this: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0254.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/... It admits in plain sight that the only thing they care about with HTTP 2.0 is solving Google's massive-scale issues at the cost of everyone else: > I finally admitted it was a dead end. At the moment the challenges consist in feeding requests as fast as possible over high latency connections and processing them as fast as possible on load balancers A good, open, self-documenting protocol didn't suit Google, so let's throw it away. It's a "dead end", after all. Jesus christ these people need a bitch-slapping. More emails on the subject can be found here: http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=The+use+of+binary+data+in+any+part+of+HTTP+2.0+is+not+good&index-grp=Public_FULL&index-type=t&type-index=ietf-http-wg http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-...