CN117527699A - 一种网络流量转发方法、装置、设备及存储介质 - Google Patents

一种网络流量转发方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN117527699A
CN117527699A CN202311554213.4A CN202311554213A CN117527699A CN 117527699 A CN117527699 A CN 117527699A CN 202311554213 A CN202311554213 A CN 202311554213A CN 117527699 A CN117527699 A CN 117527699A
Authority
CN
China
Prior art keywords
flow
receiving end
forwarding
traffic
target
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.)
Pending
Application number
CN202311554213.4A
Other languages
English (en)
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.)
Sangfor Technologies Co Ltd
Original Assignee
Sangfor 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 Sangfor Technologies Co Ltd filed Critical Sangfor Technologies Co Ltd
Priority to CN202311554213.4A priority Critical patent/CN117527699A/zh
Publication of CN117527699A publication Critical patent/CN117527699A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H04L47/115—Identifying congestion using a dedicated packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种网络流量转发方法、装置、设备及存储介质，涉及计算机技术领域，包括：根据目标检测规则检测流量接收端是否处于超载状态；目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；若是，则将已建立连接的流量对应的数据包转发至流量接收端，并根据流量接收端的当前中央处理器负载与预设负载控制范围的关系确定流量转发概率；若流量接收端转为正常状态，则将已建立连接的流量对应的数据包转发至流量接收端，并根据流量转发概率将未建立连接的流量对应的数据包转发至流量接收端。本申请将转发至流量接收端的数据包控制在流量接收端的承受范围以内，并解决了流量转发过程中的网络拥塞和波动的问题。

Description

一种网络流量转发方法、装置、设备及存储介质
技术领域
本发明涉及计算机技术领域，特别涉及一种网络流量转发方法、装置、设备及存储介质。
背景技术
在网络流量的转发过程中，常常出现流量发送端的处理能力大于接收端的处理能力的场景。若某一段时间的实时流量大于接收端的处理能力，但小于发送端的处理能力，那么发送端流量便需要排队等待处理，因而导致网络拥塞或丢包。同时，接收端因数据包的内容不同所需的处理时间也随之变化。参见图1所示，现有两条流量转发路径，第一条为Service A---->Service B----->Service A----->Service C，第二条为Service A---->Service C。Service B在这里的作用是提供安全检测能力(可以是任何一个处理流量的组件)，其对所有输入流量进行处理后再返回Service A，Service A再转发至Service C继续处理。其中，Service B的处理能力小于Service A的处理能力，Service C的处理能力大于Service A的处理能力。当系统内的流量低于Service B的处理能力时，Service A走第一条流量转发路径。当系统内的流量大于Service B的处理能力时，Service A需尽可能保证在不超过Service B的处理能力下，走第一条流量转发路径，剩余超过Service B处理能力的流量则走第二条流量转发路径。
上述流量转发过程的困难点在于：如何使转发至Service B的流量不超过其处理能力，同时解决在流量转发的过程中的网络拥塞和波动的问题。
现有技术使用基于丢包的超载检测方案检测Service B的超载情况，但缺点在于该方案需保证一直有数据包从发送端流转到接收端，且未考虑在业务负载较低时，虽然接收端能够从缓冲区能够接收数据包，但在接收端处理时间较长时会导致超时的情况。同时该方案只能从发送端主动探测，缺乏接收端的自身负载反馈机制。现有技术使用基于滑动窗口模式的拥塞控制算法、基于流量计数器模式的流控算法和基于令牌桶的限流方法实现对转发至Service B的流量的动态截流，但缺点在于基于滑动窗口模式的拥塞控制算法实现太过复杂；基于流量计数器模式的流控算法流量波动太大，在并发场景下会变得卡慢；基于令牌桶的限流方法需要预知当前系统的处理能力，而系统的网络转发处理能力随着CPU(Central Processing Unit/Processor，中央处理器)型号，流量类型等因素在变化，无法在出厂时预设一个定值。
因此，上述技术问题亟待本领域技术人员解决。
发明内容
有鉴于此，本发明的目的在于提供一种网络流量转发方法、装置、设备及存储介质，能够将转发至流量接收端的数据包控制在流量接收端的承受范围以内，并解决了流量转发过程中的网络拥塞和波动的问题。其具体方案如下：
本申请的第一方面提供了一种网络流量转发方法，应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；
如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；
若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
可选的，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
统计所述目标定时周期内向所述流量接收端发送的数据包总包数，并统计所述目标定时周期内向所述流量接收端发送失败的数据包丢包数；
根据所述数据包丢包数和所述数据包总包数计算丢包率，如果所述丢包率大于预设丢包率阈值，则判定所述流量接收端处于所述超载状态。
可选的，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
分别统计若干个所述目标定时周期内所述心跳包的发送时间与所述心跳包的接收时间的时间差，得到若干个所述时间差；
如果若干个所述时间差在若干个所述目标定时周期内的平均值大于预设时间差阈值，则判定所述流量接收端处于所述超载状态。
可选的，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
如果所述心跳包在所述目标定时周期内发生丢包，则直接判定所述流量接收端处于所述超载状态。
可选的，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率，包括：
如果所述当前中央处理器负载小于所述预设负载控制范围的下限值，则将当前流量转发概率与第一数值的乘积确定为所述目标流量转发概率；
如果所述当前中央处理器负载不小于所述预设负载控制范围的下限值，并且所述当前中央处理器负载不大于所述预设负载控制范围的上限值，则将所述当前流量转发概率确定为所述目标流量转发概率；
如果所述当前中央处理器负载大于所述预设负载控制范围的上限值，则将所述当前流量转发概率与第二数值的乘积确定为所述目标流量转发概率；
其中，所述第一数值大于1，所述第二数值小于1，所述当前流量转发概率和所述目标流量转发概率均不大于1。
可选的，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率之后，还包括：
将所述当前流量转发概率与第三数值的乘积确定为初始流量转发概率；其中，所述第三数值小于所述第二数值；
相应的，若检测到所述流量接收端由所述超载状态转为正常状态，则根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端，包括
若检测到所述流量接收端由所述超载状态转为所述正常状态，则根据所述初始流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端；
在预设时间段以内，判断所述流量接收端是否仍保持在所述正常状态，如果是则根据所述目标流量转发概率和预设转发概率增长幅度限定规则确定新目标流量转发概率，并根据所述新目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端；
在所述预设时间段以外，判断所述流量接收端是否仍保持在所述正常状态，如果是则直接根据所述目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端。
可选的，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率之前，还包括：
获取所述流量接收端基于预设负载计算规则计算并反馈的所述当前中央处理器负载；其中，所述预设负载计算规则为根据所述流量接收端收空包所耗时间在所述目标定时周期中所占的比重所构建的计算规则。
本申请的第二方面提供了一种网络流量转发装置，应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
超载状态判断模块，用于根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；
流量转发概率确定模块，用于如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；
流量转发模块，用于若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
本申请的第三方面提供了一种电子设备，所述电子设备包括处理器和存储器；其中所述存储器用于存储计算机程序，所述计算机程序由所述处理器加载并执行以实现前述网络流量转发方法。
本申请的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现前述网络流量转发方法。
本申请中，根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
综上可见，一方面，本申请基于数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则实现对流量接收端的超载状态的判断，相对于传统方案，本申请在判断流量接收端是否处于超载状态时，增加了心跳包丢包的判断以及心跳包收发时间差的判断，提高对流量接收端超载判断的准确性。同时，本申请在每一目标定时周期内，向流量接收端发送一次心跳包，并提出流量接收端向流量发送端反馈自身的当前中央处理器负载这一机制，使得业务低谷无流量的场景下依然能够检测流量接收端的状态，以确保服务正常。另一方面，本申请在判断出流量接收端处于超载状态后，仅将已建立连接的流量对应的第一数据包转发至流量接收端，能够一定程度上缓解流量接收端的负载压力，同时保证流量接收端在下一个定时周期内不会处于立刻空闲状态，避免出现流量波动。进一步的，本申请会根据流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率，使得基于目标流量转发概率转发至流量接收端的第二数据包控制在流量接收端的承受范围以内，解决了流量转发过程中的网络拥塞。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为一种流量转发路径示意图；
图2为本申请提供的一种网络流量转发方法的流程图；
图3为本申请提供的一种具体的网络流量转发方法的流程图；
图4为本申请提供的一种超载状态的切换示意图；
图5为本申请提供的一种流量转发概率的示意图；
图6为本申请提供的一种流量转发增长斜率的变化示意图；
图7为本申请提供的一种具体的网络流量转发方法的流程图；
图8为一种使用本方法前的网络波动及转发能力示意图；
图9为一种使用本方法后的网络波动及转发能力示意图；
图10为本申请提供的一种网络流量转发装置结构示意图；
图11为本申请提供的一种网络流量转发电子设备结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
现有技术使用基于丢包的超载检测方案检测Service B的超载情况，但缺点在于该方案需保证一直有数据包从发送端流转到接收端，且未考虑在业务负载较低时，虽然接收端能够从缓冲区能够接收数据包，但在接收端处理时间较长时会导致超时的情况。同时该方案只能从发送端主动探测，缺乏接收端的自身反馈机制。现有技术使用基于滑动窗口模式的拥塞控制算法、基于流量计数器模式的流控算法和基于令牌桶的限流方法实现对转发至Service B的流量的动态截流，但缺点在于基于滑动窗口模式的拥塞控制算法实现太过复杂；基于流量计数器模式的流控算法流量波动太大，在并发场景下会变得卡慢；基于令牌桶的限流方法需要预知当前系统的处理能力，而系统的网络转发处理能力随着CPU型号，流量类型等因素在变化，无法在出厂时预设一个定值。
图2为本申请实施例提供的一种网络流量转发流程图。参见图2所示，该网络流量转发方法应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
S11：根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种。
仍以图1所示的两条流量转发路径为例，图1中的Service A指代本实施中的流量发送端，Service B指代优先级高于Service C的流量接收端，其中，Service B采用进程独占单核的模型。本实施例中的具体应用场景可以是网络流量转发过程中的负载均衡场景，例如应用于含多核CPU架构的云场景下的网络流量转发场景。示例性的，网络数据面处理完数据后会转发给网卡，由网卡发送出去，其转发路径原本是Service A到Service C，为了增加网络数据的安全性，会增加一个中间安全设备Service B，Service B是基于DPDK(DataPlane Development Kit，数据平面开发套件)的具备流量安全预处理能力接收端，例如虚拟防火墙等具有数据预处理功能的设备，这样一来，将Service A的数据重定向到ServiceB，经过Service B的流量过滤(预处理)后再转发给Service C。
由上述内容可知，图3中的流量重定向是指Service A先将流量转发至Service B，经过Service B的处理后，返回至Service A，再由Service A转发至Service C。需要指出的是，图3中的Service A和Service B之间维护了定时器，Service A会按照目标定时周期向Service B发送心跳包，Service B在接收到心跳包后，会在所述目标定时周期内向ServiceA返回心跳包，若Service A在所述目标定时周期内未接收到Service B返回的心跳包，则表明所述心跳包发生丢包。此外，Service A和Service B通过队列(virtqueue)进行数据包的发送与接收，队列有容量限制，如果Service B接收不及时，导致virtqueue中无空余容量，那么Service A发送的数据包就会进入队列失败，从而导致数据包发生丢包。
进一步的，本实施例根据数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种目标检测规则实现对所述流量接收端的超载状态的检测。
在一种具体的实施方式中，根据数据包丢包规则对所述流量接收端进行超载状态的检测，包括：统计所述目标定时周期内向所述流量接收端发送的数据包总包数，并统计所述目标定时周期内向所述流量接收端发送失败的数据包丢包数，然后根据所述数据包丢包数和所述数据包总包数计算丢包率，如果所述丢包率大于预设丢包率阈值，则判定所述流量接收端处于超载状态，可以理解的是，所述丢包率为所述数据包丢包数与所述数据包总包数相除。
在第二种具体的实施方式中，根据心跳包丢包规则对所述流量接收端进行超载状态的检测，包括：如果心跳包在所述目标定时周期内发生丢包，则直接判定所述流量接收端处于超载状态。
在第三种具体的实施方式中，根据心跳包收发时间差规则对所述流量接收端进行超载状态的检测，包括：分别统计若干个所述目标定时周期内所述心跳包的发送时间与所述心跳包的接收时间的时间差，得到若干个所述时间差，如果若干个所述时间差在若干个所述目标定时周期内的平均值大于预设时间差阈值，则判定所述流量接收端处于所述超载状态。具体的，每一个心跳包上都会记录心跳包发送时间，Service B在收到心跳包后，会填上接收时间以及当前CPU负载，然后返回给Service A，Service A对发送时间和接收时间作差，得到时间差，如果若干个目标定时周期内的时间差的平均值超过预设时间差阈值，则判定Service B处于超载状态，例如，如果连续5个目标定时周期内的5个心跳包的时间差的平均值超过预设时间差阈值，则认为Service B处于超载状态。
参见图4所示，当检测到流量接收端心跳包丢失或时间差的平均值超过预设时间差阈值或丢包率超过预设丢包率阈值时，则判定所述流量接收端处于超载状态，当检测到无心跳包丢失且时间差的平均值未超过所述预设时间差阈值以及丢包率未超过所述预设丢包率阈值时，则判定所述流量接收端恢复正常状态。
S12：如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率。
本实施例中，如果检测到所述流量接收端处于所述超载状态，则仅将已建立连接的流量对应的第一数据包转发至所述流量接收端，相对于传统方案在检测到Service B超载后立刻不再将流量转发至Service B，导致Service B在处理完队列内的数据包后，会在下一个定时器周期处于空闲状态，由此产生流量波动，本实施例通过控制部分流量转发一定程度上避免了流量波动的产生。
进一步的，传统方案在检测到Service B不再处于超载状态后，又重新将流量全部转发至Service B，由于流量足够大，会导致Service B还未来得处理及更新状态便已经丢包，等到下一个定时周期，通过心跳包更新状态后，Service B又恢复至超载状态，如此反复，导致产生流量波动，且Service B的网络处理能力也无法发挥。
为了解决上述问题，本实施例引入了流量转发概率的概念，通过流量转发概率避免将所有流量转发至Service B，以避免短时间内又达到Service B的处理上限导致产生流量波动。参见图5所示，流量转发概率是指对于所有新建立连接的流量，Service A将以概率p将该流量转发至Service B，此处概率的精度为1/10000，具体的，对于某一流量，为该流量取一个范围在1/10000至1的随机值，并将其和流量转发概率作比较，若小于p，则进行引流转发，否则直接将其发送给Service C，也即，本实施例通过引入流量转发概率，允许了部分流量进入转发逻辑，其他流量不进入转发逻辑，直接发送给Service C。可以理解的是，转发逻辑是指Service A先将流量转发至Service B，经过Service B的处理后，返回至ServiceA，再由Service A转发至Service C。
为了保证转发至Service B的流量控制在Service B的承受范围以内，并为了使Service B能够发挥较大的处理能力，在已知Service B采用进程独占单核的模型，因此Service B的当前CPU负载可以体现出其实时处理能力的基础上，本实施例根据Service B反馈的当前CPU负载与预设负载控制范围的关系确定流量转发概率，得到目标流量转发概率。
在一种具体的实施方式中，如果所述当前中央处理器负载小于所述预设负载控制范围的下限值，则将当前流量转发概率与第一数值的乘积确定为所述目标流量转发概率。
在第二种具体的实施方式中，如果所述当前中央处理器负载不小于所述预设负载控制范围的下限值，并且所述当前中央处理器负载不大于所述预设负载控制范围的上限值，则将所述当前流量转发概率确定为所述目标流量转发概率。
在第三种具体的实施方式中，如果所述当前中央处理器负载大于所述预设负载控制范围的上限值，则将所述当前流量转发概率与第二数值的乘积确定为所述目标流量转发概率。其中，所述第一数值大于1，所述第二数值小于1，所述当前流量转发概率和所述目标流量转发概率均不大于1。
下面通过一具体实施例对上述内容进行说明，相关变量cur_available_session_rate表示当前流量转发概率p，其初始状态为10000/10000，cur_available_session_rate需要限制在[rate_min(1)，rate_max(10000)]之间，对于cur_available_session_rate，在定时器触发时进行维护。load_status表示Service B的当前CPU负载百分比，期望将load_status收敛至[load_min(85)，load_max(90)]之间。
参见图6所示，在一种具体的实施方式中，如果load_status<load_min/2，则说明Service B的当前CPU负载低于期望控制的负载最低值的1/2，说明Service B的当前的处理能力可以完全处理当前所转发的流量，因此，本实施例将当前流量转发概率×2，得到目标流量转发概率new_available_session_rate＝cur_available_session_rate×2，可以看出图6中的第一阶段的转发概率增长斜率为2。
在第二种具体的实施方式中，如果load_min/2<load_status<load_min，期望将流量转发概率调整至[load_min，load_max]内，但又不希望流量转发概率以2倍速度增加过快导致丢包，因此本实施例将当前流量转发概率×(load_min+load_max)/2×load_status，得到目标流量转发概率new_available_session_rate＝cur_available_session_rate×(load_min+load_max)/2×load_status，可以理解的是，当load_min/2<load_status<load_min时，1<(load_min+load_max)/2×load_status<2，可以看出图6中的第二阶段的转发概率增长斜率在1和2之间。
在第三种具体的实施方式中，如果load_min<load_status<load_max，说明转发的流量适当，则保持当前流量概率不变即可，也即将当前流量转发概率确定为所述目标流量转发概率，可以看出图6中的第三阶段的转发概率增长斜率为1。
在第四种具体的实施方式中，如果load_max<load_status，则说明Service B的当前CPU负载已经超过期望的上限值，此时通常会产生丢包和卡慢等情况，因此需要将转发的流量调小，为此本实施例将当前流量转发概率×(load_min+load_max)/2×load_status，得到目标流量转发概率new_available_session_rate＝cur_available_session_rate×(load_min+load_max)/2×load_status，可以理解的是，当load_max<load_status时，(load_min+load_max)/2×load_status<1，可以看出图6中的第四阶段的转发概率增长斜率小于1。
综上可见，本申请通过调整流量转发概率，实现在不同流量场景对流量的转发控制，从而实现对Service B的当前CPU负载的控制，以减少流量波动和网络阻塞。
S13：若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
本实施例中，若Service B由超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至Service B，并根据基于上述过程确定的所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至Service B。
综上可见，本申请解决了流量从转发到不转发的切换过程中的流量波动问题，在转发至Service B的流量超过了Service B的处理能力时，实现部分流量转发部分流量不转发的平衡态，并可以随着流量峰值的变化，保持稳定和自动切换。
本申请中，根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。综上可见，一方面，本申请基于数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则实现对流量接收端的超载状态的判断，相对于传统方案，本申请在判断流量接收端是否处于超载状态时，增加了心跳包丢包的判断以及心跳包收发时间差的判断，提高对流量接收端超载判断的准确性。同时，本申请在每一目标定时周期内，向流量接收端发送一次心跳包，并提出流量接收端向流量发送端反馈自身的当前中央处理器负载这一机制，使得业务低谷无流量的场景下依然能够检测流量接收端的状态，以确保服务正常。另一方面，本申请在判断出流量接收端处于超载状态后，仅将已建立连接的流量对应的第一数据包转发至流量接收端，能够一定程度上缓解流量接收端的负载压力，同时保证流量接收端在下一个定时周期内不会处于立刻空闲状态，避免出现流量波动。进一步的，本申请会根据流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率，使得基于目标流量转发概率转发至流量接收端的第二数据包控制在流量接收端的承受范围以内，解决了流量转发过程中的网络拥塞。
图7为本申请实施例提供的一种具体的网络流量转发流程图。参见图7所示，该网络流量转发方法包括：
S21：根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种。
S22：如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率。
S23：将所述当前流量转发概率与第三数值的乘积确定为初始流量转发概率；其中，所述第三数值小于所述第二数值。
进一步的，为了避免流量转发概率增加的太快，本实施例先将当前流量转发概率与第三数值的乘积确定为初始流量转发概率，其中，所述第三数值是小于所述第二数值的，在一种具体的实施方式中，所述第三数值可以是1/2。
S24：若检测到所述流量接收端由所述超载状态转为所述正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述初始流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端。
也就是说，在检测到所述流量接收端由所述超载状态转为所述正常状态的下一个目标定时周期，将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述初始流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端，如此一来，避免了所述流量接收端刚转为正常状态后，直接使用所述目标流量转发概率转发流量导致流量接收端的负载压力又变大。
S25：在预设时间段以内，判断所述流量接收端是否仍保持在所述正常状态，如果是则根据所述目标流量转发概率和预设转发概率增长幅度限定规则确定新目标流量转发概率，并根据所述新目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端。
进一步的，为了避免流量转发概率增加的太快，本实施例还可以在预设时间段以内，例如，在从超载状态恢复至正常状态后的60s以内，判断所述流量接收端是否仍保持在所述正常状态，若是则根据所述目标流量转发概率和预设转发概率增长幅度限定规则确定新目标流量转发概率，并根据所述新目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端，在一种具体的实施方式中，所述预设转发概率增长幅度限定规则可以是当前流量转发概率每次最大增长100/10000，也就是说，为了避免流量转发概率增长的太快，本实施例在流量接收端从超载状态恢复至正常状态后的60s以内，根据预设转发概率增长幅度限定规则对流量转发概率的增长幅度进行限制。
S26：在所述预设时间段以外，判断所述流量接收端是否仍保持在所述正常状态，如果是则直接根据所述目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端。
本实施例中，在所述预设时间段以外，例如，在从超载状态恢复至正常状态后的60s以外，若所述流量接收端仍保持在所述正常状态，则直接根据所述目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端，而不再需要对流量转发概率的增长幅度进行限制。
综上可见，本申请在流量接收端从超载状态恢复至正常状态的初始阶段，对流量转发概率的增长幅度进行限制，以避免流量接收端在短时间内又重新转为超载状态。
进一步的，相对于传统的CPU负载计算方式，本实施例中的流量接收端向流量发送端反馈的当前CPU负载是基于预设负载计算规则计算得到的，具体的，传统CPU负载计算方式为通过top命令等系统调用方式直接获取该核的实际使用率，得到CPU负载，但是本实施例中的流量接收端使用DPDK作为流量转发框架式，该流量转发框架式是死轮模式，无法通过top命令等系统调用方式直接获取该核的使用率。进一步的，传统方案还提出通过以下方式：CPU负载＝1-收空包的次数/总的次数来计算，其中，收空包的次数是指流量接收端去队列中取数据包，但未取到数据包的次数，但是经过实际验证，发现这种方式仅在DPDK纯转发的模式下工作正常，而对于本实施例中的场景，DPDK不仅用于收发包，还会进行后续处理操作，例如Service B对数据包进行安全处理操作等，而后续处理操作更为耗时，所以可能导致相比纯转发的场景下，收包的次数变少，总得次数变少，同时累计的包变多，导致空包变少，进而导致实际结果可能偏差，就测试结果而言，此种方式的CPU负载偏离较大，几乎只能检测出90％下的负载。
需要指出的是，在非纯转发的场景下，空包的次数可以理解为收空包所消耗的时间，总的时间即为定时器的目标定时周期，为此，本实施例对CPU负载的计算方式进行了调整，得到预设负载计算规则，所述预设负载计算规则为根据所述流量接收端收空包所耗时间在所述目标定时周期中所占的比重所构建的计算规则，具体的，所述预设负载计算规则包括：当前CPU负载＝1-收空包所耗时间/目标定时周期，本实施例对基于预设负载计算规则计算的当前CPU负载进行验证，发现改进后的方式可以良好的模拟当前CPU负载状态。
参见图8所示，图8为一种使用本方法前的网络波动及转发能力示意图，可以看出在使用本方法前，CPU实时负载在1.1G-1.4G之间，并且流量波动较大，图9为一种使用本方法后的网络波动及转发能力示意图，可以看出，在使用本方法后，CPU实时负载在8.9G-9G之间，吞吐能力大幅度提高，且无明显波动，其中，图8和图9的纵坐标表示CPU实时负载。
参见图10所示，本申请实施例还相应公开了一种网络流量转发装置，应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
超载状态判断模块11，用于根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；
流量转发概率确定模块12，用于如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；
流量转发模块13，用于若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
本申请中，根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。综上可见，一方面，本申请基于数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则实现对流量接收端的超载状态的判断，相对于传统方案，本申请在判断流量接收端是否处于超载状态时，增加了心跳包丢包的判断以及心跳包收发时间差的判断，提高对流量接收端超载判断的准确性。同时，本申请在每一目标定时周期内，向流量接收端发送一次心跳包，并提出流量接收端向流量发送端反馈自身的当前中央处理器负载这一机制，使得业务低谷无流量的场景下依然能够检测流量接收端的状态，以确保服务正常。另一方面，本申请在判断出流量接收端处于超载状态后，仅将已建立连接的流量对应的第一数据包转发至流量接收端，能够一定程度上缓解流量接收端的负载压力，同时保证流量接收端在下一个定时周期内不会处于立刻空闲状态，避免出现流量波动。进一步的，本申请会根据流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率，使得基于目标流量转发概率转发至流量接收端的第二数据包控制在流量接收端的承受范围以内，解决了流量转发过程中的网络拥塞。
进一步的，本申请实施例还提供了一种电子设备。图11是根据一示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。
图11为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的网络流量转发方法中的相关步骤。
本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。
另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222及数据223等，存储方式可以是短暂存储或者永久存储。
其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的网络流量转发方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223可以包括电子设备20收集到的画质调控策略等。
进一步的，本申请实施例还公开了一种存储介质，所述存储介质中存储有计算机程序，所述计算机程序被处理器加载并执行时，实现前述任一实施例公开的网络流量转发方法步骤。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个…”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本发明所提供的网络流量转发方法、装置、设备及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种网络流量转发方法，其特征在于，应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；
如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；
若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
2.根据权利要求1所述的网络流量转发方法，其特征在于，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
统计所述目标定时周期内向所述流量接收端发送的数据包总包数，并统计所述目标定时周期内向所述流量接收端发送失败的数据包丢包数；
根据所述数据包丢包数和所述数据包总包数计算丢包率，如果所述丢包率大于预设丢包率阈值，则判定所述流量接收端处于所述超载状态。
3.根据权利要求1所述的网络流量转发方法，其特征在于，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
分别统计若干个所述目标定时周期内所述心跳包的发送时间与所述心跳包的接收时间的时间差，得到若干个所述时间差；
如果若干个所述时间差在若干个所述目标定时周期内的平均值大于预设时间差阈值，则判定所述流量接收端处于所述超载状态。
4.根据权利要求1所述的网络流量转发方法，其特征在于，所述根据目标检测规则检测所述流量接收端是否处于超载状态，包括：
如果所述心跳包在所述目标定时周期内发生丢包，则直接判定所述流量接收端处于所述超载状态。
5.根据权利要求2至4任一项所述的网络流量转发方法，其特征在于，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率，包括：
如果所述当前中央处理器负载小于所述预设负载控制范围的下限值，则将当前流量转发概率与第一数值的乘积确定为所述目标流量转发概率；
如果所述当前中央处理器负载不小于所述预设负载控制范围的下限值，并且所述当前中央处理器负载不大于所述预设负载控制范围的上限值，则将所述当前流量转发概率确定为所述目标流量转发概率；
如果所述当前中央处理器负载大于所述预设负载控制范围的上限值，则将所述当前流量转发概率与第二数值的乘积确定为所述目标流量转发概率；
其中，所述第一数值大于1，所述第二数值小于1，所述当前流量转发概率和所述目标流量转发概率均不大于1。
6.根据权利要求5所述的网络流量转发方法，其特征在于，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率之后，还包括：
将所述当前流量转发概率与第三数值的乘积确定为初始流量转发概率；其中，所述第三数值小于所述第二数值；
相应的，若检测到所述流量接收端由所述超载状态转为正常状态，则根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端，包括
若检测到所述流量接收端由所述超载状态转为所述正常状态，则根据所述初始流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端；
在预设时间段以内，判断所述流量接收端是否仍保持在所述正常状态，如果是则根据所述目标流量转发概率和预设转发概率增长幅度限定规则确定新目标流量转发概率，并根据所述新目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端；
在所述预设时间段以外，判断所述流量接收端是否仍保持在所述正常状态，如果是则直接根据所述目标流量转发概率将未建立连接的流量对应的所述第二数据包转发至所述流量接收端。
7.根据权利要求1所述的网络流量转发方法，其特征在于，所述根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率之前，还包括：
获取所述流量接收端基于预设负载计算规则计算并反馈的所述当前中央处理器负载；其中，所述预设负载计算规则为根据所述流量接收端收空包所耗时间在所述目标定时周期中所占的比重所构建的计算规则。
8.一种网络流量转发装置，其特征在于，应用于流量发送端，在每一目标定时周期内，所述流量发送端向所述流量接收端发送一次心跳包，包括：
超载状态判断模块，用于根据目标检测规则检测所述流量接收端是否处于超载状态；其中，所述目标检测规则包括数据包丢包规则、心跳包丢包规则和心跳包收发时间差规则中的任意一种；
流量转发概率确定模块，用于如果检测到所述流量接收端处于所述超载状态，则将已建立连接的流量对应的第一数据包转发至所述流量接收端，并根据所述流量接收端反馈的当前中央处理器负载与预设负载控制范围的关系确定目标流量转发概率；
流量转发模块，用于若检测到所述流量接收端由所述超载状态转为正常状态，则将已建立连接的流量对应的所述第一数据包转发至所述流量接收端，并根据所述目标流量转发概率将未建立连接的流量对应的第二数据包转发至所述流量接收端。
9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，其中：
所述存储器用于存储计算机程序；
所述计算机程序由所述处理器加载并执行以实现如权利要求1至7任一项所述的网络流量转发方法。
10.一种计算机可读存储介质，其特征在于，用于存储计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如权利要求1至7任一项所述的网络流量转发方法。
CN202311554213.4A 2023-11-20 2023-11-20 一种网络流量转发方法、装置、设备及存储介质 Pending CN117527699A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311554213.4A CN117527699A (zh) 2023-11-20 2023-11-20 一种网络流量转发方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311554213.4A CN117527699A (zh) 2023-11-20 2023-11-20 一种网络流量转发方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN117527699A true CN117527699A (zh) 2024-02-06

Family

ID=89764060

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311554213.4A Pending CN117527699A (zh) 2023-11-20 2023-11-20 一种网络流量转发方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN117527699A (zh)

Similar Documents

Publication Publication Date Title
US10462707B2 (en) Data transmission method and apparatus
CN114145001B (zh) 速率优化的拥塞管理
CN109905259B (zh) 通信连接维持方法、系统和相关设备
US11316792B2 (en) Method and system of limiting traffic
EP2456142A1 (en) Methods and apparatus for detecting and limiting focused server overload in a network
CN104065586B (zh) 一种流量控制方法和装置
CN104994031A (zh) 一种主动队列自适应管理方法asred
CN116055415B (zh) 数据包的传输控制方法及装置
US20170324641A1 (en) Modified slow start for background connections
US11588736B2 (en) Communication apparatus, communication method, and program
US10298504B2 (en) Adaptive gain reduction for background connections
CN118250224B (zh) 拥塞控制方法、装置、系统、设备及介质
CN116319569A (zh) 网络参数更新方法、网络参数更新装置、介质及电子设备
CN117376212A (zh) 网络速率调整方法及装置、存储介质及电子设备
CN113364701B (zh) 基于rtt的结合比例积分微分控制的拥塞控制方法及设备
CN118233386A (zh) 一种轻量化显式拥塞反馈自动调整系统及其方法
US20170324642A1 (en) Initial and periodic slowdowns for background connections
CN117527699A (zh) 一种网络流量转发方法、装置、设备及存储介质
CN109150743B (zh) 一种网络拥塞控制策略切换方法及系统
CN110290552B (zh) 缓存深度的测量方法和装置、存储介质、电子装置
CN114024913B (zh) 一种网络性能优化方法、装置、设备以及存储介质
CN115174478A (zh) 一种网络拥塞控制方法及相关装置
Zhang et al. LearningCC: An online learning approach for congestion control
CN117499317B (zh) 链路拥塞控制方法及装置、存储介质及电子设备
CN118764472A (zh) 一种码率探测的优化方法、装置、设备及存储介质

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