3 ms·

Also: >TLS 1.2 was used for HTTP/1.1 and HTTP/2 >TLS 1.3 was used for HTTP/3.

by nix23 5y ago

tialaramex 5y ago
The latter is obligatory. HTTP/3 is a way of spelling the HTTP protocol over QUIC, and QUIC is implicitly doing TLS 1.3 (or later) cryptography. So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?
- tsimionescu 5y ago
  > HTTP/3 is a way of spelling the HTTP protocol over QUIC HTTP/3 could perhaps be described as HTTP/2 over QUIC. It's still a very different protocol from HTTP/1.1, even if you were to ignore the transport being used - the way connections are managed is entirely different.
  - tialaramex 5y ago
    It's just spelling. It certainly wouldn't be better to think of it as HTTP/2 over QUIC since it works quite differently because it doesn't have an in-order protocol underneath it. HTTP has a bunch of semantics independent of how it's spelled and HTTP/3 preserves those with a new spelling and better performance
- nix23 5y ago
  >So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack? Because it's a benchmark of HTTP3 and not a comparison of "as it might be stacks". It would a bit like bench-marking HTTP/1 with RHEL7 and Apache2, HTTP/2 with RHEL8 and NGINX and HTTP/3 with...let's say Alpine and Caddy...it's just not a clean benchmark if you mix more then one component and try to proof that this single one component is faster.
  - tialaramex 5y ago
    Good point. So TLS 1.3 everywhere would have been better
    - nix23 5y ago
      Well yes if it's a benchmark ;)
    - bawolff 5y ago
      Especially when their benchmark scenario is something that plays to the strengths of tls1.3 and would probably only mildly be improved (if at all) by http/3
- dochtman 5y ago
  QUIC does require TLS 1.3, but as far as I can tell HTTP/2 over TLS 1.3 is perfectly viable, and is likely a common deployment scenario. Upgrading just TLS to 1.3 for most people likely just means upgrading to a newer openssl which you probably want to do anyway. In many web server deployment scenarios, deploying HTTP/3 is highly likely to be more involved. The Apache httpd doesn't support H3 at all, I don't know if nginx has it enabled by default these days?
  - lazerl0rd 5y ago
    NGINX has an experimental QUIC branch [1], but in my experience it is buggy and currently has lower throughput than using Quiche [2] with NGINX. I do the latter for my fork of NGINX called Zestginx [3], which supports HTTP/3 amongst a bunch of other features. NGINX's QUIC implementation seems to also lack support for QUIC and or HTTP/3 features (such as Adaptive Reordering Thresholds and marking large frames instead of closing the connection). [1] : https://hg.nginx.org/nginx-quic https://hg.nginx.org/nginx-quic [2] : https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche [3] : https://github.com/ZestProjects/Zestginx https://github.com/ZestProjects/Zestginx EDIT: A friend of mine who works at VK ("the Russian Facebook") informed me that they're helping out with the NGINX QUIC implementation which is nice to hear, as having a company backing such work does solidify the route a little.

Also: >TLS 1.2 was used for HTTP/1.1 and HTTP/2 >TLS 1.3 was used for HTTP/3.

by nix23 5y ago

Also: >TLS 1.2 was used for HTTP/1.1 and HTTP/2 >TLS 1.3 was used for HTTP/3.

The latter is obligatory. HTTP/3 is a way of spelling the HTTP protocol over QUIC, and QUIC is implicitly doing TLS 1.3 (or later) cryptography. So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?

tsimionescu 5y ago
> HTTP/3 is a way of spelling the HTTP protocol over QUIC HTTP/3 could perhaps be described as HTTP/2 over QUIC. It's still a very different protocol from HTTP/1.1, even if you were to ignore the transport being used - the way connections are managed is entirely different.
- tialaramex 5y ago
  It's just spelling. It certainly wouldn't be better to think of it as HTTP/2 over QUIC since it works quite differently because it doesn't have an in-order protocol underneath it. HTTP has a bunch of semantics independent of how it's spelled and HTTP/3 preserves those with a new spelling and better performance
nix23 5y ago
>So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack? Because it's a benchmark of HTTP3 and not a comparison of "as it might be stacks". It would a bit like bench-marking HTTP/1 with RHEL7 and Apache2, HTTP/2 with RHEL8 and NGINX and HTTP/3 with...let's say Alpine and Caddy...it's just not a clean benchmark if you mix more then one component and try to proof that this single one component is faster.
- tialaramex 5y ago
  Good point. So TLS 1.3 everywhere would have been better
  - nix23 5y ago
    Well yes if it's a benchmark ;)
  - bawolff 5y ago
    Especially when their benchmark scenario is something that plays to the strengths of tls1.3 and would probably only mildly be improved (if at all) by http/3
dochtman 5y ago
QUIC does require TLS 1.3, but as far as I can tell HTTP/2 over TLS 1.3 is perfectly viable, and is likely a common deployment scenario. Upgrading just TLS to 1.3 for most people likely just means upgrading to a newer openssl which you probably want to do anyway. In many web server deployment scenarios, deploying HTTP/3 is highly likely to be more involved. The Apache httpd doesn't support H3 at all, I don't know if nginx has it enabled by default these days?
- lazerl0rd 5y ago
  NGINX has an experimental QUIC branch [1], but in my experience it is buggy and currently has lower throughput than using Quiche [2] with NGINX. I do the latter for my fork of NGINX called Zestginx [3], which supports HTTP/3 amongst a bunch of other features. NGINX's QUIC implementation seems to also lack support for QUIC and or HTTP/3 features (such as Adaptive Reordering Thresholds and marking large frames instead of closing the connection). [1] : https://hg.nginx.org/nginx-quic https://hg.nginx.org/nginx-quic [2] : https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche [3] : https://github.com/ZestProjects/Zestginx https://github.com/ZestProjects/Zestginx EDIT: A friend of mine who works at VK ("the Russian Facebook") informed me that they're helping out with the NGINX QUIC implementation which is nice to hear, as having a company backing such work does solidify the route a little.