HTTP The Definitive Guide （Connection Management)

TCP Connections
When given this URL, your browser performs the steps.
(1) The browser extracts the hostname
(2) The browser looks up the IP address for this hostname (DNS)
(3) The browser gets the port number (80)
(4) The browser makes a TCP connection to 202.43.78.3 port 80
(5) The browser sends an HTTP GET request message to the server
(6) The browser reads the HTTP response message from the server
(7) The browser closes the connection

TCP Reliable Data Pipes
     TCP carries HTTP data in order, and without corruption

TCP Streams Are Segmented and Shipped by IP Packets
   
 

Each TCP segment is carried by an IP packet from one IP address to another IP

address. Each of these IP packets contains:

• An IP packet header (usually 20 bytes)
• A TCP segment header (usually 20 bytes)
• A chunk of TCP data (0 or more bytes)

The IP header contains the source and destination IP addresses, the size, and other

flags. The TCP segment header contains TCP port numbers, TCP control flags, and

numeric values used for data ordering and integrity checking.

A TCP connection is distinguished by four values:

<source-IP-address, source-port, destination-IP-address, destination-port>

Together, these four values uniquely define a connection.

How TCP clients and servers communicate using the TCP sockets interface

TCP Performance Considerations

HTTP Transaction Delays

Performance Focus Areas

TCP Connection Handshake Delays

Here are the steps in the TCP connection handshake:

1. To request a new TCP connection, the client sends a small TCP packet (usually 40–60 bytes) to the server. The packet has a special “SYN” flag set, which means it’s a connection request. This is shown in Figure 4-8a.
2. If the server accepts the connection, it computes some connection parameters and sends a TCP packet back to the client, with both the “SYN” and “ACK” flags set, indicating that the connection request is accepted (see Figure 4-8b).
3. Finally, the client sends an acknowledgment back to the server, letting it know that the connection was established successfully (see Figure 4-8c). Modern TCP stacks let the client send data in this acknowledgment packet.

Delayed Acknowledgments
         To increase the chances that an acknowledgment will find a data packet headed in
the same direction, many TCP stacks implement a “delayed acknowledgment” algorithm.
Delayed acknowledgments hold outgoing acknowledgments in a buffer for a
certain window of time (usually 100–200 milliseconds), looking for an outgoing data
packet on which to piggyback. If no outgoing data packet arrives in that time, the
acknowledgment is sent in its own packet. Frequently, the disabled acknowledgment algorithms
introduce significant delays. Depending on your operating system, you may be able
to adjust or disable the delayed acknowledgment algorithm.

TCP Slow Start
         The performance of TCP data transfer also depends on the age of the TCP connection.
TCP connections “tune” themselves over time, initially limiting the maximum
speed of the connection and increasing the speed over time as data is transmitted
successfully. This tuning is called TCP slow start, and it is used to prevent sudden
overloading and congestion of the Internet.

Nagle’s Algorithm and TCP_NODELAY
       Nagle’s algorithm discourages the sending of segments that are not full-size (a
maximum-size packet is around 1,500 bytes on a LAN, or a few hundred bytes
across the Internet). Nagle’s algorithm lets you send a non-full-size packet only if all
other packets have been acknowledged. If other packets are still in flight, the partial
data is buffered. This buffered data is sent only when pending packets are acknowledged
or when the buffer has accumulated enough data to send a full packet.
     HTTP applications often disable Nagle’s algorithm to improve performance, by setting
the TCP_NODELAY parameter on their stacks. If you do this, you must ensure that
you write large chunks of data to TCP so you don’t create a flurry of small packets.

TIME_WAIT Accumulation and Port Exhaustion

HTTP Connection Handling
The Oft-Misunderstood Connection Header
     The Connection header sometimes is confusing, because it can carry three different
types of tokens:
• HTTP header field names, listing headers relevant for only this connection
• Arbitrary token values, describing nonstandard options for this connection
• The value close, indicating the persistent connection will be closed when done

 If a connection token contains the name of an HTTP header field, that header field
contains connection-specific information and must not be forwarded. Any header
fields listed in the Connection header must be deleted before the message is forwarded.

Serial Transaction Delays
TCP performance delays can add up if the connections are managed naively.

Parallel Connections
     HTTP allows clients to open multiple connections and perform multiple HTTP
transactions in parallel

Parallel Connections May Make Pages Load Faster
      Composite pages consisting of embedded objects may load faster if they take advantage
of the dead time and bandwidth limits of a single connection.
     The delays can be overlapped, and if a single connection does not saturate the client’s Internet bandwidth, the unused bandwidth can be allocated to loading additional objects.

Parallel Connections Are Not Always Faster
     In practice, browsers do use parallel connections, but they limit the total number of
parallel connections to a small number (often four). Servers are free to close excessive
connections from a particular client.
    
Parallel Connections May “Feel” Faster

Persistent Connections
TCP connections that are kept open after transactions complete are called persistent connections.

HTTP/1.0+ Keep-Alive Connections

Pipelined Connections

The Mysteries of Connection Close

• “At Will” Disconnection
• Content-Length and Truncation
• Connection Close Tolerance, Retries, and Idempotency

Graceful Connection Close

• Full and half closes

     A close( ) sockets call closes both the input and output channels of a TCP connection. This is called a “full close”. You can use the shutdown( ) sockets call to close either the input or output channel individually. This is called a “half close”

• TCP close and reset errors

     In general, closing the output channel of your connection is always safe. The peer on
the other side of the connection will be notified that you closed the connection by
getting an end-of-stream notification once all the data has been read from its buffer.
    Closing the input channel of your connection is riskier, unless you know the other
side doesn’t plan to send any more data. If the other side sends data to your closed
input channel, the operating system will issue a TCP “connection reset by peer” message
back to the other side’s machine. Most operating systems treat this as a serious error and erase any buffered data the other side has not read yet. This is very bad for pipelined connections.

• Graceful close