8 ms·
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
by RyanZAG 13y ago
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
- bitwize 13y agoThe old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
- wmf 13y agoSince the semantics of 1.1 and 2.0 are the same (besides push) you can choose which encoding you prefer based on your requirements and constraints. In fact, maybe we should rename HTTP/1.1 to "HTTP/2.0 Textual Encoding" or something so that people can feel like they're not missing out on anything. It worked for USB 2.0.
- josteink 13y agoOr we can call SPDY^WHTTP 2.0 "binary barf kitchensink internet multiplex protocol" instead. Let's not taint good, old HTTP in the process please.
- salgernon 13y agoI've never understood this sentiment. Its not like we can know what is passing through the boxes by watching the blinkenlights - this isn't paper tape anymore. You have to use tcpdump to break up the binary bits - and since its likely encrypted, set up the appropriate certificates if you want to decipher arbitrary traffic anyway. If its your own app, you know what requests are going where and can hex dump them any way you choose. The whole "its binary so its bad" thing is a complete non-issue. I've heard people complaining "netcat doesn't work anymore" but there's no reason why netcat2 can't be used to talk to arbitrary HTTP/2.0 endpoints. Sorry, I lost some mates in the SOAP wars of the late 90s and I'm still bitter.
- ubernostrum 13y agoPersonally, my issue with HTTP 2 is that it seems to be designed from the assumption that Google-scale is the common or even only use case, and that optimizing Google's bandwidth use is the sole purpose of HTTP.
- salgernon 13y agoTo me, the real reason is that we want to get to the point where all traffic is secure, and since the cost of establishing that secure connection is high we should do more with the secure connections we've got before letting it drop!
- polarix 13y agoPulling up the drawbridge.
- thirsteh 13y agoI'm sorry, but are you really implying that HTTP doesn't scale?
- alanh 13y agoAre you really implying it doesn’t? So many Web “best practices” are working around the limitations of HTTP and the web 1.0 legacy we still carry around. See: 1. Concatenating resources (1 CSS file is worlds better than 50. Need it be?) 2. Inlining resources (see above) 3. Scaling, yes, is very hard! Look at all the techniques for deploying updates to web apps without breaking users' experiences. I’m not saying HTTP2.0 will or won't solve all these problems, but clearly there is much room for improvement over HTTP 1
- thirsteh 13y agoAm I implying that it does? Yes. 1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well. 2. Sure. 3. This has nothing to do with the protocol. I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.
- bitwize 13y agoSPDY wouldn't be a thing if HTTP were sufficient at the massive scales we're talking here.
- gaius 13y agoNonsense. This is the same mentality that prefers EJBs and other complexity for its own sake.
- troels 13y agoAt scale .. Wait - You're trolling, right? Nice try - Almost fell for it.
- ynik 13y agoLet's not pretend that HTTP 1.1 was simple. Text formats break down whenever they need to contain arbitrary (possible non-text) data. You get one of: * complex escaping rules (and assorted inefficiencies) * non-text portions embedded within the text protocol (ever tried to parse HTTP with a Java InputStreamReader? you can't properly switch back to binary mode at the end of the headers...) * variable end-of-content markers that cannot occur in the content Of course, HTTP 1.x uses ALL of the above (see possible values for Transfer-Encoding). It's a horribly complicated mess that is only surpassed by MIME email. Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler!
- pwg 13y ago> Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler! It is possible to have the same simplicity with a textual protocol, it is just that most text protocol designers don't bother with explicit prefixed lengths: For example, see: http://cr.yp.to/proto/netstrings.txt http://cr.yp.to/proto/netstrings.txt
- wmf 13y agoWhen people say "text protocol" I think they really mean "something I can type into telnet"; stuff like netstrings and BEEP don't really count.
- meowface 13y agoAgreed. This spec reads more like a brand new and complex transport protocol than an application one. Is it HTTP 2.0's plan to completely replace "middleware" like SPDY with a full featured protocol?
- blueskin_ 13y agoYes, and about time too.
- rrmm 13y agoThe complexity is not horrible as far as communications protocols go. Anyone know what working implementations exist currently? Ideally, it'd be nice to see actual real world data showing the benefits over http 1.1.
- stephen_g 13y agoThere's a C++ implementation here, but I'm not sure how complete it is: https://github.com/http2d/core https://github.com/http2d/core I think nginx and Chrome support SPDY which HTTP 2.0 was based on, so that performance should be able to be tested and be fairly representative of what we can expect.
- jimktrains2 13y agoBut that's the thing...it's _not_ a communication's protocol. It's a transfer protocol...
- ll_cool_james 13y agoTo-may-to, to-mah-to..
- jimktrains2 13y agoNo, because a communication protocol has to handle all the types of problems HTTP and TCP solve. A transfer protocol is concerned with moving data and meta data, not the problems TCP solves.