Slashdot Mirror
HTTP/2 Finalized
An anonymous reader writes: Mark Nottingham, chair of the IETF HTTP working group, has announced that the HTTP/2 specification is done. It's on its way to the RFC Editor, along with the HPACK specification, where it'll be cleaned up and published. "The new standard brings a number of benefits to one of the Web's core technologies, such as faster page loads, longer-lived connections, more items arriving sooner and server push. HTTP/2 uses the same HTTP APIs that developers are familiar with, but offers a number of new features they can adopt. One notable change is that HTTP requests will be 'cheaper' to make. ... With HTTP/2, a new multiplexing feature allows lots of requests to be delivered at the same time, so the page load isn't blocked." Here's the HTTP/2 FAQ, and we recently talked about some common criticisms of the spec.
MS will only support this in Spartan on Windows 10. Which means 7 and XP are already out of support.
http://saveie6.com/
The post even has counter-arguments and links to stuff. Are the 90's back again? Do I hear rave music, modem hand-shake tones and browser wars?
I'm really going to miss being able to telnet to a server and troubleshoot using plain text. Feels like a lot of simple has disappeared from the internet
Peace, or Not?
Web pages being slow has nothing to do with HTTP and all to do with bloat eating every bit of performance that is available to the marketers who are in charge of the web now. A binary protocol to save a couple of bytes in times where every web page loads at least three "analytics" scripts weighing dozens of kbytes each. Marketing rots the brain.
As the author of an open source webserver, I must say that I'm not really happy with HTTP/2. It adds a lot of extra complexity to the server side of the protocol. And all sorts of ugly and nasty things in HTTP/1 (too much work to go into that right now) have not been fixed.
What I have experienced is that SPDY (and therefor also HTTP/2) will only offer more speed if you are Google or are like Google. Multiplexing doesn't offer that much speed increase as some people would like you to believe. Often, the content of a website is located on multiple systems (pictures, advertisements, etc), which still requires that the browser uses more than one connection, even with HTTP/2. Also, HTTP/1 already allows a browser to send multiple requests without waiting for the response of the previous request. This is called request pipelining, but is turned off by default in most browsers. What I also often see is that a browser makes a first request (often for a CGI script) and the following requests (for the images, JS, CSS, etc) are never made due to browser caching. So, to me HTTP/2 adds a lot of complexity with almost no benefits in return.
Then why do we have HTTP/2? Well, because it's good for Google. They have all the content for their websites on their own servers. Because IETF failed to come up with a HTTP/2 proposal, a commercial company (Google in this case) used that to take control. HTTP/2 is in fact a protocol by Google, for Google.
In my experience, you are far better off with smart caching. With that, you will be able to get far better speed-increase results than HTTP/2 will ever offer. Specially if you use a framework that communicates directly with the webserver about this (like I did with my PHP framework). You will be able to get hundreds to thousands requests per second for a CGI script instead of a few tens of requests. This is a speed increase that HTTP/2 will never offer.
I think this is a failed change to do it right. HTTP is just like SMTP and FTP one of those ancient protocols. In the last 20 years, a lot has changed. HTTP/1 worked fine for those years. But for where the internet is headed, we need something new. Something completely new and not a HTTP/1 patch.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Does HTTP/2 require encryption?
No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.
https://http2.github.io/faq/#d...
And please, avoid suggesting alternative explanations, it would be an insult to human intelligence.
Want faster page loads? Stop all the links to JS files on a dozen other sites.
I like how HTTP/2 and SystemD are bringing binary data formats to replace slow to parse text formats. Just throwing the controversial opinion on the table.
Finally, a Web standard that isn't total shit.
I was starting to lose hope in humanity altogether.
Now, let's also improve html by removing all JS and other VMism from it, and make it binary.
"HTTP/2... also introduces unsolicited push of representations from servers to clients."
Seriously? Do we need yet ANOTHER way for a server to push unwanted code and malware onto our client systems? This is the greatest gift we could POSSIBLY give to the cybercriminals who want to break into our systems.
How about we think of security somewhere in this process, instead of pretending it's someone elses's problem?
Sometimes the "writing on the wall" is blood spatter...
When Internet revolution arrives, they will be first up against the wall.
The main problem isn't the size of the stuff that gets loaded. What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection. The problem is latency: it takes more than 100ms for that megabyte of data to even start flowing, let alone get up to speed. That's what the multiplexing is intended to deal with.
That said, the root cause of all this is the sheer amount of unnecessary stuff on pages these days. Fancy multiplexing or not, no request can finish faster than the one that's never made.
I agree with what you say but it's a bit like saying dirt roads should never have been replaced with tarred ones because people drive badly or automobile manufacturers build sub-standard cars. (The second simile is probably more appropriate.) I perceive this to be a largely incremental improvement - it isn't exactly revolutionary. Nevertheless, for real web developers who use it properly, it is still a good thing in my opinion. (You forgot to mention popular and horrific "depend on everything" development practices and, in the world of Javascript, "inline it too" - I'm thinking of OpenLayers 3 which in-lines Google Closure!)
While we're discussing HTTP, what's wrong with Slashdot lately?
I keep getting timeouts, signed out, nothing but the front page, everything else loaded from a CDN (that just gives me browser security warnings because it's not coming up as slashdot.org), etc.
Are you guys under attack, or just unable to keep a site with ~100 comments per article up?
So you don't having something like HTTP_REFERER again
I feel like there's something important in the observation that advertising usually funds communication/information technologies. It seems like a kind of economic failure to me. But I can't quite put my finger on exactly what it is.
It's a bandwidth vs latency issue. HTTP1/1.1 is more latency sensitive, HTTP2 helps high latency. You say that pages load slowly because they're so large, yet these large bloated web pages consume nearly no bandwidth. HTTP2 multiplexing allows async requests and preemptive pushing of data, which should allow better usage of bandwidth. Fewer connections will also allow for quicker TCP relieve window ramp up and reduce the thundering hurd issue that many connections over a congested link creates.
This protocol will enable new types of web applications, things like realtime multiplayer games that need to constantly stream lots of packets at a lower latency. Things that are not done today because the current technology simply can not provide a good enough experience. Plus it will reduce your server load which is nice (marketing scripts and ads are served from third party servers).
Existing standards that are "good enough" tend to be hard to replace.
Indeed. Someone needs to do a study of how harmful to the environment all the horrible marketing Javascript running on web pages is. It's about the only thing that pegs my CPU when my computer is in "normal" use now ( "normal" being "what normal people do with a computer", because "what programmers do with a computer" is often a little more intense.)
I'm not someone who so far has joined with the ad-blocking movement, on the proviso that websites need *some* way to keep the server running, but I'm getting really close.
and by the way, chrome and firefox will only allow http2 with TLS
Will they support HTTP/2 opportunistic encryption (TLS with the http scheme)? Or will webmasters have to negotiate with their ad networks and other third-party providers for support for the https scheme before switching to HTTP/2?
"It'll" is a contraction, not slang, you fucking nitwit.
What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection.
Which means you could burn through a 5 GB/mo cap in less than 9 minutes.[1]
Cellular ISPs in the United States charge a cent or more for each megabyte. Satellite and rural DSL ISPs tend to charge half a cent per megabyte.[2] This means cost-conscious users will have to either install ad blockers or just do without sites that put this "sheer amount of unnecessary stuff on pages".
[1] 5000 MB/mo * 0.1 s/MB * 1 min/60 s = 8.3 min/mo
[2] Sources: major cell carriers' web sites; Exede.com; Slashdot/a
Natalie Portman, get your grits ready!
Marketing rots the brain.
It also pays the bills.
IPv6 needs 100% buy-in from all participants or else you need to run/pay for bridging services who converts between the two. HTTP/2 is backward compatible meaning any participants will transparently fall back on HTTP 1/1.1 if it's not supported. Plus, there are far fewer vendors of HTTP servers / clients than there are for IPv4 based software and hardware products.
Bye!
Most of that bloat you speak of is delivered via Javascript. A few weeks ago, I finally put my foot down and made my default browser Firefox with NoScript. I have a (very) small list of sites allowed to execute scripts, and most of the time I will browse a website in its broken state, since I can still see all the text and images. It even foils the news websites that use Javascript to "faux-paywall" their content behind canvases, as opposed to only sending part of the story content from the server (I'm still shaking my head as to who on the business side thought this was a good business stance since one can still read most of the articles for free, but that's another discussion entirely). But lo and behold, once I started a staunch NoScript policy, page loads completed much faster, cookie sprawl was reduced, and Firefox's memory usage stayed relatively low. I also started to learn which scripts from which servers were truly allowed for things like externally-served comment systems (disqus, etc.), and also noticed the way that some webpages end up triggering a cascading dependency of server connections due to scripts calling scripts on other servers, etc.
One of the worst instances of cascading Javascript sprawl that I've seen was a page from The Verge, with 33 domains allowed (including theverge.com) executing 133 scripts. The SBNation "eulogy for RadioShack" article had the "script counter" go over 160. Oh, and that's leaving out web fonts, which NoScript also blocks (which also reveals how often some websites use custom fonts to draw vector-based icons; you can see the Unicode codes for each character since the font isn't loaded). Vox seems to love abusing Javascript in their designs; it's most of the reason why I've abandoned reading Polygon (the other reasons being the banal editorial content, aside from a few notable articles). In comparison, Slashdot is currently asking for 21 scripts, but is running perfectly fine without any Javascript enabled (despite nagging here and there).
I've ended up moving YouTube browsing to Pale Moon, since it natively supports the HTML5 player without issues. I may end up moving all of my browsing to Pale Moon with NoScript, since it natively supports a status bar.
The whole situation with the Javascript bloat reminds me of the scene from Spaceballs where Lonestar tells Princess Vespa, "Take ONLY what you NEED to SURVIVE." We're stuck with a bunch of prima donna web designers who want to duct tape on more adverspamming and social spying avenues to their website, and not standing back and taking a look at how bad it's impacting the user experience, not to mention the bloat from the hundreds of extra scripts and objects loaded by the browser, as well as the tens of connections to third-party servers.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
If a checkbox is not checked does it still not come in on the post / get ?
That's HTML, that has nothing to do with HTTP.
Is a textarea still not a text control?
That's HTML, that has nothing to do with HTTP.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
If a checkbox is not checked does it still not come in on the post / get ?
if not then it is still broken on arrival.
Is a textarea still not a text control?
if not then it is still broken on arrival.
I think you're confusing HTTP with HTML.
You're special forces then? That's great! I just love your olympics!
Long ago I wrote an OS with only a few lines of code, try to do that with protected mode. HTTP/1.1 has some serious limitations that makes high latency high bandwidth connections feel like dial-up.
My understanding is the use of binary is to simplify parsing. It's a lot harder to hardware accelerate a mark up language than looking for byte codes in an ASIC.
"The main problem isn't the size of the stuff that gets loaded [...] the root cause of all this is the sheer amount of unnecessary stuff on pages these days"
So the main problem *is* in fact the size of that stuff, isn't it?
Oh! by the way, not everybody's connection is like yours, specially over mobile networks.
"for real web developers who use it properly, it is still a good thing in my opinion."
Well, real web developers basically ignore what HTTP is right now, focusing on HTML, why is this going to change with the new HTTP version?
That isn't at all true. My laptop has both IPv6 and IPv4 addresses. When I make a request to google.com, I'm using IPv6, when reaching sites that don't have IPv6 I fall back to IPv4. As a user I don't even notice this.
Similarly, HTTP/2 has to be implemented on clients and servers before it will be functional, else both endpoints need to agree to fall back on HTTP/1.1.
There's some additional network configuration needed before IPv6 is useful, but no need to convert anything.
What I also often see is that a browser makes a first request (often for a CGI script)
2015.
Still thinking running sites via CGI is relevant.
I'm pretty sure that "CGI" in Aethedor's post referred not to CGI proper but in a broader metonymic sense to any HTTP response that isn't just the verbatim contents of a file. I get the idea that some pedants hate metonymy.
Have you ever purchased a $250,000 firewall, reverse proxy, and encryption accelerator all-in-one device? These things are meant to handle 10mil HTTPS connections at full duplex 10Gb/s, and establish 400,000 new HTTPS connection per second. Plus, they can re-write and otherwise manipulate HTTP headers. All of this in real time at 10gb/10gb rates. It is not an easy thing to do when parsing text. Binary is much easier to accelerate.
Which is how we'll know who to put up against the wall and shoot.
Speaking of Real Time Multiplayer Games ...
https://www.ingress.com/
(aka CalvinBall)
Join the Resistance
Resistance is Freedom!
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
...to pay your $699 licensing fee you cock-smoking teabaggers.
Celebrity worship is a poor substitute for Deity worship and costs more to boot.
There are fewer parties - a few servers and a few clients, both which are updated fairly frequently (the servers because admins, the clients because auto-update) are the only ones that matter. Google already supports HTTP/2 (nee SPDY) so a huge percentage of internet traffic is already set up to use it as soon as browsers update (Chrome has had it as SPDY for years, Firefox has it or will soon).
The v6 slowness was always the ISP (both on the client and server) and the CPE. Now that most of the big US ISPs have their heads on straight, things are looking better for v6 - but Joe Blow bought a WRT54G in 2005 and damned if he'll replace it - it works fine, after all, and who can blame him?
Despite all this, v6 is actually happening. About 5.8% of all Google's global traffic is v6, and that's more than double from last year. In the US, it's more like 13.9% - which puts us 3rd globally (a rare thing in which the US is internet-competitive). Interestingly, if you zoom in the global graph it's clear that workplaces are far behind residential connections (weekends are a big jump).
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
No... maybe. It depends.
Amdahl's law is in full force here. There comes a point where increasing the bandwidth of an internet connection doesn't make pages load faster, because the page load time is dominated by the time spent setting up connections and requests (i.e. the latency). Each TCP connection needs to do a TCP handshake (one round trip), and then each HTTP request adds another round trip. Also, all new connections need to go through TCP window scaling, which means the connection will be slow for a few more round trips. Keep-alive connections help a bit by keeping TCP connections alive, but 74% of HTTP connections only handle a single transaction, so they don't help a great deal.
Oh! by the way, not everybody's connection is like yours, specially over mobile networks.
Mobile networks (and, yes, satellite) tend to have high latency, so round-trips are even more of the problem there. Also... when people shop for internet connections, they tend to concentrate on the megabits, and not give a damn about any other quality metrics. So that's what ISPs tend to concentrate on too. You'll see them announce 5x faster speeds, XYZ megabits!!, yet they don't even monitor latency on their lines. And even if your ISP had 0ms latency, there's still the latency from them to the final server (Amdahl's law rearing its ugly head again).
Given all that, I think I'm justified in saying that the main problem with page loading times isn't the amount of data but the number of round-trips required to fetch it. Reducing the amount of data is less important than reducing the number of, or impact of, the round-trips involved. And that's the main problem that HTTP/2 is trying to address with its fancy binary multiplexing.
(Now, if your connection is a 56k modem with 2ms latency, then feel free to ignore me. HTTP/2 isn't going to help you much.)
Existing standards that are NOT good enough, where replacements are not backwards compatible are hard to replace.
This is very different from IPv6 where both the server and the client have an automatic fallback ability. It's more like USB2.0 vs USB1.0 or SSL3 vs SSL2 (security issues with these aside). HTTP/2 can be implemented by any server regardless of the client (like Apache's mod_SPDY). It can be implemented by any client regardless of the server (Chrome already implements SPDY). All transparent to the user with automatic fallback.
Such standards find themselves replaced very easily when one or two major companies get behind the effort.
If comment sections were to switch to NNTP, whose responsibility would it be to implement all the purpose-designed protocols for display in the context of a web document? Would every web browser have to implement mail, NNTP, torrents, etc.? The only major browser I know of that does anything remotely like that is SeaMonkey, and even then it segregated news and web views last time I checked.
It'd be many times easier than implementing the current mess, which no browser so far has been able to do properly.
Now, let's also improve html by removing all JS and other VMism from it
Comment sections and forums aren't the only application of DHTML (manipulation of the HTML DOM through script) that loss of script might break. What workarounds for lack of script would you propose for these?
Define "properly". I have posted to Slashdot on a Wii game console using the "Internet Channel powered by Opera" app. It was dog slow, but it was better than not working at all, which is what would happened had Slashdot used NNTP.
Sure and I can use just about every protocol from the console except the Web since most websites do useless dynamic crap that doesn't work with links2.
Those analytics scripts are usually from an analytics service provider, and so are incredibly well cached, and shared across services. If you are repeatedly downloading the 15.7KB Google Analytics JS file, you are doing something wrong.
If you'd spent any time looking in to HTTP performance, you'd know there is a lot to be desired. HTTP/2 is a step in the right direction. It's not saving a couple of bytes, it's saving a shit-tonne of bytes, using connections more efficiently, and improving encryption support massively.
But I'm sure your anonymous, throw-away, off-hand comment carries far more weight than the actual experts in this field.
My ISP supports IPv6 and I didn't even realise until I ran ifconfig and saw IPv6 addresses. Just because your ISP can't handle it don't assume others can't!
If you're not ipv6 by now, you should look into it. Otherwise you may be compared to a cave man, real soon. They may use you on a Geico commercial.