The best practices of HTTP1 are harmful in a HTTP2 world • Hacker News Board

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#11

Post by currysausage » Tue, Mar 03, 2015, 9:46 PM UTC

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster.

Also, an HTTP/1.1 server, when configured properly, will use compression as well.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#12

Post by joshstrange » Tue, Mar 03, 2015, 10:00 PM UTC

molf wrote: post #8

This article makes too many assumptions for my taste. Some other considerations that spring to mind: - A sprite tends to have fewer bytes than separate images, because of image format overhead and better compression when combining similar things. - The same may be true for zipped CSS/JS. - What about CSS/JS/image parsing overhead? - Even though HTTP2's request overhead is substantially less than HTTP1, fewer HTTP req…

Agreed, as someone who has done a significant amount of work to sprite our images and concat our js/css files this title, and most the content, scared me. The only thing I haven't pushed through is different domains for static assets (though I have them cached for a year with a query string as a cache-buster for when we deploy new js/css). None of this, in a HTTP2 context, seems like it would be extremely, or at all for that matter, harmful. Furthermore with our aggressive caching the request only needs to be made a single time (assuming the user hasn't cleared their cache).

I welcome HTTP2 but I'm not too sure on the timeline for rollout and if it will end up being an "IE6"-type thorn in my side. Even if we are split 50-50 between HTTP1 and HTTP2 it sounds like the best approach is keep doing what you are doing... Either way I don't think sprites/concating/minifying is going anywhere anytime soon.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#13

Post by pmontra » Tue, Mar 03, 2015, 10:13 PM UTC

teraflop wrote: post #6

pmontra wrote: post #3

I expect to have to support HTTP for a long time on my sites but it would be nice to start using HTTP2 with browsers that can handle it. I can see two problems: 1) How can they coexist on the same server? I googled a little but maybe with the wrong keywords. I found this but it's pretty shallow on details http://nginx.com/blog/how-nginx-plans-to-support-http2/ 2) I still want to serve HTTP1 optimized content to HTTP1…

> how can they coexist on the same server? At the protocol level, this is covered by section 3 of the HTTP/2 spec: http://http2.github.io/http2-spec/index.html#starting For https:// URIs, the client and server agree on which version to use as part of the TLS negotiation. For http:// URIs, major browsers won't be using HTTP/2 at all, but if they did, the spec defines a mechanism similar to websockets: the client makes…

Thanks

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#14

Post by sargun » Tue, Mar 03, 2015, 10:21 PM UTC

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

RE: The last one

QUIC is a solution for that - It's Google's answer to TCP, and dealing with multiplexed connections. I recommend taking a look.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#15

Post by jomohke » Tue, Mar 03, 2015, 10:24 PM UTC

currysausage wrote: post #11

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. Also, an HTTP/1.1 server, when configured properly, will use compression as well.

It does support compression of the message body, but not of the headers.

They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html

In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#16

Post by fideloper » Tue, Mar 03, 2015, 10:27 PM UTC

currysausage wrote: post #11

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. Also, an HTTP/1.1 server, when configured properly, will use compression as well.

The body, but not the headers, right?

Does http2 also compress headers?

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#17

Post by treve » Tue, Mar 03, 2015, 10:28 PM UTC

lispm wrote: post #10

> It can leave the connection open for re-use for very extended periods of time, so there's no need for that costly handshake that HTTP1 requires for every request. HTTP1 supports pipelining requests. > HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. 'significantly'? How much is that? > HTTP2 multiplexes; it can send and receive multiple things at…

HTTP 1.1 supports pipelining requests but in reality it's disabled everywhere.

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#18

Post by treve » Tue, Mar 03, 2015, 10:29 PM UTC

fideloper wrote: post #16

currysausage wrote: post #11

Earlier quoted context omitted.

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. Also, an HTTP/1.1 server, when configured properly, will use compression as well.

The body, but not the headers, right? Does http2 also compress headers?

It does

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#19

Post by Illniyar » Tue, Mar 03, 2015, 10:32 PM UTC

jomohke wrote: post #15

currysausage wrote: post #11

Earlier quoted context omitted.

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster. Also, an HTTP/1.1 server, when configured properly, will use compression as well.

It does support compression of the message body, but not of the headers. They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

Re: The best practices of HTTP1 are harmful in a HTTP2 world

#20

Post by treve » Tue, Mar 03, 2015, 10:33 PM UTC

joshstrange wrote: post #12

molf wrote: post #8

This article makes too many assumptions for my taste. Some other considerations that spring to mind: - A sprite tends to have fewer bytes than separate images, because of image format overhead and better compression when combining similar things. - The same may be true for zipped CSS/JS. - What about CSS/JS/image parsing overhead? - Even though HTTP2's request overhead is substantially less than HTTP1, fewer HTTP req…

Agreed, as someone who has done a significant amount of work to sprite our images and concat our js/css files this title, and most the content, scared me. The only thing I haven't pushed through is different domains for static assets (though I have them cached for a year with a query string as a cache-buster for when we deploy new js/css). None of this, in a HTTP2 context, seems like it would be extremely, or at all…

I think if there's a significant enough uptake on HTTP/2, we may get to a point where we start feeling that it's not worth optimizing for HTTP/1.1 anymore. Obviously HTTP/1.1 will still just work, but the HTTP/2 approach _can_ potentially work much more elegantly, when all the tooling is in place, and I definitely believe it will be preferable.

I agree that the existing approaches are very much valid though, but I also look forward to not having to concatenate javascript files anymore. We've developed a lot of tooling to work around issues that stem from that, and it doesn't address the problem of needing a varying set of javascript files on a per-page basis easily.