Wait, why would you not use a websocket for this?
this post was submitted on 12 Aug 2024
86 points (95.7% liked)
Opensource
1113 readers
64 users here now
A community for discussion about open source software! Ask questions, share knowledge, share news, or post interesting stuff related to it!
⠀
founded 11 months ago
MODERATORS
My guess that websocket add additional overhead both in size (header) and complexity as browser and server need to encode/decode it making it more CPU intensive not to mention harder to implement.
I've implemented it myself, down to the encoding and buffer management.
It's a really simple back and forth first, but after that it's just dumping arbitrary binary data through the socket
Yes, but with WebSocket you need to have a server and that will consume some additional CPU.
Without it you only need some random CDN to do the download test.
This server is just a piece of software that accepts and responds to TCP sockets. It could be anything, but you're not consuming more CPU power by doing less work.
The http protocol requires you prepend every message with a bunch of headers and for them to have a static size. (tho plenty of apps allow you to bend the rules quite a bit)
After switching to a websocket, none of that applies. You can just dump data straight into the TCP socket. Or TLS stream that goes into the TCP socket. But that would be same for the http requests
On the server side to send you data, using any web server with mmap support will probably be less CPU intensive than app that handles websocket, but yes, the details matter as when reading a lot of small files vs websocket, then websocket could be better for CPU usage especially when you could generate data.
But once again using plain old http allow you to use the speestest software against any CDN very easy IMO.
Adding headers and some other minor requirements is slower than not. That's really the difference, it's not complicated.