由于端午节加班攒了两天调休,周四,五就申请休假了,刚申请下来调休,老婆突然就决定带着小小西北行了,周五出发,这次是去环青海…休假本为了放松,却成了坑。周四先是去看了《加勒比海盗5》,然后我就觉得这假期不该申请,于公于私我都是政治不正确…其实我想说的是,休假比上班累很多!工作日在家里忍耐老婆拖把在手,抱怨在口几个小时(如果在公司有这种同事,离职即可,至少可以沟通吧,但在家里,能离职吗?能沟通吗?),同时想着和我一样加班的同事除了我之外都没休假,觉得就我矫情…不管怎样,我干了错事,但这不就正是我之为我的特征吗?明天老婆就带小小出发了,我发誓我会睡一整天!
  …本文依然是以技术为主题,本次聊聊syncookie的性能和DDoS。
  虽然现在的内核都已经是4.11版本了,但本文依旧基于较老的内核版本旧事重提,就4.7版本的一个针对syncookie的一个优化书写一段吹捧与嘲讽。
  自从4.4版本的Lockless TCP listener以来,针对TCP在大并发连接处理这块一直都没有更大的突破,也许在大多数开发者看来,摆脱了显式大锁的束缚,Lockless TCP listener已经彻底解放了,余下的精力应该集中在更多的“业务逻辑”上了…有谁能指望基础设施会持续日新月异呢?

附:关于Lockless TCP listener

关于Lockless TCP listener的意义和实现方式,可以参见以下的资源(其中有我2015年大悲哀时写的):
《Lockless TCP listener》
《Linux内核4.4版本带来的网络新特性》
《多核心Linux内核路径优化的不二法门之-多核心平台TCP优化》


事情果真就这样结束了吗?Lockless TCP listener真的就是事情的全部吗?Linux 4.7内核对此给出了否定的回答。

Linux 4.7之前TCP连接处理问题

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

tcp_v4_rcv(skb)
{sk = lockless_lookup(skb);if (sk.is_listener) {
// Lockless beginprocess_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 endgoto data;} else {
data:lock(sk);process(sk, skb);unlock(sk);}
}

这个逻辑已经臻于完美了,至少在表面上看来确实如此!
  当我知道了4.7内核针对syncookie的优化之后,我便内窥了lockless_lookup内部,突破性的改进在于,4.7内核用真正的RCU callback替换了一个仅有的Atomic操作,做到了真正的无锁化查找!
  看来我们都被骗了,其实所谓的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();

当然,这个lock/unlock没有体现在tcp_v4_rcv函数里,而是体现在了ip_local_deliver_finish里。

社区patch

以下是一个社区的patch:
[PATCH v2 net-next 06/11] tcp/dccp: do not touch listener sk_refcnt under synflood
作者详细说明了取消原子变量操作后带来的收益并且携带测试结果,我想这算是令人信服的,最重要的是,它已经被合入内核了。
  值得一提的是,这个patch仅仅针对新建连接性能有所提升,对TCP的传输性能没有任何作用,竞速者慎入。

关于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值固定的简单凯撒加密。是不是更简单呢?
  别总是一提SHA,一提hash就碰撞个碰撞啥的,要看当前碰撞的后果严重吗?不严重,碰撞又如何?!

关于本文

为什么会有本文?
  我借本文的结尾,对重复造轮子表达一点自己的看法。
  早在2014年搞nf_conntrack的时候,接触了nulls hlist,后来接触到Fastsocket对TCP并发连接处理的优化,再后来我写了个仿Fastsocket TCP无锁握手处理的Demo,最后发现这些都在4.4版本发布的时候合入了,所谓该来的终究会来的,其实这些思路都差不多,所谓正确的做法往往只有少数几种,错误的方向却无限多,稍不留意就会南辕北辙…关于TCP连接处理的持续优化过程,这并不是什么黑科技,像阿里,新浪,Google,华为,甚至我自己想到的方案都差不多,只要有一方做出来并放出,其它的直接用就可以了,我的做法就是直接用4.7+版本。
  所以说,明知道高版本里终究会有的东西,或者已经有的东西,最快捷的且正确的做法难道不是直接移植吗?为什么要重新造轮子呢?重新造轮子难道不是最不值得提倡的吗?
  以一个研发工程师的视角,重新造轮子当然有意义,因为这是自己的立身之本,研发工程师无所谓是不是重新造,他们关注的只是有能力造。但站在产品的角度,他们关注的只是结果,这是典型的过程控制和目标管理之间的思维差异!
  我写了很多文章,有解析已有技术的,有阐述替代方案的,还有预测性的,但几乎我没有把它们引入工作,因为没有人需要,所有人都知道什么叫目标管理,每个人在表达自己观点之前,早就准备
了一百万个理由在背后作为掩护,其中很多都是伪的,伪引用,伪逻辑,最高境界就是伪道德,这就是现实,所以说我一般会避免跟人争论,选择保持安静,默默地做对我来讲是舒适的。
  我倾向于把一些观点整理成文,然后Email抄送给我收藏的感兴趣者,发送给微信好友,偶尔发个朋友圈,如果有人真的对问题感兴趣或者观点不同,我想文字的回执会让人谨慎得多,毕竟每个人都有三寸不烂之舌,扯几句是零成本的,但是写下来就会有负担,至少在我看来,事情就是这样。

BTW,本文中除了少数的个人观点,其余的都是从别处看的,是吧,这责任推卸的…

Linux 4.7内核针对syncookie性能所做的优化相关推荐

  1. 英特尔+性能+linux,Linux 4.20内核在英特尔处理器上性能比Linux 4.19低,附原因解释...

    在最新的Linux 4.20内核(Linux Kernel 4.20)上测试英特尔处理器性能,结果显示,在大多数低中高端英特尔处理器上Linux 4.20内核性能都比Linux 4.19内核的低,比如 ...

  2. Linux 3.10内核锁瓶颈描述以及解决-IPv6路由cache的性能缺陷

    大量线程争抢锁导致CPU自旋乃至内核hang住的例子层出不穷. 我曾经解过很多关于这方面的内核bug: nat模块复制tso结构不完全导致SSL握手弹证书慢. IP路由neighbour系统对poin ...

  3. 内核同步对性能的影响及perf的安装和简单的使用

    更多文章目录:点击这里 GitHub地址:https://github.com/ljrkernel 内核同步对性能的影响及perf的安装和简单的使用 看了一篇关于多线程应用程序性能分析的外文,结合之前 ...

  4. linux核能软件,ARM big.LITTLE大小核架构在Linux和Android内核下多核调度算法

    在2013年,big.LITTLE家族又增加了新的SoC实现,有2个Cortex-A15+3个Cortex-A7核的ARM的参考测试芯片TC2,以及在三星Galaxy S4手机中应用的Samsung- ...

  5. linux下proc里关于磁盘性能的参数

    我 们在磁盘写操作持续繁忙的服务器上曾经碰到一个特殊的性能问题.每隔 30 秒,服务器就会遇到磁盘写活动高峰,导致请求处理延迟非常大(超过3秒).后来上网查了一下资料,通过调整内核参数,将写活动的高峰 ...

  6. Linux故障之内核反向路由检测

    参考链接 环境: centos8,双网卡 ens18: 192.168.6.51 ens19: 192.168.2.111 过程中发现,client:192.168.6.41去访问192.168.6. ...

  7. Linux系统和内核目录解析

      在学习Linux以及Linux内核的过程中,总是会忘记Linux系统以及内核里的一些目录的含义,因此特地收集了关于Linux系统目录的含义解析以及Linux内核目录的解析. Linux系统目录解析 ...

  8. linux 2.4内核编译,linux 2.4内核编译详解

    2.4内核编译详解 内核简介 内核,是一个操作系统的核心.它负责管理系统的进程.内存.设备驱动程序.文件和网络系统,决定着系统的性能和稳定性. Linux的一个重要的特点就是其源代码的公开性,所有的内 ...

  9. linux之mini2440内核移植

    与其它操作系统相比,Linux最大的特点:它是一款遵循GPL(General Public License  GNU通用公共许可证(简称为GPL),是由自由软件基金会发行的用于计算机软件的许可证.)的 ...

最新文章

  1. axios post body参数_Vue开发中的一些问题(axios封装)
  2. kubernetes之kubedns部署
  3. 有关(int)和(int)的区别
  4. 【小练习】“表格”制作及答案
  5. 计算机一级挂科率,[转]计算机一级难吗?看了它想挂科,难难难难把此(精)
  6. centos service 无法用
  7. eclipse导入class文件
  8. 设计模式--23、访问者模式
  9. textarea标签内的文字无缘故居中解决原因
  10. 安徽省2018计算机一级9月报名,2018年9月份全国计算机等级考试安徽财经大学考点报名通知...
  11. 9-11NOIP模拟赛总结
  12. 【程序的流程】—— 顺序 / 分支 / 循环
  13. 手写数字数据集——MINST的读取及预处理
  14. 【Django】Specifying a namespace in include() without providing an app_name is not supported
  15. 计算机vb期末试题及答案,VB期末考试试题及答案
  16. ubuntu记录pdf手写笔记: 数位板(硬件)+xournal(软件)
  17. ICTCLAS 汉语词性标注
  18. Kafka 入门二 kafka的安装启动
  19. 车载信息系统平台的未来发展
  20. 【微信小程序】图片下方有白边

热门文章

  1. linux2007共享文件夹,Linux如何共享文件夹?
  2. jquery mobile textarea宽度更改
  3. ENSP:三层交换机+路由器+Cloud实现上网
  4. 查看穿山甲sdk版本号
  5. 计算机感染病毒后 一定不能清除的措施是,一定不能清除病毒的措施是什么?...
  6. 软件工程实验报告七 UML建模-对象模型(包图、类图)
  7. Java中的组合、聚合和关联关系
  8. [附源码]JAVA毕业设计高速收费系统后台(系统+LW)
  9. 可穿戴设备在娱乐领域的应用:音乐、电影和游戏
  10. 永磁材料行业研究及十四五规划分析报告