The meaning of the backlog within the listen function and the various situations

First read this article:

Http://www.cppblog.com/thisisbin/archive/2010/02/07/107444.html

It said it would maintain two queues, established and SYN_RCVD. The length specified by Back_log is the sum of two queues (multiplied by a factor)

When the client's first SYN arrives, TCP adds a new record to the unfinished queue and then replies to the second section in the client's three-way handshake (SYN on the server and ACK for the client), which persists until the last sub-section of the three-way handshake arrives. or until timeout (Berkeley time to define this timeout as 75 seconds)

If the queue is full when the client SYN arrives, TCP ignores the subsequent incoming SYN, but does not send the RST information to the client because the client is now allowed to retransmit the SYN section, and if an error message is returned, Then the client will not be able to tell whether the server port on the corresponding ports on the corresponding application or the service port on the corresponding ports on the queue is full of two cases

http://blog.csdn.net/wangst4321/article/details/8733212

This article gives some values for the coefficients:

Queue Length for different backlog

The system maintains a fixed-length connection queue for the TCP service program that is waiting for a connection request. The connection in this queue has been received by TCP (the handshake has been completed three times), but it has not been received by the application (call the Accept function)

The situation of Linux

The comments in the first article say that this is the BSD situation , which is not the case in Linux . In Linux, the backlog is the number of established, and the number of SYN_RCVD is

/proc/sys/net/ipv4/tcp_max_syn_backlog 设置的。具体可以看：

Http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html

The interesting question is now what such an implementation behaves if the accept queue are full and a connection needs to B E moved from the SYN queue to the accept queue, i.e. when the ACK packet of the 3-way handshake is received.

The most critical situation is when the established queue does not fit, what to do?

The paper analyzes the source code, and finds that the conclusion is that ignoring . This means that when the last ACK arrives, the connection should have been moved to the established queue, but full, then ignored and not moved; this time the situation corresponds to the ACK loss, need to three times the second step of the Handshake (syn+ack) re-hair, Then there will be an ACK (note the number of timeouts ). and after the number of times, the server side is close , the client again sent, will receive RST.

There is also a very interesting question : The three-time handshake client, when the last Ack is issued, the state is already established . At this point, it actually started sending the data.

The result is: If it sends data (without waiting for data from the server first) and then that data would be retransmitted as well. Fortunately TCP Slow-start should limit the number of segments sent during this phase.

also corresponds to the second article observed in the phenomenon, is the data sent has been not confirmed, but need to continue to resend. (Link)

The following is part of the second article:

It should be noted here that the client considers the connection state to be successful because the connection from the client port to the server port is established. This causes the client program to return successfully when it performs connect, and continues the next action to send data to the server.

Since the data is sent to the bottom of the system, when the client executes send, the data is sent to the system's bottom. If all data is received at the bottom of the system, the client considers the send to be successful and returns . This can be verified by the client execution results. All clients are completed immediately and output the following information:
Connect successfully.
Sent byte:1024
What is the actual situation like? The transmission of data is observed by the command "Tcpdump-i Lo". As can be seen from the following data, the server program does not actually establish a connection with the client program, and the data transfer is not actually completed.

Summarize

when client connect is successfully returned, it does not mean that the connection to the server has actually been established . a successful return of send data does not indicate that the server side has successfully received it. You should be aware of these two points when programming.

Content of the second article (end)

Back to the third article:

On the other hand, if the client first waits for data from the server and the server never reduces the backlog, then the E nd result is this on the client side, the connection are in State established and while on the server side, the connection is Considered CLOSED. This means, we end up with a half-open connection!

Another question is whether all of the SYN will be added to the SYN queue. Linux does not, because the established queue is full, will cause the SYN queue is full, not come in.

The benefits of Linux separating the thresholds for two queues are described in the following article:

The implementation in Linux effectively separates these the concerns:

The application is a responsible for tuning the backlog such that it can call accept fast enough to avoid filling the ACC EPT queue);

A system administrator can then tune /proc/sys/net/ipv4/tcp_max_syn_backlog based on traffic characteristics.

The meaning of the backlog within the listen function and the various situations