| > it solved another kind of blocking on the protocol level Indeed! and it works well on low latency, low packet loss networks. On high packet loss networks, it performs worse than HTTP1.1. Moreover it gets increasingly worse the larger the page the request is serving. We pointed this out at the time, but were told that we didn't understand the web. > H/1 pipelining was unusable, Yup, but think how easy it would be to create http1.2 with better spec for pipe-lining. (but then why not make changes to other bits as well, soon we get HTTP2!) But of course pipelining only really works in a low packet loss network, because you get head of line blocking. > open a dozen separate H/1 connections, but that multiplied setup cost Indeed, that SSL upgrade is a pain in the arse. But connections are cheap to keep open. So with persistent connections and pooling its possible to really nail down the latency. Personally, I think the biggest problem with HTTP is that its a file access protocol, a state interchange protocol and an authentication system. I would tentatively suggest that we adopt websockets to do state (with some extra features like optional schema sharing {yes I know thats a bit of enanthema}) Make http4 a proper file sharing prototcol and have a third system for authentication token generation, sharing and validation. However the real world says that'll never work. So connection pooling over TCP with quick start TLS would be my way forward. |
HTTP is a state interchange protocol. It's not any of the other things you mention.