3 ms·
HTTP/1.1 is far easier to implement, thus it is reasonable to assume it should contain fewer bugs. HTTP/2 (and HTTP/3) is vastly different in features (added m
by nirui 3y ago
HTTP/1.1 is far easier to implement, thus it is reasonable to assume it should contain fewer bugs.
HTTP/2 (and HTTP/3) is vastly different in features (added multiplexing, windowing, HPACK etc). All this transforms a largely stateless connection (in the HTTP/1.1 case) to a stateful one. And in order to maintain the stateful connection, you need to store some data (state, configuration etc), thus all these problems.
Also, in HTTP/2, since multiplexing is added, the protection characteristics are different. For example, if the connections were generated by CDN source draws, you may just allow fewer number of connections each with a large pool of multiplex channels, but if the connections were from direct user access, you may then want to allow large number of connections, but each with fewer number of multiplex channels. In HTTP/1, protection is much simpler, since everybody looked almost the same.
- RenThraysk 2y agoFortunately, continuation frames don't exist in HTTP/3.
- nirui 2y agoQUIC protocol itself is certainly sophisticated, but implementing it might be a different story. I'm still skeptical about the overall "safety"/protection of HTTP/3. A QUIC UDP server is definitely going to need to store state data to maintain a connection/session, and now you also have the good old UDP security (packet flood protection etc) mixed in. I guess time will tell.
- nirui 2y agoCorrection: statement "reasonable to assume it should contain fewer bugs" is not true. The correct idea is "it should be is easier to implement HTTP/1.1 server safely because HTTP/1.1 is a simpler protocol compare to HTTP/2".