CN116708597B - 一种数据处理方法及装置 - Google Patents

一种数据处理方法及装置 Download PDF

Info

Publication number
CN116708597B
CN116708597B CN202310976140.1A CN202310976140A CN116708597B CN 116708597 B CN116708597 B CN 116708597B CN 202310976140 A CN202310976140 A CN 202310976140A CN 116708597 B CN116708597 B CN 116708597B
Authority
CN
China
Prior art keywords
quic
connection
handle
user
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202310976140.1A
Other languages
English (en)
Other versions
CN116708597A (zh
Inventor
王玲
曹文晖
程博锋
孙梁
褚军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Technologies Co Ltd
Original Assignee
New H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by New H3C Technologies Co Ltd filed Critical New H3C Technologies Co Ltd
Priority to CN202310976140.1A priority Critical patent/CN116708597B/zh
Publication of CN116708597A publication Critical patent/CN116708597A/zh
Application granted granted Critical
Publication of CN116708597B publication Critical patent/CN116708597B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例提供了一种数据处理方法及装置，涉及通信技术领域，该方法包括：利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄，多个套接字接口与预设QUIC协议库关联，预设QUIC协议库中存储有用于建立QUIC连接的函数；当获取到与用户态句柄绑定的目标数据时，将目标数据缓存至预设无锁队列中，并通知目标数据关联的线程处理目标数据。应用本申请实施例提供的技术方案，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率；实现QUIC协议的Socket接口的统一，避免了每个应用程序携带各自的QUIC程序，减少了冗余，减少了学习成本；在QUIC协议的Socket接口设置无锁队列，缓解了流量突发情况下的丢包问题。

Description

一种数据处理方法及装置
技术领域
本申请涉及通信技术领域，特别是涉及一种数据处理方法及装置。
背景技术
QUIC（Quick User Datagram Protocol Internet Connection，快速用户数据报互联网连接）协议是基于UDP（User Datagram Protocol，用户数据报协议）的安全可靠的传输协议，相比于TCP（Transmission Control Protocol，传输控制协议），QUIC协议具备众多优势，被广泛应用于数据处理。但在实际使用中，QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，这导致QUIC协议的数据处理效率较低。
发明内容
本申请实施例的目的在于提供一种数据处理方法及装置，以提高QUIC协议的数据处理效率。具体技术方案如下：
在本申请实施例的第一方面，提供了一种数据处理方法，所述方法包括：
利用事件通知机制，监听快速用户数据报互联网连接QUIC协议的多个套接字接口的用户态句柄，所述多个套接字接口与预设QUIC协议库关联，且所述预设QUIC协议库中存储有用于建立客户端与服务端之间的QUIC连接的创建函数；
当获取到与所述用户态句柄绑定的目标数据时，调用所述目标数据关联的线程处理所述目标数据。
在一些实施例中，在利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄之前，所述方法还包括：
利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；
将所述用户态句柄添加至所述事件通知机制中。
在一些实施例中，所述连接分类包括套接字接口类型、QUIC连接类型和QUIC流连接类型，所述连接函数包括所述套接字接口类型对应的套接字接口函数、所述QUIC连接类型对应的QUIC连接函数、所述QUIC流连接类型对应的创建流函数；
所述利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄，具体包括：
通过所述套接字接口函数，建立套接字接口类型对应的第一用户态句柄；将所述第一用户态句柄与预配置的套接字接口实例绑定；
根据与所述第一用户态句柄绑定的套接字接口实例，配置所述多个套接字接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC线程；
通过所述QUIC连接函数，在所述多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将所述第二用户态句柄与所述QUIC连接绑定；
通过所述创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将所述第三用户态句柄与所述QUIC流连接绑定。
在一些实施例中，所述将所述用户态句柄添加至所述事件通知机制中，具体包括：
将与所述用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使所述内核态通知机制将所述内核态句柄通告给所述事件通知机制；
将所述用户态句柄添加至所述事件通知机制对应的红黑树上，所述红黑树用于记录所述用户态句柄与所述内核态句柄的绑定关系。
在一些实施例中，所述利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄，具体包括：
通过所述事件通知机制调用所述内核态通知机制，以监听所述内核态句柄；
在获取到与所述内核态句柄绑定的数据后，在所述红黑树上搜索所述内核态句柄绑定的用户态句柄。
在一些实施例中，所述调用所述目标数据关联的线程处理所述目标数据，具体包括：
当所述目标数据为待发送数据时，将所述待发送数据缓存至预设无锁队列中，并通知QUIC线程从所述预设无锁队列中读取并发送所述目标数据；
当所述目标数据为接收数据时，将所述接收数据缓存至所述预设无锁队列中，并通知用户线程从所述预设无锁队列中读取所述目标数据。
在本申请实施例的第二方面，提供了一种数据处理装置，所述装置包括：
监听单元，用于利用事件通知机制，监听快速用户数据报互联网连接QUIC协议的多个套接字接口的用户态句柄，所述多个套接字接口与预设QUIC协议库关联，且所述预设QUIC协议库中存储有用于建立客户端与服务端之间的QUIC连接的创建函数；
调用单元，用于当获取到与所述用户态句柄绑定的目标数据时，调用所述目标数据关联的线程处理所述目标数据。
在一些实施例中，所述装置还包括：
创建单元，用于利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；
添加单元，用于将所述用户态句柄添加至所述事件通知机制中。
在一些实施例中，所述连接分类包括套接字接口类型、QUIC连接类型和QUIC流连接类型，所述连接函数包括所述套接字接口类型对应的套接字接口函数、所述QUIC连接类型对应的QUIC连接函数、所述QUIC流连接类型对应的创建流函数；
所述创建单元，具体用于：
通过所述套接字接口函数，建立套接字接口类型对应的第一用户态句柄；将所述第一用户态句柄与预配置的套接字接口实例绑定；
根据与所述第一用户态句柄绑定的套接字接口实例，配置所述多个套接字接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC线程；
通过所述QUIC连接函数，在所述多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将所述第二用户态句柄与所述QUIC连接绑定；
通过所述创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将所述第三用户态句柄与所述QUIC流连接绑定。
在一些实施例中，所述添加单元，具体用于：
将与所述用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使所述内核态通知机制将所述内核态句柄通告给所述事件通知机制；
将所述用户态句柄添加至所述事件通知机制对应的红黑树上，所述红黑树用于记录所述用户态句柄与所述内核态句柄的绑定关系。
在一些实施例中，所述监听单元，具体用于：
通过所述事件通知机制调用所述内核态通知机制，以监听所述内核态句柄；
在获取到与所述内核态句柄绑定的数据后，在所述红黑树上搜索所述内核态句柄绑定的用户态句柄。
在一些实施例中，所述调用单元，具体用于：
当所述目标数据为待发送数据时，将所述待发送数据缓存至预设无锁队列中，并通知QUIC线程从所述预设无锁队列中读取并发送所述目标数据；
当所述目标数据为接收数据时，将所述接收数据缓存至所述预设无锁队列中，并通知用户线程从所述预设无锁队列中读取所述目标数据。
在本申请实施例的第三方面，提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
存储器，用于存放计算机程序；
处理器，用于执行存储器上所存放的程序时，实现上述任一所述的数据处理方法的方法步骤。
在本申请实施例的第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的数据处理方法的方法步骤。
本申请实施例提供的技术方案中，创建了QUIC协议的套接字接口的用户态句柄，利用事件通知机制（如epoll机制），对用户态句柄进行监听。当获取到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据；若未获取到与用户态句柄绑定的目标数据，则不会占用目标数据关联的线程，即目标数据关联的线程可以用于处理其他用户行为，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率。
当然，实施本申请的任一产品或方法并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的实施例。
图1为本申请实施例提供的互联网的网络模型的一种结构示意图；
图2为本申请实施例提供的多个HTTP流复用一个TCP连接的示意图；
图3为本申请实施例提供的数据处理方法的第一种流程示意图；
图4为本申请实施例提供的数据处理方法的第二种流程示意图；
图5为本申请实施例提供的客户端与服务端之间的交互图；
图6为本申请实施例提供的数据处理装置的一种结构示意图；
图7为本申请实施例提供的电子设备的一种结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员基于本申请所获得的所有其他实施例，都属于本申请保护的范围。
Socket（套接字）：网络上的两个应用程序通过一个双向的通信连接实现数据的交换，这个连接的一端为一个Socket。应用程序通过Socket向网络发出请求或应答请求。
TCP（Transmission Control Protocol，传输控制协议）起源于阿帕网，已在互联网领域使用70年。互联网的网络模型如图1所示，包括应用层、传输层、网络层和链路层，网络层即为IP（Internet Protocol，互联网协议）层。
不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。TCP是使用最广泛的传输层协议，传输层又可以称为TCP层，TCP是为了在不可靠的互联网上提供可靠的端到端字节流而专门设计的一个传输协议。互联网与单个网络有很大的不同，因为互联网的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标是能够动态地适应互联网的这些特性，而且具备面对各种故障时的健壮性。
应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP层把数据流分区成适当长度的数据段，报文段的长度受主机连接网络的链路层的MTU（MaximumTransmission Unit，最大传输单元）的限制；之后TCP层把分区得到的数据包传送给IP层，由IP层来通过网络将数据包传送给接收端实体的TCP层。TCP层为了保证不发生丢包，就给每个数据包分配一个序号，同时序号也保证了传送到接收端实体的数据包的按序接收；接收端实体对已成功收到的数据包发回一个相应的ACK（Acknowledge，确认）消息；如果发送端实体在合理的RTT（Round Trip Time，往返时延）内未收到ACK消息，那么对应的数据包就被假设为已丢失，进而该数据包将会被进行重传。TCP用一个校验和函数来检验数据包是否有错误；在发送和接收时都要计算校验和，保障数据传输可靠。
使用TCP协议进行数据传输，存在如下缺点：
1、协议僵化。
从TCP诞生至今，网络环境发生了巨大变化，TCP中的一些原始设计已不适用于当前的网络环境。但TCP在内核中实现，TCP的升级会牵涉大量的用户设备、服务设备和中间设备等巨量设备的底层系统升级，TCP的迭代更新困难重重，进展迟缓。
2、握手过程较长。
TCP建立连接需要经过三次握手，过程耗时，对于基础时延大、大量短连接的场景影响非常大，且无法消除。
3、数据安全性问题。
TCP可以使用SSL（Security Socket Layer，安全套接字层）、TLS（TransportLayer Security，安全传输层）等协议加密报文载荷，但TCP头部没有保护，依然存在较大的安全风险。
4、不支持连接迁移。
TCP连接以IP地址和端口号作为连接标识符，但由于移动终端、NAT（NetworkAddress Translation，网络地址转换）重绑定等场景中IP地址和端口号可能发生改变，这会导致TCP连接断开。
5、拥塞控制算法不灵活。
TCP使用内核拥塞控制算法，升级困难，难以优化。并且，TCP通过系统设置确定整个系统所使用的拥塞控制算法，无法根据不同应用灵活调节。
6、无法进行不可靠的数据传输。
TCP必须传输可靠的字节流，如果某些应用同时有可靠数据和不可靠数据的传输，就需要同时使用TCP和UDP（User Datagram Protocol，用户数据报协议）协同传输，这增加了Socket资源的开支，也给控制增加了难度。
7、队头阻塞。
HTTP（Hyper Text Transfer Protocol，超文本传输协议）是万维网的基础协议，是应用层的协议，通过TCP连接或TLS加密的TCP连接传输数据。当HTTP通过TCP进行数据请求和响应时，通常浏览器与一个域名之间建立6-8个TCP连接，过多的连接会大量消耗服务端资源，并且由于TCP慢启动的存在，连接建立时传输速度低下。而通过HTTP/2这些上层协议，多个HTTP流复用少量TCP连接，则存在队头阻塞问题。如图2所示的多个HTTP流复用一个TCP连接的示意图，发送端向接收端发送的流1-流4为HTTP流，复用一个TCP连接，当流1-流4中某个HTTP流的某个数据段丢失，如图2中的流2丢失了一个数据段，则该丢失的数据段之后的数据段（如流3和流4的数据段）即使到达接收端，接收端也不会将这些数据段读上来，只能阻塞，等前面的数据段（如该丢失的数据段）读上来，才会将这些数据段按字节流顺序读上来。这浪费了宝贵的处理时间和计算资源。
为解决TCP的队头阻塞、拥塞控制算法不灵活、握手过程较长等问题，提出了QUIC（Quick User Datagram Protocol Internet Connection，快速用户数据报互联网连接）协议。QUIC协议是基于UDP的安全可靠的传输协议，是一种基于连接的有状态的SERVER-CLIENT（服务端-客户端）通用传输协议。相比于TCP，QUIC协议工作在传输层，具备以下优势：
1、自带多路复用。应用程序可以通过QUIC流传输可靠用户数据，一条QUIC连接中可以起多条QUIC流，每条QUIC流相互独立，从而避免TCP中发生的队头阻塞问题。
2、支持连接迁移。QUIC协议将CID（Connection Identify，连接标识）作为连接标识符，而非像TCP使用IP地址与端口号作为连接标识符，严格绑定到单个网络路径，因此，在移动终端、NAT重绑定等情况下，可以保持QUIC连接不断。
3、0 RTT建连。QUIC协议握手过程集合加密与参数协商，简化了TLS握手流程，实现最短支持0 RTT建立连接。
4、天然安全的数据传输。QUIC协议默认嵌入TLS 1.3加密机制，包头加密，报文明文量少并签名认证，保证数据安全可靠传输。
5、精确的RTT测量。TCP为了保证可靠性，使用了基于字节序号的序列号及ACK来确认消息的有序到达，TCP重传数据的序列号和原始的数据的序列号保持一致，会导致重传歧义问题，而QUIC协议使用严格递增的包号代替序列号，准确采样RTT。
6、增强的ACK确认机制。QUIC协议最大支持256个ACK块(TCP最大3个)，在高丢包网络环境下可以加速网络恢复，减少重传量。
7、可插拔拥塞控制算法。QUIC协议实现在用户态，拥塞控制算法不需要操作系统、内核支持，便于部署、升级，支持产品快速迭代。QUIC协议可根据不同应用场景提供更精确、有效的拥塞控制。
8、协议栈用户层实现。QUIC协议实现在用户层，协议优化升级或者定向优化，对于服务来说甚至可以实现热升级，且对于同一用户不同的QUIC连接，可以使用不同的拥塞控制算法。
9、连接上提供数据报传输。如果用户某些数据不需要可靠传输，QUIC连接提供UDP传输，即不可靠传输。
基于以上QUIC协议特征，QUIC协议受到越来越多的关注。在QUIC协议日益流行的同时，QUIC协议仍存在一些问题：
1、集成难度高。
没有统一的QUIC协议栈接口。各大厂商实现了自己的QUIC协议，但QUIC协议栈接口不统一，参数配置复杂，要正确高效地使用QUIC协议门槛高，学习成本高。
网络事件模型需要适配QUIC协议栈做调整，同时还要考虑和TCP的兼容。
大部分QUIC连接实现默认用法是QUIC协议栈处理与用户线程同步，导致用户行为与QUIC协议栈处理行为相互影响严重，导致应用本身性能或QUIC协议栈本身性能难以评估。
2、协议栈性能相对较低。
QUIC协议栈处理同等流量的CPU消耗是TCP的2倍多。UDP数据包在内核接收发送上一直没有得到和TCP数据包一样的优化待遇，UDP收发占据了QUIC协议栈比较大的消耗。QUIC协议加解密过程对CPU消耗也较大。此外QUIC协议实现逻辑合理性、数据包发送pacing（步调）机制等对QUIC协议表现影响非常大。
3、UDP被运营商QoS（Quality of Service，服务质量）限制。
运营商有时会对UDP流量进行QoS限制，这可能导致QUIC有时不通，甚至断连。
QUIC协议栈使用UDP栈收发数据，UDP缓存与QUIC流量控制不存在直接关系。当流量突发时，若QUIC协议栈没有及时将数据读取上来，UDP栈可能出现大量丢包；若QUIC协议栈被用户线程阻塞，在流量突发时UDP栈也很可能出现大量丢包。
为解决上述问题，本申请实施例提供了一种数据处理方法，该方法可以应用于QUIC协议的客户端或服务端。该方法中，利用事件通知机制，监听QUIC协议的套接字（Socket）接口的用户态句柄，其中，Socket接口与预设QUIC协议库关联，且预设QUIC协议库中存储有用于建立QUIC连接的创建函数；当监听到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据。
本申请实施例提供的技术方案中，创建了QUIC协议的Socket接口的用户态句柄，利用事件通知机制（如quic epoll机制），对用户态句柄进行监听。当获取到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据；若未获取到与用户态句柄绑定的目标数据，则不会占用目标数据关联的线程，即目标数据关联的线程可以用于处理其他用户行为，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率。另外，QUIC协议的Socket接口与预设QUIC协议库关联，因此，所有QUIC连接可以利用同一预设QUIC协议库实现，实现QUIC协议的Socket接口的统一，不同应用程序可以依赖同一个QUIC协议库，避免每个应用程序携带各自的QUIC程序，减少了冗余，降低了使用QUIC协议门槛，减少了学习成本。
此外，本申请实施例提供的技术方案中，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，相应的减少了因阻塞带来的丢包。
下面通过具体实施例，对本申请实施例提供的数据处理方法进行详细说明。本申请实施例提供的数据处理方法可以应用于电子设备的CPU，电子设备可以为QUIC连接的客户端或服务端，为便于描述，下面以CPU为执行主体进行说明，对此不进行限定。本申请实施例中，带quic_前缀的函数、句柄或线程表示基于QUIC协议的函数、句柄或线程。
参见图3，图3为本申请实施例提供的数据处理方法的第一种流程示意图，该方法包括如下步骤S31-步骤S32。
步骤S31，利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄，多个套接字接口与预设QUIC协议库关联，且预设QUIC协议库中存储有用于建立客户端与服务端之间的QUIC连接的创建函数。
本申请实施例中，事件通知机制为用户态机制，可以为基于quic协议的poll机制（简称为quic_poll机制），也可以为基于quic协议的epoll机制（简称为quic_epoll机制），后续以事件通知机制为quic_epoll机制举例，并不起限定作用。QUIC协议的Socket接口为QUIC连接在电子设备一端的Socket接口，简称为quic_Socket接口。用户态句柄为用户态的文件描述符/索引，对于quic_Socket接口的用户态句柄可以采用quic_fd表示。CPU利用预设QUIC协议库关联创建了quic_fd后，在quic_epoll机制中添加quic_fd。这样，CPU可以利用quic_epoll机制对quic_fd进行监听，即对quic_fd绑定的数据（如携带quic_fd的数据）进行监听。这里，quic_fd绑定的数据可以为CPU需要向对端发送的数据，也可以为对端向CPU发送的数据。
上述quic_Socket接口类似于内核的TCP_Socket接口，提供Socket方法调用，如QUIC协议库中的各种创建函数方法，例如，套接字接口函数（如quic_socket函数）、监听函数（如quic_listen函数）、绑定函数（如quic_bind函数）、QUIC连接函数（如quic_connect函数、quic_accept函数）、创建流函数（如quic_connect_stream函数、quic_accept_stream函数）、发送函数（如quic_send函数、接收函数（如quic_recv函数）、关闭函数（如quic_close函数）等方法。
上述quic_fd可以由QUIC协议的文件系统管理，而非是内核文件系统管理。QUIC协议的文件系统似于内核的文件系统，用于对QUIC文件进行管理。本申请实施例中，CPU运行QUIC协议的文件系统可以调用上述QUIC协议库中的函数，完成QUIC连接的建立、句柄的创建等。QUIC协议的文件系统通过fd表示一个文件，文件可以是通过quic_socket函数创建的QUIC套接字（即套接字接口类型对应的fd），也可以是quic_connect函数或者quic_accept函数之后的QUIC连接fd（即QUIC连接类型对应的fd），还可以是quic_connect_stream函数或quic_accept_stream函数之后的QUIC流连接fd（即QUIC流连接类型对应的fd），以及quic_epoll fd（即quic_epoll机制对应的fd）。QUIC协议的文件系统负责文件的创建、回收、fd的分配、fd与文件建立关联、通过fd获取文件等方法。
步骤S32，当获取到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据。
本申请实施例中，目标数据关联的线程为用户态的线程，可以用于处理QUIC协议的应用数据，也可以用于处理用户行为数据。
quic_Socket接口对获取的数据封装相应的quic_fd，并上送CPU。CPU在获取到一条数据后，对数据进行解析。CPU调用quic_epoll机制，基于解析结果判定该数据是否与quic_epoll机制中监听的quic_fd绑定，若解析结果为该数据与quic_epoll机制中监听的quic_fd绑定，则该数据为目标数据。当quic_epoll机制监听到quic_fd，即监听到目标数据时，quic_epoll机制生成相应的通知，CPU基于quic_epoll机制监听到目标数据的通知，调用目标数据关联的线程处理目标数据。若解析结果为该数据未与quic_epoll机制中监听的quic_fd绑定，则CPU不会占用目标数据关联的线程来等待处理目标数据，这使得CPU可以使用该线程处理用户行为数据等其他数据。
本申请实施例提供的技术方案中，通过事件通知机制，实现异步调用目标数据关联的线程，如上述在事件通知机制中添加目标数据绑定的用户态句柄，在接收到目标数据后，才调用目标数据关联的线程，这样，QUIC协议的Socket接口可以将QUIC协议的处理行为与用户行为分开，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率。在解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，相应的减少了因阻塞带来的丢包。
另外，QUIC协议的Socket接口与预设QUIC协议库关联，因此，所有QUIC连接可以利用同一预设QUIC协议库实现，实现QUIC协议的Socket接口的统一，不同应用程序可以依赖同一个QUIC协议库，避免每个应用程序携带各自的QUIC程序，减少了冗余，降低了使用QUIC协议门槛，减少了学习成本。
在一些实施例中，预设QUIC协议库中还可以存储有连接函数。在执行步骤S31之前，CPU可以利用预设QUIC协议库中存储的连接函数，根据多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；将用户态句柄添加至事件通知机制中，实现事件通知机制对用户态句柄的监听。
本申请实施例中，套接字接口上的连接分类可以包括套接字接口类型、QUIC连接类型和QUIC流连接类型。其中，套接字接口用于建立电子设备本端与对端之间的连接。一个套接字接口上可以创建一个或多个QUIC连接，一个QUIC连接下可以创建一个或多个QUIC流连接。基于连接分类，连接函数可以包括套接字接口类型对应的套接字接口函数（如quic_socket函数）、QUIC连接类型对应的QUIC连接函数（如quic_connect函数、quic_accept函数）、QUIC流连接类型对应的创建流函数（如quic_connect_stream函数、quic_accept_stream函数）。上述连接函数与上述创建函数可以相同，也可以不同。
利用上述连接函数，根据多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄的流程如下：
（1）通过quic_socket函数建立套接字接口类型对应的第一用户态句柄，将第一用户态句柄与预配置的套接字接口实例（如quic_socket实例）绑定。之后，CPU可以根据quic_socket实例配置多个quic_Socket接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC连接对应的QUIC线程。
套接字接口类型对应的用户态句柄（即第一用户态句柄）可以表示为quic_fd。CPU通过quic_socket函数新建一个quic_fd，如fd1，将该fd1与quic_socket数据结构进行绑定。CPU在quic_socket数据结构中填充配置参数，获得quic_socket实例，此时，该quic_socket实例与上述fd1绑定。CPU通过fd1，获取该fd1绑定的quic_socket实例，进而调用监听函数（如quic_listen函数），根据quic_socket实例中的配置参数配置QUIC连接的参数，启动QUIC线程。后续，CPU可以将fd1添加到quic_epoll机制中，由quic_epoll机制监听fd1，即监听quic_Socket接口的数据。
本申请实施例中，当电子设备为服务端时，服务端还可以通过绑定函数（如quic_bind函数）将quic_Socket接口与地址、端口号绑定，便于客户端正确访问服务端。
（2）通过QUIC连接函数，在多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将第二用户态句柄与QUIC连接绑定。
电子设备作为客户端，客户端的CPU通过quic_socket函数新建一个quic_fd（即第二用户态句柄），如fd2，将该fd2与quic_socket数据结构进行绑定，也就是将该fd2与后续建立的QUIC连接进行绑定。客户端的CPU调用QUIC连接函数（如quic_connect函数）启动QUIC线程，通过QUIC线程向服务端发起连接请求，在发起连接请求后，将fd2添加到quic_epoll机制中。对于客户端来说，fd2既是套接字接口类型对应的quic_fd，也是QUIC连接类型对应的quic_fd，因为，客户端中，一个quic_Socket接口上建立一个QUIC连接。
电子设备作为服务端，服务端的CPU通过QUIC线程接收客户端发送的连接请求，基于连接请求，调用连接函数（如quic_accept函数）与客户端建立QUIC连接，并新建一个quic_fd（即第二用户态句柄），如fd3，将该fd3与QUIC连接进行绑定，并将fd3添加到quic_epoll机制中。
本申请实施例中，一个quic_Socket接口上可以建立一个或多个QUIC连接。客户端和服务端在创建QUIC连接以及第二用户态句柄时，服务端的CPU可以对套接字接口的fd1进行监听。当服务端的CPU利用quic_epoll机制监听到fd1关联的连接请求时，可以确定待建立QUIC连接的quic_Socket接口，进而调用相应的线程，使用quic_accept函数，通过quic_Socket接口与客户端建立QUIC连接。通过quic_epoll机制对QUIC连接建立进行监听，进一步解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率，减少了因阻塞带来的丢包。
（3）通过创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将第三用户态句柄与QUIC流连接绑定。
在建立QUIC连接后，CPU调用创建流函数（如quic_connect_stream函数），向对端发送流创建请求，对端调用创建流函数（如quic_accept_stream函数）接收流创建请求，对端与电子设备本端之间建立QUIC流连接，并分别新建一个quic_fd（即第三用户态句柄），如fd4，将该fd4与QUIC流连接进行绑定，并将fd4添加到quic_epoll机制中。
本申请实施例中，一个QUIC连接上可以建立一个或多个QUIC流连接。客户端和服务端在创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄时，客户端和服务端可以分别对quic_Socket接口的fd2和fd3进行监听。当客户端和服务端利用quic_epoll机制监听到的fd2和fd3关联的流创建接请求时，调用相应的线程，建立QUIC流连接。通过quic_epoll机制对QUIC流连接建立进行监听，进一步解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率，减少了因阻塞带来的丢包。
在将第一用户态句柄、第二用户态句柄和第三用户态句柄添加至事件通知机制中后，可以利用事件通知机制，对fd1、fd2、fd3、fd4指示的quic_Socket接口、QUIC连接、QUIC流连接上发送的数据进行异步处理。
例如，在quic_Socket接口创建新的QUIC连接，在QUIC连接下创建新的QUIC流连接。
再例如，发送端（客户端或服务端）调用发送函数（如quic_send函数）在fd4指示的QUIC流连接上发送应用数据，quic_epoll机制监听到fd4关联的应用数据，通知QUIC线程读取并发送该应用数据。接收端（客户端或服务端）的QUIC线程将数据收上来，通过QUIC协议解析得到应用数据，quic_epoll机制监听到fd4关联的该应用数据，通知上层应用（即用户线程）针对该应用数据的可读事件。上层应用基于可读事件，调用接收函数（如quic_recv函数）读取应用数据。
通过上述基于quic_epoll机制的应用数据异步处理，能够解决QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高QUIC协议的数据处理效率，减少因阻塞带来的丢包。
在一些实施例中，为了节约用户态句柄资源，在停止对用户态句柄的监听时，释放用户态句柄，释放用户态句柄与连接的绑定。
例如，CPU根据上层应用需求调用关闭函数（如quic_close函数）发起关闭通知，关闭quic_fd对应的QUIC连接或QUIC流连接，并告知对端关闭。对端收到连接关闭通知，调用QUIC线程关闭对应的QUIC连接或QUIC流连接，并通知上层应用。
本申请实施例中，上述各个quic_函数，如quic_socket函数、quic_connect_stream函数、quic_close函数等，可以位于同一QUIC协议库，即quic_Socket接口关联预设QUIC协议库。这样，一方面应用开发者可以方便地增加QUIC协议支持，另一方面使用统一QUIC Socket接口，不同应用程序可以依赖同一个QUIC协议库，避免每个应用程序携带各自的QUIC程序，减少了冗余，降低了使用QUIC协议门槛，减少了学习成本。
在一些实施例中，为了便于对用户态句柄进行监听。上述将用户态句柄添加至事件通知机制中的流程可以包括：将与用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使内核态通知机制将内核态句柄通告给事件通知机制；将用户态句柄添加至事件通知机制对应的红黑树上，红黑树用于记录用户态句柄与内核态句柄的绑定关系。
本申请实施例中，CPU申请一个内核态句柄，如event_fd，将内核态句柄与用户态句柄绑定，并由用户态句柄建立红黑树。内核态通知机制可以表示为epoll机制。
参考内核epoll实现的quic epoll机制，用于监听文件上的读写事件。quic epoll机制提供quic_epoll_create、quic_epoll_ctl、quic_epoll_wait等方法，分别用于创建quic_epoll fd、监听事件类型、起监听等。quic epoll机制可以同时监听tcp_fd（tcp的句柄，内核态句柄）及quic_fd。本申请实施例中，通过申请一个内核态的event_fd，并将event_fd与quic_epoll fd进行绑定，用户态的quic epoll机制通过调用内核epoll机制对event_fd的监听,来完成对quic_fd的监听。
例如，CPU将quic_fd以及对应的事件添加到quic_epoll fd对应的红黑树上，quic_epoll fd上的事件通过红黑树进行管理排序，该quic_fd被用户线程所监听。当QUIC线程（即QUIC层）有数据需要上层应用接收时，QUIC线程基于quic_epoll机制调用内核态的epoll机制向该quic_epoll fd配对的event_fd写入一个字节，并当QUIC线程向event_fd写入时，用户层触发读、写、关闭或者错误事件。用户层根据需求处理事件。
基于上述内核态句柄，本申请实施例提供了一种数据处理方法，如图4所示，包括如下步骤S41-步骤S43。
步骤S41，通过事件通知机制调用内核态通知机制，以监听内核态句柄。
本申请实施例中，CPU可以利用quid epoll机制调用epoll机制，对event_fd进行监听，即对event_fd绑定的数据（如携带event_fd的数据，或event_fd指示的流上的数据）进行监听。
步骤S42，在获取到与内核态句柄绑定的数据后，在红黑树上搜索内核态句柄绑定的用户态句柄。
在获取到与内核态句柄绑定的数据后，CPU在红黑树上搜索内核态句柄绑定的用户态句柄，即搜索数据所绑定的quid_fd。在搜索到的情况下，表示获取到与quid_fd绑定的目标数据；在未搜索到的情况下，表示未获取到与quid_fd绑定的目标数据。
步骤S43，当获取到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据。与上述步骤S32相同。
本申请实施例中，通过申请内核态的event_fd，实现了对用户态的QUIC协议的数据的监听。另外，TCP数据为内核态数据，可以通过epoll机制直接对TCP数据关联的tcp_fd进行监听，而epoll机制又受本申请实施例中的quic_epoll机制的调用，这使得本申请实施例既支持对QUIC协议的数据的监听，也支持对内核态的TCP数据的监听，扩大了本申请实施例的应用场景，可以实现QUIC协议和TCP之间的灵活切换，保证用户体验。
在一些实施例中，为了进一步降低QUIC协议的丢包，即进一步降低UDP协议的丢包，CPU在quic_Socket接口上提供了缓存队列，即无锁队列。基于无锁队列，上述步骤S32中调用目标数据关联的线程处理所述目标数据，可以为：
（1）当目标数据为待发送数据时，将待发送数据缓存至预设无锁队列中，并通知QUIC线程从预设无锁队列中读取并发送目标数据。
CPU需要向对端发送数据时，在获取到上层应用发送的目标数据时，将目标数据缓存至预设无锁队列中，之后用户线程可以用于处理其他数据；另外，将目标数据缓存至预设无锁队列中时，quic_epoll机制监听到目标数据，进而通知QUIC线程从预设无锁队列中读取并发送目标数据，QUIC线程从预设无锁队列中读取目标数据，并向对端发送目标数据。
（2）当目标数据为接收数据时，将接收数据缓存至预设无锁队列中，并通知用户线程从预设无锁队列中读取目标数据。
在接收对端发送的数据时，CPU利用QUIC线程将目标数据收上来，通过QUIC协议解析，将目标数据缓存至预设无锁队列中；另外，将目标数据缓存至预设无锁队列中时，quic_epoll机制监听到目标数据，进而通知用户线程从预设无锁队列中读取目标数据，用户线程从预设无锁队列中读取目标数据，并处理目标数据。
本申请实施例中，CPU设置无锁队列。当流量突发时，若QUIC线程没有及时将发往对端的数据读出来，或因用户线程被阻塞没有及时将来自对端的数据读上来，CPU可以通过无锁队列，可以快速收取数据，并将数据缓存至无锁队列中，等待上层应用自行读取数据。这可以大大缓解流量突发情况下的丢包问题。
下面结合图5所示的客户端与服务端之间的交互图，对本申请实施例提供的数据处理方法进行详细说明。
步骤S51，服务端调用quic_socket函数，新建一个quic_fd1，将该quic_fd1与quic_socket数据结构进行绑定。
为保证数据处理的安全性，步骤S51在触发epollhup事件后，服务端的quic_Socket接口已关闭或关断情况下执行。
步骤S52，服务端调用quic_bind函数，将quic_Socket接口与地址、端口号绑定，便于客户端正确访问服务端。
为保证数据处理的安全性，步骤S52在触发epollhup事件后，服务端的quic_Socket接口已关闭或关断情况下执行。
步骤S53，服务端调用quic_listen函数，根据quic_fd1获取quic_socket实例，并根据quic_socket实例中的配置参数配置QUIC连接的参数，启动QUIC线程，将quic_fd1添加至quic_epoll机制中进行监听。
为保证数据处理的安全性，步骤S53在触发epollhup事件后，服务端的quic_Socket接口已关闭或关断情况下执行。
步骤S54，客户端调用quic_socket函数，新建一个quic_fd2，将该quic_fd2与quic_socket数据结构进行绑定。
步骤S55，客户端调用quic_connect函数，启动QUIC线程，通过QUIC线程向服务端发起连接请求，在发起连接请求后将quic_fd2添加到quic_epoll机制中。连接请求携带quic_fd1，如图5中的fd。服务端接收到连接请求后，触发可读事件（如epollin事件），基于quic_fd1，在quic_Socket接口上建立QUIC连接。
步骤S56，服务端的QUIC线程收到连接请求后，调用quic_accept函数与客户端建立QUIC连接，并新建一个quic_fd3，将quic_fd3添加到quic_epoll机制中进行监听。quic_fd2和quic_fd3与该QUIC连接绑定，如图5中的cfd。
步骤S57，客户端调用quic_connect_stream函数创建流创建请求，服务端调用quic_accept_stream函数接收流创建请求。流创建请求发生和接收成功后，客户端和服务端分别创建quic_fd4，添加到quic_epoll机制中进行监听。quic_fd4与该QUIC流连接绑定，如图5中的sfd。流创建请求携带quic_fd2，如图5中的cfd。服务端接收到流创建请求后，触发可读事件（如epollin事件），基于quic_fd2，在QUIC连接下建立QUIC流连接。
图5中仅以客户端向服务端发送流创建请求作为示例，并不起限定作用，实际应用中，服务端也可以向客户端发送流创建请求。
步骤S58，客户端调用quic_send函数在quic_fd4指示的QUIC流连接上发送应用数据。quic_Socket接口将应用数据缓存在无锁队列中，通知QUIC线程读取并发送数据。其中，客户端向服务端发送应用数据，服务端接收到应用数据后，触发可读事件（如epollin事件），基于quic_fd4，处理通过QUIC流连接发送的数据。
步骤S59，服务端的QUIC线程将应用数据收上来，然后通过QUIC协议解析将应用数据放到无锁队列，并通知上层应用该可读事件。上层应用可调用quic_recv函数读取无锁队列中的应用数据。
图5中仅以客户端向服务端发送应用数据作为示例，并不起限定作用，实际应用中，服务端也可以向客户端发送应用数据。
步骤S510，客户端或服务端可以根据上层应用需求调用quic_close函数，关闭quic_fd对应的QUIC连接或QUIC流连接,并告知对端连接关闭。对端收到连接关闭通知，QUIC线程关闭对应连接并通知上层应用。
本申请实施例中，客户端侧，在执行步骤S55、步骤S57、步骤S58和步骤S510的过程中，客户端可以使用cfd，执行可写事件（如epollout事件），以创建QUIC流连接，并且在执行步骤S58和步骤S510的过程中，客户端可以使用sfd，执行可写事件，以发送应用数据。
相应的，服务端侧，在执行步骤S56、步骤S57、步骤S59和步骤S510的过程中，服务端可以使用cfd，执行可写事件，以创建QUIC流连接，并且在执行步骤S59和步骤S510的过程中，客户端可以使用sfd，执行可写事件，以发送应用数据。
本申请实施例提供的技术方案中可以达到如下有益效果：
（1）不同的应用程序可以依赖同意QUIC协议库，使用统一的quic_Socket接口，可以方便地增加QUIC协议支持，且避免每个应用程序携带各自的QUIC程序，减少了冗余，降低了使用QUIC协议门槛，减少了学习成本；
（2）通过quic_epoll机制实现异步调用用户线程，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率，减少了因阻塞带来的丢包；
（3）在quic_Socket接口设置了无锁队列，可以快速收取数据，并将数据缓存至无锁队列中，等待上层应用自行读取数据，大大缓解流量突发情况下的丢包问题。
与上述数据处理方法对应，本申请实施例还提供了一种数据处理装置，如图6所示，包括：
监听单元61，用于利用事件通知机制，监听快速用户数据报互联网连接QUIC协议的多个套接字接口的用户态句柄；
调用单元62，用于用于当获取到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据。
在一些实施例中，上述数据处理装置还可以包括：
创建单元，用于利用预设QUIC协议库中存储的连接函数，根据多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；
添加单元，用于将用户态句柄添加至事件通知机制中。
在一些实施例中，连接分类包括套接字接口类型、QUIC连接类型和QUIC流连接类型，连接函数包括套接字接口类型对应的套接字接口函数、QUIC连接类型对应的QUIC连接函数、QUIC流连接类型对应的创建流函数；
创建单元，具体可以用于：
通过套接字接口函数，建立套接字接口类型对应的第一用户态句柄；将第一用户态句柄与预配置的套接字接口实例绑定；
根据与第一用户态句柄绑定的套接字接口实例，配置多个套接字接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC线程；
通过QUIC连接函数，在多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将第二用户态句柄与QUIC连接绑定；
通过创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将第三用户态句柄与QUIC流连接绑定。
在一些实施例中，添加单元，具体可以用于：
将与用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使内核态通知机制将内核态句柄通告给事件通知机制；
将用户态句柄添加至事件通知机制对应的红黑树上，红黑树用于记录用户态句柄与内核态句柄的绑定关系。
在一些实施例中，监听单元，具体可以用于：
通过事件通知机制调用内核态通知机制，以监听内核态句柄；
在获取到与内核态句柄绑定的数据后，在红黑树上搜索内核态句柄绑定的用户态句柄。
在一些实施例中，调用单元，具体可以用于：
当目标数据为待发送数据时，将待发送数据缓存至预设无锁队列中，并通知QUIC线程从预设无锁队列中读取并发送目标数据；
当目标数据为接收数据时，将接收数据缓存至预设无锁队列中，并通知用户线程从预设无锁队列中读取目标数据。
在一些实施例中，套接字接口关联预设QUIC协议库。
本申请实施例提供的技术方案中，创建了QUIC协议的套接字接口的用户态句柄，利用事件通知机制（如epoll机制），对用户态句柄进行监听。当监听到与用户态句柄绑定的目标数据时，调用目标数据关联的线程处理目标数据；若未监听到与用户态句柄绑定的目标数据，则不会占用目标数据关联的线程，即目标数据关联的线程可以用于处理其他用户行为，解决了QUIC协议的处理行为与用户行为可能存在相互阻塞的问题，提高了QUIC协议的数据处理效率。
与上述数据处理方法对应，本申请实施例还提供了一种电子设备，如图7所示，包括处理器71、通信接口72、存储器73和通信总线74，其中，处理器71，通信接口72，存储器73通过通信总线74完成相互间的通信；
存储器73，用于存放计算机程序；
处理器71，用于执行存储器73上所存放的程序时，实现上述任一所述的数据处理方法。
上述电子设备提到的通信总线可以是外设部件互连标准（Peripheral ComponentInterconnect，PCI）总线或扩展工业标准结构（Extended Industry StandardArchitecture，EISA）总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器（Random Access Memory，RAM），也可以包括非易失性存储器（Non-Volatile Memory，NVM），例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器（Central Processing Unit，CPU）、网络处理器（Network Processor，NP）等；还可以是数字信号处理器（Digital SignalProcessor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本申请提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的数据处理方法。
在本申请提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的数据处理方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质（例如固态硬盘Solid State Disk (SSD)）等。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、存储介质和程序产品实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的较佳实施例，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：
利用事件通知机制，监听快速用户数据报互联网连接QUIC协议的多个套接字接口的用户态句柄，所述多个套接字接口与预设QUIC协议库关联，且所述预设QUIC协议库中存储有用于建立客户端与服务端之间的QUIC连接的创建函数；
当获取到与所述用户态句柄绑定的目标数据时，调用所述目标数据关联的线程处理所述目标数据；
所述调用所述目标数据关联的线程处理所述目标数据，具体包括：
当所述目标数据为待发送数据时，将所述待发送数据缓存至预设无锁队列中，并通知QUIC线程从所述预设无锁队列中读取并发送所述目标数据；
当所述目标数据为接收数据时，将所述接收数据缓存至所述预设无锁队列中，并通知用户线程从所述预设无锁队列中读取所述目标数据。
2.根据权利要求1所述的方法，其特征在于，在利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄之前，所述方法还包括：
利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；
将所述用户态句柄添加至所述事件通知机制中。
3.根据权利要求2所述的方法，其特征在于，所述连接分类包括套接字接口类型、QUIC连接类型和QUIC流连接类型，所述连接函数包括所述套接字接口类型对应的套接字接口函数、所述QUIC连接类型对应的QUIC连接函数、所述QUIC流连接类型对应的创建流函数；
所述利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄，具体包括：
通过所述套接字接口函数，建立套接字接口类型对应的第一用户态句柄；将所述第一用户态句柄与预配置的套接字接口实例绑定；
根据与所述第一用户态句柄绑定的套接字接口实例，配置所述多个套接字接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC线程；
通过所述QUIC连接函数，在所述多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将所述第二用户态句柄与所述QUIC连接绑定；
通过所述创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将所述第三用户态句柄与所述QUIC流连接绑定。
4.根据权利要求2所述的方法，其特征在于，所述将所述用户态句柄添加至所述事件通知机制中，具体包括：
将与所述用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使所述内核态通知机制将所述内核态句柄通告给所述事件通知机制；
将所述用户态句柄添加至所述事件通知机制对应的红黑树上，所述红黑树用于记录所述用户态句柄与所述内核态句柄的绑定关系。
5.根据权利要求4所述的方法，其特征在于，所述利用事件通知机制，监听QUIC协议的多个套接字接口的用户态句柄，具体包括：
通过所述事件通知机制调用所述内核态通知机制，以监听所述内核态句柄；
在获取到与所述内核态句柄绑定的数据后，在所述红黑树上搜索所述内核态句柄绑定的用户态句柄。
6.一种数据处理装置，其特征在于，所述装置包括：
监听单元，用于利用事件通知机制，监听快速用户数据报互联网连接QUIC协议的多个套接字接口的用户态句柄，所述多个套接字接口与预设QUIC协议库关联，且所述预设QUIC协议库中存储有用于建立客户端与服务端之间的QUIC连接的创建函数；
调用单元，用于当获取到与所述用户态句柄绑定的目标数据时，调用所述目标数据关联的线程处理所述目标数据；
所述调用单元，具体用于：
当所述目标数据为待发送数据时，将所述待发送数据缓存至预设无锁队列中，并通知QUIC线程从所述预设无锁队列中读取并发送所述目标数据；
当所述目标数据为接收数据时，将所述接收数据缓存至所述预设无锁队列中，并通知用户线程从所述预设无锁队列中读取所述目标数据。
7.根据权利要求6所述的装置，其特征在于，所述装置还包括：
创建单元，用于利用所述预设QUIC协议库中存储的连接函数，根据所述多个套接字接口上的至少一个连接分类，创建与每个连接分类对应的用户态句柄；
添加单元，用于将所述用户态句柄添加至所述事件通知机制中。
8.根据权利要求7所述的装置，其特征在于，所述连接分类包括套接字接口类型、QUIC连接类型和QUIC流连接类型，所述连接函数包括所述套接字接口类型对应的套接字接口函数、所述QUIC连接类型对应的QUIC连接函数、所述QUIC流连接类型对应的创建流函数；
所述创建单元，具体用于：
通过所述套接字接口函数，建立套接字接口类型对应的第一用户态句柄；将所述第一用户态句柄与预配置的套接字接口实例绑定；
根据与所述第一用户态句柄绑定的套接字接口实例，配置所述多个套接字接口上用于建立客户端与服务端之间的QUIC连接的参数，启动QUIC线程；
通过所述QUIC连接函数，在所述多个套接字接口上创建客户端与服务端之间的QUIC连接以及QUIC连接类型对应的第二用户态句柄；将所述第二用户态句柄与所述QUIC连接绑定；
通过所述创建流函数，在客户端与服务端之间的QUIC连接下创建QUIC流连接以及QUIC流连接类型对应的第三用户态句柄；将所述第三用户态句柄与所述QUIC流连接绑定。
9.根据权利要求7所述的装置，其特征在于，所述添加单元，具体用于：
将与所述用户态句柄绑定的内核态句柄添加至内核态通知机制中，以使所述内核态通知机制将所述内核态句柄通告给所述事件通知机制；
将所述用户态句柄添加至所述事件通知机制对应的红黑树上，所述红黑树用于记录所述用户态句柄与所述内核态句柄的绑定关系。
10.根据权利要求9所述的装置，其特征在于，所述监听单元，具体用于：
通过所述事件通知机制调用所述内核态通知机制，以监听所述内核态句柄；
在获取到与所述内核态句柄绑定的数据后，在所述红黑树上搜索所述内核态句柄绑定的用户态句柄。
CN202310976140.1A 2023-08-04 2023-08-04 一种数据处理方法及装置 Active CN116708597B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310976140.1A CN116708597B (zh) 2023-08-04 2023-08-04 一种数据处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310976140.1A CN116708597B (zh) 2023-08-04 2023-08-04 一种数据处理方法及装置

Publications (2)

Publication Number Publication Date
CN116708597A CN116708597A (zh) 2023-09-05
CN116708597B true CN116708597B (zh) 2023-10-24

Family

ID=87831484

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310976140.1A Active CN116708597B (zh) 2023-08-04 2023-08-04 一种数据处理方法及装置

Country Status (1)

Country Link
CN (1) CN116708597B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117938985A (zh) * 2024-03-21 2024-04-26 新华三技术有限公司 一种数据处理方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012152210A1 (zh) * 2011-05-11 2012-11-15 北京奇虎科技有限公司 一种文件操作的执行方法及装置
CN112698963A (zh) * 2020-12-22 2021-04-23 新华三技术有限公司成都分公司 一种事件通知方法及装置
CN114237937A (zh) * 2021-12-17 2022-03-25 威创集团股份有限公司 一种多线程的数据传输方法和装置
CN115552367A (zh) * 2020-06-03 2022-12-30 英特尔公司 存储命令传输的媒介
CN115801770A (zh) * 2023-02-07 2023-03-14 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) 一种基于全用户态quic协议的大文件传输方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9680918B2 (en) * 2014-06-30 2017-06-13 Fortinet, Inc. Socket application program interface (API) for efficient data transactions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012152210A1 (zh) * 2011-05-11 2012-11-15 北京奇虎科技有限公司 一种文件操作的执行方法及装置
CN115552367A (zh) * 2020-06-03 2022-12-30 英特尔公司 存储命令传输的媒介
CN112698963A (zh) * 2020-12-22 2021-04-23 新华三技术有限公司成都分公司 一种事件通知方法及装置
CN114237937A (zh) * 2021-12-17 2022-03-25 威创集团股份有限公司 一种多线程的数据传输方法和装置
CN115801770A (zh) * 2023-02-07 2023-03-14 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) 一种基于全用户态quic协议的大文件传输方法

Also Published As

Publication number Publication date
CN116708597A (zh) 2023-09-05

Similar Documents

Publication Publication Date Title
EP3675432B1 (en) Intelligent and dynamic overlay tunnel formation via automatic discovery of citrivity/sdwan peer in the datapath in a pure plug and play environment with zero networking configuration
US10305904B2 (en) Facilitating secure network traffic by an application delivery controller
Shreedhar et al. Evaluating QUIC performance over web, cloud storage, and video workloads
US10027761B2 (en) Facilitating a secure 3 party network session by a network device
JP5882353B2 (ja) ファイルシステムセッションにおけるマルチコネクションのための方法及びシステム
US8024469B1 (en) System and method for connecting network sockets between applications
Rosen Linux kernel networking: Implementation and theory
WO2023005773A1 (zh) 基于远程直接数据存储的报文转发方法、装置、网卡及设备
US8769021B2 (en) Method and system for light-weight SOAP transport for web services based management
WO2019134383A1 (zh) 控制网络拥塞的方法、接入设备和计算机可读存储介质
BR112020015127A2 (pt) Método, aparelho, e sistema de transmissão de dados
US10367893B1 (en) Method and apparatus of performing peer-to-peer communication establishment
CN116708597B (zh) 一种数据处理方法及装置
WO2021068973A1 (zh) 一种基于应用层协议的数据通信方法及其装置
US20180198870A1 (en) Information processing apparatus, method for controlling the same, non-transitory computer-readable storage medium, and information processing system
CN110417632B (zh) 一种网络通信方法、系统及服务器
Nowlan et al. Reducing latency in Tor circuits with unordered delivery
US10924423B2 (en) Adaptive mechanism to adjust UDT packet size based on actual network condition
EP1575236B1 (en) Connectivity confirmation method for network storage device and host computer
US20210273882A1 (en) Method for discovering intermediate functions and for selecting a path between two pieces of communication equipment
KR101364927B1 (ko) 네트워크의 토렌트 트래픽 선별 차단 방법
US20230130964A1 (en) Communication protocol, and a method thereof for accelerating artificial intelligence processing tasks
Upadhyay et al. Conclusive Analysis and Research on MPTCP Environment
EP1977557A2 (en) Method and system for light-weight soap transport for web services based management
Duchêne Helping the Internet scale by leveraging path diversity

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant