CN117675920A

CN117675920A - 数据传输的方法和装置

Info

Publication number: CN117675920A
Application number: CN202211047101.5A
Authority: CN
Inventors: 吴长冶; 黄黎明; 陆志浩; 任玉鑫; 朱迪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-08-30
Filing date: 2022-08-30
Publication date: 2024-03-08
Also published as: WO2024045857A1

Abstract

本申请实施例提供了一种数据传输的方法和装置。该方法应用于第一服务和第二服务的通信过程中，第一服务调用的协议栈执行如下步骤：获取第一服务与第二服务之间传输的业务报文的第一应用信息，第一应用信息包括应用层信息；根据第一应用信息和第一控制策略库对业务报文进行处理，第一控制策略库用于指示对业务报文的处理方式。本申请实施例的方案能够在数据传输过程中随路实现面向应用的管控，保证了服务访问体验。

Description

数据传输的方法和装置

技术领域

本申请实施例涉及网络通信领域，并且更具体地，涉及一种数据传输的方法和装置。

背景技术

在网络通信过程中，工作在网络协议栈下层(例如，传输层)的模块通常无法感知上层(例如，应用层)的应用信息。对于面向应用的通信场景，需要使用应用的相关信息对数据进行处理，目前主要是通过边车(sidecar)方式将流量劫持到单独的软件中实现的。该方式会导致时延增加，影响用户体验。

以流量治理为例，四层治理的方式主要是基于互联网协议(internet protocol，IP)地址以及端口信息等进行流量治理，不涉及传输层以上的应用信息，无法满足目前面向应用的治理诉求。七层治理的方式是将不同服务之间的流量劫持到治理软件中，治理软件根据应用层的协议信息、IP地址以及端口信息等进行流量治理，根据治理结果在服务与治理软件之间建立通信链路，实现数据传输。上述方式将原本服务之间的直通链路变为三条通信链路，大大增加了时延，影响了服务访问体验。

发明内容

本申请提供一种数据传输的方法和装置，能够在数据传输过程中随路实现面向应用的管控，保证了服务访问体验。

第一方面，提供了一种数据传输的方法，应用于第一服务和第二服务的通信过程中，第一服务调用的协议栈执行如下步骤：获取第一服务与第二服务之间传输的业务报文的第一应用信息，第一应用信息包括应用层信息；根据第一应用信息和第一控制策略库对业务报文进行处理，第一控制策略库用于指示对业务报文的处理方式。

根据本申请实施例的方案，在协议栈中可以根据应用层信息和相关控制策略对业务报文进行处理，即将应用层信息作为一个参考信息以确定对业务报文的具体操作方式，为业务报文的处理提供了更全面的判断依据，实现了面向应用的管控。本申请实施例的方案可以在数据传输过程中随路实现面向应用的管控，无需在系统中建立额外的通信链路，在提高管控效果的同时避免了由于管控而引入的额外时延，保证了服务访问体验。

示例性地，该方法可以由协议栈中的传输层执行。该业务报文可以为传输层获取的数据。业务报文也可以称为业务数据、消息或报文等。

应用层信息可以包括应用层协议的相关信息。示例性地，应用层协议的相关信息可以包括以下至少一项：应用协议类型或应用协议头信息等。

示例性地，第一应用信息还可以包括其他信息。例如，第一应用信息还可以包括传输层协议的相关信息或网络层协议的相关信息。

结合第一方面，在第一方面的一种可能的实现方式中，在获取第一服务与第二服务之间传输的业务报文之前，方法还包括：获取第一服务发起的建链请求，建链请求用于请求在第一服务和第二服务之间建立通信链路；向第一服务返回建链成功的指示信息，在向第一服务返回建链成功的指示信息之前，第一服务和第二服务之间未建立通信链路。

根据本申请实施例的方案，在服务访问过程中，服务发起链路建立请求时，协议栈返回建链成功的指示信息，“欺骗”第一服务已经建链成功，使得第一服务发送业务报文。这样，将真正建链时机推迟到业务报文的发送阶段，在业务报文的发送阶段，协议栈可以获取到业务报文的应用层信息，并基于应用层信息等进行寻址，例如，基于应用层信息确定是否执行建链动作，或者，是否需要调整链路信息等，从而实现面向应用的管控。

结合第一方面，在第一方面的一种可能的实现方式中，获取第一服务发起的建链请求，包括：获取第一服务通过通信socket发起的建链请求，以及该方法还包括：将通信socket标记为第一状态，第一状态用于指示第一服务和第二服务之间未建立通信链路。

结合第一方面，在第一方面的一种可能的实现方式中，根据第一应用信息和第一控制策略库对业务报文进行处理，包括：在第一应用信息满足第一控制策略库中的第一规则的情况下，在第一服务和第二服务之间建立通信链路，第一规则用于指示允许第一服务访问第二服务，通信链路用于传输业务报文。

根据本申请实施例的方案，在协议栈中可以根据应用层信息和第一规则确定是否允许第一服务访问第二服务，即将应用层信息作为一个参考信息以确定是否可以实现服务访问，实现了面向应用的服务访问的管控。

结合第一方面，在第一方面的一种可能的实现方式中，在第一应用信息满足第一控制策略库中的第一规则的情况下，在第一服务和第二服务之间建立通信链路，包括：在第一应用信息满足第一控制策略库中的第一规则和第二规则的情况下，根据第二规则调整业务报文，第二规则用于指示调整业务报文；在第一服务和第二服务之间建立通信链路，通信链路用于传输调整后的业务报文。

根据本申请实施例的方案，在协议栈中可以根据应用层信息和第二规则确定是否需要调整业务报文，即将应用层信息作为一个参考信息以确定是否可以在服务访问的过程中是否需要调整业务报文，提高了面向应用的服务访问的管控效果。

例如，第一服务可以通过通信socket实现数据传输。通信socket中包括该业务报文的链路信息。在第一应用信息满足第二规则的情况下，可以根据第二规则调整该通信socket，并基于调整后的socket在第一服务和第二服务之间建立通信链路。

结合第一方面，在第一方面的一种可能的实现方式中，通信链路建立完成后，清除通信socket的第一状态。

结合第一方面，在第一方面的一种可能的实现方式中，根据第一应用信息和第一控制策略库对业务报文进行处理，包括：在第一应用信息不满足第一规则的情况下，向第一服务返回第一错误信息，第一错误信息用于指示无法向第二服务发送业务报文。

结合第一方面，在第一方面的一种可能的实现方式中，向第一服务返回建链成功的指示信息，包括：提取建链请求的第二应用信息，第二应用信息包括建链请求的链路信息；在第二控制策略库包括第三规则的情况下，向第一服务返回建链成功的指示信息，第三规则与第二应用信息相关。

结合第一方面，在第一方面的一种可能的实现方式中，在第二控制策略库包括第三规则的情况下，向第一服务返回建链成功的指示信息，包括：在第二应用信息满足第三规则的情况下，向第一服务返回建链成功的指示信息。

结合第一方面，在第一方面的一种可能的实现方式中，在第二应用信息不满足第三规则的情况下，向第一服务返回建链失败的指示信息。

结合第一方面，在第一方面的一种可能的实现方式中，业务报文是由第一服务发送至第二服务，以及根据第一应用信息和第一控制策略库对业务报文进行处理，包括：在第一时段内未收到来自第二服务的业务报文的响应信息的情况下，根据第一应用信息和第一控制策略库执行以下至少一项操作：对业务报文执行重传操作，或者，向第一服务返回第二错误信息，第二错误信息用于指示未收到业务报文的响应信息。

在本申请实施例中，第一应用信息包括应用层信息，在数据重传场景下，协议栈可以可以将应用层信息作为一个参考信息用于确定对业务报文的具体操作方式，为业务报文的处理提供了更全面的判断依据，有利于提高对业务报文的处理方式的准确性。这样无需在系统中建立额外的通信链路即可实现面向应用的重传处理，在提高对业务报文的处理方式的准确性的同时避免引入额外时延，保证了服务访问体验。

结合第一方面，在第一方面的一种可能的实现方式中，业务报文是由第二服务发送至第一服务，以及根据第一应用信息和第一控制策略库对业务报文进行处理，包括：在业务报文的序列号出现乱序的情况下，根据第一应用信息和第一控制策略库执行以下至少一项操作：重组序列号或丢弃业务报文。

在本申请实施例中，第一应用信息包括应用层信息，在乱序重组场景下，协议栈可以可以将应用层信息作为一个参考信息用于确定对业务报文的具体操作方式，为业务报文的处理提供了更全面的判断依据，有利于提高对业务报文的处理方式的准确性。这样无需在系统中建立额外的通信链路即可实现面向应用的重组处理，在提高对业务报文的处理方式的准确性的同时避免引入额外时延，保证了服务访问性能。

结合第一方面，在第一方面的一种可能的实现方式中，第一控制策略库包括流量治理的规则。

第二方面，提供了一种数据传输的装置，应用于第一服务和第二服务的通信过程中，该装置可以包括第一服务调用的协议栈。该协议栈包括第一获取单元和第一处理单元。第一收发单元，用于获取第一服务与第二服务之间传输的业务报文的第一应用信息，第一应用信息包括应用层信息。第二处理单元，用于根据第一应用信息和第一控制策略库对业务报文进行处理，第一控制策略库用于指示对业务报文的处理方式。

可选地，协议栈还包括：第二获取单元和第二处理单元。第二获取单元，用于在第一获取单元获取第一服务与第二服务之间传输的业务报文之前，获取第一服务发起的建链请求，建链请求用于请求在第一服务和第二服务之间建立通信链路。第二处理单元，用于向第一服务返回建链成功的指示信息，在向第一服务返回建链成功的指示信息之前，第一服务和第二服务之间未建立通信链路。

可选地，第一处理单元具体用于：在第一应用信息满足第一控制策略库中的第一规则的情况下，在第一服务和第二服务之间建立通信链路，第一规则用于指示允许第一服务访问第二服务，通信链路用于传输业务报文。

可选地，第一处理单元具体用于：在第一应用信息满足第一控制策略库中的第一规则和第二规则的情况下，根据第二规则调整业务报文，第二规则用于指示调整业务报文；在第一服务和第二服务之间建立通信链路，通信链路用于传输调整后的业务报文。

可选地，第一处理单元具体用于：在第一应用信息不满足第一规则的情况下，向第一服务返回第一错误信息，第一错误信息用于指示无法向第二服务发送业务报文。

可选地，第二处理单元具体用于：获取建链请求的第二应用信息，第二应用信息包括建链请求的链路信息；在第二控制策略库包括第三规则的情况下，向第一服务返回建链成功的指示信息，第三规则与第二应用信息相关。

可选地，第二处理单元具体用于：在第二应用信息满足第三规则的情况下，向第一服务返回建链成功的指示信息。

可选地，业务报文是由第一服务发送至第二服务，以及第一处理单元1620具体用于：在第一时段内未收到来自第二服务的业务报文的响应信息的情况下，根据第一应用信息和第一控制策略库执行以下至少一项操作：对业务报文执行重传操作，或者，向第一服务返回第二错误信息，第二错误信息用于指示未收到业务报文的响应信息。

可选地，业务报文是由第二服务发送至第一服务，以及第一处理单元1620具体用于：在业务报文的序列号出现乱序的情况下，根据第一应用信息和第一控制策略库执行以下至少一项操作：重组序列号或丢弃业务报文。

可选地，第一控制策略库包括流量治理的规则。

第三方面，提供了一种数据传输的装置，该装置包括：存储器，用于存储程序；处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行第一方面的任意一种实现方式中的方法。

第四方面，提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行第一方面的任意一种实现方式中的方法。这些计算机可读存储包括但不限于如下的一个或者多个：只读存储器(read-only memory，ROM)、可编程ROM(programmable ROM，PROM)、可擦除的PROM(erasable PROM，EPROM)、Flash存储器、电EPROM(electrically EPROM，EEPROM)以及硬盘驱动器(hard drive)。

第五方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面的任意一种实现方式中的方法。

第六方面，提供一种芯片，该芯片包括处理器与数据接口，其中，处理器通过该数据接口读取存储器上存储的指令，以执行第一方面的任意一种实现方式中的方法。在具体实现过程中，该芯片可以以中央处理器(central processing unit，CPU)、微控制器(microcontroller unit，MCU)、微处理器(micro processing unit，MPU)、数字信号处理器(digital signal processing，DSP)、片上系统(system on chip，SoC)、专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(fieldprogrammable gate array，FPGA)或可编辑逻辑器件(programmable logic device，PLD)的形式实现。

附图说明

图1是应用程序之间的数据传输过程的示意图。

图2是劫持架构下的流量治理场景中服务网格数据面的示意图。

图3是一种服务访问流程的示意图。

图4是本申请实施例的一种协议栈的示意图。

图5是本申请实施例的一种系统架构的示意性框图。

图6是本申请实施例的一种数据传输的方法的示意性流程图。

图7是本申请实施例的一种伪建链构建过程的示意性流程图。

图8是本申请实施例的另一种伪建链构建过程的示意性流程。

图9是本申请实施例的一种数据发送流程的示意图。

图10是本申请实施例的另一种数据发送流程的示意图。

图11是本申请实施例的一种服务访问过程的示意性流程图。

图12是本申请实施例的另一种数据发送流程的示意图。

图13是本申请实施例的一种超时重传过程的示意性流程图。

图14是本申请实施例的一种乱序重组过程的示意性流程图。

图15是本申请实施例的一种数据传输的装置的示意性结构图。

图16是本申请实施例的另一种数据传输的装置的示意性结构图。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行描述。

为了更好地说明本申请实施例的方案，下面对本申请实施例可能涉及的相关术语进行说明。

(1)服务网格(service mesh)

服务网格是云原生的下一代架构，是服务间通信的基础设施层。服务网格用于负责构成云原生应用程序的复杂服务拓扑来实现请求的可靠交付。

(2)边车(sidecar)

Sidecar是一种将应用的功能从应用本身剥离出来作为单独进程的设计模式，允许向应用中无侵入地添加功能，避免为了满足第三方需求而在应用中添加额外的代码。例如，在服务网格中，可以将流量治理以及认证鉴权等工作独立成单独的sidecar进程。

(3)网络协议栈

网络协议栈也可以称为协议栈。协议栈可以为开放式系统互联通信参考模型(open system interconnection reference model，OSI)协议栈或传输控制协议/互联网协议(transmission control protocol/internet protocol，TCP/IP)协议栈。

OSI协议栈从下到上依次为：物理层、链路层、网络层、传输层、会话层、表示层和应用层。TCP/IP协议栈从下到上依次为：主机到网络层、网络互连层、传输层和应用层。

应用程序可以通过套接字(socket)调用操作系统内的协议栈发送数据。

socket是支持TCP/IP的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信所需要的信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址以及远地进程的协议端口。socket可以看成在两个应用程序进行通讯连接中的一个端点，其中一个应用程序将一段信息写入socket中，该socket将这段信息发送给另外一个socket中，使这段信息能传送到另一个应用程序中。

两个需要通信的应用程序通过调用协议栈分别创建socket。应用程序可以调用socket程序完成该操作。当双方的套接字创建完成后，应用程序调用协议栈将双方的socket连接起来。应用程序可以调用连接(connect)程序使得协议栈执行建链流程以完成该操作。

图1示出了一种应用程序之间的数据传输过程的示意图。

在双方的socket连接后，应用程序将数据送入套接字即可实现数据传输。应用程序#1通过socket将数据送入协议栈，协议栈执行消息发送流程以实现数据传输。协议栈中的每一层对于收到的数据都可以封装相应的协议信息。如图1所示，数据在协议栈中从上到下逐层进行处理直至送入网络中。对端的应用程序#2可以调用协议栈接收网络中的数据。从网络中接收到的数据在协议栈中从下到上逐层处理直至送入对应的应用程序#2中。

(4)流量治理

流量治理的核心是解决服务间的高效通信问题，以保证服务访问体验。

流量治理包括负载均衡、路由、访问控制列表(access control list，ACL)、限流、熔断、降级以及重试等。

随着微服务架构的演进，流量治理呈现出两个发展趋势。一个是面向应用治理，即流量治理的逻辑与应用信息(例如，应用协议)强相关，使得流量治理的策略越来越丰富。流量治理的策略也可以称为流量治理的规则。另一个是流量治理的基础设施与应用解耦，这样能够使得应用更轻巧，应用的发展可以聚焦于自身功能的创新。

流量治理通常包括三种实现方式：

1)通过硬件负载均衡器实现流量治理。

基于硬件实现流量治理的方式可支持的协议类型有限，灵活性较低，设备成本较高，均衡节点单一，无法满足复杂的应用流量治理需求。

2)在传输层实现四层流量治理。

N层的流量治理指的是基于网络协议栈中N层以及N层以下的应用信息实现流量治理。N为正整数。

二层流量治理即为基于网络协议栈中链路层以及链路层以下的应用信息实现流量治理。例如，基于媒体访问控制(madia access control，mac)地址实现流量治理。

三层流量治理即为基于网络协议栈中网络层以及网络层以下的应用信息实现流量治理。例如，基于IP地址等实现流量治理。

四层流量治理即为基于网络协议栈中传输层以及传输层以下的应用信息实现流量治理。例如，基于IP地址以及端口(port)等实现流量治理。

对于四层以及四层以下的流量治理方式，无法感知四层以上的应用信息(例如，应用层的协议信息)，无法满足面向应用治理的需求。

3)在应用层实现四层流量治理或七层流量治理。

七层流量治理即为基于网络协议栈中应用层以及应用层以下的应用信息实现流量治理。例如，基于主机(host)、统一资源定位器(uniform resource locator，URL)前缀(prefix)以及域(domain)等实现流量治理。

目前的七层的流量治理通常是基于劫持架构，即将流量劫持到单独的治理软件中实现流量治理。以服务网格为例，每一跳服务访问，时延增加2-3ms，严重影响服务访问体验，难以满足对实时性要求较高的通信场景，例如，直播、游戏等。在高并发可靠性系统中时延增加更加严重。

(5)ACL

ACL是一组IP地址范围或网段，用于控制用户只能从ACL内的IP地址或网段访问网络。ACL可以作为一种基于包过滤的访问控制技术，根据设定的条件对接口上的包进行过滤，使其通过或丢弃。ACL在三层交换机和路由器中得到了广泛的应用。通过使用ACL可以有效地控制用户对网络的访问，进而最大限度地保证网络的安全。

(6)服务质量(quality of service，QoS)

QoS指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力。

随着应用场景的复杂化，软件服务逐步从传统的单体系统向分布式、微服务架构演进。服务之间的通信问题是影响服务体验的一个重要因素。面向应用的通信场景中，相关功能的实现与服务的应用信息(例如，应用协议)强相关。目前主要是通过sidecar方式将流量劫持到单独的软件中以实现相关功能，这样可以使得相关功能的基础设施与应用解耦，避免影响应用。然而该方式会导致时延增加，影响服务体验。

下面以流量治理的场景为例进行说明。

图2示出了劫持架构下的流量治理场景中服务网格数据面的示意图。

如图2所示，在服务网格中，服务通过sidecar实现互通。原本服务之间的通信路径为直通路径。在引入sidecar之后，通信路径转换为3跳通信路径。

以服务#1向服务#2发送数据为例，服务#1调用操作系统(operating system)中的协议栈发送数据。治理软件将流量劫持到sidecar中，根据治理结果将数据转发给服务#2。服务#2调用操作系统中的协议栈从sidecar中接收该数据。

从图2中可以服务之间的通信需要通过多条通信链路实现，同时该过程中还涉及多次用户态-内核态切换，开销较大，导致时延增加。

图3示出了一种服务访问流程的示意图。如图3所示，服务#1对服务#2的访问可以包括如下阶段。

第一阶段，即通信请求阶段，建链请求被劫持到服务#1的sidecar节点。例如，可以通过ip表(iptables)实现劫持。Sidecar节点根据对端ip或port信息进行流量治理规则的匹配，判断本次通信请求是否合法，若是，则在服务#1和该sidecar节点之间建立通信链路，并返回建链成功的消息给服务#1。对于服务#1来说，服务#1认为是与服务#2之间完成了建链操作。

第二阶段，即首包发送阶段，服务A在收到建链成功的消息后，向服务#2发送业务报文，即首包。业务报文被劫持到服务#1对应的sidecar节点。Sidecar节点根据业务报文的内容进行流量治理规则的匹配，判断本次通信是否合法，若是，可以根据流量治理规则从服务#2对应的服务实例中寻找为服务#1提供服务的服务实例，即寻找服务#2的真正地址。在服务#1的sidecar节点与服务#2的sidecar节点(即对端的sidecar节点)之间建立通信链路，调整业务报文的链路信息。服务#2的sidecar节点收到建链请求后，与本地服务(即服务#2)，建立通信链路。这样，服务#1与服务#2之间的3跳通信链路建立完成。服务#1的sidecar节点将业务报文通过服务#2的sidecar节点转发给服务#2。

第三阶段，之后由服务#1发送给服务#2的每个业务报文(即图中的后续包)都可以通过图中的两个sidecar节点转发给服务#2。

通过sidecar方式实现流量治理，能够使得流量治理的基础设施与应用解耦，同时充分利用服务的应用信息(例如，应用协议)，有利于提高流量治理的效果。然而该方式引入了额外的时延开销，影响服务体验。

对于面向应用的方案，如何实现服务之间的高性能的通信成为一个亟待解决的问题。

有鉴于此，本申请实施例提供了一种数据传输的方法，在传输层中引入应用层的相关信息，并基于应用层的相关信息实现数据传输，能够在与应用解耦的同时实现服务之间的高性能的通信，提升服务体验。

图4示出了本申请实施例的一种协议栈的示意图。

在目前的协议栈中，传输层是以传输层以及传输层以下的应用信息作为寻址因子。例如，将IP和port等信息作为传输层的寻址因子。换言之，传输层可以基于IP和port等信息确定通信对端，以实现数据传输。

在本申请实施例中，在传输层中引入应用层信息作为数据处理的依据。例如，如图4所示，在传输层中引入应用协议寻址因子，与IP和port等信息共同作为传输层的寻址因子。换言之，传输层可以基于应用协议以及IP和port等信息确定通信对端，以实现数据传输。

图5示出了本申请实施例的一种系统架构。系统500可以用于执行本申请实施例中的数据传输的方法。

如图5所示，在系统500中，协议栈540可以与策略控制器510对接。

策略控制器510可以用于向控制面适配层520发送配置规则，例如，集群配置或流量治理配置等。控制面适配层520可以用于基于规则模型将接收到的配置规则进行数据格式的转换，以得到控制策略库。其中，规则模型即用于统一规则的格式，即使得经过规则模型转换后的规则能够适配相应的需求，例如，适配协议栈540的需求。

协议栈540中的传输层可以感知应用层的信息，并基于该控制策略库在服务间的数据传输过程中实现对数据的处理，即随流完成数据处理的工作。

示例性地，系统500还可以包括程序管理器530。程序管理器530可以用于管理相关程序的初始化、加载或卸载等逻辑。

下面以流量治理的场景为例对系统500进行示例性说明。

在流量治理的场景中，策略控制器510用于向控制面适配层520发送流量治理配置。规则模型也可以称为跨层QoS模型，用于统一流量治理规则的格式，即使得经过QoS模型转换后的流量治理规则能够适配协议栈540的需求。控制面适配层520可以用于基于跨层QoS模型将接收到的流量治理配置进行数据格式的转换，以得到控制策略库。该控制策略库中的规则即用于实现流量治理。

协议栈540可以在传输层上感知应用层的信息，并基于控制策略库在数据传输的过程中实现流量治理，即随流完成流量治理。示例性地，该协议栈540可以用于执行后文中的伪建链过程和寻址过程。

程序管理器530可以用于管理流量治理程序的初始化、加载或卸载等逻辑。

应理解，服务#1可以调用服务#1对应的协议栈，服务#2可以调用服务#2对应的协议栈。为了便于描述，在本申请实施例的附图中均只示出了一端的协议栈。

需要说明的是，图5所示的系统架构仅为示例，不对本申请实施例的方案构成限定。在实际应用中，可以包括比图5所示的系统架构更多或更少的模块或组件。例如，系统500可以仅包括协议栈540。本申请实施例对此不做限定。

图6示出了本申请实施例提供的一种数据传输的方法的示意性流程图。图6中的方法600可以由协议栈执行。或者，方法600也可以由应用程序调用协议栈执行。该协议栈可以为用户态协议栈。或者，该协议栈也可以为内核态协议栈。内核态协议栈也可以理解为操作系统内的协议栈。示例性地，该协议栈可以为图4所示的协议栈。

方法600包括步骤610至步骤620，下面对步骤610至步骤620进行说明。

610，获取第一服务和第二服务之间传输的业务报文的第一应用信息，第一应用信息包括应用层信息。

620，根据第一应用信息和第一控制策略库对业务报文进行处理。该第一控制策略库用于指示对业务报文的处理方式。

该第一应用信息可以是之前存储的，即步骤610中的“获取”可以理解为“读取”。或者，步骤610可以通过步骤611和步骤612实现(图中未示出)。

611，获取第一服务和第二服务之间传输的业务报文。

612，提取业务报文的第一应用信息。

在本申请实施例中，“服务”可以称为“应用”或“应用程序”。例如，第一服务可以称为第一应用或者第一应用程序。第二服务也可以称为第二应用或第二应用程序。

第一服务和第二服务均可以调用协议栈实现数据传输。为了便于描述和理解，本申请实施例仅以第一服务调用协议栈实现相关功能为例进行说明，不对本申请实施例的方案构成限定。

示例性地，方法600可以由协议栈中的传输层执行。该业务报文可以为传输层获取的数据。业务报文也可以称为业务数据、消息或报文等。

例如，在第一服务向第二服务发送数据的场景中，第一服务调用协议栈将数据发送至第二服务。协议栈中的传输层执行发送流程。业务报文可以为该发送流程中由传输层接收的数据。

再如，在第一服务从第二服务接收数据的场景中，第一服务调用协议栈从第二服务接收数据。协议栈中的传输层执行接收流程(即收包流程)。业务报文可以为该接收流程中由传输层接收的数据。

应用层信息可以包括应用层协议的相关信息。应用层协议也可以称为应用协议。

示例性地，应用层协议的相关信息可以包括以下至少一项：应用协议类型或应用协议头信息等。

例如，应用协议类型可以包括：安全套接字层超文本传输协议(hyper texttransfer protocol over secure socket layer，HTTPS)、google远程过程调用(googleremote procedure call，gRPC)协议、超文本传输协议(hyper text transfer protocol，http)、域名系统(domain name system，DNS)、文本传输协议(file transfer protocol，FTP)以及简单电子邮件传输协议(simple mail transefer protocol，SMTP)等。

例如，应用协议头信息可以包括：http头字段信息，比如http头的url、domain、prefix或hostName等。

例如，传输层协议的相关信息可以包括port信息。

例如，网络层协议的相关信息可以包括ip信息。

为了便于描述，在本申请实施例中，传输层协议的相关信息或网络层协议的相关信息统称为链路信息。例如，在步骤610中，可以获取业务报文的应用层信息和链路信息。

方法600可以应用于不同的通信场景中，以实现不同的任务。第一控制策略库与任务是对应的。示例性地，若方法600用于提高QoS，该第一控制策略库即用于指示对业务报文的处理方式，以提高QoS，在该情况下，第一控制策略库也可以称为第一QoS库。

可选地，第一控制策略库包括至少一个流量治理的规则。

在该情况下，方法600可以应用于执行流量治理的任务。

为了便于描述和说明，本申请实施例中主要以流量治理为例进行说明，不对本申请实施例的方案构成限定。其他需要使用应用层信息实现管控的任务均可以采用本申请实施例的方案。

第一控制策略库中可以包括一个或多个规则。规则也可以称为策略。

示例性地，步骤620可以包括：对第一应用信息和第一控制策略库中的规则进行匹配，在第一应用信息与第一控制策略库中的至少一个规则匹配时，可以根据该至少一个规则指示的处理方式处理该业务报文。

应用信息与控制策略库中的至少一个规则匹配可以理解为，控制策略库包括至少一个与该应用信息相关的规则。换言之，应用信息与控制策略库中的至少一个规则匹配，也可以理解为，应用信息与控制策略库中的至少一个规则相关。

相应地，第一应用信息与第一控制策略库中的至少一个规则匹配，可以理解为，第一控制策略库中包括至少一个与第一应用信息相关的规则。

示例性地，一个应用信息与一个规则匹配可以按照如下方式理解，该应用信息中的参数包括该规则所定义的条件中涉及的参数。例如，应用信息中包括协议类型，控制策略库中的一个规则中的条件为“协议类型为http”，在该情况下，该应用信息与该规则匹配。

进一步地，在第一应用信息满足该至少一个规则的情况下，根据该至少一个规则处理该业务报文。

示例性地，一个应用信息满足一个规则，可以按照如下方式理解，应用信息满足该规则所定义的条件。例如，应用信息中的协议类型为http，一个规则中的条件为“协议类型为http”，该应用信息满足该规则所定义的条件。再如，应用信息中的协议类型为gRPC，一个规则中的条件为“协议类型为http”，该应用信息不满足该规则所定义的条件。相应地，第一应用信息满足该至少一个规则，可以理解为，第一应用信息满足该至少一个规则所定义的条件。根据该至少一个规则处理业务报文，可以理解为，根据该至少一个规则所指示的处理方式处理该业务报文。换言之，在第一应用信息满足该至少一个规则所定义的条件的情况下，根据该至少一个规则所指示的处理方式处理该业务报文，或者说，根据满足条件所对应的处理方式处理该业务报文。

示例性地，若第一应用信息与第一控制策略库中的所有规则均不匹配，可以执行默认的处理流程。默认的处理流程也可以称为常规的处理流程。

换言之，若第一控制策略库中不存在与第一应用信息相关的规则时，可以执行默认的处理流程。

默认的处理流程与方法600的应用场景相关。

示例性地，方法600可以用于在第一服务向第二服务发送数据的场景(后文中的场景1)，若第一应用信息与第一控制策略库中的所有规则均不匹配，则执行常规的发送流程，将第一服务的数据传输给第二服务。以第一控制策略库包括流量治理规则为例，若第一应用信息与第一控制策略库中的所有规则均不匹配，则协议栈可以不进行流量治理，执行常规的发送流程。

示例性地，方法600应用于数据重传的场景(后文中的场景2)，若第一应用信息与第一控制策略库中的所有规则均不匹配，则执行常规的重传流程。

示例性地，方法600应用于乱序重组的场景(后文中的场景3)，若第一应用信息与第一控制策略库中的所有规则均不匹配，则执行常规的乱序重组流程。

根据本申请实施例的方案，在协议栈中可以根据应用层信息和相关控制策略对业务报文进行处理，以实现面向应用的管控。本申请实施例的方案可以在数据传输过程中随路实现面向应用的管控，无需在系统中建立额外的通信链路，在提高管控效果的同时避免了由于管控而引入的额外时延，保证了服务访问性能。例如，在不进行管控的场景中，第一服务和第二服务之间可以建立一条通信链路来实现数据传输，在采用本申请实施例的方案后，第一服务和第二服务之间仍可以仅建立一条通信链路来实现数据传输，同时实现管控。

此外，本申请实施例的方案对服务而言是透明的，即服务对该过程无感知，不影响服务的正常访问。

示例性地，第一控制策略库可以包括流量治理的规则。本申请实施例的方案中，在协议栈中可以基于应用层信息完成七层的流量治理的工作，能够使用与应用相关的丰富的流量治理策略实现有效的流量治理，满足了面向应用的流量治理需求。而且，本申请实施例的方案无需在服务之间引入额外的通信链路。换言之，可以在服务之间原本的通信基础上叠加流量治理的任务的实现，在实现流量治理的同时，保证了服务之间的通信效率，避免由于流量治理而引入额外时延，有利于提高服务访问性能。

为了更好地说明本申请实施例的方案，下面结合几种常见的通信场景(场景1、场景2和场景3)对本申请实施例的方案进行说明。

场景1

场景1为第一服务访问第二服务的通信场景。在该场景中，该业务报文可以为第一服务向第二服务发送的数据。

在一些通信场景下，例如，传输层协议为TCP协议的通信场景下，服务之间的数据传输需要基于通信链路实现。以第一服务向第二服务发送数据为例，若第一服务向第二服务发送数据之前，第一服务和第二服务之间未建立通信链路，第一服务会先发起通信，以便在第一服务和第二服务之间建立通信链路。例如，若步骤610至步骤620中的业务报文为第一服务向第二服务首次发送数据，在执行步骤610至步骤620之前需要先在第一服务和第二服务之间建立通信链路，然后通过该通信链路传输数据。

在本申请实施例的方案中，响应于第一服务发起的通信请求，协议栈通知第一服务建链成功，但不建立通信链路。

可选地，方法600还包括步骤601和步骤602(图6中未示出)。

601，获取第一服务发起的建链请求，该建链请求用于请求在第一服务和第二服务之间建立通信链路。

602，向第一服务返回建链成功的指示信息。在向第一服务反馈建链成功的指示信息之前，第一服务和第二服务之间未建立通信链路。

“建链”即建立通信链路。在步骤602中，协议栈响应于该建链请求，向第一服务返回通信链路已建立完成的指示信息，但实际上并未建立通信链路。

在向第一服务返回建链成功的指示信息时，第一服务和第二服务之间不存在响应于该建链请求而建立的通信链路。

第一服务向第二服务发起通信时，调用协议栈执行建链流程，协议栈通过伪建链的方式“欺骗”第一服务已经建链成功，使得第一服务认为第一服务与第二服务之间的通信链路已经建立完成，可以向第二服务发送数据。但实际上，系统中并未真正建立通信链路。

进一步地，在步骤601中，获取第一服务通过通信socket发起的建链请求。在步骤602中可以将通信socket标记为第一状态。第一状态用于指示第一服务和第二服务之间未建立通信链路。

具体地，第一服务创建通信socket，调用协议栈请求将第一服务的通信socket和第二服务的通信socket连接起来，即请求在第一服务和第二服务之间建立通信链路。示例性地，第一服务可以向第二服务的虚拟IP(virtual ip，VIP)调用connect；协议栈响应于第一服务对connect的调用，执行步骤601和步骤602。

示例性地，第一状态可以称为伪建链状态。

作为一个示例，将通信socket标记为第一状态可以为在通信socket数据结构中扩展伪建链标志，以指示该通信socket为伪建链状态。或者，也可以通过通信socket数据结构中的原有字段标记伪建链状态。本申请实施例对此不作限定。

通信socket为伪建链状态，也可以理解为，该socket对应的通信链路为伪建链状态，即此时并未建立真实的通信链路。

可选地，步骤602包括：提取建链请求的第二应用信息，在第二控制策略库包括第三规则的情况下，向第一服务返回建链成功的指示信息。第二应用信息包括链路信息。第三规则与第二应用信息相关。

或者说，步骤602包括：提取建链请求的第二应用信息，向第一服务返回建链成功的指示信息。在向第一服务返回建链成功的指示信息之前，第二处控制策略库中包括第三规则。

示例性地，链路信息可以包括IP或port信息等。

第二控制策略库中可以包括一个或多个规则。

第三规则与第二应用信息相关，即第三规则与第二应用信息匹配。“第三规则”中的“第三”仅用于限定第二控制策略库中与第二应用信息相关的规则，不具有其他限定作用。换言之，第三规则可以是第二控制策略库中与第二应用信息相关的任意规则。在第二控制策略库中，与第二应用信息相关的规则均可以称为第三规则。

第二控制策略库中可以包括一个第三规则，也可以包括多个第三规则。

换言之，对第二应用信息与第二控制策略库中的规则进行匹配，在第二应用信息与第二控制策略库中的至少一个规则匹配时，向第一服务返回建链成功的指示信息。

示例性地，第二应用信息与第三规则匹配可以按照如下方式理解，第二应用信息中的参数包括第三规则涉及的参数。例如，第二应用信息包括IP，第二控制策略库中的涉及IP的规则可以作为第三规则。

进一步地，若第二应用信息与第二控制策略库中的所有规则均不匹配，可以执行默认的建链流程。例如，默认的建链流程可以为在第一服务和第二服务之间建立通信链路。再如，默认的建链流程可以为与代理程序建立通信链路。

换言之，若第二控制策略库中不包括与第二应用信息相关的规则时，可以执行默认的建链流程。例如，通过connect流程在第一服务和第二服务之间建立通信链路。

可选地，第二控制策略库包括至少一个流量治理的规则。例如，第二控制策略库可以包括限流规则或服务监听规则等。

在该情况下，方法600可以用于执行流量治理的任务。

示例性地，若第二应用信息与第二控制策略库中的所有流量治理规则均不匹配，则不在协议栈中进行流量治理，执行默认的建链流程。例如，基于建链请求的链路信息在第一服务和第二服务之间建立通信链路。

需要说明的是，第一控制策略库与第二控制策略库可以是相同的，也可以是不同的。第一控制策略库与第二控制策略库相同可以理解为第一控制策略库中的所有规则与第二控制策略库中的所有规则相同。第一控制策略库与第二控制策略库不同，可以理解为，第一控制策略库中的规则与第二控制策略库中的规则不完全相同。

可选地，在第二控制策略库包括第三规则的情况下，向第一服务返回建链成功的指示信息，包括：在第二应用信息满足第三规则的情况下，向第一服务返回建链成功的指示信息。

或者说，向第一服务返回建链成功的指示信息。在向第一服务返回建链成功的指示信息之前，第二应用信息满足第三规则。

进一步地，在第二应用信息不满足第三规则的情况下，向第一服务返回建链失败的指示信息。

该建链失败的指示信息也可以理解为访问失败的指示信息。

或者说，向第一服务反馈建链失败的指示信息。在向第一服务返回建链失败的指示信息之前，第二应用信息不满足第三规则。

第二应用信息满足第三规则，也可以称为校验成功。第二应用信息不满足第三规则，也可以称为校验失败。

示例性地，若第二控制策略库包括多个第三规则，可以在第二应用信息满足所有第三规则所定义的条件的情况下，向第一服务返回建链成功的指示信息；否则，向第一服务返回建链失败的指示信息。

在一种可能的实现方式中，在方法600包括步骤601至步骤602的情况下，第一服务在收到建链成功的指示信息后，可以向第二服务发送数据。该数据可以为步骤610中的业务报文。

步骤601和步骤602可以称为伪建链过程。步骤610至步骤620可以称为数据发送过程。

示例性地，伪建链过程可以通过在connect建链流程中增加伪建链逻辑(即步骤602)实现，参见后文中的图7或图8。例如，在建链流程基于链路信息进行上述规则匹配，根据匹配结果确定是否执行建链动作。

作为一种示例，可以通过在目前的建链流程中挂载能够实现该伪建链逻辑的扩展的伯克利数据包过滤器(extended berkeley packet filter，ebpf)程序实现上述伪建链过程。

作为一种可能的实现方式，在需要利用应用层信息进行管控的场景中可以执行上述伪建链的过程。在需要利用传输层及以下协议层的信息进行管控的场景中，可以根据第二应用信息和第二控制策略库对业务报文进行处理，例如，确定是否建立通信链路，以及是否需要对业务报文进行修改。

以流量治理场景为例，在需要利用应用层信息进行流量治理时，即需要进行七层的流量治理时，可以在协议栈中执行上述伪建链的过程，然后基于业务报文的应用层信息等进行流量治理。在需要利用传输层及以下协议层的信息进行流量治理时，即需要进行四层的流量治理时，可以在协议栈中基于链路信息进行流量治理。

图7示出了一种伪建链构建过程的示意性流程图。图7所示的流程可以视为步骤601和步骤602的一种具体实现方式，具体描述可以参考步骤601和步骤602。下面结合图7对步骤601和步骤602进行示例性说明。

如图7所示，协议栈中可以包括链路建立模块701、信息提取模块702和规则匹配模块703。

示例性地，上述全部模块可以位于传输层中。

可替换地，上述部分模块可以位于传输层中，例如，链路建立模块701可以位于传输层中。

作为一种示例，该多个模块可以以多个进程的方式实现。

步骤1，服务#1(第一服务的一例)向服务#2(第二服务的一例)发起通信请求。服务#1创建通信socket，并向服务#2的VIP调用connect。响应于该调用请求，协议栈触发了伪建链流程，信息提取模块702可以从链路建立模块701中提取建链请求的第二应用信息。规则匹配模块703基于第二控制策略库对第二应用信息进行规则匹配。链路建立模块701根据规则匹配的结果执行相应操作。示例性地，协议栈具体可以执行如下步骤。

步骤2，信息提取模块702从链路建立模块701中提取该请求的第二应用信息，例如，链路信息。

步骤3，规则匹配模块703对第二应用信息和第二控制策略库中的规则进行匹配。

若未匹配上任何规则，即匹配失败，则执行步骤4。若匹配上至少一个规则(第三规则的一例)，即匹配成功，执行步骤5。

步骤4，规则匹配模块703向链路建立模块701返回匹配失败的指示信息。

链路建立模块701可以执行常规的建链流程，例如，在服务#1和服务2#之间建立通信链路以实现后续的报文传输。

步骤5，规则匹配模块703根据匹配的至少一个规则对第二应用信息进行校验。

若校验成功，则执行步骤6。若校验失败，则执行步骤8。

步骤6，规则匹配模块703向链路建立模块701返回校验成功的指示信息。

步骤7，链路建立模块701根据校验成功的指示信息，将通信socket标记为伪建链状态，向服务#1返回建链成功的指示信息。

步骤8，规则匹配模块703向链路建立模块701返回校验失败的指示信息。

步骤9，链路建立模块701根据校验失败的指示信息，向服务#1返回建链失败的指示信息。

需要说明的是，服务#1可以调用服务#1对应的协议栈，服务#2可以调用服务#2对应的协议栈。为了便于描述，在本申请实施例的附图中均只示出了一端的协议栈。以图7为例，图7中仅示出了服务#1对应的协议栈，没有示出服务#2对应的协议栈。这并非限定服务#1和服务#2共享协议栈。在实际应用场景中，服务#1和服务#2可以共享协议栈，也可以不共享协议栈，本申请实施例对此不做限定。

应理解，图7中的各个模块以及各个模块执行的操作仅为示例，不对本申请实施例的方案构成限定。例如，步骤601和步骤602也可以由同一个模块执行。

图8示出了本申请实施例的另一种伪建链构建过程的示意性流程。图8所示的流程可以视为步骤601和步骤602的一种具体实现方式，具体描述可以参考步骤601和步骤602。下面结合图8对步骤601和步骤602进行示例性说明。图8所示的流程可以由一个模块执行。

服务#1(第一服务的一例)向服务#2(第二服务的一例)发起通信请求。服务#1创建通信socket，并向服务#2的VIP调用connect。响应于该调用请求，协议栈触发了伪建链流程。示例性地，协议栈具体可以执行如下步骤。

801，提取建链请求的第二应用信息，例如，链路信息。

802，对第二应用信息和第二控制策略库中的规则进行匹配。

若匹配失败，则执行步骤803。若匹配成功，执行步骤804。

803，执行常规的建链流程。例如，在服务#1和服务2#之间建立通信链路以实现后续的报文传输。

804，根据匹配的规则对第二应用信息进行校验。

若校验成功，则执行步骤805。若校验失败，则执行步骤806。

805，向服务#1返回建链成功的指示信息。将通信socket标记为伪建链状态。

806，向服务#1返回建链失败的指示信息。

应理解，以上仅为伪建链构建过程的一种可能的实现方式，不对本申请实施例的方案构成限定。

第一服务收到步骤602返回的建链成功的指示信息的情况下，可以向第二服务发送数据。协议栈执行步骤610至步骤620。在该数据发送流程中，基于第一应用信息执行寻址操作，即确定第二服务的真实地址，或者说，确定业务报文的真实链路信息。该寻址操作可以通过数据发送流程中的规则匹配实现。在数据发送流程中，规则匹配校验成功，即为寻址成功。寻址成功后，即可根据链路信息实现数据传输。规则匹配校验失败，即寻址失败。寻址失败后可以结束本次数据发送流程。

下面对该数据发送流程进行具体说明。

示例性地，步骤620包括：在第一服务和第二服务之间建立通信链路；在通信链路上传输业务报文。

在第一服务和第二服务之间不存在通信链路，但第一服务接收到建链成功的指示信息的情况下，步骤620可以按照上述方式执行。

例如，在第一服务的通信socket被标记为第一状态的情况下，步骤620可以按照上述方式执行。

可选地，步骤620包括：在第一应用信息满足第一控制策略库中的第一规则的情况下，在第一服务和第二服务之间建立通信链路；在通信链路上传输业务报文。第一规则与第一应用信息相关。

第一规则与第一应用信息相关，即第一规则与第一应用信息匹配。

或者说，基于第一规则对第一应用信息进行校验，校验成功的情况下，在第一服务和第二服务之间建立通信链路；在通信链路上传输业务报文。

第一应用信息满足第一规则，即为校验成功。第一应用信息不满足第一规则，即为校验失败。

可选地，第一规则用于指示允许第一服务访问第二服务。即第一规则为与第一应用信息相关的用于指示允许第一服务访问第二服务的规则。具体地，第一应用信息满足第一规则时，第一规则指示允许第一服务访问第二服务。

或者说，第一规则用于确定第一服务和第二服务之间是否能够互通。

或者说，第一规则用于指示允许业务报文的发送。即第一规则为与第一应用信息相关的用于指示允许业务报文的发送的规则。在第一应用信息满足第一规则的情况下，允许第一服务向第二服务发送业务报文。

进一步地，在第一应用信息不满足第一规则的情况下，向第一服务返回第一错误信息，第一错误信息用于指示无法向第二服务发送业务报文。

第一应用信息与第一规则匹配后，不满足服务互通的规则，则向第一服务返回第一错误信息，用于指示无法向第二服务发送业务报文。

或者说，第一错误信息可以用于通知第一服务无法在第一服务和第二服务之间建立通信链路，即建链失败的指示信息。

第一控制规则库中可以包括一个第一规则，也可以包括多个第一规则。

示例性地，步骤620可以包括：在第一应用信息满足第一控制规则库中的所有第一规则的情况下，在第一服务和第二服务之间建立通信链路；在通信链路上发送业务报文。

可选地，步骤620可以包括：在第一应用信息满足第一控制策略库中的第一规则和第二规则的情况下，根据第二规则调整该业务报文，在第一服务和第二服务之间建立通信链路；在通信链路上发送调整后的业务报文。

第二规则与第一应用信息相关，即第二规则与第一应用信息匹配。

可选地，第二规则用于指示调整业务报文。即第二规则为与第一应用信息相关的用于指示调整业务报文的规则。具体地，第一应用信息满足第二规则时，根据第二规则调整业务报文。

示例性地，第二规则用于指示修改以下至少一项：业务报文的链路信息或业务报文的应用层信息等。

例如，第二规则用于指示修改业务报文的链路信息，在第一应用信息满足第二规则的情况下，可以根据第二规则调整该业务报文的链路信息，并根据调整后的链路信息在第一服务和第二服务之间建立通信链路。

如前所述，第一服务可以通过通信socket实现数据传输。通信socket中包括该业务报文的链路信息。在第一应用信息满足第二规则的情况下，可以根据第二规则调整该通信socket，并基于调整后的socket在第一服务和第二服务之间建立通信链路。

示例性地，根据第二规则调整该业务报文的链路信息，可以包括：根据第一应用信息和第二规则确定第二服务中的目标第二服务实例，目标第二服务实例用于为第一服务提供服务；根据目标第二服务实例的地址信息调整该链路信息。

目标第二服务实例即为真正提供服务的对端。根据第一应用信息和第二规则确定第二服务中的目标第二服务实例，也即根据第一应用信息和第二规则寻址到真正提供服务的对端。第一应用信息包括应用层信息，这样，可以在协议栈中根据应用层信息实现寻址。

若第一应用信息满足第一规则，且不满足第二规则，则无需修改业务报文，基于业务报文原本的链路信息在第一服务和第二服务之间建立通信链路，在该通信链路上发送业务报文。

可选地，通信链路建立完成后，可以清除通信socket的第一状态。

在上述数据发送流程中，规则匹配的过程也可以视为基于应用层信息的寻址过程。若上述寻址过程是在传输层完成的，则该过程也可以称为基于应用层信息的四层寻址过程，也即应用层信息和链路信息可以共同作为寻址因子，实现跨层寻址，以确定目标服务的真实地址。规则匹配过程中的校验成功即为寻址成功。寻址成功后即可建立通信链路，并发送业务报文。

图9示出了本申请实施例提供的数据发送流程的示意图。在图9所示的数据发送流程中实现基于应用层信息的寻址。图9所示的流程可以视为步骤610和步骤620的一种具体实现方式，具体描述可以参考场景1中的上述步骤610和步骤620的相关描述。下面结合图9进行示例性说明。

如图9所示，协议栈中可以包括发送模块901、信息提取模块902、规则匹配模块903和链路建立模块904。其中，信息提取模块902和图7中的信息提取模块702可以相同，也可以不同。规则匹配模块903和图7中的规则匹配模块703可以相同，也可以不同。链路建立模块904和图7中的链路建立模块701可以相同，也可以不同。

示例性地，上述全部模块可以位于传输层中。

可替换地，上述部分模块可以位于传输层中，例如，发送模块901和链路建立模块904可以位于传输层中。

作为一种示例，该多个模块可以以多个进程的方式实现。

步骤1，服务#1(第一服务的一例)向服务#2(第二服务的一例)发送业务数据。服务#1调用send。响应于该请求，协议栈触发数据发送流程。信息提取模块902可以从发送模块901中提取业务报文的第一应用信息。规则匹配模块903基于第一控制策略库对第一应用信息进行规则匹配。链路建立模块904和发送模块901根据规则匹配的结果执行相应操作。示例性地，协议栈具体可以执行如下步骤。

步骤2，信息提取模块902从发送模块901中提取该业务报文的第一应用信息，例如，应用层信息。

步骤3，规则匹配模块903对第一应用信息和第一控制策略库中的规则进行匹配。

若未匹配上第一规则，即匹配失败，则执行步骤4。若匹配上第一规则，即匹配成功，执行步骤5。

步骤4，规则匹配模块903向链路建立模块904返回匹配失败的指示信息。

链路建立模块904可以执行常规的建链流程，例如，基于该业务报文的链路信息在服务#1和服务2#之间建立通信链路。发送模块901可以执行常规的发送流程，在该通信链路上发送业务报文。

步骤5，规则匹配模块903根据第一规则对第一应用信息进行校验。

若校验成功，则执行步骤6。若校验失败，则执行步骤9。

若第一应用信息匹配上第二规则，可以根据第二规则对第一应用信息进行校验。

步骤6，规则匹配模块903向链路建立模块904返回校验成功的指示信息。

示例性地，若第二应用信息满足第二规则，根据第二规则需要对链路信息进行调整，规则匹配模块903还可以向链路建立模块904返回调整后的链路信息(图中未示出)。

步骤7，链路建立模块904在服务#1和服务#2之间建立通信链路。

在通信链路建立完成后，可以清除socket的伪建链状态。

步骤8，发送模块901可以在该通信链路上发送业务报文。

示例性地，若第二应用信息满足第二规则，根据第二规则需要对业务报文进行调整，规则匹配模块903还可以向发送模块901返回需要调整的信息(图中未示出)。

步骤9，规则匹配模块903向发送模块901返回校验失败的指示信息。

步骤10，发送模块901向服务#1返回错误信息(即第一错误信息)，结束本次数据发送流程。

应理解，图9中的各个模块以及各个模块执行的操作仅为示例，不对本申请实施例的方案构成限定。例如，步骤610至步骤620也可以由同一个模块执行。

图10示出了本申请实施例的另一种数据发送过程的示意性流程。在图10所示的数据发送流程中实现基于应用层信息的寻址。图10所示的流程可以视为步骤步骤610至步骤620的一种具体实现方式，具体描述可以参考场景1中的上述步骤610至步骤620。下面结合图10对步骤610至步骤620进行示例性说明。图10所示的流程可以由一个模块执行。

服务#1(第一服务的一例)向服务#2(第二服务的一例)发送数据。响应于该请求，协议栈触发了数据发送流程。示例性地，协议栈具体可以执行如下步骤。

1001，提取该业务报文的第一应用信息，例如，应用层信息和链路信息。

1002，对第一应用信息和第一控制策略库中的规则进行匹配。

若未匹配上第一规则，即匹配失败，则执行步骤1003。若匹配上第一规则，即匹配成功，执行步骤1004。

1003，执行常规的发送流程。例如，在服务#1和服务2#之间建立通信链路，在该通信链路上发送业务报文。

1004，根据第一规则对第二应用信息进行校验。

若校验成功，则执行步骤1005。若校验失败，则执行步骤1007。

1005，在服务#1和服务#2之间建立通信链路。

在通信链路建立完成后，可以清除socket的伪建链状态。

示例性地，若第二应用信息满足第二规则，根据第二规则需要对链路信息进行调整，步骤1005中可以基于调整后的链路信息在服务#1和服务#2之间建立通信链路(图中未示出)。

步骤1006，在该通信链路上发送业务报文。

示例性地，若第二应用信息满足第二规则，根据第二规则需要对业务报文进行调整，该通信链路上发送的业务报文可以为调整后的业务报文(图中未示出)。

1007，服务#1返回错误信息(即第一错误信息)，结束本次数据发送流程。

图11示出了本申请实施例提供的一种服务访问过程的示意性流程图。

如图11所示，服务访问可以包括如下三个阶段。

第一阶段，在服务#1访问服务#2时，发起通信请求。

协议栈响应于该请求，执行伪建链流程。

示例性地，协议栈可以根据链路信息确定是否执行建链操作。若链路信息未与控制策略库中的任何规则匹配，则执行常规的建链流程(图11中未示出)，执行建链操作。若链路信息满足与其匹配的规则，则不执行建链工作，返回建链成功的指示信息，并将在socket数据结构中扩展伪建链标志，当前链路为伪建链状态。若链路信息不满足与其匹配的规则，则不执行建链工作，返回建链失败的指示信息。

具体流程可以参考场景1中图6、图7或图8的相关描述，为避免重复，此处不再赘述。

第二阶段，服务#1在收到建链成功的指示信息后，可以向服务#2发送业务报文。

在通信链路建立完成后发送的第一个业务报文可以称为首包，之后发送的业务报文可以称为后续包。或者，在发送业务报文时，当前链路为伪建链状态时，该业务报文也可以称为首包，当前链路为真实的链路时，该业务报文可以称为后续包。

在发送业务报文时，若当前的socket数据结构中包括伪建链标志，则可以触发基于应用层信息的四层寻址操作。若当前的socket数据结构中不包括伪建链标志，则可以执行常规的发送流程，在已建立的通信链路上发送业务报文。

在触发基于应用层信息的寻址操作后，协议栈可以根据应用层信息以及链路信息进行规则匹配，即寻址操作。寻址成功后，即可建立通信链路，在该通信链路上发送业务报文。寻址失败，可以向服务#1返回错误信息(图中未示出)，结束发送流程。

具体流程可以参考场景1中图6、图9或图10的相关描述，为避免重复，此处不再赘述。

图11中仅以第一控制策略库和第二控制策略库为同一个控制策略库作为示例，不对本申请实施例的方案构成限定。

第三阶段，发送后续包。第一服务和第二服务之间的通信链路已经建立，可以按照常规的数据发送流程传输数据，如图11所示。

或者，在发送后续包时，仍可以执行步骤610至步骤620，以便根据第一控制策略库中的规则对后续包进行处理(图中未示出)。

图11所示的服务间可以仅建立一条通信链路，相较于图3的三条链路而言，可以大大减低时延，提高通信效率。

根据本申请实施例的方案，在服务访问过程中，服务发起链路建立请求时，可以“欺骗”服务已经建链成功，使得服务发送业务报文，这样，将真正建链时机推迟到业务报文的发送阶段，在业务报文的发送阶段协议栈可以获取到业务报文的应用层信息，并基于应用层信息等进行寻址，例如，基于应用层信息确定是否执行建链动作，或者，是否需要调整链路信息等，从而实现面向应用的管控。

应理解，上述步骤601和步骤602为可选步骤。示例性地，若第一服务和第二服务之间的数据传输不需要建立通信链路，则步骤601和步骤602可以省略。例如，传输层基于UDP协议传输数据，不需要建立通信链路，在该情况下步骤601和步骤602可以省略。

下面以第一服务和第二服务之间的数据传输不需要建立通信链路为例，对数据发送流程进行示例性说明。协议栈执行步骤610至步骤620。在该数据发送流程中，基于第一应用信息执行寻址操作，即确定第二服务的真实地址，或者说，确定业务报文的真实链路信息。该寻址操作可以通过数据发送流程中的规则匹配实现。在数据发送流程中，规则匹配校验成功，即为寻址成功。寻址成功后，即可根据链路信息实现数据传输。规则匹配校验失败，即寻址失败。寻址失败后可以结束本次数据发送流程。

下面对该数据发送流程进行简要说明。

可选地，步骤620包括：在第一应用信息满足第一控制策略库中的第一规则的情况下，向第二服务发送业务报文。第一规则与第一应用信息相关。

可选地，第一规则用于指示允许第一服务访问第二服务。

或者说，第一规则用于指示允许业务报文的发送。

第一规则的相关描述可以参考前文中的描述，此处不再赘述。

示例性地，步骤620可以包括：在第一应用信息满足第一控制规则库中的所有第一规则的情况下，向第二服务发送业务报文。

可选地，步骤620可以包括：在第一应用信息满足第一控制策略库中的第一规则和第二规则的情况下，根据第二规则调整该业务报文，发送调整后的业务报文。

可选地，第二规则用于指示调整业务报文。

例如，第二规则用于指示修改业务报文的链路信息或业务报文的应用层信息等。

第二规则的相关描述可以参考前文的描述，此处不再赘述。

在上述数据发送流程中，规则匹配的过程也可以视为基于应用层信息的寻址过程。若上述寻址过程是在传输层完成的，则该过程也可以称为基于应用层信息的四层寻址过程，也即应用层信息和链路信息可以共同作为寻址因子，以确定目标服务的真实地址。规则匹配过程中的校验成功即为寻址成功。寻址成功后即可发送业务报文。

图12示出了本申请实施例的一种数据发送过程的示意图。

图11和图12的主要区别在于，无需执行伪建链流程以及建链操作。具体描述可以参考图11的相关描述，此处不再赘述。

根据本申请实施例的方案，第一应用信息包括应用层信息，在第一服务访问第二服务的过程中，协议栈可以将应用层信息作为一个寻址因子，例如，将应用层信息和链路信息共同作为传输层的寻址因子。根据第一控制策略库和第一应用信息的匹配结果进行寻址，实现数据传输。这样无需在系统中建立额外的通信链路即可实现面向应用的管控，在提高管控效果的同时避免了由于管控而引入的额外时延，保证了服务访体验。例如，在不进行管控的场景中，第一服务和第二服务之间可以建立一条通信链路来实现数据传输，在采用本申请实施例的方案后，第一服务和第二服务之间仍可以仅建立一条通信链路来实现数据传输，同时实现管控。

以流量治理场景为例，在本申请实施例中，可以在协议栈中基于应用层的信息实现流量治理，确定真正的通信对端，实现数据传输。这样无需在系统中建立额外的通信链路即可实现面向应用的流量治理，在提高流量治理效果的同时避免了由于引入额外的时延，保证了服务访问性能。本申请实施例的方案能够在实现服务网格的功能的同时，使得服务访问时延、吞吐等开销与服务直通场景下的开销基本一致。例如，在400长连接场景下，采用本申请实施例的方案的TP90相较于原生服务网格时延降低，吞吐量提升。资源开销相比开源网格方案，网格引入的内存开销降低一个数量级，CPU几乎无额外开销。

需要说明的是，在场景1中仅以第一服务访问第二服务为例进行说明。在实际场景中，可能是第二服务访问第一服务。在该情况下，第一服务可以调用协议栈执行接收流程。在接收过程中，也可以执行上述步骤610至步骤620，本申请实施例对此不做限定。

场景2

场景2为数据重传的场景。例如，第一服务向第二服务发送业务报文，第二服务未返回该业务报文的响应信息。该响应信息可以为该业务报文的确认信息。

可选地，该业务报文是由第一服务发送至第二服务。步骤620包括：在第一时段内未收到来自第二服务的对该业务报文的响应信息的情况下，根据第一应用信息和第一控制策略库执行以下操作：对业务报文执行重传操作，或者，向第一服务返回第二错误信息，该错误信息用于指示未收到该业务报文的响应信息等。示例性地，重传可以包括：立即重传或延时重传等。

应理解，以上操作仅为示例，在超时未收到响应信息时，根据第一应用信息和第一控制策略库中的规则的匹配情况，协议栈还可以执行其他操作，本申请实施例对此不作限定。

示例性地，在第一应用信息和第一控制策略库中的至少一个规则匹配的情况下，对业务报文执行上述操作。

若第一应用信息和第一控制策略库中的所有规则均不匹配时，即匹配失败，可以执行默认的超时重传流程。

作为一种示例，上述规则匹配的过程可以通过钩子函数实现。匹配失败时，即可退出钩子函数。

在第一应用信息和第一控制策略库中的至少一个规则匹配的情况下，可以根据第一应用信息所满足的规则，对业务报文执行相应的操作。

例如，规则#1用于指示立即重传，规则2#用于指示延时重传，规则3#用于指示返回第二错误信息。在第一应用信息满足规则#1时，执行立即重传。在第一应用信息满足规则#2时，执行延时重传。在第一应用信息满足规则#3时，向第一服务报错。

在本申请实施例中，第一应用信息包括应用层信息，在数据重传场景下，协议栈可以可以将应用层信息作为一个参考信息用于确定对业务报文的具体操作方式，为业务报文的处理提供了更全面的判断依据，有利于提高对业务报文的处理方式的准确性。这样无需在系统中建立额外的通信链路即可实现面向应用的重传处理，在提高对业务报文的处理方式的准确性的同时避免引入额外时延，保证了服务访问性能。

应理解，以上仅以超时重传的场景为例对场景2进行说明。在其他重传场景下，例如快速重传的场景，也可以采用本申请实施例的方法，只要将第一控制策略库中的规则配置为相应的规则即可。

图13示出了一种超时重传过程的示意性流程图。图13所示的流程可以视为图6所示方法的一种具体实现方式，具体描述可以参考场景2中图6的相关描述。下面结合图13对方法600进行示例性说明。

如图13所示，协议栈中可以包括响应超时模块1301、信息提取模块1302、规则匹配模块1303和超时处理模块1304。图13中的信息提取模块1302、图7中的信息提取模块702和图9中的信息提取模块902可以相同，也可以不同。图13中的规则匹配模块1303、图7中的规则匹配模块703和图9中的规则匹配模块903可以相同，也可以不同。响应超时模块1301可以为等待响应的定时器。

示例性地，上述全部模块可以位于传输层中。

可替换地，上述部分模块可以位于传输层中，例如，响应超时模块1301和超时处理模块1304可以位于传输层中。

作为一种示例，该多个模块可以以多个进程的方式实现。

步骤1，服务#1(第一服务的一例)向服务#2(第二服务的一例)发送业务报文。

该业务报文的响应信息未在预定时段内接收到，响应超时模块1301超时。信息提取模块1302提取业务报文的第一应用信息。规则匹配模块1303基于第一控制策略库对第一应用信息进行规则匹配。超时处理模块1304根据规则匹配的结果执行相应操作。示例性地，协议栈具体可以执行如下步骤。

步骤2，该业务报文的响应信息未在预定时段内接收到，响应超时模块1301指示超时。

步骤3，信息提取模块1302提取该业务报文的第一应用信息，例如，应用层信息和链路信息。

步骤4，规则匹配模块1303对第一应用信息和第一控制策略库中的规则进行匹配。

若未匹配上任何规则，即匹配失败，则执行步骤5。若匹配上至少一个规则，即匹配成功，执行步骤6。

步骤5，规则匹配模块1303向超时处理模块1304返回匹配失败的指示信息。

超时处理模块1304可以执行常规的超时重传流程。

步骤6，规则匹配模块1303根据匹配的至少一个规则对第一应用信息进行校验。

规则匹配模块1303可以根据第一应用信息所满足的规则通知超时处理模块1304执行对应的操作。

步骤7，超时处理模块1304根据规则匹配模块返回的信息执行对应的操作，例如，立即重传、延时重传或报错。

应理解，图13中的各个模块以及各个模块执行的操作仅为示例，不对本申请实施例的方案构成限定。例如，上述步骤也可以由同一个模块执行。

场景3

场景3为乱序重组的场景。例如，第二服务向第一服务发送业务报文，业务报文的序列号出现乱序，即数据包的序列号出现乱序。第一服务调用协议栈接收业务报文。

可选地，步骤620包括，根据第一应用信息和第一控制策略库以下至少一项操作：重组序列号或丢弃该业务报文等。

应理解，以上操作仅为示例，在收到的数据包的序列号出现乱序时，根据第一应用信息和第一控制策略库中的规则的匹配情况，协议栈还可以执行其他操作例如，不执行重组序列号。再如，向第一服务返回错误信息，以通知第一服务数据包的序列号出现乱序。再如，向第二服务返回错误信息，以通知第二服务数据包的序列号出现乱序。再如，向第二服务发送指示信息，以通知第二服务重新发送相应的数据包。本申请实施例对此不作限定。

示例性地，在第一应用信息和第一控制策略库中的至少一个规则匹配的情况下，对业务报文执行以下至少一项操作：重组序列号或丢弃。

若第一应用信息和第一控制策略库中的所有规则均不匹配时，即匹配失败，可以执行默认的乱序重组流程。

例如，规则#1用于指示重组序列号，规则2#用于指示丢弃。在第一应用信息满足规则#1时，重组该业务报文的序列号。在第一应用信息满足规则#2时，丢弃该业务报文。

图14示出了一种乱序重组过程的示意性流程图。图14所示的流程可以视为图6所示方法的一种具体实现方式，具体描述可以参考场景3中图6的相关描述。下面结合图14对方法600进行示例性说明。

如图14所示，协议栈中可以包括收包模块1401、信息提取模块1402和规则匹配模块1403。图14中的信息提取模块1402、图13中的信息提取模块1302、图7中的信息提取模块702和图9中的信息提取模块902可以相同，也可以不同。图14中的规则匹配模块1403、图13中的规则匹配模块1303、图7中的规则匹配模块703和图9中的规则匹配模块903可以相同，也可以不同。

示例性地，上述全部模块可以位于传输层中。

可替换地，上述部分模块可以位于传输层中，例如，收包模块1401可以位于传输层中。

作为一种示例，该多个模块可以以多个进程的方式实现。

步骤1，服务#2(第一服务的一例)向服务#1(第二服务的一例)发送业务报文。服务#1调用协议栈接收业务报文。

协议栈收到的数据包出现乱序时，信息提取模块1402提取业务报文的第一应用信息。规则匹配模块1403基于第一控制策略库对第一应用信息进行规则匹配。收包模块1301根据规则匹配的结果执行相应操作。示例性地，协议栈具体可以执行如下步骤。

步骤2，协议栈收到的数据包出现乱序时，信息提取模块1402提取该业务报文的第一应用信息，例如，应用层信息和链路信息。

步骤3，规则匹配模块1403对第一应用信息和第一控制策略库中的规则进行匹配。

若未匹配上任何规则，即匹配失败，则执行步骤4。若匹配上至少一个规则，即匹配成功，执行步骤5。

步骤4，规则匹配模块1403向收包模块1401返回匹配失败的指示信息。

收包模块1401可以执行常规的乱序重组流程。

步骤5，规则匹配模块1403根据匹配的至少一个规则对第一应用信息进行校验。

规则匹配模块1403可以根据第一应用信息所满足的规则通知收包模块1401执行对应的操作。

步骤6，收包模块1401根据规则匹配模块返回的信息执行对应的操作，例如，重组序列号或丢弃。

应理解，图14中的各个模块以及各个模块执行的操作仅为示例，不对本申请实施例的方案构成限定。例如，上述步骤也可以由同一个模块执行。

在本申请实施例中，第一应用信息包括应用层信息，在乱序重组场景下，协议栈可以可以将应用层信息作为一个参考信息用于确定对业务报文的具体操作方式，为业务报文的处理提供了更全面的判断依据，有利于提高对业务报文的处理方式的准确性。这样无需在系统中建立额外的通信链路即可实现面向应用的重组处理，在提高对业务报文的处理方式的准确性的同时避免引入额外时延，保证了服务访问体验。

本申请实施例中以上述3个场景为例对方法600进行了说明，仅仅是为了便于本领域技术人员理解本申请实施例，并非要将本申请实施例限于例示的具体场景。本领域技术人员根据上述场景的例子，显然可以进行各种等价的修改或变化，这样的修改或变化也落入本申请实施例的范围内。在其他需要应用层信息实现管控的场景中，也可以采用本申请实施例的方案。

还可以理解，本申请的各实施例中的方案可以进行合理的组合使用，并且实施例中出现的各个术语的解释或说明可以在各个实施例中互相参考或解释，对此不作限定。

还可以理解，上述各个方法实施例中，由设备实现的方法和操作，也可以由可由设备的组成部件(例如芯片或者电路)来实现。

上文结合图1至图14，描述了本申请实施例提供的数据传输的方法，下面将结合图15至图16，描述本申请的装置的实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图15是本申请实施例提供的一种数据传输的装置1600的示意图。该装置1600应用于第一服务和第二服务的通信过程中，该装置1600可以包括第一服务调用的协议栈。该协议栈可以用于执行本申请实施例中的方法，例如，图6所示的方法600。该协议栈包括第一获取单元1610和第一处理单元1620。

第一收发单元1610，用于获取第一服务与第二服务之间传输的业务报文的第一应用信息，第一应用信息包括应用层信息。

第二处理单元1620，用于根据第一应用信息和第一控制策略库对业务报文进行处理，第一控制策略库用于指示对业务报文的处理方式。

可选地，协议栈还包括：第二获取单元和第二处理单元(图中未示出)。第一获取单元和第二获取单元可以为同一单元，也可以为不同单元。第一处理单元和第二处理单元可以为同一单元，也可以为不同单元。

第二获取单元，用于在第一获取单元获取第一服务与第二服务之间传输的业务报文之前，获取第一服务发起的建链请求，建链请求用于请求在第一服务和第二服务之间建立通信链路。第二处理单元，用于向第一服务返回建链成功的指示信息，在向第一服务返回建链成功的指示信息之前，第一服务和第二服务之间未建立通信链路。

作为一种可能的实现方式，协议栈还可以包括第二发送单元(图中未示出)，用于向第一服务返回建链成功的指示信息。第二处理单元可以用于指示第二发送单元向第一服务返回建链成功的指示信息。

可选地，第一处理单元1620具体用于：在第一应用信息满足第一控制策略库中的第一规则的情况下，在第一服务和第二服务之间建立通信链路，第一规则用于指示允许第一服务访问第二服务，通信链路用于传输业务报文。

可选地，第一处理单元1620具体用于：在第一应用信息满足第一控制策略库中的第一规则和第二规则的情况下，根据第二规则调整业务报文，第二规则用于指示调整业务报文；在第一服务和第二服务之间建立通信链路，通信链路用于传输调整后的业务报文。

可选地，第一处理单元1620具体用于：在第一应用信息不满足第一规则的情况下，向第一服务返回第一错误信息，第一错误信息用于指示无法向第二服务发送业务报文。

作为一种可能的实现方式，协议栈还可以包括第一发送单元(图中未示出)，用于向第一服务返回第一错误信息。第一处理单元1620具体用于：在第一应用信息不满足第一规则的情况下，指示第一发送单元向第一服务返回第一错误信息。

作为一种可能的实现方式，第二处理单元具体用于：获取建链请求的第二应用信息，第二应用信息包括建链请求的链路信息；在第二控制策略库包括第三规则的情况下，指示第二发送单元向第一服务返回建链成功的指示信息，

作为一种可能的实现方式，第二处理单元具体用于：在第二应用信息满足第三规则的情况下，指示第二发送单元向第一服务返回建链成功的指示信息。

可选地，第一控制策略库包括流量治理的规则。

应理解，各单元执行上述相应步骤的具体过程在上述各方法实施例中已经详细说明，为了简洁，在此不再赘述。

还应理解，这里的装置1600以功能单元的形式体现。这里的术语“单元”可以指应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。本领域技术人员可以理解，装置1600可以用于执行上述各方法实施例中各个流程和/或步骤，为避免重复，在此不再赘述。

需要说明的是，在其他实施例中，各个单元可以用于执行上述数据传输的方法的任意步骤。例如，第一处理单元可以用于执行数据传输的方法中的任意步骤，第一获取单元可以用于执行失败用例的分析方法中的任意步骤。各个单元负责实现的步骤可根据需要指定，通过各个单元分别实现数据传输的方法中不同的步骤来实现装置1600的全部功能。

图16是本申请实施例提供另一种数据传输的装置1700的示意图。该装置1700包括处理器1710和存储器1720，处理器1710用于执行存储器1720存储的计算机程序或指令，或读取存储器1720存储的数据/信令，以执行上文各方法实施例中的方法。可选地，处理器1710为一个或多个。

存储器1720用于存储计算机程序或指令和/或数据。该存储器1720可以与处理器1710集成在一起，或者也可以分离设置。可选地，存储器1720为一个或多个。

可选地，如图16所示，该装置1700还包括接口1730，接口1730可以通过无线或有线的方式实现，具体来讲可以是网卡。处理器1720、存储器1720和接口1730通过总线1740连接。接口1730具体可以包括发送器和接收器。

例如，处理器1710用于执行存储器1720存储的计算机程序或指令，以实现本申请实施例中的方法。

存储器1720包括操作系统1721和应用程序1722，用于存储程序、代码或指令，当处理器或硬件设备执行这些程序、代码或指令时可以完成方法实施例中本申请实施例中的方法。可选的，存储器1720可以包括只读存储器(read-only memory，ROM)和随机存取存储器(random access memory，RAM)。其中，所述ROM包括基本输入/输出系统(basic input/output system，BIOS)或嵌入式系统；所述RAM包括应用程序和操作系统。当需要调用协议栈时，运行在RAM中的应用程序和操作系统，从而，完成方法实施例中涉及协议栈的处理过程。

可以理解的是，图16仅仅示出了数据传输的装置的简化设计。在实际应用中，数据传输的装置可以包含任意数量的接口，处理器或者存储器。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。

还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本申请实施例还提供一种计算机可读存储介质，其上存储有用于实现上述各方法实施例中由设备执行的方法的计算机指令。

例如，该计算机程序被计算机执行时，使得该计算机可以实现上述方法各实施例中的方法。

这些计算机可读存储包括但不限于如下的一个或者多个：只读存储器(read-onlymemory，ROM)、可编程ROM(programmable ROM，PROM)、可擦除的PROM(erasable PROM，EPROM)、Flash存储器、电EPROM(electrically EPROM，EEPROM)以及硬盘驱动器(harddrive)。

本申请实施例还提供一种计算机程序产品，包含指令，该指令被计算机执行时以实现上述各方法实施例中的方法。

本申请实施例还提供了一种芯片，该芯片包括：至少一个处理器、至少一个存储器和接口电路，所述接口电路负责所述芯片与外界的信息交互，所述至少一个存储器、所述接口电路和所述至少一个处理器通过线路互联，所述至少一个存储器中存储有指令；所述指令被所述至少一个处理器执行，以进行本申请实施例中的方法。在具体实现过程中，该芯片可以以中央处理器(central processing unit，CPU)、微控制器(micro controller unit，MCU)、微处理器(micro processing unit，MPU)、数字信号处理器(digital signalprocessing，DSP)、片上系统(system on chip，SoC)、专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gatearray，FPGA)或可编辑逻辑器件(programmable logic device，PLD)的形式实现。

上述提供的任一种装置中相关内容的解释及有益效果均可参考上文提供的对应的方法实施例，此处不再赘述。

本申请实施例描述的网络架构以及业务场景是为了更加清楚地说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：包括单独存在A，同时存在A和B，以及单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。例如，所述计算机可以是个人计算机，服务器，或者网络设备等。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD)等。例如，前述的可用介质包括但不限于：U盘、移动硬盘、只读存储器(read-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种数据传输的方法，其特征在于，应用于第一服务和第二服务的通信过程中，所述第一服务调用的协议栈执行如下步骤：

获取所述第一服务与所述第二服务之间传输的业务报文的第一应用信息，所述第一应用信息包括应用层信息；

根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，所述第一控制策略库用于指示对所述业务报文的处理方式。

2.根据权利要求1所述的方法，其特征在于，在所述获取所述第一服务与所述第二服务之间传输的业务报文之前，所述方法还包括：

获取所述第一服务发起的建链请求，所述建链请求用于请求在所述第一服务和所述第二服务之间建立通信链路；

向所述第一服务返回建链成功的指示信息，在向所述第一服务返回建链成功的指示信息之前，所述第一服务和所述第二服务之间未建立通信链路。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，包括：

在所述第一应用信息满足所述第一控制策略库中的第一规则的情况下，在所述第一服务和所述第二服务之间建立通信链路，所述第一规则用于指示允许所述第一服务访问所述第二服务，所述通信链路用于传输所述业务报文。

4.根据权利要求3所述的方法，其特征在于，在所述第一应用信息满足所述第一控制策略库中的第一规则的情况下，在所述第一服务和所述第二服务之间建立通信链路，包括：

在所述第一应用信息满足所述第一控制策略库中的第一规则和第二规则的情况下，根据所述第二规则调整所述业务报文，所述第二规则用于指示调整所述业务报文；

在所述第一服务和所述第二服务之间建立通信链路，所述通信链路用于传输所述调整后的业务报文。

5.根据权利要求3或4所述的方法，其特征在于，所述根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，包括：

在所述第一应用信息不满足所述第一规则的情况下，向所述第一服务返回第一错误信息，所述第一错误信息用于指示无法向所述第二服务发送所述业务报文。

6.根据权利要求2至5中任一项所述的方法，其特征在于，所述向所述第一服务返回建链成功的指示信息，包括：

提取所述建链请求的第二应用信息，所述第二应用信息包括所述建链请求的链路信息；

在第二控制策略库包括第三规则的情况下，向所述第一服务返回建链成功的指示信息，所述第三规则与所述第二应用信息相关。

7.根据权利要求6所述的方法，其特征在于，在所述第二控制策略库包括第三规则的情况下，向所述第一服务返回建链成功的指示信息，包括：

在所述第二应用信息满足所述第三规则的情况下，向所述第一服务返回建链成功的指示信息。

8.根据权利要求1所述的方法，其特征在于，所述业务报文是由所述第一服务发送至所述第二服务，以及所述根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，包括：

在第一时段内未收到来自所述第二服务的所述业务报文的响应信息的情况下，根据所述第一应用信息和所述第一控制策略库执行以下至少一项操作：

对所述业务报文执行重传操作，或者，

向所述第一服务返回第二错误信息，所述第二错误信息用于指示未收到所述业务报文的响应信息。

9.根据权利要求1所述的方法，其特征在于，所述业务报文是由所述第二服务发送至所述第一服务，以及所述根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，包括：

在所述业务报文的序列号出现乱序的情况下，根据所述第一应用信息和所述第一控制策略库执行以下至少一项操作：重组所述序列号或丢弃所述业务报文。

10.根据权利要求1至9中任一项所述的方法，特征在于，所述第一控制策略库包括流量治理的规则。

11.一种数据传输的装置，其特征在于，应用于所述第一服务和第二服务的通信过程中，包括所述第一服务调用的协议栈，所述协议栈包括：

第一获取单元，用于获取所述第一服务与所述第二服务之间传输的业务报文的第一应用信息，所述第一应用信息包括应用层信息；

第一处理单元，用于根据所述第一应用信息和第一控制策略库对所述业务报文进行处理，所述第一控制策略库用于指示对所述业务报文的处理方式。

12.根据权利要求11所述的装置，其特征在于，所述协议栈还包括：

第二获取单元，用于在所述第一获取单元获取所述第一服务与所述第二服务之间传输的业务报文之前，获取所述第一服务发起的建链请求，所述建链请求用于请求在所述第一服务和所述第二服务之间建立通信链路；

第二处理单元，用于向所述第一服务返回建链成功的指示信息，在向所述第一服务返回建链成功的指示信息之前，所述第一服务和所述第二服务之间未建立通信链路。

13.根据权利要求12所述的装置，其特征在于，所述第一处理单元具体用于：

14.根据权利要求13所述的装置，其特征在于，所述第一处理单元具体用于：

15.根据权利要求13或14所述的装置，其特征在于，所述第一处理单元具体用于：

16.根据权利要求12至15中任一项所述的装置，其特征在于，所述第二处理单元具体用于：

获取所述建链请求的第二应用信息，所述第二应用信息包括所述建链请求的链路信息；

17.根据权利要求16所述的装置，其特征在于，所述第二处理单元具体用于：

18.根据权利要求11所述的装置，其特征在于，所述业务报文是由所述第一服务发送至所述第二服务，以及所述第一处理单元具体用于：

对所述业务报文执行重传操作，或者，

19.根据权利要求11所述的装置，其特征在于，所述业务报文是由所述第二服务发送至所述第一服务，以及所述第一处理单元具体用于：

20.根据权利要求11至19中任一项所述的装置，特征在于，所述第一控制策略库包括流量治理的规则。

21.一种数据传输的装置，其特征在于，包括：

处理器，用于执行存储器中存储的计算机程序，以使得所述装置执行如权利要求1至10中任一项所述的方法。

22.根据权利要求21所述的装置，其特征在于，所述装置还包括所述存储器。

23.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至10中任意一项所述的方法。

24.一种计算机程序产品，其特征在于，所述计算机程序产品包括用于执行如权利要求1至10中任一项所述的方法的指令。