2 ms·

Anybody got a good summary of HTTP2 features (which I know could be described as "everythign plus the kitchen sink")?

by Pxtl 12y ago

shurcooL 12y ago
It's mostly more efficient (in terms of average latency, speed and total bandwidth). Kinda like BMP format to PNG format (with compression and alpha channels). Yes, BMP is a lot simpler and you can find out the RGB of any pixel by looking at pixels[y*width+x] while with PNG you have non-trivial complexity with compression, etc. But the size efficiency is worthwhile.
- pdkl95 12y ago
  This analogy exaggerates the bandwidth savings. Converting from uncompressed BMP to compressed PNG can easily save over half of the file size; even 10:1 compression is common for some images. The bandwidth savings in HTTP2 are much smaller, and are probably only significant in aggregate.
  - stephen_g 12y ago
    True - the bandwidth savings aren't huge. What you do get with HTTP/2 is the ability to use bandwidth a lot more efficiently. Because of TCP's congestion control, such as slow-start, doin a different TCP connection for each file, as HTTP/1.1 does, is actually a fairly terribly inefficient for transferring small files. One way that web developers have tried to get around this is to combine resources together - such as having huge combined javascript and CSS files, and big sprite sheet images. But this messes up caching - if I change a 20KB source file that is part of a half meg combined JS file, then you have to redownload the entire file. Another problem is that you're limited to how many HTTP requests the browser will make to a single domain at once, so you have to wait around for files to finish before others will download. You can try sharding the files across different subdomains but it's a suboptimal solution. The multiplexing in HTTP/2 solves these problems. You can send a bunch of files at once in one connection without repeating the (necessary) slowness of TCP slow start for every file, and the browser realises that they're different, so can cache them separately. This can translate into noticeably faster page load times.
ubernostrum 12y ago
Web development in 2014 consists of using four dozen CSS files, two hundred JavaScript files, and upwards of 750 HTTP requests to an API in order to display a single blog post. It is unthinkable to impose any sort of discipline on the use of resources by developers, even at companies which theoretically have an incentive to be efficient. As a result, those companies have banded together to produce a bloated, multiplexed blob-fish of a protocol which they have vomited into the standards body for fast approval, over the objections of the people who will actually have to implement it.

Anybody got a good summary of HTTP2 features (which I know could be described as "everythign plus the kitchen sink")?

by Pxtl 12y ago

Anybody got a good summary of HTTP2 features (which I know could be described as "everythign plus the kitchen sink")?

It's mostly more efficient (in terms of average latency, speed and total bandwidth). Kinda like BMP format to PNG format (with compression and alpha channels). Yes, BMP is a lot simpler and you can find out the RGB of any pixel by looking at pixels[y*width+x] while with PNG you have non-trivial complexity with compression, etc. But the size efficiency is worthwhile.

pdkl95 12y ago
This analogy exaggerates the bandwidth savings. Converting from uncompressed BMP to compressed PNG can easily save over half of the file size; even 10:1 compression is common for some images. The bandwidth savings in HTTP2 are much smaller, and are probably only significant in aggregate.
- stephen_g 12y ago
  True - the bandwidth savings aren't huge. What you do get with HTTP/2 is the ability to use bandwidth a lot more efficiently. Because of TCP's congestion control, such as slow-start, doin a different TCP connection for each file, as HTTP/1.1 does, is actually a fairly terribly inefficient for transferring small files. One way that web developers have tried to get around this is to combine resources together - such as having huge combined javascript and CSS files, and big sprite sheet images. But this messes up caching - if I change a 20KB source file that is part of a half meg combined JS file, then you have to redownload the entire file. Another problem is that you're limited to how many HTTP requests the browser will make to a single domain at once, so you have to wait around for files to finish before others will download. You can try sharding the files across different subdomains but it's a suboptimal solution. The multiplexing in HTTP/2 solves these problems. You can send a bunch of files at once in one connection without repeating the (necessary) slowness of TCP slow start for every file, and the browser realises that they're different, so can cache them separately. This can translate into noticeably faster page load times.

ubernostrum 12y ago

Web development in 2014 consists of using four dozen CSS files, two hundred JavaScript files, and upwards of 750 HTTP requests to an API in order to display a single blog post. It is unthinkable to impose any sort of discipline on the use of resources by developers, even at companies which theoretically have an incentive to be efficient. As a result, those companies have banded together to produce a bloated, multiplexed blob-fish of a protocol which they have vomited into the standards body for fast approval, over the objections of the people who will actually have to implement it.