Contents

The Proposals for HTTP 2.0

SPDY protocol will be the base of HTTP 2.0

HTTP Speed and Mobililty

Network-Friendly HTTP Upgrade

Next steps for the HTTP 2.0 specification

Who uses SPDY already?

Using SPDY today with mod_spdy

HTTP 2.0 and PHP

Conclusion

The Proposals for HTTP 2.0

As we all know very well, HTTP is the protocol by which browsers and Web servers communicate to implement all the Web applications that we all love and use since the 1990s.

The last ratified specification version of the HTTP is 1.1. It was approved in 1996. Over time it had little improvements, mostly clarifications. HTTP 1.1 served well since then and continues to serve well for most Web applications, but there is plenty of room for further improvements.

As a matter of fact, between 1997 and 1998 there was an attempt to specify a better HTTP protocol, than called HTTP-NG. However the work on that specification ceased then because it was considered too early to submit as proposal for a new protocol version, given that HTTP 1.1 was only starting to be adopted by the generality of the browsers.

Only recently the work on HTTP 2.0 specification has finally resumed with a call for proposals. There were a few proposals, but in reality they are not exactly new. Most of the proposals are based on ideas already thought by the researchers of the HTTP-NG working group.

Currently there are three proposals submitted to the HTTP 2.0 working group also known as HTTP bis: the SPDY protocol, HTTP Speed + Mobility and Network-Friendly HTTP Upgrade.

Lets take a look at the current set of proposals, so you can see where we are and what we can expect for a final HTTP 2.0 protocol specification.

SPDY protocol will be the base of HTTP 2.0

What is SPDY?

SPDY is a protocol created by Google researchers. Announced first in 2009, it brings some of the original goals proposed by the HTTP-NG group in 1998.

The basic idea is to make HTTP work as we have today on the application layer. This means that browsers and applications running on Web servers will continue to work as before, i.e. browsers send HTTP requests with headers and eventual body data, and Web servers respond to requests with some headers and body data.

What SPDY changes is the way data is transmitted over the Internet. Several aspects of data transmission are changed to make it more efficient to transmit data not only increasing the effective data transfer speed but also reducing the latency, thus providing an overall improvement in the user experience. Lets study in more detail what this means in practice.

One Connection per Domain to Exchange All Data

Nowadays, Web applications that run on top of the HTTP 1.1 need to transfer many resources to display a single page, being those resources images, JavaScript code, CSS definitions, etc..

The transferred data is serialized over an HTTP connections. To speedup the resource data transmission, browsers end up setting multiple connections to the same server in order to receive the data of multiple resources at the same time in parallel.

It has been like this for many years but that fact is that it adds a lot of latency because each connection takes time to be established before the actual data exchange starts.

SPDY works in such way that all requests sent to the same domain go through the same connection. This way, a new HTTP request that needs to be sent to the same Web server does not have to wait to establish a new request. The initial connection will be reused.

Multiplexed requests on the same connection

HTTP 1.1 already supported reusing the same connection to send multiple requests to the same Web server using the Keep-Alive header. The problem is that in order to send a new request, the browser would have to wait for receiving the response for the previous request. So, multiple connections may still be necessary to provide some parallelism.

SPDY improves parallelism of multiple requests by interleaving the packets of data exchanged for different requests over the same connection. This means that the server can send data in response for multiple requests at the same time over the same connection.

Permanent Connection to the Server

Another aspect of Web application responsiveness is that usually when a site serves a page, the connection is closed until a new page is requested. HTTP 1.1 allowed browsers to request Web servers to not disconnect for a given period. However, the connection may still be terminated if the user takes a while to access the next page. A new connection needs to be opened to request a new page.

SPDY establishes permanent connections. This means that a connection is not terminated after each page is retrieved. This allows to keep the connection open no matter how long the user takes to access a new page.

If the user closes the browser tab and no other pages from the same site are opened, the browser may send an explicit request to end the connection, so it does not keep tying the server.

Compression of headers

Another oddity of the HTTP 1.1 protocol is that it is mostly on based on text exchange. For instance, request and response headers are sent in plain text. Human-readable headers with the same names are sent back and forth over and over again. Why header names need to be human-readable when they really are not mean to be read by humans?

SPDY addresses this matter by introducing binary encoding of frequently used headers. This means that each header is converted into a binary number that is usually shorter than the actual header name that it represents, thus reducing the actual amount of data that is exchanged on each request.

Prioritized Requests

When a browser needs to render a page it starts parsing the HTML and then it may load in parallel the different resources it needs to present the page, like images, CSS, JavaScript, etc..

External JavaScript code is often a stumbling block because the browser needs to load and execute it first before processing the rest of the page. So, if the browser was already loading images or CSS when it encounters a JavaScript block that needs to load remote JavaScript code, it is more important to load that JavaScript code before anything else.

SPDY allows to give priority to requests that need to finish first, even if they were started later. Each request may get an higher priority, so the browser and the server gives priority to the transmission of the packets of that request.

Server push

When a browser requests a Web page, the server may actually look into the page HTML to figure that it needs some files to render like CSS, images and JavaScript. Usually the browser needs to explicitly request for these files, so there is a delay between the actual page loading and the delivery of those additional files that are necessary.

SPDY can make this more efficient by sending those files upfront without an explicit request from the browser. This reduces the latency that usually occurs because the server needed to receive an explicit request for those additional files. In the end, the user experience for the first time site is accessed can be improved noticeably.

There may still be cases on which receiving those additional resources in advance may not be desired. In that case, it is possible to avoid this server push feature.

Security by design

HTTP 1.1 can work on top of secure connections or not. This means that data may be intercepted by whoever can access the connections between the user browser and the Web server. This way you are never sure if your ISP, the police or some criminals are tapping on your Web server connections and get access to your private data without your knowledge and consent.

SPDY implementations require the use of secure certificates to establish the communication with this protocol. This way you can be certain that your data is being exchanged securely, apart from the security holes that may eventually be found the in actual protocol implementation.

HTTP Compatibility

As you may understand by the explained above, SPDY is compatible at the application level with HTTP. This means that browsers and Web applications on the server side do not need to be changed to continue to work on top of SPDY.

What is really different is the way data is exchanged with the server. Therefore browsers and Web servers need to have a software layer that abstracts the differences of the way data is transmitted between the traditional HTTP and SPDY.

HTTP Speed and Mobililty

The HTTP Speed and Mobility proposal was created by Microsoft researchers. It is not exactly a new protocol proposal but rather a statement of criticism to certain aspects of the way SPDY is implemented.

I will not enter on the merits of the actual points that are criticized because they are not trivial to be fully understood. I just would like to mention that from what I could gather Microsoft researchers propose the data frames be exchanged using the WebSocket protocol.

They also complain about incompatibilities with certain aspects of the TLS specification, which is used for establishing secure connections.

Another aspect of concern is the implementation of server push of resources that were already cached by the browsers. Mobile applications may also not want to retrieve some resources that the server may assume they want to download. So the criticism is that preemptive server push may end up being an undesirable thing.

Network-Friendly HTTP Upgrade

The Network-Friendly HTTP Upgrade is a proposal by Willy Tarreau. It goes well inline with all that SPDY proposes.

Other than that, I did not find many nuances of what it is proposing, so there is not much for me to comment.

Next steps for the HTTP 2.0 specification

For now there is not much information about when HTTP 2.0 is expected to become a definitive standard. Although all points to the fact that it will based on SPDY, there seems to be some issues that need to be discussed and agreed before we can say it is ready to be made a standard.

According to the HTTP bis group schedule, they are expected to re-charter to work on HTTP/2.0 in August 2012. So lets wait and see what happens then.

Who uses SPDY already?

Despite SPDY is not yet the definitive HTTP 2.0 protocol specification, it has been in use since 2009 when it was announced. Google services like the Google search has been one of the most used site to use SPDY.

Obviously Google Chrome was the first browser to support it. After all, SPDY is one of the main secrets of the speed of Chrome, at least to access Web servers that also support SPDY. Recently Firefox also added support to SPDY.

A less known fact is that before Firefox, the Silk browser that ships only with the Amazon Kindle Fire tablet devices also use SPDY. This was actually a clever deployment of the SPDY protocol. Let me tell you more on why is that.

It would not be a great gain to use SPDY while the Web servers around the world do not also support SPDY. So, instead of making the Silk browser access the Web directly, HTTP/SPDY request are directed to Amazon servers that act as proxies. They retrieve the actual remote Web server content and optimize it to deliver to the Silk browser only via SPDY.

I never used the Silk browser because I do not own a Kindle Fire tablet yet, but it is not hard to imagine how much faster it can be by default, regardless if the site you are accessing supports SPDY or not.





Other than Google and Amazon sites, one of the largest deployments of Web servers that support the SPDY protocol is Twitter.

Using SPDY today with mod_spdy

If you want to start using SPDY in your sites, Google is providing mod_spdy, which is basically a module that allows you to implement SPDY on an Apache Web server.

The nginx Web server is also expected to support SPDY later in May.

HTTP 2.0 and PHP

Now that you have learned about SPDY and the expectation that it will become HTTP 2.0, you may be wondering if this will affect your PHP applications in a way that you need to change them.

As you may read above, there is nothing for you to be concerned. The spirit of HTTP 2.0 is that it will not affect your applications. The way SPDY/HTTP 2.0 work is that the data that Web applications send and receive does not change regardless if SPDY or HTTP 1.x is being used.

This is one of the topics we commented on the last episode of the Lately in PHP podcast recorded last week. By the time this article is being written, the recording is not yet available because we are waiting for the transcription to be finished.

Meanwhile you may watch the Lately in PHP podcast page when it is published in the next days. This time we recorded it in video, so it may more interesting to watch than before. Audio-only recording will also be available as usual.

Conclusion

Before the closing remarks, I would like to clarify that despite many aspects of the proposals are not trivial to understand, I did my best to learn what they mean and translate it into explanations that the majority of the readers can understand. However, it is possible that may have misunderstood an aspect here and there, and so I may have stated something in this article that is not accurate. If you find that to be the case, feel free to post a comment to point that out, so everybody can be clarified.

Finally, the HTTP 2.0/SPDY protocol looks very promising to make the Web faster and more efficient in general, so it will make more viable to implement Web applications that we probably have not thought in the past.