The difference between the Linux kernel tuning tcp_max_syn_backlog and Somaxconn

The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum length and this setting is ignored. See tcp(7) for more information. If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently truncated to that value; the default value in this file is 128. In kernels before 2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128.Tcp_max_syn_backlog Introduction:

All connections received by the socket are stored in the data structure of the queue type, and the key issue is that there are two of these queues, and their lengths can be set.
The following two kernel parameters are:
/proc/sys/net/ipv4/tcp_max_syn_backlog
/proc/sys/net/core/somaxconn
which
Tcp_max_syn_backlog is the maximum number of clients that can accept the SYN synchronization packet, which is the upper limit of the half connection;

Somaxconn parameter Description:

Somaxconn refers to the maximum number of clients that the server can accept to process data, that is, to complete the connection limit.
For centOS6.5 systems with no tuning, the values for both parameters are 128.
This description, although accurate, but without a certain foundation, the person who is not proficient in network programming understanding is very laborious.

To make a simple analogy:

XXX issued a notice to invite a number of guests within the Sihai to attend the feast. There are two steps to attending a banquet:

1, to the hall;
2. Find a seat (food, such as sweets, food, wine, etc.).
Tcp_max_syn_backlog used to specify how many people are allowed to enter the catering site area;
The somaxconn is used to specify the number of seats.
Apparently Tcp_max_syn_backlog>=somaxconn.
If the number of guests to come more than tcp_max_syn_backlog, so many people will meet with the director to shake hands, but to wait outside the door;
If the number of guests to the hall is greater than Somaxconn, then the extra guests will have no place to sit (must sit down to eat), can only wait for someone to eat after the empty space to eat.

So here's the question:

Somaxconn is the kernel parameter, the Listen function has a parameter backlog, if the Listen method to specify that the parameter is greater than the value of Somaxconn, recompile and start the program, What is the maximum number of connections that can be received by the server on the backlog or somaxconn?
The answer is simple, the Listen method specifies that the backlog is specified in the user state, the kernel parameter priority is higher than the parameters of the user state, so even if the Listen method specifies that the backlog is a value greater than somaxconn, The socket also checks for Somaxconn when it is running in the kernel state, and waits if the number of connections exceeds somaxconn.
It is equivalent to the owner specified how many seats are useless, guests to the scene, ready to sit, but also to see the hotel's client manager to determine how many seats.

Conclusion:

On servers that do not have a tuned version of centOS6.5, server-side programs running on that server, at the same time, can only accept 128 clients to initiate persistent connections and only handle 128 client data traffic due to system-level constraints.

The difference between the Linux kernel tuning tcp_max_syn_backlog and Somaxconn

Alibaba Cloud Hot Products
Elastic Compute Service (ECS)	Dedicated Host (DDH)	ApsaraDB RDS for MySQL (RDS)	ApsaraDB for PolarDB(PolarDB)	AnalyticDB for PostgreSQL (ADB for PG)
AnalyticDB for MySQL(ADB for MySQL)	Data Transmission Service (DTS)	Server Load Balancer (SLB)	Global Accelerator (GA)	Cloud Enterprise Network (CEN)
Object Storage Service (OSS)	Content Delivery Network (CDN)	Short Message Service (SMS)	Container Service for Kubernetes (ACK)	Data Lake Analytics (DLA)
ApsaraDB for Redis (Redis)	ApsaraDB for MongoDB (MongoDB)	NAT Gateway	VPN Gateway	Cloud Firewall
Anti-DDoS	Web Application Firewall (WAF)	Log Service	DataWorks	MaxCompute
Elastic MapReduce (EMR)	Elasticsearch