Not logged in » Login

Please login

Please log in with your Fujitsu Partner Account.


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now

Recent Discussion:

NickBown | 22.12.2018, 14:18
We have come across this issue as well, and don't seem to have found a way around it (the server is ...
NickBown | 20.12.2018, 18:40
Hi everyoneWe've got an RX2540 M1 which won't boot past the Fujitsu splash screen (which shows the i...
MarkM | 15.10.2018, 11:33
Hi there.I do not believe the Fujitsu policy on this subject has changed.So NO you can not order dri...
Feb 19 2015

Good-bye to SPDY, Pt. 2: HTTP/2 on Its Way to Standardization

Following two years of debate and 16 drafts, the Internet Engineering Steering Group (IESG) has finally come up with approved specifications for two future key Internet technologies, HTTP/2 and HPACK. In the next step, they'll be wrapped up into Requests for Comment (RFCs); large-scale rollout is supposed to start in mid-2015 or early 2016, depending on whether you look at the client or server side.

Have you ever wondered why websites are slow to build up and your browser seems to be dragging its feet even though you're on a latest-gen PC or mobile? In that case, you'll be happy to learn that the reason isn't necessarily a lack of hardware performance or bandwidth. Instead, the fault may well lie with the somewhat aged HTTP/1.1 protocol that has been around for nearly 20 years, an aeon by IT standards. And you might even get exhilarated by the notion that the wait for a 'faster web' could soon be over – provided, of course, that software vendors will flock to support the new protocols HTTP/2 and HPACK, whose specifications were submitted for standardization over the course of the last week.

Actually, providing support for these protocols shouldn't be problematic at all. That's because HTTP/2 is "not a ground-up rewrite" of its predecessor, but rather a souped-up version that retains classic HTTP methods, status codes and semantics and even corresponds with the same APIs. The newcomer just adds some performance tweaks to reduce "end-user perceived latency, network and server resource usage," says the HTTP/2 home page. More specifically, its developers want to eliminate the lack of efficiency in current HTTP implementations: when the protocol was first developed, the authors thought of the World Wide Web as a text-based affair, pimped up with occasional photographs – and not the content and app jungle it is today. As a result, loading a single page nowadays is much more resource-intensive than originally intended, with the main issue being that browsers have to use multiple TCP connections to ensure it looks good and provides all the information and features we hope to find. Sadly, if too many connections are required at a time, this means that browsers will eat up more than their fair share of network resources and hamper the performance of other applications and the network in general. Hence it was only logical that several software firms created what can best be described as web accelerators. The most successful among these efforts was Google's SPDY. First launched in 2009 and eventually supported by all major browsers and browser makers, SPDY introduced multiplexing, prioritizing and built-in header compression and thus laid the groundwork for HTTP/2, which differs from its predecessor in four main areas:

  • HTTP/2 is binary, not textual.
  • It allows for multiple request and response messages to be transmitted over one single TCP connection at the same time; according to the developers, the messages can even be broken up into various parts and "intermingled" with one another.
  • Header compression as outlined in the all-new HPACK protocol reduces HTTP overhead. HPACK replaces the GZIP and DEFLATE algorithms used in SPDY.
  • Servers are enabled to "push" responses into client caches.

It is expected that these measures will help to cut roundtrip times – the time it takes to exchange request and response packets between a client and a server – by up to 60%. As a result, end users would benefit from lower latencies (pages are rendered faster), and existing Internet connections/bandwidth would see a major boost in efficiency, all without extra costs. Given these advantages, it's not risky to predict that HTTP/2 will likely be an immediate success, even more so since Firefox and Chrome already support the new protocol, and Internet Explorer is to follow suit as soon as Windows 10 is released.

For detailed technical information about HTTP/2, please see the protocol home page and the FAQs. A list of implementations is available from GitHub. For a glance at potential problems – especially unwanted complexity and unsolved privacy issues – see Tim Anderson's report at The Register.


Comments on this article

No comments yet.

Please Login to leave a comment.