I was researching on QUIC protocol and my professor asked me this question. QUIC is said to be built on UDP and uses TLS packets. TLS itself requires reliable connection that is TCP. So, why QUIC is not said to be built on TCP?
PS: Please correct me if my concepts are wrong and if possible, please explain in deep how QUIC packets work.
QUIC is said to be built on UDP and uses TLS packets.
QUIC (RFC 9000) does not use TLS "packets".
Technically, TLS uses the term "record" to indicate a block of bytes that defines how the protocol is framed. A record specifies the TLS protocol version, the length of the record, etc.
Inside TLS frames there are one or more TLS messages that specify cryptographic information or commands.
The TLS records are transported by TCP.
What QUIC does instead is to reuse some of the TLS messages, but nothing of the TLS record layer.
For example, in TCP the first bytes sent by a client are typically a TLS record that wraps the ClientHello message.
In QUIC, instead, the first bytes are a QUIC Initial packet, that wraps a CRYPTO frame, that wraps the ClientHello message, and all of these bytes must fit into a UDP datagram (they typically do, and the Initial packet even carries a PADDING frame to make the initial bytes at least 1200).
Refer to RFC 9001 for more details about how TLS is used in QUIC.
More broadly about QUIC, it is based on UDP but borrows many TCP features (retransmissions, flow control, etc.) that basically make it an alternative to TCP in the sense that it is a reliable network protocol, with additional security (encryption) features built-in, borrowed by TLS.
TCP is clear-text and relies on TLS layered on top to provide encryption.
QUIC is a mix of TCP features and TLS features (there is no clear-text QUIC), without layering.
When you say "Why QUIC is not said to be built on TCP?", I say "QUIC is not built on TCP, it is built on UDP. However, QUIC borrows TCP features that make QUIC provide similar functionalities as TCP, in particular reliability and flow control, that are not provided by UDP".
For example, in Jetty we have implemented HTTP/1.1 and HTTP/2 (that are TCP-based protocols) on top of QUIC, using a single, persistent, QUIC stream.
This shows that QUIC can be indeed a replacement for TCP, as it can carry protocols that were designed for TCP.
QUIC includes TLS in it to allow it to be used over UDP in the same way as TCP works.
Why bother reinventing TCP and not just use TCP? Well TCP is kind of “stuck” as it’s slow to roll out new changes that fundamentally change how TCP works. Enhancing it to allow new features like multiplex streams will take a loooong time to roll out everywhere TCP is supported.
QUIC is built over simple UDP packets and everything else is handled at either end by QUIC and all the routers and networks in the middle don’t need to know about these new QUIC features.
The RFCs are all written by committee, and the structure and language is often confusing, so it is easy to mix things up.
A full TLS implementation requires a reliable transport, which as of today is provided by TCP and SCTP (RFC3436).
QUIC (RFC9001) doesn't actually require a full TLS implementation though, and instead simply re-uses parts of the TLSv1.3 standard:
4.1. Interface to TLS
As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions:
* Sending and receiving handshake messages
* Processing stored transport and application state from a resumed
session and determining if it is valid to generate or accept 0-RTT
data
* Rekeying (both transmit and receive)
* Updating handshake state
So, given the above, the actual process that QUIC takes to encrypting the packet data isn't TLS at all, but is instead provided by QUIC.
In WCF, you can create a one-way TCP Connection. How is this different from UDP?
Regarding WCF, [OperationContract(IsOneWay=true)] means that the method will not block until a response/acknowledgement appears from the callee. The underlying protocol is nonetheless TCP with all the nice features like retry, error checking etc.
See also the MSDN example
In simple words, what is the difference? Is it same as a server (the end point). Is it the same as transparent UDP? Please clear it for me.
None. UDP isn't really a client-server protocol, so 'endpoint' is a better term than 'client'.
Reading about WCP (woof, what a monster of a subject), and just into the earlier stages of what transports are available. I note that TCP is available, but not UDP. Is this because UDP is not always reliable...lossy with packets ?
Thanks,
Scott
No official reason for that. Who knows may be we will have netUDPBinding in coming releases.
But most probably they gave priority to TCP as it is reliable.
I would certainly think so. UDP is useful for streaming video or audio, not for reliable messaging.
I know that UDP is inherently unreliable, but when connecting to localhost I would expect the kernel handles the connection differently since everything can be handled internally. So in this special case, is UDP considered a reliable protocol, or will the kernel still potentially junk some packets if buffers are overrun?
I have seen UDP to localhost dropping packets. We think we were overloading the kernel queue. All we know for sure is that it was dropping packets.
I repeat a previous answer to a related question. To remain portable always anticipate your UDP sockets might drop packets or receive out of order data.
I don't think that UDP (or any other network protocol) says anything about different behavior when connecting to localhost. So the answer will depend on the specific kernel that you're using. Best to assume that UDP will behave like UDP.