4 ms·

> HTTP/3 isn't simple! It's a huge pain in the ass! Why would anyone want to do this to themselves on embedded‽ Why would anyone want to do it on desktop? Let

> HTTP/3 isn't simple! It's a huge pain in the ass! Why would anyone want to do this to themselves on embedded‽ Why would anyone want to do it on desktop? Let alone server-server APIs? HTTP 2 and 3 are spec monstrosities, which currently, effectively don't work. HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. HTTP 3 seems to be even slower in real world use. I strongly believe Google fudged its "real world trial data" to push W3C to adopt it.

slver 5y ago
Sometimes when you come up with a tidbit that the entire world of experience contradicts, it's healthy to stop and think "wait, am I full of shit?" Of course, you may not be full of shit, but let's say the odds are you are. What "real world data" you have to contradict Google's and basically everyone's personal experience? I have sites that are unbearable over HTTP/1.x and instant over HTTP/2. But maybe I was fooled by Google.
- mnahkies 5y ago
  I think QUICs design around handling network switches is a primary advantage. Devices are not static anymore and tolerating a switch from WiFi to mobile etc is a big plus
driverdan 5y ago
> HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. > > HTTP 3 seems to be even slower in real world use. [citation needed]
vitus 5y ago
> HTTP 2 and 3 are spec monstrosities A valid concern. > which currently, effectively don't work. Citation needed. > HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect -- head-of-line (HOL) blocking comes to mind, although since it still uses a single TCP connection, it's not a complete solution. It also provides header compression which can yield significant performance wins (bandwidth usage, latency if it reduces RTTs, CPU usage although this is always a mixed bag with compression). H3 solves the transport-layer HOL blocking issue, and has a number of other RTT-reducing features (e.g. removing the need for TCP 3-way handshake -> TLS handshake -> actual sending of requests by mandating the use of TLS, which admittedly can have performance impacts compared to, say, unencrypted HTTP/1.1). It does have a number of aspects which could negatively impact performance depending on your use case (e.g. userspace congestion control, always-on encryption). If you're dealing with small resources without HTTP pipelining where individual HTTP requests can and will complete in 1 RTT (and parallelization is limited because of dependencies between resources, e.g. a HTTP page contains an iframe which contains a js file which fetches an image), then your end-user latency will be dominated by the number of RTTs imposed by the underlying transport. And even if you include pipelining (assuming a non-buggy implementation, which inherently limits concurrency in order to reap its benefits), then you're still subject to HOL blocking, both request- and connection-level, which is problematic in moderate loss scenarios (wifi, mobile).
- KaiserPro 5y ago
  > H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect by multiplexing a many pseudo connections down one TCP pipe. I still don't quite understand how that was meant to improve performance over a lossy link. It seemed to me that Http2 was meant to be a file transfer protocol, but designed by people who don't really quite understand how TCP performs in the real world (especially on mobile)
  - baybal2 5y ago
    > It seemed to me that Http2 was meant to be a file transfer protocol, but designed by people who don't really quite understand how TCP performs in the real world (especially on mobile) And not only mobile, same applies for server-server connections over near perfect, inter-dc connections. Even gigabit, and above links drop packets... because it's how TCP is supposed to work! The higher is the speed, the more aggressive curve will be used by the congestion control algorithm. In other words it will hit drops fast, be in the drop zone for longer, and this will be recurring more frequently than on slower links. In fact, faster congestion protocols for speeds above 500 mbps get their speed by having A LOT MORE drops, not less. Any protocol designed for the TCP transport must have been designed to work in concert TCP mechanics, not fight, or try to workaround it. This is a perfect example of how AB test vodoo lead people down the rabbit hole.
    - moltenguardian 5y ago
      > Any protocol designed for the TCP transport must have been designed to work in concert TCP mechanics, not fight, or try to workaround it. There is a reality of running code on other peoples hardware: they impose limitations on network traffic that you cannot change. Example: Home-grade routers do NAT, but have table limitations which make it hard to have multiple connections. The connections get dropped, and users complain, not realizing it was due to them having bought a cheap router. Other actors in the network path between the client and the server impose their own limitations, making it hard to have multiple connections. (corporate firewalls being another big one). HTTP/2 is a compromise, admitting that it is not possible to go fix or replace all this hardware. I worked on a few HTTP/2 implementations, and the complexity it incurs is significantly less than the alternatives.
kstrauser 5y ago
I think the disconnect between your experience and others’ may involve the complexity of the sites you’re talking about. If you have a simple site that has a few images, HTTP 1 may be nearly equal to HTTP 2/3. If you have a complex site with a lot of resources, and your server software allows you to push resources you know the client will need before the client even gets around to asking for them, HTTP 2/3 can be a clear winner.
- kilburn 5y ago
  I think you are speaking about HTTP push, which has been abandoned [1] (also discussed in HN [2]). [1] https://evertpot.com/http-2-push-is-dead/ https://evertpot.com/http-2-push-is-dead/ [2] https://news.ycombinator.com/item?id=25283971 https://news.ycombinator.com/item?id=25283971
  - jlokier 5y ago
    No, it's not Push. As a practical matter if your page requires a large number of resources (say 50+), and you are measuring the time to complete loading all of them, HTTP/2 loads much faster than HTTP/1.1. There are some nice demo sites which show this, with pages full of small images. This is because all requests can be issued in parallel over HTTP/2 as soon as the client knows what to request, and this reduces the number of round trip times before all resources complete loading. Even without Push, the client usually knows all the requests after it receives the HTML or sometimes the CSS. With HTTP/1.1, the client requests are bottlenecked in a queue limited by the number of parallel TCP+TLS connections. Some sites boost this limit by using extra subdomains. But running 50+ TCP connections bursting at the same time is not efficient, even if it does bring down the latency by parallelising. With that many, there will be a burst of congestion and possible packet loss at the low bandwidth receiving end. And the 3-way handshake and TLS handshake needed for each new TCP+TLS means the parallel request latencies are a multiple of HTTP/2 request latency. HTTP/2 also has request header compression, which makes a difference when upstream bandwidth from the client is limited.

slver 5y ago

Sometimes when you come up with a tidbit that the entire world of experience contradicts, it's healthy to stop and think "wait, am I full of shit?" Of course, you may not be full of shit, but let's say the odds are you are. What "real world data" you have to contradict Google's and basically everyone's personal experience? I have sites that are unbearable over HTTP/1.x and instant over HTTP/2. But maybe I was fooled by Google.

mnahkies 5y ago
I think QUICs design around handling network switches is a primary advantage. Devices are not static anymore and tolerating a switch from WiFi to mobile etc is a big plus

driverdan 5y ago

> HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. > > HTTP 3 seems to be even slower in real world use. [citation needed]

vitus 5y ago

> HTTP 2 and 3 are spec monstrosities A valid concern. > which currently, effectively don't work. Citation needed. > HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect -- head-of-line (HOL) blocking comes to mind, although since it still uses a single TCP connection, it's not a complete solution. It also provides header compression which can yield significant performance wins (bandwidth usage, latency if it reduces RTTs, CPU usage although this is always a mixed bag with compression). H3 solves the transport-layer HOL blocking issue, and has a number of other RTT-reducing features (e.g. removing the need for TCP 3-way handshake -> TLS handshake -> actual sending of requests by mandating the use of TLS, which admittedly can have performance impacts compared to, say, unencrypted HTTP/1.1). It does have a number of aspects which could negatively impact performance depending on your use case (e.g. userspace congestion control, always-on encryption). If you're dealing with small resources without HTTP pipelining where individual HTTP requests can and will complete in 1 RTT (and parallelization is limited because of dependencies between resources, e.g. a HTTP page contains an iframe which contains a js file which fetches an image), then your end-user latency will be dominated by the number of RTTs imposed by the underlying transport. And even if you include pipelining (assuming a non-buggy implementation, which inherently limits concurrency in order to reap its benefits), then you're still subject to HOL blocking, both request- and connection-level, which is problematic in moderate loss scenarios (wifi, mobile).

KaiserPro 5y ago
> H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect by multiplexing a many pseudo connections down one TCP pipe. I still don't quite understand how that was meant to improve performance over a lossy link. It seemed to me that Http2 was meant to be a file transfer protocol, but designed by people who don't really quite understand how TCP performs in the real world (especially on mobile)
- baybal2 5y ago
  > It seemed to me that Http2 was meant to be a file transfer protocol, but designed by people who don't really quite understand how TCP performs in the real world (especially on mobile) And not only mobile, same applies for server-server connections over near perfect, inter-dc connections. Even gigabit, and above links drop packets... because it's how TCP is supposed to work! The higher is the speed, the more aggressive curve will be used by the congestion control algorithm. In other words it will hit drops fast, be in the drop zone for longer, and this will be recurring more frequently than on slower links. In fact, faster congestion protocols for speeds above 500 mbps get their speed by having A LOT MORE drops, not less. Any protocol designed for the TCP transport must have been designed to work in concert TCP mechanics, not fight, or try to workaround it. This is a perfect example of how AB test vodoo lead people down the rabbit hole.
  - moltenguardian 5y ago
    > Any protocol designed for the TCP transport must have been designed to work in concert TCP mechanics, not fight, or try to workaround it. There is a reality of running code on other peoples hardware: they impose limitations on network traffic that you cannot change. Example: Home-grade routers do NAT, but have table limitations which make it hard to have multiple connections. The connections get dropped, and users complain, not realizing it was due to them having bought a cheap router. Other actors in the network path between the client and the server impose their own limitations, making it hard to have multiple connections. (corporate firewalls being another big one). HTTP/2 is a compromise, admitting that it is not possible to go fix or replace all this hardware. I worked on a few HTTP/2 implementations, and the complexity it incurs is significantly less than the alternatives.

kstrauser 5y ago

I think the disconnect between your experience and others’ may involve the complexity of the sites you’re talking about. If you have a simple site that has a few images, HTTP 1 may be nearly equal to HTTP 2/3. If you have a complex site with a lot of resources, and your server software allows you to push resources you know the client will need before the client even gets around to asking for them, HTTP 2/3 can be a clear winner.

kilburn 5y ago
I think you are speaking about HTTP push, which has been abandoned [1] (also discussed in HN [2]). [1] https://evertpot.com/http-2-push-is-dead/ https://evertpot.com/http-2-push-is-dead/ [2] https://news.ycombinator.com/item?id=25283971 https://news.ycombinator.com/item?id=25283971
- jlokier 5y ago
  No, it's not Push. As a practical matter if your page requires a large number of resources (say 50+), and you are measuring the time to complete loading all of them, HTTP/2 loads much faster than HTTP/1.1. There are some nice demo sites which show this, with pages full of small images. This is because all requests can be issued in parallel over HTTP/2 as soon as the client knows what to request, and this reduces the number of round trip times before all resources complete loading. Even without Push, the client usually knows all the requests after it receives the HTML or sometimes the CSS. With HTTP/1.1, the client requests are bottlenecked in a queue limited by the number of parallel TCP+TLS connections. Some sites boost this limit by using extra subdomains. But running 50+ TCP connections bursting at the same time is not efficient, even if it does bring down the latency by parallelising. With that many, there will be a burst of congestion and possible packet loss at the low bandwidth receiving end. And the 3-way handshake and TLS handshake needed for each new TCP+TLS means the parallel request latencies are a multiple of HTTP/2 request latency. HTTP/2 also has request header compression, which makes a difference when upstream bandwidth from the client is limited.