Analysis of the backlog of TCP connection listen

In a TCP connection, the most important is the connection of the TCP connection, the state between the two directions and the relationship between each system call and the state. Can often be expressed in two graphs, the first is the state transition diagram, the second is the connection sequence diagram. As follows: State diagram: Time series diagram: Visible, the Listen state is the only way to establish a server receiving connection. When listen is called, the server enters the listen state. Listen is: int listen (int sockfd, int backlog); The backlog is a recommended value for specifying the internal queue size to control the number of simultaneous connection requests. There are two ways to implement this backlog for the control connection requirement:

1. Single queue to control the connection. The queue contains both the state of the SYN_RCVD and the established state. Accept handles only the latter state. If the ACK in the three handshake arrives, it changes its state directly in the queue. Obviously, the backlog is the length of this queue.
2. Two separate queues to control. Separate queues are implemented for each of the two states. Obviously in this case, two queues must have a definite size limit, and the backlog can only limit one of them.

In UNP, this value is described as: The kernel maintains two queues, one is an unfinished queue, and the other is a queue that has established a connection. When the first SYNC arrives, plug the connection into the first queue before replying to Ack+sync. At this point, the connection state becomes SYN_RCVD, and the second is the completion queue. After the client's ACK comes up, the corresponding connection is moved into the completion queue. The connection to this state is returned by the Accept system call, and the state becomes established. On the other hand, if the queue is full when the request comes up, TCP ignores it. Client to retry. Visible, its implementation is actually the first form of single queue, that is, the backlog control the sum of the two state connections. And for Linux:man listen visible: The behavior of the backlogArgument 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 is set using /proc/sys/net/ipv4/tcp_max_syn_backlog.  is not consistent with the description in the UNP book. is the second implementation of the above: two queues, where the queue length limit is not completed is indicated by kernel parameters, but the completion queue is the backlog. cat/proc/sys/net/ipv4/tcp_max_syn_backlog2048  specific code: After TCP receives the final ACK, it rebuilds a sock:  tcp_v4_syn_recv_ Sock function:    if (Sk_acceptq_is_full (SK))         Goto exit_overflow;     NEWSK = Tcp_create_openreq_child (SK, req, SKB);    if (!NEWSK)         Goto EXIT_NONEWSK;&NBS It can be seen that when a new socket is born, the first judgment is full.  static inline bool Sk_acceptq_is_full (const struct sock *sk) {    return sk->sk_ack_backlog > Sk-&gt ; sk_max_ack_backlog;}   /* *    Move a socket into listening state. */int inet_listen (struct socket *sock, int BAC Klog):    Sk->sk_max_ack_backlog = Backlog;  backlog passed to Sk_max_ack_backlog. Visible, this backlog is used to determine the complete queue.   In the outer layer, call:    child = INET_CSK (SK)->icsk_af_ops->syn_recv_sock (SK, SKB, req, null,    & nbsp                       req, &own_req);    if (!child)         GO To listen_overflow;     Sock_rps_save_rxhash (Child, SKB);    Tcp_synack_rtt_meas (Child, req) ;    return inet_csk_complete_hashdance (SK, Child, req, own_req); listen_overflow:    if (! Sysctl_tcp_abort_on_overflow) {        Inet_rsk (req)->acked = 1;        return null;   }embryonic_reset:    if (! ( FLG & Tcp_flag_rst) {       /* Received a bad SYN pkt-for TFO We try not to reset         * The local connection unless it ' s really necessary to         * Avoid becom ing vulnerable to outside attack aiming at         * resetting legit local connections.  &NB Sp      */        Req->rsk_ops->send_reset (SK, SKB);  } else if (Fastopen) {/* received a valid RST pkt */        Reqsk_fastopen_remove (SK, Req, Tru e);        Tcp_reset (SK);   }    if (!fastopen) {        inet _csk_reqsk_queue_drop (SK, req);        NET_INC_STATS_BH (Sock_net (SK), linux_mib_embryonicrsts);    }    return null;  visible, if the backlog is full, you need to focus on sysctl_tcp_abort_on_overflow, and the values are configured under/proc. If there is no match, then nothing is done, directly ignore, this will make the server side for a certain period of time to re-send Sync/ack. If configured, go to the process below to send the RST.   Another point, when the client sends the last ACK, it enters the established state, but as mentioned above, this ACK may be ignored because of server-side backlog issues. But the client does not know, because it is established, it can send data during this time! The subsequent re-sync/ack will cause the client to re-send the data that has been sent, in favor of bandwidth waste. TCP Slow start will mitigate this situation.   backlog is full, not only for the complete queue, but also for the ACK queue, the appropriate speed limit (? To avoid too much congestion by losing part of the sync. in function: int tcp_conn_request (struct request_sock_ops *rsk_ops,             const struct T Cp_request_sock_ops *af_ops,             struct sOck *sk, struct sk_buff *skb)   ...    /* Accept backlog is full. If we have already queued enough     * of warm entries in SYN Queue, drop request. It is better than     * clogging syn queue with openreqs with exponentially increasing     * timeout.     */    if (Sk_acceptq_is_full (SK) && Inet_csk_reqsk_queue_young (SK) > 1 ) {        NET_INC_STATS_BH (Sock_net (SK), linux_mib_listenoverflows);        Goto drop;   }  Summary:

1. Server connection Establishment there are two places to queue up, one is when the sync packet comes up, the other is the ACK. For Linux, the length of the former is determined by the configuration item, which is 2048 on the machine, and the latter is specified by the backlog brought into the listen;
2. If the backlog corresponds to the queue full, determine the configuration items, if matched, RST, otherwise directly ignored, waiting for time-out to re-send;
3. As soon as the client sends an ACK, it enters the established state, and the server has to accept it. The two are not equal, and the client can send the data immediately after it is established.
4. The sync queue also makes reference to whether the complete queue is full. If full, limit the rate of packet delivery, and discard some packages appropriately.

Analysis of the backlog of TCP connection listen