CN115150312A - 一种路由方法及设备 - Google Patents

Abstract

本申请实施例公开了一种路由方法及设备，可应用于数据传输领域，包括：源端设备将对路径的请求携带在扩展DNS请求中向控制器发送，控制器基于该扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息内容(如包括几个转发节点、转发节点间的先后转发顺序等)将目标数据包向目的端设备发送。本申请将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中(即以扩展DNS报文为媒介)，将路径信息配置在扩展DNS报文的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。

Description

一种路由方法及设备

技术领域

本申请涉及数据传输领域，尤其涉及一种路由方法及设备。

背景技术

随着5G时代的到来，互联网应用呈现新的发展态势，在线游戏、音视频、增强现实(augmented reality，AR)、虚拟现实(virtual reality，VR)等新兴移动应用对网络时延、吞吐、丢包等体验的要求不断提高。

传统互联网传输在确定源端设备的源地址、目的端设备的目的地址后，端到端的传输路径由互联网中的路由协议(如，边界网关协议(border gateway protocol，BGP)、内部网关协议(interior gateway protocol，IGP)等)所决定。

目前，源端设备到目的端设备的路由方式一般分为如下几种：基于智能域名系统(domain name system，DNS)的全局负载均衡(global server load balance，GSLB)、Overlay智能路由以及分段/源路由(segment/source routing，SR)，其中，基于DNS的GSLB解决了应用对用户请求目的端设备的目的地址的控制，但无法控制对目的端设备访问的路径，也就是说，源端设备到目的端设备的访问路径完全由互联网所决定；Overlay智能路由则涉及3个子系统，各子系统各自独立对路径进行优化，每个子系统做出的本地最优决策不等于端到端的全局最优决策；而分段/源路由目前只工作在网络内部(如路由器、交换机或网路中继转发节点(point-of-presence，PoP))。

发明内容

本申请实施例提供了一种路由方法及设备，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

基于此，本申请实施例提供以下技术方案：

第一方面，本申请实施例首先提供一种路由方法，可用于数据传输领域中，该方法包括：首先，源端设备会向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定。源端设备在向控制器发送了第一扩展DNS请求后，之后将获取由控制器发送的第一扩展DNS响应，该第一扩展DNS响应由控制器生成，该第一扩展DNS响应中包括与第一路径请求对应的路径信息，该路径信息由控制器根据该第一扩展DNS请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先源端设备将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在第一方面的一种可能的实现方式中，在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一扩展DNS响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送的过程具体可以是：首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址(如，IP地址，或，用于映射IP地址的标识，或，其他可以对第一跳转发节点进行寻址的标识等，下述各个转发节点的地址的含义与此类似，此处不予赘述)，之后，源端设备将第一数据包发送至第一跳转发节点，第一跳转发节点根据该第一头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第一跳转发节点不是最后一跳转发节点，在这种情况下，第一转发节点对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的地址以及第二跳转发节点的地址，之后，由该第一跳转发节点根据转发节点的先后转发顺序将该第二数据包向第二跳转发节点发送。类似地，第二跳转发节点根据该第二数据包中的第二头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第二跳转发节点是最后一跳转发节点，在这种情况下，第二跳转发节点对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包(即只包含原始网络层包头)，并由该第二跳转发节点将该删除了第二头域的目标数据包向目的端设备发送。需要注意的是，在本申请实施例中，路径信息中除了最后一跳转发节点之外，其他每个转发节点都需对上一个转发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序、自身的地址以及下一跳转发节点的地址。当某个转发节点接收到由上一个转发节点发送的数据包，根据数据包中头域内的先后转发顺序得知自身为最后一跳，那么该转发节点去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点将得到的目标数据包发送给目的端设备。

在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，源端设备以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。

在第一方面的一种可能的实现方式中，若路径信息中只包括一个转发节点(即第一转发节点)，那么该第一转发节点接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点会将头域删除，并将删除了头域的目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。

在第一方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。

在第一方面的一种可能的实现方式中，该第一扩展DNS请求的生成可以有多种触发形式，作为一个示例，该第一扩展DNS请求可以通过安装于该源端设备的SDK(终端软件套件，可被应用调用)生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一扩展DNS请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一扩展DNS请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一扩展DNS请求。具体地，本申请对如何触发生成第一扩展DNS请求的具体实现方式不做限定，此处不再举例示意。

在本申请上述实施方式中，阐述了几种触发第一扩展DNS请求生成的应用场景，具备普遍适用性。

在第一方面的一种可能的实现方式中，源端设备向控制器发送第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS请求向该控制器发送。类似地，源端设备获取由控制器发送的第一扩展DNS响应的实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该源端设备接收由该DNS服务器发送的第一扩展DNS响应。

在本申请上述实施方式中，具体阐述了源端设备与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。

在第一方面的一种可能的实现方式中，第一路径请求至少包括如下信息中的任意一种：

待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型(如，实时音视频类应用、游戏类应用、浏览器类应用等)、待发送数据的应用ID(如，可以是Overlay网络运营商所维护的应用标识符)、待发送数据的业务类型(如，该数据流是实时音视频数据、游戏指令类数据、网页请求类数据等)、待发送数据的QoS要求(如，待发送数据所需要的QoS性能)、待发送数据要求使用的第一路径类型。

在本申请上述实施方式中，具体阐述了第一路径请求可以是哪些类型的信息，基于这些信息，控制器可对路径信息进行规划，以选择出适合当前待发送数据的最优路径，具备广泛适用性。

在第一方面的一种可能的实现方式中，第一路径类型至少包括如下类型中的任意一种：Overlay网络路径、SRv6路径或服务链(service function chain，SFC)路径。例如，假设第一路径类型是Overlay网络路径，那么路由的路径是通过Overlay网络进行转发；假设第一路径类型是SRv6路径，那么路由的路径是通过SRv6方式进行转发；假设第一路径类型是SFC路径，那么路由的路径是通过SFC方式进行转发，SFC路径的一种典型网络应用场景是：一个数据流通常需要通过多个网络服务设备(如，入侵检测系统、入侵防御系统、防火墙、LB等)，最终才能到达目的端设备，这就是SFC最常用的场景，具体本申请不再对第一路径类型可能存在的形式进行示意。

在本申请上述实施方式中，具体阐述了第一路径类型的几种具体形式，由用户根据需求自行选择选择哪种路由路径，具备可选择性。

在第一方面的一种可能的实现方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持SFC的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。

在本申请上述实施方式中，具体阐述了当第一路径类型选择不同，所涉及的转发节点的具体表现形式也不同，在实际应用中，可根据转发节点的具体部署情况选择合适的路由路径，具备灵活性。

在第一方面的一种可能的实现方式中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式。具体地，一种定义方式可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，例如，不同的路径请求预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段预先向互联网数字分配机构申请得到；另一种定义方式还可以是兼容现有的标准协议，例如，不同路径请求预先定义在扩展DNS请求的标准资源记录的type字段内。

在本申请上述实施方式中，阐述了几种将路径请求定义在扩展DNS请求的资源记录的几种实现方式，可根据实际情况选择如何定义，具备可选择性。

本申请实施例第二方面还提供一种路由方法，该方法包括：首先，源端设备向HttpDNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)。在本申请实施例中，不同的路径请求预先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。源端设备在向Http DNS服务器发送了第一Http请求后，之后将获取由Http DNS服务器发送的第一Http响应，该第一Http响应由Http DNS服务器生成，该第一Http响应中包括与第一路径请求对应的路径信息，该路径信息由Http DNS服务器根据该第一Http请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。类似地，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先，源端设备将路径请求携带在Http请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在第二方面的一种可能的实现方式中，在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一Http响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送的过程具体可以是：首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址，之后，源端设备将第一数据包发送至第一跳转发节点，第一跳转发节点根据该第一头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第一跳转发节点不是最后一跳转发节点，在这种情况下，第一转发节点对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的地址以及第二跳转发节点的地址，之后，由该第一跳转发节点根据转发节点的先后转发顺序将该第二数据包向第二跳转发节点发送。类似地，第二跳转发节点根据该第二数据包中的第二头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第二跳转发节点是最后一跳转发节点，在这种情况下，第二跳转发节点对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包，并由该第二跳转发节点将该删除了第二头域的目标数据包向目的端设备发送。需要注意的是，在本申请实施例中，路径信息中除了最后一跳转发节点之外，其他每个转发节点都需对上一个转发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序、自身的地址以及下一跳转发节点的地址。当某个转发节点接收到由上一个转发节点发送的数据包，根据数据包中头域内的先后转发顺序得知自身为最后一跳，那么该转发节点去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点将得到的目标数据包发送给目的端设备。

在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，源端设备以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与Http DNS服务器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。

在第二方面的一种可能的实现方式中，若路径信息中只包括一个转发节点(即第一转发节点)，那么该第一转发节点接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点会将头域删除，并将删除了头域的目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。

在第二方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。

在第二方面的一种可能的实现方式中，该第一Http请求的生成可以有多种触发形式，作为一个示例，该第一Http请求可以通过安装于该源端设备的SDK生成，具体地，可以是源端设备上安装的应用发起会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一Http请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一Http请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一Http请求。具体地，本申请对如何触发生成第一Http请求的具体实现方式不做限定，此处不再举例示意。

在本申请上述实施方式中，阐述了几种触发第一Http请求生成的应用场景，具备普遍适用性。

在第二方面的一种可能的实现方式中，第一路径请求至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型(如，实时音视频类应用、游戏类应用、浏览器类应用等)、待发送数据的应用ID(如，可以是Overlay网络运营商所维护的应用标识符)、待发送数据的业务类型(如，该数据流是实时音视频数据、游戏指令类数据、网页请求类数据等)、待发送数据的QoS要求(如，待发送数据所需要的QoS性能)、待发送数据要求使用的第一路径类型。

在本申请上述实施方式中，具体阐述了第一路径请求可以是哪些类型的信息，基于这些信息，控制器可对路径信息进行规划，以选择出适合当前待发送数据的最优路径，具备广泛适用性。

在第二方面的一种可能的实现方式中，第一路径类型至少包括如下类型中的任意一种：Overlay网络路径、SRv6路径或SFC路径。

在本申请上述实施方式中，具体阐述了第一路径类型的几种具体形式，由用户根据需求自行选择选择哪种路由路径，具备可选择性。

在第二方面的一种可能的实现方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持SFC的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。

在本申请上述实施方式中，具体阐述了当第一路径类型选择不同，所涉及的转发节点的具体表现形式也不同，在实际应用中，可根据转发节点的具体部署情况选择合适的路由路径，具备灵活性。

本申请实施例第三方面还提供一种路由方法，该方法包括：首先，控制器获取由源端设备发送的第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定。控制器接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。控制器基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，控制器基于接收到的扩展DNS请求规划路径，该扩展DNS请求中包含有对路径的请求(即第一路径请求)，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在第三方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。

在第三方面的一种可能的实现方式中，控制器获取由源端设备发送的第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，控制器再接收由该DNS服务器发送的第一扩展DNS请求。类似地，控制器向源端设备发送第一扩展DNS响应的具体实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该DNS服务器将第一扩展DNS响应向源端设备发送。

在本申请上述实施方式中，具体阐述了源端设备与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。

本申请实施例第四方面还提供一种路由方法，该方法包括：首先，Http DNS服务器获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。Http DNS服务器接收到该第一Http请求后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。Http DNS服务器基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先，源端设备将路径请求携带在Http请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在第四方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。

本申请实施例第五方面提供一种终端设备，该终端设备作为源端设备，具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第六方面还提供一种终端设备，该终端设备作为源端设备，具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第七方面还提供一种控制器，该控制器具有实现上述第三方面或第三方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第八方面还提供一种Http DNS服务器，该Http DNS服务器具有实现上述第四方面或第四方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第九方面提供一种终端设备，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式的方法，或，处理器用于调用该存储器中存储的程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式的方法。

本申请实施例第十方面提供一种控制器，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第三方面或第三方面任意一种可能实现方式的方法。

本申请实施例第十一方面提供一种Http DNS服务器，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第四方面或第四方面任意一种可能实现方式的方法。

本申请第十二方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第四方面或第四方面任意一种可能实现方式的方法。

本申请实施例第十三方面提供了一种计算机程序或计算机程序产品，当该计算机程序或计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第四方面或第四方面任意一种可能实现方式的方法。

本申请实施例第十四方面提供了一种芯片，该芯片包括至少一个处理器和至少一个接口电路，该接口电路和该处理器耦合，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，至少一个处理器用于运行计算机程序或指令，其具有实现如上述第一方面或第一方面任意一种可能实现方式的方法的功能，或，具有实现如上述第二方面或第二方面任意一种可能实现方式的方法的功能，或，具有实现如上述第三方面或第三方面任意一种可能实现方式的方法的功能，或，具有实现如上述第四方面或第四方面任意一种可能实现方式的方法的功能，该功能可以通过硬件实现，也可以通过软件实现，还可以通过硬件和软件组合实现，该硬件或软件包括一个或多个与上述功能相对应的模块。此外，该接口电路用于与该芯片之外的其它模块进行通信，例如，该接口电路可将芯片上处理器得到的路径信息封装后发生给目的端设备，如，发送给其他终端设备(如，手机、个人电脑、智能手表等)或云侧设备(如，云服务器、集群等)。

附图说明

图1为传统DNS解析流程的一个示意图；

图2为标准DNS报文格式的一个示意图；

图3为扩展DNS报文中的伪资源记录的一个示意图；

图4为扩展DNS报文中伪资源记录中各个部分之间关系的一个示意图；

图5为基于智能DNS的GSLB请求流程的一个示意图；

图6为互联网Overlay技术的一个应用场景图；

图7为现有Overlay智能路由的三个子系统的一个框架结构图；

图8为本申请实施例提供的路由方法的一个流程示意图；

图9为DNS协议中标准资源记录格式的一个示意图；

图10为一个标准资源记录的实例；

图11为本申请实施例提供的数据包的一种封装格式的示意图；

图12为本申请实施例提供的数据包的另一种封装格式的示意图；

图13为本申请实施例提供的数据包在各个转发节点之间传递过程的一个示意图；

图14为本申请实施例提供的路由方法的整体流程的一个场景示意图；

图15为本申请实施例提供的各个PoP各自对目标数据包进行解封、再封装以及转发过程的一个示意图；

图16为本申请实施例提供的兼容性分析的一个示意图；

图17为本申请实施例提供的路由方法的另一流程示意图；

图18为本申请实施例提供的路由方法与传统互联网传输的DNS解析方案的对比示意图；

图19为本申请实施例提供的实验拓扑图；

图20为本申请实施例提供的任意两点间时延分布的一个示意图；

图21为本申请实施例提供的PoP点数目分别在100、200、500场景下，四种方法时延随距离的变化曲线的对比图；

图22为用户与服务器的回源请求借助边缘代理服务器做中转建立连接的一个流程示意图；

图23为本申请实施例提供的终端设备的一个结构示意图；

图24为本申请实施例提供的终端设备的另一结构示意图；

图25为本申请实施例提供的控制器的一个结构示意图；

图26为本申请实施例提供的Http DNS服务器的一个结构示意图；

图27为本申请实施例提供的计算机设备的一个结构示意图。

具体实施方式

本申请实施例提供了一种路由方法及设备，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

本申请实施例涉及了许多关于DNS的相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。

(1)域名系统(domain name system，DNS)

DNS是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

具体来说，DNS是互联网上解决网上机器命名的一种系统，传统DNS域名的解析过程为：用户通过终端设备(也可称为源端设备)访问某个网站时，需要首先通过DNS服务器(一种用于提供域名解析服务的服务器)获得该网站的IP地址。域名解析通常不是一次性完成的，常常需要查询若干不同的DNS服务器才能找到该网站对应的IP地址。如图1所示，图1为传统DNS解析流程的一个示意图，用户首先在本地的源端设备上配置一个本地DNS服务器的地址，本地DNS服务器收到用户通过该源端设备发送的DNS请求，若该本地DNS服务器对该DNS请求不能解析，会将该DNS请求转发给更高一级的DNS服务器(如，DNS根服务器)直到找到域名对应的IP地址或确定域名不存在。

(2)DNS报文

域名-实现及标准(RFC1035)中定义了两种报文，一种为查询报文(也可称为DNS请求)，另一种是对查询报文的响应，称为响应报文(也可称为DNS响应)。DNS请求和DNS响应都是用相同的报文格式，分成5个段(有的报文段在不同的情况下可能为空)，如图2所示，图2为标准DNS报文格式的一个示意图，其中，Header段是必须存在的，它定义了DNS报文的类型是DNS请求还是DNS响应，也定义了其他段是否需要存在，以及是标准查询还是其他；Question段描述了查询的问题，包括查询类型(QTYPE)、查询类(QCLASS)以及查询的域名(QNAME)；剩下的3个段则拥有相同的格式，具体地，包含一系列可能为空的资源记录(resource record，RR)，若是多条资源记录，则记为RRs，Answer段包含回答问题的RRs，Authority段包含授权域名服务器的RRs，Additional段则包含和请求相关的但不是必须回答的RRs。

(3)扩展DNS报文

随着业务的复杂化和多样化，RFC1035中定义的DNS消息格式和它支持的消息内容已经不足以满足一些DNS服务器的需求，于是，RFC2671中提出了一种扩展DNS机制(extension mechanisms for DNS，EDNS)，可称为扩展DNS报文，与DNS报文类似，扩展DNS报文也包括两种报文，一种称为扩展DNS请求，另一种为对扩展DNS报文的响应，称为扩展DNS响应，扩展DNS报文是在已有的DNS报文格式的基础上增加一些字段，来支持更多的DNS请求业务。需要注意的是，像DNS服务器这样一个大型且广泛应用的系统软件，新增加扩展协议的时候要考虑到向后兼容性(backward compatibility)，即增加了新特性的消息传输给未支持该特性的服务器时，后者依然能正确处理。

因此，为了保持向后兼容性，并不会对已有的DNS报文的协议格式做更改，而是在扩展DNS报文中引入了一种新的伪资源记录(option resource record，OPT RR)，之所以叫做伪资源记录是因为它不包含任何DNS数据，OPT RR不能被缓存(cache)、不能被转发、不能被存储在zone文件(zone文件是DNS服务器上保存域名配置的文件)中。伪资源记录被放在DNS通信双方(即requestor和responsor)的扩展DNS报文的Additional段的区域内。如图3所示，图3为扩展DNS报文中的伪资源记录的一个示意图，其中，图3中的(a)子示意图为扩展DNS报文中伪资源记录的结构示意图，其包括固定部分和可变部分，最下面的RDATA是可变部分，其余的部分都是固定部分：NAME字段目前为空；TYPE字段是伪资源记录的类型编号，互联网数字分配机构(internet assigned numbers authority，IANA)为其分配的是41(0x29)；TTL字段中是扩展DNS报文消息头部，下面会有介绍；RDLEN字段是可变部分RDATA的长度；RDATA是KV类型的可变部分。而原来的TTL字段被用来存储扩展消息头部中的RCODE和flags，它的格式如图3中的(b)子示意图所示，在图3的(b)子示意图中，高位8个bit是扩展RCODE(返回状态码)，这8个bit加上DNS头部的4bit总共有12bit(8bit在高位)，这样就可以表示更多的返回类型；VERSOION字段表示扩展DNS报文的版本(扩展DNS报文根据支持不同的扩展内容会有很多版本)。在扩展DNS报文中，可变部分RDATA字段的结构则如图3中的(c)子示意图所示，图3中(c)子示意图的OPTION-CODE由IANA分配，OPTION-LENGTH是OPTION-DATA的长度，OPTION-DATA是具体长度。图3中各子示意图中间的关系可如图4所示。需要注意的是，每个DNS消息中只能有一个伪资源记录，当有多种扩展DNS协议时，各个{attribute,value}对一个紧接一个存储在RDATA字段中。

此外，在介绍本申请实施例之前，先对目前源端设备到目的端设备的几种常见路由方式进行简单介绍，使得后续便于理解本申请实施例。

方式一、基于智能DNS的GSLB

基于智能DNS的GSLB请求流程如图5所示，根DNS服务器(在图5中简称根DNS)会将DNS请求转发到GSLB设备(即图5中的基于DNS的GSLB)上，GSLB设备根据服务器的负载情况以及用户的IP信息为用户解析最优的IP地址，放入DNS响应中回复给本地DNS服务器，并由该本地DNS服务器将该DNS响应最终返回给用户。

该方式一解决了源端设备上的应用对用户请求目的地(即目的端设备)的控制，但无法控制目的地访问的路径。例如，源端设备上的应用基于自身的需求考虑(如，安全性考虑、性能考虑等)，想进一步对用户请求的路径做进一步优化，那么该方式一就无法满足该需求。

方式二、Overlay智能路由

由于互联网由多个运营商/互联网服务提供商(internet service provider，ISP)/自治域组成，域间的互联存在着复杂的商业关系，互联网的传输路径受商业关系影响，往往不会是网络中的最短路径。例如，两个亚洲节点间的传输可能会被绕到欧洲，进而增加了端到端的时延。同时，由于互联网的路由对路径性能不感知，路径中的失败或拥塞往往很难避免，或需要很长的收敛时间。

为解决互联网路径的非最优问题，业界提出互联网Overlay技术，通过在互联网上不同地区的数据中心放置转发单元，相互连接互相调度，在现有的公共互联网(即Underlay网络)基础上构建一层新的虚拟覆盖网络(即Overlay网络)。中间部署的转发节点可称为转发中继或PoP。为便于理解，请参阅图6，图6为互联网Overlay技术的一个应用场景图，在图6中，源端设备到目的端设备之间的默认链路为虚线所示的路径，假设在域A和域B间的跨域链路当前面临严重的拥塞，那么依然按照该默认链路进行路由会导致端到端性能下降。而通过Overlay技术，在域A、域B和域C中分别部署有PoP，其中，域A上部署的PoP称为PoP1，域B上部署的PoP称为PoP2，域C上部署的PoP称为PoP3，并在该源端设备部署SDK软件开发工具包(software development kit，SDK)，将流量接入PoP1。Overlay骨干网控制PoP1到PoP3的路由为PoP1→PoP2→PoP3，从而有效绕开域A和域B间的拥塞链路，提升整体端到端表现。

Overlay智能路由是Overlay技术的关键，直接决定接入Overlay网络的用户的传输性能。Overlay智能路由为用户传输选择适合的Overlay网络转发节点PoP，组成端到端最优转发路径。现有Overlay智能路由方案由三个子系统共同实现，这三个子系统分别为：入口PoP选择系统、出口PoP选择系统和Overlay网络内部路由系统。下面对这三个子系统分别进行介绍。

1)入口PoP选择系统

该系统根据用户使用的源端设备的源地址选择最优入口PoP作为首跳接入Overlay网络。源端设备通过部署于该源端设备的SDK发送数据包。为接入Overlay网络，首先，源端设备向入口PoP选择系统发送会话请求，上报源端设备的源地址，入口PoP选择系统通过匹配该源地址，为该用户会话选择最优的入口PoP的IP地址，通常选择原则遵循就近接入原则，即为用户选择距离该源端设备最近的入口PoP，源端设备的源地址与入口PoP的IP地址之间的映射关系可称为“源IP-入口PoP”映射表，该映射表由入口PoP选择系统洗发给入口PoP；源端设备获取到入口PoP的IP地址后，该源端设备在原网络层数据包外侧封装新的外层网络头，目的IP就写为入口PoP的IP地址，并将封装后数据包送入Underlay网络进行传输。这里需要注意的是，数据的传输过程实质都还是基于Underlay网络进行的，overlay网络中的PoP只是用于指示该将数据包发往哪个域。

为便于理解，请参阅图7，图7为现有Overlay智能路由的三个子系统的一个框架结构图，在图7中，源端设备从入口PoP选择系统获取最近的入口PoP的地址(记为PoP1 IP)，获取后由源端设备将PoP1 IP写入数据包的最外层网络包头，目的IP为PoP1 IP，源IP保持不变。

2)出口PoP选择系统

该系统根据目的端设备的IP地址选择出口PoP作为Overlay网络的最后一跳。该系统选择原则通常也是就近原则，即为用户选择距离目的端设备最近的PoP的IP地址，目的端设备的IP地址与出口PoP的IP地址之间的映射关系可称为“目的IP-出口PoP”映射表，该映射表由出口PoP选择系统下发给出口PoP(在一些实现方式中，上述“源IP-入口PoP”映射表与“目的IP-出口PoP”映射表可被合并为一张表，由入口PoP选择系统和出口PoP选择系统分别下发给入口PoP和出口PoP)。具体地，数据包到达入口PoP，入口PoP将最外层网络包头解封装，根据原数据包目的端的IP地址与“目的IP-出口PoP”映射表进行比对，获取出口PoP的IP地址，之后入口PoP在原网络层数据包外侧封装头域，写入出口PoP的IP地址。

如图7所示，数据包到达PoP1后，PoP1解开外层封装，得到原数据包目的端设备的IP地址。将该地址与PoP1维护的“目的IP-出口PoP”映射表(“源IP-入口PoP”映射表与“目的IP-出口PoP”映射表可被合并为一张表合并为一张表的情况)进行比对，得到目的端设备的IP地址最近的出口PoP为PoP3，进而将PoP3的IP地址写入出口PoP字段。

3)Overlay网络内部路由系统

该系统根据出口PoP的IP地址选择下一跳PoP转发点。该系统在Overlay网络内部做PoP等级的路由，通过向各中间PoP节点下发路由表实现，路由表匹配出口PoP，返回下一跳PoP。数据包到达某一PoP时，该PoP将最外层网络包头去掉，并根据头域中的出口PoP地址选择下一跳PoP，选择后将下一跳PoP的IP地址写在最外层网络包头。

如图7所示，假设Overlay网络中从PoP1到PoP3的最优路由是PoP1-PoP2-PoP3(该最优路径由Overlay网络内部路由子系统计算得到)，数据包在PoP1封装出口PoP后，匹配路由表，发现下一跳是PoP2，然后将PoP2的IP地址封装至最外层网络头的目的IP，并送至Underlay网络，Underlay网络会根据目的端设备的IP地址(即目的IP)送至PoP2，PoP2接收数据包，解开外层封装，匹配出口PoP，得到下一跳PoP3，由该PoP2做进一步封装后发送到PoP3。PoP3收到数据包后，发现自己是最后一跳，PoP3将外层封装全部去除，将原始数据包送至Underlay网络，并根据最终目的IP将该数据包送到目的端设备。

该方式二的路由方式的缺点在于各子系统各自独立对路径进行独立优化，然而本地最优决策不等于端到端的全局最优决策。具体而言，选择最优的入口/出口PoP(即距离源端设备/目的端设备最近)并不一定在端到端也是最优的。如图7所示，假设最优的端到端的路径是源端设备→PoP2→目的端设备，但由于该方式二是各子系统独立优化，无论该系统选择的路径是怎样的，都至少会包括入口PoP和出口PoP在内的至少2个PoP，这样实际上就无法获得源端设备→PoP2→目的端设备这条最优路径。此外，该方式二中的每个子系统各自维护状态，每个PoP节点都需部署有对应相关的子系统下发的映射表或路由表，在网络动态变化时各子系统更新难度大，同时会面临更新不一致的问题，导致短暂的发送异常，如，黑洞、环路等。

方式三、分段/源路由(即SR)

SR是一项基于源的路由技术，可简化跨网络域的流量工程和管理。源主机/路由器等根据多个不同子网或内网地址，在数据包头部添加相关的路由信息来为数据包规划转发路径，从而实现网络中的数据平面有选择性地将数据包发往不同目的地。SR的主要优势在于其简化网络和降低资源占用的能力，该技术可以消除网络中过渡路由器和节点的网络状态信息，并且将路径状态信息置入入口节点的数据包标头中，从而使网络管理和运维更加容易。

SR可通过集中控制器对网络路径进行全局优化，同时简化中间节点转发状态维护。但该技术目前只工作在网络内部，如路由器、交换机或PoP，无法将SR技术应用于用户终端，如手机或PC。在终端上应用SR的主要难点是对SR域的控制，体现在可控性差和动态性高。基于可控性，终端厂商不同，内核协议栈不可控，并且网络传输过程涉及大量运营商/ISP或云骨干，无法做到整体控制。基于动态性，在传统SR中，中心控制器通过PCEP协议或Openflow协议配置到相应转发设备，且相对静态，更新难度小，但终端设备数量庞大，且具备移动性，无法下达静态配置。

综上所述，为解决上述问题，本申请实施例首先提供了一种路由方法，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

下面结合附图，对本申请的实施例进行描述。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。具体请参阅图8，图8为本申请实施例提供的路由方法的一个流程示意图，具体可以包括如下步骤：

801、源端设备向控制器发送第一扩展DNS请求，第一扩展DNS请求中包括第一路径请求。

首先，源端设备会向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即用于指示源端设备向目的端设备发送数据包的方式)。

需要注意的是，在本申请实施例中，第一路径请求中包括决定路由路径的相关信息，第一路径请求所包括的信息不同，那么控制器基于该第一路径请求规划的路径信息也不同。例如，该第一路径请求中至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。下面分别进行介绍：

a、待发送数据所要去向的目的端设备的地址，也就是所述的目的端地址，可以是具体的IP地址或URL(该地址也可存放于扩展DNS请求中的QUESTION字段内)。

b、待发送数据的应用类型，例如，实时音视频类应用、游戏类应用、浏览器类应用等，需注意的是，在本申请实施例中，针对应用类型的划分方式可以基于终端设备从终端设备的“应用市场”、“App Store”等(终端设备的制造厂商不同，名称可能不同，此处不做限定)下载应用程序时，应用市场中已经将各个应用程序进行了分类(即应用市场标签确定的分类信息，从应用市场中下载的每个应用程序都有属于自己的分类)。

c、待发送数据的应用ID，可以是Overlay网络运营商所维护的应用标识符，通过匹配映射，可获知该待发送数据发送的QoS需求及优先级等，例如，某些应用购买了Overlay网络的优质加速服务，则计算路径时将会分配更为优质的路径，而为低优先级应用分配路径时，可以分配传输成本更低的路径。

d、待发送数据的业务类型，是对该待发送数据流的描述，例如，待发送数据流是实时音视频数据、游戏指令类数据、网页请求类数据等，不同的业务类型对端到端性能的要求也不同，在计算路径时可纳入考量。

e、待发送数据的QoS要求，是对路径性能的直接描述，根据该信息，控制器为其分配满足QoS需求的路径，并有效规划资源。

f、待发送数据要求使用的路径类型(即所述的第一路径类型)，可包括Overlay网络路径、SRv6路径或SFC路径，所对应的是不同的传输场景，例如在SRv6网络中，源到目的地既可以使用Overlay路径传输，也可使用Underlay SRv6路径传输，通过在路径请求中传递该信息，可获取相应的路径信息。例如，假设第一路径类型是Overlay网络路径，那么路由的路径是通过Overlay网络进行转发；假设第一路径类型是SRv6路径，那么路由的路径是通过SRv6方式进行转发；假设第一路径类型是服务链(service function chain，SFC)路径，那么路由的路径是通过服务链方式进行转发，服务链路径的一种典型网络应用场景是：一个数据流通常需要通过多个网络服务设备(如，入侵检测系统(intrusion detectionsystems，IDS)、入侵防御系统(intrusion prevention systems，IPS)、防火墙、LB等)，最终才能到达目的端设备，这就是服务链最常用的场景，具体本申请不再对第一路径类型可能存在的形式进行示意。

以上类别的信息在路径请求中可包含一种或多种，例如，仅包含应用ID，控制器维护相应的匹配关系，即可获知该路径请求的类别、相关QoS需求等。同时，该信息也不是必须信息，控制器可默认路径请求的类型等，具体此处不予赘述。

需要说明的是，在本申请实施例中，该第一扩展DNS请求的生成可以有多种触发形式，作为一个示例，该第一扩展DNS请求可以通过安装于该源端设备的SDK(终端软件套件，可被应用调用)生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一扩展DNS请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一扩展DNS请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一扩展DNS请求。具体地，本申请对如何触发生成第一扩展DNS请求的具体实现方式不做限定，此处不再举例示意。

还需要说明的是，本申请所述的控制器可以部署在顶级DNS服务器上，也可以独立部署，可以是以硬件设备的形态存在，也可以是以软件模块的形态存在，还可以部署多个控制器以实现容灾功能(即在正常情况下，只有主控制器工作，其他控制器作为备份)，具体此处对控制器的具体表现形态、部署方式、部署数量等不做限定。

还需要说明的是，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定，为便于理解，作为一种示例，下面以第一路径请求中包含的信息为第一路径类型为例，并分别基于增加新的扩展字段和兼容现有的标准协议这两种定义方式进行阐述。

一、通过增加新的扩展字段达到在扩展DNS请求中定义路径类型的目的

在本申请实施例中，不同的路径类型可以预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段需要预先向互联网数字分配机构(IANA)申请得到。

具体地，可参考图2，本申请实施例所提供的扩展DNS请求所包括的Header、Question、Answer、Authority字段与常规的DNS报文一致，例如，Question字段中将目的地址(可以是目的端设备的IP地址、URL地址等)放入QNAME字段，Answer字段为空。不同的地方在于，在该扩展DNS请求的Additional字段内，可正常添加应用所需的新的扩展字段，具体地，可以在最后一条之后添加新的与路径请求相关的RDATA，RDATA的标准格式如图3中的(c)子示意图所示。在本申请实施例中，需要预先向IANA申请新的OPTION-CODE：QPATH(该QPATH为自定义，申请被批准后即被公开)，OPTION-CODE：QPATH字段表示对路径类型的请求；而在OPTION-DATA字段内，则放入对路径类型请求的类别。例如，若OPTION-DATA内放入的是Overlay，表示请求的路径类型是基于Overlay网络的转发路径；若OPTION-DATA内放入的是SRv6，表示请求的路径类型是基于SRv6的转发路径(即可支持源端设备发起SRv6传输)；若OPTION-DATA内放入的是SFC，表示请求的路径类型是基于SFC的转发路径(即可支持源端设备发起SFC传输)，具体本申请不再对OPTION-DATA内放入的路径类型进行示意。

需要注意的是，用QPATH表示对路径类型的请求是本申请自定义的，也可以用其他单词或句子表示对路径类型的请求，只要能够用于作为对路径类型的请求的唯一标识即可，具体本申请对该标识的具体表现形式不做限定。

还需要注意的是，本申请上述示例是直接用Overlay、SRv6、SFC等表示路径类型，在本申请的一些实施方式中，也可以赋予不同路径类型各自唯一对应的标识，对应的标识也可以用于指示对应的路径类型，例如，路径类型为Overlay网络、SRv6路径、SFC路径的标识可以分别是1(或，A、one等标识)、2(或，B、two等标识)、3(或，C、three等标识)，在这种情况下，当OPTION-DATA内的数据为对应标识时(如，1)，则说明对应的路径类型是Overlay网络。

二、通过兼容现有的标准协议达到在扩展DNS请求中定义路径类型的目的

与第一种方式不同的地方在于，本申请实施例给出了一种兼容现有标准协议的方法，即不同路径类型还可以预先定义在扩展DNS请求的标准资源记录内，例如，可以是定义在扩展DNS请求的标准资源记录的type字段内。这种方式的好处在于：不需要事先向IANA申请。

具体地，可参阅图9，图9为DNS协议中标准资源记录格式的一个示意图，图10为一个标准资源记录的实例。其中，图9中的TYPE字段表示资源记录类型，常用的几种资源记录类型如表1所示。

表1.几种常见的TYPE字段表示的资源记录类型

TYPE字段	资源记录类型
		A	地址(address)，IPv4
AAAA	地址(address)，IPv6
		NS	域名服务器(name server)
SOA	起始授权机构(start of authority)
		MX	邮件交换(mail exchanger)
CNAME	规范名(canonical name)
		PTR	指针(pointer)
TXT	文本(text)
		SRV	服务(service)

由于TYPE字段用于表示资源记录类型，且TYPE字段内的TXT为自定义文本，不易产生冲突，因此，在本申请的一些实施方式中，可以利用TXT字段来达到定义路径类型的目的。例如，传统的资源请求在QUESTION字段中的QTYPE赋值A类型资源请求，服务器则返回QNAME中目的端设备的IP地址。而在本申请中，由于需获取路径类型，因此，可以在QTYPE中填写TXT类型。对路径请求的类型，可以对目的端设备地址进行扩展，如，对www.huawei.com的路径请求，则在QNAME字段内www.overlay.huawei.com代表Overlay网络的路径类型请求，QNAME字段内www.srv6.huawei.com代表SRv6路径类型请求。控制器则需要配置代表不同路径类型的多条TXT类型的资源记录，资源记录的格式如图9所示，其中TYPE字段为TXT，NAME为扩展后的目的地址，RDATA则记录路径信息和目的端设备的IP地址，如{PoP1 IP，PoP2IP，PoP3 IP，dst IP}，其中，PoP1 IP、PoP2 IP、PoP3 IP分别为PoP1、PoP2、PoP3的IP地址，dst IP指的是目的端设备的IP地址。

需要说明的是，在本申请的一些实施方式中，源端设备向控制器发送第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS请求向该控制器发送。具体地，可以由该DNS服务器对源端设备发送的第一扩展DNS请求进行递归查询，该递归查询的过程可复用常规DNS服务器的处理流程，此处不予赘述。

这里需要注意的是，与该源端设备对应的DNS服务器是对与该源端设备对应的本地DNS服务器、DNS根服务器、权威DNS服务器、顶级DNS服务器等的概括，用于接收源端设备发送的第一扩展DNS请求，并将该第一扩展DNS请求发送到所述的控制器。

在本申请实施例中，使得DNS服务器将该第一扩展DNS请求向控制器发送的实现方式可以是该控制器注册权威DNS服务器，并在DNS根服务器或顶级DNS服务器中加入该控制器的地址，这样当与该源端设备对应的DNS服务器接收到该第一扩展DNS请求，基于已注册的控制器的地址，基于递归查询流程，该第一扩展DNS请求会被发送到该控制器。例如，在.com服务器中注册huawei.com的权威服务器地址，当查询URL为www.huawei.com的扩展DNS请求时，该扩展DNS请求将被送至huawei.com权威服务器(即控制器部署位置)。

802、控制器根据该第一扩展DNS请求，得到与该第一路径请求对应的路径信息。

控制器接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。需要注意的是，控制器根据该第一扩展DNS请求得到与该第一路径请求对应的路径信息的实现前提是：控制器已获得规划路径的必要信息(如，用户要求时延少、丢包少或带宽大等要求下的一些必要指令、指令优先等级等)，该必要信息可以是携带在该第一扩展DNS请求中，也可以是由与源端设备对应的DNS服务器向该控制器发送。为便于理解，下面分别进行阐述：

一、第一扩展DNS请求中已包含规划路径的全部必要信息

在本申请实施例中，第一扩展DNS请求中已包含控制器进行路径规划的全部必要信息，在这种情况下，控制器获取到该第一扩展DNS请求后，对该第一扩展DNS请求解析后，基于其中包含的全部必要信息，就可得到与该第一路径请求对应的路径信息，该路径信息一般为与第一路径请求对应的最优转发路径。

二、第一扩展DNS请求中不包含或只包含规划路径的部分必要信息

在本申请实施例中，第一扩展DNS请求中不包含规划路径的必要信息，或，第一扩展DNS请求中只包含规划路径的部分必要信息。在这种情况下，第一扩展DNS请求中不包含的必要信息一般是源端设备获取困难或不能获取到的，因此，在源端设备向对应的DNS服务器发送第一扩展DNS请求后，该DNS服务器需要为控制器收集对规划路径必要的其他信息(即第一扩展DNS请求中不包含的那部分必要信息)。例如，源端设备的源地址，可以是由本地DNS服务器调用EDNS0扩展协议CSUBNET获得得到，再将该源地址加入该第一扩展DNS请求一起向控制器发送(或各自单独发送)。

这里需要注意的是，在本申请实施例中，获取源端设备的源地址不在源端设备而是在本地DNS服务器的原因是NAT穿越问题，源端设备上报的地址可能是私网地址(源地址理论上也可由源端设备自行获取，只是获取过程困难)，对控制器来说私网地址是无用信息，本地DNS服务器获取的地址则是公网地址(即本申请所述的源地址)，才可用于控制器做路径规划。

还需要说明的是，在本申请实施例中，默认控制器可基于得到的必要信息实现路径规划的功能，至于该控制器如何基于得到的必要信息得到规划好的路径信息，可基于已有的算法或自研算法得到，此处不做限定。

803、控制器向源端设备发送第一扩展DNS响应，该路径信息包含在该第一扩展DNS响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。

控制器基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。还需要说明的是，在本申请的一些实施方式中，控制器向源端设备发送第一扩展DNS响应的实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS响应向该源端设备发送。

类似地，第一扩展DNS响应作为第一扩展DNS请求的响应消息，针对不同路径请求的返回也可以是事先定义在扩展DNS响应的资源记录的字段内，具体也可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，本申请对此不做限定，但需要注意的是，第一扩展DNS响应需与第一扩展DNS请求的实现方式对应。为便于理解，作为一种示例，下面以第一路径请求中包含的信息为第一路径类型为例，分别基于增加新的扩展字段和兼容现有的标准协议这两种定义方式进行阐述。

一、通过增加新的扩展字段达到在扩展DNS响应中定义路径信息的目的

由上述可知，不同的路径类型可以预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段需要预先向IANA申请得到，那么在本申请实施例中，针对路径类型的返回也可以预先定义在扩展DNS响应的伪资源记录的扩展字段内，该扩展字段也需要预先向IANA申请得到。

作为一个示例，可以预先向IANA申请OPTION-CODE：PATH(该PATH为自定义，申请被批准后即被公开，与扩展DNS请求中的扩展字段OPTION-CODE：PATH对应)，OPTION-CODE：PATH字段表示对路径类型请求的返回；而在对应的OPTION-DATA字段内，则放入对应路径类型的路径信息(如，可以路径列表的形式存放)。例如，若请求的路径类型是基于Overlay网络的转发路径，那么对应的OPTION-DATA内放入的是基于Overlay网络的路径信息(如，PoP地址列表{PoP1 IP，PoP2 IP，PoP3 IP})；若请求的路径类型是基于SRv6的转发路径(即可支持源端设备发起SRv6传输)，那么对应的OPTION-DATA内放入的是基于SRv6的路径信息；若请求的路径类型是基于SFC的转发路径(即可支持源端设备发起SFC传输)，那么对应的OPTION-DATA内放入的是基于SFC的路径信息，具体本申请不再对OPTION-DATA内放入的路径信息进行示意。

需要注意的是，用PATH表示对路径类型请求的返回也是本申请自定义的，同样地，也可以用其他单词或句子表示对路径类型的请求，只要能够用于作为对路径类型请求的返回的唯一标识即可，具体本申请对该标识的具体表现形式不做限定。

这里还需要说明的是，在本申请实施例中，是通过预先向IANA申请一对新的扩展字段(即OPTION-CODE：QPATH和OPTION-CODE：PATH)来达到在扩展DNS请求中定义路径类型(即请求消息)、在扩展DNS响应中定义路径信息(即响应消息)的目的。在本申请的另一些实施方式中，还可以是只通过预先向IANA申请一个新的扩展字段来同时达到在扩展DNS请求中定义路径类型且在扩展DNS响应中定义路径信息的目的。

申请一个新的扩展字段与申请一对新的扩展字段不同之处在于：只需先判断交互的消息是属于请求消息还是响应消息，作为一个示例，以请求的路径类型为Overlay网络为例，若是源端设备向控制器发送的请求消息，那么该扩展字段中OPTION-DATA内放入的就是Overlay，表示请求的路径类型是基于Overlay网络的转发路径；若是控制器向源端设备发送的响应消息，那么该扩展字段中OPTION-DATA内放入的就是基于Overlay网络的路径信息(如，PoP地址列表{PoP1 IP，PoP2 IP，PoP3 IP})。

二、通过兼容现有的标准协议达到在扩展DNS响应中定义路径信息的目的

与第一种方式不同的地方在于，本申请实施例给出了一种兼容现有标准协议的方法，即针对不同路径类型请求的返回也可以预先定义在扩展DNS响应的标准资源记录内，例如，可以是定义在扩展DNS响应的标准资源记录的type字段内，具体地，源端设备获取第一扩展DNS响应后，直接总响应报文的ANSWER中的RATA获取目的地址。这种方式的好处在于，不需要事先向IANA申请。具体的定义方式与上述通过兼容现有的标准协议达到在扩展DNS请求中定义路径类型的目的的方式类似，此处不予赘述。

为便于理解上述步骤802和步骤803的过程，下面举例进行示意：控制器接收到源端设备发送的扩展DNS请求，若在该扩展DNS请求的Additional字段的RDATA中发现OPTION-CODE是QPATH的扩展字段，说明该扩展DNS请求是包含了路径类型的第一扩展DNS请求，并在其OPTION-DATA中发现请求的路径类型为Overlay网络的路径类型，说明是对Overlay网络路径的请求。在这种情况下，控制器从CSUBNET扩展协议中的OPTION-DATA中读取源端设备的源地址，并根据源地址、目的地址(如，URL地址、目的端设备的IP地址等)做匹配计算，得到从源端设备访问该目的端设备的最优Overlay路径，该路径信息通过Additional字段的RDATA进行返回，该控制器在扩展DNS响应的Additional字段的RDATA中添加对路径类型请求的回应(即路径信息)OPTION-CODE：PATH，OPTION-DATA则为代表Overlay网络的路径信息，如，可以是PoP地址列表{PoP1IP，PoP2 IP，PoP3 IP}。需要注意的是，控制器对其他字段无特殊处理，例如，Answer字段中正常返回目的地址。

在本申请实施例中，路径信息的规划与源端设备的应用类型、应用需求(如，是否大带宽、是否时延小等需求)等相关，控制器规划的路径一般是指从源端设备至目的端设备之间符合当前要求的最优路径，当该路径信息的取值不同，那么路径信息所包含的信息也不同，具体地，可被划分为如下几种类型：

1)在路径信息的取值不为空的情况下，路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

2)在路径信息的取值为空的情况下，说明该路径信息不包括任何转发节点。

需要说明的是，在本申请的一些实施方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持服务链的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。

804、源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向目的端设备发送。

在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一扩展DNS响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送。

下面基于该路径信息中包括的转发节点数量具体阐述如何经由转发节点将待发送的目标数据包向目的端设备发送。

一、路径信息中包括的的转发节点为n个(n≥2)

在申请实施例中，首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址。这里需要注意的是，第一转发节点的地址可以是指第一转发节点的IP地址，也可以是指用于指向第一转发节点IP地址的标识(如，ID)，还可以是其他可以对第一跳转发节点进行寻址的标识(可称为寻址标识)等，标识(或寻址标识)与IP地址之间存在映射关系，且该映射关系存储在第一转发节点上。类似地，本申请实施例所涉及的其他转发节点的地址(如，第二跳转发节点、第三跳转发节点、……、最后一跳转发节点等)的含义均与此类似，下面就不予赘述。为便于阐述，下面以第一路径请求中包含的信息为第一路径类型为例，且均以转发节点的地址为IP地址为例进行说明。

以路径类型为Overlay网络路径为例，源端设备根据得到的路径信息对目标数据包进行封装的封装方式包括但不限于：

1)在网络层(L3)报文外侧添加头域PoP_list，将路径信息(如，路径列表)放入该头域内，添加UDP头，并将路径列表中的第一个PoP的IP地址和源端设备的源地址放入最外层网络包头。数据包的封装格式可如图11所示，封装后源端设备将封装后的数据包送入Underlay网络进行转发。

2)在传输层(L4)报文外侧进行封装，添加的头域包含两个字段，PoP_list和OLDL3，类似地，将路径信息(如，路径列表)放入该头域内，添加UDP头，并将路径列表中的第一个PoP的IP地址和源端设备的源地址放入最外层网络包头，数据包的封装格式可如图12所示，封装后源端设备将封装后的数据包送入Underlay网络进行转发。

这里需要注意的是，图12的封装方式与图11的封装方式唯一不同的是：源端设备对数据包的截获位置，图11示意的是在网络层截获，图12示意的是在传输层截获，两种方式仅在工程上有区别，其他无本质区别。

源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)之后，会将该第一数据包发送至第一跳转发节点，第一跳转发节点(假设为R1)根据第一头域读取到自身为目的地址(即图13中源端设备侧最外层网络包头中的Dst＝R1)、源端设备为源地址(即图13中源端设备侧最外层网络包头中的Src＝源IP)，就可确定该第一数据包是由源端设备发送给自身的，并且可确定自身为目的地址；此外，该第一跳转发节点R1还将根据该第一头域内包括的转发节点的先后转发顺序(即图13中的R-list)判断自身是否是最后一跳转发节点，假设R-list＝{R1、R2}，由该R-list可知，该第一跳转发节点R1不是最后一跳转发节点，在这种情况下，第一转发节点R1对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点R1封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的IP地址以及第二跳转发节点的IP地址，具体请参阅图13，第一跳转发节点的IP地址为图13中第一跳转发节点R1侧最外层网络包头中的Src＝R1，第二跳转发节点的IP地址为图13中第一跳转发节点R1侧最外层网络包头中的Dst＝R2，转发节点的先后转发顺序依然为R-list＝{R1、R2}，之后，由该第一跳转发节点R1根据转发节点的先后转发顺序(即R-list)将该第二数据包向第二跳转发节点R2发送。

类似地，第二跳转发节点R2根据该第二数据包中的第二头域读取到自身为目的地址、第一转发节点R1为源地址，就可确定该第二数据包是由第一转发节点R1发送给自身的，并且可确定自身为目的地址；此外，该第二跳转发节点R2还将根据该第二头域内包括的转发节点的先后转发顺序(即R-list)判断自身是否是最后一跳转发节点，由于R-list＝{R1、R2}，由该R-list可知，该第二跳转发节点R2是最后一跳转发节点，在这种情况下，第二跳转发节点R2对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包(即只包含原始网络层包头)，并由该第二跳转发节点R2将该删除了第二头域的目标数据包向目的端设备发送。

这里需要说明的是，在本申请上述实施例中，假设的是路径信息中包括了2个转发节点R1和R2，且这两个转发节点之间的先后转发顺序为R-list＝{R1、R2}。在本申请的另一些实施方式中，如果路径信息中包括的转发节点为R1、R2、……、Rn，n＞2，且这些转发节点之间的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么转发节点R1作为第一跳转发节点，对目标数据包封装时的头域包括的则是转发节点的先后转发顺序R-list＝{R1、R2、……、Rn}、源端设备的源地址以及第一跳转发节点的IP地址，该第一跳转发节点R1会将封装好的数据包(称为第一数据包)发送给第二跳转发节点R2，再由第二跳转发节点R2对接收到的第一数据包解封装后再封装，第二跳转发节点R2对目标数据包封装时的头域包括的就是转发节点的先后转发顺序R-list＝{R1、R2、……、Rn}、第一跳转发节点的IP地址以及第二跳转发节点的IP地址，该第二跳转发节点R2会将封装好的数据包(称为第二数据包)发送给下一跳转发节点，……，直至将数据包发送至最后一跳转发节点Rn。需要注意的是，R-list＝{R1、R2、……、Rn}中除了最后一跳转发节点Rn之外，其他每个转发节点都需对上一个转发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序R-list＝{R1、R2、……、Rn}、自身的IP地址以及下一跳转发节点的IP地址。当转发节点Rn接收到由转发节点Rn-1发送的数据包，根据数据包中头域内的R-list得知自身为最后一跳，那么转发节点Rn去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点Rn将得到的目标数据包送至Underlay网络发送给目的端设备。

需要注意的是，在本申请实施例中，各个转发节点对解封装后的目标数据包再次封装的操作与上述源端设备对初始的目标数据包的封装过程类似，可以是在网络层(L3)报文外侧封装，也可以是在传输层(L4)报文外侧进行封装，具体可参阅图11和图12对应所述的封装方式，此处不予赘述。

二、路径信息中包括的转发节点为1个

在申请实施例中，路径信息中只包括一个转发节点(即R-list＝{R1})，源端设备对目标数据包的封装方式与上述包括多个转发节点的路径信息的方式类似，此处不予赘述。

与上述路径信息中包括的多个转发节点不同的地方在于：第一转发节点R1接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序R-list＝{R1}得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点R1会将头域删除，并将删除了头域的目标数据包向目的端设备发送。

需要说明的是，在本申请的一些实施方式中，在路径信息的取值为空的情况下，即R-list＝{}，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包放入Underlay网络向目的端设备发送。

需要说明的是，在本申请上述实施例中，每个转发节点在头域中封装的先后转发顺序都是全量的，即假设路径信息中包括n个转发节点，分别为R1、R2、……、Rn，转发节点的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么每个转发节点在封装头域时，都会将该全量的先后转发顺序R-list＝{R1、R2、……、Rn}封装在头域中。这种全量的方式由于仅需改变头域中的指针项，更改较为容易，并且由于路径信息中包含的转发节点数目一般不多，因此每个转发节点都携带全量的先后转发顺序也不会带来更高的计算开销。

在本申请的另一些实施方式中，每个转发节点在头域中封装的先后转发顺序也可以是增量的，即假设路径信息中包括n个转发节点，分别为R1、R2、……、Rn，转发节点的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么在第一跳转发节点的头域中，携带的先后转发顺序为R-list-1＝{R2、……、Rn}，在第二跳转发节点的头域中，携带的先后转发顺序为R-list-2＝{R3、……、Rn}，在第三跳转发节点的头域中，携带的先后转发顺序为R-list-3＝{R3、……、Rn}，以此类推，每个当前转发节点中携带的先后转发顺序都为下一跳转发节点至最后一跳转发节点之间的先后转发顺序，而在最后一跳转发节点中，携带的信息为空，说明为最后一跳，那么该最后一跳转发节点就将头域删除，并将该删除了头域的目标数据包向目的端设备发送。这种增量的方式则需要对头域的长度进行修改。

还需要说明的是，在本申请的一些实施方式中，控制器可直接作为授权DNS服务器，也可配置为DNS代理方式。换句话说，本申请所述的控制器，本质可看做是一个DNS服务器，具备NS RR查询并返回的功能。其他的DNS服务器，如本地DNS服务器等，无需做任何修改，根据传统DNS协议，当本地DNS服务器不存在响应RR时，就会将带有路径请求的扩展DNS请求导向控制器所在的DNS服务器做查询。

还需要说明的是，在本申请上述实施例中，均是由源端设备生成第一扩展DNS请求，而在本申请的另一些实施方式中，该第一扩展DNS请求不限定仅由源端设备生成，该第一扩展DNS请求的生成也可以是由其他设备完成，例如DNS服务器、DNS proxy或其他第三方设备。该设备在截获源端设备发送的传统DNS请求后，修改为带有路径请求的扩展DNS请求，并结合控制器完成后续操作，以得到路径信息，该路径信息可以携带在传统DNS请求中直接由控制器返回至源端设备，该路径信息也可以携带在其他响应(如，扩展DNS响应)中由其他设备进行中转处理后，并最终发送给源端设备，具体本申请对此不做限定。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先源端设备将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息定义在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

为便于理解，下面以源端设备的路径请求为路径类型、且路径类型为Overlay网络路径为例，对整个路由方法的整体流程进行说明，具体请参阅图14，图14为本申请实施例提供的路由方法的整体流程的一个场景示意图，整个路由过程如下：

步骤①，首先，源端设备(如，手机)上的某个应用发起会话请求，例如，浏览器应用发起访问www.huawei.com的请求，该会话请求触发源端设备调用部署于该源端设备上的SDK生成扩展DNS请求，并将该扩展DNS请求向与源端设备对应的DNS服务器发送，该扩展DNS请求中就包括第一路径类型(假设该第一路径类型为Overlay网络路径)。

步骤②，DNS服务器对源端设备发送的扩展DNS请求进行递归查询，该步骤可复用DNS服务器的常规处理流程，并将该扩展DNS请求向控制器发送。需要注意的是，在该步骤中，若扩展DNS请求中没有包括控制器用于规划路径的全部信息(如，不包括源端设备的源地址)，那么DNS服务器还需在这个步骤中同步收集对路径规划必要的信息，收集到的必要信息可加入到该扩展DNS请求中再一并发送给控制器，也可以独立发送给控制器。

步骤③，控制器根据接收到的扩展DNS请求中的信息做匹配查询。具体地，若控制器在Additional字段的RDATA中未发现OPTION-CODE是QPATH的扩展字段(假设该扩展字段已事先向IANA申请到)，或根本不存在任何RDATA，说明这是一条常规的DNS报文，控制器则对其做常规DNS报文处理，即返回对应目的端设备的目的地址(如，返回对应URL的IP地址)；若控制器在Additional字段的RDATA中发现OPTION-CODE是QPATH的扩展字段，说明是包含路径类型的DNS请求，并在其OPTION-DATA中发现路径类型为Overlay网络路径，说明是对Overlay网络路径的DNS请求，同时控制器从CSUBNET扩展协议中的OPTION-DATA中读取到源端设备的源地址，控制器基于该源地址、目的设备的目的地址做匹配计算，得到从用户访问该目的地址的最优Overlay网络路径，该路径信息通过写入到Additional字段的RDATA中进行返回给DNS服务器。例如，控制器在Additional字段的RDATA内的最后一条之后添加新的扩展字段OPTION-CODE：PATH(假设该扩展字段已事先向IANA申请到)，OPTION-DATA则为代表Overlay网络路径的PoP地址列表，如{PoP1 IP，PoP2 IP，PoP3 IP}。需要注意的是，如果对路径类型的请求不是Overlay网络，这里OPTION-DATA就是其他的路径信息的路径列表，也就是说，这里的路径列表需与路径类型对应。

步骤④，DNS服务器将接收到的扩展DNS响应发送给源端设备。

步骤⑤，源端设备接收到DNS服务器发送的扩展DNS响应，对该报文进行解析。具体地，若源端设备在Additional字段的RDATA中未发现OPTION-CODE是PATH的扩展字段，或根本不存在任何RDATA，说明这是一条常规的DNS响应，源端设备则根据ANSWER字段中的IP地址做正常转发；若源端设备在Additional字段的RDATA中发现OPTION-CODE是PATH的扩展字段，则读取OPTION-CODE是QPATH的扩展字段，若其OPTION-DATA值为Overlay，则说明是Overlay网络的路径类型，PATH中的OPTION-DATA则是表示与Overlay网络路径对应的路径列表，在这种情况下，源端设备将待发送的目标数据包进行封装，封装的头域中包括转发节点的先后转发顺序(如，PoP的路径列表PoP-list)、源端设备的源地址、第一跳PoP的IP地址，并将该封装了头域的数据包发送给第一跳PoP。

步骤⑥，该路径列表中所涉及到的各个PoP按照先后转发顺序接收到数据包后，并解开外层封装的头域，读取PoP-list，并将下一个PoP的IP地址放入新的外层网络包头，送至Underlay网络，若该PoP是PoP-list中的最后一跳，则该PoP删除数据包的头域，将初始的目标数据包送至Underlay网络发送至目的端设备。具体地，步骤⑥的过程可参阅图15所示，详细封装、解封装的过程可参阅图13对应的实施例所述，此处不予赘述，需注意的是，图15是为了展示各个PoP如何对目标数据包进行解封、再封装以及转发过程，因此在图15中，省略了DNS服务器。

需要说明的是，在图14对应的实施例中，是以扩展DNS请求中包括的路径类型为Overlay网络路径为例进行阐述的，也就是在扩展DNS请求的QPATH扩展字段的OPTION-DATA中填写的是Overlay网络路径。在本申请的其他的一些实施方式中，也可支持源端设备发起SRv6传输，在这种情况下，在扩展DNS请求的QPATH扩展字段的OPTION-DATA中填写的是SRv6，并且在步骤③和步骤④中，控制器根据该扩展DNS请求，匹配计算最优的SRv6路径的路径列表SRv6-list，并将该路径列表SRv6-list放入PATH扩展字段的OPTION-DATA中由DNS控制器进行返回。在步骤⑤和步骤⑥中，源端设备以及转发节点根据获取的SRv6路径的路径列表SRv6-list进行封装和转发，该封装和转发过程与SRv6转发标准类似，此处不予赘述。需要注意的是，路径类型为SRv6路径的重要应用场景是企业网环境，且包含于同一SR域，源端设备可以是企业网中的手机、PC等终端设备，本申请实施例中的路径类型(即SRv6路径)也可替换为SR MPLS，即路径类型可变为MPLS标签栈，路由方法与SRv6路径类似，此处不予赘述。

还需要说明的是，本申请实施例中扩展DNS请求中包括的路径类型除了可以是Overlay网络路径、SRv6路径之外，还可以是SFC路径，即本申请所述的路由方式可支持SFC路径，具体地，当在QPATH的OPTION-DATA中的路径类型为SFC，则在步骤③和步骤④中，控制器返回的扩展DNS响应中的路径信息是SFC的路径列表，源端设备和各转发节点基于该SFC的路径列表对数据包进行封装以及转发，该过程与上述类似，此处不予赘述，不同的地方在于：相关的转发节点需要支持步骤⑥中的转发功能。

下面对本申请实施例提供的路由方法的兼容性进行分析，具体请参阅图16，图16为本申请实施例提供的兼容性示意图，其中，传统源端设备是指没有部署SDK的源端设备，新源端设备是指部署SDK的源端设备，传统DNS服务器是指没有对应部署控制器的DNS服务器，新DNS服务器是指对应部署了控制器的DNS服务器。下面针对不同情况进行分析：

a、若是传统源端设备向传统DNS服务器发送DNS报文，则是常规的DNS报文解析流程。

b、若是传统源端设备向新DNS服务器发送DNS报文，新DNS服务器根据QUESTION字段正常返回目的端设备的目的地址。

c、若是新源端设备向传统DNS服务器发送DNS报文，传统DNS服务器根据QUESTION字段正常返回目的端设备的目的地址，这是因为传统DNS服务器在ADDITIONAL字段中无法解析OPTION-CODE：QPATH，因此不做特殊处理。

d、若是新源端设备向新DNS服务器发送DNS报文，新DNS服务器可以解析OPTION-CODE：QPATH，具体过程则为本申请实施例所述的路由过程。

由上述分析可知，本申请实施例遵循后向兼容性原则，即新源端设备可配合传统DNS服务器(无控制器)或新DNS服务器(对应部署有控制器)，且新DNS服务器可回应传统DNS请求或扩展DNS请求。

需要说明的是，在本申请上述所有实施例中，阐述的都是将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。在本申请的另一些实施方式中，还可以是以其他信息为媒介，实现在终端为互联网传输配置端到端传输路径的功能。例如，可以使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到可灵活配置的HTTPDNS服务器，从而绕过运营商的本地DNS服务器，能够避免本地DNS服务器造成的域名劫持问题和调度不精准问题。具体地，请参阅图17，图17为本申请实施例提供的路由方法的另一流程示意图，该方法可以包括如下步骤：

1701、源端设备向Http DNS服务器发送第一Http请求，第一Http请求中包括第一路径请求。

首先，源端设备向Http DNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)。

同样地，在本申请实施例中，第一路径请求中包括对决定路由路径的相关信息，第一路径请求所包括的信息不同，那么控制器基于该第一路径请求规划的路径信息也不同。例如，该第一路径请求中至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。具体介绍请参阅上述步骤801中的描述，此处不予赘述。

这里需要注意的是，在图8对应的实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。在本申请实施例中，不同的路径请求预先定义在Http请求内，定义过程不涉及标准，因此无需向机构(如，IANA)申请。

需要说明的是，在本申请实施例中，该第一Http请求的生成可以有多种触发形式，作为一个示例，该第一Http请求可以通过安装于该源端设备的SDK生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一Http请求；作为另一示例，该第一Http请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一Http请求；作为另一示例，该第一Http请求还可以通过写协议栈的方式触发生成。具体地，本申请对如何触发生成第一Http请求的具体实现方式不做限定，此处不再举例示意。

1702、Http DNS服务器根据第一Http请求，得到与该第一路径请求对应的路径信息。

Http DNS服务器接收到由源端设备发送的第一Http请求之后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。

需要说明的是，在本申请实施例中，默认Http DNS服务器可基于第一Http请求中的信息实现路径规划的功能，至于该Http DNS服务器如何基于得到的信息得到规划好的路径信息，可基于自研算法得到，此处不做限定。

1703、Http DNS服务器向源端设备发送第一Http响应，该路径信息包含在该第一Http响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。

Http DNS服务器基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。

类似地，在本申请实施例中，路径信息的规划与源端设备的应用类型、应用需求(如，是否大带宽、是否时延小等需求)等相关，Http DNS服务器规划的路径一般是指从源端设备至目的端设备之间符合当前要求的最优路径，当该路径信息的取值不同，那么路径信息所包含的信息也不同，具体地，可被划分为如下几种类型：

1)在路径信息的取值不为空的情况下，路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

2)在路径信息的取值为空的情况下，说明该路径信息不包括任何转发节点。

需要说明的是，在本申请的一些实施方式中，当路径请求为路径类型，那么路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持服务链的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。

1704、源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向目的端设备发送。

在申请实施例中，步骤1704与上述步骤804类似，具体请参阅上述步骤804，此处不予赘述。

由图17对应的实施例可知，该实施例与图8对应实施例不同之处在于：1)在图17对应实施例中，对路径的请求和响应是由Http请求和Http响应承载，而图8对应实施例则是由扩展DNS报文承载；2)图17对应实施例中，将图8对应实施例中控制器规划路径的功能集成在Http DNS服务器上。除了这两点不同，其他过程与图8对应实施例的过程类似。

需要说明的是，在本申请实施例中，是将图8对应实施例中控制器规划路径的功能集成在Http DNS服务器上，在本申请的另一些实施方式中，还可以是将图8对应实施例中控制器规划路径的功能独立部署为一个模块或多个模块，该模块可以不部署在Http DNS服务器上，而是部署在其他设备上，在这种情况下，图17对应实施例中由Http DNS服务器执行的操作就由部署有该模块的其他设备执行。

同样地，在本申请实施例中，每个转发节点在头域中封装的先后转发顺序可以是全量的，也可以是增量的，本申请对此不做限定。具体可参阅上述步骤804相关的描述，此处不予赘述。

在介绍完本申请实施例提供的路由方法的具体实现方式之后，下面对本申请实施例提供的路由方法所带来的有益效果进行阐述：

一、为源端设备的应用提供控制用户访问路径的能力

当前互联网传输的DNS解析方案，应用仅能控制目的端(即应用仅能决定自身需访问的目的地址是哪个)，而路由的路径由互联网(internet)决定，无法控制。如图18所示，图18为本申请实施例提供的路由方法与传统互联网传输的DNS解析方案的对比示意图，由图18中的(a)子示意图可知，百度可通过GSLB(即图18中(a)子示意图中的Baidu GSLB)为用户分配最优的服务器进行访问，但用户到服务器的路径完全由互联网所决定。若应用还想对用户的路径进行控制，例如，需要通过overlay网络加速、路径避让策略(如，数据包不能离开中国大陆)或需要通过SFC(如，数据包必须先进入防火墙)路径传输等需求，那么采用本申请实施例提供的路由方法是直接、简单且高效的方法。如图18中的(b)子示意图所示，百度通过部署的控制器(即图18中(b)子示意图中的Baidu E2E)为用户规划路径，规划策略可以是差异化用户体验，例如，为会员用户分配更优的加速路径，而为常规用户分配默认互联网路径。

二、实现端到端联合优化

本申请实施例提供的路由方法为端到端的联合优化提供了实现手段，端到端联合优化可以为用户带来更好的性能提升，为证明该结论，本申请对联合优化的优势进行简单的仿真。具体的实验配置如下：

a、拓扑生成：如图19所示，在二维平面模拟地球尺度，固定源点，目的点在x轴水平移动，调整源-目的距离；随机撒点，部署PoP(如图19中的点)，PoP点数目100，200，500。

b、时延分布：根据测量数据分析，任意两点间的时延服从Gamma分布，如图20所示，时延均值随距离呈线性增长。

c、对比方法：1.默认直连，源点-目的点直接相连；2.距离最近PoP点接入，源点选择距离最近的PoP点作为入口，目的点选择最近的PoP点作为出口，出入口之间根据Overlay网络全连接拓扑，计算最短路径；3.时延最短PoP点接入，与2类似，仅在选择出入口PoP点时，选择时延最短接入点，而非距离最近；4.端到端联合优化(即本申请方法)，本申请实施例提供的路由方法在全连接网络拓扑中，直接在源点-目的点间计算最短路径。

基于上述的实验配置，图21展示了在不同PoP点数目的场景下，四种方法时延随距离的变化曲线。由图21中可看出：现有就近接入路由方法在近距离通信场景会带来负增益，由于上Overlay网络绕路，时延高于默认直连路径。而本申请实施例提供的方法根据实际网络情况确定Overlay网络路径(或直连通信)，性能优于其他现有方法和默认直连路径。

三、极大简化转发节点的设计，降低维护成本

在传统方法中，例如Overlay智能路由，PoP要依靠中心控制器进行管理，根据链路质量更新路由表和目的IP-出口PoP映射表。而在本申请实施例提供的路由方法中，PoP无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部。

四、延伸SR域至终端设备

SR技术可以消除网络中过渡节点的网络状态信息，将路径状态信息数据包头中，使网络管理和运维更加容易。然而现有SR域大多在网络内部，例如，同一自治域的路由器交换机等。本申请实施例提供的路由方法进一步将SR域延伸至用户终端，从真正的数据源头发起SR，端边云协同配合，实现极简网络。

需要说明的是，本申请实施例提供的路由方法还可以扩展应用到用于与服务器的回源请求。下面具体介绍该扩展应用。

在云网络发展的大趋势下，用户与服务器的回源请求往往需要借助边缘代理服务器做中转，而非用户直接与服务器建立连接，该具体流程可如图22所示，用户至服务器的路径包括：用户-边缘代理服务器-云骨干网-DC。各设备的功能分别为：边缘代理服务器/PoP点用于终结用户的TCP或Http请求，并对内容缓存；DC用于承载应用的逻辑和状态；云骨干网用于连接DC和边缘代理服务器。可以看到，边缘代理服务器作为DC服务器网络的出入口，一方面将内容缓存至离用户更近的位置，另一方面作为用户与DC间的管理者，保证安全性和负载均衡。

现有的用户与与服务器的回源请求的方法包括三个子系统：1)边缘代理服务器选择系统：用户根据DNS协议，获得就近边缘代理服务器/PoP点；2)DC选择系统：根据各DC负载状况及网络状况，选择DC节点服务用户请求；3)云骨干网路由系统：生成各边缘代理服务器至各DC的最优路径。

现有方法存在两个突出问题：1)端到端的路径联合优化，是当前云网络最大的诉求之一。例如，用户若就近接入Proxy1，但由于Proxy1-DC链路拥塞，骨干网自身无法解决，只能通过用户重新连接Proxy2恢复通信。2)三个子系统决策在不同实体(分为位于DNS服务器、负载均衡器、骨干控制器)，因此难以协调，无法实现一致性更新配置。例如，若用户新会话通过DNS服务器连接Proxy2，但骨干网Proxy-DC的路由还未建立，在Proxy2处会发生黑洞、丢包。

而利用本申请实施例提供的路由方法的思路，可解决用户回源流程中不同子系统独立配置的不一致性问题。具体而言，用户发起回源请求，做DNS报文解析，DNS服务器联合控制器根据用户地址、DC负载及网络情况、边缘代理服务器负载及网络状况和云骨干网状况，联合计算回源路径，并将回源路径承载在扩展DNS报文中进行下发，该回源路径包括选择的代理服务器、选择的骨干网路由、选择的DC节点等。该回源路径封装于用户传输的数据包头内，用户端设备根据路径信息，先与选择的边缘代理服务器建立连接，之后边缘代理服务器根据路径信息与相应DC建立连接(复用长连接)，并根据该回源路径中的骨干线路规划路径。

在图8所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图23，图23为本申请实施例提供的一种终端设备的示意图，该终端设备作为源端设备，具体可以包括：第一发送模块2301、获取模块2302以及第二发送模块2303，其中，第一发送模块2301，用于向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；获取模块2302，用于接收由该控制器发送的第一扩展DNS响应，该第一扩展DNS响应中包括与该第一路径请求对应的路径信息，该路径信息由该控制器根据该第一扩展DNS请求得到，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序；第二发送模块2303，用于经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，第一发送模块2301将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，规划好的路径信息携带于扩展DNS响应中，该获取模块2302将会接收到由该控制器发送的扩展DNS响应，再由该第二发送模块2303根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在一种可能的设计中，该第二发送模块2303，具体用于：首先，根据该路径信息对该目标数据包进行封装，得到封装了第一头域的第一数据包，该第一头域内包括该先后转发顺序、源端设备的源地址以及第一跳转发节点的地址(如，IP地址，或，IP地址的标识，或，其他可以对第一跳转发节点进行寻址的标识等)；之后，将该第一数据包发送至该第一跳转发节点，且在该第一跳转发节点不是最后一跳转发节点的情况下，由该第一跳转发节点对该第一数据包的第一头域解封装后对该目标数据包进行再封装，得到封装了第二头域的第二数据包，并由该第一跳转发节点将该第二数据包向第二跳转发节点发送，该第二头域包括该先后转发顺序、该第一跳转发节点的地址以及第二跳转发节点的地址，且在该第二跳转发节点是最后一跳转发节点的情况下，由该第二跳转发节点删除该第二头域，并由该第二跳转发节点将删除了该第二头域的该目标数据包向该目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，第二发送模块2303以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。

在一种可能的设计中，该第二发送模块2303，还用于：在该路径信息的取值为空的情况下，直接将待发送的该目标数据包向该目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。

在一种可能的设计中，该终端设备2300还包括生成模块2304，该生成模块2304，用于在该第一发送模2301向控制器发送第一扩展DNS请求之前，通过安装于该源端设备上的SDK生成该第一扩展DNS请求，该第一扩展DNS请求的生成由该源端设备上安装的应用发起的会话请求触发。

在本申请上述实施方式中，阐述了生成模块2304如何触发生成第一扩展DNS请求的应用场景，具备可实现性。

在一种可能的设计中，该第一发送模块2301，具体用于：向与该源端设备对应的DNS服务器发送该第一扩展DNS请求，并由该DNS服务器向该控制器发送该第一扩展DNS请求；

该获取模块2302，具体用于接收该控制器通过该DNS服务器转发的第一扩展DNS响应。

在本申请上述实施方式中，具体阐述了第一发送模块2301以及获取模块2302与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。

需要说明的是，图23对应实施例所述的终端设备2300中各模块/单元之间的信息交互、执行过程等内容，与本申请中图8对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中源端设备所执行的操作过程以及叙述，此处不再赘述。

接下来介绍本申请实施例提供的另一种终端设备，请参阅图24，图24为本申请实施例提供的终端设备的一种结构示意图，该终端设备作为源端设备，具体可以包括：第一发送模块2401、获取模块2402以及第二发送模块2403，其中，第一发送模块2401，用于向HttpDNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；获取模块2402，用于获取由Http DNS服务器发送的第一Http响应，该第一Http响应中包括与该第一路径请求对应的路径信息，该路径信息由该Http DNS服务器根据该第一Http请求得到，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序；第二发送模块2403，用于经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，第一发送模块2401将路径请求携带在Http请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中，该获取模块2402将会接收到由该Http DNS服务器发送的Http响应，再由该第二发送模块2403根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息定义在Http响应中从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在一种可能的设计中，该第二发送模块2403，具体用于：首先，根据该路径信息对该目标数据包进行封装，得到封装了第一头域的第一数据包，该第一头域内包括该先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；之后，将该第一数据包发送至该第一跳转发节点，且在该第一跳转发节点不是最后一跳转发节点的情况下，由该第一跳转发节点对该第一数据包的第一头域解封装后对该目标数据包进行再封装，得到封装了第二头域的第二数据包，并由该第一跳转发节点将该第二数据包向第二跳转发节点发送，该第二头域包括该先后转发顺序、该第一跳转发节点的地址以及第二跳转发节点的地址，且在该第二跳转发节点是最后一跳转发节点的情况下，由该第二跳转发节点删除该第二头域，并由该第二跳转发节点将删除了该第二头域的该目标数据包向该目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，第二发送模块2403以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。

在一种可能的设计中，该第二发送模块2403，还用于：在该路径信息的取值为空的情况下，直接将待发送的该目标数据包向该目的端设备发送。

在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。

在一种可能的设计中，该终端设备2400还包括生成模块2404，该生成模块2404，用于在该第一发送模2401向Http DNS服务器发送第一Http请求之前，通过安装于该源端设备上的SDK生成该第一Http请求，该第一Http请求的生成由该源端设备上安装的应用发起的会话请求触发。

在本申请上述实施方式中，阐述了生成模块2404如何触发生成第一Http请求的应用场景，具备可实现性。

需要说明的是，图24对应实施例所述的终端设备2400中各模块/单元之间的信息交互、执行过程等内容，与本申请中图17对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中源端设备所执行的操作过程以及叙述，此处不再赘述。

本申请实施例还提供一种控制器，请参阅图25，图25为本申请实施例提供的控制器的一种结构示意图，该控制器2500具体可以包括：获取模块2501、路径规划模块2502以及发送模块2503，其中，获取模块2501，用于获取由源端设备发送的第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；路径规划模块2502，用于根据该第一扩展DNS请求得到与该第一路径请求对应的路径信息；发送模块2503，用于向该源端设备发送第一扩展DNS响应，该路径信息包含在该第一扩展DNS响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得该源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，获取模块2501获取由源端设备发送的扩展DNS请求，该扩展DNS请求中包含有对路径的请求(即第一路径请求)，路径规划模块2502再基于接收到的扩展DNS请求规划路径，再由发送模块2503将规划的路径信息携带在扩展DNS响应中向源端设备发送，由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

在一种可能的设计中，该获取模块2501，具体用于：获取由该源端设备通过DNS服务器转发的第一扩展DNS请求，该DNS发服务器与该源端设备对应；

发送模块2503，具体用于向该DNS服务器发送第一扩展DNS响应，并由该DNS服务器向该源端设备发送该第一扩展DNS响应。

在本申请上述实施方式中，具体阐述了获取模块2501、发送模块2503与源端设备之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。

需要说明的是，图25对应实施例所述的控制器2500中各模块/单元之间的信息交互、执行过程等内容，与本申请中图8对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中控制器所执行的操作过程以及叙述，此处不再赘述。

本申请实施例还提供一种Http DNS服务器，请参阅图26，图26为本申请实施例提供的Http DNS服务器的一种结构示意图，该Http DNS服务器2600具体可以包括：获取模块2601、路径规划模块2602以及发送模块2603，其中，获取模块，用于获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；路径规划模块2602，用于根据该第一Http请求得到与该第一路径请求对应的路径信息；发送模块2603，用于向该源端设备发送第一Http响应，该路径信息包含在该第一Http响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得该源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。

在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，获取模块2601获取由源端设备发送的Http请求，该Http请求中包含有对路径的请求(即第一路径请求)，路径规划模块2602再基于接收到的Http请求规划路径，再由发送模块2603将规划的路径信息携带在Http响应中向源端设备发送，由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。

需要说明的是，图26对应实施例所述的Http DNS服务器2600中各模块/单元之间的信息交互、执行过程等内容，与本申请中图17对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中Http DNS服务器所执行的操作过程以及叙述，此处不再赘述。

接下来介绍本申请实施例提供的一种计算机设备，请参阅图27，图27为本申请实施例提供的计算机设备的一种结构示意图，该计算机设备2700可以是本申请所述的终端设备，也可以是本申请所述的控制器，还可以是本申请所述的Http DNS服务器。当该计算机设备2700为终端设备时，那么该计算机设备2700上可以部署有图23或图24对应实施例中所描述的模块，用于实现图23或图24对应实施例中终端设备的功能；当该计算机设备2700为控制器时，那么该计算机设备2700上可以部署有图25对应实施例中所描述的模块，用于实现图25对应实施例中控制器的功能；当该计算机设备2700为Http DNS服务器时，那么该计算机设备2700上可以部署有图26对应实施例中所描述的模块，用于实现图26对应实施例中Http DNS服务器的功能。计算机设备2700由一个或多个服务器实现，计算机设备2700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)2722(例如，一个或一个以上中央处理器)和存储器2732，一个或一个以上存储应用程序2742或数据2744的存储介质2730(例如一个或一个以上海量存储设备)。其中，存储器2732和存储介质2730可以是短暂存储或持久存储。存储在存储介质2730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备2700中的一系列指令操作。更进一步地，中央处理器2722可以设置为与存储介质2730通信，在计算机设备2700上执行存储介质2730中的一系列指令操作。

计算机设备2700还可以包括一个或一个以上电源2726，一个或一个以上有线或无线网络接口2750，一个或一个以上输入输出接口2758，和/或，一个或一个以上操作系统2741，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

本申请实施例中，当计算机设备2700为终端设备，那么该计算机设备2700作为源端设备，可用于执行图8或图17对应实施例中由源端设备执行的步骤，例如，中央处理器2722可以用于：向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。在向控制器发送了第一扩展DNS请求后，之后将获取由控制器发送的第一扩展DNS响应，该第一扩展DNS响应由控制器生成，该第一扩展DNS响应中包括与第一路径请求对应的路径信息，该路径信息由控制器根据该第一扩展DNS请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

中央处理器2722，用于执行图8或图17对应实施例中由源端设备执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请另一些实施例中，当计算机设备2700为控制器，可用于执行图8对应实施例中由控制器执行的步骤，例如，中央处理器2722可以用于：获取由源端设备发送的第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

中央处理器2722，用于执行图8对应实施例中由控制器执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请另一些实施例中，当计算机设备2700为Http DNS服务器，可用于执行图17对应实施例中由Http DNS服务器执行的步骤，例如，中央处理器2722可以用于：获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。接收到该第一Http请求后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。

中央处理器2722，用于执行图17对应实施例中由Http DNS服务器执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如前述所示实施例描述中计算机设备所执行的步骤。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid statedisk，SSD))等。

Claims (39)

1.一种路由方法，其特征在于，包括：

源端设备向控制器发送第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

所述源端设备接收由所述控制器发送的第一扩展DNS响应，所述第一扩展DNS响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述控制器根据所述第一扩展DNS请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；

所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

2.根据权利要求1所述的方法，其特征在于，所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送包括：

所述源端设备根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；

所述源端设备将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址；

在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。

3.根据权利要求2所述的方法，其特征在于，

在所述第一跳转发节点是最后一跳转发节点的情况下，由所述第一跳转发节点删除所述第一头域，并由所述第一跳转发节点将删除了所述第一头域的所述目标数据包向所述目的端设备发送。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述方法还包括：

在所述路径信息的取值为空的情况下，所述源端设备直接将待发送的所述目标数据包向所述目的端设备发送。

5.根据权利要求1-4中任一项所述的方法，其特征在于，在所述源端设备向控制器发送第一扩展DNS请求之前，所述方法还包括：

所述源端设备通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一扩展DNS请求，所述第一扩展DNS请求的生成由所述源端设备上安装的应用发起的会话请求触发。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述源端设备向控制器发送第一扩展DNS请求包括：

所述源端设备向与所述源端设备对应的DNS服务器发送所述第一扩展DNS请求，并由所述DNS服务器向所述控制器发送所述第一扩展DNS请求；

所述源端设备接收由所述控制器发送的第一扩展DNS响应包括：

所述源端设备接收所述控制器通过所述DNS服务器转发的第一扩展DNS响应。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述第一路径请求至少包括如下信息中的任意一种：

所述目的端地址、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。

8.根据权利要求7所述的方法，其特征在于，所述第一路径类型至少包括如下类型中的任意一种：

Overlay网络路径、SRv6路径、服务链(SFC)路径。

9.根据权利要求8所述的方法，其特征在于，

当所述第一路径类型为所述Overlay网络路径，所述转发节点为PoP；

当所述第一路径类型为所述SRv6路径，所述转发节点为SRv6路由器；

当所第一路径类型为所述服务链路径，所述转发节点为支持服务链的硬件设备。

10.根据权利要求1-9中任一项所述的方法，其特征在于，

所述第一路径请求在扩展DNS请求的伪资源记录的新增字段内定义；

或，

所述第一路径请求在扩展DNS请求的标准资源记录的已有字段内定义。

11.一种路由方法，其特征在于，包括：

源端设备向Http DNS服务器发送第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

所述源端设备接收由Http DNS服务器发送的第一Http响应，所述第一Http响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述Http DNS服务器根据所述第一Http请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；

所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

12.根据权利要求11所述的方法，其特征在于，所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送包括：

所述源端设备根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；

所述源端设备将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址；

在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。

13.根据权利要求12所述的方法，其特征在于，

在所述第一跳转发节点是最后一跳转发节点的情况下，由所述第一跳转发节点删除所述第一头域，并由所述第一跳转发节点将删除了所述第一头域的所述目标数据包向所述目的端设备发送。

14.根据权利要求11-13中任一项所述的方法，其特征在于，所述方法还包括：

在所述路径信息的取值为空的情况下，所述源端设备直接将待发送的所述目标数据包向所述目的端设备发送。

15.根据权利要求11-14中任一项所述的方法，其特征在于，在所述源端设备向HttpDNS服务器发送第一Http请求之前，所述方法还包括：

所述源端设备通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一Http请求，所述第一Http请求的生成由所述源端设备上安装的应用发起的会话请求触发。

16.根据权利要求11-15中任一项所述的方法，其特征在于，所述第一路径请求至少包括如下信息中的任意一种：

所述目的端地址、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。

17.根据权利要求16所述的方法，其特征在于，所述第一路径类型至少包括如下类型中的任意一种：

Overlay网络路径、SRv6路径、服务链(SFC)路径。

18.根据权利要求17所述的方法，其特征在于，

当所述第一路径类型为所述Overlay网络路径，所述转发节点为PoP；

当所述第一路径类型为所述SRv6路径，所述转发节点为SRv6路由器；

当所第一路径类型为所述服务链路径，所述转发节点为支持服务链的硬件设备。

19.一种路由方法，其特征在于，包括：

控制器接收由源端设备发送的第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

所述控制器根据所述第一扩展DNS请求得到与所述第一路径请求对应的路径信息；

所述控制器向所述源端设备发送第一扩展DNS响应，所述路径信息包含在所述第一扩展DNS响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

20.根据权利要求19所述的方法，其特征在于，所述控制器接收由源端设备发送的第一扩展DNS请求包括：

所述控制器接收由所述源端设备通过DNS服务器转发的第一扩展DNS请求，所述DNS发服务器与所述源端设备对应；

所述控制器向所述源端设备发送第一扩展DNS响应包括：

所述控制器向所述DNS服务器发送第一扩展DNS响应，并由所述DNS服务器向所述源端设备发送所述第一扩展DNS响应。

21.一种路由方法，其特征在于，包括：

Http DNS服务器接收由源端设备发送的第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

所述Http DNS服务器根据所述第一Http请求得到与所述第一路径请求对应的路径信息；

所述Http DNS服务器向所述源端设备发送第一Http响应，所述路径信息包含在所述第一Http响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

22.一种终端设备，其特征在于，所述终端设备作为源端设备，包括：

第一发送模块，用于向控制器发送第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

获取模块，用于接收由所述控制器发送的第一扩展DNS响应，所述第一扩展DNS响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述控制器根据所述第一扩展DNS请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；

第二发送模块，用于经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

23.根据权利要求22所述的设备，其特征在于，所述第二发送模块，具体用于：

根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；

将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址，且在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。

24.根据权利要求22-23中任一项所述的设备，其特征在于，所述第二发送模块，还用于：

在所述路径信息的取值为空的情况下，直接将待发送的所述目标数据包向所述目的端设备发送。

25.根据权利要求22-24中任一项所述的设备，其特征在于，所述设备还包括：

生成模块，用于在所述第一发送模块向控制器发送第一扩展DNS请求之前，通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一扩展DNS请求，所述第一扩展DNS请求的生成由所述源端设备上安装的应用发起的会话请求触发。

26.根据权利要求22-25中任一项所述的设备，其特征在于，所述第一发送模块，具体用于：

向与所述源端设备对应的DNS服务器发送所述第一扩展DNS请求，并由所述DNS服务器向所述控制器发送所述第一扩展DNS请求；

所述获取模块，具体用于接收所述控制器通过所述DNS服务器转发的第一扩展DNS响应。

27.一种终端设备，其特征在于，所述终端设备作为源端设备，包括：

第一发送模块，用于向Http DNS服务器发送第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

获取模块，用于接收由Http DNS服务器发送的第一Http响应，所述第一Http响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述Http DNS服务器根据所述第一Http请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；

第二发送模块，用于经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

28.根据权利要求27所述的设备，其特征在于，所述第二发送模块，具体用于：

根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；

将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址，且在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。

29.根据权利要求27-28中任一项所述的设备，其特征在于，所述第二发送模块，还用于：

在所述路径信息的取值为空的情况下，直接将待发送的所述目标数据包向所述目的端设备发送。

30.根据权利要求27-29中任一项所述的设备，其特征在于，所述设备还包括：

生成模块，用于在所述第一发送模块向Http DNS服务器发送第一Http请求之前，通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一Http请求，所述第一Http请求的生成由所述源端设备上安装的应用发起的会话请求触发。

31.一种控制器，其特征在于，包括：

获取模块，用于接收由源端设备发送的第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

路径规划模块，用于根据所述第一扩展DNS请求得到与所述第一路径请求对应的路径信息；

发送模块，用于向所述源端设备发送第一扩展DNS响应，所述路径信息包含在所述第一扩展DNS响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

32.根据权利要求31所述的控制器，其特征在于，所述获取模块，具体用于：

接收由所述源端设备通过DNS服务器转发的第一扩展DNS请求，所述DNS发服务器与所述源端设备对应；

所述发送模块，具体用于向所述DNS服务器发送第一扩展DNS响应，并由所述DNS服务器向所述源端设备发送所述第一扩展DNS响应。

33.一种Http DNS服务器，其特征在于，包括：

获取模块，用于接收由源端设备发送的第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；

路径规划模块，用于根据所述第一Http请求得到与所述第一路径请求对应的路径信息；

发送模块，用于向所述源端设备发送第一Http响应，所述路径信息包含在所述第一Http响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。

34.一种终端设备，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，所述终端设备作为源端设备，其特征在于，

所述存储器，用于存储程序；

所述一个或多个处理器，用于执行所述存储器中的程序，使得所述终端设备执行如权利要求1-18中任一项所述的方法。

35.一种控制器，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，其特征在于，

所述存储器，用于存储程序；

所述一个或多个处理器，用于执行所述存储器中的程序，使得所述控制器执行如权利要求19-20中任一项所述的方法。

36.一种Http DNS服务器，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，其特征在于，

所述存储器，用于存储程序；

所述一个或多个处理器，用于执行所述存储器中的程序，使得所述Http DNS服务器执行如权利要求21所述的方法。

37.一种计算机可读存储介质，包括计算机可读指令，其特征在于，当所述计算机可读指令在计算机上运行时，使得计算机执行如权利要求1-21中任一项所述的方法。

38.一种计算机程序产品，包括计算机可读指令，其特征在于，当所述计算机可读指令在计算机上运行时，使得计算机执行如权利要求1-21中任一项所述的方法。

39.一种芯片，其特征在于，所述芯片包括存储器和一个或多个处理器，所述芯片用于读取存储器中存储的计算机程序，使得所述一个或多个处理器执行如权利要求1-21任一项所述的方法。

Images