HTTP connection Management

1.TCP Connection

Almost all of the HTTP traffic is hosted by TCP/IP, which is a commonly used packet-switched network layered protocol set for global computers and network devices. Once the connection is established, the messages exchanged between the client and the server are never lost, damaged, or out of sequence. But the computer or network crashes, will make the communication terminal.

1.1.TCP Reliable Data Pipeline

TCP provides a reliable bit-transport pipeline for HTTP.

When the browser accepts a URL, the following steps are performed:

#1: The client resolves the host name;

#2: The client queries the IP address (DNS) of this host name;

#3: The client resolves the port number;

#4: The client initiates a connection to the corresponding IP and port;

#5: The client sends an HTTP GET request message to the server;

#6: The client waits for a response, responds to the loopback client, and the client reads the HTTP response message;

#7: Closes the connection.

1.2. Segmented data transfer

When HTTP is transmitting a message, the message data content is transmitted sequentially through the open TCP connection in the form of a stream. When TCP receives the data stream, it cuts the data stream into small chunks, encapsulated in IP packets, and transmitted over the Internet. All of this work is handled by the TCP/IP software.

Each IP grouping includes:

#1: An IP packet header (usually 20 bytes);

#2: A TCP segment Header (usually 20 bytes);

#3: A block of TCP data (0 to n bytes).

1.3.TCP Connection Identification

A TCP connection is identified by 4 values:

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

Two different TCP connections cannot have 4 identical address component values.

2.TCP Performance

HTTP is located on top of TCP, so the performance of HTTP is largely dependent on the performance of the underlying TCP channel.

2.1.HTTP Transaction Delay Reason

#1: The client determines the IP address and port of the Web server based on the URL. It may take 10 seconds for the DNS resolution system to replace the hostname of the URL with an IP address, and if there is any recent access to it, the client caches it and does not require access to DNS, but the DNS cache is small;

#2: The client sends a TCP connection request to the server. Each TCP connection will have a connection setting delay;

#3: Internet transmission request message and processing request message;

#4: The server echoes the HTTP response.

2.2.TCP Latency

#1: The TCP connection establishes the handshake;

#2: TCP Slow-start congestion control;

#3: Nagle algorithm for data aggregation;

#4: A delay acknowledgement algorithm for TCP with a piggyback acknowledgment;

#5: time_wait delay and port exhaustion.

2.3.TCP Connection establishes handshake delay

#1: When a new TCP connection is requested, the client sends a small TCP packet (usually 40~60 bytes) to the server, which sets a special SYN token;

#2: If the server accepts a connection, it will want the client to echo the TCP packet, and the SYN and ACK tokens in the two groupings will be set, indicating that the request has been accepted;

#3: The client sends back a confirmation message to the server to notify the connection that it was successfully established.

Note: Small HTTP transactions can take up to 50% or more of the time TCP is established.

2.4. Delayed acknowledgement algorithm for TCP with piggyback acknowledgement

#1: Each TCP segment has a serial number and data integrity checksum. When the recipient of each segment receives a good segment, the acknowledgement message is sent back to the sender.

#2: If the sender does not receive a confirmation message within the specified window time, the sender considers the grouping to be corrupted or destroyed and re-sends the data.

#3: Because the acknowledgment message is small, TCP allows "piggyback" in the output data packet destined for the same direction, and if no output data is grouped in a particular time window (typically 100~200 milliseconds), the acknowledgment information is sent in a separate packet.

2.5.TCP Slow start

#1: The use of TCP connections (age) is one of the factors that affect TCP data transfer performance.

#2: Initially limits the maximum speed of the connection and, if the data is successfully transmitted, increases the transmitted data over time. This tuning, known as TCP slow start, is used to prevent sudden internet overloads and congestion.

#3: TCP Slow Boot limits the number of packets that a TCP endpoint can transmit at any point in time.

#4: Because of this congestion control feature, the transfer speed of a new connection is slower than a "tuned" connection that has exchanged a certain amount of data.

2.6.Nagle algorithm and Tcp_nodelay

#1: The Nagle algorithm attempts to send a packet of TCP data together to improve network efficiency. Encourage send full size (LAN maximum size grouping approximately 1500 bytes, hundreds of bytes on the Internet), send only if all other groupings are confirmed, or if the cache accumulates a full-size packet data;

#2: The Nagle algorithm blocks the sending of data. If a small HTTP message fails to fill a packet, it may be delayed by waiting for additional data that will never come up, but blocking the data is sent, but its own packet acknowledgement delay 100~200 milliseconds;

#3: Tcp_nodelay can set the Disable Nagle algorithm to provide performance, but make sure that TCP writes large chunks of data.

2.7.time_wait Latency and port exhaustion

#1: When a TCP endpoint closes a connection, a control block that records the IP address and port number of the recently closed connection is maintained in memory, typically only two times (2MSL, typically 2 minutes) of the maximum staging period are maintained, to ensure that new connections with the same address and port number are not created during this period;

#2: Some operating systems will set the 2MSL to a smaller value, but beyond this value, be careful that the grouping is indeed copied, if the replication from the previous connection is inserted into a new TCP stream with the same connection value, the TCP data will be destroyed;

#3: Each time a client connects to the server, it obtains a new source port for the connection to be unique. But the source port is limited, and the connection is not reusable in 2MSL, the connection rate is limited;

#4: Some operating systems can slow down significantly in the event of a large number of open connections or control blocks.

3.HTTP performance 3.1.http serial processing time delay

With simple management of the connection, TCP performance delays may overlap.

If a Web page contains 3 embedded images, the browser needs to initiate 4 HTTP transactions to display this page, and each transaction needs to (serially create) A new connection, then the connection delay and slow start delay are superimposed.

Improve HTTP connection performance:

#1: Parallel connection : Multiple TCP connections initiate concurrent HTTP requests;

#2: Persistent connection : Reusing TCP connections, eliminating connections and closing delays;

#3: pipelined connection : A shared TCP connection initiates concurrent HTTP requests;

#4: multiplexed connection : Alternate transfer request and Response message (experimental phase).

3.2. Parallel connection

#1: Parallelism may increase the speed of page loading

Parallel connections, which overcomes the no-load time and bandwidth limitations of a single connection, can also improve speed.

#2: Parallel connections are not necessarily faster

1) When the client network bandwidth is insufficient, most of the time is used to transmit data, resulting in a small increase;

2) Open a large number of connections, will cause serious degradation of server performance;

3) In fact, the browser uses a parallel connection, the general number of connections is usually limited to 4, the server can be arbitrarily shut down from a specific client over the connection.

3.3. Persistent connection

The client often opens a connection to the same site, reusing an idle persistent connection opened to the target server to avoid slow connection establishment and slow-start congestion adaptation phases for faster data transfer.

There are two types of persistent connections: http/1.0+ "keep-alive" (older) and http/1.1 "persistent"

#1: http/1.0+ keep-alive Connection

The early http/1.0+ keep-alive persistent connection was plagued by some interoperability line design problems, and the problem was fixed in http/1.1, with many clients and servers still using version 1.0.

1>keep-alive operation

A client that implements a http/1.0 keep-alive connection remains open by including a connection:keep-alive header request.

If the response does not have a connection:keep-alive header, the client considers that the server does not support keep-alive.

2>keep-alive Options

Note:

1) issuing keep-alive requests, the client and the server will not necessarily agree;

2) The client and server can close idle keep-alive connection at any time;

3) You can arbitrarily limit the number of transactions processed by the keep-alive connection.

Keep-alive header can adjust the above behavior:

Format:

Connection:keep-alive

Keep-alive: (["max" "=" n] ["," "Timeout" "=" seconds][header[value]])

The server keeps the connection open for up to 5 other transactions, or the open state remains idle for 2 minutes for the connection, as an example:

Connection:keep-alive

Keep-alive:max=5, timeout=120

Parameters:

Max: estimate how many transactions the server also wants to keep this connection active. Non-commitment value.

Timeout: estimate how long the server also wants to keep the connection active. Non-commitment value.

Header: any of the treated properties for diagnostics and debugging.

Restrictions and rules for 3>keep-alive connections

1) http/1.0, keep-alive is not the default use, need to connection:keep-alive;

2) The connection:keep-alive must be sent along with all messages wishing to be persistent, otherwise the connection will be closed after that request;

3) There is no connection:keep-alive in the response message, the server shuts down the persistent connection after the response is issued;

4) The entity part must have the correct content-length, otherwise cannot accurate one message end and another message start, cannot the persistent connection;

5) The proxy or gateway must delete all header fields named in the connection header and the connection header before forwarding or caching the message;

6) The Keep-alive connection should not be established with a proxy server that cannot determine whether the connection header is supported.

4>keep-alive and Dummy Agent

1) proxy blind Relay for connection header is not supported

STEP-1: The client sends a request message containing the connection:keep-alive header;

Step-2: Dumb agent does not understand the connection header, just along the link to send the header to the server;

STEP-3: The server receives the Connection:keep-alive, thinks the other party wants to carry on the keep-alive dialogue, the echo contains connection:keep-alive the response message;

Step-4: The dummy proxy sends back the response message from the server to the client and waits for the source server to close the connection, but the server does not close the connection;

STEP-5: The client receives a response message containing the connection:keep-alive header and considers that the agent agrees to carry out the keep-alive dialogue;

STEP-6: The client sends the request message to the agent on the Keep-alive connection, and the agent does not think that there will be other requests on the same connection, and the request is ignored;

STEP-7: The client is suspended until the connection times out and shuts it down.

2) Agent and Skip header

In order to avoid the above problems, modern agents can never forward connection header and all names appearing in the connection value of the header.

Proxy-authenticate/proxy-connection/transfer-encoding/upgrade also cannot be forwarded by proxy or used as the header for cached responses.

5> inserting proxy-connection

A smart agent (a handshake that understands persistent connections) uses a connection header to replace the proxy-connection header and forwards it to the server to achieve the desired effect.

But for multi-level proxies, proxy-connection still doesn't solve the problem.

#2: http/1.1 Persistent connection

http/1.1 used a persistent connection (persistent connection) instead of keep-alive, with the same purpose as keep-alive;

http/1.1 The persistent connection is activated by default, to close the connection after the end of the transaction, to include the connection:close in the response message;

The response message does not contain connection:close, and does not mean that the server is committed to always keep the connection open, and the client and server can still close idle connections at any time.

#3: Persistent connection restrictions and rules

1) Send Connection:close, the client cannot send more requests on that connection;

2) The connection is maintained, all the messages on the connection need to be correct and the custom message length is correct;

3) The http/1.1 Proxy server should not establish a connection with the http/1.0 client;

4) The client can only maintain a maximum of 2 persistent connections to the task server or agent, preventing the server from overloading.

3.4. Piping connection

http/1.1 allows optional use of the request pipeline on persistent connections. You can put multiple requests into the queue before the response arrives. You can reduce the return time of the network and improve performance.

Piping restrictions:

#1: Determine if the client supports persistent connections;

#2: The HTTP response must be echoed in the order in which it was requested;

#3: The client is ready to close the connection at any time and re-send all requests that have not been pipelined.

3.5. Close the connection

#1: "Any moment" to unblock the connection

pipelined persistent connections are common. A persistent connection is idle for some time, and the server may decide to close the connection. But the server can not determine the moment of shutdown, the other end of the connection there is no message to send, if the client at this time in writing half of the request message, an error will occur.

#2: Content-length and truncation operations

The connection is closed according to the correct content-length header or the response message containing the connection:close.

#3: Connection Close tolerance, retry, and idempotent

If a transaction, no matter how many times it is executed, gets the same result, then the transaction is idempotent.

In the case of a non-error, the connection is closed at any time, the client is prepared to handle the unexpected shutdown correctly, the idempotent transaction can be re-requested, but for non-idempotent transactions to be considered (if only the response message does not return, the request will cause unintended results).

#4: Normal close connection

TCP connections are bidirectional , and each segment has an input queue and an output queue.

1>TCP Shutdown and reset errors

A simple HTTP application can only use full shutdown.

Many client, server, and agent communications have started using a pipelined persistent connection, using a semi-shutdown to prevent the peer entity from receiving unintended write errors .

If the other end sends data to the input channel you have closed, the operating system will send a message to the other end that the TCP "connection is end multiplicity". Most systems act as a serious error handler, emptying all cached data that has not yet been read by the peer.

2> Normal shutdown

Turn off your output channel first, and then wait for the peer entity on the other end to close its output channel.

If the input channel is not closed on the peer for a period of time, the application can force the connection to close.

Appendix:

http/1.1 Official Website specification

Persistent Connection HTTP Instance

Performance interaction between P-http and TCP

TCP slow start, avoid congestion, fast retransmission, and fast recovery algorithms

TCP Acknowledgement and delay acknowledgement

Nagle algorithm

Tcp

HTTP connection Management