What is new and latest improvements inside HTTP version 2 Protocol

Knowingly or unknowingly each and every one of us are using one or the other communication protocol in our day to day lives. It takes a lot of hard work to design a protocol that fulfils our requirement of any network communication. Computer scientists are working day and night to improve, modify or further advance already existing communication systems. Most of the times, they are scientists, working due to the sole reason of interest.

One such large group of computer scientist’s, work in the form of different groups on different topics of interest. They are mostly called as “working groups” of IETF (Internet Engineering Task Force).

Each working group is governed by a group of chairpersons, and anybody can participate in the group by opting out for their mailing list. There are different field of areas where these groups dedicatedly work. Some of these fields are mentioned below.

• Routing
• Security
• Internet
• Applications

The main publication medium for IETF is something called as RFC’s(Request For Comments).  There was a time when these papers called RFC’s containing the technical details for implementation of certain technology were circulated by hand among scientists working inside ARPANET (The first working network). Thanks to their collective work, due to which we are accessing them with a few mouse clicks. RFC’s are most of the times made for reference purposes, as well as for peer review of a certain technology. I would say that RFC’s are the single most document available on the planet explaining the in and out of a topic in its entirety. In fact application programmers refer these documents to port a technology or protocol inside their application.
 

Other than RFC’s there is something called as DRAFTS from IETF, commonly known as Internet Drafts.  These drafts can be viewed as to-be-RFC’s in the future. Although Drafts does give the complete details, they are not considered reference material for implementing a technology. Consider the below points before going ahead with this article.

• Drafts are works which are under progress
• Never rely on Drafts for implementation
• These drafts are valid for only 6 months after its initial release
• Modification of these drafts resets the validity

In this article i will be discussing one draft which is going to expire on January 9, 2014. The main reason for this article lies in the fact that the draft is all about a major protocol that we are actively using. Even while you are reading this article, you are using that protocol. I am talking about HTTP!!

The current version of HTTP is either 1 or 1.1(it depends on the server and the client, and their preference). The Internet Engineering Task Force has released a DRAFT on July 8, 2013 which describes an advanced version of HTTP, which in the coming near future will become an RFC for HTTP version 2 Protocol. This future version of HTTP will be having a good number of advanced features, which the current version lacks. In fact I must say that the current version of HTTP was not designed by keeping performance in mind, but was designed by keeping simple implementation in mind.

There were some main shortcomings in HTTP version 1 protocol and HTTP version 1.1, which are addressed by HTTP version 2. Some of these shortcomings are mentioned below.

• HTTP version 1 allowed processing of only one request at a time
• Due to this one request at a time, clients will have to make multiple HTTP connection to the server, to reduce page load time.
• Headers in multiple requests were repetitive, and were very descriptive, which results in generation of larger packets(in other words previous versions were not using network resources in an optimized manner)

HTTP version 2 is also an application layer protocol, similar to previous versions. Some of the new advancements in HTTP version 2 is based on a protocol developed by Google called as speedy. If you want a basic introduction about Speedy you can read the below article.

Read: Speedy Protocol Developed by Google - An advanced HTTP

Remember the fact that there will be no change in the URL or URI addressing scheme, the changes are in the server and client implementation of the protocol.

Let's first discuss the main advancements in HTTP version 2 protocol, before discussing how a client will send an HTTP version 2 request.

Multiple Streams in Single HTTP connection [MULTIPLEXING]

Streams are similar to data channels. A single established HTTP connection from the client to the server can have multiple streams inside it. Which means different streams can exchange data between server and the client, at the same time in a same connection.

Streams can be initiated by either the client or the server, or can be a shared stream, where both the parties can exchange data at the same time, also streams can be disconnected or closed by either the server or the client.

There are identity numbers that will be assigned to each frame send over the stream. These identity numbers are integers and the order of the delivery is very much important(because the receiving end will process them according to the same order they arrived).

These streams carry nothing but frames. Let's see what is a frame.

In HTTP version 2, both the data and the HTTP headers are converted into something called as a frame. But yeah there are headers which are frame specific, which are very much need to understand the charecterestics of a frame. Some of the headers of frames are mentioned below.

• Length of the frame
• Type of the frame
• Which stream it belongs to etc

Yeah each stream in an HTTP connection will be identified with a 31 bit integer number. As i told before both the server and the client can start a stream, but to differentiate between these streams they are numbered in different manner.

Streams initiated by the client are always odd integer numbers, however streams initiated by the server will be even in number. Also there is one reserved number of 0 stream identifier, which will be used for connection control message. The newer streams opened by either the client or the server must have a greater identity number than the previous streams that it had opened(no matter even those previosly opened streams are closed). Another major fact to note about stream's is that stream identity numbers cannot be reused in the same connection.

When an HTTP 2 connection is initiated, the client will tell the server the maximum number of streams (multiplexed connections) the server can open, and similarly the server will tell the client, the maximum number of streams the client can open. Basically each endpoint dictate the number of streams the other can open, with the help of a settings header.

Setting Priority in Requests

Some data requested by the client will have more urgency to be fullfilled than the others. Such requests can be set with a priority flag, which will be processed first by the recieving end.

As we have discussed in the previous section, streams can be opened by both the server and the client. If the client is initiating a stream with the server, the client can set a priority for that stream(same with the stream initiated by the server). Similar to the stream identifier, priority for the streams are also set with the help of a 31 bit priority identifier.

A value of 0 means that its a high priority stream. This method of setting priority in the stream, will enable the frames send through that stream to be processed faster than other parellel streams running on that same connection.

Header Compression

In HTTP version 1 and 1.1, both the clients and the server used to send headers which were not compressed as well as sometimes headers are repetitive. In HTTP version 2 headers fields and their values are combined together to form a block, which is then compressed before sending to the target.

As we have seen before, everything that travels inside a stream are called as frames. There are multiple types of frames in HTTP version 2. For example, DATA frame, HEADER frame etc. Headers are send inside header frame and are sometimes fragmented, which are reassembled at the recieving end, before decompression.

The header frame must be send contigious. And there must be a flag END_HEAHDERS in the final header frame send.

Server Push

There is a mechanism in HTTP version 2 wherein the server can push data to client, proactively by anticipating the requirement, in response to a single request from the client. This kind of a pushing of data from the server to the client, becomes too efficient when the server knows the fact that the client will require the data for the completion of a request.

This data pushed by the server is very much similar to the response the server would have send while getting a GET request for that resource. While pushing data, server includes several header blocks, which defines the kind of request the server assumed before pushing those data.

Let's take an example of server push to understand it. Say for example, a client browser is requesting a page which contains several images. Now as the server knows that the page contains several images to load, the server will proactively push those data to the client, instead of waiting for the client to send get request for each of them.

As far as HTTP vesion 1 is concerned, even if the server knows that the client requires a resource, it does not have any method to push those resources to the client.

Can i start using HTTP version 2 now?

Well as of now you cannot use HTTP version 2, because its too early, because the official RFC for HTTP version 2 is yet to release(which will be happening after multiple reviews of the DRAFT currently prepared by IETF.)

But yeah am quite sure that we will be entering a new era of web browsing with some advanced features, especially in the performance field. However you can still implement speedy protocol on your websites, because most of the web servers are currently supporting it. Speedy does have a lot of features similar to the proposed HTTP version 2 protocol, in fact i must say that HTTP version 2 is based on improvements brought to light by Speedy.

You can implement speedy on your web servers if it is using any of the below web server packages to serve pages.

• Apache (mod_spdy)
• Nginx

Most of the major player in the industry have already started using speedy to power their websites. Some of them are mentioned below.

• Facebook
• Twitter
• Google

We can expect a faster web access and low latency of websites in the coming near future, even in a slow GPRS connection, with HTTP version 2 applied. But yeah it will take quite a good time from now for its realease as well as wide acceptance.