Shulou(Shulou.com)06/02 Report--

What is the function of the backlog field in the listen function? for this question, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

By constantly adjusting the number of client, I found that the performance did not decrease significantly with the decrease in the number of client, but suddenly decreased when the number of client reached a certain value.

For example, when my own data is 491 client, the performance of silly is similar to that of redis, but when 492 client are concurrent at the same time, the performance of silly drops sharply to about 30% of redis.

This also shows once again that the overhead should not be caused by malloc and memcpy.

During this period, I tried to increase the epoll buffer and increase the socket read-ahead buffer, respectively, with no obvious effect. This also shows that the problem is not in the read speed of IO and the overhead of system calls.

In desperation, Download began to compare the source code of redis3.0, and finally found that the only difference was that the backlog of redis's listen was 511, while mine was only 5. 5.

It suddenly became clear that because the backlog queue was too small, all connect had to be executed serially, and most of the time was waiting for the establishment of a connection. After changing the value of backlog to 511, the performance was already close to that of redis.

Google found that not only redis but also nginx also uses 511. However, the backlog parameter in memory will affect the size of the queue of outstanding requests, and it seems that increasing backlog will increase the risk of syn flood attacks.

After looking up the data for a long time, it was found that the backlog parameter in listen after Linux 2.2 was only used to specify the length of the completed socket queue waiting to be accept. The queue length of the incomplete connection is specified by / proc/sys/net/ipv4/tcp_max_syn_backlog.

As for why backlog is 511 instead of 512, it is because backlog is roundup_power_of_tow (backlog+1) in kernel, and 511 is actually used here so as not to waste too much unnecessary space.

It has been said that backlog is an empirical value and needs to be adjusted according to experience. However, I didn't expect that when a large number of connections flooded in, the backlog parameter would have such a big impact. So this experience seems to be to estimate the number of connections per second.

For example, due to the characteristics of http, web servers need to establish disconnected links frequently, so a large number of connections are bound to pour in at the same time, so a higher backlog value may be required, but for game servers, most of them are long connections, except that there will be a large number of connections pouring in when the service is first started, and in most cases the connection establishment is not as frequent as the web server. Of course, even so, you still need to estimate how many links enter at the same time per second to measure the size of the backlog.

Although the maximum value of backlog can be used directly without estimating, it may cause the queue of socket that has been completed but not Accept to be too long, and when the accept leaves the connection behind the queue, it has been remotely closed.

After testing, even if the backlog is 63, there is no performance impact on concurrent 2000 clients in the local area network.

On December 23, we will add:

1. The backlog value of listen actually specifies the accept queue precisely, but it not only controls the size of the accept queue, but also affects the size of the unfinished connect queue, so

Roundup_power_of_tow (backlog+1) actually increases the size of the incomplete connect queue.

2. / proc/sys/net/ipv4/tcp_max_syn_backlog although there is a sync in the field name, it actually limits the size of the accept queue, not the size of the incomplete connect queue.

Although do not want to write as a kernel net source code parsing file (in fact, it is afraid of misleading children: d), but still go through the process to prove it (only for tcp and ipv4 based on 3.19).

Let's take a look at the whole process of listen:

The listen system call is actually done through sock- > ops- > listen (sock, backlog).

So where does the sock- > ops- > listen function come from? let's take a look at the socket system call, which is actually done by calling _ _ sock_create indirectly through socket_create.

The sock- > ops- > listen function is accomplished by calling pf- > create in the _ _ socket_create function. Pf is actually registered by calling socket_register through the inet_init function. As for when the inet_init is called, I will not repeat it here. After all, this is not an article of kernel analysis: D.

From this we find that pf- > create actually calls the inet_create function.

Ah! Then we finally find the sock- > ops- > listen function through inetsw_array and it turns out to be the inet_listen function. You can see that the backlog we passed through listen is directly assigned to the sk_max_ack_backlog field after the maximum value has been passed.

OK, let's take a look at what kernel does after receiving a sync packet.

All right, let's take a look at how the function icsk- > icsk_af_ops- > conn_request comes from.

Looking back, inetsw_array finds that the prot field of type in SOCK_STREAM actually points to the tcp_prot structure.

The last part of the inet_create function you saw earlier calls the sk- > sk_prot- > init function. The sk_prot field actually assigns a value to the prof field in inetsw_array when you call sk_alloc.

So what is called at the end of the inet_create function sk- > sk_prot- > init is actually the tcp_v4_init_sock function. In the tcp_v4_init_sock function, the value of icsk- > icsk_af_ops is assigned to the address of ipv4_specific.

As a result, it is finally found that icsk- > icsk_af_ops- > conn_request is actually the tcp_v4_conn_request function, which then calls the tcp_conn_request function to complete the following content.

In tcp_conn_request, it is judged by sk_acceptq_is_full.

We can see from the sk_acceptq_is_full function that he is judged by the sk_max_ack_backlog field, which is actually the value passed in by listen when we analyze the listen system call.

As an additional note, the space allocated for listen_sock::syn_table in reqsk_queue_alloc is only a hash table, not an international request_sock space.

The answer to the question about the role of the backlog field in the listen function is shared here. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.