TCP abnormal connection

Catalog

connect

The first handshake

The third handshake

tuning

Insufficient ports

In case of handshake

Full queue and half queue queries

Full connection queue

Semi connected queues

---

        TCP Abnormal connections are divided into connect, The first handshake , Third handshake source logic introduction , Give the optimization scheme and the method to view the full connection and half connection .

connect

After the connection fails , A large number of port range lookups , Can call spin lock and other operations hash lookup , Cause system state CPU Expenses are rising .

The first handshake

client

• 1） Half the queue is full , And tcp_syncookies by 0

2） The whole line is full , And there are unfinished semi connection requests ;

3） Have not received synack Client initiated retry , Time to 1s in the future , Have an impact on the system ;

4） Retransmission time 1 2 4 8 16 32 Double ; Times is tcp_syn_retries

int tcp_conn_request(struct request_sock_ops *rsk_ops,
             const struct tcp_request_sock_ops *af_ops,
             struct sock *sk, struct sk_buff *skb)
{

    // Check whether the half connection queue is full 

    if ((net->ipv4.sysctl_tcp_syncookies == 2 ||
         inet_csk_reqsk_queue_is_full(sk)) && !isn) {
        // Check whether kernel parameters are enabled tcp_syncookies, Generally open , When the semi connection queue is full, the normal handshake can still be guaranteed 
        want_cookie = tcp_syn_flood_action(sk, rsk_ops->slab_name);//syn attack   The half connection queue on the server is exhausted, making the user request unable to respond 

        if (!want_cookie)
            goto drop;
    }

    // Check whether the full connection queue is full 
    if (sk_acceptq_is_full(sk)) {
        NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
        goto drop;
    }
}

The third handshake

Server side

1） If the full connection queue is full, it will be discarded , The client doesn't know , The server initiates syn+ack

2） The number of times by tcp_synack_retries control

（ Phenomenon manufacturing , Don't make accept, Let the client fill up the connection queue resources ）

tuning

Insufficient ports

1） Adjust port  Ip_local_port_range Increase the port range

2） Use multiplexed connections

3） Use long links

4） Turn on tcp_tw_reuse and tcp_tw_recycle

In case of handshake

1） open syncookies

      Prevent too many requests from filling the half connection queue ;SYN attack ; Solve the packet loss caused by the full half connection queue at the server .

2） Increase the full connection queue length

      The whole queue ：Min(backlog,net.core.somaxconn)

3） Call as soon as possible accept

      Remove the connection from the whole queue

4） Reduce TCP Number of connections , Reject as soon as possible ;

         Kernel parameters tcp_abort_on_overflow Send directly when full rst To the client , The client receives connection reset by peer

         Use long links instead of short ones ;

         The number of retries should not be increased ;

Full queue and half queue queries

Full connection queue

#netstat -s | grep overflowed

A change in the preceding number means an overflow

Semi connected queues

       netstat –s | grep SYNs This method is wrong , Can't explain the problem Because full connection overflow will also increase .

        1）want_cookie Whether the parameter is 1, If it's true , Then the semi connection overflow and packet loss will not occur .

        2）want_cookie, Not open , except netstat –antp, Suggest checking listen On port SYN_RECV The number of

#watch 'netstat -s | grep "SYNs"'

#netstat –antp | grep SYN_RECV | wc -l

  Reference resources
https://course.0voice.com/v1/course/intro?courseId=2&agentId=0

---