4 ms·

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).

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.

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.