4 ms·

How we get here? By pushing the previous protocol to the limit, observing where it breaks down, and fixing those things. We could even predict what will rep

How we get here? By pushing the previous protocol to the limit, observing where it breaks down, and fixing those things. We could even predict what will replace HTTP/2 by looking at where it starts to break down. I work with HTTP/2 daily, and there are some pain points when running at high speeds: - Headers are still head of line blocking. You must synchronize sending them to maintain the HPACK table state. At a high number of requests per second, this is a bottle neck - Running over TLS is CPU bottleneck since encrypted messages are sequential. We get around this by making multiple TCP connections. - Long lived HTTP/2 connections will often break because of NAT's (home internet), or changing IP address (mobile). A single dropped packet kills throughput for highspeed links too. All of these are addressed by the QUIC protocol. I suspect that eventually HTTP/2 will be last major protocol over TCP because of most of the aforementioned problems come from running over it.

the8472 10y ago
> Running over TLS is CPU bottleneck since encrypted messages are sequential. ChaCha20 takes around 4cycles/byte on a xeon. At 3GHz that's 750MB/s. Or about a 10Gbit pipe fed with a single core, i.e. without any need for parallelization.
- rdtsc 10y ago
  Is that running in a loop or mixed in a larger application context where cache lines might be flushed and replaced by others. That often make a things behave very differently when running in small benchmarks vs production.
  - the8472 10y ago
    Small message sizes don't seem to slow it down much according to DJB's paper[0]. It doesn't use large s-boxes or a lot of other internal state, unlike AES does. Its cache footprint is fairly small. [0] https://cr.yp.to/snuffle/salsafamily-20071225.pdf#2 https://cr.yp.to/snuffle/salsafamily-20071225.pdf#2 (page 2)
niftich 10y ago
> Running over TLS is CPU bottleneck since encrypted messages are sequential. Does TLS off-loading help in this case? > Headers are still head of line blocking. You must synchronize sending them to maintain the HPACK table state Is this still an issue if you only use the static table, and send any other namevalue-pairs as either dynamic non-indexed [1] or more likely, dynamic never-indexed [2]? [1] https://http2.github.io/http2-spec/compression.html#literal.header.without.indexing https://http2.github.io/http2-spec/compression.html#literal.... [2] https://http2.github.io/http2-spec/compression.html#literal.header.never.indexed https://http2.github.io/http2-spec/compression.html#literal....
yeukhon 10y ago
The TLS one, is that specific to HTTP/2, or TLS in general? That's a important distinction. NAT one is interesting though.
cm2187 10y ago
SMTP is way beyond its limit and I see no good replacement in sight.
bsdetector 10y ago
Exactly! One of the big pain points in HTTP/1.1 is that you don't know who the client is. You get six or more connections at a time, so you have to correlate them together using cookies or other ids. It's easy to proxy and cache so you don't know if it's a single person on the other end or many people. Since there are so many connections they close in a minute or less so you have figure out which connections are the same user from earlier. Now with HTTP/2 there's only one connection and it stays open for a long time so that connection info can be used to identify a client session. It's TLS only so much less likely to be a proxy, since the proxy needs a trusted certificate added to the browser. And also connections to a third-party domain are shared across all pages, so if you are doubleclick.net you know the same user is browsing different sites. The new protocol makes tracking users much easier and fixes a huge privacy problem in HTTP/1.1.

the8472 10y ago

> Running over TLS is CPU bottleneck since encrypted messages are sequential. ChaCha20 takes around 4cycles/byte on a xeon. At 3GHz that's 750MB/s. Or about a 10Gbit pipe fed with a single core, i.e. without any need for parallelization.

rdtsc 10y ago
Is that running in a loop or mixed in a larger application context where cache lines might be flushed and replaced by others. That often make a things behave very differently when running in small benchmarks vs production.
- the8472 10y ago
  Small message sizes don't seem to slow it down much according to DJB's paper[0]. It doesn't use large s-boxes or a lot of other internal state, unlike AES does. Its cache footprint is fairly small. [0] https://cr.yp.to/snuffle/salsafamily-20071225.pdf#2 https://cr.yp.to/snuffle/salsafamily-20071225.pdf#2 (page 2)

niftich 10y ago

> Running over TLS is CPU bottleneck since encrypted messages are sequential. Does TLS off-loading help in this case? > Headers are still head of line blocking. You must synchronize sending them to maintain the HPACK table state Is this still an issue if you only use the static table, and send any other namevalue-pairs as either dynamic non-indexed [1] or more likely, dynamic never-indexed [2]? [1] https://http2.github.io/http2-spec/compression.html#literal.header.without.indexing https://http2.github.io/http2-spec/compression.html#literal.... [2] https://http2.github.io/http2-spec/compression.html#literal.header.never.indexed https://http2.github.io/http2-spec/compression.html#literal....

yeukhon 10y ago

The TLS one, is that specific to HTTP/2, or TLS in general? That's a important distinction. NAT one is interesting though.

cm2187 10y ago

SMTP is way beyond its limit and I see no good replacement in sight.

bsdetector 10y ago

Exactly! One of the big pain points in HTTP/1.1 is that you don't know who the client is. You get six or more connections at a time, so you have to correlate them together using cookies or other ids. It's easy to proxy and cache so you don't know if it's a single person on the other end or many people. Since there are so many connections they close in a minute or less so you have figure out which connections are the same user from earlier. Now with HTTP/2 there's only one connection and it stays open for a long time so that connection info can be used to identify a client session. It's TLS only so much less likely to be a proxy, since the proxy needs a trusted certificate added to the browser. And also connections to a third-party domain are shared across all pages, so if you are doubleclick.net you know the same user is browsing different sites. The new protocol makes tracking users much easier and fixes a huge privacy problem in HTTP/1.1.