5 ms·

That's a long post, and I will not comment on all of it. However some very short thoughts: HTTP/3 has nothing to do with protocol buffers. Yes, it uses a binar

That's a long post, and I will not comment on all of it. However some very short thoughts: HTTP/3 has nothing to do with protocol buffers. Yes, it uses a binary encoding for request headers on top of QUIC streams. And those QUIC streams use another binary encoding to get QUIC frame data into UDP datagrams. But neither of those are using protocol buffers. If a user uses HTTP/3 in the end (most likely through a library), they can store anything in the request response bodies - whether its binary data or just text data. Multiplexing and binary encoding already exist in a HTTP/1.1 stack. The main difference is that it happens on the kernel level (it multiplexes IP datagrams in the end, and associates them with sockets). The main difference with QUIC is that this multiplexing layer now lives in application space. But since most users are not going to write their own library, they will rely on someone else to get that layer right. Either they want to have a solid kernel plus a solid TLS library on top, or they want a solid QUIC library. There is obviously a risk related to introducing anything new into a system, but once things mature it's not that different anymore. Once users have a QUIC library, APIs don't really have to be harder than for handling HTTP/1.1 requests. One can easily offer blocking send() and receive() APIs to interact with request bodies, the encoding and multiplexing doesn't have to leak into application code.

mleonhard 6y ago
> HTTP/3 has nothing to do with protocol buffers. I don't know why I thought it was protocol buffers. I see now that it's a TLV protocol. I think that is worse, since it requires custom binary parsers. > Multiplexing and binary encoding already exist in a HTTP/1.1 stack. This is disingenuous. The majority of code supporting HTTP/1.1 is in text processing. Binary encoding only happens while transfer encoding bodies. TCP is multiplexed over IP, but very few engineers ever think about that because our tools deal with TCP connections.
- slver 6y ago
  I don't know why you seem to completely disregard the idea of libraries and abstractions outside the OS kernel. Your HTTP library can hide the complexity of HTTP/3 from you and give you HTTP/1.1 style streams to deal with, WITHOUT being part of the OS. Said engineers won't have to learn or do anything, just update their dependencies.
  - mleonhard 6y ago
    I need to understand the technology my systems depend on so I can solve problems. I accept complexity when it is necessary or when it brings strong benefits. Things that are necessary complexity: JPEG libraries, database engines, Rust's borrowing rules, and TLS (only because no straightforward alternative exists). Why is the extra complexity of HTTP/3 necessary?
    - slver 6y ago
      You don't need to understand every implementation detail of a technology to solve problems, you need to understand the abstraction it exposes. In this case HTTP/2 and HTTP/3 expose the same abstraction that HTTP/1.1 exposes. The only thing you need to know is that the cost each request/response is much smaller then before, so you can make more of them with less overhead. That's it. Without abstraction this world is so complex, we wouldn't be able to get out of bed in the morning and put our pants on.

mleonhard 6y ago

> HTTP/3 has nothing to do with protocol buffers. I don't know why I thought it was protocol buffers. I see now that it's a TLV protocol. I think that is worse, since it requires custom binary parsers. > Multiplexing and binary encoding already exist in a HTTP/1.1 stack. This is disingenuous. The majority of code supporting HTTP/1.1 is in text processing. Binary encoding only happens while transfer encoding bodies. TCP is multiplexed over IP, but very few engineers ever think about that because our tools deal with TCP connections.

slver 6y ago
I don't know why you seem to completely disregard the idea of libraries and abstractions outside the OS kernel. Your HTTP library can hide the complexity of HTTP/3 from you and give you HTTP/1.1 style streams to deal with, WITHOUT being part of the OS. Said engineers won't have to learn or do anything, just update their dependencies.
- mleonhard 6y ago
  I need to understand the technology my systems depend on so I can solve problems. I accept complexity when it is necessary or when it brings strong benefits. Things that are necessary complexity: JPEG libraries, database engines, Rust's borrowing rules, and TLS (only because no straightforward alternative exists). Why is the extra complexity of HTTP/3 necessary?
  - slver 6y ago
    You don't need to understand every implementation detail of a technology to solve problems, you need to understand the abstraction it exposes. In this case HTTP/2 and HTTP/3 expose the same abstraction that HTTP/1.1 exposes. The only thing you need to know is that the cost each request/response is much smaller then before, so you can make more of them with less overhead. That's it. Without abstraction this world is so complex, we wouldn't be able to get out of bed in the morning and put our pants on.