Modularity is an important kind of simplicity, and HTTP 1.x isn't very modular. If we look carefully at HTTP 1.x, we can see it addresses three layers of concerns, but in a way that does not cleanly separate those layers: message transport, general-purpose remote method invocation, and a particular set of methods historically focused on document processing (broadly construed to include things like forms processing and searching).

The lack of modularity makes the specification and evolution of HTTP more difficult than necessary and also causes problems for other applications. Applications are being layered on top of HTTP, and these applications are thus forced to include a lot of HTTP's design, whether this is technically ideal or not. Furthermore, to avoid some of the problems associated with layering on top of HTTP, other applications start by cloning a subset of HTTP and layering on top of that.

The HTTP-NG protocol is a new architecture for the Web infrastructure based on a layered approach where HTTP is split up in layers as depicted in the diagram below:

The single HTTP-NG connection is divided up into multiple virtual sessions, each of which can carry a requested object in parallel. These are asynchronous, so a client can fire off multiple requests without waiting for the request to be acknowledged, let alone wait for the object to be sent.

There is a dedicated control session, similar in application to the separate control connection in the FTP protocol, which is used to send all the requests and to receive meta information (author, copyright details, costs, or redirection requests to use a special external connection, for example for live video over an ATM link).

HTTP is a text based protocol. This makes it easy to debug. However all those text headers means that there is considerable overhead when transporting small objects around. The transport is 8 bit capable, so it could cope with binary data and indeed does so for the object bodies. Only the headers are text based.

HTTP-NG uses a binary protocol, encoded in ASN.1 and made even more compact by using Packed Encoding Rules (PER). What this means is that a typical request is very small, but looks like random garbage until you decode it.

Each individual message within an HTTP-NG connection can be authenticated. The security method is not part of the protocol, so any method that both the client and the server support can be used, individual messages can use different authentication schemes if needed. The encrypted data can be securely carried across untrusted intermediate proxies.

Related to the challenge response model of authentication, a server can notify a client that a requested service will incur a fee, sending the cost and a list of acceptable payment methods.

The current status of HTTP-NG is as an experimental prototype. It has been tested between a pair of machines over a transatlantic link, and shown to perform well, utilising the entire available bandwidth. In contrast, HTTP 1,0 was only able to effectively use around a tenth of the available bandwidth. As predicted, the performance of HTTP-NG did not degrade as badly as HTTP in congested conditions, it performed significantly better than multiple concurrent connections such as would be made by a modern multithreaded browser.

All initial HTTP-NG requests are also valid HTTP 1.0 requests, but use an invalid access method. This means that an HTTP-NG enabled client can initiate a request with a server and continue it with HTTP-NG (if that is supported) or receive an error response and try again with HTTP 1.0 on the same port.