Linux 4.7内核syncookie的性能

虽然现在的内核都已经是4.11版本了，但本文依旧基于较老的内核版本旧事重提，就4.7版本的一个针对syncookie的一个优化书写一段吹捧与嘲讽。

自从4.4版本的Lockless TCP listener以来，针对TCP在大并发连接处理这块一直都没有更大的突破，也许在大多数开发者看来，摆脱了显式大锁的束缚，Lockless TCP listener已经彻底解放了，余下的精力应该集中在更多的“业务逻辑”上了…有谁能指望基础设施会持续日新月异呢？

Linux 4.7之前TCP连接处理问题

我们已经知道，在TCP的接收主函数tcp_v4_rcv中，基于skb的元数据查找socket的过程是无锁的，查找完毕之后，会针对找到的socket结果上锁或者无锁处理，逻辑非常清晰：

tcp_v4_rcv(skb)
{
    sk = lockless_lookup(skb);
    if (sk.is_listener) {
// Lockless begin
        process_handshake(sk, skb);
        new_sk = build_synack_sk(skb);
        new_sk.listener = sk;
    } else if (sk.is_synrecv) {
        listener = sk.lister;
        child_sk = build_child_sk(skb, sk);
        add_sk_into_acceptq(listener, child_sk);
// Lockless end
        goto data;
    } else {
data:
        lock(sk);
        process(sk, skb);
        unlock(sk);
    }
}

这个逻辑已经臻于完美了，至少在表面上看来确实如此！

当我知道了4.7内核针对syncookie的优化之后，我便内窥了lockless_lookup内部，突破性地改进在于，4.7内核用真正的RCU callback替换了一个仅有的Atomic操作，做到了真正的无锁化查找！

资料直通车：最新Linux内核源码资料文档+视频资料

学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

看来我们都被骗了，其实所谓的lockless_lookup并不是真正的lockless，为了应景和应题，本文只讨论Listener socket，我们来看下它的逻辑：

lockless_lookup(skb)
{
    hash = hashfn(skb);
    hlist = listener_list[hash];
// 第一部分：#1-查找socket
begin:
    sk_nulls_for_each_rcu(sk, node, hlist) {
        if (match(skb, sk)) {
            ret = sk;
        }
    }
// 第二部分：#2-与socket重新hash并插入hlist进行互斥    
    if (get_nulls_value(node) != hash) {
        goto begin;
    } 

// 第三部分：#3-与socket被释放进行互斥   
    if (ret) {
        if (!atomic_inc_not_zero(ret))
            ret = NULL;
    }

    return ret;
}

这个逻辑可以分为3个部分，我在注释中已经表明，可以看到，虽然在调用者tcp_v4_rcv看来，查找socket的操作是无锁的，然而内窥其实现逻辑之后便会发现，它其实还是在内部进行了两个轻量级的互斥操作。

nulls hlist互斥

由于在lockless_lookup被调用时是无锁的，所以在sk_nulls_for_each_rcu遍历过程中会出现以下情况造成遍历混乱：

这种情况下，常规的hlist是无法发现的，因为这种hlist以next为NULL视为链表的结束。不管一个node被重新hash到哪个链表，在结束的时候都会碰到NULL，此时你根本区别不出来这个NULL是不是一开始遍历开始时那个hlist冲突链表的NULL。怎么解决这个问题呢？上锁肯定是不妥的，幸亏Linux内核有一个精妙的数据结构，即nulls hlist！下面我先来简单地介绍一下这个精妙的hlist数据结构和标准的hlist有何不同。

差异：

nulls hlist不再以NULL结尾，而以一个大到2^31空间的任意值结尾

nulls hlist以node最低位是不是1标识是不是链表的结束，于是nulls hlist的结尾节点的next字段可以编码为高31位和低1位，如果低1位为1，那么高31位便可以取出当初存进去的任意值，是不是很精妙呢？！之所以可以这么做，原因很简单，在计算机中，Linux内核数据结构的所有的地址都是对齐存放的，因此最低1位的数据位是空闲的，当然可以借为它用了。

现在我们考虑这个nulls node的高31位存什么数据好呢？答案很明确，当然是存在hlist的hash值了，这样以下的操作一目了然：

init:
for (i = 0; i < INET_LHTABLE_SIZE; i++) {
    // 低1位和高31位的拼接：
    // 低1位保存1，代表结束，新节点会插入到其前面
    // 高31位保存该list的hash值
    listener_list[i].next = (1UL | (((long)i) << 1)) 
}

lookup:
hash1 = hashfn(skb);
hlist = listener_list[hash1];
sk_nulls_for_each_rcu...{
    ...
}
hash2 = get_nulls_value(node);
if (hash1 != hash2) {
    // 发现结束的时候已经不在开始遍历的链表上了
    goto begin;
}
//.....

是不是很精妙呢？其实在Linux中，很多地方都用到了这个nulls hlist数据结构，我第一次看到它是在当年搞nf conntrack的时候。

以上的叙述大致解释了这个nulls hlist的精妙之处，说完了优点再看看它的问题，这个nulls hlist带来的不断retry是一种消极尝试，非常类似顺序锁读操作，只要读冲突便一直重复，直到某次没有冲突，关于顺序锁，可以看一下read_seqbegin/read_seqretry以及write_seqlock这对夫妻和小三。

为什么会这样？答案是，在无锁化的lookup中，必须这样！因为你取出一个node和从该node取出下一个node之间是有时间差的，你没有对这个时间差强制没有任何保护措施，这就是根本原因，所以，消极的尝试也未尝不是一个好办法。

总结下根本原因，取出node和取出下一个node之间存在race！

原子变量互斥

刚刚说完了lockless_lookup的第二部分，下面看看第三部分，atomic_inc_not_zero带来的互斥。

我们知道，在sk_nulls_for_each_rcu找到一个匹配的socket并且nulls node检查通过之后，在实际使用它之前，由于无锁化调用，会存在race，此期间可能会有别的线程将该socket释放到虚空，如何避免使用一个已经被释放的socket呢？这个很简单，操作原子计数器即可：

free：
if (atomic_dec_and_test(sk)) {
    // 此往后，由于已经将ref减为0，别处的inc_not_zero将失败，因此可以放心释放socket了。
    free(sk);
}

lookup：
if (ret && !atomic_inc_not_zero(ret)) {
    ret = NULL;
    goto done;
}
// 此处后，由于已经增加了ref，引用的数据将是有效数据
//...

虽然这个Atomic变量不是什么锁，但是在微观上，操作它是要锁总线的，即便在代码层面没有看到任何lock字眼，但这是指令集的逻辑。当面对ddos攻击的时候，试想同时会有多少的线程争抢这个Atomic底下的总线资源！！这是一笔昂贵的开销！

为什么非要有这么一个操作呢？答案很明确，怕取到一个被释放的socket从而导致内核数据混乱，简单点说就是怕panic。所以必然要有个原子变量来保护一下，事实证明，这么做还真不错呢。然而把问题更上一层来谈，为什么内核数据会混乱导致panic？因为取出node和使用node之间存在race，在这两个操作之间，node可能会被释放掉。这一点和上面的“取出node和取出下一个node之间存在race”是不同的。

现在发现了2个race：

• 取出node和取出下一个node之间
• 取出node和使用node之间

但归根结底，这两个race是同一个问题导致，那就是socket被释放(重新hash也有个先被释放的过程)！如果一个socket在被lookup期间，不允许被释放是否可以呢(你可以调用释放操作，但在此期间，你要保证数据有效)？当然可以，如何做到就是一个简单的事情了。如果能做到这一点并且真的做了，上述针对两个race的两个互斥就可以去掉了，TCP的新建连接数性能指标必然会有大幅度提升。

Linux 4.7的优化

Linux 4.7内核通过SOCK_RCU_FREE标识重构了sk_destruct的实现：

void sk_destruct(struct sock *sk)
{
    if (sock_flag(sk, SOCK_RCU_FREE))
        call_rcu(&sk->sk_rcu, __sk_destruct);
    else
        __sk_destruct(&sk->sk_rcu);
}

如果携带有SOCK_RCU_FREE标识，便通过RCU callback进行释放，我们知道，RCU callback的调用时机是必须经过一个grace period，而这个period通过rcu lock/unlock可以严格控制。

一切显得简单明了。Linux 4.7内核仅为Listener socket设置了SOCK_RCU_FREE标识：

// 创建socket
__inet_hash(...)
{
    ...
    sock_set_flag(sk, SOCK_RCU_FREE);
    ...
}

// 从一个Listener socket派生子socket
inet_csk_clone_lock(...)
{
    struct sock *newsk = sk_clone_lock(sk, priority);
    if (newsk) {
        ...
        /* listeners have SOCK_RCU_FREE, not the children */
        sock_reset_flag(newsk, SOCK_RCU_FREE);
        ...
    }
    ...
}

这保证了在lockless_lookup调用中不必再担心取到错误的数据和无效的数据，前提是lockless_lookup的调用必须有rcu锁的保护。这很容易：

rcu_read_lock();
    sk = lockless_lookup(skb);
    ...
done:
    rcu_read_unlock();

关于DDoS的认知

我不想在这里爆粗口，但我还是忍不住说“机器在被DDoS时仅仅关注CPU使用率的”都是XX。抗DDoS指标难道不该是服务不可用之前的最大pps吗？

下面谈下CPU使用率的问题。

关注这个并且时刻关注这个的基本都是玩过PC时代组装机的那帮人，当然也包括我自己。可能也受点微软的误导。每次打开任务管理器，发现CPU使用率超过50%的时候，是不是就觉得天都要塌下来了…继续之前，我先说几件事。

中国很多人买了西装之后，一直到扔掉都不会把袖口的商标撕掉，很多人买了沙发，一直到搬家把这沙发当旧货卖掉时都不会撕开沙发上塑料薄膜，几乎95%以上的人会在自己的iPhone或者S6e/S7e上加个壳子贴个膜不是为了美观而是为了怕划痕，这就是我们金玉其外的性格，对于内在当然是内敛越好了。我们忽略了一个重要的东西，那就是除了内在的，其它的都是耗材。西装就是用来穿的，穿破了再买，沙发就是用来坐的，真皮沙发外面套个塑料薄膜，难道就是为了不脏吗？…CPU难道不就是用来飙的吗？如果你花了100块钱买了一块CPU，结果它的利用率仅仅不到50%，你不是白花了50块钱吗？

不要把耗材当古董来收藏！

我们试想一台服务器被DDoS时会怎样？它应该怎样？如果服务器被猛打，那么CPU一定会飙高到几乎100%，这就是DDoS的定义！那些号称自己的服务器在猛打时还能悠闲保持CPU利用率10%的，都是扯淡，他们是主动拒绝服务的骗子。

你有100%的能力，却只释放出10%。哪怕是没有被攻击，只要CPU飙到70%以上，我相信很多不称职的运维第一反应肯定是哪里出故障了，这故障一定是实现上的bug导致，而不是访问模式导致的流量异常。其实他们的这种行为也无可厚非，毕竟他们也是领薪水的，维持各项指标的正常能让他们基本“称职”，一旦有异常，那可能就意味着“失职”，如果平时CPU利用率都是30%，突然有一天变成了60%，他们一定会害怕背锅失职，在运维眼里，系统保持正常是最好的，如果指标优化了，那是研发的功劳，这是羚羊，鬣狗以及狮子之间的博弈，所得和所失也有一顿饭和一条命之间的差别。

谜底很简单，理论上讲，只要CPU没有持续100%，哪怕一直持续99%，也可以说CPU还有1%的空闲，此时CPU仍然可以说没有满载。加上调度开销和统计误差，一台服务器的CPU利用率持续保持在85%左右是最佳的，这说明它没有在空转浪费电能。如果你的服务器CPU持续飙高到85%但是服务却不可用了，那是你的服务程序设计的有问题，但几乎可以肯定不是操作系统的问题。

如果服务程序开发者觉得这不公平，说服他们其实也并不难，你拿一个原生Linux发行版装上他的服务，如果是OS内核的问题，世界上这么多人难道就没有发现吗？

总之，DDoS是一种正常的现象，它并不是异常。抗DDoS很大意义上是指在面对DDoS时的反应，在CPU接近100%时尽可能保持高的pps。

最后看个DDoS防护相关的实现细节，DDoS来临前，Linux一般会开启syncookie，此时会在返回的seq中编码很多信息，为了保证这些信息的隐蔽性，编码后的seq需要做杂凑(其实就是hash)，然而Linux内核使用的是SHA算法，这个算法是不是太重了呢？

在DDoS来临时，要考虑的是此时主要矛盾是什么？是怕别人猜出序列号从而进行后续的攻击呢，还是说怕响应不过来当前的处理请求？我想都已经被打了，还是顾眼前会更加现实！虽然我也知道如果被人猜出了序列号，攻击会更加严重，形成一个正反馈的爆炸点，鉴于此我肯定不会推荐使用不编码的原始值作为序列号直接返回(即编码后的裸数据)，而是推荐一种简单的杂凑，比如K值固定的简单凯撒加密。是不是更简单呢？