HTTP/2 makes media loading 3–15 times faster on mobile
medium.com
medium.com
Edit: oh and throw in a few videos, everything has a video or two nowadays.
If your page loads stuff from 25 different domains, HTTP/2 barely helps at all. Likewise if your page is loading MB-size image or script files. Likewise if your server takes 2+ seconds to render the darn HTML in the first place.
But HTTP/2 is awesome when all the resources come from the same domain, because it eliminates the bottleneck of separate TCP/TLS connections. This means you don't have to do stuff like bundling resources and sharding domains. And indeed you shouldn't do this stuff if you're using HTTP/2.
HTTP/2's biggest problem is that nobody is changing their site to take advantage of its benefits.
These changes will see widespread use once CDNs start to take advantage of it. If you are serving a big enough website to take advantage of HTTP/2, you are using edge servers.
When you have a web site this is a totally different story : beside your content and statics, you'll have maps from a CDN, widgets from third parties, ads ... and so on. "changing their site to take advantage of its benefits" is just not realistic for normal website.
See the "Stop Concatenating Files" part of this article : https://blog.cloudflare.com/http-2-for-web-developers/
I think where this will really start to shine is when browsers get js module support internally... combined with http/2 and some smarter server-side rendering, that could be a really nice place to be.
e.g. Remind me why I should be concatenating all my JS/CSS files into one again? and why exactly do I have 6 hostnames for that 1 static server?
200 resource fetches really isn't that many once you, and your framework authors, remove these and other HTTP/1 workarounds.
Is this a push to make the internet more secure by design or is there some other reason behind this?
What's the speed difference between HTTP/2 and HTTP/1.1 without TLS? I'm sure this is hard to test because of lack of client support.
It is not always trivial to move large legacy projects to secure connections (especially because any resource, even an image, being loaded from an insecure endpoint results in a warning) so the result is now:
- Support TLS first
- Then implement HTTP/2
Consumers will not be able to take advantage of the better HTTP/2 performance without big changes to websites to first support TLS on the server end. Why?
For reliability and success of the protocol. "Reasons for choosing TLS-only include respect for user's privacy and early measurements showing that the new protocols have a higher success rate when done with TLS. This is because of the widespread assumption that anything that goes over port 80 is HTTP 1.1, which makes some middle-boxes interfere with or destroy traffic when any other protocols are used on that port." (Source: http://http2-explained.haxx.se/content/en/part5.html)
Believe me, TLS is very much necessary in practice here.
I'm not convinced that's a real problem once traffic leaves your servers/CDN. In practice I have seen lots of protocols use port 80, since 80 is the port that's most likely to be unrestricted on even the strictest corporate firewalls.
I remember watching a video of some Go developers writing an HTTP/2 client and one of them mentioned that there was an agreement to never accept non encrypted connections.
>any resource, even an image, being loaded from an insecure endpoint results in a warning
By nessesity, unsecured resources undermine TLS's integrity guarantees. An unsecured image on my bank's website would mean that anyone who MitMs my connection can swap that image to show a message that appears to be from my bank.
The internet is no longer the trustworthy place it was in the eighties. HTTP2 is one attempt to make developers catch up with ye that.
Should all those sites not benefit from the speed improvements that HTTP/2 offers? It seems unusual to couple HTTP/2 with TLS, again, it's not the spec that does this but the vendors who are doing this.
The bigwigs of the industry will throw tons of developer resources at converting everything to TLS (haven't they already for the most part?) and then deploying HTTP/2. They already throw tons of money at being the fastest out there.
I find it interesting (worrying?) that while a spec does not specifically enforce a requirement, large browser vendors have enforced it and created an imperative for pretty much everyone to comply if they want the benefits of the new protocol.
I think one reason they insist on TLS is because the need for privacy and integrity is a lot bigger than most people realize, and historically server folks have not reliably made the right choice.
In my experience the times that I've had users complain about "injected" information or weird ads, it's usually come from malware that resides ON their system. There's no MITM required for this. The injection happens client side through a browser plugin or some other resource that gets loaded up along with the page. TLS wouldn't fix this in any way as far as I am aware.
Gee, I don't know, imagine plastering your brand all over the NYT homepage or libelously accusing your political opponent of some heinous crime or behavior or injecting your malicious script onto millions of visitors' machines.
> There's no MITM required for this.
Um, local scripts injecting ads are still MITM by definition.
> TLS wouldn't fix this in any way as far as I am aware.
Yes it would. That's why pesky "antivirus" software MITMs TLS connections on your local computer.
A local script injecting an ad is not the same kind of MITM attack and is no way mitigated by enabling TLS.
The discussion here is not about whether encryption is bad. My aim was to ask about whether no encryption = no HTTP/2 for you and why this is the case. I understand that the technical reason at the protocol level is because of obsolete proxies often sitting on port 80 and also the protocol negotiation that needs to take place.
Injecting ads is a relatively harmless but hugely profitable application we are already seeing.
On the more serious side, changing news feeds has huge potential for governments. It's the perfect propaganda tool, and with advances in machine learning the cost of doing this on a gigantic scale shrinks every day.
We've already seen large scale MITM be used for political reasons: to DDOS github off the internet in retaliation hosting anti-censorship technologies.
For people who do use the web to stay informed, reputation, ie. trust, matters. I might think that CNN publishes clickbait alonside real news, but I trust that CNN won't put blantaly false breaking news warnings above the fold about made-up events. Or, if I don't trust a single source in isolation, I trust that if several news outlets are posting breaking news warnings about the same event at the same time, that event must be real. How else would you find out?
In this day and age, refusing HTTPS means that the site author has done a cost-benefit analysis and decided that their content is not important enough to be verifiably originating from them, and that their reputation is not valuable enough to be protected from malicious tampering. In that case, why host a self-hosted website at all?
This is what you can do with a single fake tweet: http://business.time.com/2013/04/24/how-does-one-fake-tweet-...
HTTPS. It's not just about privacy. You want people changing the content of your articles and injecting ads or malicious scripts for your visitors? As the owner of the site, you have a responsibility to protect them and protect yourself from liabilities.
Are you using the transport layer? Then you need Transport Layer Security.
> Should all those sites not benefit from the speed improvements that HTTP/2 offers?
So, nope. Not until they can guarantee integrity and authentication.
Who's to say it won't be ads next? Who's to say they won't be serving exploits to clients? One lazy ISP trying to make a quick buck could serve untrustworthy ads to millions of people and have it show up on other sites, making it difficult initially to determine the source of the exploit, and preventing browsers' 'untrustworthy site' warnings from protecting users.
The same thing happened years ago with RBLs, where ISPs would return fake DNS results for sites which didn't exist, breaking RBL lookups completely and severely hampering spam detection for any users using those DNS servers. Worse yet, some of them prevent you from accessing other DNS servers directly, making it impossible to avoid their breakage.
If there's one thing we've learned in the last ten years it's that we can't trust ISPs to stay in their roles as providers of connectivity and services; they all see the potential for more money and never seem to grasp the downsides until it's too late.
Yes? I thought that was obvious. Google is even giving higher ranking to HTTPS sites now and even showing HTTPS versions of the site by default on Google, I believe.
If I'm not mistaken Apple is also pretty much forcing all app developers to use encrypted TLS connections for their apps (although there may be some exceptions).
Actually, it is:
2. I see ~1.5MB on the linked page, more than half of which are images used in the article, which are of course not simple text.
At the very low bandwidth (2g/edge), the constraint goes the other way, where you don't gain much as the channel is pretty much flooded the entire time and the connection overhead offset is lower. ymmv.
All around, more traditional approaches can have a bigger impact... actually optimizing images, switching to svg where practical and reducing code, markup and stylesheets goes a long way. Reducing server response times is also pretty crucial. If your DBMS is taking 200ms to respond to most requests, your application is already going to be at least that slow... got multiple requests, worse still.
Effective caching strategies are how you overcome a lot of that. There are many pieces, and it's a matter of checking what your bottlenecks actually are, and minimizing your content transferred first.
But seriously, as much as I like HTTP/2, it's not fully replacing 1.1 ever.