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.
Building Protocols with HTTP
31–40 of 55 posts
Re: Building Protocols with HTTP
#32I 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…
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
#33Things 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
#34Earlier 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.
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
#35Re: Building Protocols with HTTP
#36As 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…
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
#37Earlier 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.
Yeah, using TCP directly is great, isn't it?
Re: Building Protocols with HTTP
#38Earlier quoted context omitted.
I agree. What is wrong with creating new protocols?
Anything outside of port 80/443 will be blocked at some point.
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
#39I 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…
Re: Building Protocols with HTTP
#40I 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?