←back to thread

QUIC is not quick enough over fast internet

(arxiv.org)
306 points carlos-menezes | 2 comments | 19 Oct 24 21:04 UTC | HN request time: 0s | source
Show context
austin-cheney ◴[19 Oct 24 22:26 UTC] No.41891263[source]▶
EDITED.

I preference WebSockets over anything analogous to HTTP.

Commented edited because I mentioned performance conditions. Software developers tend to make unfounded assumptions/rebuttals of performance conditions they have not tested.

replies(6): >>41891324 #>>41891333 #>>41891426 #>>41891517 #>>41891549 #>>41891575 #
1. akira2501 ◴[19 Oct 24 22:37 UTC] No.41891333[source]▶
I'd use them more, but WebSockets are just unfortunately a little too hard to implement efficiently in a serverless environment, I wish there was a protocol that spoke to that environment's tradeoffs more effectively.

The current crop aside from WebSockets all seem to be born from taking a butcher knife to HTTP and hacking out everything that gets in the way of time to first byte. I don't think that's likely to produce anything worthwhile.

replies(1): >>41891438 #
2. austin-cheney ◴[19 Oct 24 22:58 UTC] No.41891438[source]▶
That is a fair point. I wrote my own implementation of WebSockets in JavaScript and learned much in doing so, but it took tremendous trial and effort to get right. Nonetheless, the result was well worth the effort. I have a means to communicate to the browser and between servers that is real time with freedom to extend and modify it at my choosing. It is unbelievably more responsive than reliance upon HTTP in any of its forms. Imagine being able to execute hundreds of end-to-end test automation scenarios in the browser in 10 seconds. I can do that, but I couldn't with HTTP.