QUIC Is Not a TCP Replacement
I see two main arguments, and neither quite makes sense to me.<p>First, that TCP wasn&#x27;t suitable for RPC based systems. Which can be true, but doesn&#x27;t imply anything about the position that QUIC isn&#x27;t ideal for reliable byte streams. Even though QUIC does great for RPC, there&#x27;s plenty of possibility that QUIC does great for reliable byte streams.<p>The second argument is that QUIC is complex, and the main argument seems to be:<p>&gt; <i>QUIC is doing a lot of work: its definition spans three RFCs covering the basic protocol (RFC 9000), its use of TLS (9001) and its congestion control mechanisms (9002)</i><p>In general, I think the decomposition of specs into different pieces is a huge win for clarity &amp; understandability and implies little about how much &quot;work&quot; it is to implement.<p>That QUIC integrates these three pieces reasonably elegantly, with clear boundaries between the aspects, shows how simple &amp; conceptually well separated the pieces can be made.<p>And then, TCP just doesn&#x27;t cover encryption, which makes using TCP securely a whole new set of complexities &amp; difficulties. TLS itself has a host of extensions &amp; related RFCs that you may need to evaluate and implement, and you and some other shop may choose quite significantly different ways of setting up TLS between systems. QUIC isn&#x27;t entirely free of <i>all</i> these choices, but it is of some of them, and having the extra work built in is, in my view, less work in the long run.<p>I&#x27;m left unconvinced that the requirements of TCP have anything special or notable over the requirements of QUIC, or that sticking to TCP in some cases has any real advantage or cause. It still feels to me like everything could switch to QUIC and we&#x27;d likely do better, &amp; end up creating better systems.