Nonpersistent and Persistent Connections

Knowledge Base

Nonpersistent and Persistent Connections

HTTP can use both persistent and nonpersistent connections; although, persistent connections is the HTTP default mode. HTTP clients and servers can also be configured to use non persistent connections instead. Here are the steps for transferring a Web page from server to client for the case of non persistent connections.

The HTTP client process initiates a TCP connection to the server on the HTTP default
port number 80. The HTTP client sends and HTTP request message to the server via its
socket associated with the TCP connection. The request message includes the path name.
The HTTP server process receives the request message via its socket associated with
the connections and retrieves the object from its storage, encapsulates the object in an
HTTP response message and sends the response message to the client via its socket.

The HTTP server process tells TCP to close the TCP connection; however, the connection
is not actually terminated until the TCP knows for sure the client has received the response
message intact. The HTTP client receives the response message and the TCP connection
terminates. The message indicates that the encapsulated object is an HTML file. The client
extracts the file from the response message, examines the HTML file, and finds references
to the objects.

The browser receives the Web page; it displays the page to the user. HTTP has nothing to
do with how a Web page is interpreted by a client, the specification of the HTTP define only
the communication protocol between the client HTTP program and the server HTTP
program. Consider what happens when a user click s a hyperlink. This causes the browser
to imitate a TCP connection between the browser and the Web server; this involves a three-
way “handshake”—the client sends a small TCP segment to the server, the server
acknowledges and responds with a small TCP segment, and, finally, the client acknowledges
back to the server. The first two parts of the three-way handshake takes one round-trip
time (RTT) . After the first two parts are completed, the client sends the HTTP request
message combined with the third part of the three way handshake into the TCP connection.
Once the request message arrives at the server, the server sends the HTML file into the TCP
connection. This HTTP takes up another RTT, thus, roughly, the total response time is two
RTTs plus the transmission time of the server of the HTML file.

With persistent connections , the server leaves the TCP connection open after sending a response. Subsequent requests and responses between the same client and server can be sent over the same connections. An entire Web page or multiple Web pages residing on the same server can be sent from the server to the same client over a single persistent TCP connection. There are two versions of persistent connections: without pipelining and with pipelining. Without pipelining, the client issues a new request only when the previous response has been received. The client experiences one RTT in order to request and receive each of the referenced objects.

RTT delay can be further reduced with pipelining. Another disadvantage of no pipelining is
that after the server sends an object over the persistent TCP connection, the connection idles
while it waits for another request to arrive. This idling wastes server resources. The default
mode of HTTP uses persistent connections with pipelining. The HTTP client issues a request
as soon as it encounters a reference, thus, the HTTP client can make back to back requests for the referenced objects; in other words, it can make a new request before receiving a
response to a previous request. When the server receives the back to back requests, it sends
the objects back to back. With pipelining, it is possible for only one RTT to be expended for
all the referenced objects. Furthermore, the pipelined TCP connection remains idle for a
smaller fraction of time.

Back to The Web and HTTP