TCP performance tuning by changing kernel parameters under Linux-high concurrency

Objective:
The importance of TCP/IP protocol to network programming, the people who have done the network development know that we write the network program in addition to the hardware, structure and other limitations, by altering the TCP/IP kernel parameters can also get a very large performance improvement,
The following is a list of some TCP/IP kernel parameters, explaining their meanings and modifying them to optimize our network programs, mainly for high concurrency scenarios.
The network program here mainly refers to the server side

1. Fs.file-max

The maximum number of file descriptive descriptors that can be opened. Attention is the whole system.
In the server. We know that each connection is created, and the system opens a file descriptor, so the maximum number of file descriptor opens determines our maximum number of connections.
The reason that select is replaced in high concurrency is also the maximum value opened by the file description descriptor, although it can be changed but is generally not recommended, details are visible in the UNP select section.

2.net.ipv4.tcp_max_syn_backlog

The maximum length of the TCP SYN queue, the three-time handshake of TCP occurs when the system calls connect, and the server kernel maintains two queues for TCP. SYN queues and accept queues, which are the connections that hold the first handshake. The Accept queue is the connection that holds the entire TCP three handshake, and the change net.ipv4.tcp_max_syn_backlog makes it larger to accept many other network connections.
Note that this number is too large to encounter a SYN flood attack, where the other party sends multiple SYN relaying to fill up the SYN queue, leaving the server unable to continue accepting other connections
can refer to this article http://tech.uc.cn/?p=1790

3.net.ipv4.tcp_syncookies

Modifying this parameter can effectively prevent the SYN flood attack as described above.
Principle: When TCPServer receives a TCP Syn packet and returns a TCP Syn+ack packet, it is not specifically assigned a data area. Instead, a cookie value is calculated based on the SYN packet.

When a TCP ACK packet is received, TCPServer checks the validity of the TCP ACK packet based on that cookie value. Assuming legal, the dedicated data area is then allocated for processing future TCP connections.
The default feels 0. 1 means Open

4.net.ipv4.tcp_keepalive_time

TCP keepalive heartbeat packet mechanism. Used to detect if the connection has been disconnected. We can change the default time to intermittent heartbeat packet sending frequency.
KeepAlive is usually the server that sends the client to see if the client is online. Because the server allocates a certain amount of resources to the client. However, TCP's keepalive mechanism is very controversial. Because they can consume a certain amount of bandwidth.
TCP keepalive details see TCP/IP Specific Interpretation Volume 1 23rd Chapter

5.net.ipv4.tcp_tw_reuse

In my previous article, I wrote about the time_wait state, where a lot of the time_wait state is a waste of resources, and they occupy the server's descriptive descriptors.

Change this number of references. Agree to reuse the socket in time_wait.

The 0,1 said that the opening

6.net.ipv4.tcp_tw_recycle

is also for the TIME_WAIT state, which indicates a high-speed recovery of the socket in time_wait.
The 0,1 said that the opening

7.net.ipv4.tcp_fin_timeout

Change the presence time of the time_wait-like. The default 2MSL
Note: Time_wait exists and has a survival time of 2MSL for a reason. See my last blog why there is a time_wait state of existence. So change it has a certain risk, or according to the specific situation to analyze.

8.net.ipv4.tcp_max_tw_buckets

The maximum number of time_wait states that are agreed upon is immediately clear and warning.

9.net.ipv4.ip_local_port_range

Represents the port range of the external connection.

10.somaxconn

The maximum length limit of the SYN queue is stated earlier, and the Somaxconn parameter determines the length of the accept queue, which determines the length of the accept queue when the Listen function is called, which is too small to limit the maximum number of concurrent connections. Because the number of connections that are 3 times over at the same time is too small, the server handles the connection more slowly. The server-side call to the Accept function is actually a connection that takes three handshakes from the connected accept queue.

The Accept queue and the SYN queue are listen functions that are created and maintained.

/proc/sys/net/core/somaxconn changes

Each of the above is actually enough to write an article to analyze, here I just outline the next part of the parameter, note that in the change of TCP parameters we must be based on their actual needs and test results to determine.

Blog:
Http://cenwj.com/2015/2/25/19

TCP performance tuning by changing kernel parameters under Linux-high concurrency