Apache's keepalive and TCP/IP time_wait

Original paste: http://blog.chinaitlab.com/html/10/56410-161952.html

Starting site to help Kay [http://www.php-oa.com] Apache's keepalive and TCP/IP time_wait

Previous/Next 2008-04-25 12:13:33/Personal Category: Web technology View (129)/Comments (0)/rating (0/0)

Today checked a basic server, found Time_wait high to 3k. The time_wait itself does not take up much of the resources unless it is attacked. But too many servers are still possible to hang up.
Time_wait 3699
Close_wait 52
Fin_wait1 32
Syn_sent 1
Fin_wait2 2
Established 17
SYN_RECV 45
CLOSING 6

Explanation of "TCP termination" in the establishment and termination of TCP in "TCP /IP Details"

The termination of TCP is achieved by a handshake of four times on both sides. The party initiating the termination performs the active shutdown, and the other side of the response performs a passive shutdown.

1. The initiator changes the state to Fin_wait_1, closes the application process, emits a TCP fin segment;
2. The receiver receives the fin segment, returns an ACK with the confirmation serial number, and sends a file Terminator EOF to its corresponding process while changing the state to close_wait, and the initiator receives the ACK state to fin_wait_2;
3. The receiver closes the application process, changes the state to Last_ack, and emits a TCP fin segment to the other party;
4. The initiator was changed to time_wait after receiving the fin and issued an ACK confirmation of the fin. After the ACK is sent successfully (within 2MSL) both TCP states become closed.

It is not difficult to see the meaning of the result shown above. According to the TCP protocol, the active initiating shutdown will enter the TIME_WAIT state (the TCP implementation must reliably terminate the two directions (Full-duplex shutdown) of the connection), persistent 2*msl (Max Segment Lifetime), and 240 seconds by default.

why the TIME_WAIT state needs to stay 2MSL so long.

The time_wait wait time is 2MSL, which is the maximum segment lifetime. If the time_wait state is not kept long enough (for example, less than 2MSL), the first connection is terminated normally. The second connection that has the same associated five tuples appears (because the party initiating before the connection terminates may need to be sent an ACK, so the time to stay in that state must be twice times that of MSL.) and the first connected duplicate message arrives, interfering with the second connection. The TCP implementation must prevent a connected duplicate message from appearing after the connection is terminated, so that the time_wait state remains long enough (2MSL), and the TCP message connected to the corresponding direction is either complete or discarded. When a second connection is established, it is not confused.

Note: The MSL (maximum segment lifetime) indicates the maximum lifetime of a TCP message on the Internet, and each specific TCP implementation must select a determined MSL value. RFC 1122 is recommended for 2 minutes, but the BSD legacy implementation takes 30 seconds. TIME_WAIT State Maximum retention time is 2 * MSL, which is 1-4 minutes.

The operation of Apache
The HTTP protocol version 1.1 stipulates that the default behavior is keep-alive, which is to reuse a TCP connection to transmit multiple request/response. So I opened the keepalive on HTTP and found Time_ The wait was immediately reduced. Only 300. To sum up. I think there are two reasons.

1.keepalive does not open, resulting in each request to establish a new TCP connection, the request is completed after the shutdown, adding a lot of time_wait state, no reuse, keepalive I think it means to keep the connection active, similar to permanent connection to Mysql . If you set keepalive to on, requests from the same client do not need to be connected again, to avoid creating a new connection for each request, and to add to the server's burden.
2. Then the keepalive in the system itself is very high. The default idle connection is 7,200 seconds (2 hours) without activity. will be disconnected.

We open keepalive:

KeepAlive on
Maxkeepaliverequests 120
KeepAliveTimeout 15

This allows each connection to send 100 requests with a timeout of 15 seconds (if the second request and the first request exceed the KeepAliveTimeout time, the first connection is interrupted and a new second connection is created).

optimized tuning of kernel-level keepalive and Time_wait

Vi/etc/sysctl

Net.ipv4.tcp_tw_reuse = 1
Net.ipv4.tcp_tw_recycle = 1
Net.ipv4.tcp_keepalive_time = 1800
Net.ipv4.tcp_fin_timeout = 30
Net.core.netdev_max_backlog =8096

Modify the finished use sysctl-p let it take effect

Annotations of the above parameters
/proc/sys/net/ipv4/tcp_tw_reuse
This file indicates whether the time-wait-state socket is allowed to reapply for a new TCP connection.

/proc/sys/net/ipv4/tcp_tw_recycle
Recyse is an accelerated time-wait sockets recovery

Changes to Tcp_tw_reuse and tcp_tw_recycle may occur. Warning, got duplicate TCP line warning, got BOGUS TCP Line. The above two parameters refer to the existence of these two identical TCP connections, which occur when a connection is quickly disconnected and reconnected, and the port and address used are the same. But basically such things will not happen, anyway, so that the above settings will increase the chance of recurrence. This tip will not be compromised and will not degrade system performance and is currently working

/proc/sys/net/ipv4/tcp_keepalive_time
Indicates how often TCP sends KeepAlive messages when KeepAlive is enabled. The default is 2 hours.

The/proc/sys/net/ipv4/tcp_fin_timeout best value is 30 the same as BSD.
The FIN_WAIT1 state is when the initiator actively requests the shutdown of the TCP connection, and after the active sending of the fin, waits for the receiving end to reply to the ACK. For a socket connection that is disconnected from the end, TCP remains in the Fin-wait-2 state for a time. The other side may disconnect or never end the connection or the unexpected process dies.

/proc/sys/net/core/netdev_max_backlog
This file specifies the maximum number of packets that are allowed to be sent to the queue when the interface receives packets at a faster rate than the kernel processes those packets

Import Forum Reference Links Collection Share to Friends recommendation to the Circle Administration Report

Tag:apache