Hacker News Reader

Comment by mid-kid | Hacker News Reader

I had been messing with game-related network protocols before writing my first IRC client, and the sheer simplicity of it was an eye opener.

For many protocols these days, the handshaking/authentication/formatting of the protocol and setting up a connection is so complex that you're already hundreds of lines down before you can do anything with the service, even if it's a dumb text chat like IRC is.

It's completely changed my view of what a network protocol is, and how to judge what features and characteristics are appropriate. Oftentimes this complexity is completely unwarranted! Underlying protocols like TCP and TLS already do a majority of the heavy lifting.

View on HN

Personally, after implementing an IRC+XMPP server myself I became very disappointed by prevailance of HTTP-based protocols in everything. All software is so browser-based and/or browser-driven nowadays that HTTP became de-facto the only transport-layer protocol. This is just an additional abstraction and overhead over TCP/UDP, which we cannot remove at all.

Well, there are a lot of things one get for free by going over HTTP. Things like header parsing, widely-known status codes, handling of encoding and compression, connection reuse and upgrade, load balancing, caching, etc.

I feel like many of these things are a source of confusion, including headers and status codes. Others are not really are for free even with HTTP, e.g. load balancing, this is still very much service-specific.

UDP-based HTTP/3 could be considered a better transport protocol in the future with its multiplexing and lack of HOL-blocking, but right now it's still worse than TCP on stable connections

> Well, there are a lot of things one get for free by going over HTTP. Things like header parsing, widely-known status codes, handling of encoding and compression, connection reuse and upgrade, load balancing, caching, etc.

We should, but do we in practice?

Every so often it comes up that the status code is 200 but the body is {"error": "Internal Server Error"}

I've seen JSON Web Tokens used a lot in iOS apps over the last few years (cross platform products, so it makes sense to do whatever the web thing is), but I've never been clear how this isn't just reinventing the wheel over a normal cookie and HTTPS.

(How does caching work with HTTPS, anyway? I remember that being an argument against it back in the day, but I assume there's a solution now everyone's encrypting…)

> I've seen JSON Web Tokens used a lot in iOS apps over the last few years (cross platform products, so it makes sense to do whatever the web thing is), but I've never been clear how this isn't just reinventing the wheel over a normal cookie and HTTPS.

Why are you opposing JWTs and cookies/HTTPS? It’s common to set JWTs as cookies on HTTP(S). The benefit (and disadvantage!) of JWTs is that they contain the full state, so you don’t need a database to maintain it with a session identifier.

Ah, so it's for the benefit of backend. No wonder I didn't get it, being app-side.

(I wasn't "opposing" them with more boring forms of cookie, it just seemed like reinventing the same benefit but in a more complicated way; thanks for the explanation).

> (How does caching work with HTTPS, anyway? I remember that being an argument against it back in the day, but I assume there's a solution now everyone's encrypting…)

You use Cloudflare, and let them de-encrypt the user's data.

Oh no.

(I wonder if what I'm feeling is deja vu, or if you really did remind me of a previous time someone told me that…)

Reply on news.ycombinator.com