HTTP as a protocol has done pretty well so far. Initially intended to be a delivery medium for scientific data and documents, HTTP has become "The Web / The Internet" for most people and the content being transmitted via HTTP has changed a lot from its initial days.

There are two limitations in particular that some modern proposals attempt to overcome:

- request based nature of HTTP: The server will not be able to notify the client of new data
- latency: HTTP uses pretty extensive headers and isn't exactly latency friendly.

Google in particular has put out a number of proposals to address some of these challenges:

1 - Sending HTTP request data on SYN

The TCP RFC always allowed to send data on SYN, but nobody really attempted to do it... ever. A standard HTTP request is typically a couple of hundred bytes in size. It is unlikely that it will get fragmented, and it would make sense to send it as part of the SYN packet, removing the overhead (in particular latency) caused by properly establishing the TCP connection first. Establishing the full 3 way handshake will easily add 100ms to a new connection on a well connected server.

However, if you have ever done any kind of IDS work, the idea of sending data on SYN probably doesn't sound all that comforting, and I would assume that many firewalls/IPSs/IDSs will not allow data on SYN to pass unnoticed.

2 - Compressing HTTP headers / SPDY

Most browsers will support compressing the HTTP body. However, they do not support compressing HTTP headers right now. A proposal to frame HTTP requests called "SPDY" (pronounce speedy), among other features, includes the ability to compress HTTP headers. This should be in particular interesting for asymmetric internet connections with little upstream bandwidth.

SPDY in itself is probably worth a future diary as it provides a lot more then just compressed headers. It is implemented (but turned off by default) in recent versions of Chrome and Firefox). Twitter starts using SPDY so does Google on select pages. Interestingly, SPDY is currently only used over SSL. 

3 - Websockets

Websockets (in addition to SPDY) are an attempt to allow the web server to notify the client about new events. Think about web mail or instant messenger software notifying you of a new message. The web sockets specification has had a rough start, but got finalized last November. It starts to see some use on social networking websites.

4 - Speed + Mobility

Microsoft came up with its own proposal: Speed + Mobility . So far, I am not aware of any implementations of it, and it may be pre-empted by SPDY as it directly competes with SPDY.  

Looking further ahead: All of this (SPDY, S+M...) may ultimately become HTTP 2.0. HTTP 2.0 is specifically going to address performance issues, and SPDY as well as S+M are trying to address these.

[1] http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html
[2] http://dev.chromium.org/spdy/spdy-whitepaper
[3] http://blogs.msdn.com/b/interoperability/archive/2012/03/25/speed-and-mobility-an-approach-for-http-2-0-to-make-mobile-apps-and-the-web-faster.aspx

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter