HTTP 2.0 – Here’s what you need to know!

Contributed by Emil Soman on 30 Sep 2013

• 
• Tweet
• Get in Touch

The first draft of the HTTP 2.0 implementation was made in July and it’s planned to become the standard by next year or so. The implementation draft is pretty long, but here’s what you need to know about HTTP 2.0 right now (the implementation is bound to change over the next year anyways): HTTP 2.0 brings this idea of interleaving and multiplexing “frames” over multiple “streams” within a single TCP connection.What does that mean, you ask?

 

1. Every HTTP 2.0 client establishes only a single TCP connection with the HTTP 2.0 server.
2. The server or the client can create as many streams as it wants over this TCP connection.
3. The client can send a request-message to the server and the server can respond with more than one response as message.
4. Each message is split into “frames” which can be sent over the stream. Frames of different streams can be interleaved. (See the diagram below )
5. Messages can be passed in both directions at the same time over a single stream.
6. There’s this idea of assigning priority to a stream so that stuff that should be sent first (for example HTML, CSS or JS files) can use a higher priority stream and images can be sent over a lower priority stream.
7. There is also this new idea that the server can “promise a push” in response to a client request and then the server can initiate a new stream for pushing frames to the client (this seems to be the only way a server can initiate streams)

 

(Reference : http://chimera.labs.oreilly.com/books/1230000000545/ch12.html )

Here you can see there are 3 concurrent messages in transit over a single TCP connection. I think that’s pretty cool !

Okay enough said. How is this going to change the Web?

•    No more transport “optimization” workarounds required. Since the server can create new streams without the overhead of creating TCP connections, image sprites and concatenated assets will be things of the past.
•    No more head-of-line blocking (a network problem where many packets are blocked by a packet at the head of the queue) because messages are sent concurrently over different streams.

Less number of TCP connections. Less memory use?

HTTP 2.0 is based on the experimental work using SPDY protocol and using SPDY, they got a 55% better page load time for the top 25 websites, that means faster web !

How is all this going to affect my web development? Even though application code is not expected to change, I am expecting changes at the App server layer which would allow the server to communicate more effectively with clients. Debugging tools will have changes too. Also, server side events look more promising with HTTP 2.0.  You will also surely see changes in your static web asset build tools. (And think about the opportunity to come up with implementations in your favorite language and develop libraries out of them, Open Source anybody?)

Visit us at Neevtech.com to know more about our offerings.

Tags: App server, application, client, code, CSS, Debug, frame, HTML, HTTP, HTTP 2.0, interleaving, JS, libraries, memory, message, multiplex, Neev, Neevtech, open source, packet, queue, server, static, stream, TCP, web asset build tool, web development