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.
Go progress!
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.
Slashdot will never be able to support HTTP 2.0. They can't even support typical implementations under HTTP 1.1. Why do I have a "Working..." with the "dog chasing its tail icon" at the bottom of my screen on every page? If they can't even handle things like Javascript, you can put your money on it that they will forcibly implement HTTP 2.0 and break everything (including anything trying to use 1.1) in its path.
Also,
where it'll be cleaned up and published
Nice journalistic quality. Let's use slang like "it'll," brah! It'll be fun 2 read d00d lol
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.
How can something be "cheaper" when the complexity dial just got turned up to eleven?
HTTP/1 is a bicycle when used in the simplest way (no pipelining, single request), with HTTP/2 being an F35. And all I need is to go half a mile to buy groceries.
Long ago I wrote a very simple web server in about ten lines of bash script. Try that with HTTP/2.
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.
On YOUR connection, you dick. Not everyone is on fiber.
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?
You have that backwards. I'm not at all saying that web pages are slow because they're so large. I'm saying that making HTTP/2 a binary protocol is meant to save some bytes, and that that's silly. I say, send those few extra bytes and keep it readable. Binary protocols are brittle and difficult to debug. Saving bandwidth where none of the users of the protocol seem to give a shit about conserving bandwidth or keeping the number of connections per page reasonable, is a completely pointless and counterproductive endeavor.
Multiplexing may be nice, but I notice that the most fervent proponents are the ones whose scripts bloat almost every web page. An easier and more effective way to speed up the web is to block a few well known domains, if you know what I mean.
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!
Isn't that what websockets already do?
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
That's HTML, not HTTP. And, yeah, HTML forms are still broken. I think the official response is that you should use more JavaScript because making those things work right by default would make far too much sense.
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!
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.
Minor Correction: When the distributed web revolution arrives, theirs will be first to be filtered out and not re-served by local nodes.
"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.
You're pulling my leg, aren't you? HTTP/2 ASICs?
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.
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.
Your router that you connect to needs to do ipv6. Your modem needs to be able to handle it. Your ISP needs to do it. Your ISP's ISP and any partners it connects to needs to do it. The other ends routers need to do it and the computer it connects to also needs to do it. PLUS all the software in between needs to know to make the right tcp6 stack calls. Even now I would say 2-3% of the connections I make are ipv6. The rest are still ipv4. I have the logs to back it up too.
IPv6 was/is a huge ordeal to make happen. I went thru 2 routers and two modems that said they did ipv6 and did not really. My ISP spent some serious money buying routers to handle it. In the next year or so ipv6 will not be that big of a deal anymore. To get it to work you pretty much need the whole pipeline to be ipv6 (even thru a proxy at some point you have to go back to talking ipv6). About the only thing that ipv6 can reuse from ipv4 is the phys layer.
HTTP on the other hand uses the existing IP infrastructure so HTTP2 just rides on top of that. Its just a different protocol that looks a lot like the previous one. Its more of flip a switch and if the other end can talk http2 then cool beans. If not back to http1.1/1 for you.
Comparing it to ipv6 is a bit wrong.
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.
what an ignorant comment. ofc the size of stuff that gets loaded affects loading speed you fucking douche
You're not in charge of running the Slashdot servers as of late, are you? Anyone who thinks they should put a high level protocol like HTTP in silicon deserves what they get. Complex binary protocols are brittle as hell, especially in a heterogeneous environment. Implementing HTTP/2 that way may look easier, but I assure you you'll only end up turning off the hardware acceleration to have the software handle it after all, just so you can work around the bug of the day, especially if the HTTP/1.x semantics remain valid.
My mind is drawn to the HD video that autoplays as a background image on PayPal's homepage.
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.
Existing standards that are "good enough" tend to be hard to replace.
HTTP/2 is just a modified version of SPDY.
Do you use Google or Facebook in any browser other than Internet Explorer? You are already using HTTP/2 v0.8.
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.