CN115118791B - Udp报文的分发方法、设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种UDP报文的分发方法、设备及可读存储介质，一个应用服务的多个进程组同时存在时，每个进程组具有独立的ebpf资源，ebpf资源用于保存进程组中每个进程的文件句柄fd的信息。服务器接收到UDP报文后，根据UDP报文的四元组从端口复用组的多个进程组中确定出目标进程组，从目标进程组的各进程的fd中选择出目标fd，并利用目标fd收发数据。采用该种方案，由于每个进程组具有独立的ebpf资源，不同进程组中的进程不会抢占同一个fd，确保多个进程组共存时UDP报文的分发不会出现错乱，实现保证业务质量的目的。而且，还能够避免UDP connect带来的软中断性能消耗问题，并发能力高。

Description

UDP报文的分发方法、设备及可读存储介质

技术领域

本申请涉及互联网技术领域，特别涉及一种UDP报文的分发方法、设备及可读存储介质。

背景技术

用户数据报协议(User Datagram Protocol，UDP)是开放式系统互连(OpenSystemInterconnect，OSI)参考模型中的一种无连接的传输层协议。随着技术的发展，越来越多的流媒体协议基于UDP实现。

基于UDP实现的流媒体协议包括：安全可靠传输(Secure Reliable Transport，SRT)协议、网页即时通信(Web Real-Time Communication，WEBRTC)协议、快速UDP互联网连接(Quick UDP Internet Connections，QUIC)协议等。相较于传输控制协议(TransmissionControl Protocol，TCP)，UDP没有连接的概念、速度快、可靠性较低。

Nginx服务器是一个高性能的超文本传输协议(Hyper Text Transfer Protocol，HTTP)和反向代服务器，有着高并发、性能好和占用内存少等特点。基于Nginx的流媒体服务器被广泛应用于流媒体技术中。Nginx服务器上部署多个应用服务，多个应用服务能够同时运行，每个应用服务对应一组进程，一组进程包含多个进程。一组进程使用同一个UDP端口收发数据。

然而，经验证发现：当应用服务升级或热更新时，会存在两组或多组进程。这时候，多组进程使用同一个UDP端口进行数据收发会带来数据错乱的问题。例如，存在两组进程，分别为旧进程组和新进程组，则原本由新进程组中的进程分发的UDP报文被分发到旧进程组中的进程，或者，一个UDP报文原本应该分发给旧进程组中的进程，却分发给了新进程组中的进程。

发明内容

本申请提供一种UDP报文的分发方法、设备及可读存储介质，每次产生一个新的进程组，则为该新进程组分配ebpf资源，使得多个进程组中的每个进程组具有独立的ebpf资源，保证多个进程组共存时UDP报文的分发不会出现错乱，实现提高业务质量的目的。

第一方面，本申请实施例提供一种UDP报文的分发方法，包括：

接收来自终端设备的UDP报文；

根据所述UDP请求携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组是针对应用服务依次创建的多个进程组，所述多个进程组中的每个进程组具有独立的ebpf资源；

利用所述目标fd分发所述UDP报文。

第二方面，本申请实施例提供一种UDP报文的分发装置，包括：

收发模块，用于接收来自终端设备的UDP报文；

处理模块，用于根据所述UDP请求携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组是针对应用服务依次创建的多个进程组，所述多个进程组中的每个进程组具有独立的ebpf资源；

选择模块，用于从所述目标进程组的各进程的fd中选择出目标fd；

分发模块，用于利用所述目标fd分发所述UDP报文。

第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时使得所述电子设备实现如上第一方面或第一方面各种可能的实现方式所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令在被处理器执行时用于实现如上第一方面或第一方面各种可能的实现方式所述的方法。

第五方面，本申请实施例提供一种包含计算程序的计算机程序产品，所述计算机程序被处理器执行时实现如上第一方面或第一方面各种可能的实现方式所述的方法。

本申请实施例提供的UDP报文的分发方法、设备及可读存储介质，一个应用服务的多个进程组同时存在时，每个进程组具有独立的ebpf资源，ebpf资源用于保存进程组中每个进程的文件句柄fd的信息。服务器接收到UDP报文后，根据UDP报文的四元组从端口复用组的多个进程组中确定出目标进程组，从目标进程组的各进程的fd中选择出目标fd，并利用目标fd收发数据。采用该种方案，由于每个进程组具有独立的ebpf资源，不同进程组中的进程不会抢占同一个fd，确保多个进程组共存时UDP报文的分发不会出现错乱，实现保证业务质量的目的。而且，还能够避免UDP connect带来的软中断性能消耗问题，并发能力高。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的UDP报文分发方法的实施环境示意图；

图2是本申请实施例提供的UDP报文的分发方法的流程图；

图3A是本申请实施例提供的UDP报文分方法中UDP报文和进程组的关系一个示意图；

图3B是本申请实施例提供的UDP报文分方法中UDP报文和进程组的关系另一个示意图；

图4是本申请实施例提供的UDP报文分发方法中服务器内部新增模块的结构示意图；

图5为本申请实施例提供的一种UDP报文的分发装置的示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

目前，传输控制协议(Transmission Control Protocol，TCP)可靠性高但是速度较慢。UDP具有低延迟、抗弱网等性能，因此被广泛应用于音视频传输中，如直播场景等。UDP和TCP不同，UDP没有连接的概念，当Nginx服务器使用UDP时，Nginx服务器上的一个应用服务的多个进程使用同一个UDP端口进行数据收发。正常情况下，应用服务未发生热更新或升级(upgrade)时，一个应用服务具有一个进程组，该进程组包含多个进程，这个进程组中的每个进程使用自己的文件句柄(file handle，fd)收发UDP报文不会出现问题。但是，当应用服务热更新或升级时，同时会存在2个甚至多个进程组，每个进程组都会抢占fd，导致UDP报文的收发错乱。例如，一个UDP报文本应该发送给新进程组中的进程，但是被发送给了旧进程组中的进程；再如，一个UDP报文本应该发送给旧进程组中的进程，但是被发送给新进程组中的进程，导致整个应用服务不可用，影响业务质量。

直播场景中，假设主播端正在推流，推流数据本应该发送给旧进程组中的进程，出现上述错乱时，推流会被断开，导致直播中断。同理，观众拉流时，终端设备向Nginx服务器发送UDP报文请求拉流，该UDP报文本应该分发给新进程组中的进程，但是被分发给旧进程组中的进程，则观众无法观看直播。

若采用UDP connect方式解决上述的UDP报文分发错乱的问题，则会带来单核软中断性能消耗的问题。而且，UDP connect方案的并发能力较低，大概500左右。

基于此，本申请实施例提供一种UDP报文的分发方法、设备及可读存储介质，每次产生一个新的进程组，则为该新进程组分配ebpf资源，使得多个进程组中的每个进程组具有独立的ebpf资源，保证多个进程组共存时UDP报文的分发不会出现错乱，实现提高业务质量的目的。

图1是本申请实施例提供的UDP报文分发方法的实施环境示意图。请参照图1，该网络架构包括终端设备11和服务器12。

终端设备11可以是主播端的终端设备，也可以是观看端的终端设备，包括但不限于安装有安卓操作系统、微软操作系统、塞班操作系统、Linux操作系统或苹果iOS操作系统的手机、平板电脑、个人电脑、电子书阅读器、膝上型便携电脑、台式计算机等。

服务器12可以是硬件也可以是软件。当服务器12为硬件时，该服务器12为单个服务器或多个服务器组成的分布式服务器集群。当服务器12为软件时，可以为多个软件模块或单个软件模块等，本申请实施例并不限制。服务器12为基于Nginx的服务器，包括但不限于内容分发网络(Content Delivery Network，CDN)中的边缘节点等。

服务器12能够提供多种应用服务，该些应用服务可同时运行，一个应用服务对应一个UDP端口，一个UDP端口可以同时存在多个进程组，多个进程组组使用同一个UDP端口分发UDP报文，这个UDP端口即为端口复用(reuseport)组。Reuseport是套接字(socket)的一个特性，支持多个不同的fd使用同一个UDP端口进行UDP报文的分发。

本案目的在于解决：多个进程组同时存在、多个进程组使用同一个UDP端口分发UDP报文时，如何确保UDP报文的分发不会错乱。一个应用服务的多个进程组同时存在的原因是：对应用服务热更新或升级。另外，当一个进程组中的某个进程异常时，基于本案，也能够确保UDP报文的分发不会出现错乱。当多个进程组同时存在时，异常进程是多个进程组中最新创建的进程组中的进程；当应用服务只有一个进程组时，异常进程是该进程组中的进程。

服务器12利用ebpf进行UDP数据流的管理，ebpf特性在linux新内核上支持，通过在应用层编写一段业务逻辑代码植入内核运行，无需修改内核代码即可解决不同业务不同逻辑问题。真正做到可插拔，相较于修改内核代码具有周期快、安全性高的特点。

服务器12在模块初始化中初始化ebpf资源，并将ebpf资源加载入内核。同时考虑多端口的场景，即多个UDP端口，每个UDP端口都可以是reuseport组，每个UDP端口都有独立的ebpf资源，互不干扰。比如，UDP端口包括80端口和443端口，80端口有自己的ebpf资源，443端口有自己的ebpf资源。端口80可以有多个进程组，443端口也可以有多个进程组。

应当理解的是，图1中的终端设备11和服务器12的数量仅仅是示意性的。实际实现中，根据实际需求部署任意数量的终端设备11和服务器12。

下面，基于图1所示架构，对本申请实施例所述的UDP报文的分发方法进行详细说明。示例性的，请参照图2。

图2是本申请实施例提供的UDP报文的分发方法的流程图。本实施例是从服务器的角度进行说明，本实施例包括：

201、服务器接收来自终端设备的UDP报文。

终端设备可以是主播端或观众的播放端等，本申请实施例并不限制。当终端设备为主播端时，UDP报文携带推流数据，服务器接收到UDP报文后，找到目标fd，利用目标fd将UDP报文携带的推流数据传递给上层的worker进程。当终端设备为播放端时，UDP报文用于请求直播数据，服务器接收到UDP报文后，根据UDP报文确定出目标fd，利用目标fd向终端设备返回直播数据。

202、服务器根据所述UDP请求携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组是针对应用服务依次创建的多个进程组。

本申请实施例中，服务器能够提供多种应用服务，该些应用服务可并行运行。应用服务不可避免的需要热更新或升级等。其中，热更新也称为reload、配置更新、热重载、重载配置等，指动态加载配置、更新应用服务中的参数，但是不改变整个应用服务，未对应用服务进行版本升级。升级是指对应用服务进行版本升级，即用升级后的应用服务替换升级前的应用服务。

服务器启动后，针对一个应用服务创建主(master)进程，由主进程创建一组工作(worker)进程。Master进程负责管理worker进程的运行情况。这组worker进程即为步骤202中多个进程组中的一个进程组。当对应用服务进行热更新时，每reload一次，则产生一个新的进程组。为了确保旧进程上的数据不会中断，旧进程不会立即退出，而是在退出时间到达时才退出，这就使得多次reload后，同时存在多个进程组。一般来说不会连续多次reload。但是有时候运维人员着急修改配置等，则会多次reload，使得多个进程组同时存在。每次reload时，主进程不变，主进程创建一组worker进程。

为了避免同时存在多个进程组占用大量的资源，预先设置一个第一个数，该第一个数用于指示端口复用组的进程组的最大个数，可以是5、32等，本申请实施例并不限制。

需要说明的是，第一个数用来表示一个端口复用组中进程组的最大个数，并不代表reload的最多次数。例如，第一个数为5，表示一个端口复用组最多同时存在5个进程组。当5个进程组同时存在时，有可能reload了4次、5次或更多次。这是因为一旦同时存在的进程组的个数达到第一个数，则接下来reload时，服务器会清理掉最早创建的进程组以及相关记录，之后进行reload。

同理，每次升级时也会产生一个新的进程组。与reload不同的是，每次升级时，服务器创建新的master，由新的master进程创建一组worker进程从而得到一个新的进程组。

本申请实施例中，服务器维护一个动态数组，用reuseport array来表示。这个动态数组中的元素是每个进程组的ebpf资源，元素的个数和同时存在的进程组的个数相同，一个元素对应一个进程组。由此可见：每个进程组具有独立的ebpf资源，ebpf资源用来保持进程组中每个进程的fd。例如，同时存在两个进程组，每个进程组包含7个进程，则对于任意一个进程组，该进程组的ebpf资源中保存7个fd，不同fd对应不同的进程。

可选的，上述实施例中，所述ebpf资源用于保存对应进程组中每个进程的文件句柄fd的信息，所述多个进程组中进程组的个数大于或等于2。

示例性的，多次reload或upgrade之后，多个进程组共存，一个r进程组的ebpf资源中存放该进程组中各进程的fd以及一些其他的资源等。

本申请实施例中，服务器根据四元组区分客户端(发送UDP报文的终端设备)。假设reload之前，一个终端设备(终端设备1)的UDP报文被分发到旧的进程组中的进程。那么，reload之后，这个终端设备的UDP报文一定得分给旧的进程组。新的终端设备(终端设备2)发送UDP报文后，由于终端设备2的IP和终端设备1的IP等不一样，终端设备2的UDP报文分发给新的进程组。

服务器接收到UDP请求后，从UDP报文的报文头中提取出四元素，即源端口号、源IP地址、目的端口号和目的IP地址，根据四元组从多个进程组中确定目标进程组。由于每个进程组有独立的ebpf资源，即不同进程组的fd不同，因此不同进程组不会抢占同一个fd，不会造成UDP报文的错乱。也就是说，不会将原本分发给新进程组的UDP报文分发给旧进程组，不会将原本分发给旧进程组的UDP报文分发给新进程组中的进程。

例如，同时存在2个进程组，分别为应用服务reload前后创建的进程组，先创建的称之为旧进程组，后创建的称之为新进程组。旧进程组里有7个进程，每个进程有自己的fd，新进程中有7个fd，每个进程也由自己的fd，新进程的fd是新产生的fd，不是继承旧进程的fd。倘若采用现有的技术，由于新进程组是通过对旧进程组复制产生，新进程组中的进程继承旧进程组中的进程的fd，使得新旧两个进程组共14个进程但只有7个fd，哈希映射变化导致数据错乱。而本申请实施例中，新进程组和旧进程组共14个进程，但是有14个fd，不同进程组中的进程不会抢占同一个fd，因此不会发生数据错乱。

203、服务器从所述目标进程组的各进程的fd中选择出目标fd。

图3A是本申请实施例提供的UDP报文分方法中UDP报文和进程组的关系一个示意图。图3B是本申请实施例提供的UDP报文分方法中UDP报文和进程组的关系另一个示意图。

请参照图3A，当一个UDP报文的四元组和之前接收到的UDP报文的四元组相同时，则该UDP报文视为旧请求，目标进程组为旧进程组，旧请求被分发给旧的进程组，服务器从旧进程组的各进程的fd中确定目标fd。

请参照图3B，当一个UDP报文的四元组和之前接收到的UDP报文的四元组不相同时，则该UDP报文视为新请求，目标进程组为新进程组，新请求被分发给新的进程组，服务器从新进程组的各进程的fd中确定目标fd。

服务器基于负载均衡原则等从目标进程组包含的各进程的fd中选择出目标fd。例如，服务器从目标进程组包含的多个进程中确定出负载较小的进程，将该进程的fd作为目标fd。

204、服务器利用目标fd分发UDP报文。

当UDP报文是主播端的报文时，服务器利用目标fd向上层worker进程发送推流数据。当UDP报文为观众端的请求报文时，服务器获取视频数据等并利用目标fd响应给观众端。

本申请实施例提供的UDP报文分发方法，一个应用服务的多个进程组同时存在时，每个进程组具有独立的ebpf资源，ebpf资源用于保存进程组中每个进程的文件句柄fd的信息。服务器接收到UDP报文后，根据UDP报文的四元组从端口复用组的多个进程组中确定出目标进程组，从目标进程组的各进程的fd中选择出目标fd，并利用目标fd收发数据。采用该种方案，由于每个进程组具有独立的ebpf资源，不同进程组中的进程不会抢占同一个fd，确保多个进程组共存时UDP报文的分发不会出现错乱，实现保证业务质量的目的。而且，还能够避免UDP connect带来的软中断性能消耗问题，并发能力高。

可选的，上述实施例中，每次创建进程组时，服务器利用主进程创建第二进程组，所述第一进程组和所述第二进程组是所述多个进程组中先后创建的两个进程组，所述第一进程组对应第一组fd。之后，针对所述第二进程组生成第二组fd。最后，将所述第二组fd设置到资源集合中的待用资源中以得到第二进程组的ebpf资源，所述资源集合中存储预先创建好的待用资源，所述资源集合中待用资源的第一个数与所述端口复用组的进程组的最大个数相同，所述多个进程组中进程组的第二个数小于或等于所述第一个数。

示例性的，服务器上预先创建一个资源集合，该资源集合中存储预先创建好的待用资源，待用资源的个数为第一个数，该第一个数即为上述的端口复用组的进程组的最大个数。例如，预先设置一个端口复用组最多同时存在5个进程组，则第一个数＝5。当前同时存在的进程组的个数可以是2、3、4或5。当然，倘若没有发生reload或升级，则一个端口复用组中仅存在一个进程组。

服务器每次创建一个新的进程组时，保存当前最新的进程组的序号。例如，只有一个进程组时，该进程组的序号为序号1。第一次执行reload创建一个新的进程组后，新的进程组的序号为序号2，以此类推。进程组由服务器的应用层创建，由应用层负责ebpf资源的清理工作。一般而言，新进程组中进程的个数和旧进程组中进程的个数相同。但是，本申请实施例并不限制，旧进程组中进程的个数可以等于、少于或多于新进程组中进程的个数。

无论是reload还是upgrade，服务器每次创建一个新的进程组时，本次创建进程组之前，已经存在的进程组为第一进程组，本次创建的进程组为第二进程组。每次创建第二进程组时，服务器都是利用主进程创建出第二进程组，第一进程组和第二进程组是多个进程组中先后创建的两个进程组，第一进程组对应第一组fd。但是，第二进程组中的进程并不继承第一进程组中的进程的fd，而是针对第二进程组中的各个进程生成新的fd，即第二组fd。生成第二组fd后，服务器从资源集合中拿出一个待用资源，将第二组fd设置到该待用资源中，从而得到第二进程组的ebpf资源。之后，将第二进组的ebpf资源作为一个元素存储到动态数组(reuseport array)中。

采用该种方案，每次创建进程组时，服务器针对新创建的进程组生成一组fd，不继承旧进程组中进程的fd，避免服务器接收到UDP报文后，多个进程抢占同一个fd，确保UDP报文发送不会出现错乱。

下面，分别从reload和upgrade的角度，对每次创建新的进程组后，如何针对该新进程组生成一组新的fd进行详细描述。

首先，reload场景。

当对所述应用服务执行热更新以创建所述第二进程组时，服务器针对第二进程组生成第二组fd之前，过滤掉所述第一进程组的监听结构体中的fd，所述第一进程组和所述第二进程组均由第一主进程创建。

这种场景中，master进程没有变，因此第二进程组可以得到第一进程组的监听结构体。传统的基于Nginx的服务器，当对应用服务进行热更新时，第一进程组中的进程的fd会被关闭，第一进程组中各进程的fd会被第二进程组中的对应进程继承，导致第一进程组的fd和第二进程组的fd相同，这两组fd就无法设置到动态数组(reuseport array)中。本案中，为了确保第一进程组的第一组fd和第二进程组的第二组fd不同，当第一进程组中的监听结构体(listening结构体)中的bpf标志当前是ebpf方式的监听结构时，该监听结构体的fd不被继承，而是被过滤掉，不传递给第二进程组，而且，不关闭第一进程组中进程的fd。

采用该种方案，针对reload场景，过滤掉第一进程组的监听结构体中的fd，使得第二进程组中的进程不继承第一进程组的fd，而是针对第二进程组生成一组新的fd，即第二组fd，确保第一进程组的第一组fd和第二组fd不同，进而避免热更新时多个进程抢占同一个fd，确保热更新场景中UDP报文的分发不会错乱。

其次，升级场景。

当对所述应用服务执行升级以创建所述第二进程组时，利用第一主进程向第二主进程传递环境变量，所述第一主进程是所述应用服务升级之前的主进程，所述第二主进程是所述应用服务升级之后的主进程。之后，当所述环境变量中存在携带预设标识的fd时，服务器关闭所述携带预设标识的fd。其中预设标识用于指示该fd是ebpf的fd。

这种场景中，master进程发生变化：升级之前为第一主进程，升级之后为新创建的第二主进程，整个进程空间都变了，替换为新的可执行程序，使得第二进程组无法得到第一进程组的监听结构体。新创建的第二进程组通过fork函数和execv函数产生。第一进程组中各进程的fd没有关闭。传统的基于Nginx的服务器，针对upgrade场景，服务器将第一进程组的旧的监听结构体的所有fd通过环境变量传递给新的主进程，即第二主进程。第二主进程通过环境变量得到这些fd后，设置到第二进程组的监听结构体中继续使用。

本案与传统方案的不同之处在于：本案中，利用环境变量传递fd时区分普通fd和ebpf的fd，对于ebpf的fd，对该fd添加预设标识，预设标识例如为b等本申请实施例并不限制。例如，利用环境变量传递的fd包括12、13、b14和15，b14表示该fd是ebpf的fd，值为14。第二主进程解析出携带预设标识的fd后，关闭该fd，使得第二进程组不再继承该fd，服务器为第二进程组产生一组新的ebpf的fd，将这组fd设置到一个待用资源中得到第二进程组的ebpf资源。

采用该种方案，针对upgrade的场景，由于主进程发生变化，通过环境变量传递并区分fd，关闭携带预设标识的fd使得第二进程组不继承该fd，而是针对第二进程组生成一组新的fd，即第二组fd，确保第一进程组的第一组fd和第二组fd不同，进而避免升级时多个进程抢占同一个fd，确保升级场景中UDP报文的分发不会错乱。

升级时，很有可能存在升级失败的场景。这种情况下，服务器利用第一主进程创建第三进程组，关闭所述第三进程组的监听结构体中的fd。之后，服务器针对所述第三进程组生成第三组fd，并根据所述第三组fd创建所述第三进程组对应的ebpf资源。

示例性的，如果升级失败，旧的主进程，即第一主进程再次启动一组worker进程，这组work进程即为第三进程组。例如，一个应用服务有一个第一进程组，如果升级成功，则新的主进程，即第二主进程创建第二进程组。但是，升级失败，第一主进程会创建一个第三进程组。倘若采用现有的方案，由于第一主进程并未修改第一进程组的监听结构体，所以第三进程组的fd和第一进程组的fd相同，就会出现问题。而且，第一进程组在到达退出时间时会退出。本申请实施例中，会给第三进程组重新产生一组fd，即第三组fd，将该第三组fd设置到一个待用资源中从而得到第三进程组的ebpf资源。也就是说，第一主进程创建第三进程组时，根据第一进程组得到一组新的fd，即第三组fd，将第三组fd通过ebpf接口加入到动态数组(reuseport array)中。后续新的UDP报文就分发给第三进程组中的fd，接着启动第三进程组，第三进程组中的工作进程使用新的fd服务。

采用该种方案，升级失败时旧的master进程重启一个进程组，针对该新的进程组生成fd以使得该新的进程组具有独立的ebpf资源，确保升级失败时不会发生UDP报文分发错乱的现象，实现提高业务质量的目的。

上述实施例中，着重描述了reload和upgrade时，同时存在至少两个进程组时如何确保UDP报文的分发不会错乱。还有一种场景：多个进程组中最新创建的进程组中存在异常进程，这种场景同样会导致UDP报文的收发出现错乱。下面，对如何解决异常进程带来的数据错乱进行详细说明。

服务器确定出多个进程组中最新创建的进程组中存在异常进程后，针对该最新创建的进程组创建一个新的worker进程，该worker进程的fd即为异常进程的fd。

示例性的，无论是reload还是upgrade的，最新创建的进程组中的某个进程可能会因为bug存在的原因出现异常，该进程即为异常进程或挂掉的进程。例如，最新创建的进程组中包含7个进程，当7个进程中的一个进程时，剩下6个进程，倘若采用现有技术，则服务器维护的哈希表错乱导致UDP报文分发错乱。本案中，当最新创建的进程组中出现异常进程时，主进程(reload场景下，主进程为第一主进程，upgrade场景下，主进程为第二主进程)重启一个worker进程，并worker进程继续沿用异常进程的fd。这样一来，主进程根据最新创建的进程组中的每个进程的序号关联fd，使得重新创建的worker进程可以接收UDP报文。

当旧进程组中出现异常进程时，由于已经创建新的进程组，旧进程组会在退出时间到达时退出。因此，服务器无需处理。旧进程组为多个进程组中除了最新创建的进程组外的其他进程组。例如，同时存在5个进程组，第5个进程组是最新创建的进程组，其他4个进程组是旧进程组。

另外，倘若未执行reload或upgrade，则只有一个进程组，同样存在出现异常进程的现象，处理方式同样，即master创建一个新的worker进程，该worker进程沿用异常进程的fd。

采用该种方案，当进程组中出现异常进程时，master进程重新创建一个worker进程并沿用异常进程的fd，确保出现异常进程时UDP报文的分发不会错乱，实现提高业务质量的目的。

可选的，上述实施例中，服务器维护一个动态数组(reuseport array)。每次创建进程组后，服务器将本次创建的进程组的ebpf资源作为一个元素存储在动态数组中。当动态数组中元素的个数大于或等于第一个数时，服务器按照所述多个进程组中进程组的创建顺序清理最先创建的进程组的元素后，将本次创建的进程组的ebpf资源存储在所述动态数组中。

示例性的，对于reload场景，每reload一次就会产生一个新的进程组，由于主进程并没有变，因此不会调用exit_master接口进行资源清理。其中，exit_master接口是服务器注册的一个用于完成资源回收工作的接口。

服务器预先定义第一个数，即同时最多存在的进程组的个数。每次创建进程组后，服务器将该进程组的ebpf资源作为一个元素存储在动态数组中。当动态数组中元素的个数首次达到第一个数时，表示预先创建的资源集合中的待用资源已经使用完。后续再次创建进程组时需要将最先创建的进程组对应的ebpf资源从动态数组中清理掉从而释放该ebpf资源，这样一来，创建新的进程组后，该新的进程组就有ebpf资源可用。

采用该种方案，针对reload场景，循环利用ebpf资源，确保应用服务能够多次reload，通过及时对应用服务进行热更新，实现提高业务质量的目的。

针对upgrade的场景，每次创建新的进程组后，master进程发生变化，新的master进程调用exit_master接口进行资源清理，通过及时清理资源，确保应用服务能多次upgrade，通过及时对应用服务进行升级，实现提高业务质量的目的。

上述实施例中，均是对服务器上的一个端口复用组同时存在至少两个进程组时，如何确保UDP报文的分发不会错乱。然而，一个服务器上具有多个UDP端口，每个UDP端口都可以作为端口复用组。对于每个端口复用组，服务器都采用本申请实施例所述的UDP报文分发方法进行UDP报文的分发，因此不会出现数据错乱的问题。

另外，基于UDP实现的流媒体协议包括SRT、QUIC等，可以为一个协议配置多个UDP端口，不同协议具有不同的UDP端口。每个UDP端口对应一个ebpf资源，如果有多个UDP端口则需要加载多分ebpf资源到内核。同时，每个端口的ebpf资源存储在不同的路径。

而且，不同端口是通过端口复用组来区分的，而端口复用组是以IP+端口(port)，因此，同一个端口可以绑定至少两种IP协议时，所述端口复用组同时服务于所述至少两种IP协议。

例如，UDP端口为10080端口，该UDP端口同时绑定IPv4和IPV6，则该UDP端口可以视为两个复用端口，一个服务于IPV4，一个服务于IPV6。

采用该种方案，通过支持多端口，基于一个UDP端口可以创建多个端口复用组，灵活度高。

本申请实施例提供的UDP报文分发方法具有通用性，可同时适用于SRT、QUIC、WEBRTC等流媒体协议，能够解决多个进程组使用同一个UDP端口分发UDP报文导致的数据错乱的问题。下面，以SRT为例，对本申请实施例所述的UDP报文发送方法进行详细说明。示例性的，请参照图4，图4是本申请实施例提供的UDP报文分发方法中服务器内部新增模块的结构示意图。

请参照图4，服务器用于SRT时，相较于传统的服务器，该服务器上除了SRT模块(ngx_srt_moudle)外，新增ebpf模块(ngx_core_bpf_moudle)，用于完成ebpf相关处理。ebpf模块注册两个接口，一个是初始化接口(ngx_core_bpf_int_moudle)，一个是资源回收接口(ngx_core_bpf_exit_moudle_)。初始化接口用于完成ebpf资源的初始化以及加载工作，资源回收接口用于完成资源回收工作。由于本案主要是解决多个进程组使用同一个端口复用组导致的UDP报文分发错乱的问题，在master-worker模式下，所有的ebpf操作必须有master进程完成。

本案中，一个reuseport组会有一个监听结构体，监听结构体具有套接字地址(sockaddr)，若两个监听结构体的sockaddr相同，则这两个监听结构体对应一个reuseport组，若两个监听结构体的sockaddr不相同，则这两个监听结构体对应不同的reuseport组。一个UDP端口可能会存在一个、两个或更多的reuseport组。服务器在一个reuseport组的监听结构体中新增预设标识，表示该reuseport组采用本申请实施例的方案进行UDP报文的分发。

本申请实施例中，为了使得服务器实施上述的UDP报文分发方法，主要修改包括以下五点：

一、模块初始化工作。

服务器在初始化接口中做初始化操作，而ebpf对服务器的内核版本有要求，倘若服务器的内核版本太低，则不支持本案的UDP报文分发方法。因此，服务器需要先判断内核版本，例如采用uname系统调用方式判断内核是否支持，如果内核不支持，则采用传统的基于UDP connect方式。若内核支持，则采用本申请实施例所述的UDP报文分发方法。

倘若内核版本支持，服务器通过四元组从多个进程组中选择目标进程组，一个应用服务可同时存在多个进程组，一个进程组的各进程的fd为一组fd，视为一份ebpf资源。当一个UDP报文的四元组为新的四元组时，该UDP报文为新请求，新请求从新的进程组里获取目标fd；当一个UDP报文的四元组为旧的四元组时，该UDP报文为旧请求，从旧的进程组里获取目标fd。服务器每次创建一个新的进程组后，需要保存当前最新的进程组的序号。比如，当前有一个进程组组，则序号为1，执行一次reload产生一个新的进程组，新的进程组的讯号为2，以此类推。

新的进程组由应用层创建，由应用层负责清理工作。ebpf程序在内核工作，在模块初始化函数中设置好ebpf相关资源，比如动态数组(reuseport array)，然后将ebpf程序加载到内核。

Reload场景中，master进程没有变，还是当前的master进程，reload时无需再次加载ebpf程序。因此，需要将ebpf的fd保存起来，多次reload时只需要加载之前的fd即可。保存方式采用文件系统关联的方式，使用bpf_obj_pin和bpf_pin_get方式。例如，将ebpf程序的句柄映射到文件系统的路径为：/sys/fs/bpf/udp_reuseport/udp_reuseport_prog，不同reuseport组的保存路径不同。

二、核心代码修改。

本案中，服务器是基于Nginx的服务器，Nginx是一个开源组件，需要对开源组件进行一些修改。

因为UDP没有连接的概念，当多进程时，每个进程具有fd，一个进程一个fd服务多个客户端。当执行reload或upgrade时，一个应用服务会同时存在多个进程组，旧进程组的fd继续服务旧请求，新请求由新进程组里的fd服务。传统的基于Nginx的服务器，当对应用服务执行reload或upgrade时，旧进程组中各个旧进程的fd会被关闭。本案中，通过修改Nginx组件，使得当对应用服务执行reload或upgrade时，旧进程组中各进程的fd不关闭。例如，上述的预设标识为1，则表示服务器的内核版本支持ebpf，这时候，每次创建新的进程组后，不关闭旧进程组中各进程的fd。

传统的基于Nginx的服务器，当对应用服务执行reload或upgrade时，旧进程组的监听结构体的fd都会通过继承的方式传递给新进程组的监听结构体，导致两个进程组的fd相同，无法设置到动态数组(reuseport array)中。为此，本申请实施例中，当内核版本支持ebpf，服务器采用本申请的UDP报文分发方法时，每次创建新的进程组后，不继承旧进程组中的fd，而是过滤掉旧进程组的监听结构体中的fd。具体做法是在旧循环(old cycle)里面将携带预设标识的fd，不传递给新的循环(cycle)。监听结构体用来存放监听信息，由master进程创建，每个worker进程都有监听结构体，监听结构体里存放的监听信息例如为fd等。本案中，每次产生一个新的进程组，新进程组里的进程并不继承旧进程组里的进程的fd。

执行升级(upgrade)时，不同于reload。因为reload时主进程并没有变，所以可以得到旧进程的监听结构体。但是，执行upgrade时，主进程变了，新的主进程通过fork+execv方式产生，新的主进程会继承旧的主进程的所有监听的fd。新的主进程创建新的进程组时，关闭继承的fd，并针对新的进程组生成新的fd。传统方案中，服务器将旧进程组的监听结构体的所有fd通过环境变量传递给新的master，在新的master进程通过环境变量得到fd后，给新的进程组使用。这就使得两个进程组中的不同进程使用同一个fd。本案中，对fd的传递和设置进行修改。传递过程中，为了区分普通fd和ebpf的fd，在ebpf的fd前面加一个预设标识，预设标识例如为b等，本申请实施例并不限制。例如，传递的fd包括12、13、b14和15，其中，b14表示ebpf的fd，值为14。新的master进程解析到ebpf的fd后，关闭该fd，新的进程组不继承该fd，新的master进程针对新的进程组产生一组新的fd，之后将该组新的fd加入到动态数组(reuseport array)中。

倘若升级失败，旧的master进程再次启动一组worker进程，即第三进程组。这种场景下因为旧的master进程并没有修改第一进程组的fd，所以第三进程组的fd还是第一进程组的fd，这两个进程组的fd相同，无法将第三进程组的fd设置到动态数组中。为此，本案中，将第三进程组中的fd关闭，针对第三进程组重新生成一组fd，即第三组fd，将第三组fd设置到动态数组中，后续新的请求就在第三组fd中获取目标fd，接着启动第三进程组中的worker进程，这些新启动的worker进程就可以使用新的fd服务了。

本案中，由于一个reuseport组存在多个进程组，每个进程组中的每个进程有自己的fd处理UDP报文，所以在底层由内核使用ebpf方式确保UDP报文到达对应的进程即可。然后在进程内部通过四元组区分每个客户端的UDP报文。由进程决定一个UDP报文是去新进程还是旧进程，UDP报文到达进程后，应用层根据维护的客户端的信息，区分不同的连接。

三、异常场景解决。

本申请实施例中，异常场景包括：reload、upgrade和进程异常。

针对reload场景，应用服务的版本不会变化，但是会更新参数等。主进程不会退出，会重新加载配置。每次创建新的进程组时，主进程根据第一进程组创建出第二进程组，针对第二进程组产生一组新的fd，使得第一进程组和第二进程组的fd不同，每个进程组通过自己的fd接收UDP报文，保证UDP报文的分发不会错乱。

针对upgrade场景，应用服务升级，新版本的应用程序替换旧版本的应用程序。新的主进程加载新版本的可执行程序，然后新的主进程创建新的一组fd以及新的进程组。由于传统的Nginx会设置fd的继承，使得旧的进程组的fd会被继承到新的进程组，这对于TCP是没有问题的。但是针对UDP，因为使用了ebpf，需要为每个进程组分别设置一组f才能保证这些进程组同时服务，不然，若两个或多个进程组的fd相同，则会发生UDP报文分发错乱。因此，本申请实施例中，新的进程组不继承旧的进程组的fd，而是对新的进程组创建一组新的fd，将新创建的fd加载到内核，后续每个进程组通过自己的fd分发UDP报文。

针对进程异常(coredump)场景，统一在master进程分配各个worker进程的fd，然后通过内核接口加载进入和ebpf关联。此时内核维护一组fd，这些fd内部通过reuseport监听同一个端口，确保数据不会错乱。当某个worker进程挂掉时，master进程会重新拉起一个新的worker进程，fd仍然是挂掉的进程，即异常进程的fd。主进程会根据每个worker进程的序号关联之前的fd，所以重新拉起的进程仍然可以接收UDP报文。

四、多端口问题。

本申请实施例中，一个流媒体协议可以配置多个端口，不同协议配置不同端口，协议包括SRT、QUIC等。这样一来，服务器上就会存在多个reuseport组，不同reuseport组对应不同的ebpf资源，不同的reuseport对应不同的UDP端口或者同一个UDP端口。例如，端口123为支持SRT的端口，端口123是一个reuseport组，端口111为支持QUIC的端口，端口111是一个reuseport组。再如，端口10080同时绑定IPv4和IPv6，则端口10080对应两个reuseport组，端口10080同时服务于IPv4和IPv6。当存在多个reuseport组时，多个reuseport组中每个reuseport组有自己的ebpf资源，而每个reuseport组具有多个进程组，每个进程组也有独立的ebpf资源。

当存在多个reuseport组时，需要将每个reuseport组的ebpf资源加载到内核。同时，设置ebpf资源和文件系统关联时需要做区分，可通过命名方式区分：

/sys/fs/bpf/udp_reuseport_10080/udp_reuseport_prog表示10080端口；

/sys/fs/bpf/udp_reuseport_10081/udp_reuseport_prog表示10081端口。

本案中，不同的UDP端口通过reuseport组来区分，而reuseport组通过IP+Port区分。当一个UDP端口绑定两种或以上IP协议时，一个UDP端口可创建两个及以上的reuseport组。比如，上述的端口10080绑定IPv4和IPv6时，会创建两个reuseport组，每组都会走ebpf流程。

服务器遍历监听结构体，判断各监听结构体中的sockaddr，如果sockaddr相同，则认为该两个监听结构体对应的端口为同一个reuseport组，一起加载到ebpf中。每个reuseport组有多个进程组，每个进程组有多个进程，每个进程有自己的fd。

五、资源回收问题。

请参照图4，ebpf模块注册了两个接口，分别为初始化接口和资源回收接口，资源回收接口负载ebpf资源的清理操作。Upgrade场景中，主进程会发生变化，每次创建新的进程组后，ebpf模块调用资源回收接口进行资源回收。

Reload场景中，每reload一次就会产生一组ebpf资源，用于保存新进程组中各进程的fd的信息，这组fd后续会被设置到待用资源中从而产生新进程组的ebpf资源。但是，由于主进程没有变，因此不会调用资源回收接口进行清理，导致每reload一次资源就会泄露一次。为了清理这组资源，传统方案是所有的worker进程退出后才可以清理，倘若在worker进程没有退出时就清理则会导致worker进程无法服务。但是现有方案中，没有机制得到一个进程组内所有worker进程退出的时机。因为服务器支持多次reload，每次reload的时候之前的旧的进程组可能并没结束，每个worker进程的退出时机不同，所以没法得知哪些worker进程是一组的。

本案中，动态数组中的元素不能超过第一个数，第一个数例如是5个，本申请实施例并不限制。一旦元素的个数超过第一个数则需要清理，从而保证同时存在的元素的个数小于或等于第一个数，即同时存在的进程组的个数小于或等于第一个数。例如，第一个数为5，表示最多可以同时存在5个进程组，序号分别为0、1、2、3、4。每次针对新的进程组创建一组fd，得到一个ebpf资源后，将该ebpf资源作为一个元素存入动态数组的一个位置。存入之前判断该位置是否为空，如果不为空则先清理该位置原来保持的元素，然后将本次创建的元素保存到该位置。动态数组中有5个位置，分别为位置0～位置4。当位置0～位置4都保存了元素后，再次reload创建的元素会放到位置0，由于位置0不为空，则会对位置0对应的ebpf资源进程清理操作，比如释放内存等操作，关闭ebpf资源的fd。然后，将新创建的元素存入位置0。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请实施例提供的一种UDP报文的分发装置的示意图。该UDP报文的分发装置500包括：收发模块51、处理模块52、选择模块53和分发模块54。

收发模块51，用于接收来自终端设备的UDP报文；

处理模块52，用于根据所述UDP请求携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组是针对应用服务依次创建的多个进程组，所述多个进程组中的每个进程组具有独立的ebpf资源；

选择模块53，用于从所述目标进程组的各进程的fd中选择出目标fd；

分发模块54，用于利用所述目标fd分发所述UDP报文。

一种可行的实现方式中，所述处理模块52根据所述UDP请求携带的四元组从端口复用组的多个进程组中确定目标进程组之前，还用于每次创建进程组时，利用主进程创建第二进程组，所述第一进程组和所述第二进程组是所述多个进程组中先后创建的两个进程组，所述第一进程组对应第一组fd；针对所述第二进程组生成第二组fd；将所述第二组fd设置到资源集合中的待用资源中以得到所述ebpf资源，所述资源集合中存储预先创建好的待用资源，所述资源集合中待用资源的第一个数与所述端口复用组的进程组的最大个数相同，所述多个进程组中进程组的第二个数小于或等于所述第一个数。

一种可行的实现方式中，所述处理模块52针对所述第二进程组生成第二组fd之前，还用于当对所述应用服务执行热更新以创建所述第二进程组时，过滤掉所述第一进程组的监听结构体中的fd，所述第一进程组和所述第二进程组均由第一主进程创建。

一种可行的实现方式中，所述处理模块52，还用于每次创建进程组后，将本次创建的进程组的ebpf资源作为一个元素存储在动态数组中；当动态数组中元素的个数大于或等于第一个数时，按照所述多个进程组中进程组的创建顺序清理最先创建的进程组的元素后，将本次创建的进程组的ebpf资源存储在所述动态数组中。

一种可行的实现方式中，所述处理模块52针对所述第二进程组生成第二组fd之前，还用于当对所述应用服务执行升级以创建所述第二进程组时，利用第一主进程向第二主进程传递环境变量，所述第一主进程是所述应用服务升级之前的主进程，所述第二主进程是所述应用服务升级之后的主进程；当所述环境变量中存在携带预设标识的fd时，关闭所述携带预设标识的fd。

一种可行的实现方式中，所述处理模块52，还用于每次创建进程组后，调用资源回收接口清理所述第一进程组的ebpf资源。

一种可行的实现方式中，所述处理模块52，还用于当所述应用服务升级失败时，利用所述第一主进程创建第三进程组；关闭所述第三进程组的监听结构体中的fd；针对所述第三进程组生成第三组fd；根据所述第三组fd创建所述第三进程组对应的ebpf资源。

一种可行的实现方式中，所述处理模块52，还用于确定所述多个进程组中最新创建的进程组中存在异常进程；针对所述最新创建的进程组创建新的worker进程，所述worker进程的文件句柄为所述异常进程的fd。

一种可行的实现方式中，当所述端口复用组对应的UDP端口绑定至少两种IP协议时，所述UDP端口同时服务于所述至少两种IP协议。

一种可行的实现方式中，所述ebpf资源用于保存对应进程组中每个进程的文件句柄fd的信息，所述多个进程组中进程组的个数大于或等于2。

本申请实施例提供的UDP报文的分发装置，可以执行上述实施例中服务器的动作，其实现原理和技术效果类似，在此不再赘述。

图6为本申请实施例提供的一种电子设备的结构示意图。如图6所示，该电子设备600例如为上述的调控中心或抗攻击节点，该电子设备600包括：

处理器61和存储器62；

所述存储器62存储计算机指令；

所述处理器61执行所述存储器62存储的计算机指令，使得所述处理器61执行如上服务器实施的UDP报文的分发方法。

处理器61的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，该电子设备600还包括通信部件63。其中，处理器61、存储器62以及通信部件63可以通过总线64连接。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上服务器实施的UDP报文的分发方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包含计算机程序，计算机程序被处理器执行时实现如上服务器实施的UDP报文的分发方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (12)

1.一种UDP报文的分发方法，其特征在于，包括：

接收来自终端设备的UDP报文；

根据所述UDP报文携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组是针对应用服务依次创建的多个进程组，所述多个进程组中的每个进程组具有独立的ebpf资源，所述ebpf资源用于保存对应进程组中每个进程的文件句柄fd的信息；

从所述目标进程组的各进程的fd中选择出目标fd；

利用所述目标fd分发所述UDP报文。

2.根据权利要求1所述的方法，其特征在于，所述根据所述UDP报文携带的四元组从端口复用组的多个进程组中确定目标进程组之前，还包括：

每次创建进程组时，利用主进程创建第二进程组，第一进程组和所述第二进程组是所述多个进程组中先后创建的两个进程组，所述第一进程组对应第一组fd；

针对所述第二进程组生成第二组fd；

将所述第二组fd设置到资源集合中的待用资源中以得到所述ebpf资源，所述资源集合中存储预先创建好的待用资源，所述资源集合中待用资源的第一个数与所述端口复用组的进程组的最大个数相同，所述多个进程组中进程组的第二个数小于或等于所述第一个数。

3.根据权利要求2所述的方法，其特征在于，所述针对所述第二进程组生成第二组fd之前，还包括：

当对所述应用服务执行热更新以创建所述第二进程组时，过滤掉所述第一进程组的监听结构体中的fd，所述第一进程组和所述第二进程组均由第一主进程创建。

4.根据权利要求3所述的方法，其特征在于，还包括：

每次创建进程组后，将本次创建的进程组的ebpf资源作为一个元素存储在动态数组中；

当动态数组中元素的个数大于或等于第一个数时，按照所述多个进程组中进程组的创建顺序清理最先创建的进程组的元素后，将本次创建的进程组的ebpf资源存储在所述动态数组中。

5.根据权利要求2所述的方法，其特征在于，所述针对所述第二进程组生成第二组fd之前，还包括：

当对所述应用服务执行升级以创建所述第二进程组时，利用第一主进程向第二主进程传递环境变量，所述第一主进程是所述应用服务升级之前的主进程，所述第二主进程是所述应用服务升级之后的主进程；

当所述环境变量中存在携带预设标识的fd时，关闭所述携带预设标识的fd。

6.根据权利要求5所述的方法，其特征在于，还包括：

每次创建进程组后，调用资源回收接口清理所述第一进程组的ebpf资源。

7.根据权利要求5所述的方法，其特征在于，还包括：

当所述应用服务升级失败时，利用所述第一主进程创建第三进程组；

关闭所述第三进程组的监听结构体中的fd；

针对所述第三进程组生成第三组fd；

根据所述第三组fd创建所述第三进程组对应的ebpf资源。

8.根据权利要求1-7任一项所述的方法，其特征在于，还包括：

确定所述多个进程组中最新创建的进程组中存在异常进程；

针对所述最新创建的进程组创建新的worker进程，所述worker进程的文件句柄为所述异常进程的fd。

9.根据权利要求1-7任一项所述的方法，其特征在于，

当所述端口复用组对应的UDP端口绑定至少两种IP协议时，所述UDP端口同时服务于所述至少两种IP协议。

10.根据权利要求1-7任一项所述的方法，其特征在于，

所述多个进程组中进程组的个数大于或等于2。

11.一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时使得所述电子设备实现如权利要求1至10任一所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至10任一所述的方法。