Today the Internet has faced a very large and dynamic growth, both in size and number of users. As not only universities or research centers are the major users, but it is also accessible from the homes, it has gained a huge popularity. This could be caused not only by the technological improvements but also the user-friendly and accessible applications.
We can observe a shift from the almost exlusive use of telnet, email, ftp to the increasing demand and use of http, real-time and multimedia applications. One of the most popular part of the Internet is the WWW (World Wide Web). Homepages are visited and viewed using the HTTP (HyperText Transfer Protocol).
In communications there was developed a standardized model of the architectures used, called the OSI (Open Systems Interconnection) model. It consists of 7 layers built upon each other, forming a so-called protocol stack: application, presentation, session, transport, network, data-link and physical layers. However, as we'll focus on HTTP, which is built upon the TCP/IP protocol suite, we'll consider the protocol model of the TCP/IP, which is organized in a slightly different way. Its components are : application, transport, internet, network access and physical layers.
The physical layer deals with the physical interface used between the physical device and the transmission media. Due to new technological achievements, transmission is getting faster and bandwith is getting larger. A typical example is the optical fiber. At this level further improvements are possible using better integration. In our specific case this means faster modems with larger buffers, connecting to larger bandwith networks.
The network access layer provides connection between an end user and a network. It can provide different services, like priority and must be able to identify the different machines, as well as route information towards them.
The function of the internet layer is to connect different types of networks. It makes possible the communication between machines sitting on different kind and possibly remote networks. As example is the IP protocol, which makes all these possible.
The transport layer achieves exchange of data between end-systems. In the TCP/IP protocol suite there are two known protocols : TCP and UDP.At the application layer we can find the applications, that is the end-part of the whole system, which is visible for the user.
In order to achieve better performance, the best way to do is by finding possible improvements at all of these layer levels , as well as on their border, i.e. try to find a better interaction between these layers by means of improving the interaction between the protocols on different layers.
HTTP is a simple, request-reply interactive protocol, used by the WWW to retrieve distributed objects. It uses the TCP as transport protocol, because it offers a reliable service in contrast to UDP, which is unreliable. We need this reliability, because we neeed that the data retrieved be correct.
TCP (Transmission Control Protocol) is a connection oriented transport protocol, which provides flow end error control as well. It first establishes a logical connection between the end-users, then carries out the transmission of data and finally it closes the connection. Connection establishment is done by a three-way handshake mechanism in order to avoid errors which could occur due to some lost data packets during the setup period. It is performed in the following way : the requesting end sends a synchronization segment with its own initial sequence number(ISN). Then the other end responds with another synchronization segment with its ISN, acknowledging in the same time the requesting end's initiative. The 3rd step is done by the requesting end, acknowledging the responding end's will. Connection termination requires an even longer time, because it is done in 4 steps. After one end has signalled that it's closing the connection, the other end must acknowledge it. This stands for both ends.
It was found that HTTP's main weakness is that HTTP opens a new TCP connection for each transaction (request/reply) it carries out. Typically a user once retrieveing a hypertext document, it follows a link further on. This implies the opening of new TCP connections. The problem is that generally a hypertext is not only a simple text, but it consists of several images or other elements. To retrieve them, new TCP connections are needed for each of them. So for each of them another three-way handshake must be performed, thus introducing significant delays. This is one of the drawbacks of using TCP for HTTP.
Another problem is related to TCP's flow control mechanism. To clarify things, first a few basic notions must be discussed. TCP uses the sliding window protocol to transmit data. This means that there exists a window at the sender's side and one at the receiver's side. The sender is able to send data up to the amount it advertises and the receiver can buffer data up to its own advertized window size. But in order to not cause congestion in the network by just bursting out data, TCP uses an algorithm to cotrol the data flow : the slow start. A new window, the congestion window is introduced. This is initialized to one segment when a new connection is established or some error occured. For each ACK received, the congestion window is increased by one segment. The sender can send the minimum of it's own window and the congestion window. The problem with the use of the slow start algorithm in TCP for HTTP is that each time a new connection is established, data transmission begins with a low rate, thus limiting the performance.
In order to avoid the above described shortcomes, new protocols, such as T/TCP and P-HTTP were develped. P-HTTP (Persistent HTTP) doesn't open a new connection for each transaction, but leaves the first connection opened. Thus both the slow-start algorithm and the initial 3-way handshake are avoided for all the transactions but the first. The disadvantage of leaving a connection open might be that is such a case the server's performance decreases if a large number of connections are up. Leaving a connection opened arises another question : how long should it be left in that state? If it is too long, appears the risk that there was some error on the way or maybe the other end had crashed and that is the reason why there are not coming further requests. On the other hand, if duration of a connection is limited to a too short time, that might happen that the user at client hadn't finished yet the processing of the last retrieved document when suddenly the connection is closed by the server.Leaving half-open connections is a waste of resources, while disconnecting too early the performance is decreased. A possibility to decide about how long should a connection last is to use the keepalive option provided by TCP. This could be done by setting the keepalive timer at the server's side. This must be done at this side, because the server must check if the client is still alive or not. It is the server which gains more by closing down half-open connections. Today TCP's keepalive timer is set to 2 hours, which is a reasonable value for this purpose - in that time any user should be able to process a requested document and decide on whether to issue a further request. Another feature of persistent HTTP is that it provides pipelineing, by means of which multiple requests can be issued at the same time. Thus all the elements included in a hypertext document can be retrieved at the same time. T/TCP (Transactions TCP) tries to improve performance by caching information about hosts (e.g. RTT) to avoid the 3-way handshake and slow-start. Actually P-HTTP and T/TCP behave in quite a similar way. But of course when setting up the first connection, they have to do a regular setup, with both 3-way handshake and slow-start.
Another problem of the slow start is that the congestion window size is increased based on the number of received ACKs and not the number of acknowledged segments. There is a difference between these two numbers due to TCP's delayed acknowledgment algorithm. Let's have a look what happens when this algorithm is operating : TCP, hoping that there will be some data needed to be sent to the other side, not only the ACK, waits a while. If it really exists some data, then the ACK can be 'piggybacked' with it. If there is no data waiting to be sent, TCP will not wait forever, but it uses a timer, which goes off every time a predefined period has expired. TCP timers are usually set to 200 ms or 500 ms and go off periodically relative to bootstrapping time.
However, in HTTP, this delayed acknowledgement algorithm is not necessary, but even more, it has a negative effect. Typically, in HTTP, after the 3-way handshake is performed, first a request is sent by the client. This must be acknowledged by the server. While sending the request, the server doesn't have any data to transmit, only the acknowledgements. After it received the request, it must send the retrieved data. This time the client is the one who doesn't have any data to send together with the acnowledgments. So all the time TCP, due to its delayed-acknowledgement algorithm is just waiting in vain, until the timer expires. A possible solution to this problem would be to disable this delayed-acknowledgment algorithm, so we could achieve that the slow-start algorithm works in practice as it should work theoretically.
Until now there has been discussed some problems of using HTTP over TCP during connection establishment and data transfer. Let's have a look now on what happens when a connection is terminated. At connection termination usually one end sends a FIN, signaling that it wants to close. At this end an active close is performed. The other end, which performs the passive close, must acknowledge this FIN. But the first end, by doing the active close, enters the so-called TIME_WAIT state, which is normally the double of ' the MSL (maximum segment lifetime). This state is necessary in order to resend the final ACK if it gets lost on the way. The problem with this TIME_WAIT state is that during it the socket pair of the connection (both end's IP address and port number) are in use. In HTTP, as the active close is performed by the server after sending the requested data, this means that each time a connection is terminated, the server is the one left in the TIME_WAIT state. Thus the server's resources can't be reused for this given time. This can create bottlenecks and limit performance. A possible improvement could be achieved if the active close would be performed by the client. That is when the server finishes transmitting data, it just waits for the client's active close. So the client when acknowledges the last data packet received, emits a FIN. In this way it would be client who enters the TIME_WAIT and thus the server's operation can be optimized.
To this point we have considered only error free cases. But errors can occur. TCP achieves reliability by a strong error-handling mechanism. Lost packets are retransmitted. In most of the cases packet loss occurs due to congestion somewhere on the network. TCP observes this by getting multiple acknowledgements or if a retransmission timeout has occured. This problem is handled by the congestion avoidance algorithm. When congestion occurs on the network, the rate of data transmission must be decreased. This is done by using an additive increase of the congestion window instead of the exponential increase, which happens when slow-start operates. The congestion window is increased by 1/cwnd for every ACK received. But in fact the congestion avoidance and the slow-start algorithm are used together. Another variable is introduced : the slow start threshold size (ssthresh). Depending on it's relative value to cwnd, slow start or congestion avoidance is performed. Because a congestion source can be the presence of bottlenecks on the path between the 2 communicating ends (e.g. a slower link portion - a modem line connected to a fast network), it could be an improvement to use a proxy server at the point where the modem line is connected to a fast, large-bandwith network.
A proxy operates somewhere on the path between the client and the server. For the client it appears to be like a server, while for the server it appears to be a client. By opening a connection from a client through a modem line to a proxy, we could avoid the case when large amount of data coming from a fast network causes congestion on the modem line. Using path-MTU discovery, the MSS from the proxy to the client can be determined from the beginning and data transmission can be done according to it. If it wasn't used a proxy, the larger packets should have been fragmented somewhere on the way or there should be used smaller packets through the whole transmission. If there are several clients accessing the network by a modem line, their traffic requires small packet sizes, due to their small bandwith lines. If there is a proxy, and all these clients are connected to the proxy instead, then low speed traffic is carried out only between the clients and the proxy. This means that they don't slow down the otherwise fast network. Even if the clients don't support persistent HTTP, but the server does, by placing a proxy between them, which also supports persistent connections, significant improvements are possible. In that case the proxy will open regular HTTP connections with each of the clients, while on the other side maintaining one or several persistent ones with the servers. If requests coming from different users are addressing the same server, by holding one connection open to that server, the proxy acts like a kind of multiplexer-demultiplexer. It collects all the requests, transmits and when receives the responses it just re-distributes between the clients. By opening only one connection to a specific server through a proxy, and not several from a number of clients, the network is not overloaded by an excessive number of packets, for example the initial SYN and ACKs and further ACKs. Also the server gains at connection termination. If the server must do the active closes, if it has to close only one connection instead of several, only one connection is left in the TIME_WAIT state. So only one socket of the server can't be reused for a 2 MSL period of time. A similar gain can be observed at connection establishment as well: the 3-way handshake is performed only once. The same stands for the slow start algrithm, too. By this a better utilization of the network is possible. The gain by the usage of a proxy is greater if clients having similar interests or requesting similar type of documents are connected to it. Finally, the disadvantage of the proxy-utilisation must be named, too. In the case the proxy crashes, all the clients are affected and thus can't reach the network.
We have had a look to how HTTP operates, to the interaction between HTTP and TCP. We had also discussed the performance improvements achieved by using persistent connections, which are already implemented in HTTP/1.1. There were proposed some ideas concerning further improvements, as well as the use of a proxy when accessing the network via a modem. As the Internet is showing a further growth, it is very important to develop faster, but still reliable procols in the future.
TCP/IP Illustrated, Volume 1, by W. Richard Stevens
Simon E Spero, Analysis of HTTP Performance problems
Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance",USC/Information Sciences Institute, August 16, 1996, Initial Release, V1.2
John Heidemann, Katia Obraczka, and Joe Touch. Modeling the Performance of HTTP Over Several Transport Protocols. IEEE/ACM Transactions on Networking 5(5), October 1997. November, 1996.
John Heidemann, Performance Interactions Between P-HTTP and TCP Implementations. ACM Computer Communication Review, 27 2, 65-73, April, 1997.
R.Fielding, HTTP/1.1 - Internet draft, February 20, 1997