Slashdot Mirror
Internet Explorer Implements HTTP/2 Support
jones_supa writes: As part of the Windows 10 Technical Preview, Internet Explorer will introduce HTTP/2 support, along with performance improvements to the Chakra JavaScript engine, and a top-level domains parsing algorithm based on publicsuffix.org. HTTP/2 is a new standard by the Internet Engineering Task Force. Unlike HTTP/1.1, the new standard communicates metadata in binary format to significantly reduce parsing complexity. While binary is usually more efficient than text, the real performance gains are expected to come from multiplexing. This is where multiple requests can be share the same TCP connection. With this, one stalled request won't block other requests from being honored. Header compression is another important performance concern for HTTP.
When did the slash get added, and why? Anyway it is just a cleaner modern verison of SPDY should be trivial to support for most browser assuming it is actually final final.
Slowly, web services are becoming a bad reimplementation* of CORBA. Once again, why did we jump on their band wagon?
* Hm, maybe the correct word is "restandardization"?
Chrome has plenty of innovations but it easily becomes a resource hog and bogs down the system. IE 10 keeps chugging along. Microsoft isn't quite the microsoft of the past. These improvements should be felt the most in the mobile space where they clearly have the best browser. Their only problem? it might all be too late if they can never get out from under the shadow of their reputation.
This. They actually call their JS engine Chakra, which is quite a misnomer, given that Chakras according to Wikipedia are "energy points or knots in the subtle body". Ok come to consider, knots reminds me of IE, a huge blockage of energy on the Universe. :-)
So is this actual support of a standard, or is it some Microsoft bastardized version?
Seems like the efficiency you gain parsing the binary header would be lost with the need to first decompress it ;-)
I expect it to be renamed to MS-HTTP 3.11 Workgroups.
/nt
the real performance gains are expected to come from multiplexing. This is where multiple requests can be share the same TCP connection
Now we can report your activities to the NSA at the same time as the request: all right from your own computer! (pay no attention to those extra binary headers, they're there for your safety!)
Nice try Microsoft.
IE may have some nice sides to it - but it require windows which is a resource hog and bogs down the system. Firefox keeps chugging along - unbogged.
Parsing out the binary format of HTTP frames will most likely open up a whole new class of client vulnerabilities as malicious servers feed them bad data. Yay.
You forgot the first word of "embrace, extend, extinguish".
Take html for example:
1) We now have browser that renders html, just like Netscape. ... years later ...
2) "Best viewed in Internet Explorer"
3) Requires IE 4
Of fuck, Firefox is kicking our ass. Time to return to step 1.
I just did a quick test and found that decompression runs at about 800 Mbps. Therefore, if the network connection is slower than 800 Mbps, it makes sense to transfer compressed data over the network, then decompress it.
The fact that binary data doesn't need the same parsing like ascii does is kind of an unrelated issue.
That was at 1.2 Ghz. It's likely that most devices used in the next 15 years will run at 1.2 Ghz or faster.
> Did the net result of header decompression along with the easier parsing of the binary header take more or fewer CPU resources then the older uncompressed, ASCII header?
You keep conflating two completely separate things, but faster + faster = faster. Compressed is faster than uncompressed. Note that's the end of a sentence.
Also, and completely separately, binary is faster than ascii. Both are improvements, in terms of speed.
Compressed is faster on the wire, but takes more CPU time to decompress. If I have a 100GbE network connection coming into a server - my network bandwidth might outpace my compute abilities.
So does this put the pressure on to adapt JS to match up? Otherwise, it seems to me that the single thread deal with JS will partly hinder mulitplexing goodness. fast fast on the network, still slow slow on the browser. I guess that has always been the case even with multiple requests at a time, but it always seemed to me that was a kind of accepted, almost excuse re JS. Like yeah, "you don't want to make too many requests at once anyway"...
Yes, if you're using a full 100GbE link to serve empty files nothing but headers, and you have an Atom CPU, that CPU will probably be the bottleneck. You'd want to upgrade that CPU.
On the other hand, if you're serving files, where the body of the response is much larger than the headers, you'd have only 100 Mbps of headers and your Atom CPU could keep up.
You're not under the impression that you are the first person to think about the potential tradeoff, are you? People much smarter than either of us calculated many different scenarios years ago, then actually tested it in the real world with a few billion requests between Android or Chrome and the various Google-owned sites. Based on analyzing a few billion data points in the real world, this is the optimal architecture for performance.
Mainframes have always done this. Parameters and settings are often assembled (yes, from assembler source code) into load modules (think shared libraries) for speed. There is no parsing, you directly address the offset in the DSECT (think struct in C) where your parameter is. Microsoft and others are probably reinventing this wheel, since I doubt they have anyone who knows about this. Back when mainframes started this, computers were not able to do a lot of parsing because of memory/processing being so primitive.
My anus is bleeding!
Header compression always *sounds* like a good idea, but is there actually any way to do it securely? I was under the impression that SPDY was only secure against the CRIME attack if header compression was completely disabled.
Or is there some way to do it while ensuring that separate header fields are compressed independently of one another?
You have to downgrade to something simple like XFCE to get similar levels of performance under Linux.
Downgrade? Xfce was an upgrade from the auto-installed Unity crap in Ubuntu 11.04. Running sudo apt-get install xubuntu-desktop let me get back up to where I was with GNOME 2.
Depends on the network.
I agree. Let me explain another way it can depend on the network: There are cellular technologies in development that can push 1 Gbps. But if your cellular ISP imposes a 5 GB per month cap, as is common in the United States market, you can transfer data at maximum speed for 40 seconds and then suffer 100% packet loss for the rest of the day and the next 29 days. The sustained rate with a 5 GB cap is closer to 5*10^6*8/86400/30 = 15 kbps. So even if a network has a peak speed fast enough for uncompressed data, the sustained speed can still be low enough to justify compression.