CN115396372A - 数据流的速率控制方法、智能网卡、云端设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种数据流的速率控制方法、智能网卡、云端设备及存储介质，其中方法应用于智能网卡，方法包括：获取第一设备端的握手连接报文；如果握手连接报文指示的拥塞控制机制状态为不允许建立拥塞控制机制连接，则修改握手连接报文；将修改后的握手连接报文发送给第二设备端，以在第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接时，使得第二设备端设置第二设备端的拥塞控制机制处于启用状态；其中，第二设备端的拥塞控制机制用于在数据流出现拥塞时，在协议栈层面降低数据流的发送速率。本申请实施例可以利用拥塞控制机制，保障数据流的传输可靠性，并且提升适用场景。进一步，源端的智能网卡还可利用Meter表对数据流进行限速。

Description

数据流的速率控制方法、智能网卡、云端设备及存储介质

技术领域

本申请实施例涉及网络技术领域，具体涉及一种数据流的速率控制方法、智能网卡、云端设备及存储介质。

背景技术

随着云计算和虚拟化技术的发展，用户可以租用云端的虚拟机，从而在云端的虚拟机部署用户的应用程序或者服务。在云网络中，虚拟机是由云端设备通过虚拟化得到，位于不同云端设备的虚拟机之间存在互联互通的需求，因此云网络中存在着大量的在不同云端设备之间传输的数据流。在数据流的传输过程中，发送数据流的设备端可称为源端（也称为发送端），接收数据流的设备端可称为接收端。

数据流在云网络中传输时，数据流可能出现拥塞情况，这将导致数据流中的数据包到达接收端的时延增加，甚至丢失数据包等现象，严重影响了数据流的传输可靠性。因此如何提供技术方案，以保障数据流的传输可靠性，成为了本领域技术人员亟需解决的技术问题。

发明内容

有鉴于此，本申请实施例提供一种数据流的速率控制方法、智能网卡、云端设备及存储介质，以在源端发送的数据流出现拥塞时，对源端的数据流实现无丢包限速，即在不丢失源端的数据流的数据包的前提下，实现降低数据流速率，从而保障数据流的传输可靠性；并且，本申请实施例提供的方案具有较广的适用场景。

为实现上述目的，本申请实施例提供如下技术方案。

第一方面，本申请实施例提供一种数据流的速率控制方法，应用于智能网卡，所述智能网卡设置于第一设备端；所述方法包括：

获取第一设备端的握手连接报文，所述握手连接报文用于所述第一设备端与第二设备端进行握手连接，并且所述握手连接报文指示有所述第一设备端的拥塞控制机制状态；

如果所述握手连接报文指示的拥塞控制机制状态为所述第一设备端不允许建立拥塞控制机制连接，则将所述握手连接报文指示的拥塞控制机制状态，修改为所述第一设备端允许建立拥塞控制机制连接的状态，以得到修改后的握手连接报文；

将修改后的握手连接报文发送给所述第二设备端，以在所述第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接时，使得所述第二设备端设置所述第二设备端的拥塞控制机制处于启用状态；其中，所述第二设备端的拥塞控制机制用于在所述第二设备端发送的数据流在网络中出现拥塞时，在所述第二设备端的协议栈层面降低数据流的发送速率。

第二方面，本申请实施例提供一种智能网卡，所述智能网卡包括至少一个处理器和至少一个存储器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的数据流的速率控制方法。

第三方面，本申请实施例提供一种云端设备，所述云端设备设置有如上述第二方面所述的智能网卡。

第四方面，本申请实施例提供一种存储介质，所述存储介质存储有一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时，实现如上述第一方面所述的数据流的速率控制方法。

第五方面，本申请实施例提供一种计算机程序，所述计算机程序被执行时，实现如上述第一方面所述的数据流的速率控制方法。

本申请实施例提供的数据流的速率控制方法，可在第一设备端的拥塞控制机制状态为不允许建立拥塞控制机制连接时，对第一设备端的握手连接报文所指示的拥塞控制机制状态进行修改，使得修改后的握手连接报文指示第一设备端允许建立拥塞控制机制连接；从而在第二设备端本身允许建立拥塞控制机制连接的情况下，第二设备端能够通过第一设备端修改后的握手连接报文，认为第一设备端期望与第二设备端建立拥塞控制机制连接；进而，第二设备端可设置拥塞控制机制处于启用状态。后续当第二设备端成为发送数据流的源端时，如果源端的数据流在网络中出现拥塞，则源端可使用处于启用状态的拥塞控制机制，在源端的协议栈层面，对源端的数据流实现无丢包限速，保障源端数据流的传输可靠性；也就是说，源端可在不丢失数据流的数据包的前提下，利用拥塞控制机制，在源端的协议栈层面降低数据流速率，保障数据流的传输可靠性。

同时，本申请实施例可在第一设备端的拥塞控制机制状态为不允许建立拥塞控制机制连接，而第二设备端本身的拥塞控制机制状态为允许建立拥塞控制机制连接时，通过修改第一设备端的握手连接报文，使得第二设备端能够设置拥塞控制机制处于启用状态，可以在不违背第二设备端侧的拥塞控制机制使用意愿的情况下，提升拥塞控制机制的适用场景。

附图说明

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

图1为本申请实施例提供的数据流传输系统的示例图。

图2为消息队列的示例图。

图3为客户端和服务端之间的握手连接示例图。

图4为本申请实施例提供的数据流传输系统的另一示例图。

图5为本申请实施例提供的数据流的速率控制方法的流程图。

图6为本申请实施例提供的数据流的速率控制方法的另一流程图。

图7为本申请实施例提供的数据流的速率控制方法的再一流程图。

图8为本申请实施例提供的智能网卡的框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于理解云网络的数据流传输过程，图1示例性的示出了本申请实施例提供的数据流传输系统的示例图，该数据流传输系统可以视为是云网络实现数据流传输的简化系统架构，如图1所示，该数据流传输架构可以包括：第一设备端110、第二设备端120和中间设备130。

第一设备端110和第二设备端120可以是不同的云端设备（例如云端不同的服务器主机），在物理形式上，第一设备端110和第二设备端120可以属于云端不同的物理设备。基于虚拟化技术，第一设备端110可以虚拟化有供用户使用的多台虚拟机111，第二设备端120可以虚拟化有供用户使用的多台虚拟机121；第一设备端110虚拟化的多台虚拟机可以提供给相同用户使用，也可以提供给不同用户使用；第二设备端120虚拟化的多台虚拟机可以提供给相同用户使用，也可以提供给不同用户使用；同一用户使用的虚拟机可能涉及第一设备端110虚拟化的虚拟机和第二设备端120虚拟化的虚拟机。

当第一设备端110中的虚拟机，与第二设备端120中的虚拟机存在互联互通的需求时，第一设备端110和第二设备端120之间可传输虚拟机的数据流；第一设备端110和第二设备端120中发送数据流的一端可称为源端，接收数据流的一端可称为接收端。例如，当第一设备端110中的虚拟机向第二设备端120中的虚拟机发送数据流时，第一设备端110可将虚拟机的数据流发送给第二设备端120中的虚拟机，此时，第一设备端110为发送数据流的源端，第二设备端120为接收数据流的接收端。又例如，当第二设备端120中的虚拟机向第一设备端110中的虚拟机发送数据流时，第二设备端120可将虚拟机的数据流发送给第一设备端110中的虚拟机，此时，第二设备端120为发送数据流的源端，第一设备端110为接收数据流的接收端。需要说明的是，源端和接收端的角色并不固定，需要根据数据流在云端设备之间的流向而定。

中间设备130为云网络中负责在源端和接收端之间传输数据流的数据传输设备，涉及利用网络功能虚拟化层，虚拟化的NFV（Network Functions Virtualization，网络功能虚拟化）网关、负载均衡器等。在一个示例中，不同云端设备之间可通过中间设备实现数据流的传递。

基于云网络可使用消息队列来进行数据收发两端之间的解耦，中间设备130可以设置消息队列，以对源端和接收端之间传输的数据流进行排队处理。为便于理解，图2示例性的示出了消息队列的示例图，如图2所示，源端发送的数据流可以包括多个数据包，数据流的数据包可以在中间设备的消息队列进行排队；中间设备可对消息队列中排队的数据包进行传输处理，从而将消息队列中排队的数据包传输给接收端，以实现数据流在源端和接收端之间的传输。

云网络中的流量主要分为东西向流量和南北向流量。其中，数据中心的云端服务器之间交互的流量，称为东西向流量（也称为横向流量）；数据中心的外部用户和云端服务器之间交互的流量，称为南北向流量（也称为纵向流量）。基于云端的虚拟机部署于云端的服务器主机等云端设备中，因此云端的虚拟机之间的数据流属于云网络的东西向流量；也就是说，本申请实施例所指的源端与接收端之间传输的数据流，属于云网络的东西向流量。

由于云网络对于东西向流量并不进行限速，源端发送的数据流可能出现流量过高的情况，当源端发送的数据流的流量过高时，中间设备在对数据流的数据包进行传输处理时，中间设备的处理速率可能与源端发送数据流的速率不匹配（例如，中间设备的处理速率低于源端发送数据流的速率），这可能导致数据流的数据包在消息队列中的排队长度过长（即数据流在网络中出现拥塞）。也就是说，当源端发送数据流的流量过高时，中间设备处理数据流的处理速率，将低于源端发送数据流的速率，从而源端新发送的数据包将在中间设备的消息队列中不断的增加，导致源端的数据流在消息队列中排队长度过长，数据流在网络中出现拥塞。

数据流的数据包在中间设备的消息队列中排队长度过长，将使得数据流的数据包到达接收端的时延增加，甚至出现消息队列丢失数据包等现象；另外，如果消息队列中排队有多个用户的数据流的数据包，而一个用户的数据流的数据包在消息队列中的排队长度过长，也可能影响消息队列中其他用户的数据流的流量，违反云上租户隔离的原则，导致云网络的运行受到影响。

为避免源端的数据流在网络中出现拥塞，而进一步导致数据流到达接收端的时延增加、丢失数据包、影响云网络运行等问题，当源端发送的数据流的流量过高时，需要降低源端发送数据流的速率（例如对源端发送数据流的速率进行限速），以使得中间设备处理数据包的处理速率能够与源端发送数据流的速率相匹配（例如，中间设备处理数据包的处理速率，高于或等于源端发送数据流的速率）；这种对源端发送数据流的速率进行控制的机制称为源端反压（back pressure）。也就是说，源端反压意味着云网络的中间设备处理数据流的速率，跟不上源端发送数据流的速率，需要对源端发送数据流的速率进行限速，以保障数据流的传输可靠性。

需要进一步说明的是，云网络中传输的流量可以主要分为TCP（TransmissionControl Protocol，传输控制协议栈）协议的流量和UDP（User Datagram Protocol，用户数据报协议栈）协议的流量。其中，UDP协议提供不可靠性的服务，不保证流量能够从源端到达接收端；例如，针对UDP协议，UDP协议的数据流在云网络中出现丢包时，UDP协议并不感知丢包情况，也不会主动降低数据流的发送速率。TCP协议提供可靠性的服务，TCP协议的流量会受到丢包、重传等因素的影响，因此TCP协议栈中定义有流量的拥塞控制机制，以保障流量的可靠传输。例如TCP协议栈中提供拥塞避免、慢启动、快重传等流量的拥塞控制机制，针对TCP流量，数据流会由于丢包等因素而自行降低发送速率。

在源端发送的数据流的流量过大时，源端发送的数据流可称为大流（heavyhitte），例如，heavy hitte可以认为是数据包数量超过数量阈值的数据流。源端发送的大流会在中间设备的消息队列产生拥塞，从而导致源端发送的大流在网络中出现拥塞，此时，需要对源端发送数据流的速率进行精准限速。为了能够尽量减少数据流的限速对用户体验的影响，需要对源端实现无损反压（即在源端的数据流无数据包丢失的情况下，降低数据流的速率）。

对源端实现无损反压，可以在源端的协议栈层面降低数据流的速率（即对源端的协议栈实现反压），由于UDP协议并未定义流量的拥塞控制机制，而TCP协议定义有流量的拥塞控制机制，因此对源端的协议栈实现反压，目前并不适用于UDP协议的数据流，而适用于TCP协议的数据流。需要说明的是，TCP协议和UDP协议只是云网络的传输协议的示例，云网络中可能存在其他类型的传输协议，对于任一传输协议，只要传输协议定义有流量的拥塞控制机制，则可以通过传输协议的拥塞控制机制，实现在协议栈的层面降低数据流的速率，从而对源端的协议栈实现反压；TCP协议仅是支持拥塞控制机制的传输协议的一种示例。

为便于进一步理解TCP等传输协议中定义的拥塞控制机制，下面以ECN（ExplicitCongestion Notification，显示拥塞通知）机制为例进行介绍。ECN机制可以视为是TCP等传输协议的扩展，是拥塞控制机制的一种示例，用于控制TCP等传输协议的数据流的发送速率；ECN机制支持源端到接收端的网络拥塞通知，当数据流在云网络中出现拥塞时，中间设备可为数据流的数据包的CE（Congestion experienced，遇到拥塞）字段进行标记，从而基于数据流的数据包的CE字段被标记的情况，源端可在TCP协议栈的层面，降低数据流的发送速率，以降低数据流在云网络中的拥塞情况。

ECN等拥塞控制机制需要在用户启用的情况下使用，也就是说，源端和接收端中的一方发起拥塞控制机制连接请求时，另一方需要响应拥塞控制机制连接请求，才可使得源端使用拥塞控制机制，在协议栈层面实现无损反压；例如，当源端和接收端中的一方发起ECN连接请求时，另一方需要响应ECN连接请求，才可使得源端使用ECN，在协议栈层面实现无损反压。源端和接收端的拥塞控制机制（例如ECN）主要具有以下三种不同的状态：

不主动发起拥塞控制机制连接请求（例如不主动发起ECN连接请求），以及不响应拥塞控制机制连接请求（例如不响应ECN连接请求）的状态，为便于说明，称该状态为第一状态；在以状态值设置拥塞控制机制状态（例如ECN状态）时，如果拥塞控制机制状态值（例如ECN状态值）被设置为0，则拥塞控制机制处于第一状态；

主动发起拥塞控制机制连接请求（例如主动发起ECN连接请求），以及被动响应拥塞控制机制连接请求（例如被动响应ECN连接请求）的状态，为便于说明，称该状态为第二状态；在以状态值设置拥塞控制机制状态时，如果拥塞控制机制状态值被设置为1，则拥塞控制机制处于第二状态；

默认状态，默认状态指示被动响应拥塞控制机制连接请求（例如被动响应ECN连接请求）；在以状态值设置拥塞控制机制状态时，如果拥塞控制机制状态值被设置为2，则拥塞控制机制处于默认状态。

为便于理解拥塞控制机制状态，下面以ECN为例，对以上三种状态的情况进行列表说明，作为示例，下表1示例性的示出了ECN的三种状态示例内容。

表1

可以看出，如果需要在协议栈层面对源端实现无损反压，则源端和接收端需要建立拥塞控制机制连接（例如源端和接收端需要建立ECN连接），而源端和接收端能否建立拥塞控制机制连接（例如ECN连接），依赖于源端和接收端设置的拥塞控制机制状态（例如ECN状态）；当源端和接收端设置的拥塞控制机制状态，并不无法使得源端和接收端建立拥塞控制机制连接时（例如源端和接收端的拥塞控制机制状态均为默认状态，由于源端和接收端均被动响应拥塞控制机制连接请求，网络中并无发起拥塞控制机制连接请求的一方，因此源端和接收端无法建立拥塞控制机制连接），就无法依赖拥塞控制机制，对源端的协议栈进行反压。也就是说，当源端和接收端设置的拥塞控制机制状态，无法使得源端和接收端建立拥塞控制机制连接时，无法依赖源端协议栈的拥塞控制机制，在源端的协议栈层面对数据流实现无丢包限速（即无法实现协议栈层面的源端无损反压），这导致基于拥塞控制机制的源端反压的适用场景受限。

基于此，本申请实施例提供数据流的速率控制方案，通过设备端之间的握手连接过程，设置设备端的拥塞控制机制为启用状态；从而在设备端成为发送数据流的源端时，如果设备端的数据流在网络中出现拥塞，则设备端可使用处于启用状态的拥塞控制机制，在源端的协议栈层面，对源端的数据流实现无丢包限速；进而，能够在不丢失源端的数据流的数据包的前提下，利用拥塞控制机制（例如ECN），在源端的协议栈层面降低数据流速率。并且，本申请实施例提供的方案可以适用于与设备端建立握手连接的另一设备端，不允许建立拥塞控制机制连接的情况，从而提升本申请实施例提供的方案的适用场景。

作为可实现，结合图1所示，以第一设备端和第二设备端为例，第一设备端和第二设备端之间可通过握手连接，协商第一设备端和第二设备端的拥塞控制机制状态。例如，第一设备端和第二设备端可通过TCP的握手连接，完成第一设备端和第二设备端的ECN状态协商。为便于说明，在握手连接过程中，第一设备端和第二设备端中发起握手连接的一端可称为客户端（client），响应握手连接的一端可称为服务端（server）；在一个示例中，图3示例性的示出了客户端和服务端之间的握手连接示例图，如图3所示：

客户端作为发起握手连接的一方，可向服务端发送SYN（Synchronize SequenceNumbers，同步序列编号）报文，以向服务端发起握手连接；

服务端在接收SYN报文后，可向客户端响应SYN-ACK（Acknowledge character，确认字符）报文，以响应客户端发起的握手连接；

客户端接收到SYN-ACK报文后，可向服务端发送ACK报文，以完成与服务端的握手连接。

在客户端与服务端的握手连接过程中，客户端可以在SYN报文中指示客户端的ECN状态，服务端可以在SYN-ACK报文中指示服务端的ECN状态，以完成客户端和服务端的ECN状态协商。

可以理解的是，客户端作为握手连接的发起方，客户端的ECN状态如果不是主动发起ECN连接请求的状态（例如客户端的ECN状态为第一状态或者默认状态），则客户端与服务端在握手连接过程中协商的ECN状态，并无法使得客户端和服务端建立ECN连接；从而，客户端与服务端之中发送数据流的源端，在出现大流情况时，无法利用ECN机制，来在源端的协议栈层面降低数据流速率；

同时，在客户端的ECN状态为主动发起ECN连接的状态时（例如客户端的ECN状态为第二状态），但服务端处于不响应ECN连接请求的状态（例如服务端的ECN状态为第一状态），则客户端与服务端在握手连接过程中协商的ECN状态，也无法使得客户端和服务端建立ECN连接；从而，客户端与服务端之中发送数据流的源端，在出现大流情况时，也同样无法利用ECN机制，来在源端的协议栈层面降低数据流速率。

需要说明的是，客户端与服务端交互数据时，客户端可向服务端发送数据流，此时客户端为源端，服务端为接收端；服务端也可向客户端发送数据流，此时服务端为源端，客户端为接收端；源端和接收端的角色并不固定，需要视数据流的流向而定。

综上所述，无法依赖拥塞控制机制，对源端的协议栈进行反压主要涉及以下几种情况：

客户端的拥塞控制机制状态为不是主动发起拥塞控制机制连接请求的状态；例如，客户端的拥塞控制机制状态为第一状态或者默认状态；

或者，客户端的拥塞控制机制状态为主动发起拥塞控制机制连接请求的状态，但是服务端的拥塞控制机制状态为不响应拥塞控制机制连接请求的状态；例如，客户端的拥塞控制机制状态为第二状态，但是服务端的拥塞控制机制状态为第一状态。

需要说明的是，在ECN等拥塞控制机制的连接建立过程中，服务端是处于响应拥塞控制机制连接请求的角色，而客户端是处于发起拥塞控制机制连接请求的角色。

为便于理解，以ECN为例，下表2示例性的示出了客户端和服务端的ECN状态分布情况和对应的ECN机制能否实现的说明。

表2

由表2可以看出，针对情况一，客户端的ECN状态值为1（对应客户端处于第二状态，能够主动发起ECN连接请求），服务端的ECN状态值为1或2（对应服务端处于第二状态或者默认状态，能够被动响应ECN连接请求），此时客户端和服务端通过握手连接协商的ECN状态，能够使得客户端和服务端建立ECN连接；从而客户端与服务端之中发送数据流的源端，在出现大流情况时，能够利用ECN机制，实现在源端协议栈对数据流进行限速；

针对情况二，客户端的ECN状态值为0或2（对应客户端处于第一状态或者默认状态，客户端不是主动发起ECN连接请求的状态），服务端的ECN状态值为1或2时（对应服务端处于第二状态或者默认状态，能够被动响应ECN连接请求），此时由于客户端不主动发起ECN连接请求，因此就算服务端能够被动响应ECN连接请求，那客户端与服务端通过握手连接协商的ECN状态，也无法使得客户端和服务端建立ECN连接；从而，客户端与服务端之中发送数据流的源端，在出现大流情况时，并无法利用ECN机制，在源端协议栈对数据流进行限速；

针对情况三，客户端的ECN状态值为1，服务端的ECN状态值为0时（对应服务端处于第一状态，不响应ECN连接请求），此时虽然客户端能够主动发起ECN连接请求，但是服务端不响应ECN连接请求，因此客户端与服务端通过握手连接协商的ECN状态，无法使得客户端和服务端建立ECN连接；从而，客户端与服务端之中发送数据流的源端，在出现大流情况时，并无法利用ECN机制，在源端协议栈对数据流进行限速；

针对情况四，客户端的ECN状态值为0或2，服务端的ECN状态值为0时，此时由于客户端不主动发起ECN连接请求，服务端也不响应ECN连接请求，因此客户端与服务端通过握手连接协商的ECN状态，无法使得客户端和服务端建立ECN连接。

从上文描述可以看出，虽然在上述情况二和情况三下，客户端与服务端之间通过正常的握手连接过程，协商的ECN状态并无法使得客户端和服务端建立ECN连接；但是，在情况二和情况三下，客户端与服务端中存在一方是允许建立ECN连接的；例如，在情况二下，服务端能够被动响应ECN连接请求，服务端允许建立ECN连接；在情况三下，客户端能够主动发起ECN连接请求，客户端允许建立ECN连接。

基于此，以第一设备端和第二设备端之间传输数据流为例，本申请实施例可对第一设备端的握手连接报文所指示的拥塞控制机制状态进行修改（此处的第一设备端例如情况二下的客户端，或者情况三下的服务端），使得修改后的拥塞控制机制状态指示，第一设备端允许建立拥塞控制机制连接；从而在第二设备端允许建立拥塞控制机制连接的情况下（此处的第二设备端例如情况二下的服务端，或者情况三下的客户端），第二设备端能够通过第一设备端修改后的握手连接报文，认为第一设备端期望与第二设备端建立拥塞控制机制连接；进而，第二设备端可设置拥塞控制机制处于启用状态，从而第二设备端可响应一切拥塞控制机制。后续，当第二设备端发送的数据流在网络中出现拥塞时，第二设备端可基于处于启用状态的拥塞控制机制，使用拥塞控制机制，在第二设备端的协议栈的层面，降低数据流的传输速率，实现在源端的协议栈层面对数据流进行限速。

基于上述思路，在第一设备端和第二设备端进行握手连接的过程中，本申请实施例可利用第一设备端的智能网卡，获取第一设备端的握手连接报文，并对第一设备端的握手连接报文所指示的拥塞控制机制状态进行修改，以使得修改后的拥塞控制机制状态指示，第一设备端允许建立拥塞控制机制连接。为便于理解设置有智能网卡的数据流传输系统架构，图4示例性的示出了本申请实施例提供的数据流传输系统的另一示例图，结合图1和图4所示：

第一设备端110中除虚拟化有多台虚拟机111外，还设置有虚拟机监视器112和智能网卡113；第二设备端120中除虚拟化有多台虚拟机121外，还设置有虚拟机监视器122和智能网卡123；中间设备130中除利用网络功能虚拟化层，虚拟化有NFV网关、负载均衡器等虚拟组件外，还可设置虚拟机监视器131和智能网卡132。

需要说明的是，虚拟机监视器可用于对虚拟机、虚拟组件等进行管理。智能网卡是为实现数据的高性能转发而设置的硬件器件，原本由虚拟交换机（Virtual switch，Vswitch）实现的功能可由智能网卡实现；智能网卡除了能完成数据的网络传输功能之外,还可通过内置的可编程、可配置的硬件加速引擎，提升应用性能和大幅降低处理器在通信中的消耗。智能网卡可以理解为是利用硬件完成虚拟交换机的数据转发操作，并且拥有片上处理器的网卡。

基于图4示例的系统架构，作为可选实现，图5示例性的示出了本申请实施例提供的数据流的速率控制方法的可选流程图。在可选实现中，该方法流程中由第一设备端执行的步骤，可以由第一设备端设置的智能网卡执行实现；参照图5，该方法流程可以包括如下步骤。

在步骤S510中，第一设备端的智能网卡，获取第一设备端的握手连接报文；所述握手连接报文用于第一设备端与第二设备端进行握手连接，并且所述握手连接报文指示有所述第一设备端的拥塞控制机制状态。

在第一设备端与第二设备端进行握手连接的过程中，第一设备端的智能网卡可获取第一设备端的握手连接报文。例如，第一设备端的智能网卡，可劫持第一设备端的握手连接报文。在一些实施例中，第一设备端可能是发起握手连接的客户端，也可能是响应握手连接的服务端。

第一设备端的握手连接报文可以指示第一设备端的拥塞控制机制状态。在一些实施例中，握手连接报文可以携带状态字段，状态字段的值与拥塞控制机制状态值相对应，不同的拥塞控制机制状态值对应不同的拥塞控制机制状态。

在可选实现中，如果第一设备端的握手连接报文携带的状态字段的值，指示第一设备端不允许建立拥塞控制机制连接，则第一设备端的智能网卡，可对握手连接报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与第一设备端允许建立拥塞控制机制连接的状态相对应。在可选实现中，指示拥塞控制机制状态的状态字段可以例如CWR（Congestion Window Reduced，拥塞窗口减少标志）字段、ECE（ECN回声）字段等。

作为可选实现，第一设备端如果是发起握手连接的客户端（相应的，第二设备端为响应握手连接的服务端），则第一设备端的握手连接报文可以是客户端的SYN报文，SYN报文可以指示客户端是否主动发起拥塞控制机制连接请求。例如，SYN报文的可以通过CWR字段和ECE字段的值，指示客户端是否主动发起拥塞控制机制连接请求。在一个示例中，如果SYN报文中CWR字段和ECE字段的值为1，则客户端的拥塞控制机制状态为主动发起拥塞控制机制连接请求的状态（例如客户端的拥塞控制机制状态值为1）；如果SYN报文中CWR字段和ECE字段的值为0，则客户端的拥塞控制机制状态为不主动发起拥塞控制机制连接请求的状态（例如客户端的拥塞控制机制状态值为0或2）。

作为可选实现，第一设备端如果是响应握手连接的服务端（相应的，第二设备端为发起握手连接的客户端），则第一设备端的握手连接报文可以是服务端的SYN-ACK报文。例如，SYN-ACK报文可以通过ECE字段的值，指示服务端的拥塞控制机制状态。在一个示例中，如果服务端的拥塞控制机制状态为不响应拥塞控制机制连接请求的状态（例如服务端的拥塞控制机制状态值为0），则SYN-ACK报文中ECE字段的值不为1；如果SYN-ACK报文中ECE字段的值为1，则服务端的拥塞控制机制状态可以至少为被动响应拥塞控制机制连接请求的状态。

在步骤S511中，如果握手连接报文指示的拥塞控制机制状态为第一设备端不允许建立拥塞控制机制连接，则第一设备端的智能网卡将握手连接报文指示的拥塞控制机制状态，修改为第一设备端允许建立拥塞控制机制连接的状态，以得到修改后的握手连接报文。

在第一设备端与第二设备端的握手连接过程中，如果第一设备端的拥塞控制机制状态为不允许建立拥塞控制机制连接，并指示在第一设备端的握手连接报文中，则为使得第二设备端在获得第一设备端的握手连接报文后，第二设备端能够通过第一设备端的握手连接报文，认为第一设备端期望建立拥塞控制机制连接，从而在第二设备端本身也允许建立拥塞控制机制连接的情况下，第二设备端能够设置拥塞控制机制处于启用状态；本申请实施例可在第一设备端的智能网卡，劫持到第一设备端的握手连接报文后，对握手连接报文所指示的拥塞控制机制状态进行修改，使得修改后的握手连接报文所指示的拥塞控制机制状态为第一设备端允许建立拥塞控制机制连接。

在一些实施例中，第一设备端的智能网卡，可对握手连接报文携带的状态字段（例如CWR字段和ECE字段）的值进行修改，以使得修改后的状态字段的值，与第一设备端允许建立拥塞控制机制连接的状态相对应。

作为可选实现，第一设备端如果是发起握手连接的客户端（相应的，第二设备端为响应握手连接的服务端），则在SYN报文指示的拥塞控制机制状态为，客户端不主动发起拥塞控制机制连接请求时（例如客户端的拥塞控制机制状态值为0或2），客户端的智能网卡可将SYN报文指示的拥塞控制机制状态修改为，客户端主动发起拥塞控制机制连接请求。在一个示例中，如果SYN报文中CWR字段和ECE字段的值为0，则客户端的拥塞控制机制状态为不主动发起拥塞控制机制连接请求的状态；从而，客户端的智能网卡可将SYN报文中CWR字段和ECE字段的值修改为1，以与客户端主动发起拥塞控制机制连接请求的状态相对应。

作为可选实现，第一设备端如果是响应握手连接的服务端（相应的，第二设备端为发起握手连接的客户端），则当SYN-ACK报文指示的拥塞控制机制状态为，服务端不响应拥塞控制机制连接请求时（例如服务端的拥塞控制机制状态值为0），则服务端的智能网卡可将SYN-ACK报文指示的控制机制状态修改为，至少被动响应拥塞控制机制连接请求。在一个示例中，如果服务端的拥塞控制机制状态为不响应拥塞控制机制连接请求，则SYN-ACK报文中ECE字段的值不为1；从而，服务端的智能网卡可将SYN-ACK报文中ECE字段的值修改为1，以与服务端被动响应拥塞控制机制连接请求的状态相对应。

在步骤S512中，第一设备端的智能网卡，将修改后的握手连接报文发送给第二设备端。

第一设备端的智能网卡在修改握手连接报文后，可将修改后的握手连接报文发送给第二设备端。

作为可选实现，第一设备端如果是发起握手连接的客户端，则客户端的智能网卡可将修改后的SYN报文（CWR字段和ECE字段的值修改为1），发送给服务端。作为可选实现，第一设备端如果是响应握手连接的服务端，则服务端的智能网卡可将修改后的SYN-ACK报文（ECE字段的值修改为1），发送给客户端。

在步骤S513中，如果第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接，基于修改后的握手连接报文，设置第二设备端的拥塞控制机制处于启用状态。

第二设备端在获得上述修改后的握手连接报文后，可基于修改后的握手连接报文所指示的拥塞控制机制状态，认为第一设备端期望与第二设备端建立拥塞控制机制连接；此时，如果第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接的情况，则第二设备端可设置第二设备端的拥塞控制机制处于启用状态，以便第二设备端发送的数据流在网络中出现拥塞时，第二设备端能够利用处于启用状态的拥塞控制机制，在第二设备端的协议栈层面对数据流进行限速，以使得第二设备端能够在不丢失数据流的数据包的前提下，实现在协议栈层面降低数据流速率，保障数据流的传输可靠性。

作为可选实现，如果第一设备端为客户端，第二设备端为服务端，则服务端基于客户端修改后的SYN报文，可认为客户端期望与服务端建立拥塞控制机制连接（例如客户端修改后的SYN报文中CWR字段和ECE字段的值为1），此时，如果服务端本身的拥塞控制机制状态为被动响应拥塞控制机制连接请求（例如服务端的拥塞控制机制状态值为1或2），则在服务端本身的拥塞控制机制状态为允许建立拥塞控制机制连接的情况下，服务端可设置拥塞控制机制处于启用状态，以使得服务端可使用拥塞控制机制，对数据流在协议栈层面进行反压。

需要进一步说明的是，如果服务端本身的拥塞控制机制状态为不响应拥塞控制机制连接请求（例如服务端的拥塞控制机制状态值为0），则服务端虽然能通过客户端修改后的SYN报文，认为客户端期望与服务端建立拥塞控制机制连接，但是由于服务端本身不响应拥塞控制机制连接请求，因此服务端无法启用拥塞控制机制。也就是说，以ECN为例，在第一设备端为客户端的情况下，本申请实施例可在表2情况二的场景下，通过修改客户端的SYN报文中的状态字段的值，使得修改后的SYN报文指示客户端处于主动发起ECN连接请求的状态，进而在服务端的ECN状态本身处于被动响应ECN连接请求的状态时，使得服务端能够设置ECN机制处于启用状态。

作为可选实现，如果第一设备端为服务端，第二设备端为客户端，则客户端基于服务端修改后的SYN-ACK报文，可认为服务端期望与客户端建立拥塞控制机制连接（例如服务端修改后的SYN-ACK报文中ECE字段的值为1），此时，如果客户端本身的拥塞控制机制状态为主动发起拥塞控制机制连接请求（例如客户端的拥塞控制机制状态值为1），则在客户端本身的拥塞控制机制状态为允许建立拥塞控制机制连接的情况下，客户端可设置拥塞控制机制处于启用状态，以使得客户端可使用拥塞控制机制，对数据流在协议栈层面进行反压。

需要进一步说明的是，如果客户端本身的拥塞控制机制状态为不主动发起拥塞控制机制连接请求（例如客户端的拥塞控制机制状态值不为1），则客户端虽然能通过服务端修改后的SYN-ACK报文，认为服务端期望与客户端建立拥塞控制机制连接，但是由于客户端本身不主动发起拥塞控制机制连接请求，因此客户端无法启用拥塞控制机制。也就是说，以ECN为例，在第一设备端为服务端的情况下，本申请实施例可在表2情况三的场景下，通过修改服务端的SYN-ACK报文中的ECE字段的值，使得修改后的SYN-ACK报文指示服务端处于被动响应ECN连接请求的状态，进而在客户端的ECN状态本身处于主动发起ECN连接请求的状态时，使得客户端能够设置ECN机制处于启用状态。

作为可选实现，作为设置第二设备端的拥塞控制机制处于启用状态的可选实现方式，第二设备端可将内核中关于拥塞控制机制状态的状态机，转移到启用状态，以使得第二设备端在拥塞控制机制状态的启用状态下，可响应一切的拥塞控制机制。以ECN为例，第二设备端可将内核中ECN状态的状态机，转移到TCP_ECN_OK状态（启用状态的一种示例）；在TCP_ECN_OK状态下，第二设备端可响应一切ECN机制。

本申请实施例提供的数据流的速率控制方法，可在第一设备端的拥塞控制机制状态为不允许建立拥塞控制机制连接时，对第一设备端的握手连接报文所指示的拥塞控制机制状态进行修改，使得修改后的握手连接报文指示第一设备端允许建立拥塞控制机制连接；从而在第二设备端本身允许建立拥塞控制机制连接的情况下，第二设备端能够通过第一设备端修改后的握手连接报文，认为第一设备端期望与第二设备端建立拥塞控制机制连接；进而，第二设备端可设置拥塞控制机制处于启用状态。后续当第二设备端成为发送数据流的源端时，如果源端的数据流在网络中出现拥塞，则源端可使用处于启用状态的拥塞控制机制，在源端的协议栈层面，对源端的数据流实现无丢包限速，保障源端数据流的传输可靠性；也就是说，源端可在不丢失数据流的数据包的前提下，利用拥塞控制机制，在源端的协议栈层面降低数据流速率，保障数据流的传输可靠性。

同时，本申请实施例可在第一设备端的拥塞控制机制状态为不允许建立拥塞控制机制连接，而第二设备端本身的拥塞控制机制状态为允许建立拥塞控制机制连接时，通过修改第一设备端的握手连接报文，使得第二设备端能够设置拥塞控制机制处于启用状态，可以在不违背第二设备端侧的拥塞控制机制使用意愿的情况下，提升拥塞控制机制的适用场景。

可见，本申请实施例提供的方案可以通过修改第一设备端的握手连接报文，从而在与第一设备端建立握手连接的第二设备端，设置拥塞控制机制处于启用状态；进而在第二设备端成为发送数据流的源端，且数据流出现拥塞时，源端可利用拥塞控制机制，在协议栈层面对数据流实现无丢包限速，保障数据流的传输可靠性；同时，本申请实施例通过修改第一设备端的握手连接报文，可以在第一设备端不允许建立拥塞控制机制连接，而第二设备端允许建立拥塞控制机制连接的情况下，不违背第二设备端侧的拥塞控制机制使用意愿，在第二设备端设置拥塞控制机制处于启用状态，从而提升拥塞控制机制的适用场景。

在进一步的可选实现中，第二设备端在作为发送数据流的源端时，如果检测到数据流在网络中出现拥塞，则第二设备端可利用拥塞控制机制，在协议栈层面，降低数据流的发送速率。在可选实现，第二设备端如果从第一设备端获取到ECE字段的值为1的ACK报文，则视为检测第二设备端发送的数据流在网络中出现拥塞。例如，第二设备端发送的数据流的数据包的CE字段，被中间设备标记了拥塞标记；则第一设备端在获取到中间设备传递的CE字段被标记的数据包后，可基于CE字段被标记的数据包，将发送给第二设备端的ACK报文中的ECE字段的值设置为1，以使得第二设备端检测到数据流在网络中出现拥塞；进而，第二设备端可利用拥塞控制机制，在协议栈层面，对CE字段被标记的数据包所对应的数据流进行降速处理。例如，利用拥塞控制机制，在协议栈层面，降低CE字段被标记的数据包所对应的数据流的发送窗口。

在进一步的可选实现中，第二设备端在作为发送数据流的源端时，如果第二设备端检测到数据流在网络中出现拥塞时，则第二设备端的智能网卡，还可利用Meter表，对数据流进行限速。

为便于进一步理解本申请实施例提供的方案，以ECN为例，下面结合表2示例的几种情况，对本申请实施例提供的数据流的速率控制方案进行介绍。结合表2所示，针对情况一，客户端的ECN状态值为1，服务端的ECN状态值为1或2，本申请实施例不需修改客户端和服务端的握手连接报文；

针对情况四，客户端的ECN状态值为0或2，服务端的ECN状态值为0，本申请实施例虽然修改了客户端和服务端的握手连接报文，但是在修改客户端的握手连接报文后，服务端本身不响应ECN连接请求；在修改服务端的握手连接报文后，客户端本身不主动发起ECN连接请求；因此本申请实施例在情况四下对客户端和服务端的握手连接报文进行修改，并无法使得客户端和服务端中的任一方，将与关于ECN状态的状态机转移到启用状态（例如TCP_ECN_OK状态）；

针对情况二，客户端的ECN状态值为0或2，服务端的ECN状态值为1或2，通过修改客户端的握手连接报文，可在服务端本身允许被动响应ECN连接请求的情况下，使得服务端认为客户端期望与服务端建立ECN连接，进而在不违背服务端的ECN机制使用意愿的情况下，服务端可将与关于ECN状态的状态机转移到启用状态，以使得服务端能够使用ECN机制；

针对情况三，客户端的ENC状态值为1，服务端的ENC状态值为0，通过修改服务端的握手连接报文，可在客户端本身会主动发起ECN连接请求的情况下，使得客户端认为服务端期望与客户端建立ECN连接，进而在不违背客户端的ECN机制使用意愿的情况下，客户端可将与关于ECN状态的状态机转移到启用状态，以使得客户端能够使用ECN机制。

需要说明的是，本申请实施例虽然对客户端的握手连接报文，和服务端的握手连接报文进行了修改，但是在握手连接过程，本申请实施例只是对客户端的SYN报文，和服务端的SYN-ACK报文进行了修改，只是修改2个报文，因此本申请实施例对于报文的修改开销较低，并且本申请实施例可在情况二和情况三的场景下，使得服务端或者客户端能够启用ECN机制，实现在协议栈层面对数据流进行无损反压，因此相比于修改报文的较低开销，本申请实施例能够获得更高的数据流传输可靠性和ECN机制的适用性。

基于情况二的场景，作为可选实现，图6示例性的示出了本申请实施例提供的数据流的速率控制方法的另一可选流程图。参照图6，该方法流程可以包括如下步骤。

在步骤S610中，客户端的智能网卡，获取客户端的SYN报文；所述SYN报文携带有CWR字段和ECE字段。

作为可选实现，客户端的SYN报文携带有指示客户端的ECN状态的状态字段，该状态字段可以包括CWR字段和ECE字段，状态字段的值可以确定ECN状态；例如，客户端的ECN状态值为0或2，则SYN报文中CWR字段和ECE字段的值均为0；又例如，客户端的ECN状态值为1，则SYN报文中CWR字段和ECE字段的值均为1。

在可选实现中，智能网卡可以分析客户端报文的FLAG（标示）信息，以确定客户端的报文是否为SYN报文。

在步骤S611中，如果SYN报文携带的CWR字段和ECE字段的值均为0，客户端的智能网卡将SYN报文携带的CWR字段和ECE字段的值均修改为1。

客户端的ECN状态处于第二状态时（第二状态即主动发起ECN连接请求，并且被动响应ECN连接请求的状态），ECN状态值为1，相应的CWR字段和ECE字段的值为1。客户端的ECN状态不为第二状态，则客户端的ECN状态可能为第一状态（ECN状态值为0），也可能为默认状态（ECN状态值为2）。作为可选实现，如果SYN报文携带的CWR字段和ECE字段的值为0，则说明客户端的ECN状态值为0或2，客户端的ECN状态不处第二状态；此时，客户端的智能网卡可将SYN报文携带的CWR字段和ECE字段的值为修改为1，以使得修改后的状态字段的值，与ECN的第二状态相对应。

在步骤S612中，客户端的智能网卡将修改后的SYN报文，发送给服务端。

在步骤S613中，如果服务端的ECN状态值为1或2，则基于修改后的SYN报文，服务端将内核中关于ECN状态的状态机转移到TCP_ECN_OK状态。

服务端获取到客户端的智能网卡所发送的修改后的SYN报文后，基于修改后的SYN报文中CWR字段和ECE字段的值（值为1），可认为客户端期望与服务端建立ECN连接；进而，服务端可在自身的ECN状态处于第二状态（ECN状态值为1）或者默认状态（ECN状态值为2），即服务端至少可被动响应ECN连接请求的情况下，将内核中关于ECN状态的状态机转移到TCP_ECN_OK状态。

在TCP_ECN_OK状态下，服务端会响应一切ECN机制，从而当服务端发送的数据流在网络中拥塞（即服务端发送的数据流为大流）时，服务端可利用ECN机制，在服务端的协议栈层面，对数据流进行限速。也就是说，在可能的实现中，当客户端的ECN状态值为0或2，服务端的状态值为1或2时（表1的情况二），本申请实施例可将客户端的SYN报文中CWR字段和ECE字段的值修改为1（对应客户端的ECN状态值为1），从而在服务端侧实现启用ECN机制。

进一步结合图6所示，在步骤S614中，服务端将发送给客户端的数据流，传递给中间设备。

在步骤S615中，如果数据流在网络中出现拥塞，中间设备在数据流的数据包的CE字段标记拥塞标记。

服务端如果成为发送数据流的源端，则服务端可通过中间设备将数据流发送给客户端。数据流的数据包将在中间设备的消息队列中排队处理，如果数据流在网络中出现拥塞，则中间设备可在数据流的数据包的CE字段标记拥塞标记，以指示数据流出现拥塞。

作为可选实现，中间设备可在处理器利用率超过利用率阈值时，视为数据流在网络中出现拥塞，从而在数据流的数据包的CE字段标记拥塞标记。

作为可选实现，中间设备可将数据流的数据包的CE字段标记为1，以实现在数据包的CE字段标记拥塞标记。

在步骤S616中，中间设备将CE字段标记拥塞标记的数据包，传递给客户端。

在步骤S617中，客户端的智能网卡获取CE字段被标记拥塞标记的数据包，将客户端的ACK报文中的ECE字段的值设置为1，直至从服务端获取到CWR字段的值为1的报文。

在情况二下，由于客户端本身不响应ECN机制，因此对于发送给客户端的数据流，客户端的智能网卡可获取数据流的数据包（例如客户端的智能网卡可劫持，发送给客户端的数据流的数据包），从而在数据包的CE字段被标记拥塞标记的情况下，模拟响应ECN机制。

在模拟响应ECN机制的可选实现中，客户端的智能网卡可将客户端的ACK报文中的ECE字段的值设置为1，以模拟客户端对于ECN机制的响应。上述模拟响应ECN机制的过程，可以在客户端的智能网卡获取到服务端发送的值为1的CWR字段的报文时停止。

在步骤S618中，客户端的智能网卡将ECE字段的值为1的ACK报文，发送给服务端。

在步骤S619中，服务端利用ECN机制，在协议栈层面，降低数据流的发送速率；以及服务端的智能网卡根据Meter表，对数据流进行限速。

在步骤S620中，服务端将下一个报文中的CWR字段的值设置为1，并将下一个报文发送给客户端。

客户端的智能网卡模拟响应ECN机制，将ECE字段的值为1的ACK报文发送给服务端后，服务端可获取到ECE字段的值为1的ACK报文，从而服务端可确认数据流在网络中出现拥塞，进而服务端可利用启用状态的ECN机制，在协议栈层面对数据流进行限速处理（即在协议栈层面，降低数据流的发送速率）。在可选实现中，服务端可利用拥塞控制机制，在协议栈层面，降低CE字段被标记的数据包所对应的数据流的发送窗口，以对数据流进行限速。在本申请实施例的进一步实现中，为了防止协议栈对于数据流的速率降低不到位，或者服务端无法成功设置状态机到TCP_ECN_OK状态，服务端的智能网卡还可利用Meter表，对数据流进行限速。进一步的，服务端在获取到ECE字段为1的ACK报文，并且对数据流进行限速后，服务端可将下一个报文中的CWR字段的值设置为1，并发送给客户端。

作为可选实现，Meter表可以通过依赖令牌桶的丢包机制，来实现数据流的限速。例如，针对数据流，可以在一段时间内，给定有限的令牌数量；从而，每发送数据流的一个数据包，则消耗一个令牌；当令牌消耗完毕后，所有数据包都将被丢弃；在一段时间过后，可以刷新令牌桶中令牌的数量，以此反复执行。通过这种方式可以使大流的速率受到限制，而小流的速率不受影响。

Meter表的数据流限速方式存在一定的问题：第一，会产生大量的连续丢包，对用户体验造成明显的下降；第二，令牌消耗完毕后，所有数据包都将被丢弃的限速方式，会使得数据流的流量速率从微观角度呈现剧烈抖动的状态，即数据流在一段时间内的流量速率很高，而一段时间过后，数据流的流量速率归零，以此不断循环往复。虽然从较长时间窗口的角度观察，数据流的平均速率相对稳定，但是较短时间窗口则是呈现极大偏差，这可能会造成中间设备的消息队列长度也出现较大变化。

基于此，基于Meter表在源端的智能网卡的层面，对数据流进行限速作为本申请实施例提供的进一步完善方案。也就是说，本申请实施例利用ECN等拥塞控制机制，在源端的协议栈层面对数据流进行限速的基础上，进一步利用Meter表在智能网卡的层面，对数据流进行限速，可以进一步完善数据流的限速效果。

例如，针对UDP协议等没有定义拥塞控制机制的传输协议下，本申请实施例可以利用Meter表，在源端的智能网卡层面，对UDP大流进行限速。在源端无法成功设置状态机到TCP_ECN_OK状态时，本申请实施例可以利用Meter表，在源端的智能网卡层面，对数据流进行限速。在源端成功设置状态机到TCP_ECN_OK状态时，但是源端利用ECN机制，在协议栈层面对数据流进行限速的效果不佳时，本申请实施例可以利用Meter表，在源端的智能网卡层面，对数据流进行进一步限速。本申请实施例提供的方案进一步利用Meter表的限速方式，可使得本申请实施例对源端数据流进行反压的效果更为精准。

需要说明的是，本申请实施例提供的方案中所示例的具体数值0，1和2仅是一种可选示例，例如，0仅是第零预设值的可选示例，1仅是第一预设值的可选示例，2仅是第二预设值的可选示例。

基于情况三的场景，作为可选实现，图7示例性的示出了本申请实施例提供的数据流的速率控制方法的再一可选流程图。参照图7，该方法流程可以包括如下步骤。

在步骤S710中，服务端的智能网卡，获取服务端的SYN-ACK报文；所述SYN-ACK报文携带有ECE字段。

作为可选实现，服务端的SYN-ACK报文携带有指示服务端的ECN状态的状态字段，该状态字段可以包括ECE字段，状态字段的值可以确定ECN状态。

在步骤S711中，如果SYN-ACK报文携带的ECE字段的值不为1，服务端的智能网卡将SYN-ACK报文携带的ECE字段的值修改为1。

服务端的ECN状态为不响应ECN连接请求（例如第一状态），则服务端的ECN状态值为0，相应的，服务端在SYN-ACK报文携带的ECE字段的值不为1；此时，服务端的智能网卡可将SYN-ACK报文携带的ECE字段的值修改为1。

在步骤S712中，服务端的智能网卡将修改后的SYN-ACK报文，发送给客户端。

在步骤S713中，如果客户端的ECN状态值为1，则基于修改后的SYN-ACK报文，客户端将内核中关于ECN状态的状态机转移到TCP_ECN_OK状态。

客户端的ECN状态值为1，说明客户端能够主动发起ECN连接请求，并且被动响应ECN连接请求；基于修改后的SYN-ACK报文携带的ECE字段的值（值为1），客户端可认为服务端期望与客户端建立ECN连接；进而，客户端可在自身的ECN状态值为1时，将内核中关于ECN状态的状态机转移到TCP_ECN_OK状态。

进一步结合图7所示，在步骤S714中，客户端将发送给服务端的数据流，传递给中间设备。

在步骤S715中，如果数据流在网络中出现拥塞，中间设备在数据流的数据包的CE字段标记拥塞标记。

在步骤S716中，中间设备将CE字段标记拥塞标记的数据包，传递给服务端。

在步骤S717中，服务端的智能网卡获取CE字段被标记拥塞标记的数据包，将服务端的ACK报文中的ECE字段的值设置为1，直至从客户端获取到CWR字段的值为1的报文。

在步骤S718中，服务端的智能网卡将ECE字段的值为1的ACK报文，发送给客户端。

在步骤S719中，客户端利用ECN机制，在协议栈层面，降低数据流的发送速率；以及客户端的智能网卡根据Meter表，对数据流进行限速。

在步骤S720中，客户端将下一个报文中的CWR字段的值设置为1，并将下一个报文发送给服务端。

可以理解是，图6和图7所示流程的原理类似。图6所示方法流程是在客户端的ECN状态值为0或2，不允许建立ECN连接，而服务端的ECN状态值为1或2，允许建立ECN连接的情况下，通过修改客户端的SYN报文，以使得服务端认为客户端期望建立ECN连接；从而，服务端可将ECN状态的状态机转移到启用状态，进而在服务端作为发送数据流的源端时，可利用ECN机制，在协议栈层面对数据流进行限速；进一步的，服务端作为源端时，还可在智能网卡层面，利用Meter表，对数据流进行限速。

而图7所示方法是在客户端的ENC状态值为1，允许建立ECN连接，而服务端的ECN状态值为0，不允许建立ECN连接的情况下，通过修改服务端的SYN-ACK报文，以使得客户端认为服务端期望建立ECN连接；从而，客户端可将ECN状态的状态机转移到启用状态，进而在客户端作为发送数据流的源端时，可利用ECN机制，在协议栈层面对数据流进行限速；进一步的，客户端作为源端时，还可在智能网卡层面，利用Meter表，对数据流进行限速。

图6和图7所示流程中原理类似的部分可相互参照，此处不再展开。需要说明的是，本申请实施例虽然是通过修改握手连接报文，以使得客户端或服务端的协议栈，认为进行握手连接的另一端期望建立ECN连接；但是，本申请实施例提供的方案是建立在客户端或服务端中的一端本身允许建立ECN连接的前提下，并且，启用ECN机制的一端也是本身允许建立ECN连接的这一端，因此本申请实施例提供的方案并不违背本身允许建立ECN连接的设备端的意愿。以情况三为例，对于情况三，客户端的ECN状态值为1，而服务端的ECN状值为0，客户端本身是希望主动建立ECN连接的，但是服务端并不希望建立ECN连接；此时本申请实施例提供的方案，通过修改服务端的SYN-ACK报文，从而使得客户端认为服务端是期望建立ECN连接的状态，进而本申请实施例可在本身就希望建立ECN连接的客户端启用ECN机制，来在客户端的协议栈层面对数据流进行反压，因此并没有违背客户端的意愿。

下面对不修改握手连接报文情况下的数据流传输效果，源端的智能网卡使用Meter表情况下的数据流传输效果，以及本申请实施例提供的数据流传输效果进行说明。本申请实施例可以在修改握手连接报文的情况下，在源端的协议栈层面对数据流进行无损反压，并且在源端的智能网卡层面，利用Meter表对数据流进行限速。

在不修改握手连接报文的情况下，仅基于客户端和服务端本身的ECN状态，进行协议栈层面的数据流限速（客户端和服务端协商的ECN状态能够建立ECN连接时，客户端和服务端中发送数据流的源端，可利用ECN机制，在协议栈层面对数据流进行限速），则源端发送数据流的速率会受到CE字段被标记频率的影响；当CE字段被标记频率较高时，数据流的发送速率较低。这意味着，如果CE字段的被标记频率设置不当，有可能无法很好地保护中间设备。另外，由于ECN机制能够实现在协议栈层面，对数据流进行无损反压，因此无论CE字段被标记频率是较高或较低，数据流的丢包重传都很少。而对于源端的智能网卡使用Meter表情况下的数据流传输效果进行分析，Meter表的使用会引入大量的丢包重传情况。

本申请实施例提供的方案，结合修改握手连接报文的方式以及Meter表技术，可以使得数据流的速率不受CE字段被标记频率的影响，这是因为有着Meter表作为数据流限速的后备限速手段，解决了协议栈限速不到位的问题。当数据流的CE字段被标记频率较高时，本申请实施例可以利用ECN机制，在协议栈层面实现数据流的无损反压；当数据流的CE字段被标记频率较低时，本申请实施例可使用Meter表，对数据流进行限速。

本申请实施例还提供一种智能网卡，该智能网卡可被配置为，执行本申请实施例提供的数据流的速率控制方法。该智能网卡可以设置于云端设备，并且在云端设备与另一云端设备进行握手连接时，执行本申请实施例提供的数据流的速率控制方法。设置智能网卡的云端设备可能是发起握手连接的客户端，也可能是响应握手连接的服务端。

作为可选实现，图8示例性的示出了本申请实施例提供的智能网卡的可选框图，该框图可以视为是智能网卡中的片上处理器部分对应的系统结构，如图8所示，智能网卡可以包括至少一个处理器81，至少一个通信接口82，至少一个存储器83和至少一个通信总线84。

在本申请实施例中，处理器81、通信接口82、存储器83、通信总线84的数量为至少一个，且处理器81、通信接口82、存储器83通过通信总线84完成相互间的通信。

可选的，通信接口82可以为用于进行网络通信的通信模块的接口。

可选的，处理器81可能是中央处理器，GPU（Graphics Processing Unit，图形处理器），NPU（嵌入式神经网络处理器），FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列），TPU（张量处理单元），AI芯片，特定集成电路ASIC（Application SpecificIntegrated Circuit），或者是被配置成实施本申请实施例的一个或多个集成电路等。

存储器83可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatilememory），例如至少一个磁盘存储器。

其中，存储器83存储一条或多条计算机可执行指令，处理器81调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的数据流的速率控制方法。

本申请实施例还提供一种云端设备，例如云端的服务器主机，该云端设备可以设置有本申请实施例提供的智能网卡。

本申请实施例还提供一种存储介质，该存储介质存储有一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时，实现如本申请实施例提供的数据流的速率控制方法。

本申请实施例还提供一种计算机程序，该计算机程序被执行时，实现如本申请实施例提供的数据流的速率控制方法。

上文描述了本申请实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本申请实施例披露、公开的实施例方案。

虽然本申请实施例披露如上，但本申请并非限定于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。

Claims (14)

1.一种数据流的速率控制方法，其中，应用于智能网卡，所述智能网卡设置于第一设备端；所述方法包括：

获取第一设备端的握手连接报文，所述握手连接报文用于所述第一设备端与第二设备端进行握手连接，并且所述握手连接报文指示有所述第一设备端的拥塞控制机制状态；

如果所述握手连接报文指示的拥塞控制机制状态为所述第一设备端不允许建立拥塞控制机制连接，则将所述握手连接报文指示的拥塞控制机制状态，修改为所述第一设备端允许建立拥塞控制机制连接的状态，以得到修改后的握手连接报文；

将修改后的握手连接报文发送给所述第二设备端，以在所述第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接时，使得所述第二设备端设置所述第二设备端的拥塞控制机制处于启用状态；其中，所述第二设备端的拥塞控制机制用于在所述第二设备端发送的数据流在网络中出现拥塞时，在所述第二设备端的协议栈层面降低数据流的发送速率。

2.根据权利要求1所述的方法，其中，所述如果所述握手连接报文指示的拥塞控制机制状态为所述第一设备端不允许建立拥塞控制机制连接，则将所述握手连接报文指示的拥塞控制机制状态，修改为所述第一设备端允许建立拥塞控制机制连接的状态，以得到修改后的握手连接报文包括：

如果所述握手连接报文携带的状态字段的值，指示所述第一设备端不允许建立拥塞控制机制连接，则对所述握手连接报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与所述第一设备端允许建立拥塞控制机制连接的状态相对应；其中，状态字段的值与拥塞控制机制状态值相对应，不同的拥塞控制机制状态值对应不同的拥塞控制机制状态。

3.根据权利要求2所述的方法，其中，所述第一设备端为发起握手连接的客户端，所述第二设备端为响应握手连接的服务端，所述握手连接报文为SYN报文；

所述如果所述握手连接报文携带的状态字段的值，指示所述第一设备端不允许建立拥塞控制机制连接，则对所述握手连接报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与所述第一设备端允许建立拥塞控制机制连接的状态相对应包括：

如果所述SYN报文携带的状态字段的值，指示所述客户端的拥塞控制机制不处于主动发起拥塞控制机制连接请求的状态，则对所述SYN报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与所述客户端主动发起拥塞控制机制连接请求的状态相对应。

4.根据权利要求3所述的方法，其中，所述将修改后的握手连接报文发送给所述第二设备端，以在所述第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接时，使得所述第二设备端设置所述第二设备端的拥塞控制机制处于启用状态包括：

将修改后的SYN报文发送给所述服务端，以在所述服务端的拥塞控制机制状态为被动响应拥塞控制机制连接请求的状态时，使得所述服务端设置所述服务端的拥塞控制机制处于启用状态。

5.根据权利要求4所述的方法，其中，所述拥塞控制机制包括ECN，所述SYN报文中的状态字段包括CWR字段和ECE字段；

所述如果所述SYN报文携带的状态字段的值，指示所述客户端的拥塞控制机制不处于主动发起拥塞控制机制连接请求的状态，则对所述SYN报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与所述客户端主动发起拥塞控制机制连接请求的状态相对应包括：

如果所述SYN报文携带的CWR字段和ECE字段的值均为0，将所述SYN报文携带的CWR字段和ECE字段的值均修改为1；

其中，所述SYN报文携带的CWR字段和ECE字段的值均为0，则表示所述客户端的ECN状态值为0或2，所述客户端处于不主动发起ECN连接请求的状态；所述SYN报文携带的CWR字段和ECE字段的值均为1，则表示所述客户端的ECN状态值为1，所述客户端处于主动发起ECN连接请求的状态。

6.根据权利要求5所述的方法，其中，所述将修改后的SYN报文发送给所述服务端，以在所述服务端的拥塞控制机制状态为被动响应拥塞控制机制连接请求的状态时，使得所述服务端设置所述服务端的拥塞控制机制处于启用状态包括：

将修改后的SYN报文发送给所述服务端，以在所述服务端的ECN状态值为1或2时，使得所述服务端将内核中关于ECN状态的状态机转移到启用状态；其中，所述服务端的ECN状态值为1或2，则所述服务端处于被动响应ECN连接请求的状态。

7.根据权利要求3-6任一项所述的方法，其中，还包括：

通过中间设备获取服务端发送的数据流，其中，所述数据流在网络中出现拥塞时，所述数据流的数据包的CE字段被所述中间设备标记有拥塞标记；

如果检测到标记有拥塞标记的数据包，将发送给服务端的ACK报文中的ECE字段的值设置为1，以通知服务端的数据流在网络中出现拥塞，直至获取到服务端发送的CWR字段的值为1的报文；

其中，所述服务端获取到ECE字段为1的ACK报文后，所述服务端利用拥塞控制机制，在协议栈层面，降低数据流的发送速率；并且，所述服务端的智能网卡利用Meter表，对数据流进行限速处理；以及，所述服务端将下一个报文中的CWR字段的值设置为1。

8.根据权利要求2所述的方法，其中，所述第一设备端为响应握手连接的服务端，所述第二设备端为发起握手连接的客户端，所述握手连接报文为SYN-ACK报文；

所述如果所述握手连接报文携带的状态字段的值，指示所述第一设备端不允许建立拥塞控制机制连接，则对所述握手连接报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，与所述第一设备端允许建立拥塞控制机制连接的状态相对应包括：

如果所述SYN-ACK报文携带的状态字段的值，指示所述服务端的拥塞控制机制处于不响应拥塞控制机制连接请求的状态，则对所述SYN-ACK报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，至少与所述服务端处于被动响应拥塞控制机制连接请求的状态相对应。

9.根据权利要求8所述的方法，其中，所述将修改后的握手连接报文发送给所述第二设备端，以在所述第二设备端的拥塞控制机制状态为允许建立拥塞控制机制连接时，使得所述第二设备端设置所述第二设备端的拥塞控制机制处于启用状态包括：

将修改后的SYN-ACK报文发送给所述客户端，以在所述客户端的拥塞控制机制状态为主动发起拥塞控制机制连接请求的状态时，使得所述客户端设置所述客户端的拥塞控制机制处于启用状态。

10.根据权利要求9所述的方法，其中，所述拥塞控制机制包括ECN，所述SYN-ACK报文中的状态字段包括ECE字段；

所述如果所述SYN-ACK报文携带的状态字段的值，指示所述服务端的拥塞控制机制处于不响应拥塞控制机制连接请求的状态，则对所述SYN-ACK报文携带的状态字段的值进行修改，以使得修改后的状态字段的值，至少与所述服务端处于被动响应拥塞控制机制连接请求的状态相对应包括：

如果SYN-ACK报文携带的ECE字段的值不为1，将SYN-ACK报文携带的ECE字段的值修改为1；其中，所述服务端的ECN状态值为0，则所述服务端的SYN-ACK报文携带的ECE字段的值不为1，所述服务端的ECN状态值为0，表示所述服务端处于不响应ECN连接请求的状态；

所述将修改后的SYN-ACK报文发送给所述客户端，以在所述客户端的拥塞控制机制状态为主动发起拥塞控制机制连接请求的状态时，使得所述客户端设置所述客户端的拥塞控制机制处于启用状态包括：

将修改后的SYN-ACK报文发送给所述客户端，以在所述客户端的ECN状态值为1时，使得所述客户端将内核中关于ECN状态的状态机转移到启用状态。

11.根据权利要求8-10任一项所述的方法，其中，还包括：

通过中间设备获取客户端发送的数据流，其中，所述数据流在网络中出现拥塞时，所述数据流的数据包的CE字段被所述中间设备标记有拥塞标记；

如果检测到标记有拥塞标记的数据包，将发送给客户端的ACK报文中的ECE字段的值设置为1，以通知客户端的数据流在网络中出现拥塞，直至获取到客户端发送的CWR字段的值为1的报文；

其中，所述客户端获取到ECE字段为1的ACK报文后，所述客户端利用拥塞控制机制，在协议栈层面，降低数据流的发送速率；并且，所述客户端的智能网卡利用Meter表，对数据流进行限速处理；以及所述客户端将下一个报文中的CWR字段的值设置为1。

12.一种智能网卡，其中，所述智能网卡包括至少一个处理器和至少一个存储器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如权利要求1-11任一项所述的数据流的速率控制方法。

13.一种云端设备，其中，所述云端设备设置有如权利要求12所述的智能网卡。

14.一种存储介质，其中，所述存储介质存储有一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时，实现如权利要求1-11任一项所述的数据流的速率控制方法。

Images