CN116156020A - 数据处理方法、设备及可读存储介质 - Google Patents

Abstract

本申请实施例提供一种数据处理方法、设备及可读存储介质，上行过程中，当NGINX服务器通过目标UDP端口接收到来自客户端设备的第一QUIC报文后，将该第一QUIC报文发送给QUIC协议栈，使得QUIC协议栈处理第一QUIC报文得到应用层数据，并向上游服务器发送包含第一应用层数据包的第一数据流。下行过程中，从上游服务器接收第二数据流，将第二数据流中的第二应用层数据包缓存在第二缓存中，并在QUIC协议栈可写时交给QUIC协议栈处理得到第二QUIC报文并发送给客户端设备。采用该种方案，通过在NGINX服务器上集成QUIC协议栈，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

Description

数据处理方法、设备及可读存储介质

技术领域

本申请实施例涉及互联网技术领域，特别涉及一种数据处理方法、设备及可读存储介质。

背景技术

用户数据报协议(User Datagram Protocol，UDP)是开放式***互连(OpenSystemInterconnect，OSI)参考模型中的一种无连接的传输层协议。快速UDP互联网连接(Quick UDP Internet Connections，QUIC)协议是谷歌制定的一种基于UDP的低时延的互联网传输层协议，具有很多的优点，比如减少连接延迟、避免队头阻塞等。

NGINX服务器是一个高性能的超文本传输协议(Hyper Text Transfer Protocol，HTTP)和反向代服务器，有着高并发、性能好和占用内存少等特点。目前，基于NGINX使用QUIC的场景中，使用443端口传输超文本传输协议(Hypertext Transfer Protocol，HTTP)/3报文。

然而，上述的443端口仅支持一种应用层协议，即仅支持HTTP/3.0，不支持其他应用层协议，导致基于NGINX使用QUIC的场景受限，无法支持更多的业务。

发明内容

本申请实施例提供一种数据处理方法、设备及可读存储介质，通过在NGINX服务器上集成QUIC协议栈，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

第一方面，本申请实施例提供一种数据处理装置，通过目标UDP端口接收来自客户端设备的第一QUIC报文，所述目标UDP端口支持多种应用层协议；

向所述QUIC协议栈发送所述第一QUIC报文，以使得所述QUIC协议栈处理所述第一QUIC报文并得到应用层数据；

根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流，所述第一应用层数据包至少包含一个所述第一QUIC报文对应的应用层数据。

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

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

本申请实施例提供的数据处理方法、设备及可读存储介质，应用于集成了QUIC协议栈的NGINX服务器。上行过程中，当NGINX服务器接收到来自客户端设备的第一QUIC报文后，将该第一QUIC报文发送给QUIC协议栈，使得QUIC协议栈处理第一QUIC报文得到应用层数据，并向上游服务器发送包含第一应用层数据包的第一数据流。下行过程中，从上游服务器接收第二数据流，将第二数据流中的第二应用层数据包缓存在第二缓存中，并在QUIC协议栈可写时交给QUIC协议栈处理得到第二QUIC报文并发送给客户端设备。采用该种方案，通过在NGINX服务器上集成QUIC协议栈，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

附图说明

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

图1是本申请实施例提供的数据处理方法所适用的网络架构示意图；

图2是本申请实施例提供的NGINX服务器的结构示意图；

图3是本申请实施例提供的数据处理方法的流程图；

图4是本申请实施例提供的数据处理方法中第一QUIC报文的结构示意图；

图5是本申请实施例提供的数据处理方法的另一个流程图；

图6是本申请实施例提供的数据处理方法中在NGINX服务器上集成QUIC协议栈的示意图；

图7是本申请实施例提供的数据处理方法中预先注册回调事件的示意图；

图8为本申请实施例提供的一种数据处理装置的示意图；

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

具体实施方式

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

随着QUIC协议的大量普及，第三版超文本传输协议(Hypertext TransferProtocol/3，HTTP/3.0)也已经标准化，越来越多的厂商开始推出支持使用QUIC协议传输HTTP请求的产品，这种应用QUIC的场景称之为HTTP/3.0融合QUIC(HTTP/3.0over QUIC)。

实时消息传输协议(Real Time Messaging Protocol，RTMP)是直播领域的推拉流场景中一种常见的协议，随着QUIC协议的发展，也存在RTMP over QUIC的需求。

目前，HTTP/3.0over QUIC使用的是HTTP/3.0。但是，在网页和其他领域也有一部分客户需求使用HTTP/1.1over QUIC、HTTP/2.0over QUIC。显然，现在的融合QUIC的场景，仅支持HTTP/3.0，不支持其他应用层协议，如HTTP/1.1、HTTP/2.0或RTMP等。其中，HTTP/3.0over QUIC场景中，使用443端口传输HTTP/3.0报文。

为了使得融合QUIC的场景支持除了HTTP/3.0以外的其他应用层协议，常见的解决方式是针对每个应用层协议分配UDP端口，不同应用层协议对应不同的UDP端口，从而使的QUIC能够服务多种不同的应用层协议。

然而，当为不同的应用层协议分配不同的UDP端口时，对外提供的UDP端口多、UDP端口开销大。

基于此，本申请实施例提供一种数据处理方法、装置、设备及***，通过在NGINX服务器上集成QUIC协议栈，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

图1是本申请实施例提供的数据处理方法所适用的网络架构示意图。请参照图1，该网络架构包括NGINX服务器11、客户端设备12和上游服务器13。NGINX服务器11与客户端设备12之间建立网络连接，NGINX服务器11与上游服务器13之间建立网络连接。

NGINX服务器11集成QUIC协议栈，QUIC协议栈例如是自研的协议栈或基于开源的协议栈。NGINX服务器11是一个代理服务器，NGINX服务器11新增QUIC协议栈的处理功能，例如，在NGINX服务器11上新增一个NGX-QUIC模块，NGX-QUIC模块负责QUIC协议栈的处理，包括QUIC的配置项处理、QUIC的业务处理等。

客户端设备12包括但不限于安装有安卓操作***、微软操作***、塞班操作***、Linux操作***或苹果iOS操作***的手机、平板电脑、个人电脑、电子书阅读器、膝上型便携电脑、台式计算机、服务器等。直播领域中，客户端设备12可以是主播端的终端设备，也可以是观看端的终端设备。当客户端设备12是主播端时，通过NGINX服务器11向上游服务器13推流。当客户端设备12是观看端时，通过NGINX服务器11从上游服务器13拉流。

上游服务器13例如为直播服务器等流媒体服务器。

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

图2是本申请实施例提供的NGINX服务器的结构示意图。请参照图2，本申请实施例提供的NGINX服务器200包括NGX-QUIC模块21、探测模块22、应用层协议模块23。其中，应用层协议模块23包括HTTP/1.1单元231、HTTP/2.0单元232和RTMP单元233。图2中的客户端设备100相当于图1中的客户端设备12，图2中的NGINX服务器200相当于图1中的NGINX服务器11，图2中的上游服务器300相当于图2中的上游服务器13。

NGX-QUIC模块21，负责QUIC协议栈的处理，包括QUIC的配置项处理、QUIC的业务处理等。对于上行，NGX-QUIC模块21接收到客户端设备发送的第一QUIC报文后，将该第一QUIC报文发送给QUIC协议栈，经过QUIC协议栈的处理得到第一应用层数据包后，应用层协议模块23向上游服务器发送包含第一应用层数据包的第一数据流。对于下行，应用层协议模块23从上游服务器接收第二数据流，将该第二数据流中的第二应用层数据包发送给QUIC协议栈，经过QUIC协议栈的处理得到第二QUIC报文后，NGX-QUIC模块21将第二QUIC报文发送给客户端设备。

NGX-QUIC模块21具有第一缓存和第二缓存，第一缓存又称为接收缓存，当QUIC协议栈可读时，NGX-QUIC模块21从QUIC协议栈读取第一应用层数据包并缓存在第一缓存中。第二缓存又称为发送缓存，用来缓存NGINX服务器200的应用层准备发送出去的第二应用层数据，第二应用层数据包是NGINX服务器200从上游服务器接收到的第二数据流包含的应用层数据包。当QUIC协议栈可写时，NGX-QUIC模块21将第二缓存中的第二应用层数据包写入QUIC协议栈。

NGX-QUIC模块21还挂钩QUIC协议栈的各种接口，如新连接创建、新流创建、流结束、连接结束等，通过在NGX-QUIC模块21上实现这些接口，能够完成相关业务功能。

探测模块22，用于探测第一应用层数据包的协议类型。当需要将第一缓存中的第一应用层数据包通过NGINX服务器200的应用层发送给上游服务器时，探测协议模块对第一应用层数据包进行协议探测，以探测第一应用层数据包是基于HTTP/1.1的数据包、基于HTTP/2.0的数据包或基于RTMP的数据包。

应用层协议模块23，用于从第一缓存中读取第一应用层数据包，并向上游服务器发送包含所述第一应用层数据包的第一数据流，或者，从上游服务器接收包含第二应用层数据包的第二数据流，并将第二应用层数据包缓存到第二缓存中。

请参照图2，对于上行(即NGINX服务器向上游服务器发包)，应用层协议模块23，用于根据第一应用层数据包的协议类型，从第一缓存读取第一应用层数据包并向上游服务器发送。例如，需求NGINX服务器200支持HTTP/1.1over QUIC、HTTP/2.0over QUIC或RTMPover QUIC，则应用层协议模块23包括HTTP/1.1单元231、HTTP/2.0单元232和RTMP单元233，分别用来发送基于HTTP/1.1的第一应用层数据包、基于HTTP/2.0的第一应用层数据包和基于RTMP的第一应用层数据包。

图2中，实线箭头代表QUIC报文的流向，虚线箭头代表第一应用层数据包的流向，点划线箭头代表第一数据流和第二数据流的流向。

对于下行，应用层协议模块23的各个单元从上游服务器接收第二应用层数据包，第二应用层数据包又称为NGINX服务器的应用层准备发送的数据包。应用层协议模块23将这些第二应用层数据包缓存到NGX-QUIC模块21的第二缓存中。当QUIC协议栈可写时，将第二缓存中的第二应用层数据包写入QUIC协议栈，以使得所述QUIC协议栈处理所述第二应用层数据包并得到第二QUIC报文。NGX-QUIC模块21向客户端设备发送第二QUIC报文。

下面，基于图1所示网络架构和图2所示NGINX服务器的结构，对本申请实施例所述的数据处理方法进行详细说明。示例性的，请参照图3。

图3是本申请实施例提供的数据处理方法的流程图。本实施例是从集成了QUIC协议栈的NGINX服务器的角度进行说明，本实施例包括：

301、通过目标UDP端口接收来自客户端设备的第一QUIC报文，所述目标UDP端口支持多种应用层协议。

本申请实施例中，目标UDP端口例如为443端口等，多种不同的应用层协议使用相同的目标UDP端口。多种不同的应用层协议包括但不限于HTTP/1.1、HTTP/2.0或RTMP等。NGINX服务器监听目标UDP端口，从网卡接收来自客户端的第一QUIC报文。

图4是本申请实施例提供的数据处理方法中第一QUIC报文的结构示意图。请参照图4，UDP报文的载荷包含第一QUIC报文，第一QUIC报文包括QUIC报文头和QUIC载荷，QUIC载荷包含加密的应用层数据，该些加密的应用层数据例如为基于HTTP/1.1、HTTP/2.0或RTMP的数据。

302、向所述QUIC协议栈发送所述第一QUIC报文，以使得所述QUIC协议栈处理所述第一QUIC报文并得到应用层数据。

NGINX服务器接收到第一QUIC报文后，并非直接发送给应用层，而是将第一QUIC报文发送给QUIC协议栈，由QUIC协议栈对第一QUIC报文进行处理。例如，NGINX服务器挂钩监听目标UDP端口的读事件，在读事件处理函数内部负责接收第一QUIC报文，并通过QUIC协议栈的接口将第一QUIC报文传递给QUIC协议栈。采用该种方案，通过挂钩目标UDP端口的读事件处理函数实现将第一QUIC报文截获并发送给QUIC协议栈，方式简单、速度快。

为了提高性能，NGINX服务器可使用内核支持的组合收包函数收包(即接收第一QUIC报文)，组合收包函数例如为recvmmsg等，本申请实施例并不限制。

对于上行，QUIC协议栈的处理包括乱序重组、重复过滤、校验、解密等，处理后得到第一应用层数据包。例如，QUIC协议栈依次收到两个第一QUIC报文，第一个第一QUIC报文携带序号为20的、200字节的应用层数据，第二个第一QUIC报文携带序号为19的、300字节的应用层数据，QUIC协议栈解密两个第一QUIC报文得到明文的应用层数据，对应用层数据进行重组得到500字节的第一应用层数据包，该第一应用层数据包中序号为19的应用层数据在前，序号为20的应用层数据在后。

再如，QUIC协议栈收到2个第一QUIC报文，携带相同的应用层数据，则QUIC协议栈删除其中一个第一QUIC报文。

又如，QUIC协议栈收到两个第一QUIC报文并解密成明文数据，其中一个第一QUIC报文携带序号为3的应用层数据，另一个第一QUIC报文携带序号为14号的应用层数据。QUIC协议栈将3号应用层数据和14号应用层数据放到QUIC协议栈的读缓存中，但是不通知应用层读取，即QUIC协议栈不可读。直到4-13号应用层数据都放到QUIC协议栈的读缓存中后，QUIC协议栈可读，通知应用层从QUIC协议栈读取3-14号应用层数据对应的一个或多个第一应用层数据包。

303、根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流，所述第一应用层数据包至少包含一个所述第一QUIC报文对应的应用层数据。

本申请实施例中，NGINX服务器的应用层根据第一应用层数据包的协议类型，向上游服务器发送包含第一应用层数据包的第一数据流。显然，应用层发送的第一数据流中的第一应用层数据包并非是监听网卡从目标UDP端口得到的，而是经过QUIC协议栈处理后得到的第一应用层数据包。第一层应用层数据包有可能是基于RTMP的数据包、基于HTTP/1.1的数据包、基于HTTP/2.0的数据包等。

本申请实施例提供的数据处理方法，应用于集成了QUIC协议栈的NGINX服务器。当NGINX服务器接收到来自客户端设备的第一QUIC报文后，将该第一QUIC报文发送给QUIC协议栈，使得QUIC协议栈处理第一QUIC报文得到应用层数据，之后根据第一应用层数据包的协议类型向上游服务器发送包含第一应用层数据包的第一数据流。采用该种方案，通过在NGINX服务器上集成QUIC协议栈，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

可选的，上述实施例中，NGINX服务器根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流的过程中，当所述QUIC协议栈可读时，从所述QUIC协议栈读取所述第一应用层数据包并缓存至第一缓存。之后，根据所述第一应用层数据包的协议类型，从所述第一缓存读取所述第一应用层数据包并向上游服务器发送包含所述第一应用层数据包的第一数据流。

本申请实施例中，当QUIC协议栈的读缓存中有第一应用层数据包时，表示QUIC协议栈可读。此时，NGINX服务器从QUIC协议栈的读缓存中读取第一应用层数据包，并将第一应用层数据包缓存到第一缓存，即接收缓存中。

当第一缓存中有第一应用层数据包时，NGINX服务器的应用层根据第一应用层数据包的协议类型，从第一缓存读取所述第一应用层数据包。之后，向上游服务器发送包含所述第一应用层数据包的第一数据流。

采用该种方案，QUIC协议栈可读时，NGINX服务器从QUIC协议栈读取第一应用层数据包并缓存在第一缓存中，应用层中第一缓存中读取第一应用层数据包而非监听网卡读取实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

以上是从上行的角度进行说明，下面对下行过程中，即NGINX服务器从上游服务器接收到第二数据流，NGINX服务器的应用层如何将第二数据流中的第二应用层数据包发送给客户端进行详细说明。示例性的，请参照图5。

图5是本申请实施例提供的数据处理方法的另一个流程图。本实施例是从下行的角度说明。本实施例包括：

501、接收来自上游服务器的第二数据流。

本步骤中，NGINX服务器的应用层接收来自流媒体服务器等上游服务器的第二数据流，该第二数据流包含至少一个第二应用层数据包。这些第二应用层数据包称作NGINX服务器的应用层准备发出去的数据包。

502、将所述第二数据流包含的第二应用层数据包缓存至第二缓存。

本申请实施例中，NGINX服务器的应用层接收到第二数据流后，并非直接把第二应用层数据包通过网卡发送给客户端，而是把第二应用层数据包缓存在第二缓存，即发送缓存中。

503、当所述QUIC协议栈可写时，向所述QUIC协议栈发送所述第二缓存中的所述第二应用层数据包，以使得所述QUIC协议栈处理所述第二应用层数据包并得到第二QUIC报文。

本申请实施例中，当QUIC协议栈的写缓存空出时，表示QUIC协议栈可写，例如，写缓存50％的空间空闲，则表示QUIC协议栈可写。此时，NGINX服务器将第二缓存中的第二应用层数据包写入QUIC协议栈的写缓存，使得QUIC协议栈对第二应用层数据包进行添加QUIC报文头、UDP包头等QUIC报文组装动作并加密等，从而得到第二QUIC报文。

504、通过目标UDP端口向所述客户端设备发送所述第二QUIC报文。

NGINX服务器通过目标UDP端口向客户端设备发送第二QUIC报文。例如，NGINX服务器挂钩QUIC协议栈的发包接口，在NGX-QUIC模块负责将第二应用层数据包进行组装得到第二QUIC报文后发送。为了提高发送性能，NGINX服务器可使用内核支持的组合发包函数发包，即发送第二QUIC报文。组合发包函数例如为通用分段延后处理(Generic SegmentationOffload，GSO)函数、sendmmsg函数等。

采用该种方案，下行过程中通过将第二数据流中的第二应用层数据包缓存并交给QUIC协议栈处理，实现基于NGINX使用QUIC的场景同时支持多种应用层协议的目的，且不同应用层协议使用同一个UDP端口，降低端口开销。

可选的，上述实施例中，NGINX服务器根据所述第一应用层数据包的协议类型，向上游服务器发送所述第一应用层数据包之前，还挂钩所述NGINX服务器应用层基于HTTP的第一接收接口，通过所述第一接收接口从所述第一缓存读取所述第一应用层数据包。之后，探测所述第一应用层数据包的协议类型，所述协议类型包括HTTP/1.1、HTTP/2.0或RTMP。

请参照图2，本申请实施例中，NGINX服务器需要同时支持HTTP/1.1，HTTP/2.0，HTTP/3.0以及RTMP，需要有探测模块。NGINX服务器有一个应用层连接原生的接收(recv)接口，但是可以挂载，比如挂载同一个接口来收包，然后发给不同的应用层单元。原生的接收(recv)接口可区分出HTTP/1.1、HTTP/2.0或RTMP。比如，给原生的接收(recv)接口挂两个简单的函数，分别对应HTTP的第一接收接口以及RTMP单元的第二接收接口。其中，HTTP/1.1单元和HTTP/2.0都利用第一接收接口从第一缓存中读取第一应用层数据包。

当第一缓存中有第一应用层数据包时，NGINX服务器200的NGX-QUIC模块21挂钩应用层基于HTTP的第一接收接口，如第一接收接口或第二接收接口。然后，通过所述第一接收接口从所述第一缓存读取第一应用层数据包，例如，读取第一应用层数据包的一个或几个字节，基于读取到的字节探测第一应用层数据包的协议类型，所述协议类型包括HTTP/1.1、HTTP/2.0或RTMP等。

这样一来，协议探测所读取的字节从HTTP单元，如HTTP/1.1单元进入探测模块，探测模块对第一应用层数据包的一个或几个字节进行分析，从而确定出第一应用层数据包采用的是哪种应用层协议，应用层协议包括但不限于HTTP/1.1、HTTP/2.0或RTMP等。

采用该种方案，通过协议探测的方式完成不同应用层协议使用同一个目标UDP端口，同一个UDP端口同时服务不同的应用层协议，减少UDP端口开销、提高基于NGINX使用QUIC的场景的适用范围。

可选的，上述实施例中，NGINX服务器通过探测模块探测第一应用层数据包的协议类型时，使用第一文件描述符(file description，fd)针对第一应用层数据包创建应用层连接，其中，第一fd和第一QUIC报文的第二fd不同。然后，为应用层连接添加探测接口(peek)，利用所述探测接口探测所述第一应用层数据包的协议类型。

传统基于传输控制协议(Transmission Control Protocol，TCP)的不同应用层协议共用端口的方案中，HTTP/2.0、RTMP的探测是通过对已经完成3次握手的TCP的fd执行接收接口的MSG_PEEK操作。但是本申请实施例中，应用层的fd，即第一fd是没有经过3次握手的fd，因此探测(peek)时会失败。为此，本申请实施例中，针对第一应用层数据包创建应用层连接(connection)，在该应用层连接上添加一个探测接口，并修改HTTP/2.0或RTMP的探测函数。之所以未修改HTTP/1.1的探测函数，是因为用于协议探测的第一应用层数据包是从HTTP/1.1单元进入的。

协议探测的时候，如果一个第一应用层数据包是UDP的数据包，则利用为应用层添加的探测接口进行探测。倘若是TCP的数据包，则通过传统的基于TCP的端口共用的探测方案。

本申请实施例中，为应用层连接添加的探测接口在NGX-QUIC模块中挂钩一个探测函数，如ngx_quic_peek函数，在该探测函数内部只是拷贝从QUIC协议栈接收到的数据给上层，即应用层模块，如RTMP或HTTP/2.0，拷贝后对应的下标不会移动，即指针不会移动。这样一来，下次应用层模块调用接收函数(ngx_quic_recv)时候数据还在，能够从头读取数据。也就是说，NGX-QUIC模块不负责协议探测，协议探测用的是内核层为应用层连接添加的peek接口，给它挂一个新的用于针对UDP进行协议探测的探测接口，探测完毕之后数据还是在原来的地方而不是读走，比如只探测第一应用层数据包的一个字节或几个字节，探测完毕后这一个字节或几个字节还是在第一缓存中，这种探测不能认为是读操作，因为读操作的话指针要往后移动。而本申请中，通过添加探测(peek)接口，使得指针不会移动。

需要说明的是，一个QUIC连接可以具有多个流，每个流对应一个应用层连接，应用层连接是虚拟出来的，第一fd不是经过3次握手得到的fd，应用层连接例如为HTTP连接、RTMP连接等。

采用该种方案，通过对基于TCP的端口共用的探测方案进行改进，使得协议探测模块同时支持基于TCP的端口共用的探测和基于UDP的端口共用的探测，提高NGINX服务器的业务适用范围，降低成本和工作量。

可选的，上述实施例中，当NGINX服务器根据所述第一应用层数据包的协议类型，向上游服务器发送所述第一应用层数据包时，挂钩所述NGINX服务器应用层基于RTMP的第二接收接口，当所述第一应用层数据包的协议类型为RTMP时，通过所述第二接收接口从所述第一缓存中读取所述第一应用层数据包，并向所述上游服务器发送；当所述第一应用层数据包的协议类型为HTTP/1.1或HTTP/2.0时，通过所述第一接收接口从所述第一缓存中读取所述第一应用层数据包，并向所述上游服务器发送。

示例性的，为了使得NGINX同时支持HTTP/1.1over QUIC、HTTP/2.0over QUIC或RTMP over QUIC，在NGINX服务器上分别设置HTTP/1.1单元、HTTP/2.0单元和RTMP单元，使用HTTP/1.1单元来处理HTTP/1.1协议的收发，使用HTTP/2.0来处理HTTP/2.0协议的收发，使用RTMP单元来处理RTMP协议的收发。

针对HTTP/1.1、HTTP/2.0的收包，以针对HTTP/1.1的收包为例，NGINX服务器的NGX-QUIC模块挂钩NGINX服务器原生的应用层的第一接收接口1，在第一接收接口1对应的接收函数内部调用QUIC协议栈的读(read)接口，读出QUIC协议栈已经处理好并缓存到第一缓存中的第一应用层数据包给HTTP/1.1单元来处理。HTTP/1.1单元将第一应用层数据包放在HTTP数据流中发送给上游的服务器。

同理，针对HTTP/2.0的收包为例，NGINX服务器的NGX-QUIC模块挂钩NGINX服务器原生的应用层的第一接收接口，在第一接收接口对应的接收函数内部调用QUIC协议栈的读(read)接口，读出QUIC协议栈已经处理好并缓存到第一缓存中的第一应用层数据包给HTTP/2.0单元来处理。HTTP/2.0单元将将第一应用层数据包放在HTTP数据流中发送给上游的服务器。

针对RTMP的收包，NGINX服务器的NGX-QUIC模块挂钩NGINX服务器原生的应用层的第二接收接口，在第二接收接口对应的接收函数内部调用QUIC协议栈的读(read)接口，读出QUIC协议栈已经处理好并缓存到第一缓存中的第一应用层数据包给RTMP单元来处理。RTMP单元将第一应用层数据包放在RTMP数据流中发送给上游的服务器。

采用该种方案，通过挂钩NGINX服务器原生的应用层的接收接口，应用层的不同协议单元就可以从第一缓存中读取第一应用层数据并发送给上游服务器，过程简单、成本低。

以上描述了客户端设备向NGINX服务器发送第一QUIC报文后，NGINX服务器的应用层如何收包并发送给上游服务器。下面，对上游服务器对NGINX服务器发送第二数据流后，NGINX服务器的应用层如何发包进行详细说明。

可选的，上述实施例中，当所述QUIC协议栈可写时，NGINX服务器接收来自上游服务器的第二数据流，将所述第二数据流包含的第二应用层数据包缓存至第二缓存。

当QUIC协议栈可写时，针对HTTP/1.1、HTTP/2.0的发包，NGINX服务器的NGX-QUIC模块挂钩NGINX服务器原生的第一发送接口，如send_chain接口，在该第一发送接口内部将HTTP/1.1单元或HTTP/2.0单元准备发送的第二应用层数据包，通过QUIC协议栈的写(write)接口写入QUIC协议栈的写缓存，由QUIC协议栈决定何时发送给客户端设备。其中，NGINX服务器的NGX-QUIC模块可针对HTTP/1.1、HTTP/2.0挂载同一个第一发送接口，或不同的第一发送接口，本申请实施例并不限制。

当QUIC协议栈可写时，即QUIC协议栈的写缓存的空闲空间比较多时，针对RTMP的发包，NGINX服务器的NGX-QUIC模块挂钩所述NGINX服务器的第二发送接口，如send接口，在该第二发送接口内部将RTMP单元准备发送的第二应用层数据包，通过QUIC协议栈的写(write)接口写入QUIC协议栈的写缓存，由QUIC协议栈决定何时发送给客户端设备。

采用该种方案，通过挂钩NGINX服务器原生的发送接口，应用层的不同协议单元就可以将准备发送给客户端设备的第二应用层数据发送给QUIC协议栈，，过程简单、成本低。

可选的，上述实施例中，NGINX服务器向所述QUIC协议栈发送所述第一QUIC报文时，当所述NGINX服务器热更新或升级时，根据所述第一QUIC报文携带的四元组从端口复用组的多个进程组中确定目标进程组，所述多个进程组中的每个进程组具有独立的ebpf资源。之后，从所述目标进程组的各进程的fd中选择出目标fd；并利用所述目标fd向所述QUIC协议栈发送所述第一QUIC报文。

示例性的，热更新也称为reload、配置更新、热重载、重载配置等，指动态加载配置、更新部署在NGINX服务器上的应用服务中的参数，但是不改变整个应用服务，未对应用服务进行版本升级。升级是指对应用服务进行版本升级，即用升级后的应用服务替换升级前的应用服务。NGINX服务器启动后，针对一个应用服务创建主(master)进程，由主进程创建一组工作(worker)进程。当对应用服务进行热更新时，每reload一次，则产生一个新的进程组，从而存在多个进程组。此时，NGINX服务器根据第一QUIC报文携带的四元组从目标UDP端口的多个进程组中确定目标进程组，多个进程组中的每个进程组具有独立的ebpf资源。然后，从目标进程组的各进程的fd中选择出目标fd。例如，NGINX服务器从目标进程组包含的多个进程中确定出负载较小的进程，将该进程的fd作为目标fd，利用目标fd向QUIC协议栈发送第一QUIC报文。

采用该种方案，通过使用ebpf方式，在内核针对第一QUIC报文选择路由时挂入应用层的决策，通过四元组方式区分不同的客户端设备，解决热更新或升级带来的数据包错乱问题。

图6是本申请实施例提供的数据处理方法中在NGINX服务器上集成QUIC协议栈的示意图。请参照图6，上行场景中，客户端设备发送的第一QUIC报文进入NGINX服务器后，被NGX-QUIC模块发送给QUIC协议栈。在QUIC协议栈经过握手处理、证书加载和模式选择后，进行连接处理。之后，QUIC协议栈对第一QUIC报文进行流处理，如乱序重组、校验等得到第一应用层数据包，该第一应用层数据包缓存在QUIC协议栈的读缓存中。图中未示意出QUIC协议栈的读缓存。

当QUIC协议栈的读缓存中有第一应用层数据时，表示QUIC协议栈可读。此时，触发流可读事件。NGX-QUIC模块从QUIC协议栈读取第一应用层数据包并缓存在第一缓存中，图中未示意出第一缓存。由于NGX-QUIC模块挂钩了应用层协议模块的第一接收接口或第二接收接口，因此，应用层协议模块的各协议单元就能从第一缓存中读取第一应用层数据包，从而完成应用层收包。之后，各协议单元将从第一缓存读取到的数据包通过流的方式发送给上游服务器。

下行场景中，上游服务器的第二数据流到达NGINX服务器后，由于NGX-QUIC模块挂钩了应用层协议模块的第一发送接口和第二发送接口，因此，NGX-QUIC模块将第二数据流缓存至第二缓存，图中未示意出第二缓存。当QUIC协议栈的写缓存可写时，触发流可写事件。NGX-QUIC模块将第二缓存中的第二应用层数据包写入QUIC协议栈的写缓存。QUIC协议栈对第二应用层数据包进行处理，得到第二QUIC报文。然后，QUIC协议栈进行拥塞控制等流控。流控完毕后，在合适的时机调用QUIC协议栈的发包函数，把第二QUIC报文发送出去，如采用GSO方式发包等。

图7是本申请实施例提供的数据处理方法中预先注册回调事件的示意图。请参照图7，NGX-QUIC模块监听的目标UDP端口的读事件处理函数例如为ngx_quic_read_handler。NGINX服务器的工作进程初始化时，向QUIC协议栈注册回调事件，回调事件包括流可读(stream read)事件、流可写(stream write)事件。之后，上下行过程中，当回调事件中的任意一个目标事件触发回调时，处理目标事件。

另外，回调事件除了包括上述的流可读(stream read)事件、流可写(streamwrite)事件外，可选的，还包括新连接(new conn)创建事件、新流(new stream)创建事件、流关闭(stream close)事件或连接关闭(conn close)事件等。

请参照图7，初始化包括初始化QUIC协议栈(init QUIC stack)、设置流的回调(set QUIC stream Callback)、设置证书加载的回调(set QUIC load cert callback)、设置服务器名称认证回调(set QUIC sni Callback)、设置QUIC连接读事件回调(set QUICconn read handler)、设置发包函数回调(set pack out Callback)、增加定时器(addtimer to process QUIC conns)。

图7中，QUIC协议栈的回调函数例如为Process quic conns。NGINX服务器通过ngx_quic_read_handler函数收到第一QUIC报文后，送给QUIC协议栈，由QUIC协议栈完成包的乱序重组、校验等工作。当QUIC协议栈可读时，NGX-QUIC模块处理可读事件回调。

NGX-QUIC模块调用协议栈的回调函数Process quic conns处理所有回调事件，包括新连接创建事件、新流创建事件、流可读事件、流可写事件、流关闭事件或连接关闭事件等。这些回调事件在NGINX服务器的工作进程初始化时就已经做好注册。

采用该种方案，NGINX服务器的工作进程初始化时向QUIC协议栈注册各种回调事件，确保NGINX服务器支持多种应用层协议，提高基于NGINX使用QUIC的应用范围。

本申请实施例中，给QUIC协议栈添加数据包发送回调，用于发送QUIC协议栈组装好准备发送的第二QUIC报文，也是在工作进程初始化中设置。

请参照图7，添加一个定时器，根据定时器处理QUIC协议栈的各种事件。这是因为QUIC协议栈收到第一QUIC报文后，QUIC协议栈的读缓存很有可能并不是马上就能可读，比如，QUIC协议栈收到第一QUIC报文携带4号应用层数据，之前应用层协议模块已经从第一缓存中读完2号应用层数据，由于3号应用层数据还未收到，因此，不能将携带4号应用层数据缓存到第一缓存中。倘若QUIC协议栈不可读，则需要通过定时器处理后续的QUIC协议栈可读事件。

针对QUIC协议栈回调新连接事件，NGINX服务器使用第一fd创建一个应用层的连接，即应用层连接，从而避免将目标UDP端口的第二fd传给应用层时被应用层调用关闭(close)函数关闭，或者其他可能导致第二fd出现问题的操作。应用层连接与HTTP挂钩，设置该应用层连接对应的接收函数和发送函数，如recv函数、send函数或send_chain函数，然后通过HTTP的监听函数初始化。

针对QUIC协议栈回调可读事件：NGX-QUIC模块从QUIC协议栈的读缓存中读取第一应用层数据包，保存在应用层连接对应的buffer中，每个应用层连接有自己的buffer。然后，调用应用层的第一接收接口或第二接收接口，如HTTP/1.1单元、HTTP/2.0单元或RTMP单元，从而读取第一缓存中的第一应用层数据包。

针对QUIC协议栈回调可写事件：NGX-QUIC模块将应用层协议模块的各个协议单元准备调用send或send_chain发送出去的第二应用层数据包缓存至第二缓存。当QUIC协议栈可写时，通过QUIC协议栈的写(write)接口写入QUIC协议栈的写缓存，QUIC协议栈在合适的时机调用QUIC协议栈的发包函数，把第二QUIC报文发送出去，如采用GSO方式发包等。

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

图8为本申请实施例提供的一种数据处理装置的示意图。该数据处理装置800集成在NGINX服务器上，所述NGINX服务器上还集成QUIC协议栈，该数据处理装置800包括：接收模块81、发送模块83和处理模块82。

接收模块81，用于通过目标UDP端口接收来自客户端设备的第一QUIC报文，所述目标UDP端口支持多种应用层协议；

处理模块82，用于向所述QUIC协议栈发送所述第一QUIC报文，以使得所述QUIC协议栈处理所述第一QUIC报文并得到应用层数据；

发送模块83，用于根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流，所述第一应用层数据包至少包含一个所述第一QUIC报文对应的应用层数据。

一种可行的实现方式中，所述处理模块82，还用于当所述QUIC协议栈可读时，从所述QUIC协议栈读取所述第一应用层数据包并缓存至第一缓存，根据所述第一应用层数据包的协议类型，从所述第一缓存读取所述第一应用层数据包；

所述发送模块83，用于向上游服务器发送包含所述第一应用层数据包的第一数据流。

一种可行的实现方式中，所述处理模块82在所述发送模块83向上游服务器发送包含所述第一应用层数据包的第一数据流之前，还用于挂钩所述NGINX服务器应用层基于HTTP的第一接收接口；通过所述第一接收接口从所述第一缓存读取所述第一应用层数据包；探测所述第一应用层数据包的协议类型，所述协议类型包括HTTP/1.1、HTTP/2.0或RTMP。

一种可行的实现方式中，所述处理模块82探测所述第一应用层数据包的协议类型时，用于使用第一文件描述符fd针对所述第一应用层数据包创建应用层连接，所述第一fd与所述第一QUIC报文的第二fd不同；为所述应用层连接添加探测接口；利用所述探测接口探测所述第一应用层数据包的协议类型。

一种可行的实现方式中，所述处理模块82，用于挂钩所述NGINX服务器应用层基于RTMP的第二接收接口，当所述第一应用层数据包的协议类型为RTMP时，通过所述第二接收接口从所述第一缓存中读取所述第一应用层数据包；所述发送模块83，用于向所述上游服务器发送所述第一应用层数据包；

所述处理模块82，用于挂钩所述NGINX服务器应用层基于RTMP的第二接收接口，当所述第一应用层数据包的协议类型为HTTP/1.1或HTTP/2.0时，通过所述第一接收接口从所述第一缓存中读取所述第一应用层数据包，并通过所述发送模块83向所述上游服务器发送。

一种可行的实现方式中，所述接收模块81，还用于接收来自上游服务器的第二数据流；

所述处理模块82，还用于将所述第二数据流包含的第二应用层数据包缓存至第二缓存；

所述发送模块83，还用于当所述QUIC协议栈可写时，向所述QUIC协议栈发送所述第二缓存中的所述第二应用层数据包，以使得所述QUIC协议栈处理所述第二应用层数据包并得到第二QUIC报文；通过所述目标UDP端口向所述客户端设备发送所述第二QUIC报文。

一种可行的实现方式中，所述处理模块82，还用于挂钩所述NGINX服务器的第一发送接口；

所述发送模块83，用于当所述第二应用层数据包的协议类型为HTTP/1.1或HTTP/2.0时且所述QUIC协议栈可写时，通过所述第一发送接口将所述第二缓存中的所述第二应用层数据包写入所述QUIC协议栈；

所述处理模块82，还用于挂钩所述NGINX服务器的第二发送接口；

所述发送模块83，用于当所述第二应用层数据包的协议类型为RTMP时且所述QUIC协议栈可写时，通过所述第二发送接口将所述第二缓存中的所述第二应用层数据包写入所述QUIC协议栈。

一种可行的实现方式中，所述处理模块82，还用于所述NGINX服务器的工作进程初始化时，向所述QUIC协议栈注册回调事件，所述回调事件包括：流可读事件、流可写事件；当所述回调事件中的任意一个目标事件触发回调时，处理所述目标事件。

一种可行的实现方式中，所述处理模块82，还用于挂钩所述目标UDP端口的读事件处理函数；

所述发送模块83，用于利用所述读事件处理函数将所述第一QUIC报文发送至所述QUIC协议栈。

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

图9为本申请实施例提供的一种电子设备的结构示意图。如图9所示，该电子设备900例如为上述的NGINX服务器，该电子设备900包括：

处理器91和存储器92；

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

所述处理器91执行所述存储器92存储的计算机指令，使得所述处理器91执行如上NGINX服务器实施的数据处理方法。

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

可选地，该电子设备900还包括通信部件93。其中，处理器91、存储器92以及通信部件93可以通过总线94连接。

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

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

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

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

Claims (11)

1.一种数据处理方法，其特征在于，应用于集成了QUIC协议栈的NGINX服务器，所述方法包括：

通过目标UDP端口接收来自客户端设备的第一QUIC报文，所述目标UDP端口支持多种应用层协议；

向所述QUIC协议栈发送所述第一QUIC报文，以使得所述QUIC协议栈处理所述第一QUIC报文并得到应用层数据；

根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流，所述第一应用层数据包至少包含一个所述第一QUIC报文对应的应用层数据。

2.根据权利要求1所述的方法，其特征在于，所述根据第一应用层数据包的协议类型，向上游服务器发送包含所述第一应用层数据包的第一数据流，包括：

当所述QUIC协议栈可读时，从所述QUIC协议栈读取所述第一应用层数据包并缓存至第一缓存；

根据所述第一应用层数据包的协议类型，从所述第一缓存读取所述第一应用层数据包并向上游服务器发送包含所述第一应用层数据包的第一数据流。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一应用层数据包的协议类型，从所述第一缓存读取所述第一应用层数据包并向上游服务器发送包含所述第一应用层数据包的第一数据流之前，还包括：

挂钩所述NGINX服务器应用层基于HTTP的第一接收接口；

通过所述第一接收接口从所述第一缓存读取所述第一应用层数据包；

探测所述第一应用层数据包的协议类型，所述协议类型包括HTTP/1.1、HTTP/2.0或RTMP。

4.根据权利要求3所述的方法，其特征在于，所述探测所述第一应用层数据包的协议类型，包括：

使用第一文件描述符fd针对所述第一应用层数据包创建应用层连接，所述第一文件描述符fd与目标UDP端口的第二文件描述符fd不同；

为所述应用层连接添加探测接口；

利用所述探测接口探测所述第一应用层数据包的协议类型。

5.根据权利要求3所述的方法，其特征在于，所述根据所述第一应用层数据包的协议类型，从所述第一缓存读取所述第一应用层数据包并向上游服务器发送包含所述第一应用层数据包的第一数据流，包括：

挂钩所述NGINX服务器应用层基于RTMP的第二接收接口，当所述第一应用层数据包的协议类型为RTMP时，通过所述第二接收接口从所述第一缓存中读取所述第一应用层数据包，并向所述上游服务器发送；

当所述第一应用层数据包的协议类型为HTTP/1.1或HTTP/2.0时，通过所述第一接收接口从所述第一缓存中读取所述第一应用层数据包，并向所述上游服务器发送。

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

接收来自上游服务器的第二数据流；

将所述第二数据流包含的第二应用层数据包缓存至第二缓存；

当所述QUIC协议栈可写时，向所述QUIC协议栈发送所述第二缓存中的所述第二应用层数据包，以使得所述QUIC协议栈处理所述第二应用层数据包并得到第二QUIC报文；

通过所述目标UDP端口向所述客户端设备发送所述第二QUIC报文。

7.根据权利要求6所述的方法，其特征在于，所述当所述QUIC协议栈可写时，向所述QUIC协议栈发送所述第二缓存中的所述第二应用层数据包，包括：

挂钩所述NGINX服务器的第一发送接口，当所述第二应用层数据包的协议类型为HTTP/1.1或HTTP/2.0时，通过所述第一发送接口将所述第二缓存中的所述第二应用层数据包写入所述QUIC协议栈；

挂钩所述NGINX服务器的第二发送接口，当所述第二应用层数据包的协议类型为RTMP时，通过所述第二发送接口将所述第二缓存中的所述第二应用层数据包写入所述QUIC协议栈。

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

所述NGINX服务器的工作进程初始化时，向所述QUIC协议栈注册回调事件，所述回调事件包括流可读事件、流可写事件。

9.根据权利要求1～5任一项所述的方法，其特征在于，所述向所述QUIC协议栈发送所述第一QUIC报文，包括：

挂钩所述目标UDP端口的读事件处理函数；

利用所述读事件处理函数将所述第一QUIC报文发送至所述QUIC协议栈。

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

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

Images