The Next Version of HTTP Won't Be Using TCP

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
In order to improve network latency, the next iteration of the Hypertext Transfer Protocol (HTTP) is switching from TCP (Transmission Control Protocol) to a protocol layered on top of UDP (User Datagram Protocol) called QUIC, or "Quick UDP Internet Connections." UDP is generally less reliable than TCP because it deals with unordered data, but QUIC, which was developed by Google, is supposed to minimize potential errors.

QUIC reinstates the reliability and ordering that TCP has but without introducing the same number of round trips and latency. For example, if a client is reconnecting to a server, the client can send important encryption data with the very first packet, enabling the server to resurrect the old connection, using the same encryption as previously negotiated, without requiring any additional round trips.
 
Is it weird that I read "developed by Google" and have come to wonder what sort of way's they'll implant to track things in that? I know highly unlikely for technical reasons alone. But to me, that's all Google has become.
 
How is "supposed to minimize potential errors" better? Sounds like something that's only good for Google.
 
How will current modems and security handle the new protocol?
 
This is interesting and all, but since when is current http too slow? Every page I load always loads I mediately. There is no wait like back in the modem days...
 
Despite Google's AMP debacle, this is a much more reasonable change and provides the flexibility in connection types that web servers could have used for a long time.

However, I won't enable HTTP/3 across the board until the current gap in DTLS support matches the features of TLS 1.3. Those features weren't added for nothing, lol.
This is interesting and all, but since when is current http too slow? Every page I load always loads I mediately. There is no wait like back in the modem days...
The effect on the end user will barely change, but it's a huge difference for the server jamming pre-cached or concurrent requests down the pipe faster to multiple, similar-state clients. It's inline with this long-standing trend toward T H I C C client apps by pushing even more responsibility up to the application layer (both from server rendering and now the session model.)
 
I block http/https udp. Udp is inherently way less secure and harder to protect against as it is connectionless.

Edit: I'm going to backtrack on this one, udp is harder to SECURE than tcp.
 
Last edited:
Is it weird that I read "developed by Google" and have come to wonder what sort of way's they'll implant to track things in that? I know highly unlikely for technical reasons alone. But to me, that's all Google has become.

Given that Google is currently a partner with China and helping them develop better censorship and tracking tools?

Not weird at all. In fact, I'd be damn skeptical of anyone who WASN'T concerned...
 
How will current modems and security handle the new protocol?
Likely like any other UDP stream. The authentication will probably occur at the end-points, everything else should be the same.
 
Likely like any other UDP stream. The authentication will probably occur at the end-points, everything else should be the same.

No I've already given one example where things have to change. You have to open 80/443 udp.
 
No I've already given one example where things have to change. You have to open 80/443 udp.
That's a simple firewall/routing rule change. Consumer routers out of support would require manual configuration, everything else could be fixed with a new firmware or by pushing out new rules.
 
That's a simple firewall/routing rule change. Consumer routers out of support would require manual configuration, everything else could be fixed with a new firmware or by pushing out new rules.

AND the stock firewall on a lot of consumer firewalls will probably need to be re-written as out of the box, I have seen several that are STATEFULL. It's not as simple as you are making it out to be.
 
AND the stock firewall on a lot of consumer firewalls will probably need to be re-written as out of the box, I have seen several that are STATEFULL. It's not as simple as you are making it out to be.
In that case, the browser would likely use tcp for http instead. In any case, consumers will have to take action themselves if their routers don't automatically fetch and apply updates–either update/reconfigure their router themselves or buy a newer router that supports the protocol out of the box.
 
Just to clarify, quic will be a new rfc and the older ones will probably remain in place for compatibility. To take advantage of the quic speed, mods need to be made as mentioned.
 
How will current modems and security handle the new protocol?

Likely like any other UDP stream. The authentication will probably occur at the end-points, everything else should be the same.

No I've already given one example where things have to change. You have to open 80/443 udp.

Probably could have stated this more clearly earlier. What I meant was in the end it's just a UDP stream with some stuff added on the ends–it shouldn't require any special handling in that regard.

However, if your router firewall is configured to accept udp on the correct ports (unlikely by default), nothing else need be done on the router for quic to work. If it is not (set to reject, or accept/reject based on a state table), it will require reconfiguration or update for quic to work (but http/tcp will still work fine).
 
No I've already given one example where things have to change. You have to open 80/443 udp.

I think by default all consumer devices have their outgoing ports open. this is just literally shifting from the tcp protocol to the udp protocol, on the firewall side of things most companies would block certain ports (both tcp and udp) occasionally based on their security policies, this might be the case where some changes would be required. its just a another later of encapsulation sitting on top of UDP, I don't think there would big deal, and since they are planning to implement this is as http/3 im guessing if indeed the udp ports are unavailable then it would just fallback to tcp.

I'm still curious what is the definition of "slow" for the current tcp implementation that you would sacrifice reliability for a bit of performance.
 
Probably could have stated this more clearly earlier. What I meant was in the end it's just a UDP stream with some stuff added on the ends–it shouldn't require any special handling in that regard.

However, if your router firewall is configured to accept udp on the correct ports (unlikely by default), nothing else need be done on the router for quic to work. If it is not (set to reject, or accept/reject based on a state table), it will require reconfiguration or update for quic to work (but http/tcp will still work fine).

it is more than just an addition of udp protocol to tcp for http/s.. Quic actually includes an encryption layer of tls so The additional tls layer is not needed, among other things. You need a browser built for quic to use it. Which means chrome or opera. Again this is not just adding a udp port or 2.
 
Last edited:
I'm still curious what is the definition of "slow" for the current tcp implementation that you would sacrifice reliability for a bit of performance.

Not enough for a person to know, but Google's latest AI threatened to burn down their datacenter if they couldn't feed it information faster, so Google is trying to appease its new overlord. [/s]
 
AND the stock firewall on a lot of consumer firewalls will probably need to be re-written as out of the box, I have seen several that are STATEFULL. It's not as simple as you are making it out to be.

Are you trying to imply that current stateful firewalls just don't work with UDP traffic? Obviously they do, and this is just regular old UDP traffic just like any other UDP traffic so I don't see the issue here. Plus I'm sure there is a graceful fallback to older TCP based protocols built in.
 
Are you trying to imply that current stateful firewalls just don't work with UDP traffic? Obviously they do, and this is just regular old UDP traffic just like any other UDP traffic so I don't see the issue here. Plus I'm sure there is a graceful fallback to older TCP based protocols built in.

No,I did not imply whatever you are talking about but if you've ever used iptables, you specify the protocol.
 
How will current modems and security handle the new protocol?
They already do, I have been seeing it gradually increase in usage over the last 2 years, I was wondering what it was for the longest time and when I finally had time to research it I was really let down because it was so mundane and boring.
 
This is interesting and all, but since when is current http too slow? Every page I load always loads I mediately. There is no wait like back in the modem days...
The Ack/Nak process is very wasteful, there have been a number of advancements over the last number of years to remove it, mostly in the cell phone space to increase efficiency and decrease traffic collisions. It is proving to be very beneficial and it is one of the many ways that the protocall can be improved to reduce packet overhead.
 
If your router has SPI "Statefull packet inspection" then you shouldn't use quic, since the udp traffic will bypass the SPI. Which is looking at tcp 80/443 only.
 
Last edited:
Chrome has actually been using this protocol for a while. At work we kept seeing UDP/443 in wireshark and thinking it was some type of data exfiltration.
 
This is interesting and all, but since when is current http too slow? Every page I load always loads I mediately. There is no wait like back in the modem days...
The infrastructure to get content to you fast is ridiculous on a MASSIVE scale....and if this protocol alone is faster that can take a lot of over head out of the equation.
 
I phrased it wrong, edit above.

Statefull firewalls may have issues.
I see what you're getting at. I don't have enough relevant examples to support the point, but for a weak example: shaping is not really an option. However, if policy justifies the resources to audit state with purpose, the protocol performance is not in question of changing in the first place. :/ My example is bad and I feel bad.
Chrome has actually been using this protocol for a while. At work we kept seeing UDP/443 in wireshark and thinking it was some type of data exfiltration.
Yup. Chrome has been in testing since back in 2016, I believe. It's great for Google's needs (youtube and whatnot), but not that relevant for anything important. ;)
 
If your router has SPI "Statefull packet inspection" then you shouldn't use quic, since the udp traffic will bypass the SPI. Which is looking at tcp 80/443 only.
This is my concern.
The modem/router and local firewalls use SPI.
Question is how to block use of the protocol on a modem/router without impacting other services.
 
This is my concern.
The modem/router and local firewalls use SPI.
Question is how to block use of the protocol on a modem/router without impacting other services.

Block 80 443 udp source and destination ports or use chrome;//flags -> experimental quic -> disable in chrome
 
Block 80 443 udp source and destination ports or use chrome;//flags -> experimental quic -> disable in chrome
Of course, was forgetting TCP 80 can still pass, thanks.
 
it is more than just an addition of udp protocol to tcp for http/s.. Quic actually includes an encryption layer of tls so The additional tls layer is not needed, among other things. You need a browser built for quic to use it. Which means chrome or opera. Again this is not just adding a udp port or 2.
I wasn't talking about that, because he didn't ask about that.
 
I wasn't talking about that, because he didn't ask about that.

Seeing the posts here where everyone is saying quic is just the addition of a couple udp ports, I felt the need to mention it. There is additional application layer programming involved to implement the RFC.
 
In order to improve network latency, the next iteration of the Hypertext Transfer Protocol (HTTP) is switching from TCP (Transmission Control Protocol) to a protocol layered on top of UDP (User Datagram Protocol) called QUIC, or "Quick UDP Internet Connections." UDP is generally less reliable than TCP because it deals with unordered data, but QUIC, which was developed by Google, is supposed to minimize potential errors.

QUIC reinstates the reliability and ordering that TCP has but without introducing the same number of round trips and latency. For example, if a client is reconnecting to a server, the client can send important encryption data with the very first packet, enabling the server to resurrect the old connection, using the same encryption as previously negotiated, without requiring any additional round trips.

A missing UDP packet during a video stream will lead to block corruption. A missing UDP during gaming will cause movement & hit test glitches. But neither is fatal. A missing UDP with audio results in noise. The quality of the experience just drops, but it isn't fatal.

It will be interesting to see how google which navigates the issues with UDP. As there are MANY elements to a web page, I can see how it can be broken into multiple UDP packets. However, Rendering of div sections cannot be completed until all elements of the DOM tree are known. As each element on the DOM tree can have multiple dynamic sub DOM trees, it becomes a difficult process to render quickly when the rendering engine much recompose the entire page over and over. Guaranteeing order delivery helps reduce the number of redraws. Load the base page, load the CSS, read resource headers, load scripts, load actual resources, and starting the scripts are the generally accepted order. UDP doesn't guarantee order or that the packet will be delivered at all. So this creates issues with efficiency and reliability.
 
How will current modems and security handle the new protocol?

UDP and TCP is just a standard describing the data coming over the cable modem. It's like the header of jpg or bmp. The first bits of the file just describe the format of the data. Bits are bits to cable modems. What might be affected is routers and switches if it's a new protocol. But I imagine they will just use UDP data format and implement the new standard inside that.
 
A missing UDP packet during a video stream will lead to block corruption. A missing UDP during gaming will cause movement & hit test glitches. But neither is fatal. A missing UDP with audio results in noise. The quality of the experience just drops, but it isn't fatal.

It will be interesting to see how google which navigates the issues with UDP. As there are MANY elements to a web page, I can see how it can be broken into multiple UDP packets. However, Rendering of div sections cannot be completed until all elements of the DOM tree are known. As each element on the DOM tree can have multiple dynamic sub DOM trees, it becomes a difficult process to render quickly when the rendering engine much recompose the entire page over and over. Guaranteeing order delivery helps reduce the number of redraws. Load the base page, load the CSS, read resource headers, load scripts, load actual resources, and starting the scripts are the generally accepted order. UDP doesn't guarantee order or that the packet will be delivered at all. So this creates issues with efficiency and reliability.
Correct DOM flow design is a much clearer concept ever since the finalization of display:grid (early 2017), and rendering engines are much faster at reflows. And since UDP packets may provide unique identifiers and checksum for a series (so the client now knows at all times what it is waiting for, waiting patiently until it receives a certain percentage of the series before requesting a resend) , various components of an HTTP response can be sent as interleaved UDP series matching DOM reflow priority. A fun side effect to this is that page flow could be used to justify policy for when the server may ignore UDP resend requests. i.e. Don't respond to resend requests until a prerequisite series has been sent. Not that this is important, but just a neat way to look at it.

I think the best part about UDP based HTTP is that your IP addresses can change and it's business as usual. It allows for some DTN caching implementations that were previously ignored.
 
Back
Top