关于Linux UDP/TCP reuseport 二三事

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                       

聊到reuseport，大致要从四年前说起。

OpenVPN-以往的故事

当时要优化OpenVPN的并发性能，了解到socket有一个reuseport特性，于是非常兴奋，本着拿来主义的想法，无非就是在OpenVPN的源码里加一个setsockopt吧…我们当时基于Linux 2.6.32开发，无奈并没有实现这个特性，后来的版本也只是实现了reuseport热备份模式，并没有实现负载均衡模式，也是无奈…

不过无所谓，好在我对Linux网络部分的代码是很熟悉的，当我知道Linux 3.9内核实现了完备的reuseport负载均衡模式时，就迫不及待地将它移植到了2.6.32内核，也就半个小时不到的样子搞定，然后就可以愉快地玩OpenVPN了！

故事零零散散地被记录，从未被整理，找到下面几篇，可见一斑：
基于UDP服务的负载均衡方法：https://blog.csdn.net/dog250/article/details/17061277
OpenVPN多处理之-为什么一定要做：https://blog.csdn.net/dog250/article/details/38154707
Linux 4.6内核对TCP REUSEPORT的优化：https://blog.csdn.net/dog250/article/details/51510823

我玩reuseport的几个阶段-故事的延续

在继续reuseport的故事之前，先来回顾一下reuseport的版本。

围绕着reuseport如何来hash的细节，大致可以分为以下几个阶段：

• 版本1：3.96内核轻移植到2.6.32内核的reuseport版本
  这个不多说，我当时只是保证能用即OK，二十分钟的移植工作当然是没有时间去深究的。
• 版本2：加入OpenVPN session ID的版本
  SID版OpenVPN，即2013年底对OpenVPN的一个增强版本，我觉得我这个是个创举，一举解决了移动终端频繁的3G/Wifi，强信号/弱信号切换导致的断线重连问题。该版本的OpenVPN对应的Linux内核需要对reuseport逻辑进行修正，即用OpenVPN协议头中的sid来计算hash key，而不再使用传统的四元组。详情参见：
  OpenVPN移动性改造-靠新的session iD而不是IP/Port识别客户端：https://blog.csdn.net/dog250/article/details/29180765
• 版本3：3.96内核-4.5内核版本的数值分析伪随机版本
  返璞归真，自3.96原生内核，我便不再自己玩了，这个时候我已经不再继续做OpenVPN了，扔下一个烂摊子，发现reuseport已经被我玩坏了。
  于是仔细分析了原生的实现，其中的核心是next_pseudo_random32函数，这是一个数值分析方法里导出的公式，该版本的reuseport就是用它来做next伪随机数的，我们信赖这个公式，所以我们信赖最终的结果是均匀的。
• 版本4：4.6内核的取模版本，顺带支持bpf
  这个版本就是迄至4.14版本中一直在用的，详情参见：
  Linux 4.6内核对TCP REUSEPORT的优化：https://blog.csdn.net/dog250/article/details/51510823

以上，除了版本2是我自己派生的之外，其它3个版本几乎都是原生的，不管是采用数值复分析的方法还是采用取模的方法，其最终的hash结果都是不可靠的。这种不可靠主要由两个原因导致，我来分别说。

1. 数据接收端的socket变更导致的不一致

   以取模版的hash为例，考虑以下情景，一共建立了n n，然后每隔2个slot填充相同的socket即可，如果有新的socket创建，就随机拆分，即reuse->next_slot以2为单位进行随机，然后随机到那个slot，就按照伙伴系统的算法进行拆分…嗯，棒极了。

   显然，不管再怎么好，这也不是内核的标准功能，也许，很多人正希望使用原生的实现呢…于是，一个新的sockopt是必要的，即SO_REUSEPORTHOLD。

   reuseport版本5

   于是出现了reuseport版本5，正如上节所述。

   展望-未来会发生什么

   reuseport一直以来都是青睐UDP而不是TCP！

   随着http2的逐渐进入视野，几乎全部基于tcp的http1正在加速退出，未来的UDP将大展宏图。

   最为先行者，Google已经将QUIC用在了其自家的Chrome浏览器上封装其自家的http流量，这开了一个大口子，就像G家的bbr开了个大口子一样。为什么是UDP？

   因为TCP过时了，过时了，过时了，因为TCP过时了！

   很多人都知道Google在TCP上的最新进展，那是因为教育的落后，我们付出了大量的时间精力学习复杂的一逼的TCP，却忽略了UDP。TCP是30年前的协议，它也是为30年前的网络场景准备的，然而我们像追星一样追了30年。其实Google的很多TCP优化都是从其在QUIC的试验田里移植过来的，Google可能早就想拥抱UDP了，其对TCP的态度更多的是兼容，而不是优化！TCP到底怎么了？

   • TCP强行打包了握手，按序…强买强卖
   • TCP实现可插拔功能非常不灵活
   • TCP为了节省空间开销付出了时间的代价(30年前的场景)
   • TCP完全基于ACK而全无NAK
   • TCP不得不在信息量极少的情况下实现失败的拥塞控制
   • QUIC的bbr性能比TCP的bbr性能高
   • TCP的脑残粉太多太多了

   UDP的优势在于灵活，比如它可以实现松散按序传输，特别是对于音视频类的传输非常棒，偶尔的丢包不会阻碍窗口向前滑行，拥塞控制可以基于ACK+NAK从而精确判断到底发生了什么…

   UDP的空间非常大，因为很多TCP的特性都要你自己实现，很多TCP中你不需要的东西你也可以随便抛弃，reuseport只是其中一个可以利用的，但绝不是唯一的一个，相信今后会有更多的基于UDP的可玩且好玩的东西出来。

   后记

   本来打算去大鹏杨梅坑过个完整的周末，无奈周六上午小小有家长会，只能下午出发了…别说搞IT的加班上瘾，小学老师也是一个加班上瘾的群体…多少个周末都被小小小学的各种活动所破坏，都上一周班了，就不能消停点吗？！

              

给我老师的人工智能教程打call！http://blog.csdn.net/jiangjunshow