Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

Post reply on HN
Print view View original

41–50 of 162 posts

Re: The 7-bit Internet

#41

Post by joshaidan »

I work in telecom, and this makes me think of two protocols I work a lot with, SS7 and SIP.

SIP is like HTTP, in fact I believe it was modelled after HTTP and has a lot in common with it. You can troubleshoot SIP issues very easily using a packet inspector like ngrep (using Telnet might be a bit difficult as there are some timers that expire if you don't respond fast enough, but that's besides the point).

Then there's a protocol like SS7 which is binary based. It's all structure binary bit fields. Even though it's binary based, and not very human readable, we have tools that decode the bits into a human readable format, which in turn makes it just as easy as SIP to troubleshoot.

The question I ask myself is, which one would be easier to implement, text based or binary format? I guess I'd lean towards text based--in fact I have implemented a SIP client myself with success. But have yet to implement any kind of SS7 or binary based protocols. Perhaps experience has something to do with it, would having experience implementing binary protocols make it any bit easier? And to be fair, SIP is also much well more documented then SS7. As well it's easier to test SIP.

I'm just starting to work with binary protocols, so it will be interesting how much progress I make. I realize there are also some libraries that help with working with binary/bit field data.

Re: The 7-bit Internet

#42

Post by dsr_ »

zxcdw wrote: post #35
jbert wrote: post #22

Earlier quoted context omitted.

I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence. You can talk about efficiency until you're blue in the face, but human-readability is very useful. I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant prog…

> * 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 model of the problem you are solving and the context of existing program code.

To sysadmins, protocols are like programming languages. That's why we like text-based protocols: we can fit them in our heads and type them out, slowly, like ancient creaky teletypes that make lots of mistakes and pause in between commands. Meanwhile, we're running down checklists: can we connect? OK, there's no IP-based packet filtering. What does the banner say? Can it support STARTTLS? OK, disconnect and try again with telnet-tls. Hey, it doesn't negotiate...

Totally unnecessary waste? Sure, assuming someone has already written a tool which does all the testing for you, and you know that tool exists, and you have access to it right now over your tiny smartphone's 3G connection at 0400 while you thought you were on vacation.

Re: The 7-bit Internet

#43

Post by comex »

I don't think a simple binary protocol for HTTP would be bad at all. HTTP servers are still going to support text-based connections forever, so it only matters if you're snooping on existing traffic; but the ability to use Wireshark or tcpdump to grab the text out of packets directly is already disappearing because of encryption (SSL), which is such a good thing in general that it far outweighs that drawback. Therefore more specialized tools are required, and those may as well parse such a protocol - it wouldn't be that hard. The compression is a significant benefit, and can't be done well below the level of HTTP.

What I don't understand is why we need both SPDY and QUIC.

SPDY provides fast multiplexing, compression, and guaranteed SSL. QUIC provides fast multiplexing and guaranteed SSL at the transport(-ish) layer. QUIC does at least one thing that can't be done at the application layer - faster opens - and seems nice to have as a generic base for multiple protocols, so I call it a good thing (and I'd like to see it in the kernel). But the plan seems to be to run SPDY over QUIC - I can't actually find enough information on the Internet (and am too lazy to look through the source) to find out whether packets are going to be double encrypted for the time being, but even if/when that is avoided, the multiplexing and optional encryption seem to be wasteful complexity. I would prefer if HTTP/2.0 were a simple and easy-to-parse protocol providing compression only, expected to be used over QUIC.

Re: The 7-bit Internet

#44

Post by enqk »

skrebbel wrote: post #11
joosters wrote: post #5

I agree with most of the article, but would strongly argue against any use of the 'robustness principle'. There have been huge security vulnerabilities because systems disagree with each other about what is a valid request and response.

And billions of money wasted because browser vendors, at some point long ago, decided to accept invalid HTML.

and lots of experiments, new websites and happy users appeared because HTML has been accepted leniently

Re: The 7-bit Internet

#45

Post by makmanalp »

I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do:

  cake:~ mali$ telnet google.com 80
  Trying 74.125.235.8...
  Connected to google.com.
  Escape character is '^]'.
  GET / HTTP/1.1
  .......
  HTTP/1.1 200 OK
  Date: Wed, 10 Jul 2013 22:25:02 GMT
  Expires: -1
  Cache-Control: private, max-age=0
  Content-Type: text/html; charset=ISO-8859-1
At which point they go "oh cool" and go do something else. For the rest of us who use curl, wget, requests, Chrome / Firefox developer tools every day (who are we kidding, it's everyone, you liars! :P), the binary transformation would be transparent.

Hell, if you're going for pure cool-factor, how is pulling out your hex editor less cool? But in reality, you'd never do this.

For a non-standardized and obscure protocol where tooling would likely be lacking, I can see why human readability is a good idea. But we're talking about the very protocol that makes up the fabric of the internet. Seriously, why?

Give me one good reason.

Re: The 7-bit Internet

#46

Post by itcmcgrath »

jperras wrote: post #20

For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or used telnet to help develop a client for something like memcached. The ease of discoverability of a protocol should not be underrated.

So you are saying you are using a tool (telnet) to view/interact with the current protocol and this is good because it is easy to read and use.

Now we build a different tool, let's call it http2net. With HTTP being so prevalent, perhaps it isn't unreasonable to think it becomes part of most OS distributions.

So now you are using a tool (http2net) to view/interact with the new protocol and this is good because it is easy to read and use.

In summary, is binary vs text really the big problem here?

Re: The 7-bit Internet

#47

Post by laumars »

zxcdw wrote: post #35
jbert wrote: post #22

Earlier quoted context omitted.

I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence. You can talk about efficiency until you're blue in the face, but human-readability is very useful. I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant prog…

> * 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…

Well actually, your assembly example is a good one because C#, Go and a bunch of other similar languages all have refractor information compiled into the output binary because debugging machine code is a pig (even with assembly mnemonics). So even the average developer enjoys the luxury of wasted information in modern specifications.

Re: The 7-bit Internet

#48

Post by jimktrains2 »

lstamour wrote: post #27

Am I the only one who thinks its ironic that the title references 7-bits? This shows that you're already binary encoded enough that your terminal has to parse it out. Why not just have a dumber terminal? Plus, it's SSL based. SSL means you're already used to not looking at things through telnet. Are you really saying we shouldn't use SSL because "it's not just 7-bit plaintext"? That's the point, after all...

> SSL means you're already used to not looking at things through telnet.

Someone has never used `openssl s_client` before.

Very few people actually delve into and edit the TLS protocol. People, including devs, often delve into the HTTP protocol and craft requests by hand, or with a simple text-processing script.

To most people, TLS is transparent. This HTTP 2.0 protocol is not transparent.

Re: The 7-bit Internet

#49

Post by wmf »

comex wrote: post #43

I don't think a simple binary protocol for HTTP would be bad at all. HTTP servers are still going to support text-based connections forever, so it only matters if you're snooping on existing traffic; but the ability to use Wireshark or tcpdump to grab the text out of packets directly is already disappearing because of encryption (SSL), which is such a good thing in general that it far outweighs that drawback. Therefo…

As I see it, SPDY/HTTP 2.0 is for the next ten years. QUIC is for the ten years after that.

Re: The 7-bit Internet

#50

Post by jimktrains2 »

makmanalp wrote: post #45

I don't get all the for-telnet arguments. Who uses telnet for this anyway? I'd bet that 90% of telnet-folk do: cake:~ mali$ telnet google.com 80 Trying 74.125.235.8... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 ....... HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 22:25:02 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 At which point they go "oh cool" and…

Have you never had to send a specific request/response to a server? I've often found it easier to store the request in a text file and pipe it instead of using curl or another tool to craft it.

When I was a webdev (over the past few years) I did this at least once a month.

I'd daily look at the HTTP headers, though. Also, I'd often add custom headers for debugging purposes.

Edit: It's also not just telnet, it's being able to use simple scripts to automate requests or responses for many reasons.

Post reply on HN