4 ms·
Apart from the obvious push capabilities, yes, websocket has much less overhead and is faster than HTTPS. Once the connection is established, you can send requ
by ht85 9y ago
Apart from the obvious push capabilities, yes, websocket has much less overhead and is faster than HTTPS.
Once the connection is established, you can send requests starting at 1 byte size, whereas HTTP needs the full headers on every request.
HTTPS also has a lot of handshake overhead, where you need 2-3 round trips per request instead of a single one with websocket. This can make a world of difference in a 150+ ping situation, where HTTP feels sluggish and websocket feels instant.
- ammmir 9y agoactually, both HTTPS and WebSocket over TLS (wss://) require a TLS handshake, so it's not like you're constantly doing that after you've loaded the page, but HTTP request/response header sizes could def be a concern.
- jeremyjh 9y agoNo, there is not a handshake for every message you send over websocket. You do the handshake only when you open the connection.
- snaily 9y agoHTTP keepalive should get you much of the same benefit, though? The major improvement comes from fewer headers sent over websockets?
- ht85 9y agoSSL Session Reuse needs to be configured as well, otherwise every single request will have to perform a new handshake, independently of keepalive. In practice I've always observed HTTPS requests to take at least twice as long compared to a back and forth through a websocket, even when SSR and keepalive are enabled. I don't know if having both theorically allows for single-roundtrip HTTPS requests.