Hacker News Reader

Comment by drdaeman | Hacker News Reader

Nice, but a bit worrysome. Is such binary protocol a Good Thing?

Ancient people — even though they hadn't much CPU, memory and network resources — in all their wisdom made high-level protocols text-oriented. Sure, they didn't consider everything (so we're still haunted with evil spirits of, for example, UTF-7 and quoted-printable), but overall design was simple yet perfectly functional. And anyone could use just a telnet client to talk to HTTP (FTP, SMTP, etc) server. With SPDY you can't do such thing anymore, you need specialized software.

I'm all for something like "Upgrade: SPDY"/"HTTP/1.1 101 Switching Protocols" (then binary framed message-oriented protocol goes into effect), but I somehow worried with binary-from-the-beginnig "HTTP 2.0". Maybe I'm just too conservative?

(Side question: If we want multiplexing streams so badly, why noone cares about SCTP? Is it flawed or inappropriate?)

View on HN

The reason we didn't like the Upgrade header is because it requires yet-another-round-trip in the protocol. Round trips are expensive, and getting worse both for desktops and mobile. (average RTT is ~114ms to Google, which has pretty good global presence)

As for SCTP, I think applications generally drive progress better than OSes do. Certainly the OSes have had enough time to sort out SCTP, but they haven't done it, and the end-game is nowhere in sight. Until there is an app that showcases it, will it ever happen?

My recommendation is to first prove new protocols at the application layer (perhaps run SCTP over UDP just to grease the skids). When people are addicted to how much better the experience is (multihoming + concurrent streams), then the OSes will pull it into the kernel to make it more scalable.

What do you think?

The simplicity of text protocols is illusory and mostly leads to bad implementations that look like they work but don't really. Any protocol that supports multiplexing is fundamentally complex; for example, BEEP is a "text" protocol but I doubt you could speak it with telnet.

SPDY is always an upgrade; AFAIK there's no way to start out talking SPDY (since there's no spdy: scheme). Every SPDY server should still support old-fashioned HTTP.

SCTP gets broken by NATs, so outside of a few telco networks it's dead.

Nobody questions that a secure protocol is not readable text :-)

I fundamentally believe the protocol has to be server authenticated and encrypted always. We've seen breach after breach of user privacy and the desire for governments to crack down on its citizens has no bound. We simply have to encrypt. Once we do that, text is off the table, and it doesn't really matter if it is binary or not.

Of course, we need much better tools for managing the encryption, I'm not a believer that the status quo is adequate in any way.

TLS is just a layer, which replaces `telnet` with `openssl s_client`.

Alright, but that is just theory. The reason you'd want a text protocol is so that humans could read it. Once you secure the protocol, you can't read it without a machine to help you.

Well, by the same reasoning I "can't" easily talk HTTP because I can't talk TCP, IP and 802.3 - they're all binary.

This is exactly why I wrote "high-level protocols". With just a telnet client I can talk HTTP, FTP, SMTP, IMAP, POP3, IRC and so on. And the machine just needs to handle lowel-level details.

Yeah it's only simple in the sense that you can generate a packet with telnet. It's not so simple when you're trying to write a server that has to parse the stuff in a correct and secure manner.

Maybe, but SPDY does nothing in this area. It's just message-oriented multiplexed binary-framed medium for HTTP.

Disagree.. Having written both HTTP clients and servers, the SPDY spec is a breath of fresh air. Every packet has a predefined header length, and a clearly defined length for the trailing data - removes a heck of a lot of edge cases when implementing a parser.

Now if only TCP was message oriented... For that, I guess we have ZMQ.

Is there any need today to talk manually to a web server using telnet?

I don't know. Probably not, but it's sometimes convenient to do so.

Well, I've did so when I had to debug some redirect caching problem with "walled garden" setup. This could also be done with a more specialized software, though, I just happened to use telnet as it was readily available.

I also sometimes check server's availability (and overall response correctnes) by telnetting to it. Although, I was just too lazy to set up a tunnel to the LAN they're residing at.

I very frequently use netcat (or openssl s_client for HTTPS servers) to connect directly to a server I am debugging.

It could be argued that there is no "need" for this, but I find myself doing it quite frequently all the same. That may have something to do with the fact that I am developing a relatively low-level reverse HTTP proxy tool (PageKite), but I also did it quite a bit when working on more traditional webapps.

Once you speak the protocol it's nice to be able to just connect and chat with the server directly. :-) Humans are really bad at speaking binary.

I most commonly do it to read the HTTP headers using HEAD.

    curl -I

is an easy way to do that as well.

It requires fewer keystrokes :P

Whilst you can use more dedicated tools for debugging http connections than telnet, there is still an argument for protocols simple enough that you can use telnet.

Take Arduino for example, writing a naive but working http client is childs play; writing a SPDY client in Arduino is well beyond many people's capabilities. Yes libraries will appear eventually, but we've not even got a decent open http library yet.

Reply on news.ycombinator.com