The HyperText Transfer Protocol, abbreviated to HTTP, is a protocol for request-response based communication between a client and server over the internet, and is used by the world wide web following it's adoption in 1990. HTTP communicates via the TCP/IP networking protocol, although it can just as well be used over any other type of connection based network. The original HTTP specification is referred to as HTTP 0.9, which was superseded by version 1.0. The latter version is the one currently in use, although HTTP 1.1 is now starting to be deployed (in fact it is already supported by the most popular web browsers such as Netscape and Microsoft Internet Explorer).
When a client requests a resource from a server it first opens a new TCP/IP connection using the appropriate domain name, IP number and port number. A port number need not be provided, in which case a default port number of 80 is assumed. The client then places the request by issuing the word "GET" followed by the document address. Then the client must wait for a reply from the server, which is in HTML format for HTTP 0.9. The version 1.0 response will contain an HTTP version number, a result code, an optional message (used for errors etc.) and optional content type and length etc, followed by the document data. After the transaction is complete the TCP/IP connection is closed. Further requests follow the same pattern, with a new TCP/IP connection being made for each one. In the case of a web page consisting of text and pictures for example, there will be a request/reply transaction of this type for each picture and for the text. This is illustrated in the diagram 1 below.
HTTP version 1.0 suffers from poor performance particularly if the part of the network being accessed is busy. Hotspots of congestion often form on the world wide web around popular sites, which not only slows down access to those sites but also to other sites nearby. One reason for the poor performance is due to HTTP 1.0 making a new TCP/IP connection for every request, resulting in a significant overhead associated with opening those connections, and the inability of the client to send further requests until the reply to the previous one has been received. TCP/IP employs a three-way handshaking system to open a connection, where the client makes a request, waits for a reply from the server and acknowledges that reply. As a result, regardless of the bandwidth of the network, the connection overhead depends on the round trip time for the request to reach the server and the reply to get back to the client. This round trip time is dictated partly by the physical distance between client and server, as well as the speed of light. Until the world's physicists find a way of sending signals at superluminal velocities, this limiting factor will always be present. So on a fast network, an HTTP 1.0 client may spend most of it's time waiting for it's requests to be responded to, rather than transferring useful data. This makes very poor use of the network capacity - see diagram 2 below for an illustration. Another related problem is that the TCP/IP specification states that the server must hold information about each connection for a given time after closure, just in case a late packet should turn up. Due to the large number of connections made in an HTTP 1.0 session, the server may run out of space to store information on each connection if the network is very busy.
Another inefficiency with HTTP 1.0 lies in how it interacts with TCP/IP. A TCP/IP network breaks up the data into segments which are sent individually to the receiver, which returns an acknowledgement for each one. To improve performance, up to a certain number of segments can be sent without waiting for acknowledgement. The receiver tells the sender what this number is, the upper limit depending on the size of it's buffers. However, too many unacknowledged segments can congest the network, so TCP/IP uses a system called 'slow start'. This system initially allows only one segment to go unacknowledged, and if it arrives okay then the number of segments that can be sent before acknowledgement is increased. If a segment is lost in transit due to a time-out, this number is decreased. The system will eventually settle at the optimum value. However, due to the typically large number of short connections for HTTP 1.0, the slow start mechanism doesn't get time to reach it's equilibrium state, so transfer is not very efficient.
A common way of relieving congestion around hotspot sites is by providing duplicate sites at other locations, that are updated along with the original. For example, duplicating a site in the US and Europe prevents US users from having to access the European one and vice versa, so intercontinental traffic is reduced. Cacheing is also very effective, the cache usually being at the client end of the network, for example in a proxy server for a Local Area Network. This cache would hold a copy of frequently accessed sites, which must be updated to reflect changes in the originals. A number of methods can be used to do this, for example it can be left to the client to check how old cached files are (and load them from the original source if they are too 'stale'), or the actual server can actively notify the caches when the originals have changed. HTTP 1.0 provides crude facilities for cache validation, by means of the 'if modified since' request. This is used by most current cacheing systems. The cache would make this request periodically to check whether the cached data has changed sinced it was loaded into the cache.
The need for an improved HTTP protocol - HTTP 1.1Even with cacheing and replication, HTTP 1.0 can still suffer serious congestion. What is needed is a more efficient HTTP that doesn't make so many TCP/IP connections - even if this won't clear the congestion it will help. HTTP 1.1 addresses this problem with support for persistent connections, and it also provides better facilities for cache validation so that caches can be used where they otherwise would not have been before. Persistent connections allow many requests to occur within a single TCP/IP connection, which can be kept open continuously. HTTP 1.1 also allows the pipelining of requests so that further requests can be made before the responses to previous ones have been received. The improvement from this is illustrated in diagram 3. HTTP 1.1 also has support for data compression, using the content-encoding and accept-encoding headers to specify a compression scheme such as LZW or LZ77. Data is pre-compressed, and decompressed on the fly by the client. Data compression is useful particularly when lots of data is being downloaded in a single object, and if the network bandwidth is low. HTTP 1.1 also requires that a URI or Uniform Resource Identifier is supported by a host, which was not necessary in version 1.0. This has the advantage that multiple web sites can be hosted from a single IP address, which was not possible before. HTTP 1.1 is certainly an improvement over HTTP 1.0, but it is only a temporary fix for an ever growing network.
Eventually a completely redesigned system would be needed to handle increased world wide web traffic, rather than an extended version of HTTP 1.X. Such a system is HTTP Next Generation, or HTTP-NG, which is an enhanced HTTP. It makes use of persistent connections as in HTTP 1.1, but divides it into a number of virtual connections that are asynchronous. This enables transactions to be pipelined, and several transactions can go on in parallel in different virtual sessions (see diagram 4). Another refinement in HTTP-NG is the use of a binary rather than text based protocol. The text headers in HTTP 1.X are replaced by headers in ASN.1 (abstract syntax notation) format, using Packed Encoding Rules to reduce their size further. ASN.1 is a bit like a type declaration in a programming language, which can be encoded numerically in Tag-Length-Value form. The Packed Encoding Rules allow tags and lengths to be omitted where possible, storing the ASN.1 information to be encoded as compactly as possible without ambiguity. The advantage of ASN.1 over text headers is that the ASN.1 headers are very small, so the exchange of small objects is less affected by the request overhead. HTTP-NG also includes support for encryption and authentication, and individual messages can be authenticated even if they have been transferred via an untrustworthy intermediate host. Support for electronic cash is also present, so that shopping on the world wide web will be more feasible. HTTP-NG is still only in prototype stages, and has not yet been deployed on the internet. Initially it is likely to be used in the main bottlenecks of the web, such as the trans-atlantic link, before it comes into general use. When it does become as widespread as HTTP 1.0 is today, we can look forward to a substantial increase in the speed and usability of the world wide web.
