Live data from Hacker News

Building Protocols with HTTP

tools.ietf.org

31–40 of 55 posts

Re: Building Protocols with HTTP

#31
post #28

Earlier quoted context omitted.

Yes, the blocking problem mostly affects corporate networks or shady wlan access points. Game developers don't really have a problem with using UDP/TCP on random ports.

Sure, but there's a bit of a stretch from there to the parent posters claim "anything outside of port 80/443 will be blocked at some point" as a justification not to develop new, non-HTTP based protocols.

Of course, it's just a sloppy excuse.

Re: Building Protocols with HTTP

#32
post #11

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP". The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Int…

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-inv…

As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance?

I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right?

P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.

Re: Building Protocols with HTTP

#33
As I regard HTTP to be one of the main hindrance in todays IT industry I feel it is my duty to add my voice to those trying to warn against the now decade long trend to wrap everything into HTTP.

Things that HTTP makes more complicated:

1. It's a verbose protocol with more often than not a really bad ratio payload over metadata;

2. Client authentication is hard;

3. Server authentication is expensive;

4. It's bad at streaming;

5. It does not help a bit for RPC (no support for fan-out, quotas, fail-overs, retries, ...).

Building an infrastructure on HTTP makes it so unreliable that I came to consider one of the reason for Google technical superiority is that they early ditched HTTP completely out and used stubby for everything instead. Maybe they themselves view it as their secret sauce, which would explain why they've never published a comparative review (that I'm aware of)? Many people I've spoken to about this have expressed surprise that there is no HTTP flowing on Google's veins. To many, removing HTTP is like removing the solid ground; but to a former googler, loosing access to stubby and having to work with HTTP again is a painful experience that requires quite some time to accept.

Re: Building Protocols with HTTP

#34
post #24

Earlier quoted context omitted.

My bad. I should have said SSL/TLS/SSH. * SFTP/FTPS (SSH) * SSH (SSH) * SMTPS (SSL, TLS)

Still wrong. FTPS is vanilla FTP over TLS.

> Still wrong

You know that thing that gives security practitioners a bad reputation with engineers?

You're doing it.

As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?

Re: Building Protocols with HTTP

#36
post #33

As I regard HTTP to be one of the main hindrance in todays IT industry I feel it is my duty to add my voice to those trying to warn against the now decade long trend to wrap everything into HTTP. Things that HTTP makes more complicated: 1. It's a verbose protocol with more often than not a really bad ratio payload over metadata; 2. Client authentication is hard; 3. Server authentication is expensive; 4. It's bad at s…

> they early ditched HTTP completely out and used stubby for everything instead.

Yes, when I worked there, it was interesting to realize that they take HTTP, and immediately convert it to protobuf.

Re: Building Protocols with HTTP

#37
post #7

Earlier quoted context omitted.

I agree. What is wrong with creating new protocols?

Familiarity. I can either work with a protocol that has been around, in some way shape or form, for almost 30 years. That has matured, has a myriad of information relating to edge cases, is familiar to new and old developers, and is quick to develop for. Or I can create my own protocol which has none of those benefits besides possibly quick development.

> Familiarity. I can either work with a protocol that has been around, in some way shape or form, for almost 30 years.

Yeah, using TCP directly is great, isn't it?

Re: Building Protocols with HTTP

#38
post #5

Earlier quoted context omitted.

I agree. What is wrong with creating new protocols?

Anything outside of port 80/443 will be blocked at some point.

Only if nobody uses those ports.

I want as much as possible to break for people who block those ports, and engage in other user-hostile actions.

Re: Building Protocols with HTTP

#39
post #11

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP". The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Int…

Just curious, what do you think of QUIC? Seems like a layer 4 replacement, right?

Re: Building Protocols with HTTP

#40
post #39
post #11

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP". The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Int…

Just curious, what do you think of QUIC? Seems like a layer 4 replacement, right?

QUIC operates on top of UDP, which would make it layer 5.
Post reply on HN