@Eli
No way. Apple tried hard to push SCTP adoption. SCTP is not great regarding latency either, requiring about 4 round trips while QUIC only needs 0. Initial latency is the major reason behind QUIC’s design.
SCTP needs about 4 round trips while QUIC is 0. Initial latency is really what drives QUIC.
Now that’s a solid reason to pick QUIC over SCTP.
Apple tried hard for SCTP adoption.
Haha, not really. Just one simple UI cue on “network health” on every iPhone, and they could’ve made it widely accepted years ago.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
Is this one of those scenarios where we can picture a different universe where Al Gore won and we’re using SCTP over IPv6, but in reality, we’re stuck with TCP over IPv4? (Yes, TCP. Even shiny new things like HTTP/3 are still kind of rare.)
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
The trouble now is that SCTP in its current form is outdated, and there aren’t many full SCTP implementations available as open source. Its congestion control isn’t great and needs a proper update to account for the latest research.
Currently, the only implementation that supports mixed messaging at a nearly production-ready level is in Chrome, and it’s only including what’s necessary for WebRTC.
The other common implementation, usrsctp, doesn’t support this feature, which has existed in the spec for a while. It also has many known bugs that can lead to deadlocks, which makes it not suitable for production (Chrome saw a significant drop in crashes once it moved away from usrsctp).
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
SCTP never performed well on a large scale because of stubborn middleboxes blocking it since it’s its own protocol. Most dumb firewalls only allow TCP, UDP, and ICMP while dismissing everything else as bad. Apple put in a lot of effort to take this to the general public but ultimately failed.
@Zyler
SCTP does support UDP encapsulation.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
How else will you get a promotion?
@Hadi
Browsers should probably use QUIC for downloading HTML while starting an http2 connection at the same time to load resources. This way, you get the best of both latency and max speed.
TCP is a streaming protocol that doesn’t keep message boundaries. This means the application’s buffer writings don’t control how those bytes turn into packets.
That’s not entirely accurate:
The PSH flags tell the operating system to send (for the sending side) and receive (for the receiving side) all the data right away. This means this flag instructs the network stack of the operating system to send/receive all the content of its buffers right away.
Understanding TCP Flags: Site24x7.
This is significant for many chatty protocols.
Maybe you got this, but not everyone reading your reply might.
@Uma
Just keep in mind that using the PSH flag can still lead to writes or reads that don’t take message boundaries into account. If the app receiving the data doesn’t clear the read buffer before a PSH flag arrives, the next time it reads, it may get both the buffered data and the PSH data (if it provides a large enough buffer).
@Hadi
The idea about more system calls doesn’t seem correct. You can read and write multiple UDP packets using a single system call, and even make that more efficient using io_uring. There’s no fundamental problem with doing more in user space.
@Keegan
You’re right that there are effective ways to do multiple writes in one syscall. I wonder if they’re being used properly in these cases.
A lot of work and teamwork from different players in the web scene, including OS makers, QUIC developers, and standard organizations, will be key to improve QUIC. As more web services adopt HTTP/3, we can expect broader use of QUIC across the web. We hope our findings can lead to further efforts to enhance QUIC and upper-level protocols generally, improving their performance for next-gen networks, services, and applications.
QUIC may not be faster right now, but it’s not like years of optimizations have been applied yet.
@Dara
Sure, but that’s a problem: any new tech needs to be better than what it’s replacing now, not just in the distant future. Of course, I’m speaking from an ideal standpoint. In reality, bad technologies often become dominant (like JavaScript), but it would be nice if we could avoid that.
I’m not saying QUIC is bad- it just presents signs of a tech that might be stylish for a while and then lead to a lot of regret. I could be wrong, but if there’s one thing to understand about network protocols, once they’re widely used, they never really go away.
@Toryn
I don’t know, Gopher really is pretty much done for. It only took about 40 years or so…
@Toryn
That’s not true. For items like lightbulbs and transistors, history shows that being almost as good but not yet optimized is the threshold to cross.
@Toryn
JavaScript perfectly embodies your first point.
It’s flawed, but has anything been made that works better and seamlessly takes its place? I can create an HTML file, load files, and manipulate binary data more easily than going through a giant IDE or handling MinGW (though that’s much easier now than it was 10 years ago).
@Uma
Has any browser ever deeply integrated support for another language, besides WASM?
There are a lot of JS transpilers like TypeScript or CoffeeScript, but it feels like JS is a functional technology with flaws easier to build around, so integrated with how HTML is processed that untangling it is tough. Ironically, changing the transport protocol might be easier since it seems to be better packed in most implementations than JS.
@Dallas
ActiveX, Java, Silverlight, and ActionScript were all other languages. Aside from ActiveX, they were all implemented through plugins, so whether they fit your definition of “browser implementation” is debatable.
@Arin
What I’m saying by “browser implementation” is the ability to manipulate the DOM and have it self-hoist without needing JS management, basically integrate with the browser like JS does.