Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

111–120 of 162 posts

Re: The 7-bit Internet

#111
post #37
post #4

I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

For Google, a .0001% reduction in user overhead may translate to millions of dollars of resource savings. Google is willing to do crazy things like run their own modified Linux kernel that most companies wouldn't bother with. What is the end-user benefit in performance using HTTP 2.0? The only analysis of SPDY I saw indicated low single digit percentage benefit vs HTTPS. Whoop-dee-do. http://www.guypo.com/technical/n…

It's funny, isn't it? We gave out more domains to speed things up, but now it slows us down (referring to your link).

I would highlight that HTTP 2 > SPDY as far as standards go, and the "beta" protocol of SPDY is already at 55% market share including IE 11: http://caniuse.com/spdy

For those who are interested in speed optimization for 2013 and beyond, plus why SPDY's faster-than-SSL descendants are crucial to the web's success, have a look at http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier... -- I believe there's a video out there too somewhere. Edit: Video link is on first page of the slides.

What's interesting too is that this talk focuses as much on what's achievable without SPDY as what might be with, down the road. We really need faster SSL negotiation for that first time connection cost.

Re: The 7-bit Internet

#112
post #19
post #4

I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

Google can afford to dedicate a bunch of engineers just to deal with all these complexities and inconveniences of binary protocols, but others can't. And this is far more important than some hypothetical tiny improvements in performance.

Yeah. It's too bad there aren't free web servers out there that everyone can use that implement these protocols. Oh wait, there are.

By making things more efficient, HTTP 2.0 is really going to make startups spend more money. Oh wait, no, the opposite thing.

Re: The 7-bit Internet

#113
post #42
post #35

Earlier quoted context omitted.

> * but human-readability is very useful.* For who, how often and when exactly? As far as I have understood, we are doing something wrong if we have to deal with debugging protocols which implement an abstraction, rather than just let the abstraction do it's job. This is like saying that "Well for programmers x86 assembly instruction mnemonics are useful compared to machine code bytes!", to which one could say that f…

I'm starting to feel like I start all my HN posts with "Hi, I'm a sysadmin." Hi, I'm a sysadmin. Sometimes we have to debug things that are on the other side of the world. When we do that, we need to have a mental model of what we're doing. You're familiar with that as a software developer: you have a mental model of the capabilities of the language that you are using, and you are fitting that in with the mental mode…

Don't want to debug it? Don't turn it on. The only reason you would is if it had more benefits than drawbacks. Standards bodies make standards, they don't force people to pick one.

Re: The 7-bit Internet

#114

Earlier quoted context omitted.

If you're not working at the TLS layer, then why make the request over HTTP 2.0? You can just ask for 1.1 instead. If it works for Google.com, it should work for you too, right?

I don't understand, HTTP is not TLS. So you're saying that we should continue to maintain 2 protocols? As some others have said, I feel that making a "webapps" protocol, a streamlined websocks or something, maybe this HTTP2.0, and keep HTTP for stateless resource representations, like it was designed to do.

Stateless? What about that hack known as cookies? Aren't they useful? How about HTML5?

And what happened to the calls for SSL everywhere? Defending your cookies from the NSA and MITM? Of course we need two protocols, perhaps more than two. I'd love to see something more interesting happen with multicast given talk of IPTV in 4K.

I'm shocked that your only objection ends up being the protocol name. Worse, it's the version number. But hey, it is semantic versioning... Don't use it if you don't want to. It's not like anyone else will notice if your site is already fast because it's one request with no state.

Re: The 7-bit Internet

#115

Earlier quoted context omitted.

If you're not working at the TLS layer, then why make the request over HTTP 2.0? You can just ask for 1.1 instead. If it works for Google.com, it should work for you too, right?

I don't understand, HTTP is not TLS. So you're saying that we should continue to maintain 2 protocols? As some others have said, I feel that making a "webapps" protocol, a streamlined websocks or something, maybe this HTTP2.0, and keep HTTP for stateless resource representations, like it was designed to do.

"maintain 2 protocols" - actually, yes, I do expect browser vendors to maintain compatibility with HTTP 1.0, 1.1, 1.2 and 2.0+. By the way, you might be interested in 1.2: http://www.infoq.com/news/2011/04/http-1.2-released

The way I see it, we can have our cake, both flavours. Why make someone remember different URLs? "http://" is too entrenched for when people type it in, and I'd rather not worry about browsers trying to sniff out faster protocols as they currently do with SPDY. Better to make it a version number, even if you personally never use it.

Re: The 7-bit Internet

#116
post #4

I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.

I see the proposals of binary protocols, push content, etc. as symptoms of a deeper issue. Different than the spirit of HTTP, those protocols have little to do with publishing content anymore. They are just more kludges, in the history of kludges, to patch browsers into application platforms. That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can…

> That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can track to their hearts content, display unsolicited advertising

Please. All you need for advertising is plain text, all you need for tracking is cookies.

Re: The 7-bit Internet

#117
Marco claims that HTTP 2.0 is overly complex, but never gives any reasons why. He claims that text protocols are better than binary, but never really gives any reason for that either. Nostalgia for the days of telnet and gopher is not a reason.

Then he goes off to talk about SOAP, which he hates, because "the only way [he] know[s] to hand-debug a SOAP transaction is with a hammer and a straitjacket." But SOAP is text based, which directly contradicts his argument from earlier.

The other allegation here is that the new protocol "satisf[ies] what are essentially the needs of a small group of very influential players." Again, Marco just states this with no rationale at all. In fact, the opposite is true. By being more efficient, HTTP 2.0 will serve the needs of everyone. Should startups have to pay for 10 servers when they could have paid for 5 with HTTP 2.0? Apparently Marco thinks they should. It's easier for Google to pay for a few more servers than it is for Joe startup. This should be obvious to everyone, but apparently it's not.

The whole binary versus text thing is a complete red herring. If you have ever used wireshark, you know that it makes binary fields easy to read. Binary protocols are easier to develop and standardize. Pretty much every good developer realizes this, and the responses here reflect that. The idea that making something LOOK like (but not actually be) "human text" makes anything better is an idea we should have buried along with COBOL and other mistakes from the past. But I guess not.

Re: The 7-bit Internet

#118

Marco claims that HTTP 2.0 is overly complex, but never gives any reasons why. He claims that text protocols are better than binary, but never really gives any reason for that either. Nostalgia for the days of telnet and gopher is not a reason. Then he goes off to talk about SOAP, which he hates, because "the only way [he] know[s] to hand-debug a SOAP transaction is with a hammer and a straitjacket." But SOAP is text…

SOAP is to REST as XML is to JSON. They're all technically 7-bit and notionally human-readable, but SOAP/XML are (well, can be) so verbose as to be near-impossible to parse by hand. Comparing the "Hello World"-style simple examples on Wikipedia is instructive:

REST

http://example.com/resources/item17

SOAP

" rel="nofollow">http://www.w3.org/2003/05/soap-envelope"> " rel="nofollow">http://www.example.org/stock"> IBM

Re: The 7-bit Internet

#119
post #53

I think TLS/SSL is the elephant in the room here. A large part of the web is effectively already using binary protocol (HTTPS), and frankly I'd wish the part was even bigger. Think of HTTP 2.0 as a successor for HTTPS instead of HTTP if it makes you feel better.

Wrong. An encrypted text session is different from a purely for binary session (encrypted or not). The former can be mangled from text by a generic encryption proxy, the latter needs a protocol-specific analyser.

I don't get it. Why does it matter if your tool just decrypts SSL or you use a tool that decrypts SSL and additionally unpacks the binary representation of HTTP 2.0?

The output is exactly the same - plain old HTTP.

Re: The 7-bit Internet

#120

Marco claims that HTTP 2.0 is overly complex, but never gives any reasons why. He claims that text protocols are better than binary, but never really gives any reason for that either. Nostalgia for the days of telnet and gopher is not a reason. Then he goes off to talk about SOAP, which he hates, because "the only way [he] know[s] to hand-debug a SOAP transaction is with a hammer and a straitjacket." But SOAP is text…

SOAP is to REST as XML is to JSON. They're all technically 7-bit and notionally human-readable, but SOAP/XML are (well, can be) so verbose as to be near-impossible to parse by hand. Comparing the "Hello World"-style simple examples on Wikipedia is instructive: REST http://example.com/resources/item17 SOAP " rel="nofollow">http://www.w3.org/2003/05/soap-envelope"> " rel="nofollow">http://www.example.org/stock"> IBM

Amen. "Human readable" is not the same thing as human readable.
Post reply on HN