UDP实现高并发其实非常简单(续集)

柔情只为你懂 2022-11-17 13:56 162阅读 0赞

上周放假时跟着小小学python，就写了一个所谓 ***“高并发UDP服务器”*** ，详见：  
[https://blog.csdn.net/dog250/article/details/115413967][https_blog.csdn.net_dog250_article_details_115413967]

之所以这么写是因为我想让UDP服务看起来像TCP服务而已，但还是发现了新东西。

我所谓的 ***服务*** ，专门指的是那种长连接，高并发的服务。

在上面这个随笔里，我的观点是 ***让socket的数量上去，并发也就上去了，剩下的就交给CPU了*** ，因此最直接的方式就是预先创建海量的reuseport UDP socket，bind到同一个端口，有客户端接入的时候，从这个socket池子里分配一个来为该客户端提供服务。但有问题：

*  ***我们该预创建多少个socket？***
 *  ***如果预创建的socket都已经在服务了，又来了请求该怎么办？***
 *  …

这里的问题在于， ***服务资源往往不该受socket数量限制，而是受CPU，内存的限制！*** 所以，本质上，我们需要一种动态创建socket的方式：

*  ***来一个请求，创建一个socket。***

这样就剩下最后一个问题了：

*  ***如何知道有客户端连接了？***

所以，需要有一个专门的socket在侦听！哈哈，是不是回到了TCP的老路子上了呢？这不就是TCP的Listen/Accept模型吗？

所以说呢，我对UDP的高并发模型的认识是正确的，至少我自己认为是正确的。我重新整理了代码，这次为了突破1024的限制，我用了poll(epoll还是有点麻烦，所以不管它)：

#!/usr/bin/python3
    import select
    import socket
    
    sd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    sd.bind(('192.168.56.101', 5001))
    sd.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
    
    READ_ONLY = ( select.POLLIN | select.POLLPRI | select.POLLHUP | select.POLLERR)
    poller = select.poll()
    poller.register(sd, READ_ONLY)
    fd_to_socket = { sd.fileno():sd, }
    
    while True:
        events = poller.poll(1000)
        for fd, flag in  events:
            s = fd_to_socket[fd]
            if s == sd: # Accept
                data, addr = s.recvfrom(1024)
                csd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
                csd.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
                csd.bind(('192.168.56.101', 5001))
                csd.connect(addr)
                fd_to_socket[csd.fileno()] = csd
                poller.register(csd, READ_ONLY)
                print('accept connection from %s:%s' % addr, 'sd[%d] created' % csd.fileno())
            else: # Echo
                data, addr = s.recvfrom(1024)
                if data:
                    print('received "%s" from %s' % (data.splitlines()[0].decode('utf-8'), addr), 'sd[%d]' % s.fileno())
                    s.sendto(data, addr)

如果不看冰山下的东西，这就已经结束了。然而冰山下有什么呢？

还是先从问题说起，如果系统已经有了10000个 ***reuseport bind到同一个端口，connect到不同客户端的socket*** ，当这些客户端发来数据的时候，内核是如何根据四元组找到对应的socket的呢？

从最老的代码直到现在，内核都只是根据bind的源IP/源端口对组织hash表，bind到同一个地址和端口的socket会链接在同一个链表中，当报文到来的时候，内核协议栈会根据目标地址和目标端口做hash，在对应的hash链表中遍历查找：

*  ***在链表中遍历，冒泡排序，找到得分最高的。***

如果一个socket connect了remote，那么将会匹配四元组，匹配成功得高分，如果没有connect的socket，将只会匹配二元组，匹配成功得低分，如果连二元组都不匹配，不得分，一遍冒泡之后，就会得到一个最佳匹配结果。

理解了这个机制之后，其实不难看出一个优化点：

*  ***如果已经匹配了一个connected socket的四元组，就没有必要继续遍历下去了，因为不可能再有更佳的匹配了。***

但这只是冰山一角。

如果在明知hash链表很长的时候，对connected socket进行四元组hash组织的话，查这个表的效率是相当高的，Linux内核的jhash是一个十分完美的hash算法实现。

这就是我上周最后一天半的实际工作，测试效果非常好：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]  
左边是优化过的，已经接入了3万的连接，socket实际查询时间只有2000ns(最下面一栏是测量脚本)，而右边原生版本仅仅接入了1万连接，socket查询时间就90万ns了。

注意左边最上面的那一行，接近300万ns的时延，那是client第一次接入时查询到UDP的 ***“Listen socket”*** 所需的时间，它恰恰是原生版本socket查询时间的3倍，毕竟它的连接数是原生版本的3倍嘛，这意味着客户端第一次接入时，是不能受惠于优化机制的：

*  ***此时还没有反向connect呢。***

这和TCP的处理是一致的， ***TCP先匹配ESTABLISHED socket，然后再匹配Listen socket*** 。然而TCP的ESTABLISHED socket是精确四元组组织的，所以匹配效率非常高。UDP无法全部精确四元组组织，只能针对connected socket来这么干，因此，只要有一个socket无法四元组组织，就无法避开那个链表冒泡遍历。

有人会质疑，我加了一个四元组匹配逻辑，这不是额外增加处理时延吗？并不。我仅仅在二元组hash链表长度达到一定程度的时候，才会进入四元组匹配，这个长度阈值如何确定呢：

*  ***假设阈值为L，意味着遍历冒泡L个socket的处理时间和四元组hash计算的处理和匹配时长一致。***

所谓的可扩展性不就这回事嘛？其实就是 O ( 1 ) O(1) O(1)，hash才是王道。那么如何保证四元组hash不会冲突成一个超长链表呢？不是学数学的，还是相信jhash为好吧。

借用eBPF来为socket查找提供策略定制功能是不错的，这也是趋势，Linux内核确实也为这件事留下了钩子，但在我看来，总不能什么事都eBPF吧，利器要用在夹缝里，而不能当大刀挥舞。

我一直都觉得UDP的实现效率差是历史原因，历史上并没有什么动力促使人们对UDP采用更优化的算法，可如今呢？事情起了变化，QUIC，HTTP 3+，各种乱七八糟的基于UDP的自研传输协议，我就不信精通这精通那的高人们没人做优化，我这点儿雕虫小技只是一个引子罢了。 ***对UDP实现上的不足持续优化是正道。一直到把UDP搞成像TCP那样乱七八糟，但效率高啊！***

当然，如果大家一窝蜂all in DPDK/XDP的话，内核里的这点儿破事，那就留给low人吧。

纵观一部事关Linux内核的技术史，就是一部把任何一个逻辑搬进再搬出再搬进Linux内核的历史，Linux内核就是这么被乱入乱出的：

*  2.4内核里有一个Web服务器。
 *  2.6内核里没有了这个Web服务器。
 *  嫌内核协议栈处理太低效，就有了Netmap/PF\_RING/DPDK的bypass技术。
 *  把协议处理逻辑搬进smartnic。
 *  把SSL/TLS搬进Linux内核。
 *  以在Linux内核实现一个加解密隧道而自豪(就是我)。
 *  在Netfilter上实现NAT64。
 *  把NAT64处理逻辑通过tun网卡搬到用户态。
 *  用户态实现UDP可靠传输库。
 *  UDP可靠传输库搬进内核。

不过说实话，网络协议栈本就不适合在内核里实现，只是一开始恰好这么做了后面也就延续了而已。

--------------------

浙江温州皮鞋湿，下雨进水不会胖。

[https_blog.csdn.net_dog250_article_details_115413967]: https://blog.csdn.net/dog250/article/details/115413967
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RvZzI1MA_size_16_color_FFFFFF_t_70]: /images/20221022/55d895d3cdc04e21974e8fbedcbd5f18.png