Hacker News Reader

Comment by kevincox | Hacker News Reader

> the overhead of the http layer

There isn't much overhead here other than connection setup. For HTTP/1 the connection is just "upgraded" to websockets. For HTTP/2 I think the HTTP layer still lives on a bit so that you can use connection multiplexing (which maybe be overhead if you have no use for it here) but that is still a very thin layer.

So I think the question isn't so much HTTP overhead but WebSocket overhead. WebSockets add a bit of message framing and whatnot that may be overhead if you don't need it.

In 99% of applications if you need encryption, authentication and message framing you would be hard-pressed to find a significantly more efficient option.

View on HN

> In 99% of applications if you need encryption, authentication and message framing you would be hard-pressed to find a significantly more efficient option.

AFAIK, websockets doesn't do authentication? And the encryption it does is minimal, optional xor with a key disclosed in the handshake. It does do framing.

It's not super common, but if all your messages have a 16-bit length, you can just use TLS framing. I would argue that TLS framing is ineffecient (multiple length terms), but using it by itself is better than adding a redundant framing layer.

But IMHO, there is significant benefit from removing a layer where it'd unneeded.

> AFAIK, websockets doesn't do authentication?

Websocket allows for custom header and query parameters which make it possible to run a basic authentication scheme and later on additional autorisation in the message themselves if really necessary.

> And the encryption it does is minimal, optional xor with a key disclosed in the handshake. It does do framing.

Web Secure Socket (WSS) is the TLS encrypted version of Websockets (WS) (similar to HTTP vs. HTTPS).

Worth noting that wbesockets in the browser don't allow custom headers and custom header support is spotty accross sever impls. It's just not exposed in the javascript API. There has been an open chrome bug for that for like 15 years

> Worth noting that wbesockets in the browser don't allow custom headers

They do during the initial handshake (protocol upgrade from HTTP to WebSocket).

Afterwards the message body can be used to send authorisation data.

Server support will depend on tech but Node.js has great support.

https://github.com/whatwg/websockets/issues/16

No, I don't think you get it. `new Websocket()` from JS takes no arguments for headers. You literally can't send headers during the handshake from JS. https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/W...

Actually will look into using the subprotocol as a way to do auth, but most impls in the wild send the auth as the first message.

The fact the protocol in theory supports it doesn't really matter much since no browser implements that part of the spec.

Ok, so what is WebSockets providing that you don't get from TLS?

In a browser context, I see the value; browsers are very constrained, so you use what's offered. In a non-browser context, I don't see the value.

If you need to support mixed use, you could go either way and that's fine, too.

Reply on news.ycombinator.com