一种提升嵌入式平台Socket服务端稳定性和并发处理能力的方法

摘要

本发明公开了一种基于嵌入式平台服务端的并发处理方法，包括，调用Linux系统APIsocket创建套接字、APIbind绑定服务端口号、APIaccept接收请求、APIfork创建子进程处理所述请求；在fork中的子进程中运行重定向处理程序，同时运行若干个fork子进程，实现并发处理；所述fork中的子进程运行完成定向处理程序后，释放子进程，完成一次完整的请求处理流程。本发明预置子服务进程，避免程序运行状态下频繁的内存拷贝、进程申请、释放等操作；代码逻辑简单，不存在线程管理、事件调用等额外的代码，能够兼容原始服务，扩展的子服务和原始服务并存，并且相互独立，即使扩展服务故障，原始服务还能正常运行。

说明书

技术领域

本发明涉及后端服务并发处理的技术领域，尤其涉及一种基于嵌入式平台服务端的并发处理方法。

背景技术

目前，常用的软件架构有CS架构和BS架构，两者都是通过socket套接字实现，一般服务端都需要同时支持若干个C端或者B端访问请求，所以要求服务端具备并发处理能力；常用的服务端并发实现方案如下：子进程、子线程、池化(子进程池或者线程池)、异步事件处理。

上述几个方案的缺点：

子进程会拷贝父进程内存，频繁拷贝会导致CPU使用率提升，进程的申请释放也会占用资源，嵌入式平台CPU资源相对比较紧张，该方案会导致CPU使用率居高不下，影响正常业务。

多线程同享父进程的内存空间，和子进程相比降低了CPU的使用率，但限制了使用场景(需要内存隔离的使用场景)，一个线程出错往往会导致其它线程都出错，另外线程频繁申请释放还是会占用额外的资源。

池化技术主要解决线程频繁申请、释放的问题，弊端是增加了代码的复杂度，可靠性不高，线程频繁切换也可能会导致线程抖动，且线程过多会造成服务器不稳定。

异步事件处理效率高，但事件之间调度比较复杂，适合从零开始的项目，另外异步事件处理一般只适用于非阻塞性处理中，对于耗时较长的还是需要多进程或者多线程。

发明内容

本部分的目的在于概述本发明的实施例的一些方面以及简要介绍一些较佳实施例。在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊，而这种简化或省略不能用于限制本发明的范围。

鉴于上述现有存在的问题，提出了本发明。

为解决上述技术问题，本发明提供如下技术方案：包括，调用Linux系统 APIsocket创建套接字、API bind绑定服务端口号、API accept接收请求、API fork创建子进程处理所述请求；在fork中的子进程中运行重定向处理程序，同时运行若干个fork子进程，实现并发处理；所述fork中的子进程运行完成定向处理程序后，释放子进程，完成一次完整的请求处理流程。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：还包括，

循环迭代，API accept接收请求、API fork创建子进程处理所述请求；

持续不断的接收来自客户端的请求；

当所述客户端请求间隔时间小于业务处理所需的时间时，就会存在多个 fork子进程，此时所述客户端处于并发处理状态。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：增加一个虚拟网卡驱动程序，虚拟网卡ed0；

在程序启动时预置若干子进程，每个子进程都对应一个侦听端口，网卡为 ed0，原始服务还绑定3990端口，网卡为eth1。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：设置端口映射功能模块，利用Netfliter的HooK机制捕获所述客户端访问请求报文；

结合扩展服务端口替换原始的所述3990端口号，根据TCP/UDP的协议要求修改端口后，计算TCP或者UDP的头部校验值；

将skb->dev的值由eth1替换成ed0接口，所述skb重新提交到系统协议栈中，绑定ed0的预置子服务进程接收到所述请求。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：预置服务进程，从ed0上收到所述客户端的请求报文，业务子程序按照业务处理逻辑响应请求，并将其产生的响应报文通过ed0发送出去；

所述端口映射模块捕获到发送给所述客户端的响应报文后，将报文中扩展的端口号还原成3990，调用eth1的发送接口将报文发送给所述客户端。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：所述端口映射模块为内核模块，通过代码编译后得到一个.ko的内核驱动，利用insmod加载所述ko模块。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：所述ko模块启动后，利用Linux系统的Netfilter的HOOK机制捕获到客户端访问WebPortal服务的报文，服务端口号是3990，端口映射根据客户端MAC地址得到。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：定义捕获到的客户端请求报文目的端口号是3990，选取客户端MAC 地址的最后一个字节与扩展端口数做取余计算，将计算结果加3990得出要替换的端口，其确定将请求送给哪个预置服务进程处理。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：若扩展32个服务端口，当前捕获的客户端MAC地址是 48-51-C5-70-9B-49，则请求替换的服务端口号为3999，所述客户端请求会被绑定3999的预置子服务处理，计算公式如下：

0x49％32+3990＝3999。

作为本发明所述的基于嵌入式平台服务端的并发处理方法的一种优选方案，其中：所述Skb在Linux内核代码中代表一个数据包，skb->dev表示所述数据包来自哪个网卡,不替换则应用程序就无法接收到数据包。

本发明的有益效果：一、预置子服务进程，避免程序运行状态下频繁的内存拷贝、进程申请、释放等操作；二、代码逻辑简单，不存在线程管理、事件调用等额外的代码；三、能够兼容原始服务，扩展的子服务和原始服务都是并存的，并且相互独立，即使扩展服务故障，原始服务还能正常运行。

附图说明

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

图1为本发明第一个实施例所述的基于嵌入式平台服务端的并发处理方法的流程示意图；

图2为本发明第一个实施例所述的基于嵌入式平台服务端的并发处理方法的WebPortal业务处理流程示意图；

图3为本发明第一个实施例所述的基于嵌入式平台服务端的并发处理方法的调用子进程流程示意图；

图4为本发明第二个实施例所述的基于嵌入式平台服务端的并发处理方法的预置服务处理示意图；

图5为本发明第二个实施例所述的基于嵌入式平台服务端的并发处理方法的测试架构示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合说明书附图对本发明的具体实施方式做详细的说明，显然所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明的保护的范围。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。

其次，此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。

本发明结合示意图进行详细描述，在详述本发明实施例时，为便于说明，表示器件结构的剖面图会不依一般比例作局部放大，而且所述示意图只是示例，其在此不应限制本发明保护的范围。此外，在实际制作中应包含长度、宽度及深度的三维空间尺寸。

同时在本发明的描述中，需要说明的是，术语中的“上、下、内和外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一、第二或第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

本发明中除非另有明确的规定和限定，术语“安装、相连、连接”应做广义理解，例如：可以是固定连接、可拆卸连接或一体式连接；同样可以是机械连接、电连接或直接连接，也可以通过中间媒介间接相连，也可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

实施例1

参照图1、图2和图3，为本发明的第一个实施例，提供了一种基于嵌入式平台服务端的并发处理方法，具体包括：

S1：调用Linux系统API socket创建套接字。

S2：调用Linux系统API bind绑定服务端口号。

S3：调用Linux系统API accept接收请求。

S4：调用Linux系统API fork创建子进程处理该请求。

S5：在fork中的子进程中运行重定向处理程序，可以同时运行若干个fork 子进程，达到并发处理的目的。

S6：Fork中的子进程运行完重定向处理程序后，释放子进程，完成一次完整的请求处理流程。

S3至S6处于一个循环中，持续不断的接收来自客户端的请求，并把请求交给S4处理，当客户端请求间隔时间小于业务处理所需的时间时，就会存在多个fork子进程，此时客户端处于并发处理状态。

调用代码示意如下：

参照图1，每个Accept请求都对应一个业务处理进程，从而达到并发处理的目的。

参照图2，本实施例还提供一种Web Portal业务处理单元，其负责处理客户端请求，并发送响应报文，其中，3990端口是默认的Web Portal服务端口，3991-xxxxx端口是本实施例技术扩展的端口号也用于Web Portal服务端口，虚拟接口ed0，本实施例希望提升并发性能，同时又不改变原来的软件架构，所以将扩展的服务端口绑定到虚拟接口ed0上。

端口映射，将原始的3990根据一定的规则映射到扩展的服务端口号(3991-xxxx)上。

具体的，步骤如下：

(1)增加一个虚拟网卡驱动程序，虚拟网卡ed0。

(2)在程序启动时，预置若干子进程(具体数量可以根据业务规模而定)，每个子进程都对应一个侦听端口，网卡使用ed0，原始服务还绑定3990端口，网卡使用eth1。

进一步的，为了确保使用本实施例所提供的的技术方案不会出现比不使用情况下更差的结果，图2中的业务子进程还具备fork子进程的能力，虽然不同客户端的的请求会被分配到不同的业务子进程上处理，但理论上还是有可能发生请求集中到某一个业务子进程中，根据对客户端MAC地址的统计计算，以及实际测试，出现这种情况的概率很小。

(3)设置端口映射功能模块，利用Netfliter的HooK机制捕获客户端访问请求报文。

具体的，端口映射模块是一个内核模块，代码编译后得到一个.ko的内核驱动，使用insmod加载该ko模块，模块启动后会利用Linux系统的Netfilter 的HOOK机制捕获到客户端访问Web Portal服务的报文，服务端口号是3990，端口映射根据客户端MAC地址获得。

假设模块捕获到的客户端请求报文目的端口号是3990，选取客户端MAC 地址的最后一个字节与扩展端口数做取余计算(取余算法能够将不同的MAC地址离散分布，本发明使用取余算法是为了将不同的MAC地址请求映射到不同的端口号上，避免多个请求集中到某一个端口号上)，该计算结果加3990得出要替换的端口，该端口确定将请求送给哪个预置服务进程处理。

再进一步的，若扩展32个服务端口，当前捕获的客户端MAC地址是 48-51-C5-70-9B-49，则该请求替换的服务端口号为3999,该客户端请求会被绑定3999的预置子服务处理，计算公式如下：

1. 0x49％32+3990＝3999

(4)使用步骤(3)中计算的扩展服务端口替换原始的3990端口号，根据TCP/UDP的协议要求修改端口后只需要计算TCP或者UDP的头部校验值，所以性能还是有保证的。

(5)将步骤(4)中的skb->dev的值由eth1替换成ed0接口，将该skb 重新提交到系统协议栈中，这样绑定ed0的预置子服务进程就能接收到该请求。

具体的，Skb在Linux内核代码中代表一个数据包，skb->dev表示数据包来自哪个网卡,不替换则应用程序就无法接收到数据包。

(6)步骤(5)后预置服务进程就能从ed0上收到客户端的请求报文，业务子程序按照业务处理逻辑响应请求，并将业务逻辑处理模块产生的响应报文通过ed0发送出去。

(7)端口映射模块捕获到发送给客户端的响应报文后，将报文中扩展的端口号还原成3990，还原操作方法与步骤(4)相同，只是将映射的3999还原成3990，然后调用eth1的发送接口将报文发送给客户端。

上述步骤完成了一次请求、响应交互过程，整个过程对客户端来讲是透明不可见的。

优选的，本实施例还需要详细说明的是，本发明通过预启动若干个具备业务功能的服务子进程的方法，使服务端具备并发处理能力，与常用的并发技术相比，本发明方法代码结构更加简单，能够兼容已有的代码，当预置子服务出现故障时，原服务任然能够正常运行，所以稳定性更高。

优选的是，本发明在服务端初始化阶段就预置多个子服务进程并绑定各自的服务端口号，根据客户端标识如MAC地址，将原始的服务端口号映射成子服务端口号，与进程池相比本发明方法不需要对子进程调度和管理完全是静态的；此外由于各个服务子进程完全是独立的(包括端口号)，所以即使某个子进程出现故障，也不会影响整个服务。

实施例2

参照图4和图5，为本发明的第二个实施例，该实施例不同于第一个实施例的是，提供了一种基于嵌入式平台服务端的并发处理方法的实验测试，具体包括：

传统的服务端并发处理方法若运行在嵌入式平台上CPU、内存、flash资源都相对有限，本发明设计思路是将服务端程序静态化，用静态预置的服务子进程代替动态申请的子进程，每个预置的服务进程都绑定到一个扩展端口上，每个子进程都是一个独立的服务端，，服务端通过客户端标识将若干客户端请求离散分配到各个子进程上处理。

优选的，每个服务端软件对外都会有一个端口号，如HTTP用80；MySQL 用3306；FTP用21、22；若一个服务端软件对外端口是8000，本发明方法则在原来的基础上扩展若干个业务端口，这些扩展的端口对客户端是透明的，从客户端看服务端口号始终是8000。

参照图4，端口映射模块根据客户端标识(如MAC地址)，使用离散算法将客户端请求分配到各个预置服务进程中处理，在该模块中还能很容易地实现优先级控制,功能。

本实施例在嵌入式开发平台上测试开源的Coovachilli软件，Coova Chilli是一种应用广泛的Web Portal认证(Captive Portal、UMA)和网关解决方案，可以作为嵌入程序到路由器中，或者作为独立服务软件运行，目前已经被集成到操作系统Openwrt中。

为了验证本发明的有效性，在相同的硬件平台上，对比使用本发明的Coovachilli软件和未使用本发明的Coovachilli软件在响应相同数量的QPS 时的CPU占用率。

表1：试验环境:。

测试步骤：

SS1：github下载coova-chilli源码，源码地址；

SS2：编译、安装coova-chilli软件；

SS3：使用三台PC接BCM4908平台路由器LAN口；

SS4：PC浏览器访问某个IP地址如1.2.3.4，coovachilli Web Portal 认证功能会将该页面请求重定向到指定的页面如：192.168.0.1/index.htm；

SS5：设置PC的IE浏览器自动刷新功能，时间间隔100ms；

SS6：TOP命令统计BCM4908 CPU使用率。

表2：测试结果。

表2-1

表2-2

表2-3

参照上述表格内容，能够直观的从表2-1中看出，未使用本发明的 Coovachilli软件方案占用了大量CPU资源，而使用本发明的测试结果如表2-2 所示，CPU占用率则显著降低，从测试结果表2-3中看出，本发明方法能够让相同硬件平台接入处理更多的业务请求。

应当认识到，本发明的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术-包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作——根据在具体实施例中描述的方法和附图。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本文描述的过程的操作，除非本文另外指示或以其他方式明显地与上下文矛盾。本文描述的过程(或变型和/或其组合) 可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本发明的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本文所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本发明所述的方法和技术编程时，本发明还包括计算机本身。计算机程序能够应用于输入数据以执行本文所述的功能，从而转换输入数据以生成存储至非易失性存储器的输出数据。输出信息还可以应用于一个或多个输出设备如显示器。在本发明优选的实施例中，转换的数据表示物理和有形的对象，包括显示器上产生的物理和有形对象的特定视觉描绘。

如在本申请所使用的，术语“组件”、“模块”、“系统”等等旨在指代计算机相关实体，该计算机相关实体可以是硬件、固件、硬件和软件的结合、软件或者运行中的软件。例如，组件可以是，但不限于是：在处理器上运行的处理、处理器、对象、可执行文件、执行中的线程、程序和/或计算机。作为示例，在计算设备上运行的应用和该计算设备都可以是组件。一个或多个组件可以存在于执行中的过程和/或线程中，并且组件可以位于一个计算机中以及/或者分布在两个或更多个计算机之间。此外，这些组件能够从在其上具有各种数据结构的各种计算机可读介质中执行。这些组件可以通过诸如根据具有一个或多个数据分组(例如，来自一个组件的数据，该组件与本地系统、分布式系统中的另一个组件进行交互和/或以信号的方式通过诸如互联网之类的网络与其它系统进行交互)的信号，以本地和/或远程过程的方式进行通信。

应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。