5 ms·

This is another reason these text style protocols are poorly designed. In addition to ending up ambiguous in practice, in addition to not being standard because

This is another reason these text style protocols are poorly designed. In addition to ending up ambiguous in practice, in addition to not being standard because of "liberal implementations", we get this terrible performance to boot. SIP has the same issue. Though most VoIP companies don't have much bandwidth and you can just saturate them. But if they manage to filter that, overloading the actual system is not a difficult task.

chubot 11y ago
Design has many dimensions; performance is only one of them. Text protocols tend to grow ambiguities, but that's because they're evolvable. That's a feature, not a bug. A binary protocol would likely have already collapsed under its own weight. (Name a binary application level protocol that has achieved adoption as wide as HTTP) HTTP also wasn't designed from scratch. The message format is shared with e-mail (RFC 2822, RFC 822), presumably so people could reuse existing code. HTML wasn't designed from scratch either; it was based on SGML. There are lots of good reasons that e-mail was text. You're basically arguing against nature. Humans ostensibly design protocols, but it's really the laws of evolution and economics (nature) that determine which ones survive. It's like complaining that human knees and backs are fragile... yeah that's true, but there's nothing you could have done about it.
- userbinator 11y ago
  Name a binary application level protocol that has achieved adoption as wide as HTTP DNS?
  - andrewflnr 11y ago
    That's what I thought first, but it's pretty reasonable to say that DNS is not an application level protocol. It's not a transport protocol, but feels like it belongs at the same "height" as TCP.
- magila 11y ago
  > That's a feature, not a bug. No, it's definitely a bug. You can have extensiblity without ambiguity, see the examples below... > Name a binary application level protocol that has achieved adoption as wide as HTTP TLS, SSH, DHCP, DNS
  - chubot 11y ago
    Why does SSH have v1 and v2? Honest question, I don't know the protocol. I would guess it's because v1 was too brittle to be upgraded. SSH and TLS have very few implementations... and there also seem to be incompatible versions there, at least with SSL 2.0 and 3.0. That approach might work for the ecological niche of those protocols, but I don't think it would have worked for HTTP. There are orders of magnitude more HTTP implementations than DNS, DHCP, TLS, SSH, etc. That's one reason for its wide adoption.
    - magila 11y ago
      The different versions of SSH and TLS came about because the protocols' semantics needed to be revised in non-backwards compatible ways to resolve security issues. This has nothing to do with the format of the protocol. I would remind you that HTTP has also had similar revisions (0.9, 1.0, 1.1). Hyperbole about "orders of magnitude" aside, I'm not sure having a very large number of implementations should be seen as a plus. Protocols like SSH, DNS, and DHCP have relatively few implementations because the vast majority of use cases are covered perfectly well by a handful of existing libraries and tools. By comparison HTTP implementations tend to be ad-hoc and tightly coupled.
      - chubot 11y ago
        HTTP 1.1 is backward compatible with 1.0, and I'm pretty sure 0.9 is. I think with SSH and SSL they basically have an (if version) statement at the top level, and then enter a completely different codebase for each version. They can get away with this because there are so few implementations. With HTTP you had more graceful upgrade. They made "mistakes" but were able to accomodate it within the existing structure.
- amenod 11y ago
  Well said. Also, binary protocol could easily be added on top of HTTP, a kind of "smart-gzip" which would encode (known) HTTP to binary codes. That could make parsing faster while keeping the evolvability of the protocol intact.
  - chubot 11y ago
    Actually, that's exactly what HTTP 2.0 is :) They're keeping the exact same message semantics, while changing the encoding to binary and also changing the network transfer part. I'd be a little concerned about fixing it in place, but it's perhaps possible that HTTP is done evolving, and this will be a win. HTTP has gotten so much usage far beyond its original intent. As an aside, I chafe against the implicit assumption in your message that binary is more space-efficient than text. :) Compressed text and binary formats are the same size (e.g. JSON vs protocol buffers), and compression is almost free these days in terms of CPU. And sometimes uncompressed text is SMALLER than binary, i.e. in the case of encoding numbers. Many data sets have lots of zeros and small numbers, and it takes 1-3 bytes to encode a zero in text ("0", "0,", "0.0") while it takes 4-8 bytes to encode in most binary formats. A CSV file vs. a memory dump of the same numbers can show this. Numbers encoded as ASCII is a built-in "varint" format, which shouldn't be underestimated.
    - MichaelGG 11y ago
      General use compression algorithms suck at both ratio and speed when it comes to compressing integers. ASCII numbers are strictly inferior to even varint (base128) encoding. And varint is junk (in bulk) compared to int formats like PFor or Simple16 etc. You're arguing that a format with fixed width is worse. Sure. So what about fixed width text protocols? Nothing stops the spec writers from requiring leading zeros. Just like nothing stops binary protocols from using varint. The reason you want fixed width, though, is because it's so easy and fast to deal with. It's a no-op. TCP/IP is so easy because you just deref the message as a struct.
      - chubot 11y ago
        OK but I also think you're conflating two issues: text vs. binary on the one hand, and delimiter vs length-prefixed on the other. I like DJB's netstring scheme, which is an ASCII length-prefixed encoding: 3:foo, 10:0123456789, Text formats usually have delimiters (like HTTP headers), and binary formats usually have length prefixes, but technically they're orthogonal. I've never seen a fixed-width text format for numbers in practice.
- MichaelGG 11y ago
  Trace those RFCs all the way back. Where does the format originate? Nearly 50 years ago, as a codification of what humans were writing by hand. Those formats make tons of sense where you are encoding messages by hand. Be flexible. Allow comments. Allow continuing headers across multiple lines then turning the extra spaces into one. All this is great when ed (or nothing?) was your mail client. It makes absolutely zero sense in any protocol of the last 30 years at least. Code reuse for parsing a line? No one does that, and supposedly it's so easy they wouldn't need too, right? And it wouldn't work anyways, as different headers have different rules - you can't treat it just as a sequence of name-value pairs. Extensibility has nothing to do with text vs binary. And my complaint is bad text formats. Having strict, simple, rules, then using ASCII printable chars is just inefficient, but not atrocious. HTML is funny example, being the poster child of crap-interop, with browsers interpreting things differently, even at a basic level (unclosed tags, incorrectly closed tags, spacing, etc.). Can you explain how text is more extensible? Seems like that's totally dependent on the spec.
  - chubot 11y ago
    Well, I'm not arguing that they are optimal now, or that code reuse is an issue now. My point is that it really couldn't have been any other way, for economic and evolutionary reasons. In your posts, I see the implicit assumption that "someone made a mistake a long time ago", and that a lack of knowledge by those people led to the current situation. I should have been more precise about extensibility. (I have had this argument a bunch of times...) Another way to say it is that text formats are more amenable to partial implementation. That's the "dual". Suppose you have N people using a protocol, and there are O(N^2) communication paths. And then three of those people have a need for some extension -- say they want to add some new caching mechanism to save bandwidth. They can negotiate an extension to the protocol out of band. If it introduces some value, then it might be adopted by everybody. Or it might just die. But at all points in time, somebody is extending. And they don't necessarily consult a spec to do so; they just read the raw messages and negotiate something based on their needs, which doesn't break other people. "The Art of Unix Programming" has more concrete examples of this process actually happening [1]. Depending on how you look at it, other users now have a partial implementation. It can also start the other way -- there are plenty of partial implementations of HTTP that are useful -- implementing only GET, not implementing caching, etc. Yes these are sloppy, but they are useful, and help the protocol gain adoption. Don't underestimate the number of people debugging HTTP with telnet or netcat in a shell script either. You can either try to each everyone the "right way" to do things or accept that there is a lot more diversity in the computing world that most people think. The precise things that make text formats a pain to deal with are the things that make them survive. There is no instant at which a global truth for the protocol is born; it arises over time. This wisdom is baked into the name: "RFC". It's open-ended and ambiguous. [1] http://www.catb.org/esr/writings/taoup/html/ch05s01.html http://www.catb.org/esr/writings/taoup/html/ch05s01.html
userbinator 11y ago
I agree completely --- they look "human friendly" but parsing them is a huge pain. A simple binary protocol, while not as easily human-readable (but that's what hex dumps are for), could be just as extensible without all the ambiguity. It doesn't even have to be something as complex as ASN.1; a similar sort of TLV-based protocol would fit the use case very well. E.g. [1 byte request method; 2 bytes URL length; variable-length URL; [1 byte header name; 2 bytes header data length; variable-length header data] 0 terminator] On the bright side, at least IP, TCP, etc. weren't designed in the same way...
- zzzcpan 11y ago
  > On the bright side, at least IP, TCP, etc. weren't designed in the same way... And yet almost anyone can implement an HTTP server with their own parser, that works for every client out there in just a few weeks, but not TCP stack or DNS server. It is incorrect to assume, that parsing text is hard. It never was and never will be. It's the other way around.
  - userbinator 11y ago
    And yet almost anyone can implement an HTTP server with their own parser, that works for every client out there in just a few weeks, but not TCP stack or DNS server. That has little to do with binary vs. text. It's because [1] TCP is itself a very complex protocol, especially to get all the corner cases right, and [2] DNS servers are not popular to write because there is usually very little reason to. If HTTP was a simple binary protocol you'd probably make the same observation.
    - zzzcpan 11y ago
      I think it has everything to do with it. Because text protocols share a single textual encoding with lots of tools available and usually don't force you to parse anything you don't need. Put a few rules in your parser generator and you are done. Binary protocols, on the other hand, each use their own encoding and usually force you to decode every little thing before they can be used correctly. Which always makes them much more complicated and error-prone, than textual protocols.
joosters 11y ago
HTTP parsing can be very fast, the article doesn't really show that it is slow. Their use case of 'If logging is switched off and all content is in cache, then HTTP parser becomes the hottest spot' is hardly surprising. All that's left is to read() the request and write() the response, the parsing is everything that remains.
- MichaelGG 11y ago
  Google seems to disagree, and this is a main reason HTTP2 uses a proper binary format. And it concurs with my keen experience, having written a proxy and indexer for SIP, which shares most of HTTP's parse design. The simple fact that there's more bytes involved means there gonna be more work. Add to that the inane "human writeable" rules like line folding and it's a mess.

chubot 11y ago

Design has many dimensions; performance is only one of them. Text protocols tend to grow ambiguities, but that's because they're evolvable. That's a feature, not a bug. A binary protocol would likely have already collapsed under its own weight. (Name a binary application level protocol that has achieved adoption as wide as HTTP) HTTP also wasn't designed from scratch. The message format is shared with e-mail (RFC 2822, RFC 822), presumably so people could reuse existing code. HTML wasn't designed from scratch either; it was based on SGML. There are lots of good reasons that e-mail was text. You're basically arguing against nature. Humans ostensibly design protocols, but it's really the laws of evolution and economics (nature) that determine which ones survive. It's like complaining that human knees and backs are fragile... yeah that's true, but there's nothing you could have done about it.

userbinator 11y ago
Name a binary application level protocol that has achieved adoption as wide as HTTP DNS?
- andrewflnr 11y ago
  That's what I thought first, but it's pretty reasonable to say that DNS is not an application level protocol. It's not a transport protocol, but feels like it belongs at the same "height" as TCP.
magila 11y ago
> That's a feature, not a bug. No, it's definitely a bug. You can have extensiblity without ambiguity, see the examples below... > Name a binary application level protocol that has achieved adoption as wide as HTTP TLS, SSH, DHCP, DNS
- chubot 11y ago
  Why does SSH have v1 and v2? Honest question, I don't know the protocol. I would guess it's because v1 was too brittle to be upgraded. SSH and TLS have very few implementations... and there also seem to be incompatible versions there, at least with SSL 2.0 and 3.0. That approach might work for the ecological niche of those protocols, but I don't think it would have worked for HTTP. There are orders of magnitude more HTTP implementations than DNS, DHCP, TLS, SSH, etc. That's one reason for its wide adoption.
  - magila 11y ago
    The different versions of SSH and TLS came about because the protocols' semantics needed to be revised in non-backwards compatible ways to resolve security issues. This has nothing to do with the format of the protocol. I would remind you that HTTP has also had similar revisions (0.9, 1.0, 1.1). Hyperbole about "orders of magnitude" aside, I'm not sure having a very large number of implementations should be seen as a plus. Protocols like SSH, DNS, and DHCP have relatively few implementations because the vast majority of use cases are covered perfectly well by a handful of existing libraries and tools. By comparison HTTP implementations tend to be ad-hoc and tightly coupled.
    - chubot 11y ago
      HTTP 1.1 is backward compatible with 1.0, and I'm pretty sure 0.9 is. I think with SSH and SSL they basically have an (if version) statement at the top level, and then enter a completely different codebase for each version. They can get away with this because there are so few implementations. With HTTP you had more graceful upgrade. They made "mistakes" but were able to accomodate it within the existing structure.
amenod 11y ago
Well said. Also, binary protocol could easily be added on top of HTTP, a kind of "smart-gzip" which would encode (known) HTTP to binary codes. That could make parsing faster while keeping the evolvability of the protocol intact.
- chubot 11y ago
  Actually, that's exactly what HTTP 2.0 is :) They're keeping the exact same message semantics, while changing the encoding to binary and also changing the network transfer part. I'd be a little concerned about fixing it in place, but it's perhaps possible that HTTP is done evolving, and this will be a win. HTTP has gotten so much usage far beyond its original intent. As an aside, I chafe against the implicit assumption in your message that binary is more space-efficient than text. :) Compressed text and binary formats are the same size (e.g. JSON vs protocol buffers), and compression is almost free these days in terms of CPU. And sometimes uncompressed text is SMALLER than binary, i.e. in the case of encoding numbers. Many data sets have lots of zeros and small numbers, and it takes 1-3 bytes to encode a zero in text ("0", "0,", "0.0") while it takes 4-8 bytes to encode in most binary formats. A CSV file vs. a memory dump of the same numbers can show this. Numbers encoded as ASCII is a built-in "varint" format, which shouldn't be underestimated.
  - MichaelGG 11y ago
    General use compression algorithms suck at both ratio and speed when it comes to compressing integers. ASCII numbers are strictly inferior to even varint (base128) encoding. And varint is junk (in bulk) compared to int formats like PFor or Simple16 etc. You're arguing that a format with fixed width is worse. Sure. So what about fixed width text protocols? Nothing stops the spec writers from requiring leading zeros. Just like nothing stops binary protocols from using varint. The reason you want fixed width, though, is because it's so easy and fast to deal with. It's a no-op. TCP/IP is so easy because you just deref the message as a struct.
    - chubot 11y ago
      OK but I also think you're conflating two issues: text vs. binary on the one hand, and delimiter vs length-prefixed on the other. I like DJB's netstring scheme, which is an ASCII length-prefixed encoding: 3:foo, 10:0123456789, Text formats usually have delimiters (like HTTP headers), and binary formats usually have length prefixes, but technically they're orthogonal. I've never seen a fixed-width text format for numbers in practice.
MichaelGG 11y ago
Trace those RFCs all the way back. Where does the format originate? Nearly 50 years ago, as a codification of what humans were writing by hand. Those formats make tons of sense where you are encoding messages by hand. Be flexible. Allow comments. Allow continuing headers across multiple lines then turning the extra spaces into one. All this is great when ed (or nothing?) was your mail client. It makes absolutely zero sense in any protocol of the last 30 years at least. Code reuse for parsing a line? No one does that, and supposedly it's so easy they wouldn't need too, right? And it wouldn't work anyways, as different headers have different rules - you can't treat it just as a sequence of name-value pairs. Extensibility has nothing to do with text vs binary. And my complaint is bad text formats. Having strict, simple, rules, then using ASCII printable chars is just inefficient, but not atrocious. HTML is funny example, being the poster child of crap-interop, with browsers interpreting things differently, even at a basic level (unclosed tags, incorrectly closed tags, spacing, etc.). Can you explain how text is more extensible? Seems like that's totally dependent on the spec.
- chubot 11y ago
  Well, I'm not arguing that they are optimal now, or that code reuse is an issue now. My point is that it really couldn't have been any other way, for economic and evolutionary reasons. In your posts, I see the implicit assumption that "someone made a mistake a long time ago", and that a lack of knowledge by those people led to the current situation. I should have been more precise about extensibility. (I have had this argument a bunch of times...) Another way to say it is that text formats are more amenable to partial implementation. That's the "dual". Suppose you have N people using a protocol, and there are O(N^2) communication paths. And then three of those people have a need for some extension -- say they want to add some new caching mechanism to save bandwidth. They can negotiate an extension to the protocol out of band. If it introduces some value, then it might be adopted by everybody. Or it might just die. But at all points in time, somebody is extending. And they don't necessarily consult a spec to do so; they just read the raw messages and negotiate something based on their needs, which doesn't break other people. "The Art of Unix Programming" has more concrete examples of this process actually happening [1]. Depending on how you look at it, other users now have a partial implementation. It can also start the other way -- there are plenty of partial implementations of HTTP that are useful -- implementing only GET, not implementing caching, etc. Yes these are sloppy, but they are useful, and help the protocol gain adoption. Don't underestimate the number of people debugging HTTP with telnet or netcat in a shell script either. You can either try to each everyone the "right way" to do things or accept that there is a lot more diversity in the computing world that most people think. The precise things that make text formats a pain to deal with are the things that make them survive. There is no instant at which a global truth for the protocol is born; it arises over time. This wisdom is baked into the name: "RFC". It's open-ended and ambiguous. [1] http://www.catb.org/esr/writings/taoup/html/ch05s01.html http://www.catb.org/esr/writings/taoup/html/ch05s01.html

userbinator 11y ago

I agree completely --- they look "human friendly" but parsing them is a huge pain. A simple binary protocol, while not as easily human-readable (but that's what hex dumps are for), could be just as extensible without all the ambiguity. It doesn't even have to be something as complex as ASN.1; a similar sort of TLV-based protocol would fit the use case very well. E.g. [1 byte request method; 2 bytes URL length; variable-length URL; [1 byte header name; 2 bytes header data length; variable-length header data] 0 terminator] On the bright side, at least IP, TCP, etc. weren't designed in the same way...

zzzcpan 11y ago
> On the bright side, at least IP, TCP, etc. weren't designed in the same way... And yet almost anyone can implement an HTTP server with their own parser, that works for every client out there in just a few weeks, but not TCP stack or DNS server. It is incorrect to assume, that parsing text is hard. It never was and never will be. It's the other way around.
- userbinator 11y ago
  And yet almost anyone can implement an HTTP server with their own parser, that works for every client out there in just a few weeks, but not TCP stack or DNS server. That has little to do with binary vs. text. It's because [1] TCP is itself a very complex protocol, especially to get all the corner cases right, and [2] DNS servers are not popular to write because there is usually very little reason to. If HTTP was a simple binary protocol you'd probably make the same observation.
  - zzzcpan 11y ago
    I think it has everything to do with it. Because text protocols share a single textual encoding with lots of tools available and usually don't force you to parse anything you don't need. Put a few rules in your parser generator and you are done. Binary protocols, on the other hand, each use their own encoding and usually force you to decode every little thing before they can be used correctly. Which always makes them much more complicated and error-prone, than textual protocols.

joosters 11y ago

HTTP parsing can be very fast, the article doesn't really show that it is slow. Their use case of 'If logging is switched off and all content is in cache, then HTTP parser becomes the hottest spot' is hardly surprising. All that's left is to read() the request and write() the response, the parsing is everything that remains.

MichaelGG 11y ago
Google seems to disagree, and this is a main reason HTTP2 uses a proper binary format. And it concurs with my keen experience, having written a proxy and indexer for SIP, which shares most of HTTP's parse design. The simple fact that there's more bytes involved means there gonna be more work. Add to that the inane "human writeable" rules like line folding and it's a mess.