1

TCP has a standard API called "TCP sockets" and in our environment we don't need to worry about which library implements TCP.

However, HTTP/3 explained says QUIC has no standard API. So, any program over QUIC depends on the library that implements QUIC. Porting those programs to other environments can also be a hard work.

Why did QUIC Working Group make this decision?

hiroyuki
  • 61
  • 4
  • You are better off directing this question to the QUIC Working Group. There are both GitHub repo and a mailing list. See here: https://quicwg.org/ – Dmitri Dec 07 '20 at 21:21
  • Actually, TCP libraries across platforms (windows and linux) are often quite different. QUIC is just very new: give it a few years and it'll settle down to a similar state of afairs. – Buffoonism Aug 08 '22 at 16:46
  • TCP is implemented at the kernel level whereas QUIC is implemented in the user-space. Due to this, there are multiple QUIC implementations based on the protocol laid out in RFC9000 whereas there aren't many user libraries for TCP. Also, keep in mind that as @Buffoonism mentioned, different kernels could have different TCP implementations. – nnori Sep 13 '22 at 10:04

1 Answers1

1

Why did QUIC Working Group make this decision?

The QUIC working group defines the protocol. It doesn't write APIs. From there, many different groups went off and implemented the protocol independently. Each had different API requirements, so they all evolved a little differently.

You can find a (fairly out date) list of them here: https://github.com/quicwg/base-drafts/wiki/Implementations.

Porting those programs to other environments can also be a hard work.

Several implementations (e.g. msquic) are cross platform (and even cross-language) so you shouldn't have to "port" to other environments.

Nick Banks
  • 4,298
  • 5
  • 39
  • 65