3 ms·
> 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 wor
by 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 agoI 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 agoI 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 agoYou 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.