<story><title>HTTP/3 explained</title><url>https://http3-explained.haxx.se/en/</url></story><parent_chain><item><author>shereadsthenews</author><text>The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.</text></item><item><author>jlouis</author><text>I&amp;#x27;m worried, not because of the standard itself, which seems well thought out, even if rushed.&lt;p&gt;I&amp;#x27;m worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much.&lt;p&gt;Also, note that the exact problem that HTTP&amp;#x2F;3 tries to solve was known in the design process of HTTP&amp;#x2F;2 and some people even noted having multiple flow control schemes at multiple layers would become a problem. We are letting the same people design the next layer, and probably too fast in the name of time to market.&lt;p&gt;This should definitely live in a way people can make use of it easily, with an API highly amenable to binding. If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth. This kills operating system diversity as well, or runs the risk at doing so.&lt;p&gt;OTOH, I see the lure: SCTP never caught on for a reason, and much of this is the opposite of my above worries.</text></item><item><author>1_player</author><text>So much negativity in this thread.&lt;p&gt;Personally I am _very_ excited by HTTP&amp;#x2F;3 (and QUIC), it feels like the building block for Internet 2.0, with connection migration over different IPs, mandatory encryption, bidirectional streams and it being a user-space library – sure, more bloat, but from now on we won&amp;#x27;t have to wait for your kernel to support feature X, or even worse, your ISP-provided router or decade old middleware router on the Internet.&lt;p&gt;I haven&amp;#x27;t had the chance to read the actual spec yet, but it&amp;#x27;s obvious that while the current tech (HTTP2) is an improvement over what we had before, HTTP&amp;#x2F;3 is a good base to make the web even faster and more secure.&lt;p&gt;HTTP&amp;#x2F;3 won&amp;#x27;t be IPv6: it only requires support from the two parties that benefit from it the most: browser vendors and web server vendors. We won&amp;#x27;t have to wait on the whole internet to upgrade their hardware.</text></item></parent_chain><comment><author>jandrese</author><text>The rallying cry of everybody who later comes to the realization that they have re-implemented TCP.</text></comment>
<story><title>HTTP/3 explained</title><url>https://http3-explained.haxx.se/en/</url></story><parent_chain><item><author>shereadsthenews</author><text>The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.</text></item><item><author>jlouis</author><text>I&amp;#x27;m worried, not because of the standard itself, which seems well thought out, even if rushed.&lt;p&gt;I&amp;#x27;m worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much.&lt;p&gt;Also, note that the exact problem that HTTP&amp;#x2F;3 tries to solve was known in the design process of HTTP&amp;#x2F;2 and some people even noted having multiple flow control schemes at multiple layers would become a problem. We are letting the same people design the next layer, and probably too fast in the name of time to market.&lt;p&gt;This should definitely live in a way people can make use of it easily, with an API highly amenable to binding. If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth. This kills operating system diversity as well, or runs the risk at doing so.&lt;p&gt;OTOH, I see the lure: SCTP never caught on for a reason, and much of this is the opposite of my above worries.</text></item><item><author>1_player</author><text>So much negativity in this thread.&lt;p&gt;Personally I am _very_ excited by HTTP&amp;#x2F;3 (and QUIC), it feels like the building block for Internet 2.0, with connection migration over different IPs, mandatory encryption, bidirectional streams and it being a user-space library – sure, more bloat, but from now on we won&amp;#x27;t have to wait for your kernel to support feature X, or even worse, your ISP-provided router or decade old middleware router on the Internet.&lt;p&gt;I haven&amp;#x27;t had the chance to read the actual spec yet, but it&amp;#x27;s obvious that while the current tech (HTTP2) is an improvement over what we had before, HTTP&amp;#x2F;3 is a good base to make the web even faster and more secure.&lt;p&gt;HTTP&amp;#x2F;3 won&amp;#x27;t be IPv6: it only requires support from the two parties that benefit from it the most: browser vendors and web server vendors. We won&amp;#x27;t have to wait on the whole internet to upgrade their hardware.</text></item></parent_chain><comment><author>mehrdadn</author><text>How does it work with a debugger? With TCP the connection didn&amp;#x27;t die just because you paused the program. But when everything is in userspace then that can&amp;#x27;t happen anymore?</text></comment>