CN113810330A - 发送验证信息的方法、装置及存储介质 - Google Patents

Abstract

本申请实施例公开了一种发送验证信息的方法、装置及存储介质，属于网络技术领域。在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，相较于采用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，直接通过数据包的网络层信息即可快速高效的实现对客户端的合法性验证或对客户端的访问控制。

Description

发送验证信息的方法、装置及存储介质

技术领域

本申请实施例涉及网络技术领域，特别涉及一种发送验证信息的方法、装置及存储介质。

背景技术

当前，出于网络通信安全的考虑，客户端和服务端在进行交互时，服务端能够对客户端进行验证。相关技术中，服务端在与客户端建立请求之后，通过诸如短信或者是专门的应用插件向客户端下发验证信息。后续，客户端通过该验证信息从服务端获取相应地服务。其中，如果采用短信方式下发验证信息时，后续客户端需要用户的参与才能获取到验证信息，如果采用应用插件来下发验证信息，则用户需要事先下载并安装相应的应用插件，无论是上述哪种方式，对于用户而言都比较繁琐。

发明内容

本申请实施例提供了一种发送验证信息的方法、装置及存储介质，服务端通过传输层协议向客户端下发验证信息，简便且适用性广，客户端通过数据包的网络层信息携带验证信息，使得客户端的合法性验证或访问控制更为高效。所述技术方案如下：

第一方面，提供了一种发送验证信息的方法，所述方法包括：通过传输层协议向所述第一客户端发送所述第一客户端的验证信息；接收所述第一客户端发送的第一数据包，所述第一数据包的网络层信息中携带所述第一客户端的验证信息，所述第一客户端的验证信息用于验证所述第一客户端的合法性，或者，用于对所述第一客户端进行访问控制。

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，这样，相较于用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，直接通过数据包的网络层信息即可实现对客户端的合法性验证或访问控制，高效便捷。

在一些可能的实施例中，在所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息之前，所述方法还包括：确定所述第一客户端为合法客户端，并向所述第一客户端发送合法标识。

其中，合法标识用于指示客户端为合法客户端。服务端在确定客户端为合法客户端的情况下向客户端发送合法标识，后续客户端与服务端再次建立连接时，就能够向服务端发送该合法标识来证明自身为合法客户端，简便高效。

在一些可能的实施例中，通过传输层协议向所述第一客户端发送所述第一客户端的验证信息的实现过程可以为：通过QUIC协议向所述第一客户端发送第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述第一客户端的验证信息。

也即，本申请实施例中服务端能够利用现有的QUIC协议中的已有字段来传输验证信息，这样，只要服务端和客户端双方均支持QUIC协议，就能实现验证信息的传输，无需客户端安装任何插件，适用性广。并且，该种实现方式中，无需修改现有协议和客户端，仅需要修改服务端即可实现验证信息的下发。

在一些可能的实施例中，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息的实现过程可以为：通过QUIC协议向所述第一客户端发送第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述第一客户端的验证信息。

在该种实现方式中，服务端通过修改现有QUIC协议，重新定义一个自定义字段来携带客户端的验证信息，这样，该验证信息不仅能够在服务端与客户端的本次连接中使用，而且还能在服务端与客户端的再次连接中使用，如此，在客户端与服务端再次连接的握手过程中，也能实现对客户端的合法性验证或访问控制。

在一些可能的实施例中，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息的实现过程可以为：通过安全传输层TLS协议向所述第一客户端发送新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述第一客户端的验证信息。

在该种实现方式中，服务端能够在基于TCP的TLS的NewSessionTicket消息或者是在基于QUIC协议的TLS的NewSessionTicket消息中携带第一客户端的验证信息，以实现验证信息的下发，这样，无论是对于使用TCP TLS还是使用UDP QUIC协议的客户端，均可以实现验证信息的下发，扩大了本申请实施例的适用范围。

在一些可能的实施例中，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息的实现过程可以为：通过多路传输控制协议MPTCP向所述第一客户端发送添加地址消息，所述添加地址消息携带所述第一客户端的验证信息。

在该种实现方式中，无需修改现有协议，也无需修改客户端，仅修改服务端即可实现验证信息的下发。

第二方面，提供了一种发送验证信息的方法，所述方法包括：接收服务端通过传输层协议发送的所述客户端的验证信息；向所述服务端发送第一数据包，所述第一数据包的网络层信息携带所述客户端的验证信息，所述客户端的验证信息用于验证所述客户端的合法性，或，所述客户端的验证信息用于对所述客户端进行访问控制。

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，这样，相较于用短信方式或者是应用插件的方式，无需用户参与，且客户端无需安装任何插件，简便且适用性广。客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端通过数据包的网络层信息即可实现对客户端的合法性验证或访问控制，高效便捷。

在一些可能的实施例中，在接收服务端通过传输层协议发送的所述客户端的验证信息之前，接收所述服务端发送的合法标识。

在一些可能的实施例中，所述接收服务端通过传输层协议发送的所述客户端的验证信息的实现过程为：接收所述服务端通过QUIC协议发送的第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述客户端的验证信息。

在一些可能的实施例中，所述接收服务端通过传输层协议发送的所述客户端的验证信息的实现过程为：接收所述服务端通过QUIC协议发送的第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述客户端的验证信息。

在一些可能的实施例中，所述接收服务端通过传输层协议发送的所述客户端的验证信息的实现过程为：接收所述服务端通过TLS协议发送的新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述客户端的验证信息。

在一些可能的实施例中，所述接收服务端通过传输层协议发送的所述客户端的验证信息的实现过程为：接收所述服务端通过MPTCP发送的添加地址消息，所述添加地址消息携带所述客户端的验证信息。

第三方面，提供了一种发送验证信息的装置，所述发送验证信息的装置具有实现上述第一方面或第二方面中发送验证信息的方法行为的功能。所述发送验证信息的装置包括至少一个模块，该至少一个模块用于实现上述第一方面或第二方面所提供的发送验证信息的方法。

第四方面，提供了一种发送验证信息的装置，所述发送验证信息的装置的结构中包括处理器和存储器，所述存储器用于存储支持发送验证信息的装置执行上述第一方面或第二方面所提供的发送验证信息的方法的程序，以及存储用于实现上述第一方面或第二方面所提供的发送验证信息的方法所涉及的数据。所述处理器被配置为用于执行所述存储器中存储的程序。所述存储设备的操作装置还可以包括通信总线，该通信总线用于该处理器与存储器之间建立连接。

第五方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第二方面所述的发送验证信息的方法。

第六方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或第二方面所述的发送验证信息的方法。

第七方面，提供了一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现上述方法中服务端或客户端的功能。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

第八方面，本申请还提供了一种通信系统，所述通信系统包括实现该第一方面描述的方法的通信装置，以及实现该第二方面描述的方法的通信装置。

上述第二方面、第三方面、第四方面、第五方面、第六方面、第七方面和第八方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。

本申请实施例提供的技术方案带来的有益效果至少包括：

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，相较于采用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，通过数据包的网络层信息即可快速高效的实现对客户端的合法性验证或对客户端的访问控制。

本申请中，客户端和服务端的名字对设备本身不构成限定，在实际实现中，这些设备可以以其他名称出现。只要各个设备的功能和本申请类似，属于本申请权利要求及其等同技术的范围之内。

附图说明

图1是本申请实施例提供的一种验证系统的架构图；

图2是本申请实施例提供的另一种验证系统的架构图；

图3是本申请实施例提供的又一种验证系统的架构图；

图4是本申请实施例提供的一种计算机设备的结构示意图；

图5是本申请实施例提供的一种发送验证信息的方法流程图；

图6是本申请实施例提供的基于QUIC协议定义的preferred_address字段的格式示意图；

图7是本申请实施例提供的通过QUIC协议传输第一客户端的验证信息的流程图；

图8是本申请实施例提供的一种基于当前QUIC协议的preferred_address字段扩展得到preferred_address_new字段的示意图；

图9是本申请实施例提供的第一种第一客户端与服务端交互以传输验证信息和数据包的流程图；

图10是本申请实施例提供的第二种第一客户端与服务端交互以传输验证信息和数据包的流程图；

图11是本申请实施例提供的第三种第一客户端与服务端交互以传输验证信息和数据包的流程图；

图12是本申请实施例提供的第一种第一客户端与服务端交互以传输验证信息和数据包的流程图；

图13是本申请实施例提供的一种发送验证信息的装置的结构示意图；

图14是本申请实施例提供的另一种发送验证信息的装置的结构示意图。

具体实施方式

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

在对本申请实施例进行详细的解释说明之前，先对本申请实施例涉及的应用场景进行介绍。

当前，出于网络通信安全的考虑，服务端在与客户端进行交互时，可以对客户端进行验证。

示例性地，服务端对客户端进行验证是指对客户端的身份进行合法性验证。例如，为了防止分布式拒绝服务(distributed denial of service，DDoS)攻击，当监测到发往服务端的流量存在异常时，对发送该流量的客户端进行合法性验证，以区分该流量是合法客户端发送的合法流量还是非法客户端发送的用于攻击服务端的非法流量。

或者，服务端对客户端进行验证是指对客户端本身进行验证以实现对客户端的访问控制。例如，服务端验证是否允许该客户端获取指定类型的服务，比如，在视频播放领域，服务端验证当前登录客户端的用户是否为未成年用户，以此来确定是否允许该客户端获取成年用户所能获取的服务。或者，服务端验证是否允许该客户端获取某些类型的数据，例如，在互联网金融领域，客户端想要获取某个用户的账单信息时，服务端通过验证该客户端的当前登录用户的身份来确定是否允许该客户端获取该账单信息。

本申请实施例提供的发送验证信息的方法即能够用于上述各种需要服务端对客户端进行验证的场景中，以实现服务端向客户端分配验证信息，进而客户端携带该验证信息以便服务端进行验证。

需要说明的是，上述仅是本申请实施例给出的几种可能的服务端对客户端进行验证的场景，并不构成对验证场景的限制。

接下来对本申请实施例提供的发送验证信息的方法所涉及的系统架构进行介绍。

图1是本申请实施例提供的一种验证系统的系统架构图。如图1所示，该验证系统中包括客户端01和服务端02。其中，客户端01和服务端02通过有线或无线的方式建立通信连接。

在一些可能的应用场景中，例如，在对客户端进行访问控制的场景中，服务端02是指对客户端01提供服务的服务器。在这种情况下，服务端02通过本申请实施例提供的方法通过传输层协议向客户端01分配对应的验证信息。相应地，客户端01在向服务端02发送数据包时，在数据包的网络层信息携带该验证信息，这样，服务端02或者是位于客户端01和服务端02之间的诸如路由器、交换机之类的转发设备或者是防火墙等中间件能够根据该验证信息对该客户端进行访问控制。

在另一些可能的场景中，例如，在防止DDoS攻击的场景中，该服务端02同样可以是指为客户端01提供服务的服务器。相应地，参见图2，该验证系统中还包括互联网服务提供商(internet service provider，ISP)设备03。其中，该ISP设备03分别与客户端01和服务端02建立通信连接。在这种情况下，服务端02为客户端01分配验证信息，并将该验证信息发送至客户端01。后续，当客户端01向服务端02发送数据包时，可以由ISP设备03根据客户端01发送的数据包的网络层信息中携带的验证信息对该客户端01进行合法性验证。

可选地，在一些实施例中，在防止DDoS攻击的场景中，参见图3，该服务端02包括用于向客户端01提供服务的服务器021以及中间设备022。其中，该中间设备022可以是指网站应用防火墙(web application firewall，WAF)，服务器021通过该中间设备022与客户端01进行通信。在这种情况下，可以由该中间设备022向客户端01分配并发送验证信息。后续，同样由该中间设备022根据发往服务器021的数据包的网络层信息中携带的验证信息对发送数据包的客户端进行合法性验证。

需要说明的是，上述的服务器可以是部署于云环境中用于向用户提供一项或多项服务的服务器或服务器集群，或者，上述的服务器可以是指某个数据中心中的服务器。上述的客户端可以是指诸如智能手机、平板电脑、个人计算机等用户终端设备。本申请实施例对此均不作限定。

图4是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备可以是图1中所示的服务端或者是客户端。该计算机设备包括一个或多个处理器401、通信总线402、存储器403以及一个或多个通信接口404。

处理器401可以是一个通用中央处理器(central processing unit，CPU)、网络处理器(network processor，NP)、微处理器、或者可以是一个或多个用于实现本申请方案的集成电路，例如，专用集成电路(application-specific integrated circuit，ASIC)、可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic,GAL)或其任意组合。

通信总线402用于在上述组件之间传送信息。通信总线402可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器403可以是只读存储器(read-only memory，ROM)，也可以是随机存取存储器(random access memory，RAM)，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、光盘(包括只读光盘(compact discread-only memory，CD-ROM)、压缩光盘、激光盘、数字通用光盘、蓝光光盘等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器403可以是独立存在，并通过通信总线402与处理器401相连接。存储器403也可以和处理器401集成在一起。

通信接口404使用任何收发器一类的装置，用于与其它设备或通信网络通信。通信接口404包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，WLAN)接口，蜂窝网络通信接口或其组合等。

在一些实施例中，计算机设备可以包括多个处理器，如图4中所示的处理器401和处理器405。这些处理器中的每一个可以是一个单核处理器，也可以是一个多核处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，计算机设备还可以包括输出设备406和输入设备407。输出设备406和处理器401通信，可以以多种方式来显示信息。例如，输出设备406可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emitting diode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备或投影仪(projector)等。输入设备407和处理器401通信，可以以多种方式接收用户的输入。例如，输入设备407可以是鼠标、键盘、触摸屏设备或传感设备等。

在一些实施例中，存储器403用于存储执行本申请实施例的方案的程序代码408，处理器401可以执行存储器403中存储的程序代码408。该程序代码中可以包括一个或多个软件模块，该计算机设备通过处理器401以及存储器403中的程序代码408，来实现下文图3实施例提供的发送验证信息的方法。

接下来对本申请实施例提供的发送验证信息的方法进行介绍。

图5是本申请实施例提供的一种发送验证信息的方法的流程图。该方法可以应用于图1所示的验证系统中，参见图5，该方法包括以下步骤：

步骤501：服务端通过传输层协议向第一客户端发送第一客户端的验证信息，第一客户端接收第一客户端的验证信息。

其中，第一客户端可以是指服务端所服务的多个客户端中的任一个客户端。传输层协议可以为QUIC协议、TLS协议、MPTCP中的任意一个。

第一客户端的验证信息是指服务端为第一客户端分配的用于唯一识别第一客户端的信息。示例性地，该验证信息可以包括可验证身份标识符(authenticatableidentifier，AID)和验证码(code)。其中，AID可以为用于唯一标识对应的客户端的标识，例如设备标识、用户标识等。或者，AID可以为客户端所在的安全组的标识，或者，AID可以为用于标识用户类型的信息，例如，可以为用于标识用户为成年用户或未成年用户的用户类型标识，或者，AID也可以为客户端对应的安全级别、设备类型等，code用于验证AID的合法性。

在本申请实施例中，根据传输层协议的不同，服务端可以通过以下几种不同的实现方式发送第一客户端的验证信息。

第一种实现方式：通过QUIC协议向第一客户端发送第二数据包，第二数据包包括基于QUIC协议的推荐地址字段，该推荐地址字段携带第一客户端的验证信息。

其中，QUIC协议是一种基于用户数据报协议(user datagram protocol，UDP)的低时延的互联网传输层协议。当第一客户端和服务端均支持QUIC协议的情况下，第一客户端请求与服务端建立连接，在第一客户端和服务端握手阶段，服务端可以通过QUIC协议向第一客户端发送第二数据包。

示例性地，第一客户端向服务端发送client hello消息，以请求建立连接，服务端在接收到client hello消息之后，可以根据该client hello消息识别第一客户端是否为合法客户端。当确定第一客户端为合法客户端时，服务端可以向第一客户端发送第二数据包。其中，第二数据包中可以包括基于QUIC定义的推荐地址(preferred_address)字段。第一客户端的验证信息可以被携带在该preferred_address字段中进行传输。

需要说明的是，在本申请实施例中，第一客户端的验证信息和服务端的位置定位符(Locator)可以组成一个安全地址，服务端可以将该安全地址携带在preferred_address字段中进行传输。其中，服务端的Locator用于标识该服务端所在的子网。

图6示出了基于QUIC协议定义的preferred_address字段的格式。如图6所示，preferred_address字段中包括32比特的IPv4地址、16比特的IPv4端口、128比特的IPv6地址、16比特的IPv6端口、8比特的连接标识符(connection identifier，CID)长度、CID以及128比特的无状态重置令牌(stateless reset token)。其中，验证信息可以内嵌在128比特的IPv6地址中发送至第一客户端。

另外，需要说明的是，在本申请实施例中，在服务端通过本次连接向第一客户端发送携带验证信息的第二数据包之前，服务端还可以向第一客户端发送合法标识，该合法标识用于标识该第一客户端为合法客户端。

示例性地，服务端在首次与第一客户端建立连接时，可以通过第一客户端发送的数据包的应用层信息或者是第一客户端发送的数据包的其他信息来识别第一客户端是否为合法客户端，并在确定第一客户端为合法客户端的情况下，通过新会话票证(NewSessionTicket)消息携带合法标识，以将该合法标识发送至第一客户端。后续，第一客户端再次请求与服务端建立连接时，即可以将该合法标识携带在Client Hello消息中预共享公钥(pre_shared_key)的身份字段(identity)中。这样，服务端通过检测Client Hello消息中是否携带合法标识即可以确定出对应的客户端是否为合法客户端，进而决定是否向客户端发放对应的验证信息。

图7是本申请实施例示出的通过QUIC协议传输第一客户端的验证信息的流程图。如图7所示，第一客户端在与服务端首次建立连接时，服务端通过第一客户端的应用层信息识别第一客户端为合法客户端，并向第一客户端发送携带有合法标识的NewSessionTicket消息。之后，第一客户端再次请求与服务端建立连接时，向服务端发送client hello消息，该client hello消息的pre_shared_key的identity中携带合法标识。服务端通过该合法标识确定第一客户端为合法客户端，并将包含有第一客户端的验证信息的安全地址携带在第二数据包中的preferred_address字段中发送至第一客户端。

在该种实现方式中，无需修改现有协议和客户端，仅需要修改服务端即可实现验证信息的下发。

第二种实现方式：通过QUIC协议向第一客户端发送第三数据包，第三数据包包括基于QUIC协议的自定义字段，该自定义字段携带第一客户端的验证信息。

在第一种实现方式中，在第一客户端与服务端握手阶段，服务端可以将第一客户端的验证信息携带在第二数据包的preferred_address字段中发送至第一客户端。然而，在该次连接的握手阶段中发送的第一客户端的验证信息只能在第一客户端与服务端该次握手结束之后的本次连接中使用。当本次连接断开之后，第一客户端再次请求与服务端建立连接时，在握手过程中，第一客户端将无法再使用该验证信息。基于此，本申请实施例可以基于QUIC协议定义一个preferred_address_new字段，将定义的preferred_address_new字段称为自定义字段。服务端可以在与第一客户端的本次连接中通过该自定义字段携带第一客户端的验证信息，并将该自定义字段携带在第三数据包中发送至第一客户端。这样，当第一客户端再次请求与服务端建立连接时，在握手过程中，第一客户端即可以在发往服务端的数据包中携带上次连接中得到的第一客户端的验证信息。不仅如此，在第一客户端和服务端的本次连接中，第一客户端在接收到该验证信息之后，也可以在发往服务端的数据包中携带该验证信息。

其中，服务端在与第一客户端的本次连接中发送携带有自定义字段的第三数据包可以是指在与第一客户端的本次握手阶段发送，也可以是指在与第一客户端本次握手结束之后成功建立连接之后的任何时段内，本申请实施例对此不作限定。

并且，在该种实现方式中，服务端同样可以将服务端的locator与第一客户端的验证信息组成安全地址，将该安全地址携带在自定义字段中发送至第一客户端，以实现第一客户端的验证信息的下发。

另外，基于QUIC协议定义的preferred_address_new字段可以是完全基于QUIC协议重新定义的一种传输参数，也可以是对基于当前QUIC协议的preferred_address字段扩展的得到。

图8是本申请实施例示出的一种基于当前QUIC协议的preferred_address字段扩展得到preferred_address_new字段。如图8所示，相对于图6所示的当前的preferred_address字段，可以在preferred_address字段增加标记(Flag)字段，当Flag字段中的S置位时，表示该字段是用于验证的安全地址。

另外，值得注意的是，在该种实现方式中，服务端在向第一客户端发送第一客户端的验证消息之前，同样可以识别第一客户端是否为合法客户端。

其中，由于该种实现方式中的自定义字段可以在本次连接的任何时刻进行发送，且自定义字段中携带的第一客户端的验证信息不仅可以在本次连接中使用，还可以在下次连接中使用，因此，服务端在与第一客户端首次建立连接时，即可以通过第一客户端发送的数据包的应用层信息或者是其他用户数据来识别第一客户端是否为合法客户端，并在确定第一客户端为合法客户端时，即刻向第一客户端下发第一客户端的验证信息。

第三种实现方式：通过TLS协议向目标客户端发送NewSessionTicket消息，NewSessionTicket消息携带第一客户端的验证信息。

在该种实现方式中，服务端可以在基于传输控制协议(transmission controlprotocol，TCP)的TLS的NewSessionTicket消息中或者是在基于QUIC协议的TLS的NewSessionTicket消息中携带第一客户端的验证信息，并将该NewSessionTicket消息发送至第一客户端。

其中，在一些可能的实施例中，服务端可以不修改TLS，而是在NewSessionTicket消息的Ticket参数中携带第一客户端的验证信息。在另一些可能的实施例中，服务端可以修改TLS，重新定义一个用于携带第一客户端的验证信息的安全参数。

另外，在该种实现方式中，服务端可以在与第一客户端握手结束之后，发送该NewSessionTicket消息。后续，第一客户端可以在本次握手结束之后与服务端建立的本次连接中使用该验证信息，也可以在本次连接断开之后，再次与服务端建立连接时使用该验证信息。其中，第一客户端可以在再次请求与服务端建立连接时的握手过程中使用该验证信息，也可以在握手结束后的成功建立连接的时段内使用该验证信息，本申请实施例对此不做限定。

还需要说明的是，服务端同样可以将服务端的locator与第一客户端的验证信息组成安全地址，将该安全地址携带在NewSessionTicket消息中发送至第一客户端，以实现第一客户端的验证信息的下发。

第四种实现方式：通过MPTCP向第一客户端发送添加地址消息，该添加地址消息携带第一客户端的验证信息。

在该种实现方式中，第一客户端和服务端通过MPTCP建立第一子连接，之后，第一客户端可以通过第一子连接向服务端发送应用数据。服务端在接收到第一客户端通过第一子连接发送的应用数据之后，可以通过该应用数据识别第一客户端是否为合法客户端，在确定第一客户端为合法客户端之后，服务端可以通过添加地址(add address)消息携带第一客户端的验证信息，将该add address消息发送至第一客户端。

其中，服务端同样可以将服务端的locator与第一客户端的验证信息组成安全地址，将该安全地址携带在add address消息中发送至第一客户端，以实现第一客户端的验证信息的下发。

另外，在该种实现方式中，无需修改现有协议，同时，客户端也无需修改，仅修改服务端即可实现验证信息的下发。

服务端可以通过上述四种方式中的任一种方式来发送第一客户端的验证信息。相应地，第一客户端可以接收服务端下发的第一客户端的验证信息。

步骤502：第一客户端向服务端发送第一数据包，服务端接收第一数据包，第一数据包的网络层信息携带第一客户端的验证信息。

第一客户端在接收到服务端下发的验证信息之后，可以使用该验证信息向服务端发送第一数据包。其中，第一数据包的网络层信息中携带该第一客户端的验证信息。示例性地，可以将第一客户端的验证信息携带在第一数据包的数据包头中。

由前述步骤501中的介绍可知，服务端可以通过四种不同的方式向第一客户端发送验证信息。基于此，根据服务端下发方式的不同，第一客户端可以采用不同的方式向服务端发送第一数据包。

(1)当服务端通过前述步骤501中的第一种实现方式来下发第一客户端的验证信息时，由前述步骤501中的介绍可知，服务端可以在一次连接的握手阶段向第一客户端发送携带该推荐地址字段的第二数据包，基于此，在接收到该验证信息之后，第一客户端可以在本次握手结束之后，在本次连接中发往服务端的第一数据包中携带该验证信息。而在第一客户端再次请求与服务端建立连接时，则服务端需要重新在握手阶段向第一客户端发送第一客户端的验证信息，而无法使用之前建立连接时获取到的验证信息。换句话说，在该种实现方式中，第一客户端在握手阶段获取到的验证信息用于在本次连接中发往服务端的数据包中携带。

图9是本申请实施例示出的第一种第一客户端与服务端交互以传输验证信息和数据包的流程图。如图9所示，第一客户端向服务端发送client hello消息以请求建立连接，该client hello消息中携带有合法标识。服务端通过client hello消息中的合法标识确定第一客户端为合法客户端之后，向第一客户端发送第二数据包，第二数据包的preferred_address字段中携带第一客户端的验证信息。第一客户端在接收到第二数据包之后，可以向服务端发送握手完成消息。此时，第一客户端和服务端握手结束，本次连接成功建立，之后，第一客户端可以向服务端发送携带有第一客户端的验证信息的第一数据包。

需要说明的是，如果服务端是将第一客户端的验证信息和服务端的locator组成安全地址下发至第一客户端的，则第一客户端可以将该安全地址作为第一数据包的目的地址携带在第一数据包中发送至服务端。

(2)当服务端通过前述步骤501中的第二种实现方式向第一客户端下发验证信息时，由前述步骤501的介绍可知，服务端可以在一次连接的握手阶段或者是握手结束之后的任意时刻向第一客户端下发该验证信息。基于此，第一客户端在接收到该验证信息之后，可以在本次连接中发送携带该验证信息的第一数据包，也可以在再次与服务端建立连接时发送携带该验证信息的第一数据包。其中，第一客户端可以在再次请求与服务端建立连接时，在握手过程中向服务端发送携带该验证信息的第一数据包，或者，也可以在握手结束后成功建立连接后的时段内向服务端发送携带该验证信息的第一数据包。换句话说，第一客户端接收到的验证信息不仅可以携带在本次连接中发往服务端的数据包中，还可以携带在再次连接中发往服务端的数据包中。

图10是本申请实施例示出的第二种第一客户端与服务端交互以传输验证信息和数据包的流程图。如图10所示，在第一连接中，服务端可以在preferred_address_new字段中携带第一客户端的验证信息，并向第一客户端发送携带preferred_address_new字段的第三数据包。第一客户端在接收到该第三数据包后，可以在本次连接中发往服务端的数据包中携带第三数据包中验证信息。后续，当第一客户端再次与服务端建立连接时，假设再次建立的连接为第二连接，则在第二连接中，第一客户端可以依然在发往服务端的数据包中携带该验证信息。

在该种实现方式中，服务端在一次连接中下发至第一客户端的验证信息，在再次建立连接时，第一客户端在握手阶段即可以在发往服务端的数据包中携带该验证信息，这样，避免了第一客户端在再次与服务端建立连接时，服务端无法对第一客户端在握手阶段发送的数据包进行验证的问题，扩大了数据包的可验证范围，提高了安全性。

另外，如果服务端是将第一客户端的验证信息和服务端的locator组成安全地址下发至第一客户端的，则第一客户端可以将该安全地址作为第一数据包的目的地址携带在第一数据包中发送至服务端。

(3)当服务端通过前述步骤501中的第三种实现方式来下发第一客户端的验证信息时，在接收到该验证信息之后，可以在本次连接中发往服务端的第一数据包中携带该验证信息，也可以在再次与服务端建立连接时发往服务端的第一数据包携带该验证信息。其中，第一客户端可以在再次请求与服务端建立连接时，在握手过程中向服务端发送携带该验证信息的第一数据包，或者，也可以在握手结束后成功建立连接后的时段内向服务端发送携带该验证信息的第一数据包。

图11是本申请实施例示出的第三种第一客户端与服务端交互以传输验证信息和数据包的流程图。如图11所示，在第一连接中，服务端可以在NewSessionTicket消息携带第一客户端的验证信息，并向第一客户端发送该NewSessionTicket消息。第一客户端在接收到该NewSessionTicket消息后，当第一客户端再次与服务端建立连接时，假设再次建立的连接为第二连接，则在第二连接中，第一客户端可以在发往客户端的第一数据包中携带该第一连接中的NewSessionTicket消息中携带的验证信息。

在该种实现方式中，服务端可以在基于TCP的TLS的NewSessionTicket消息或者是在基于QUIC协议的TLS的NewSessionTicket消息中携带第一客户端的验证信息，以实现验证信息的下发，这样，无论是对于使用TCP TLS还是使用UDP QUIC协议的客户端，均可以实现验证信息的下发，扩大了本申请实施例的适用范围。

(4)当服务端通过前述步骤501中的第四种实现方式来下发第一客户端的验证信息时，由前述步骤501中的介绍可知，服务端可以在建立第一子连接之后，向第一客户端下发第一客户端的验证信息。基于此，在接收到该验证信息之后，第一客户端可以基于下发的验证信息与服务端建立第二子连接，并通过第二子连接向服务端发送携带有第一客户端的验证信息的第一数据包。

图12是本申请实施例示出的第四种第一客户端与服务端交互以传输验证信息和数据包的流程图。如图12所示，第一客户端在通过第一子连接(subflow1)向服务端发送应用数据之后，服务端可以通过该应用数据识别第一客户端为合法客户端，之后，服务端可以将第一客户端的验证信息和服务端的locator组成安全地址，将该安全地址携带在addaddress消息中，通过第一子连接下发至第一客户端。第一客户端在接收到add address消息之后，可以基于其中的安全地址与服务端建立第二子连接(subflow2)。之后，服务端可以通知第一客户端将第一子连接的优先级修改为低优先级，以将第一子连接设置为备份路径或者关闭第一子连接。后续，第一客户端即可以通过第二子连接发送携带有第一客户端的验证信息的第一数据包。

第一客户端在发送第一数据包之后，根据应用场景的不同，可以通过第一数据包的网络层信息中携带的第一客户端的验证信息来做不同的验证操作。

示例性地，当该验证信息用于在图2所示的场景中验证发送数据包的客户端的合法性时，第一客户端的第一数据包首先可以发送至ISP设备，ISP设备在接收到第一客户端发送的第一数据包之后，可以直接对第一数据包的网络层信息进行解析，如果该网络层信息中携带有验证信息、且经过校验该验证信息正确，则ISP设备认为发送第一数据包的第一客户端为合法客户端，在这种情况下，ISP设备可以将该第一数据包发送至服务端。如果该网络层信息中携带有验证信息、但经过校验该验证信息错误，则ISP设备可以认为发送第一数据包的客户端为非法客户端，第一数据包为非法数据包，在这种情况下，ISP设备可以直接对该第一数据包进行拦截，而不再转发至服务端。如果该网络层信息中未携带有验证信息，则ISP设备可以参考现有技术中的处理方法来处理该数据包，例如，在预防DDoS攻击中，ISP设备可以将该第一数据包导向至黑洞或者是导向流量清洗中心进行进一步处理。

可选地，当该验证信息用于在图3所示的场景中验证数据包的合法性时，第一客户端的第一数据包首先可以发送至服务端包括的中间设备处。中间设备在接收到第一数据包之后，可以直接对第一数据包的网络层信息进行解析，如果该网络层信息中携带有验证信息、且经过校验该验证信息正确，则中间设备认为发送第一数据包的第一客户端为合法客户端，在这种情况下，中间设备可以将该第一数据包发送至服务端中的服务器。如果该网络层信息中携带有验证信息、但经过校验该验证信息错误，则中间设备可以认为发送第一数据包的第一客户端为非法客户端，第一数据包为非法数据包，在这种情况下，中间设备可以直接对该第一数据包进行拦截，而不再转发至服务器。如果该网络层信息中未携带有验证信息，则中间设备可以参考现有技术中的处理方法来处理该数据包，例如，在预防DDoS攻击中，中间设备可以将该第一数据包导向至黑洞或者是导向流量清洗中心进行进一步处理。

可选地，当验证信息用于在图1所示的场景中对客户端进行访问控制时，服务端或转发设备或防火墙等验证设备在接收到第一客户端发送的第一数据包之后，可以根据第一数据包的网络层信息中携带的第一客户端的验证信息，来决定是否为第一客户端提供服务，或者是决定为第一客户端提供何种类型的服务。

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，相较于采用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，直接通过数据包的网络层信息即可快速高效的实现对客户端的合法性验证或对客户端的访问控制。

参见图13，本申请实施例提供了一种发送验证信息的装置1300，该装置1300包括：

发送模块1301，用于执行前述实施例中步骤501中通过传输层协议向第一客户端发送第一客户端的验证信息的操作；

接收模块1302，用于执行前述实施例中步骤501中接收第一客户端发送的第一数据包的操作。

可选地，参见图13，该装置还包括1300：处理模块1303；

该处理模块1303用于确定第一客户端为合法客户端，发送模块用于向第一客户端发送合法标识。

可选地，发送模块1301具体用于：

通过QUIC协议向第一客户端发送第二数据包，第二数据包包括基于QUIC协议的推荐地址字段，推荐地址字段携带第一客户端的验证信息。

可选地，发送模块1301具体用于：

通过QUIC协议向第一客户端发送第三数据包，第三数据包包括基于QUIC协议的自定义字段，自定义字段携带第一客户端的验证信息。

可选地，发送模块1301具体用于：

通过安全传输层TLS协议向第一客户端发送新会话票证NewSessionTicket消息，NewSessionTicket消息携带第一客户端的验证信息。

可选地，发送模块1301具体用于：

通过多路传输控制协议MPTCP向第一客户端发送添加地址消息，添加地址消息携带第一客户端的验证信息。

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，相较于采用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，直接通过数据包的网络层信息即可快速高效的实现对客户端的合法性验证或对客户端的访问控制。

参见图14，本申请实施例还提供了一种发送验证信息的装置1400，该装置1400包括：

接收模块1401，用于执行前述实施例中步骤501中接收服务端通过传输层协议发送的客户端的验证信息的操作；

发送模块1402，用于执行前述实施例中步骤502中向服务端发送第一数据包的操作。

可选地，接收模块1401还用于：接收服务端发送的合法标识。

可选地，接收模块1401具体用于：

接收服务端通过QUIC协议发送的第二数据包，第二数据包包括基于QUIC协议的推荐地址字段，推荐地址字段携带客户端的验证信息。

可选地，接收模块1401具体用于：

接收服务端通过QUIC协议发送的第三数据包，第三数据包包括基于QUIC协议的自定义字段，自定义字段携带客户端的验证信息。

可选地，接收模块1401具体用于：

接收服务端通过TLS协议发送的新会话票证NewSessionTicket消息，NewSessionTicket消息携带客户端的验证信息。

可选地，接收模块1401具体用于：

接收服务端通过MPTCP发送的添加地址消息，添加地址消息携带客户端的验证信息。

在本申请实施例中，服务端通过传输层协议向客户端下发验证信息，相较于采用短信方式或者是应用插件的方式，无需用户参与，简便且适用性广。后续，客户端在向服务端发送数据包时，在数据包的网络层信息中携带该验证信息，这样，服务端无需解析数据包中封装的数据，直接通过数据包的网络层信息即可快速高效的实现对客户端的合法性验证或对客户端的访问控制。

需要说明的是：上述实施例提供的发送验证信息的装置在发送验证信息时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的发送验证信息的装置与发送验证信息的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(Digital Subscriber Line，DSL))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(Digital Versatile Disc，DVD))、或者半导体介质(例如：固态硬盘(Solid State Disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

应当理解的是，本文提及的“至少一个”是指一个或多个，“多个”是指两个或两个以上。在本文的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

以上所述为本申请提供的实施例，并不用以限制本申请实施例，凡在本申请实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请实施例的保护范围之内。

Claims (25)

1.一种发送验证信息的方法，其特征在于，应用于服务端，所述方法包括：

通过传输层协议向所述第一客户端发送所述第一客户端的验证信息；

接收所述第一客户端发送的第一数据包，所述第一数据包的网络层信息中携带所述第一客户端的验证信息，所述第一客户端的验证信息用于验证所述第一客户端的合法性，或者，用于对所述第一客户端进行访问控制。

2.根据权利要求1所述的方法，在所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息之前，所述方法还包括：

确定所述第一客户端为合法客户端，并向所述第一客户端发送合法标识。

3.根据权利要求1所述的方法，其特征在于，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息，包括：

通过QUIC协议向所述第一客户端发送第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述第一客户端的验证信息。

4.根据权利要求1所述的方法，其特征在于，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息，包括：

通过QUIC协议向所述第一客户端发送第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述第一客户端的验证信息。

5.根据权利要求1所述的方法，其特征在于，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息，包括：

通过安全传输层TLS协议向所述第一客户端发送新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述第一客户端的验证信息。

6.根据权利要求1所述的方法，其特征在于，所述通过传输层协议向所述第一客户端发送所述第一客户端的验证信息，包括：

通过多路传输控制协议MPTCP向所述第一客户端发送添加地址消息，所述添加地址消息携带所述第一客户端的验证信息。

7.一种发送验证信息的方法，其特征在于，应用于客户端，所述方法包括：

接收服务端通过传输层协议发送的所述客户端的验证信息；

向所述服务端发送第一数据包，所述第一数据包的网络层信息携带所述客户端的验证信息，所述客户端的验证信息用于验证所述客户端的合法性，或，所述客户端的验证信息用于对所述客户端进行访问控制。

8.根据权利要求7所述的方法，其特征在于，所述接收服务端通过传输层协议发送的所述客户端的验证信息之前，还包括：

接收所述服务端发送的合法标识。

9.根据权利要求7所述的方法，其特征在于，所述接收服务端通过传输层协议发送的所述客户端的验证信息，包括：

接收所述服务端通过QUIC协议发送的第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述客户端的验证信息。

10.根据权利要求7所述的方法，其特征在于，所述接收服务端通过传输层协议发送的所述客户端的验证信息，包括：

接收所述服务端通过QUIC协议发送的第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述客户端的验证信息。

11.根据权利要求7所述的方法，其特征在于，所述接收服务端通过传输层协议发送的所述客户端的验证信息，包括：

接收所述服务端通过TLS协议发送的新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述客户端的验证信息。

12.根据权利要求7所述的方法，其特征在于，所述接收服务端通过传输层协议发送的所述客户端的验证信息，包括：

接收所述服务端通过MPTCP发送的添加地址消息，所述添加地址消息携带所述客户端的验证信息。

13.一种发送验证信息的装置，其特征在于，应用于服务端，所述装置包括：

发送模块，用于通过传输层协议向所述第一客户端发送所述第一客户端的验证信息；

接收模块，用于接收所述第一客户端发送的第一数据包，所述第一数据包的网络层信息中携带所述第一客户端的验证信息，所述第一客户端的验证信息用于验证所述第一客户端的合法性，或者，用于对所述第一客户端进行访问控制。

14.根据权利要求13所述的装置，所述装置还包括：处理模块；

所述处理模块用于确定所述第一客户端为合法客户端，所述发送模块用于向所述第一客户端发送合法标识。

15.根据权利要求13所述的装置，其特征在于，所述发送模块用于：

通过QUIC协议向所述第一客户端发送第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述第一客户端的验证信息。

16.根据权利要求13所述的装置，其特征在于，所述发送模块用于：

通过QUIC协议向所述第一客户端发送第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述第一客户端的验证信息。

17.根据权利要求13所述的装置，其特征在于，所述发送模块用于：

通过安全传输层TLS协议向所述第一客户端发送新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述第一客户端的验证信息。

18.根据权利要求13所述的装置，其特征在于，所述发送模块用于：

通过多路传输控制协议MPTCP向所述第一客户端发送添加地址消息，所述添加地址消息携带所述第一客户端的验证信息。

19.一种发送验证信息的装置，其特征在于，应用于客户端，所述装置包括：

接收模块，用于接收服务端通过传输层协议发送的所述客户端的验证信息；

发送模块，用于向所述服务端发送第一数据包，所述第一数据包的网络层信息携带所述客户端的验证信息，所述客户端的验证信息用于验证所述客户端的合法性，或，所述客户端的验证信息用于对所述客户端进行访问控制。

20.根据权利要求19所述的装置，其特征在于，所述接收模块还用于：

接收所述服务端发送的合法标识。

21.根据权利要求19所述的装置，其特征在于，所述接收模块用于：

接收所述服务端通过QUIC协议发送的第二数据包，所述第二数据包包括基于所述QUIC协议的推荐地址字段，所述推荐地址字段携带所述客户端的验证信息。

22.根据权利要求19所述的装置，其特征在于，所述接收模块用于：

接收所述服务端通过QUIC协议发送的第三数据包，所述第三数据包包括基于所述QUIC协议的自定义字段，所述自定义字段携带所述客户端的验证信息。

23.根据权利要求19所述的装置，其特征在于，所述接收模块用于：

接收所述服务端通过TLS协议发送的新会话票证NewSessionTicket消息，所述NewSessionTicket消息携带所述客户端的验证信息。

24.根据权利要求19所述的装置，其特征在于，所述接收模块用于：

接收所述服务端通过MPTCP发送的添加地址消息，所述添加地址消息携带所述客户端的验证信息。

25.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行权利要求1-6或7-12任一项所述的发送验证信息的方法。

Images