tcp的半链接与彻底链接队列

时间 2019-11-07

原文原文链接

队列及参数

server端的半链接队列(syn队列)

在三次握手协议中，服务器维护一个半链接队列，该队列为每一个客户端的SYN包开设一个条目(服务端在接收到SYN包的时候，就已经建立了request_sock结构，存储在半链接队列中)，该条目代表服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包（会进行第二次握手发送SYN＋ACK 的包加以确认）。这些条目所标识的链接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。
该队列为SYN 队列，长度为 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ，在机器的tcp_max_syn_backlog值在/proc/sys/net/ipv4/tcp_max_syn_backlog下配置。php

server端的彻底链接队列(accpet队列)

当第三次握手时，当server接收到ACK 报以后，会进入一个新的叫 accept 的队列，该队列的长度为 min(backlog, somaxconn)，默认状况下，somaxconn 的值为 128，表示最多有 129 的 ESTAB 的链接等待 accept()，而 backlog 的值则应该是由 int listen(int sockfd, int backlog) 中的第二个参数指定，listen 里面的 backlog 能够有咱们的应用程序去定义的。html

当Client发送SYN包以后挂了(`syn flood攻击`)

Client发送SYN包给Server后挂了，Server回给Client的SYN-ACK一直没收到Client的ACK确认，这个时候这个链接既没创建起来，也不能算失败。这就须要一个超时时间让Server将这个链接断开，不然这个链接就会一直占用Server的SYN链接队列中的一个位置，大量这样的链接就会将Server的SYN链接队列耗尽，让正常的链接没法获得处理。mysql

目前，Linux下默认会进行5次重发SYN-ACK包，重试的间隔时间从1s开始，下次的重试间隔时间是前一次的双倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，因此，总共须要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会把断开这个链接。因为，SYN超时须要63秒，那么就给攻击者一个攻击服务器的机会，攻击者在短期内发送大量的SYN包给Server(俗称 SYN flood 攻击)，用于耗尽Server的SYN队列。对于应对SYN 过多的问题，linux提供了几个TCP参数：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 来调整应对。linux

net.ipv4.tcp_synack_retries #内核放弃链接以前发送SYN+ACK包的数量
net.ipv4.tcp_syn_retries #内核放弃创建链接以前发送SYN包的数量nginx

为了应对SYNflooding（即客户端只发送SYN包发起握手而不回应ACK完成链接创建，填满server端的半链接队列，让它没法处理正常的握手请求），Linux实现了一种称为SYNcookie的机制，经过net.ipv4.tcp_syncookies控制，设置为1表示开启。简单说SYNcookie就是将链接信息编码在ISN(initialsequencenumber)中返回给客户端，这时server不须要将半链接保存在队列中，而是利用客户端随后发来的ACK带回的ISN还原链接信息，以完成链接的创建，避免了半链接队列被攻击SYN包填满。sql

当syn队列满的状况(`tcp_abort_on_overflow`)

对于SYN半链接队列的大小是由（/proc/sys/net/ipv4/tcp_max_syn_backlog）这个内核参数控制的，有些内核彷佛也受listen的backlog参数影响，取得是两个值的最小值。当这个队列满了，不开启syncookies的时候，Server会丢弃新来的SYN包，而Client端在屡次重发SYN包得不到响应而返回（connection time out）错误。可是，当Server端开启了syncookies=1，那么SYN半链接队列就没有逻辑上的最大值了，而且/proc/sys/net/ipv4/tcp_max_syn_backlog设置的值也会被忽略。segmentfault

Client端在屡次重发SYN包得不到响应而返回connection time out错误tomcat

查看服务器

netstat -s | grep LISTEN
4375 SYNs to LISTEN sockets dropped

当accept队列满的状况

当accept队列满了以后，即便client继续向server发送ACK的包，也会不被响应，此时ListenOverflows+1，同时server经过/proc/sys/net/ipv4/tcp_abort_on_overflow来决定如何返回，0表示直接丢弃该ACK，1表示发送RST通知client；相应的，client则会分别返回read timeout 或者 connection reset by peer。cookie

client则会分别返回read timeout 或者 connection reset by peer

查看

root@b5dbe93bcb04:/opt# netstat -s | grep listen
22438 times the listen queue of a socket overflowed

accept队列满了，对 syn队列也有影响，在代码 net/ipv4/tcp_ipv4.c ：

int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
    /*tcp_syncookies为2 进行syn cookie
      tcp_syncookies为1 且request队列满了 进行syn cookie处理
      tcp_syncookies为0 且request队列满了 将该syn报文drop掉
    */
    if ((sysctl_tcp_syncookies == 2 ||
         inet_csk_reqsk_queue_is_full(sk)) && !isn) {
        want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
        if (!want_cookie)
            goto drop;
    }

    /* Accept backlog is full. If we have already queued enough
     * of warm entries in syn queue, drop request. 
     */
    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;
}

accept队列大多数状况下会比较小，因此会出现SYN 队列没有满，而ACCEPT 队列满了的状况，此时会按照tcp_aborton_overflow来决定直接丢弃，仍是返回拒绝RST。而若是启用了syncookies，那么syncookies会开启，限制SYN包进入的速度。

当系统丢弃最后的 ACK，而系统中还有一个 net.ipv4.tcp_synack_retries 设置时，Linux 会从新发送 SYN ACK 包。而客户端收到多个 SYN ACK 包，则会认为以前的 ACK 丢包了。因而促使客户端再次发送 ACK ，在 accept队列有空闲的时候最终完成链接。若 accept队列始终满员，则最终客户端收到 RST 包。