Http2 explained
daniel.haxx.se
Http2 explained
1–10 of 67 posts
Re: Http2 explained
#2I'm still not entirely sure why the problems inherent in single-stream connections (request/response) couldn't be solved simply by removing the artificial RFC-recommended limitation on parallel connections to a server. As the author says, providers have been escaping this limitation for years by simply adding hostname aliases, but has nothing negative to say about it.
Modern HTTP servers are highly concurrent; allowing 100 connections per request doesn't seem like a problem nowadays. And doing so would solve 99% of the browser performance problem without introducing a significantly more complicated multiplexing protocol.
Re: Http2 explained
#3"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection"
Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come back with explanations of why you might need Content-Length, a different issue.
Re: Http2 explained
#4I'm still not entirely sure why the problems inherent in single-stream connections (request/response) couldn't be solved simply by removing the artificial RFC-recommended limitation on parallel connections to a server. As the author says, providers have been escaping this limitation for years by simply adding hostname aliases, but has nothing negative to say about it. Modern HTTP servers are highly concurrent; allowi…
Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many moderately-sized or large resources (think images) will cost you many round trips you didn't need to spend.
Re: Http2 explained
#5"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come bac…
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection.
HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"
Re: Http2 explained
#6"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come bac…
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection. HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"
Ah, sorry, I misread your question! I don't actually know the lengthy reasoning for that edge case. =(
Re: Http2 explained
#7"Some of the bigger players in the HTTP field have been missing from the working group
discussions and meetings. I don't want to mention any particular company or product
names here, but clearly some actors on the Internet today seem to be confident that IETF
will do good without these companies being involved..."
I haven't been following this much, who is he referring to?
Re: Http2 explained
#8I'm still not entirely sure why the problems inherent in single-stream connections (request/response) couldn't be solved simply by removing the artificial RFC-recommended limitation on parallel connections to a server. As the author says, providers have been escaping this limitation for years by simply adding hostname aliases, but has nothing negative to say about it. Modern HTTP servers are highly concurrent; allowi…
Because running multiple TCP connections in parallel plays havoc with TCP congestion control and also plays poorly with the TCP slow-start logic. Every TCP connection begins its receive window again and so it starts small, so fetching many moderately-sized or large resources (think images) will cost you many round trips you didn't need to spend.
Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem fine for a client to open hundreds connections, but imagine being a server with thousands of clients all opening hundreds of connections to you. You very quickly run out of resources and either have to close connections or reject new connections.
Re: Http2 explained
#9"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come bac…
Sure. The only way to stop a message before the content-length is transmitted is to kill your TCP connection. This is inefficient: you need to recreate it, bearing all the TCP set-up cost all over again, and then deal with the small initial congestion window on your new connection. HTTP/2 allows you to avoid that by saying "I'm done with this stream now, sorry!"
How do web browsers handle cancelled requests? Subjectively speaking, it feels like browsers can take a while to recover from cancelling the loading of a large page/page with a large number of assets. Could this be part of that?
Re: Http2 explained
#10"Some of the bigger players in the HTTP field have been missing from the working group discussions and meetings. I don't want to mention any particular company or product names here, but clearly some actors on the Internet today seem to be confident that IETF will do good without these companies being involved..." I haven't been following this much, who is he referring to?
Probably Apple, there is another mention of them later on in the document.