Modifying kernel parameters for TCP performance tuning 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 modifying the TCP/IP kernel parameters can also get a lot of 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 situations.
The network program here mainly refers to the server-side

1. Fs.file-max

The maximum number of file descriptors that can be opened, note the entire system.
In the server, we know that each connection is created, the system will open a file descriptor, so the maximum number of file descriptor open determines our maximum number of connections
The reason that select is superseded in high concurrency is also the maximum value opened by the file descriptor, although it can be modified 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 TCP three handshake occurs when the system calls connect, the server kernel maintains two queues for TCP, the SYN queue and the Accept queue, and the SYN queue refers to the connection that holds the first handshake. The Accept queue is a connection that holds the entire TCP three handshake, modifying the net.ipv4.tcp_max_syn_backlog so that it can accept more network connections.
Note that this parameter is too large to encounter a SYN flood attack, that is, the other party sends multiple SYN relaying fill up the SYN queue, so that the server cannot continue to accept other connections
Refer to this article http://tech.uc.cn/?p=1790

3.net.ipv4.tcp_syncookies

Modifying this parameter can effectively protect against the above mentioned SYN flood attack.
Principle: When the TCP server receives the TCP Syn packet and returns the TCP Syn+ack packet, it does not allocate a data area specifically, but calculates a cookie value based on the SYN packet. When a TCP ACK packet is received, the TCP server checks the validity of the TCP ACK packet against that cookie value. If it is legal, then the dedicated data area is allocated for processing future TCP connections.
The default is 0, and 1 means open

4.net.ipv4.tcp_keepalive_time

TCP keepalive heartbeat packet mechanism, used to detect whether the connection is broken, we can modify the default time to intermittent heartbeat packet sent frequency.
KeepAlive generally, the server sends the client to see if the client is online, because the server allocates a certain amount of resources to the client, but the TCP keepalive mechanism is controversial because they can consume a certain amount of bandwidth.
TCP keepalive details see TCP/IP Detailed 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, they occupy the server descriptor, and so on.
Modify this parameter to allow the TIME_WAIT socket to be reused.
The default is 0, and 1 means open

6.net.ipv4.tcp_tw_recycle

Also for the TIME_WAIT state, this parameter indicates that the socket in time_wait is quickly recycled.
The default is 0, and 1 means open

7.net.ipv4.tcp_fin_timeout

Modify the time_wait-like time, the default 2MSL
Note: Time_wait exists and survival time is 2MSL for a reason, see my previous blog why there is a time_wait status, so modify 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 allowed to exist 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, the Somaxconn parameter determines the Accept queue length, and the backlog parameter determines the length of the accept queue when the Listen function is called, and the parameter is too small to limit the maximum number of concurrent connections. Because the number of connections that complete the 3 handshake at the same time is too small, the server handles the connection more slowly. The server-side call to the Accept function is actually the connection from the connected accept queue that completes the three-time handshake.
The Accept queue and the SYN queue are listen functions to complete the creation of the maintenance.
/proc/sys/net/core/somaxconn modification

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

Reference blog:
Http://cenwj.com/2015/2/25/19

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Modifying kernel parameters for TCP performance tuning under Linux-high concurrency