TCP or UDP
Last updated
Was this helpful?
Last updated
Was this helpful?
If we can't fix head-of-line blocking within TCP, then in theory we should be able to make a new transport protocol next to UDP and TCP in the network stack. Or perhaps even use which is a transport protocol standardized by the IETF in with several of the desired characteristics.
However, in recent years efforts to create new transport protocols have almost entirely been halted because of the difficulties in deploying them on the Internet. Deployment of new protocols is hampered by many firewalls, NATs, routers and other middle-boxes that only allow TCP or UDP are deployed between users and the servers they need to reach. Introducing another transport protocol makes N% of the connections fail because they are being blocked by boxes that see it not being UDP or TCP and thus evil or wrong somehow. The N% failure rate is often deemed too high to be worth the effort.
Additionally, changing things in the transport protocol layer of the network stack typically means protocols implemented by operating system kernels. Updating and deploying new operating system kernels is a slow process that requires significant effort. Many TCP improvements standardized by the IETF are not widely deployed or used because they are not broadly supported.
SCTP is a reliable transport protocol with streams, and for WebRTC there are even existing implementations using it over UDP.
This was not deemed good enough as a QUIC alternative due to several reasons, including:
SCTP does not fix the head-of-line-blocking problem for streams
SCTP requires the number of streams to be decided at connection setup
SCTP does not have a solid TLS/security story
SCTP has a 4-way handshake, QUIC offers 0-RTT
QUIC is a bytestream like TCP, SCTP is message-based
QUIC connections can migrate between IP addresses but SCTP cannot
For more details on the differences, see .