The Next Generation HTTP Protocol (HTTP 2.0) for Enterprise Applications

I will talk in this blog about the next generation HTTP Protocol (HTTP 2.0) and put special emphasis on the implications for enterprise applications. Starting with the challenges and recent improvements to the HTTP protocol, such as WebSockets, I will describe the current state of the HTTP 2.0 specification. Finally, I will discuss implications for distributed web applications and enterprise service bus/complex event processing based enterprise applications. The WebRTC protocol is seen complementary to the HTTP 2.0 specification.

Introduction

The recent version of the HTTP protocol is 1.1 and is used by most of the web servers, proxies as well as browsers on the Internet. The main difference to HTTP 1.0 is that a connection can be reused, i.e. each request for a resource, such as image or HTML files, uses the same connection without the overhead of creating a connection for each of them. This already shows the need to reduce the number of connections to avoid overload of firewalls or the network stack.

Furthermore, new protocols have emerged based on HTTP. Their goal is to support real-time applications, such as collaborative editing (cf. Apache Wave). Other examples can be found in the area of adaptive streaming, such as apple live streaming. Clearly, these new killer application required adaptation to the existing HTTP protocol standard. I will briefly describe these applications and explain why these adaptations are still somehow flawed and require a new standard: HTTP 2.0.

Applications

Real-Time

Real-time applications require a permanent connection to a web server to push events or data to the server. Contrary to the standard request-response approach the connection is never terminated. The underlying assumption is that the application does not know exactly how much data needs to be transferred when to the server. However, data transfers occur frequently. One example is collaborative editing: There, we need to transfer text additions, changes, removals to the server and ultimately to other participants in the collaborative editing sessions. More advanced collaborative editors may also transfer other events, such as clicks or highlighting text. Given the context of real-time applications, the WebSocket standard has been developed. This standard enables a permanent connection for the aforementioned purposes. Basically, it uses HTTP 1.1, but does not transfer a lot of header information (see also example of a standard HTTP request below). Mostly JavaScript applications leverage this standard. For compatibility reasons the JavaScript libraries sock.js or socket.io/engine.io support a similar approach which works for older browsers or proxies. This is based on various techniques, such as XHR polling.

Media Streaming

Many popular live video streaming protocols are based on HTTP, such as apple live streaming or MPEG DASH. Basically they offer a list of links to chunks (short media blocks of few seconds length) of the media stream. These chunks are then downloaded via HTTP.

Challenges

Although we identified already some improvements with respect to HTTP 1.1, there are several issues with the current HTTP protocol:

1. Communication is text-based

2. No prioritization of data streams

Communication is Text-based

If we look at a standard request response then we see that there is a lot of over-head due to the fact that the communication is human-readable.

This can be seen from the following requests (via Google Chrome):

HTTP Example Request (Assumption: connection to server www.wikipedia.org established)

GET / HTTP/1.1
Host: www.wikipedia.org
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.70 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*

HTTP Example Response

Age:428
Cache-Control:s-maxage=3600, must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Length:11603
Content-Type:text/html; charset=utf-8
Date:Tue, 12 Feb 2013 22:36:12 GMT
Last-Modified:Mon, 11 Feb 2013 01:58:47 GMT
Server:Apache
Vary:Accept-Encoding
X-Cache:HIT from amssq38.esams.wikimedia.org
X-Cache:HIT from knsq24.knams.wikimedia.org
X-Cache-Lookup:HIT from knsq24.knams.wikimedia.org:80
X-Cache-Lookup:HIT from amssq38.esams.wikimedia.org:3128
X-Content-Type-Options:nosniff

[..] (content of the html page)

All attributes and values are human-readable. Thus, they consume a lot of overhead for transferring them each time we make a request and receive a response. Clearly this is a problem for real-time or media streaming applications. Furthermore, there is overhead when parsing them for further processing.

No Prioritization of Data Streams

The underlying assumption of HTTP is that all data streams have the same priority. However, this is not true for all applications. Let us imagine you upload several large images for your collaborative editing application. At the same time you modify some text. This can mean that the other users in the collaborative editing session won’t see the updated text until the images are uploaded. Clearly this is an undesirable situation.

The Current State

If we imagine further applications, such as an enterprise service bus, which can be based on web services/SOAP services or REST services, then we can see a lot of room for improvement. Hence, some big vendors have developed proprietary HTTP extensions:

• Google developed the SPDY protocol
• Micosoft proposes the Speed + Mobility protocol

SPDY by Google has been used as a first draft for the new HTTP 2.0 protocol, which is in process of being standardized by the IETF. Microsoft approach seems to be based on SPDY, but makes some parts of it optional to take into account mobile devices, which have limited resources and should, for example, only deal with encrypted content if necessary. Microsoft proposed extensions have been submitted to the IETF to be taken into account for HTTP 2.0

The main improvements of SPDY compared to the HTTP 1.1 protocol are the following:

• Reduce the overhead of HTTP by tokenizing headers, compressing data or remove unnecessary headers.
• Single data channel for multiple request (multiplexing). This has been to some extent already part of HTTP 1.1.
• Prioritization of data (e.g. text editing events have higher priority than image upload events).
• Server can push data to the client or suggest data to the client to be requested.
• Further security features.

Luckily SPDY is designed in a way that it is backward-compatible. It only changes the way how HTTP data is transmitted, but existing applications do not need to be modified. The underlying assumption is that there is a translator in the middle (e.g. a proxy or directly provided by the application/library). More advanced features/applications have to implement HTTP 2.0 natively to control and leverage all features.

At the moment the following browsers implement SPDY:

• Google Chrome

• Mozilla Firefox

• Opera

• Amazon Silk (Cloud Browser)

Some proxies, such as NGINX, support SPDY. Furthermore, first popular web pages implement SPDY.

Implications

Clearly, the design of HTTP 2.0 has many interesting implications. Firstly, we note that HTTP 2.0 is not purely an application layer protocol as it is described in the OSI network layer architecture. It is partly a session, presentation and transport protocol.

Secondly, we can see that prioritization of data streams is an extremely powerful feature. Especially, if we consider not only one application, but several applications integrated via an enterprise service bus. The enterprise service bus can be also compared with some kind of advanced HTTP 2.0 proxy. Imagine premium customers connected via a web site. The website is integrated with the CRM and production system via the enterprise service bus. Interactions with these customers via the web site are prioritized over to interactions with basic customers.

Thirdly, complex event processing application can leverage the speed improvements of HTTP 2.0 over HTTP 1.0 and analyze streams as well as correlate events in different streams over different users.

HTTP 2.0 may have the potential to replace not only HTTP 1.1, but also other protocols, in the future. Support and implementations of major software vendors demonstrate the seriousness of HTTP 2.0.

At the same time, we see further protocols emerging, such as the WebRTC protocol. The WebRTC protocol is a browser-based peer to peer protocol for voice/video chat and real-time applications. It is thus not server-based. Hence, it can be seen as complementary to the HTTP 2.0 protocol.

In the future WebRTC and HTTP 2.0 may also be combined to HTTP 3.0 to fulfill the vision of a truly decentralized Internet architecture.