1. Problem Statement

The current implementation of the HTTP protocol uses TCP/IP as the transport protocol and sends each object on a web page separately to the client. The TCP/IP protocol incurs a great amount of overhead with a three-way handshake for every connection opened and packets are sent essentially serially over the network, with an acknowledge packet sent for every packet received. This potentially doubles the amount of packet traffic over a network and causes unnecessary overhead on small networks. Added to that, the requirement to send every object on the web page individually causes most of the slowdown when requesting a page with a lot of small images.

There exists a different transport protocol that is often used on small networks. UDP/IP (User Datagram Protocol / Internet Protocol) dispenses with most of the overhead of TCP/IP, resulting in a much faster but less reliable transport protocol. Because of this it was originally decided to do HTTP over TCP/IP in stead of over UDP/IP. Reliability in small networks, however, has increased dramatically since the design of HTTP. Because of this, there is a gap that needs to be filled and this is where the proposed protocol comes in.

It is also unknown whether lumping all the objects on a web page at the server level and sending them as a single object would increase performance markedly. On small networks a lot of unnecessary overhead is created when connections are made and broken for multiple objects. Reliability is normally very high and a single large object would be transmitted more efficiently than a number of smaller objects.

The proposed system should be transparent to the user and improve performance in some way at least when requesting web pages over a small network. It should be compatible with current software and be easily implemented on various architectures.

2.1 General Description of the Functions the System Should Perform

• Provide a standard TCP/IP interface to the application requesting the web page;
• Provide a method of falling back to the standard TCP/IP protocol should the system prove ineffective;
• Provide a reliable method of transferring data;
• Be portable to various architectures.

2.2 Value System

The following lists in order of importance the goals to be achieved during the course of this project:

1. Reliability;
2. Speed;
3. Compatibility;
4. Extendibility.

2.3 Criteria for Success

Success is achieved when a product has been delivered that is able to execute on a server and client and allows communication between them using the newly designed protocol. The protocol's functionality is paramount and the system has to decrease network traffic over a small network to succeed.

4. System Specifications

5. Deliverables

On completion of this project the following would be delivered:

1. A protocol description in RFC format that details the working of the improved HTTP protocol;
2. A program that either replaces a normal HTTP server, or adapts an existing server to act as a server for the newly designed protocol.;
3. A program that either replaces a normal HTTP browser, or adapts an existing browser to act as a client for the newly designed protocol;
4. Evidence to prove the efficiency of the protocol in low loading conditions on a small network;
5. A design report detailling the modifications made (if any) to existing software and/or development of new software.

Higher than average marks should be in order for a working system that outperforms an existing setup on virtually all levels.