In this section, we give a brief overview of the working of a typical HTTP server on a machine with a Unix-based TCP/IP implementation. The description provides background for the discussion in the following sections. For simplicity, we focus our discussion on a BSD [14, 32] based network subsystem. The working of many other implementations of TCP/IP, such as those found in Unix System V and Windows NT, is similar.
Figure 1: HTTP Connection Establishment Timeline
In the HTTP protocol, for each URL fetched, a browser establishes a
new TCP connection to the appropriate server, sends a request on this
connection and then reads the server's response
. To display a typical Web page,
a browser may need to initiate several HTTP transactions to fetch the
various components (HTML text, images) of the page.
Figure 1 shows the sequence of events in the connection establishment phase of an HTTP transaction. When starting, a Web server process listens for connection requests on a socket bound to a well known port--typically port 80. When a connection establishment request (TCP SYN packet) from a client is received on this socket (Figure 1, position 1), the server TCP responds with a SYN-ACK TCP packet, creates a socket for the new, incomplete connection, and places it in the listen socket's SYN-RCVD queue. Later, when the client responds with an ACK packet to the server's SYN-ACK packet (position 2), the server TCP removes the socket created above from the SYN-RCVD queue and places it in the listen socket's queue of connections awaiting acceptance (accept queue). Each time the WWW server process executes the accept() system call (position 3), the first socket in the accept queue of the listen socket is removed and returned. After accepting a connection, the WWW server--either directly or indirectly by passing this connection to a helper process--reads the HTTP request from the client, sends back an appropriate response, and closes the connection.
In most Unix-based TCP/IP implementations, the kernel variable
somaxconn limits the maximum backlog on a listen socket. This
backlog is an upper bound on the sum of the lengths of the SYN-RCVD
and accept queues. In the context of the discussion above, the server
TCP drops incoming SYN packets (Figure 1, position
1) whenever this sum exceeds a value of 1.5 times the backlog. When the
client TCP misses the SYN-ACK packet, it goes into an exponential
backoff-paced SYN retransmission mode until it either receives a
SYN-ACK, or its connection establishment timer
expires.
The average length of the SYN-RCVD queue depends on the average round-trip delay between the server and its clients, and the connection request rate. This is because a socket stays on this queue for a period of time equal to the round trip delay. Long round-trip delays and high request rates increase the length of this queue. The accept queue's average length depends on how fast the HTTP server process calls accept(), (i.e., the rate at which it serves requests,) and the request rate. If a server is operating at its maximum capacity, it cannot call accept() fast enough to keep up with the connection request rate and the queue grows.
Each socket's protocol state is maintained in a data structure called
a Protocol Control Block (PCB). TCP maintains a table of the active
PCBs in the system. A PCB is created when a socket is created, either
as a result of a system call, or as a result of a new connection being
established. A TCP connection is closed either actively by one of the
peers executing a close() system call, or passively as a result
of an incoming FIN control packet. In the latter case, the PCB is
deallocated when the application subsequently performs a close()
on the associated socket. In the former case, a FIN packet is sent to
the peer and after the peer's FIN/ACK arrives and is ACKed, the PCB is
kept around for an interval equal to the so-called TIME-WAIT period of
the implementation. The purpose of this TIME-WAIT state is to be able to
retransmit the closing process's ACK to the peer's FIN if the original
ACK gets lost, and to allow the detection of delayed, duplicate TCP
segments from this connection.
A well-known problem exists with many traditional implementations of TCP/IP that limits the throughput of a Web server. Many BSD based systems have small default and maximum values for somaxconn. Since this threshold can be reached when the accept queue and/or the SYN-RCVD queue fills, a low value can limit throughput by refusing connection requests needlessly. As discussed above, the SYN-RCVD queue can grow because of long round-trip delays between server and clients, and high request rates. If the limit is too low, an incoming connection may be dropped even though the Web server may have sufficient resources to process the request. Even in the case of a long accept queue, it is usually preferable to accept a connection, unless the queue already contains enough work to keep the server busy for at least the client TCP's initial retransmission interval (6 seconds for 4.4BSD). To address this problem, some vendors have increased the maximum value of somaxconn and ship their systems with large maximum values (e.g. Digital Unix 32767, Solaris 1000). In Section 3, we will see how this fact interacts with WWW request generation.