CN113973109A - 文件下载方法、设备及系统 - Google Patents

Abstract

本申请提供了一种文件下载方法、设备及系统，属于网络技术领域。本申请通过在客户端设备、中继设备和服务端设备这样的三层系统架构中，在报文中携带指示信息从而指示中继设备上具有客户端所需的文件，客户端设备通过与中继设备进行交互，能够从中继设备下载文件，从而支持客户端设备就近下载文件，因此节省了文件传输占用的带宽。

Description

文件下载方法、设备及系统

本申请要求于2020年07月22日提交的申请号为202010711732.7、发明名称为“一种文件传输方法、装置及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及网络技术领域，特别涉及一种文件下载方法、设备及系统。

背景技术

在一些规模较大、地域较分散的网络中，当需要将文件下载至客户端设备时，会由服务端设备基于文件传输协议(file transfer protocol，FTP)将文件传输至客户端设备。然而，由于服务端设备与客户端设备之间的距离较远，会导致文件传输占用的带宽过大。

发明内容

本申请实施例提供了一种文件下载方法、设备及系统，能够节省文件传输占用的带宽。所述技术方案如下：

第一方面，提供了一种文件下载方法，应用于包括客户端设备、中继设备和服务端设备的通信系统，在该方法中，所述客户端设备发送请求报文；所述客户端设备接收所述中继设备发送的应答报文，所述应答报文为所述请求报文的应答，所述应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括目标文件；所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件。

以上提供的方法中，通过在客户端设备、中继设备和服务端设备这样的三层系统架构中，在报文中携带指示信息来指示中继设备上具有客户端所需的文件，客户端设备通过与中继设备进行交互，能够从中继设备下载文件，从而支持客户端设备就近下载文件，因此节省了文件传输占用的带宽。

在一种可能的实现方式中，所述第一指示信息包括：所述目标文件的第一信息，所述第一信息包括以下一项或多项：文件名、版本号、文件类型和文件保存地址。

通过在客户端设备、中继设备、服务端设备之间交互的报文中携带例如文件保存地址这样的具体文件信息，使得文件信息在客户端设备、中继设备、服务端设备之间随着报文的转发而互相传递，那么客户端设备从接收的报文中即可获得具体文件信息从而实现文件下载，因此减少配置工作量，有助于复用网络已有的转发机制，降低方案实施的复杂度，提高方案的实用性。

在一种可能的实现方式中，所述请求报文包括第二指示信息，所述第二指示信息用于指示所述客户端设备请求所述目标文件。

客户端通过在请求报文中携带指示信息来指明自身具有下载文件的需求，有助于简化中继设备或者服务端设备的处理逻辑。

在一种可能的实现方式中，所述第二指示信息包括以下一项或多项：文件名、版本号和文件类型。

客户端设备通过在请求报文中携带如文件名这样的具体文件信息，从而利用请求报文指定具体需要下载哪一个文件，便于中继设备或者服务端设备根据文件信息明确查询本地是否存在客户端设备所需的文件，有助于中继设备或者服务端设备后续提供的文件更精准地满足客户端设备的需求。

在一种可能的实现方式中，所述请求报文采用下述协议报文之一：动态主机配置协议(Dynamic Hosting Configuration Protocol，DHCP)协议报文、远程用户拨号认证服务(remote authentication dial in user service，RADIUS)报文或基于以太网的点对点协议(Point-to-Point Protocol Over Ethernet，PPPOE)报文。

以上方式支持文件下载流程与DHCP协议、RADIUS协议或者PPPOE协议平滑地融合起来，便于复用DHCP协议、RADIUS协议或者PPPOE协议的系统架构以及通信流程实施方案，从而降低方案实施的复杂度和配置的复杂度，提高方案的可用性。

在一种可能的实现方式中，在所述请求报文为DHCP报文的情况下，所述中继设备为DHCP中继relay设备，所述客户端设备为DHCP客户端设备。

以上方式支持复用DHCP协议中已有的三层系统架构实现方案，提高方案的可用性。

在一种可能的实现方式中，所述请求报文为DHCP发现(discover)报文，所述应答报文为DHCP提供(offer)报文；或者，所述请求报文为DHCP请求(request)报文，所述应答报文为DHCP确认(Acknowledge，ACK)报文。

以上为如何复用DHCP协议的通信机制来下载文件提供了多种实现方式，能够进一步提高方案的可用性。

在一种可能的实现方式中，在所述请求报文为RADIUS报文的情况下，所述中继设备为RADIUS relay设备，所述客户端设备为RADIUS客户端设备。

以上方式支持复用RADIUS协议中已有的三层系统架构实现方案，提高方案的可用性。

在一种可能的实现方式中，所述请求报文为RADIUS接入请求(access-request)报文，所述应答报文为RADIUS接入成功回应(access-accept)报文；或者，所述请求报文为RADIUS计费请求(accounting-request)报文，所述应答报文为RADIUS计费回应(accounting-response)报文。

以上为如何复用RADIUS协议的通信机制来下载文件提供了多种实现方式，能够进一步提高方案的可用性。

在一种可能的实现方式中，在所述请求报文为PPPOE报文的情况下，所述中继设备为PPPOE relay设备，所述客户端设备为PPPOE客户端设备。

通过以上方式，支持复用PPPOE协议中已有的三层系统架构实现方案，提高方案的可用性。

在一种可能的实现方式中，所述请求报文为PPPOE主动发现初始(PPPOE ActiveDiscovery Initiation，PADI)报文，所述应答报文为PPPOE主动发现提供(PPPoE ActiveDiscovery Offer，PADO)报文；或者，所述请求报文为PPPOE主动发现请求(PPPoE ActiveDiscovery Request，PADR)报文，所述应答报文为PPPOE主动发现会话确认(PPPoE ActiveDiscovery Session-confirmation，PADS)报文。

以上为如何复用PPPOE协议的通信机制来下载文件提供了多种实现方式，能够进一步提高方案的可用性。

在一种可能的实现方式中，所述应答报文包括第一选项部分，所述第一选项部分包括类型字段以及值字段，所述值字段包括所述第一指示信息，所述类型字段用于标识所述第一选项部分包括所述第一指示信息。

通过在应答报文中扩展一种新类型的选项来携带指示信息，便于设备从应答报文中直接获得指示信息，减少网络的配置。

在一种可能的实现方式中，所述请求报文包括第二选项部分，所述第二选项部分包括类型字段以及值字段，所述值字段包括所述第二指示信息，所述类型字段用于标识所述第二选项部分包括所述第二指示信息。

通过在请求报文中扩展一种新类型的选项来携带指示信息，便于设备从请求报文中直接获得指示信息，减少网络的配置。

在一种可能的实现方式中，在所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件之前，所述方法还包括：所述客户端设备确定所述目标文件的类型与所述客户端设备的类型满足匹配条件。

通过这种方式，保证客户端下载的目标文件与客户端的类型匹配，有助于下载的文件更精确的匹配客户端的需求。

在一种可能的实现方式中，所述目标文件为系统软件或者补丁文件，所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件之后，所述方法还包括：所述客户端设备根据所述系统软件进行升级；或者，所述客户端设备根据所述补丁文件加载补丁。

通过这种方式，使得方案匹配设备升级以及加载补丁的需求，满足更多的应用场景。

在一种可能的实现方式中，所述目标文件为所述中继设备从所述服务端设备处获得的。

第二方面，提供了一种文件传输方法，应用于包括客户端设备、中继设备和服务端设备的通信系统，在该方法中，所述中继设备接收所述客户端设备发送的第一请求报文；所述中继设备向所述客户端设备发送第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括所述目标文件；响应于所述第一应答报文，所述中继设备向所述客户端设备传输所述目标文件。

以上提供的方法中，通过在客户端设备、中继设备和服务端设备这样的三层系统架构中，利用客户端设备与中继设备之间传递的报文来指示中继设备上具有客户端所需的文件，客户端设备通过与中继设备进行交互，能够从中继设备下载文件，从而实现了文件的就近下载文件，因此节省了文件传输占用的带宽。

在一种可能的实现方式中，所述第一请求报文包括第二指示信息，所述第二指示信息用于指示所述客户端设备请求所述目标文件。

由于客户端的请求报文中携带指示信息来指明自身具有下载文件的需求，中继设备从接收的报文中即可获得具体文件信息，因此减少配置工作量。

在一种可能的实现方式中，所述中继设备向所述客户端设备传输所述目标文件之前，所述方法还包括：所述中继设备向所述服务端设备发送第二请求报文；所述中继设备接收所述服务端设备发送的第二应答报文，所述第二应答报文为所述第二请求报文的应答，所述第二应答报文包括第三指示信息，所述第三指示信息用于指示所述服务端设备包括所述目标文件；所述中继设备根据所述第三指示信息下载所述目标文件。

以上提供的方法中，利用中继设备与服务端设备之间传递的报文来指示服务端设备上具有客户端所需的文件，便于中继设备利用报文中携带的指示信息从服务端设备下载文件，减少配置工作量，提高方案的实用性。

在一种可能的实现方式中，所述第二请求报文包括第四指示信息，所述第四指示信息用于指示所述中继设备请求所述目标文件。中继设备通过在请求报文中携带指示信息来指明自身具有下载文件的需求，有助于简化服务端设备的处理逻辑。

在一种可能的实现方式中，所述中继设备向所述客户端设备发送第一应答报文之前，所述方法还包括：所述中继设备根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

通过这种方式，保证中继设备向客户端传输的目标文件与客户端的类型匹配，有助于传输的文件更精确的匹配客户端的需求。

第三方面，提供了一种文件传输方法，应用于包括客户端设备、中继设备和服务端设备的通信系统，在该方法中，所述服务端设备接收所述中继设备发送的第一请求报文；所述服务端设备生成第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述服务端设备包括目标文件；所述服务端设备向所述中继设备发送所述第一应答报文。

以上提供的方法中，通过在客户端设备、中继设备和服务端设备这样的三层系统架构中，利用中继设备与服务端设备之间传递的报文来指示服务端设备上具有客户端所需的文件，便于中继设备利用报文中携带的指示信息从服务端设备下载文件，减少配置工作量，提高方案的实用性。

在一种可能的实现方式中，所述第一请求报文包括第二指示信息，所述第二指示信息用于指示所述中继设备请求所述目标文件。

中继设备通过在请求报文中携带指示信息来指明自身具有下载文件的需求，有助于简化服务端设备的处理逻辑。

在一种可能的实现方式中，所述服务端设备生成第一应答报文之前，所述方法还包括：所述服务端设备根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

通过这种方式，保证服务端设备向中继设备传输的目标文件与客户端的类型匹配，有助于传输的文件更精确的匹配客户端的需求。

第四方面，提供了一种客户端设备，该客户端设备具有实现上述第一方面或第一方面任一种可选方式中的功能。该客户端设备包括至少一个单元，至少一个单元用于实现上述第一方面或第一方面任一种可选方式所提供的文件下载方法。

在一些实施例中，客户端设备中的单元通过软件实现，客户端设备中的单元是程序模块。在另一些实施例中，客户端设备中的单元通过硬件或固件实现。第四方面提供的客户端设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。

第五方面，提供了一种中继设备，该中继设备具有实现上述第二方面或第二方面任一种可选方式中的功能。该中继设备包括至少一个单元，至少一个单元用于实现上述第二方面或第二方面任一种可选方式所提供的文件传输方法。

在一些实施例中，中继设备中的单元通过软件实现，中继设备中的单元是程序模块。在另一些实施例中，中继设备中的单元通过硬件或固件实现。第五方面提供的中继设备的具体细节可参见上述第二方面或第二方面任一种可选方式，此处不再赘述。

第六方面，提供了一种服务端设备，该服务端设备具有实现上述第二方面或第二方面任一种可选方式中的功能。该服务端设备包括至少一个单元，至少一个单元用于实现上述第二方面或第二方面任一种可选方式所提供的文件传输方法。

在一些实施例中，服务端设备中的单元通过软件实现，服务端设备中的单元是程序模块。在另一些实施例中，服务端设备中的单元通过硬件或固件实现。第六方面提供的服务端设备的具体细节可参见上述第二方面或第二方面任一种可选方式，此处不再赘述。

第七方面，提供了一种客户端设备，该客户端设备包括处理器和通信接口，该处理器用于执行指令，使得该客户端设备执行上述第一方面或第一方面任一种可选方式所提供的方法，所述通信接口用于接收或发送报文。第七方面提供的客户端设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。

第八方面，提供了一种中继设备，该中继设备包括处理器和通信接口，该处理器用于执行指令，使得该中继设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输方法，所述通信接口用于接收或发送报文。第八方面提供的中继设备的具体细节可参见上述第二方面或第二方面任一种可选方式，此处不再赘述。

第九方面，提供了一种服务端设备，该服务端设备包括处理器和通信接口，该处理器用于执行指令，使得该服务端设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输方法，所述通信接口用于接收或发送报文。第九方面提供的服务端设备的具体细节可参见上述第二方面或第二方面任一种可选方式，此处不再赘述。

第十方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令由处理器读取以使客户端设备执行上述第一方面或第一方面任一种可选方式所提供的文件下载方法。

第十一方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令由处理器读取以使中继设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输方法。

第十二方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令由处理器读取以使服务端设备执行上述第三方面或第三方面任一种可选方式所提供的文件传输方法。

第十三方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。客户端设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该客户端设备执行上述第一方面或第一方面任一种可选方式所提供的文件下载方法。

第十四方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。中继设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该中继设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输方法。

第十五方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。服务端设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该服务端设备执行上述第三方面或第三方面任一种可选方式所提供的文件传输方法。

第十六方面，提供了一种芯片，当该芯片在客户端设备上运行时，使得客户端设备执行上述第一方面或第一方面任一种可选方式所提供的文件下载方法。

第十七方面，提供了一种芯片，当该芯片在中继设备上运行时，使得中继设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输方法。

第十八方面，提供了一种芯片，当该芯片在服务端设备上运行时，使得服务端设备执行上述第三方面或第三方面任一种可选方式所提供的文件传输方法。

第十九方面，提供了一种通信系统，该通信系统包括客户端设备、中继设备以及服务端设备，该客户端设备用于执行上述第一方面或第一方面任一种可选方式所述的方法，该中继设备用于执行上述第二方面或第二方面任一种可选方式所述的方法，该服务端设备用于执行上述第三方面或第三方面任一种可选方式所述的方法。

第二十方面，提供一种客户端设备，所述客户端设备包括：主控板和接口板，进一步，还可以包括交换网板。所述客户端设备用于执行第一方面或第一方面的任意可能的实现方式中的方法。具体地，所述客户端设备包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的单元。

第二十一方面，提供一种中继设备，所述中继设备包括：主控板和接口板，进一步，还可以包括交换网板。所述中继设备用于执行第二方面或第二方面的任意可能的实现方式中的方法。具体地，所述中继设备包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的单元。

第二十二方面，提供一种服务端设备，所述服务端设备包括：主控板和接口板，进一步，还可以包括交换网板。所述服务端设备用于执行第三方面或第三方面的任意可能的实现方式中的方法。具体地，所述服务端设备包括用于执行第三方面或第三方面的任意可能的实现方式中的方法的单元。

附图说明

图1是本申请实施例提供的一种系统架构100的示意图；

图2是本申请实施例提供的一种DHCP交互的流程示意图；

图3是本申请实施例提供的一种DHCP报文的报文格式的示意图；

图4是本申请实施例提供的一种option X的格式示意图；

图5是本申请实施例提供的一种文件传输方法的流程图；

图6是本申请实施例提供的一种文件传输方法的流程图；

图7是本申请实施例提供的一种文件传输方法的流程图；

图8是本申请实施例提供的一种文件传输方法的流程图；

图9是本申请实施例提供的一种RADIUS报文的报文格式的示意图；

图10是本申请实施例提供的一种客户端设备的结构示意图；

图11是本申请实施例提供的一种中继设备的结构示意图；

图12是本申请实施例提供的一种服务端设备的结构示意图；

图13是本申请实施例提供的一种设备900的结构示意图；

图14是本申请实施例提供的一种设备1500的结构示意图；

图15是本申请实施例提供的一种通信系统的结构示意图。

具体实施方式

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

下面先对本申请实施例涉及的一些术语相关概念进行介绍。

(1)文件传输协议(file transfer protocol，FTP)

FTP是用于在网络上进行文件传输的一套标准协议。FTP工作在应用层。FTP基于客户端/服务端(client/server，C/S)的模式通信。FTP服务端设备用来存储文件。FTP客户端设备通过FTP协议访问位于FTP服务端设备上的文件。

(2)动态主机配置协议(Dynamic Hosting Configuration Protocol，DHCP)

DHCP是一种用于集中对用户互联网协议(internet protocol，IP)地址进行动态管理和配置的协议。DHCP允许计算机动态地获取IP地址。此外，DHCP还能够分配IP地址之外的其他配置参数，例如客户端设备的启动配置文件。DHCP协议由请求评论(request forcomments，RFC，一系列以编号排定的文件)中的RFC 2131定义。DHCP采用客户端/服务端通信模式，由客户端(DHCP Client)设备向服务端设备(DHCP Server)提出配置申请，服务端设备返回为客户端设备分配的配置信息。DHCP的优势主要包含两点。第一，DHCP易配置部署，降低客户端设备的配置和维护成本。第二，DHCP便于集中管理。DHCP服务端设备能够管理多个网段的配置信息，当某个网段的配置信息发生变化时，管理员只需要更新DHCP服务端设备上的相关配置即可。DHCP组网主要包括三种角色，DHCP服务端设备、DHCP中继设备、DHCP客户端设备。DHCP包括两类场景，一类场景是互联网协议第四版(internet protocolversion 4，IPv4)动态主机配置协议(dynamic host configuration protocol for IPv4，DHCPv4)，另一类场景是互联网协议第六版(internet protocol version 6，IPv6)动态主机配置协议(dynamic host configuration protocol for IPv6，DHCPv6)。

(3)DHCP服务端设备

DHCP服务端设备负责从地址池中选择IP地址分配至DHCP客户端设备。可选地，DHCP服务端设备还为DHCP客户端设备提供IP地址之外的其他网络参数。DHCP服务端设备能够接收处理来自本网段或跨网段由DHCP中继设备转发的DHCP请求报文。

(4)DHCP客户端设备

DHCP客户端设备发送DHCP请求报文。DHCP客户端设备是通过DHCP协议请求获取IP地址或者其他网络参数的设备。例如，DHCP客户端设备为IP电话、个人计算机(PersonalComputer，PC)、手机、无盘工作站等。

(5)DHCP中继(DHCP relay)设备

DHCP中继设备负责转发DHCP服务端设备和DHCP客户端设备之间的DHCP报文。具体地，当DHCP客户端设备与DHCP服务端设备处于同一网段时，DHCP客户端设备广播请求报文(目的IP地址为255.255.255.255)后，DHCP服务端设备由于与DHCP客户端设备位于同一网段，DHCP服务端设备能够收到请求报文。当DHCP客户端设备与DHCP服务端设备处于不同网段时，DHCP服务端设备无法直接收到来自DHCP客户端设备的请求报文。有鉴于此，通过部署DHCP中继设备在DHCP服务端设备和DHCP客户端设备之间转发DHCP报文，从而保证DHCP服务端设备和DHCP客户端设备能够正常交互。

(6)DHCPv4

DHCPv4针对IPv4编址方案设计。DHCPv4用于为主机分配IPv4地址或其他网络配置参数。

(7)DHCPv6

DHCPv6针对IPv6编址方案设计。DHCPv6用于为主机分配IPv6地址或IPv6前缀或其他网络配置参数。

(8)IP无线承载网络(IP radio access network，IPRAN)

IPRAN即IP化的无线接入网(wireless access network，RAN)。IPRAN是利用IP传输技术取代传统多业务传送平台(multi-service transport platform，MSTP)技术的RAN解决方案。IPRAN能够为各种类型的网络设备(如基站)接入基站控制器提供可靠的连接。

(9)接入传输网络(access transport network，ATN)设备

ATN设备定位于移动承载网络边缘。ATN设备通常是面向多业务接入的盒式设备。ATN设备通常部署在城域网络的接入层，或者部署在大业务量接入站点以实现多业务接入。

下面介绍本申请实施例涉及的应用场景以及该场景在具体应用中的情况进行介绍。

本申请实施例提供的方法能够应用在客户端设备下载文件的场景，例如应用在网络设备通过下载系统软件来进行升级的场景。下面以网络设备升级的场景为例进行说明。

IPRAN或者其他通信网络存在大量的运营商网络设备，如网络设备。在网络设备的升级过程中，操作人员需要在实验室使用网管工具，基于FTP将系统软件(如后缀名为.cc的文件)传输到网络设备。为了保证网络的平稳运行，通常将网络设备升级的时间限定在凌晨等业务流量较少的时候，由于可供升级的时间段有限，而通过FTP传输系统软件的时间又是固定的，在网络设备数量较多的情况下，升级比较慢。

在相关技术中，会在网管设备(如一台PC机)上安装网管升级工具。然后，网管设备作为FTP服务端设备，网管设备通过FTP或者安全文件传送协议(secure file transferprotocol，SFTP)远程连接每台网络设备，网管设备向每台网络设备传输系统软件后，每台网络设备使用获得系统软件进行升级并在升级完成后重启。但是，网管设备集中升级的方式会造成带宽占用过大的问题。并且，由于待升级的网络设备离网管设备较远，则该网络中的网络质量问题导致网络设备升级失败的概率较高。

而本申请的一些实施例中，基于客户端设备、中继设备和服务端设备的网络架构，由网络设备作为客户端设备，从中继设备下载系统软件，从而使用该系统软件进行升级。由于网络设备与中继设备之间的距离小于网络设备与服务端设备之间的距离，即网络设备与中继设备更近，因此实现了系统软件的就近下载，进而实现了网络设备的就近升级。通过就近下载和就近升级，能够减少升级带来的带宽占用，降低网络不稳定导致的升级失败的概率。

值得说明的一点是，本实施例并不限定客户端设备利用本技术方案下载的文件的具体类型，也不限定客户端设备如何应用下载的文件。以上介绍的下载系统软件以及应用文件进行升级仅是对应用场景的示例性介绍。在另一个示例中，客户端设备利用本技术方案下载其他类型的文件，应用其他类型的文件实现其他功能。例如，客户端设备下载的文件是补丁文件。补丁文件例如是后缀名为补丁(patch，PAT)的文件。客户端设备使用补丁文件来加载补丁。又如，客户端设备下载的文件是视频，客户端设备播放下载到本地的视频。

下面对本申请实施例的系统架构举例说明。

参见附图1，附图1是对本申请实施例提供的系统架构100的举例说明。系统架构100包含三层结构，一层结构包含一个或多个客户端设备，另一层结构包含一个或多个中继设备，另一层结构包含一个或多个服务端设备。例如，如附图1所示，系统100包含服务端设备110、中继设备121、中继设备122、客户端设备131、客户端设备132、客户端设备133和客户端设备134。

系统100中的客户端设备例如为网络设备或者计算设备。系统100中的中继设备例如为网络设备或者计算设备。在一个示例中，系统100中的客户端设备包括交换机、路由器、ATN设备、终端或其他设备。系统100中的中继设备包括交换机、路由器、ATN设备或其他设备。可选地，系统100中一个或多个设备是物理设备；或者，可选地，系统100中的一个或多个设备是虚拟设备。

在一个示例中，系统100为IPRAN系统。系统100中的客户端设备为网络设备。可选地，系统100中的中继设备为IPRAN中的汇聚设备。可选地，系统100中的服务端设备为IPRAN中的核心设备或网络管理设备。

服务端设备110通过网络与中继设备121和中继设备122相连。中继设备121通过网络与客户端设备131和客户端设备132相连。中继设备122通过网络与客户端设备133和客户端设备134相连。

系统100是对树形组网架构的举例说明。客户端设备131和客户端设备132通过中继设备121与服务端设备110通信。客户端设备133和客户端设备134通过中继设备122与服务端设备110通信。系统100的组网架构还可以是其他形式的，如客户端设备132还可以与中继设备122相连，在此不再对其他组网形式一一举例。

系统100包括多种实现方式，以下通过方式一至方式三举例说明。

方式一、系统100基于DHCP通信。

具体地，服务端设备110为DHCP服务端设备。中继设备121以及中继设备122为DHCP中继设备。客户端设备131、客户端设备132、客户端设备133和客户端设备134为DHCP客户端设备。系统100包含的客户端设备、中继设备与服务端设备之间基于DHCP通信。

在一个示例中，方式一包括以下方式(1.1)和方式(1.2)。

方式(1.1)系统100基于DHCPv4通信。

具体地，服务端设备110为DHCPv4服务端设备。中继设备121以及中继设备122为DHCPv4中继设备。客户端设备131、客户端设备132、客户端设备133和客户端设备134为DHCPv4客户端设备。系统100包含的客户端设备、中继设备与服务端设备之间基于DHCPv4通信。

方式(1.2)系统100基于DHCPv6通信。

具体地，服务端设备110为DHCPv6服务端设备。中继设备121以及中继设备122为DHCPv6中继设备。客户端设备131、客户端设备132、客户端设备133和客户端设备134为DHCPv6客户端设备。系统100包含的客户端设备、中继设备与服务端设备之间基于DHCPv6通信。

方式二、系统100基于以太网的点对点协议(Point-to-Point Protocol OverEthernet，PPPOE)通信。

具体地，服务端设备110为PPPOE服务端设备。中继设备121以及中继设备122为PPPOE中继设备。客户端设备131、客户端设备132、客户端设备133和客户端设备134为PPPOE客户端设备。系统100包含的客户端设备、中继设备与服务端设备之间基于PPPOE通信。

方式三、系统100基于远程用户拨号认证服务(remote authentication dial inuser service，RADIUS)通信。

具体地，服务端设备110为RADIUS服务端设备。中继设备121以及中继设备122为RADIUS中继设备。客户端设备131、客户端设备132、客户端设备133和客户端设备134为RADIUS客户端设备。系统100包含的客户端设备、中继设备与服务端设备之间基于RADIUS通信。

在系统100中，客户端设备如何确定与其对应的中继设备的方式包括多种可能的实现方式。以下通过方式A和方式B，对客户端设备确定中继设备的方式进行举例说明。

方式A、客户端设备通过就近的方式确定与其对应的中继设备。

客户端设备在上线时，确定与其进行直接的报文交互或直接相连的设备为中继设备。例如：客户端设备131根据中继设备121与其直接相连，或在其上线时与其交互报文的设备为中继设备121，则，客户端设备131确定与其对应的中继设备为中继设备121。客户端设备131确定其对应的中继设备为中继设备121，以便后续从中继设备121获得所需的文件。通过这种方式，有助于客户端从就近的中继设备获得文件，从而提高文件下载效率。

方式B、通过指定的方式确定与客户端设备对应的中继设备。

例如，网络运维人员可以通过网络管理系统或者其他配置管理工具，指定中继设备包括：中继设备121和中继设备122。进一步的，网络运维人员还可以为中继设备121指定对应的客户端设备，如：客户端设备131和客户端设备132，为中继设备121指定对应的客户端设备，如：客户端设备133和客户端设备134。通过上述指定的方式，客户端设备即可通过其对应的中继设备获得对应的文件，加快文件获得的过程。

本实施例对系统100中一个服务端设备连接多少个中继设备不做限定，附图1示出的一个服务端设备连接两个中继设备是示意性的。本领域技术人员可以知晓，服务端设备110连接的中继设备可以更多。比如，服务端设备110连接的中继设备为几十个或几百个，或者更多数量。此时，虽然附图1未示出，系统100还包括其他中继设备。

本实施例对系统100中一个中继设备连接多少个客户端设备不做限定，附图1示出的一个中继设备连接两个客户端设备是示意性的。本领域技术人员可以知晓，中继设备121或者中继设备122连接的客户端设备可以更多。比如，中继设备110或者中继设备122连接的客户端设备为几十个或几百个，或者更多数量。此时，虽然附图1未示出，系统100还包括其他客户端设备。

尤其是，在一个中继设备连接大量客户端设备的情况下，大量客户端能够从同一个中继设备获得文件，使得文件从中继设备批量下载至每个客户端设备上，有助于更快、更高效地对批量客户端设备传输文件。

以上通过系统100对本申请实施例的系统架构进行了介绍，以下结合附图2介绍系统基于DHCP进行交互的基本流程。在一个示例中，在系统100基于DHCP进行交互的流程中，在DHCP报文中扩展一种新类型的选项来携带文件相关的信息。

附图2所示的流程可通过系统100实现。例如，下面介绍的步骤一至步骤四中服务端设备为服务端设备110。下面介绍的步骤一至步骤四中的DHCP中继设备为中继设备121或者中继设备122。下面介绍的步骤一至步骤四中的客户端设备为客户端设备131、客户端设备132、客户端设备133或者客户端设备134中的一个客户端设备。

附图2所示的流程简称为四步交互，具体包含以下步骤一至步骤四。

步骤一、客户端设备广播DHCP发现(DHCP discover)报文。DHCP中继设备接收到DHCP discover报文后，DHCP中继设备将DHCP discover报文以单播的方式发送到服务端设备。

步骤二、服务端设备以单播的方式向DHCP中继设备发送DHCP提供(DHCP offer)报文。DHCP中继设备接收到DHCP offer报文后，将DHCP offer报文以广播的方式转发给客户端设备。

步骤三、客户端设备以广播的方式发送DHCP请求(DHCP request)报文。DHCP中继设备接收到DHCP request报文后，DHCP中继设备将DHCP request报文以单播的方式发送到服务端设备。

步骤四、服务端设备接收到DHCP request报文后，以单播的方式向DHCP中继设备发送DHCP确认(Acknowledge，ACK)报文或DHCP拒绝响应(DHCP negative acknowledgment，DHCP NAK)报文。DHCP中继设备接收到DHCP ACK报文或DHCP NAK报文后，DHCP中继设备将DHCP ACK报文或DHCP NAK报文以广播的方式发送到客户端设备。

下面对DHCP报文的报文格式进行介绍。

请参考附图3，附图3是对DHCP报文的报文格式的举例说明。附图3中各字段的描述如下。

操作代码(operation code，OP)字段的值为1或2。当OP字段的值为1时，表示DHCP报文是客户端设备向服务端设备发送的请求报文。当OP字段的值为2时，表示DHCP报文是服务端设备向客户端设备发送的应答报文。OP字段的长度是1字节。

硬件地址类型(hardware type，htype)字段表示客户端设备的网络硬件地址类型。当htype字段的取值为1时，表示客户端设备的网络硬件是10兆比特每秒(Mb/s)的以太网。

硬件长度(hardware length，hlen)字段表示客户端设备的网络硬件地址长度。当hlen字段的取值为6时，表示客户端设备的网络硬件地址长度是6字节，即以太网类型的6字节的媒体访问控制(media access control，MAC)地址。hlen字段的长度是1字节。

跳数(hops)字段表示当前的DHCP报文经过的DHCP中继设备的数目。每经过一个DHCP中继设备时，hops字段加1。hops字段由客户端设备设置为0，也能被一个代理服务端设备设置。hops字段的长度是1字节。

事务ID(transaction ID，xid)字段表示客户端设备选择的一个随机数。xid被服务端设备和客户端设备用来在服务端设备和客户端设备之间交流请求报文和应答报文。客户端设备用xid对请求报文和应答报文进行匹配。xid由客户端设备设置并由服务端设备返回。xid为32位整数。xid字段的长度为4字节。

秒数(second，secs)字段由客户端设备填充。secs字段表示从客户端设备开始获得IP地址或IP地址续借后所使用了的秒数。secs字段的长度为2字节。

标志(flags)字段的长度为2字节(即16个比特)。flags字段的16个比特中，最高位(即最左边的一个比特)目前被DHCP使用，最高位之外的剩余的15个比特均为保留字段。其中，flags字段的最高位称为单播响应标志位或者广播响应标志位(broadcast flag)。当flags字段的最高位的值为0时，表示客户端设备请求服务端设备以单播方式发送应答报文；当flags字段的最高位的值为1时，表示客户端设备请求服务端设备以广播方式发送应答报文。

客户端IP地址(client IP address，ciaddr)字段表示客户端设备的IP地址。当客户端设备处于绑定(bound)状态、续租(renew)状态或者重新绑定(rebinding)状态，并且客户端设备能响应地址解析协议(地址解析协议，ARP)请求时，ciaddr字段能被填充。ciaddr字段的长度为4字节。

你的客户端的IP地址(Your(client)IP address，yiaddr)字段表示服务端设备分配给客户端设备的IP地址。当服务端设备进行DHCP响应时，服务端设备将分配给客户端设备的IP地址填入此字段。yiaddr字段的长度为4字节。

下一个服务端设备IP地址(IP address of next server to talk to，siaddr)字段表示DHCP协议流程的下一个阶段要使用的服务端设备的IP地址。siaddr字段的长度为4字节。

中继代理IP地址(DHCP relay agent IP address giaddr)字段表示DHCP中继设备的IP地址。giaddr字段的长度为4字节。

客户端硬件地址(client hardware address，chaddr)字段表示客户端设备的硬件地址(例如MAC地址)。客户端设备会在DHCP报文中设置chaddr字段。UDP数据包的以太网帧头也包含客户端设备的硬件地址，但通常通过查看UDP数据包来确定以太网帧头的字段获取硬件地址比较困难。而通过在UDP协议承载的DHCP报文中设置chaddr字段，用户进程从chaddr字段能够很容易地获取硬件地址。chaddr字段的长度为16字节。

服务端设备名(server host name，sname)字段是可选字段。sname字段表示服务端设备的主机名。sname字段的值是空结尾的字符串。sname字段由服务端设备填写。sname字段为64字节。

file字段表示启动文件名。可选地，file字段的值是一个空结尾的字符串。DHCP发现报文中file字段的值是"generic"名字或空字符。DHCP提供报文中file字段的值是有效的目录路径全名。

选项(options)部分是DHCP报文中的可选参数域。选项部分的格式为类型长度值(type length value，TLV)。选项部分包括类型(type)字段、长度(length)字段以及值(value)字段。类型字段包括选项部分的选项号。长度字段包括选项部分中值字段的长度。选项部分的长度是可变的。

下面对本实施例在DHCP中扩展的选项举例说明。

以携带文件相关信息的选项称为option X为例，下面对option X进行介绍。其中，X表示选项号(即Option号)。X为正整数。例如，X为211。

请参见附图4，附图4是对option X的格式的举例说明。可选地，附图4所示的option X为在DHCP报文中新增的选项。option X包括类型字段、长度字段以及值字段。

在一个示例中，option X中的值字段包括启动文件名(startFilename)字段。startFilename字段用于携带文件信息。startFilename字段的格式如下表1所示。在一个示例中，startFilename字段包括目标文件的文件名。例如，startFilename字段包括V*R*C00_ATN.CC。在一个示例中，startFilename字段包括目标文件的文件保存地址。例如，startFilename字段包括CFARD*:\\V*R*C00_ATN.CC。在一个示例中，startFilename字段的值为空(null)。

表1

option X中的类型字段用于标识option X包括文件字段，类型字段包括option X的选项号(即X的取值)。在一个示例中，option X中类型字段的值为211，表明option X中值字段携带的信息为文件信息。

以上对本申请实施例涉及的系统架构以及报文格式进行了举例说明，下面通过方法200至方法300，示例性介绍基于上文提供的系统架构下载文件的方法流程。

方法200以及方法300中涉及客户端设备与中继设备之间交互的请求报文以及应答报文，还涉及中继设备与服务端设备之间交互的请求报文以及应答报文。为了区分描述，下面的一些实施例中，将客户端设备发送的请求报文称为第一请求报文，将中继设备发送的应答报文称为第一应答报文；将中继设备发送的请求报文称为第二请求报文，将服务端设备发送的应答报文称为第二应答报文。

参见附图5，附图5是本申请实施例提供的一种文件下载方法200的流程图。方法200应用在包括客户端设备、中继设备和服务端设备的通信系统。例如，方法200应用在系统架构100中，方法200中的服务端设备为服务端设备110，方法200中的中继设备为中继设备121，方法200中的客户端设备为客户端设备131。

示例性地，方法200包括S210至S250。

S210、客户端设备发送第一请求报文。

S220、中继设备接收客户端设备发送的第一请求报文。

S230、中继设备向客户端设备发送第一应答报文。

第一应答报文为第一请求报文的应答。第一应答报文包括第一指示信息，第一指示信息用于指示中继设备包括目标文件。

第一指示信息的具体内容包括多种情况，下面结合情况A和情况B对第一指示信息举例说明。

情况A、中继设备发送的应答报文包含具体的文件信息。

在一个示例中，第一指示信息包括目标文件的第一信息。目标文件的第一信息包括以下一项或多项：文件名、版本号、文件类型和文件保存地址。在一个示例中，文件保存地址用于指示目标文件在中继设备中存储的位置。例如，文件保存地址为目标文件在中继设备中的存储路径。例如，文件保存地址为FTP目录或者SFTP目录。例如，文件保存地址为CFARD*:\\V*R*C00_ATN.CC。又如，文件保存地址为目标文件在中继设备中的逻辑地址或物理地址。

情况B、中继设备发送的应答报文包含指示文件存在的标识。

在一个示例中，第一指示信息包括第一存在标识。第一存在标识用于指示中继设备包括目标文件。

本实施例对第一存在标识的形式不做限定。例如，第一存在标识为预设字符串。该预设字符串的含义是中继设备具有目标文件，客户端设备能够从中继设备下载目标文件。比如说，第一存在标识为“yes”、“OK”等。又如，第一存在标识的格式满足预设格式。例如，第一存在标识是数字、字母和符号的组合。比如说，第一存在标识的前m位均是数字，后n位均是字母。其中，m和n为正整数。

中继设备通过在应答报文中携带第一指示信息，从而利用应答报文来通告中继设备上存在目标文件，便于客户端设备根据第一指示信息来执行后续的文件下载流程。

在一个示例中，第一请求报文包括第二指示信息，第二指示信息用于指示客户端设备请求目标文件。第二指示信息的具体内容包括多种情况，下面结合情况一和情况二对第二指示信息举例说明。

情况一、客户端设备发送的请求报文包含具体的文件信息。

情况一适于客户端通过请求报文指定文件的场景。在一个示例中，第二指示信息包括以下一项或多项：目标文件的文件名、目标文件的版本号和目标文件的文件类型。例如，目标文件的文件名为V*R*C00_ATN.CC。目标文件的文件类型为系统软件(如*.CC格式的文件)、补丁文件(如*.PAT格式的文件)、多媒体文件(如音频、视频、图像)等。

基于情况一描述的方式，客户端设备通过在请求报文中携带具体的文件信息，从而利用请求报文指定具体需要下载哪一个文件，便于中继设备或者服务端设备根据文件信息明确查询本地是否存在客户端设备所需的文件，有助于简化中继设备或者服务端设备的处理逻辑，有助于中继设备或者服务端设备后续提供的文件更精准地满足客户端设备的需求。

情况二、客户端设备发送的请求报文包含请求文件的标识。

情况二适于客户端不通过请求报文指定文件的场景。在一个示例中，第二指示信息包括第一请求标识，第一请求标识用于指示客户端设备请求文件。

本实施例对第一请求标识的形式不做限定。例如，第一请求标识为null。又如，第一请求标识为预设字符串。又如，第一请求标识的格式满足预设格式。例如，第一请求标识是数字、字母和符号的组合。比如说，第一请求标识的前m位均是数字，后n位均是字母。其中，m和n为正整数。

第二指示信息与第一指示信息可以相同，也可以不同。例如，第一指示信息为目标文件的文件保存地址。第二指示信息为目标文件的文件名。

以上介绍的第二指示信息为第一请求报文的可选特征。在另一个示例中，第一请求报文不包括第二指示信息。例如，在中继设备或者服务端设备控制向客户端设备传输文件的场景下，中继设备通过应答报文(第一应答报文)指示目标文件，而无需客户端设备在请求报文中携带文件相关的信息。

在一个示例中，在第一请求报文包括第二指示信息的情况下，中继设备根据第一请求报文携带的第二指示信息向客户端设备发送以上介绍的第一应答报文。其中，以上第二指示信息涉及的情况一、第二指示信息涉及的情况二与第一指示信息涉及的情况A、第一指示信息涉及的情况B可以任意结合。具体地，在客户端设备发送的请求报文包含具体的文件信息的情况下，中继设备发送的应答报文可选地包含具体的文件信息，或者包含指示文件存在的标识；在客户端设备发送的请求报文包含请求文件的标识的情况下，中继设备发送的应答报文可选地包含具体的文件信息，或者包含指示文件存在的标识。下面对各种不同情况的指示信息结合时方案的具体实现方式进行举例介绍。

结合上述第二指示信息涉及的情况一以及第一指示信息涉及的情况A，中继设备根据第一请求报文携带的目标文件的文件名、目标文件的版本号和目标文件的文件类型，确定目标文件的第一信息；中继设备根据目标文件的第一信息生成第一应答报文。例如，第一请求报文携带目标文件的文件名。中继设备保存有文件名与文件保存地址之间的对应关系。中继设备根据第一请求报文携带的文件名，查询文件名与文件保存地址之间的对应关系，得到目标文件的文件保存地址；中继设备将目标文件的文件保存地址携带在应答报文中，从而得到包括文件保存地址的第一应答报文。

结合上述第二指示信息涉及的情况一以及第一指示信息涉及的情况B，中继设备根据第一请求报文携带的目标文件的文件名、目标文件的版本号和目标文件的文件类型，中继设备判断本地是否保存目标文件。如果中继设备本地保存目标文件，则中继设备将第一存在标识携带在应答报文中，从而得到包括第一存在标识的第一应答报文。

结合上述第二指示信息涉及的情况二以及第二指示信息涉及的情况A，中继设备判断第一请求报文是否携带第一请求标识；如果第一请求报文携带第一请求标识，中继设备确定客户端设备所需的目标文件；中继设备根据目标文件的第一信息生成第一应答报文，从而得到包括目标文件的第一信息的第一应答报文。

结合上述第二指示信息涉及的情况二以及第二指示信息涉及的情况B，中继设备判断第一请求报文是否携带第一请求标识；如果第一请求报文携带第一请求标识，中继设备确定客户端设备所需的目标文件；中继设备判断本地是否保存目标文件。如果中继设备本地保存目标文件，则中继设备将第一存在标识携带在应答报文中，从而得到包括第一存在标识的第一应答报文。

在由中继设备来确定客户端设备所需的目标文件的情况下，本实施例对中继设备如何确定目标文件不做限定。在一个示例中，中继设备根据客户端设备的类型确定目标文件，目标文件的类型与客户端设备的类型满足匹配条件。其中，客户端设备的类型例如通过客户端设备的设备型号、客户端设备的IP地址、客户端设备的系统版本或者其他信息表示。例如，中继设备发现客户端设备的设备型号为V1R1C00_ATC，则中继设备确定与V1R1C00_ATC满足匹配条件的文件为V1R2C00_ATN.cc，在这个例子中，V1R2C00_ATN.cc为与客户端类型匹配的目标文件。又如，中继设备保存IP地址范围与文件类型之间的对应关系。中继设备确定客户端设备的IP地址所属的IP地址范围，中继设备根据预先保存的对应关系确定该IP地址范围对应的文件类型，从而找到该文件类型的目标文件。

其中，中继设备如何确定客户端设备的类型包括多种方式。在一个示例中，第一请求报文包括客户端设备的类型。例如，客户端设备的类型和上述第一请求标识携带在同一个第一请求报文中。比如说，请求报文中option X的值字段同时包含请求标识以及客户端设备的类型。通过这种方式，客户端设备在请求下载文件的同时，通过在请求报文中携带自身的类型，便于中继设备选择适于传给客户端设备的文件。在另一个示例中，中继设备预先配置中继设备连接的每个客户端设备的类型。在另一个示例中，中继设备根据服务端设备发来的消息确定客户端设备的类型。

此外，第一指示信息涉及的情况A或者第一指示信息涉及的情况B可以和第一请求报文不包括第二指示信息的情况任意结合。在一个示例中，在第一请求报文不包括第二指示信息的情况下，中继设备接收到第一请求报文后，中继设备判断是否需要向客户端设备提供目标文件。如果中继设备确定需要将目标文件传输给客户端设备，则中继设备根据目标文件的第一信息生成第一应答报文。例如，中继设备根据客户端设备的设备型号、客户端设备的IP地址、客户端设备的系统版本或者其他信息，判断是否需要向客户端设备提供目标文件。例如，在批量升级的场景下，预先配置一段MAC地址范围，指定该MAC地址范围内的每个客户端设备均需要进行升级。当中继设备在接收到第一请求报文后，如果中继设备发现第一请求报文中的源MAC地址落入该指定的MAC地址范围，则中继设备确定需要将升级所需的目标文件传输给客户端设备。

在一个示例中，客户端设备收到第一应答报文后，先通过类型匹配的方式，验证第一应答报文指示的文件是否是客户端所需的文件；如果第一应答报文指示的文件是客户端所需的文件，则客户端设备执行下载文件的动作；如果第一应答报文指示的文件不是客户端所需的文件，则客户端设备取消执行下载文件的动作。例如，第一指示信息包括目标文件的文件类型；客户端设备判断目标文件的类型与客户端设备的类型是否满足匹配条件；客户端设备确定目标文件的类型与客户端设备的类型满足匹配条件，则客户端设备根据第一指示信息从中继设备下载目标文件。

本实施例对第一请求报文以及第一应答报文具体采用哪种协议报文实现不做限定。在一个示例中，第一请求报文采用下述协议报文之一：DHCP协议报文、RADIUS报文或PPPOE报文，对应的，第一应答报文采用下述协议报文中与第一请求报文一致的协议报文。下面通过场景一至场景三结合具体的协议类型对第一请求报文以及第一应答报文举例说明。

场景一、通过DHCP协议实现方法200的方法流程。

第一请求报文采用DHCP协议报文实现。第一请求报文具体为DHCP协议中的请求报文。第一应答报文采用DHCP协议报文实现。第一应答报文具体为DHCP协议中的应答报文。例如，第一请求报文为DHCP discover报文，第一应答报文为DHCP offer报文。又如，第一请求报文为DHCP request报文，第一应答报文为DHCP ACK报文。

场景一可基于DHCP协议的三层系统架构实现。具体地，DHCP协议的三层系统架构包括DHCP server设备、DHCP relay设备以及DHCP client设备。应用在本实施例中，服务端设备为DHCP server设备。中继设备为DHCP relay设备，客户端设备为DHCP client设备。

本实施例通过以上场景一介绍的特征，支持文件下载流程与DHCP协议平滑地融合起来，便于复用DHCP协议的系统架构以及通信流程实施方案，从而降低方案实施的复杂度和配置的复杂度，提高方案的可用性。

场景二、通过RADIUS协议实现方法200的方法流程。

第一请求报文采用RADIUS协议报文实现。第一请求报文具体为RADIUS协议中的请求报文。第一应答报文采用RADIUS协议报文实现。第一应答报文具体为RADIUS协议中的应答报文。例如，第一请求报文为RADIUS接入请求(access-request)报文，第一应答报文为RADIUS接入成功回应(access-accept)报文。又如，第一请求报文为RADIUS计费请求(accounting-request)报文，第一应答报文为RADIUS计费回应(accounting-response)报文。

场景二可基于RADIUS协议的三层系统架构实现。具体地，RADIUS协议的三层系统架构包括RADIUS server设备、RADIUS relay设备以及RADIUS client设备。应用在本实施例中，服务端设备为RADIUS server设备。中继设备为RADIUS relay设备，客户端设备为RADIUS client设备。

本实施例通过以上场景二介绍的特征，支持文件下载流程与RADIUS协议平滑地融合起来，便于复用RADIUS协议的系统架构以及通信流程实施方案，从而降低方案实施的复杂度和配置的复杂度，提高方案的可用性。

场景三、通过PPPOE协议实现方法200的方法流程。

第一请求报文采用PPPOE协议报文实现。第一请求报文具体为PPPOE协议中的请求报文。第一应答报文采用PPPOE协议报文实现。第一应答报文具体为PPPOE协议中的应答报文。例如，第一请求报文为PPPOE主动发现初始(PPPOE Active Discovery Initiation，PADI)报文，第一应答报文为PPPOE主动发现提供(PPPoE Active Discovery Offer，PADO)报文。又如，第一请求报文为PPPOE主动发现请求(PPPoE Active Discovery Request，PADR)报文，第一应答报文为PPPOE主动发现会话确认(PPPoE Active Discovery Session-confirmation，PADS)报文。

场景三可基于PPPOE协议的三层系统架构实现。具体地，PPPOE协议的三层系统架构包括PPPOE server设备、PPPOE relay设备以及PPPOE client设备。应用在本实施例中，服务端设备为PPPOE server设备。中继设备为PPPOE relay设备，客户端设备为PPPOEclient设备。

本实施例通过以上场景三介绍的特征，支持文件下载流程与PPPOE协议平滑地融合起来，便于复用PPPOE协议的系统架构以及通信流程实施方案，从而降低方案实施的复杂度和配置的复杂度，提高方案的可用性。

本实施例对第一指示信息在第一应答报文中的携带位置不做限定。在一个示例中，通过新增一种类型的选项来携带第一指示信息。具体地，第一应答报文包括第一选项部分，第一选项部分包括类型字段以及值字段，值字段包括第一指示信息，类型字段用于标识第一选项部分包括第一指示信息。在一个示例中，第一选项部分还包括长度字段。长度字段用于标识值字段的长度。在一个示例中，第一选项部分为以上介绍的option X。第一选项部分包括的类型字段为option X中的类型字段。第一选项部分中的值字段为表1所示的startFilename字段。结合以上场景一，第一选项部分例如为DHCP协议报文中一种新增的选项。结合以上场景二，第一选项部分例如为RADIUS协议报文中一种新增的选项。结合以上场景三，第一选项部分例如为PPPOE协议报文中一种新增的选项。

本实施例对第二指示信息在第一请求报文中的携带位置不做限定。在一个示例中，通过新增一种类型的选项来携带第二指示信息。具体地，第一请求报文包括第二选项部分，第二选项部分包括类型字段以及值字段，值字段包括第二指示信息，类型字段用于标识第二选项部分包括第二指示信息。在一个示例中，第二选项部分还包括长度字段。长度字段用于标识值字段的长度。在一个示例中，第二选项部分为以上介绍的option X。第二选项部分包括的类型字段为option X中的类型字段。第二选项部分中的值字段为表1所示的startFilename字段。结合以上场景一，第二选项部分例如为DHCP协议报文中一种新增的选项。结合以上场景二，第二选项部分例如为RADIUS协议报文中一种新增的选项。结合以上场景三，第二选项部分例如为PPPOE协议报文中一种新增的选项。

S240、客户端设备接收中继设备发送的第一应答报文。

S250、客户端设备根据第一指示信息从中继设备下载目标文件。

客户端设备如何利用应答报文携带的指示信息下载文件包括多种实现方式，下面结合实现方式a和实现方式b举例说明。

实现方式a、客户端设备从应答报文携带的保存地址下载文件。

实现方式a适用于上述情况A中第一信息包括文件保存地址的情况。具体地，客户端设备从第一应答报文获得目标文件的文件保存地址，客户端设备根据目标文件的文件保存地址下载目标文件。

通过实现方式a，客户端设备能够直接从应答报文中获得文件保存地址，从而降低客户端设备以及中继设备配置的复杂度，从而提高文件下载的效率。

实现方式b、客户端设备从默认地址下载文件。

实现方式b适用于上述情况A中第一信息包括文件名、版本号、文件类型的情况以及上述情况B。具体地，客户端设备保存默认地址。客户端设备接收到第一应答报文后，判断第一应答报文是否包含第一存在标识。响应于第一应答报文包含第一存在标识，客户端设备从默认地址下载文件。

本实施例对客户端设备如何获得默认地址不做限定。在一个示例中，客户端设备通过与中继设备预先进行协商来获得默认地址。比如说，中继设备预先分配一段用于保存文件的存储空间，中继设备将该存储空间的地址作为默认地址，中继设备将该默认地址在协商阶段通告给客户端设备。客户端设备接收并保存该默认地址。每当客户端设备需要下载文件时，客户端设备均从该默认地址下载所需的文件。在另一个示例中，客户端设备与中继设备通过静态配置的方式获得默认地址。例如，由网管人员在客户端设备与中继设备分别执行配置操作来配置默认地址。在另一个示例中，客户端设备保存默认地址与文件名、版本号或者文件类型之间的对应关系。客户端设备接收到第一应答报文后，客户端设备从第一应答报文获得文件名、版本号或者文件类型。客户端设备根据文件名、版本号或者文件类型查询该对应关系，得到文件名、版本号或者文件类型对应的默认地址。

以上通过实现方式a和实现方式b介绍了客户端设备从中继设备下载文件的两类实现方式。可选地，上述下载文件的流程基于文件传输协议实现。该文件传输协议包括而不限于FTP或者SFTP。例如，客户端设备生成FTP请求或者SFTP请求；客户端设备向中继设备发送FTP请求或者SFTP请求；中继设备响应于FTP请求或者SFTP请求，基于FTP或者SFTP向客户端设备发送文件。其中，结合上述实现方式a，客户端设备发送的FTP请求或者SFTP请求例如携带应答报文携带的保存地址。例如，客户端设备发送的FTP请求或者SFTP请求携带目标文件的文件保存地址。结合上述实现方式b，客户端设备发送的FTP请求或者SFTP请求例如携带默认地址。

本实施例对客户端设备如何应用下载的文件不做限定。在一个示例中，应用在设备升级的场景下，目标文件为系统软件，客户端设备根据系统软件进行升级。在另一个示例中，应用在设备打补丁的场景下，目标文件为补丁文件，客户端设备根据补丁文件加载补丁。

本实施例提供的方法，通过在客户端设备、中继设备和服务端设备这样的三层系统架构中，利用客户端设备与中继设备之间传递的报文来指示中继设备上具有客户端所需的文件，客户端设备通过与中继设备进行交互，能够从中继设备下载文件，从而实现了文件的就近下载文件，因此节省了文件传输占用的带宽。

以上方法200中，中继设备会响应于第一应答报文，中继设备向客户端设备传输目标文件，使得客户端设备从中继设备获得目标文件。

本实施例对中继设备何时获得客户端所需的目标文件不做限定。在一个示例中，中继设备在客户端发起请求之后获得目标文件。例如，中继设备接收到第一请求报文后，中继设备判断本地是否保存目标文件。如果中继设备本地没有保存目标文件，则中继设备下载目标文件，再将下载的目标文件发送给客户端。在另一个示例中，中继设备在客户端发起请求之前已经获得目标文件。例如，中继设备预先下载至少一个文件，中继设备将至少一个文件保存至本地。中继设备接收到第一请求报文后，中继设备从本地保存的至少一个文件中确定客户端所需的目标文件，将目标文件发送至客户端。

本实施例对中继设备获得目标文件的方式不做限定。在一个示例中，目标文件为中继设备从服务端设备处获得的。下面结合方法300对中继设备具体如何从服务端设备获得文件举例说明。

参见附图6，附图6是本申请实施例提供的一种文件下载方法300的流程图。方法300应用在包括客户端设备、中继设备和服务端设备的通信系统。例如，方法300应用在系统架构100中，方法300中的服务端设备为服务端设备110，方法300中的中继设备为中继设备121，方法300中的客户端设备为客户端设备131。

示例性地，方法300包括S310至S360。

S310、中继设备发送第二请求报文。

S320、服务端设备接收中继设备发送的第二请求报文。

S330、服务端设备生成第二应答报文。第二应答报文为第二请求报文的应答。第二应答报文包括第三指示信息，第三指示信息用于指示服务端设备包括目标文件。

S340、服务端设备向中继设备发送第二应答报文。第二应答报文为第二请求报文的应答。第二应答报文包括第三指示信息，第三指示信息用于指示服务端设备包括目标文件。

第三指示信息的具体内容包括多种情况，下面结合情况A和情况B对第三指示信息举例说明。

情况A、服务端设备发送的应答报文包含具体的文件信息。

在一个示例中，第三指示信息包括目标文件的第二信息。目标文件的第二信息包括以下一项或多项：文件名、版本号、文件类型和文件保存地址。在一个示例中，文件保存地址用于指示目标文件在服务端设备中存储的位置。例如，文件保存地址为目标文件在服务端设备中的存储路径。例如，文件保存地址为FTP目录或者SFTP目录。例如，文件保存地址为CFARD*:\\V*R*C00_ATN.CC。又如，文件保存地址为目标文件在服务端设备中的逻辑地址或物理地址。

情况B、服务端设备发送的应答报文包含指示文件存在的标识。

在一个示例中，第三指示信息包括第二存在标识。第二存在标识用于指示服务端设备包括目标文件。

本实施例对第二存在标识的形式不做限定。例如，第二存在标识为预设字符串。该预设字符串的含义是服务端设备具有目标文件，中继设备能够从服务端设备下载目标文件。比如说，第二存在标识为“yes”、“OK”等。又如，第二存在标识的格式满足预设格式。例如，第二存在标识是数字、字母和符号的组合。比如说，第二存在标识的前m位均是数字，后n位均是字母。其中，m和n为正整数。

服务端设备通过在应答报文中携带第三指示信息，从而利用应答报文来通告服务端设备上存在目标文件，便于中继设备根据第三指示信息来执行后续的文件下载流程。

在一个示例中，第二请求报文包括第四指示信息，第四指示信息用于指示中继设备请求目标文件。第四指示信息的具体内容包括多种情况，下面结合情况一和情况二对第四指示信息举例说明。

情况一、中继设备发送的请求报文包含具体的文件信息。

在一个示例中，第四指示信息包括以下一项或多项：目标文件的文件名、目标文件的版本号和目标文件的文件类型。

可选地，第四指示信息和第二指示信息是相同的。例如，第四指示信息和第二指示信息都是目标文件的文件名。或者，第四指示信息和第二指示信息是同一个目标文件的不同信息。例如，第二指示信息为目标文件的文件类型，第四指示信息为目标文件的文件名。例如，中继设备接收到第一请求报文后，中继设备根据第一请求报文携带的文件类型，查询文件类型与文件名之间的对应关系，将文件类型对应的文件名携带在第二请求报文中。

情况二、中继设备发送的请求报文包含请求文件的标识。

在一个示例中，第四指示信息包括第二请求标识，第二请求标识用于指示中继设备请求文件。

本实施例对第二请求标识的形式不做限定。例如，第二请求标识为null。又如，第二请求标识为预设字符串。又如，第二请求标识的格式满足预设格式。例如，第二请求标识是数字、字母和符号的组合。比如说，第二请求标识的前m位均是数字，后n位均是字母。其中，m和n为正整数。

以上介绍的第四指示信息为第二请求报文的可选特征。在另一个示例中，第二请求报文不包括第四指示信息。

在一个示例中，在第二请求报文包括第四指示信息的情况下，服务端设备根据第二请求报文携带的第四指示信息向中继设备发送以上介绍的第二应答报文。其中，以上第四指示信息涉及的情况一、第四指示信息涉及的情况二与第三指示信息涉及的情况A、第三指示信息涉及的情况B可以任意结合。具体地，在中继设备发送的请求报文包含具体的文件信息的情况下，服务端设备发送的应答报文可选地包含具体的文件信息，或者包含指示文件存在的标识；在中继设备发送的请求报文包含请求文件的标识的情况下，服务端设备发送的应答报文可选地包含具体的文件信息，或者包含指示文件存在的标识。下面对各种不同情况的指示信息结合时方案的具体实现方式进行举例介绍。

结合上述第四指示信息涉及的情况一以及第三指示信息涉及的情况A，服务端设备根据第二请求报文携带的目标文件的文件名、目标文件的版本号和目标文件的文件类型，确定目标文件的第二信息；服务端设备根据目标文件的第二信息生成第二应答报文。例如，第二请求报文携带目标文件的文件名。服务端设备保存有文件名与文件保存地址之间的对应关系。服务端设备根据第二请求报文携带的文件名，查询文件名与文件保存地址之间的对应关系，得到目标文件的文件保存地址；服务端设备将目标文件的文件保存地址携带在应答报文中，从而得到包括文件保存地址的第二应答报文。

结合上述第四指示信息涉及的情况一以及第三指示信息涉及的情况B，服务端设备根据第二请求报文携带的目标文件的文件名、目标文件的版本号和目标文件的文件类型，服务端设备判断本地是否保存目标文件。如果服务端设备本地保存目标文件，则服务端设备将第二存在标识携带在应答报文中，从而得到包括第二存在标识的第二应答报文。

结合上述第四指示信息涉及的情况二以及第四指示信息涉及的情况A，服务端设备判断第二请求报文是否携带第二请求标识；如果第二请求报文携带第二请求标识，服务端设备确定中继设备所需的目标文件；服务端设备根据目标文件的第二信息生成第二应答报文，从而得到包括目标文件的第二信息的第二应答报文。

结合上述第四指示信息涉及的情况二以及第四指示信息涉及的情况B，服务端设备判断第二请求报文是否携带第二请求标识；如果第二请求报文携带第二请求标识，服务端设备确定中继设备所需的目标文件；服务端设备判断本地是否保存目标文件。如果服务端设备本地保存目标文件，则服务端设备将第二存在标识携带在应答报文中，从而得到包括第二存在标识的第二应答报文。

在由服务端设备来确定客户端设备所需的目标文件的情况下，本实施例对服务端设备如何确定目标文件不做限定。在一个示例中，服务端设备根据客户端设备的类型确定目标文件，目标文件的类型与客户端设备的类型满足匹配条件。其中，客户端设备的类型例如通过客户端设备的设备型号、客户端设备的IP地址、客户端设备的系统版本或者其他信息表示。例如，服务端设备发现客户端设备的设备型号为V1R1C00_ATC，则服务端设备确定与V1R1C00_ATC满足匹配条件的文件为V1R2C00_ATN.cc，在这个例子中，V1R2C00_ATN.cc为与客户端类型匹配的目标文件。又如，服务端设备保存IP地址范围与文件类型之间的对应关系。服务端设备确定客户端设备的IP地址所属的IP地址范围，服务端设备根据预先保存的对应关系确定该IP地址范围对应的文件类型，从而找到该文件类型的目标文件。

其中，服务端设备如何确定客户端设备的类型包括多种方式。在一个示例中，第二请求报文包括客户端设备的类型。例如，客户端设备的类型和上述第二请求标识携带在同一个第二请求报文中。比如说，请求报文中option X的值字段同时包含请求标识以及客户端设备的类型。通过这种方式，中继设备在请求下载文件的同时，通过在请求报文中携带客户端设备的类型，便于服务端设备选择适于传给客户端设备的文件。在另一个示例中，服务端设备预先配置每个客户端设备的类型。在另一个示例中，服务端设备根据中继设备发来的消息确定客户端设备的类型。

此外，第三指示信息涉及的情况A或者第三指示信息涉及的情况B可以和第二请求报文不包括第四指示信息的情况任意结合。在一个示例中，在第二请求报文不包括第四指示信息的情况下，服务端设备接收到第二请求报文后，服务端设备判断是否需要向中继设备提供目标文件。如果服务端设备确定需要将目标文件传输给中继设备，则服务端设备根据目标文件的第二信息生成第二应答报文。例如，服务端设备根据客户端设备的设备型号、客户端设备的IP地址、客户端设备的系统版本或者其他信息，判断是否需要向客户端设备提供目标文件。

本实施例对第二请求报文以及第二应答报文具体采用哪种协议报文实现不做限定。在一个示例中，第二请求报文采用下述协议报文之一：DHCP协议报文、RADIUS报文或PPPOE报文。第二应答报文采用与第二请求报文一致的协议报文。下面通过场景一至场景三结合具体的协议类型对第二请求报文以及第二应答报文举例说明。

场景一、通过DHCP协议实现方法300的方法流程。

第二请求报文采用DHCP协议报文实现。第二请求报文具体为DHCP协议中的请求报文。第二应答报文采用DHCP协议报文实现。第二应答报文具体为DHCP协议中的应答报文。例如，第二请求报文为DHCP discover报文，第二应答报文为DHCP offer报文。又如，第二请求报文为DHCP request报文，第二应答报文为DHCP ACK报文。

场景二、通过RADIUS协议实现方法300的方法流程。

第二请求报文采用RADIUS协议报文实现。第二请求报文具体为RADIUS协议中的请求报文。第二应答报文采用RADIUS协议报文实现。第二应答报文具体为RADIUS协议中的应答报文。例如，第二请求报文为RADIUS access-request报文，第二应答报文为RADIUSaccess-accept报文。又如，第二请求报文为RADIUS accounting-request报文，第二应答报文为RADIUS accounting-response报文。

场景三、通过PPPOE协议实现方法300的方法流程。

第二请求报文采用PPPOE协议报文实现。第二请求报文具体为PPPOE协议中的请求报文。第二应答报文采用PPPOE协议报文实现。第二应答报文具体为PPPOE协议中的应答报文。例如，第二请求报文为PADI报文，第二应答报文为PADO报文。又如，第二请求报文为PADR报文，第二应答报文为PADS报文。

本实施例对第三指示信息在第二应答报文中的携带位置不做限定。在一个示例中，通过新增一种类型的选项来携带第三指示信息。具体地，第二应答报文包括第三选项部分，第三选项部分包括类型字段以及值字段，值字段包括第三指示信息，类型字段用于标识第三选项部分包括第三指示信息。在一个示例中，第三选项部分还包括长度字段。长度字段用于标识值字段的长度。在一个示例中，第三选项部分为以上介绍的option X。第三选项部分包括的类型字段为option X中的类型字段。第三选项部分中的值字段为表1所示的startFilename字段。结合以上场景一，第三选项部分例如为DHCP协议报文中一种新增的选项。结合以上场景二，第三选项部分例如为RADIUS协议报文中一种新增的选项。结合以上场景三，第三选项部分例如为PPPOE协议报文中一种新增的选项。

本实施例对第四指示信息在第二请求报文中的携带位置不做限定。在一个示例中，通过新增一种类型的选项来携带第四指示信息。具体地，第二请求报文包括第四选项部分，第四选项部分包括类型字段以及值字段，值字段包括第四指示信息，类型字段用于标识第四选项部分包括第四指示信息。在一个示例中，第四选项部分还包括长度字段。长度字段用于标识值字段的长度。在一个示例中，第四选项部分为以上介绍的option X。第四选项部分包括的类型字段为option X中的类型字段。第四选项部分中的值字段为表1所示的startFilename字段。结合以上场景一，第四选项部分例如为DHCP协议报文中一种新增的选项。结合以上场景二，第四选项部分例如为RADIUS协议报文中一种新增的选项。结合以上场景三，第四选项部分例如为PPPOE协议报文中一种新增的选项。

S350、中继设备接收服务端设备发送的第二应答报文。

S360、中继设备根据第三指示信息从服务端设备下载目标文件。

中继设备如何利用应答报文携带的指示信息下载文件包括多种实现方式，下面结合实现方式a和实现方式b举例说明。

实现方式a、中继设备从应答报文携带的保存地址下载文件。

实现方式a适用于上述情况A中第二信息包括文件保存地址的情况。具体地，中继设备从第二应答报文获得目标文件的文件保存地址，中继设备根据目标文件的文件保存地址下载目标文件。

通过实现方式a，中继设备能够直接从应答报文中获得文件保存地址，从而降低中继设备以及服务端设备配置的复杂度，从而提高文件下载的效率。

实现方式b、中继设备从默认地址下载文件。

实现方式b适用于上述情况A中第二信息包括文件名、版本号、文件类型的情况以及上述情况B。具体地，中继设备保存默认地址。中继设备接收到第二应答报文后，判断第二应答报文是否包含第二存在标识。响应于第二应答报文包含第二存在标识，中继设备从默认地址下载文件。

本实施例对中继设备如何获得默认地址不做限定。在一个示例中，中继设备通过与服务端设备预先进行协商来获得默认地址。比如说，服务端设备预先分配一段用于保存文件的存储空间，服务端设备将该存储空间的地址作为默认地址，服务端设备将该默认地址在协商阶段通告给中继设备。中继设备接收并保存该默认地址。每当中继设备需要下载文件时，中继设备均从该默认地址下载所需的文件。在另一个示例中，中继设备与服务端设备通过静态配置的方式获得默认地址。例如，由网管人员在中继设备与服务端设备分别执行配置操作来配置默认地址。在另一个示例中，中继设备保存默认地址与文件名、版本号或者文件类型之间的对应关系。中继设备接收到第二应答报文后，中继设备从第二应答报文获得文件名、版本号或者文件类型。中继设备根据文件名、版本号或者文件类型查询该对应关系，得到文件名、版本号或者文件类型对应的默认地址。

以上通过实现方式a和实现方式b介绍了中继设备从服务端设备下载文件的两类实现方式。可选地，上述下载文件的流程基于文件传输协议实现。该文件传输协议包括而不限于FTP或者SFTP。例如，中继设备生成FTP请求或者SFTP请求；中继设备向服务端设备发送FTP请求或者SFTP请求；服务端设备响应于FTP请求或者SFTP请求，基于FTP或者SFTP向中继设备发送文件。其中，结合上述实现方式a，中继设备发送的FTP请求或者SFTP请求例如携带应答报文携带的保存地址。例如，中继设备发送的FTP请求或者SFTP请求携带目标文件的文件保存地址。结合上述实现方式b，中继设备发送的FTP请求或者SFTP请求例如携带默认地址。

以下通过附图7所示的方法400，对上述方法200和方法300进一步举例说明。在下面的方法400中，客户端设备、中继设备、服务端设备之间的交互属于部署中继场景下DHCP客户端接入网络时的交互过程，客户端设备、中继设备、服务端设备之间交互的报文为DHCP报文，携带文件信息的选项部分为option X，客户端下载的文件为*.CC类型的文件。换句话说，方法400关于客户端设备、中继设备、服务端设备如何通过在DHCP报文中添加option X实现*.CC类型的文件的下载。

示例性地，方法400包括以下步骤S401至S408。

S401、客户端设备发送DHCP discover报文。客户端设备发送的DHCP discover报文携带option X，option X携带*.CC类型文件的文件信息。例如，option X携带文件名。

S402、中继设备接收到客户端发送的DHCP discover报文后，中继设备向服务端设备发送DHCP discover报文。中继设备发送的DHCP discover报文携带option X。option X携带*.CC类型文件的文件信息。例如，option X携带文件名。

S403、服务端设备向中继设备发送DHCP offer报文。服务端设备发送的DHCPoffer报文携带option X，option X携带*.CC类型文件的文件保存地址。

S404、中继设备接收到DHCP offer报文后。中继设备向服务端设备发送FTP请求，FTP请求携带*.CC类型文件的文件保存地址。

S405、中继设备向客户端设备发送DHCP offer报文。中继设备发送的DHCP offer报文携带option X，option X携带*.CC类型文件的文件保存地址。

S406、服务端设备向中继设备发送DHCP ACK报文。DHCP ACK报文携带option X，option X携带*.CC类型文件的保存地址。

S407、客户端设备接收到DHCP offer报文后。客户端设备向中继设备发送FTP请求，FTP请求携带*.CC类型文件的保存地址。

S408、中继设备向客户端设备发送DHCP release报文。中继设备发送的DHCPrelease报文携带option X。

通过以上方法400，能够在复杂网络中，实现更快，更高效对批量设备传输文件，加快现网升级速度。并且，就近下载的方式能够减少网络中升级带来的带宽占用以及网络不稳定导致传输失败等问题。

以下通过附图8所示的方法500，对上述方法200进一步举例说明。在下面的方法500中，客户端设备、中继设备、服务端设备之间的交互的报文为RADIUS报文。

示例性地，方法500包括以下步骤S501至S502。

S501、客户端设备发送RADIUS access-request报文。客户端设备发送的RADIUSaccess-request报文携带目标文件的文件名或者null。

S502、中继设备接收RADIUS access-request报文。中继设备向客户端设备发送RADIUS access-accept报文，RADIUS access-accept报文携带目标文件的文件保存地址。

下面对RADIUS协议报文的格式举例说明。

参见附图9，附图9是对RADIUS协议报文的举例说明。RADIUS协议报文包含五个字段：编码(code)字段、标识(identifier，ID)字段、长度(length)字段、验证信息(authenticator)字段、属性(attributes)字段。其中，除了attributes字段，其余字段都是固定长度。

code字段是用来区分RADIUS报文类型的，常见的RADIUS报文类型有1、2、3。code字段的具体含义参见下表2。

表2

identifier字段用来匹配请求与回应的数据包，也就是用来区分每组请求回应的编号。

length字段是用来记录整个数据包的长度。其中code字段、identifier字段、length字段、authenticator字段为定长。报文最短长度为20字节，最长长度为4096字节。如果报文长度小于length字段的长度值，报文会被丢弃。

authenticator字段分为两种。第一种是接入请求报文产生的一个16字节的随机数RequestAuth。第二种是接入成功回应报文由公式产生的16字节的数值，具体公式为：MD5(Code+ID+Length+RequestAuth+Attributes+Secret)。

attributes字段携带了特定的认证和授权信息以及请求和回应报文的配置细节，涉及用户的账号，密码，登录的IP地址，登录设备的IP地址等等。

以上介绍了本申请实施例的方法200、方法300、方法400以及方法500，以下介绍本申请实施例的客户端设备、中继设备以及服务端设备。下面介绍的客户端设备、中继设备以及服务端设备分别具有上述方法200、方法300、方法400以及方法500中客户端设备、中继设备或者服务端设备的任意功能。

附图10示出了上述实施例中所涉及的客户端设备的一种可能的结构示意图。附图10所示的客户端设备600例如实现方法200、方法300、方法400以及方法500中客户端设备的功能。

请参考附图10，客户端设备600包括发送单元601、接收单元602和下载单元603，可选的，客户端设备600还包括处理单元。客户端设备600中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。客户端设备600中的各个单元用于执行上述方法200、方法400以及方法500中客户端设备的相应功能。具体地，发送单元601用于支持客户端设备600执行S210、S401以及S407。接收单元602用于支持客户端设备600执行S240、S405以及S408。下载单元603用于支持客户端设备600执行S250。客户端设备600包括的处理单元用于支持客户端设备600执行确定目标文件的类型与客户端设备600的类型满足匹配条件、根据系统软件进行升级、根据补丁文件加载补丁等步骤。

在一个示例中，接收单元602还用于支持客户端设备600接收中继设备发送的目标文件。

本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式。

在一些实施例中，客户端设备600中各个单元集成在一个单元中。例如，客户端设备600中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。下载单元603通过芯片中的处理电路实现。接收单元602通过芯片中的输入接口实现。发送单元601通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(英文全称：field－programmable gate array，英文简称：FPGA)、可编程逻辑器件(英文全称：programmable logic device，英文简称：PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，客户端设备600各个单元单独物理存在。在另一些实施例中，客户端设备600一部分单元单独物理存在，另一部分单元集成在一个单元中，如下载单元集成到处理单元中。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在客户端设备600中通过硬件实现的情况下，在一个示例中，客户端设备600中下载单元603例如通过设备900中的主控板910实现。客户端设备600中接收单元602、发送单元601例如通过设备900中的接口板930实现。在另一个示例中，客户端设备600中下载单元603例如通过设备1500中的处理器1501实现。客户端设备600中接收单元602、发送单元601例如通过设备1500中的通信接口1504实现。

在客户端设备600中通过软件实现的情况下，客户端设备600中各个单元例如为设备900中主控板910或者设备1500中处理器1501读取存储器中存储的程序代码后生成的软件。例如，客户端设备600为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，客户端设备600以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合网络功能虚拟化(Network FunctionsVirtualization，NFV)技术来实现客户端设备600。采用虚拟机的方式实现时，客户端设备600例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出客户端设备600。在另一些实施例中，客户端设备600以容器(例如docker容器)的形式，部署在硬件设备上。例如，客户端设备600执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建客户端设备600。在另一些实施例中，客户端设备600以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现客户端设备600中的一个或多个单元。

附图11示出了上述实施例中所涉及的中继设备的一种可能的结构示意图。附图11所示的中继设备700例如实现方法200、方法300、方法400以及方法500中中继设备的功能。

请参考附图11，中继设备700包括接收单元701、发送单元702和传输单元703，可选的，该中继设备700还包括处理单元。中继设备700中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。中继设备700中的各个单元用于执行上述方法200、方法300、方法400以及方法500中的中继设备的相应功能。具体地，接收单元701用于支持中继设备700执行S220、S340、S401、S403、S406。传输单元703用于支持中继设备700执行向客户端设备传输文件；发送单元702用于支持中继设备700执行S230、S310、S402、S404、S405、S408。中继设备700包括的处理单元用于支持中继设备700执行根据客户端设备的类型确定目标文件等步骤。

本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式。

在一些实施例中，中继设备700中各个单元集成在一个单元中。例如，中继设备700中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。传输单元703通过芯片中的处理电路实现。接收单元701通过芯片中的输入接口实现。发送单元702通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(英文全称：field－programmable gate array，英文简称：FPGA)、可编程逻辑器件(英文全称：programmable logic device，英文简称：PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，中继设备700各个单元单独物理存在。在另一些实施例中，中继设备700一部分单元单独物理存在，另一部分单元集成在一个单元中。例如，在一些实施例中，传输单元703和发送单元702是同一个单元。在另一些实施例中，传输单元703和发送单元702是不同的单元。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在中继设备700中通过硬件实现的情况下，在一个示例中，中继设备700中接收单元701、发送单元702通过设备900中的接口板930实现。中继设备700中传输单元703通过设备900中的主控板910以及接口板930实现。在另一个示例中，中继设备700中传输单元703通过设备1500中的处理器1501以及通信接口1504实现。中继设备700中接收单元701、发送单元702通过设备1500中的通信接口1504实现。

在中继设备700中通过软件实现的情况下，中继设备700中各个单元例如为设备900中主控板910或者设备1500中处理器1501读取存储器中存储的程序代码后生成的软件。例如，中继设备700为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，中继设备700以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合NFV技术来实现中继设备700。采用虚拟机的方式实现时，中继设备700例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出中继设备700。在另一些实施例中，中继设备700以容器(例如docker容器)的形式，部署在硬件设备上。例如，中继设备700执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建中继设备700。在另一些实施例中，中继设备700以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现中继设备700中的一个或多个单元。

附图12示出了上述实施例中所涉及的服务端设备的一种可能的结构示意图。附图12所示的服务端设备800例如实现方法300、方法400以及方法500中服务端设备的功能。

请参考附图12，服务端设备800包括接收单元801、处理单元802和发送单元803。服务端设备800中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。服务端设备800中的各个单元用于执行上述方法300、方法400以及方法500中服务端设备的相应功能。具体地，接收单元801用于支持服务端设备800执行S320、S402、S404。处理单元802用于支持服务端设备800执行S330以及根据客户端设备的类型确定目标文件等步骤。发送单元803用于支持服务端设备800执行S340、S403、S406。

本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式。

在一些实施例中，服务端设备800中各个单元集成在一个处理单元中。例如，服务端设备800中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。处理单元802通过芯片中的处理电路实现。接收单元801通过芯片中的输入接口实现。发送单元803通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(英文全称：field－programmable gate array，英文简称：FPGA)、可编程逻辑器件(英文全称：programmable logic device，英文简称：PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，服务端设备800各个单元单独物理存在。在另一些实施例中，服务端设备800一部分单元单独物理存在，另一部分单元集成在一个单元中。例如，在一些实施例中，处理单元802和发送单元803是同一个单元。在另一些实施例中，处理单元802和发送单元803是不同的单元。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在服务端设备800中通过硬件实现的情况下，在一个示例中，服务端设备800中处理单元802通过设备900中主控板910实现。服务端设备800中接收单元801、发送单元803通过设备900中的接口板930实现。在另一个示例中，服务端设备800中处理单元802通过设备1500中的处理器1501实现。服务端设备800中接收单元801、发送单元803例如通过设备1500中的通信接口1504实现。

在服务端设备800中通过软件实现的情况下，服务端设备800中各个单元例如为设备900中主控板910或者设备1500中处理器1501读取存储器中存储的程序代码后生成的软件。例如，服务端设备800为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，服务端设备800以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合NFV技术来实现服务端设备800。采用虚拟机的方式实现时，服务端设备800例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出服务端设备800。在另一些实施例中，服务端设备800以容器(例如docker容器)的形式，部署在硬件设备上。例如，服务端设备800执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建服务端设备800。在另一些实施例中，服务端设备800以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现服务端设备800中的一个或多个单元。

以上通过客户端设备600、中继设备700以及服务端设备800，主要从逻辑功能的角度介绍了如何实现客户端设备或者中继设备或者服务端设备。以下通过设备900以及设备1500，从硬件的角度介绍如何实现客户端设备或者中继设备或者服务端设备。附图13所示的设备900或者附图14所示的设备1500是对客户端设备或者中继设备或者服务端设备的硬件结构的举例说明。

设备900或者设备1500对应于上述方法200或方法300或方法400或方法500中的客户端设备或者中继设备或者服务端设备，设备900或者设备1500中的各硬件、模块和上述其他操作和/或功能分别为了实现方法实施例中客户端设备或者中继设备或者服务端设备所实施的各种步骤和方法，关于设备900或者设备1500如何传输文件的详细流程，具体细节可参见上述方法200或方法300或方法400或方法500，为了简洁，在此不再赘述。其中，方法200或方法300或方法400或方法500的各步骤通过设备900或者设备1500处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块例如位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤，为避免重复，这里不再详细描述。

参见附图13，附图13示出了本申请一个示例性实施例提供的设备900的结构示意图，设备900例如配置为方法200或方法300或方法400或方法500中的客户端设备或者中继设备或者服务端设备。设备900包括：主控板910和接口板930。

主控板也称为主处理单元(main processing unit，MPU)或路由处理卡(routeprocessor card)，主控板910用于对设备900中各个组件的控制和管理，包括路由计算、设备管理、设备维护、协议处理功能。主控板910包括：中央处理器911和存储器912。

接口板930也称为线路接口单元卡(line processing unit，LPU)、线卡(linecard)或业务板。接口板930用于提供各种业务接口并实现数据包的转发。业务接口包括而不限于以太网接口、POS(Packet over SONET/SDH)接口等，以太网接口例如是灵活以太网业务接口(Flexible Ethernet Clients，FlexE Clients)。接口板930包括：中央处理器931、网络处理器932、转发表项存储器934和物理接口卡(physical interface card，PIC)933。

接口板930上的中央处理器931用于对接口板930进行控制管理并与主控板910上的中央处理器911进行通信。

网络处理器932用于实现报文的转发处理。网络处理器932的形态例如是转发芯片。具体而言，网络处理器932用于基于转发表项存储器934保存的转发表转发接收到的报文，如果报文的目的地址为设备900的地址，则将该报文上送至CPU(如中央处理器911)处理；如果报文的目的地址不是设备900的地址，则根据该目的地址从转发表中查找到该目的地址对应的下一跳和出接口，将该报文转发到该目的地址对应的出接口。其中，上行报文的处理包括：报文入接口的处理，转发表查找；下行报文的处理：转发表查找等等。

物理接口卡933用于实现物理层的对接功能，原始的流量由此进入接口板930，以及处理后的报文从该物理接口卡933发出。物理接口卡933也称为子卡，可安装在接口板930上，负责将光电信号转换为报文并对报文进行合法性检查后转发给网络处理器932处理。在一些实施例中，中央处理器也可执行网络处理器932的功能，比如基于通用CPU实现软件转发，从而物理接口卡933中不需要网络处理器932。

可选地，设备900包括多个接口板，例如设备900还包括接口板940，接口板940包括：中央处理器941、网络处理器942、转发表项存储器944和物理接口卡943。

可选地，设备900还包括交换网板920。交换网板920也例如称为交换网板单元(switch fabric unit，SFU)。在网络设备有多个接口板930的情况下，交换网板920用于完成各接口板之间的数据交换。例如，接口板930和接口板940之间例如通过交换网板920通信。

主控板910和接口板930耦合。例如。主控板910、接口板930和接口板940，以及交换网板920之间通过系统总线与系统背板相连实现互通。在一种可能的实现方式中，主控板910和接口板930之间建立进程间通信协议(inter-process communication，IPC)通道，主控板910和接口板930之间通过IPC通道进行通信。

在逻辑上，设备900包括控制面和转发面，控制面包括主控板910和中央处理器931，转发面包括执行转发的各个组件，比如转发表项存储器934、物理接口卡933和网络处理器932。控制面执行路由器、生成转发表、处理信令和协议报文、配置与维护设备的状态等功能，控制面将生成的转发表下发给转发面，在转发面，网络处理器932基于控制面下发的转发表对物理接口卡933收到的报文查表转发。控制面下发的转发表例如保存在转发表项存储器934中。在有些实施例中，控制面和转发面例如完全分离，不在同一设备上。

例如，如果设备900被配置为客户端设备，接口板930上的物理接口卡933用于发送请求报文以及接收应答报文；物理接口卡933还用于将应答报文上送至主控板910上的中央处理器911。中央处理器911用于根据应答报文中的第一指示信息从中继设备下载目标文件。

例如，如果设备900被配置为中继设备，接口板930上的物理接口卡933用于接收请求报文以及向客户端设备发送应答报文；主控板910上的中央处理器911以及物理接口卡933还用于向客户端设备传输目标文件。

例如，如果设备900被配置为服务端设备，接口板930上的物理接口卡933用于接收请求报文；物理接口卡933还用于将请求报文上送至主控板910上的中央处理器911。中央处理器911用于生成应答报文；物理接口卡933还用于向中继设备发送应答报文。

接口板940上的操作与接口板930的操作一致，为了简洁，不再赘述。

值得说明的是，主控板可能有一块或多块，有多块的时候例如包括主用主控板和备用主控板。接口板可能有一块或多块，网络设备的数据处理能力越强，提供的接口板越多。接口板上的物理接口卡也可以有一块或多块。交换网板可能没有，也可能有一块或多块，有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下，网络设备可以不需要交换网板，接口板承担整个系统的业务数据的处理功能。在分布式转发架构下，网络设备可以有至少一块交换网板，通过交换网板实现多块接口板之间的数据交换，提供大容量的数据交换和处理能力。所以，分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。可选地，网络设备的形态也可以是只有一块板卡，即没有交换网板，接口板和主控板的功能集成在该一块板卡上，此时接口板上的中央处理器和主控板上的中央处理器在该一块板卡上可以合并为一个中央处理器，执行两者叠加后的功能，这种形态设备的数据交换和处理能力较低(例如，低端交换机或路由器等网络设备)。具体采用哪种架构，取决于具体的组网部署场景，此处不做任何限定。

参见附图14，附图14示出了本申请一个示例性实施例提供的设备1500的结构示意图，该设备1500例如配置为方法200或方法300或方法400或方法500中的客户端设备或者中继设备或者服务端设备。该设备1500可以是主机、服务器或个人计算机等。该设备1500可以由一般性的总线体系结构来实现。

设备1500包括至少一个处理器1501、通信总线1502、存储器1503以及至少一个通信接口1504。

处理器1501例如是通用中央处理器(central processing unit，CPU)、网络处理器(network processer，NP)、图形处理器(Graphics Processing Unit，GPU)、神经网络处理器(neural-network processing units，NPU)、数据处理单元(Data Processing Unit，DPU)、微处理器或者一个或多个用于实现本申请方案的集成电路。例如，处理器1501包括专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。PLD例如是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合。

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

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

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

在具体实现中，作为一种实施例，处理器1501可以包括一个或多个CPU，如附图14中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，设备1500可以包括多个处理器，如附图14中所示的处理器1501和处理器1505。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。

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

在一些实施例中，存储器1503用于存储执行本申请方案的程序代码1510，处理器1501可以执行存储器1503中存储的程序代码1510。也即是，设备1500可以通过处理器1501以及存储器1503中的程序代码1510，来实现方法实施例提供的方法。

参见附图15，本申请实施例提供了一种通信系统1600，系统1600包括：客户端设备1601、中继设备1602和服务端设备1603。可选的，客户端设备1601为如附图10所示的客户端设备600或附图13所示的设备900或者附图14所示的设备1500，中继设备1602为如附图11的中继设备700或附图13所示的设备900或者附图14所示的设备1500，服务端设备1603为如附图12的服务端设备800或附图13所示的设备900或者附图14所示的设备1500。

本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。

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

该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件单元的形式实现。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例中方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。还应理解，尽管以下描述使用术语第一、第二等来描述各种元素，但这些元素不应受术语的限制。这些术语只是用于将一元素与另一元素区别分开。例如，在不脱离各种示例的范围的情况下，第一指示信息可以被称为第二指示信息，并且类似地，第二指示信息可以被称为第一指示信息。第一指示信息和第二指示信息都可以是指示信息，并且在某些情况下，可以是单独且不同的指示信息。

本申请中术语“至少一个”的含义是指一个或多个。本文中术语“系统”和“网络”经常可互换使用。

术语“如果”可被解释为意指“当...时”(“when”或“upon”)或“响应于确定”或“响应于检测到”。类似地，根据上下文，短语“如果确定...”或“如果检测到[所陈述的条件或事件]”可被解释为意指“在确定...时”或“响应于确定...”或“在检测到[所陈述的条件或事件]时”或“响应于检测到[所陈述的条件或事件]”。

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

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD)、或者半导体介质(例如固态硬盘)等。

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

以上，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (34)

1.一种文件下载方法，其特征在于，应用于包括客户端设备、中继设备和服务端设备的通信系统，所述方法包括：

所述客户端设备发送请求报文；

所述客户端设备接收所述中继设备发送的应答报文，所述应答报文为所述请求报文的应答，所述应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括目标文件；

所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件。

2.根据权利要求1所述的方法，其特征在于，所述第一指示信息包括：所述目标文件的第一信息，所述第一信息包括以下一项或多项：文件名、版本号、文件类型和文件保存地址。

3.根据权利要求1或2所述的方法，其特征在于，所述请求报文包括第二指示信息，所述第二指示信息用于指示所述客户端设备请求所述目标文件。

4.根据权利要求3所述的方法，其特征在于，所述第二指示信息包括以下一项或多项：文件名、版本号和文件类型。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述请求报文采用下述协议报文之一：动态主机配置协议DHCP协议报文、远程用户拨号认证服务RADIUS报文或基于以太网的点对点协议PPPOE报文。

6.根据权利要求5所述的方法，其特征在于，在所述请求报文为DHCP报文的情况下，所述中继设备为DHCP中继relay设备，所述客户端设备为DHCP客户端设备。

7.根据权利要求6所述的方法，其特征在于，所述请求报文为DHCP发现discover报文，所述应答报文为DHCP提供offer报文；或者，

所述请求报文为DHCP请求request报文，所述应答报文为DHCP确认ACK报文。

8.根据权利要求5所述的方法，其特征在于，在所述请求报文为RADIUS报文的情况下，所述中继设备为RADIUS relay设备，所述客户端设备为RADIUS客户端设备。

9.根据权利要求8所述的方法，其特征在于，所述请求报文为RADIUS接入请求access-request报文，所述应答报文为RADIUS接入成功回应access-accept报文；或者，

所述请求报文为RADIUS计费请求accounting-request报文，所述应答报文为RADIUS计费回应accounting-response报文。

10.根据权利要求5所述的方法，其特征在于，在所述请求报文为PPPOE报文的情况下，所述中继设备为PPPOErelay设备，所述客户端设备为PPPOE客户端设备。

11.根据权利要求10所述的方法，其特征在于，所述请求报文为PPPOE主动发现初始PADI报文，所述应答报文为PPPOE主动发现提供PADO报文；或者，

所述请求报文为PPPOE主动发现请求PADR报文，所述应答报文为PPPOE主动发现会话确认PADS报文。

12.根据权利要求1至11任一项所述的方法，其特征在于，所述应答报文包括第一选项部分，所述第一选项部分包括类型字段以及值字段，所述值字段包括所述第一指示信息，所述类型字段用于标识所述第一选项部分包括所述第一指示信息。

13.根据权利要求3或4所述的方法，其特征在于，所述请求报文包括第二选项部分，所述第二选项部分包括类型字段以及值字段，所述值字段包括所述第二指示信息，所述类型字段用于标识所述第二选项部分包括所述第二指示信息。

14.根据权利要求1至13任一项所述的方法，其特征在于，在所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件之前，所述方法还包括：

所述客户端设备确定所述目标文件的类型与所述客户端设备的类型满足匹配条件。

15.根据权利要求1至14任一项所述的方法，其特征在于，所述目标文件为系统软件或者补丁文件，所述客户端设备根据所述第一指示信息从所述中继设备下载所述目标文件之后，所述方法还包括：

所述客户端设备根据所述系统软件进行升级；或者，

所述客户端设备根据所述补丁文件加载补丁。

16.根据权利要求1至15任一项所述的方法，其特征在于，所述目标文件为所述中继设备从所述服务端设备处获得的。

17.一种文件传输方法，其特征在于，应用于包括客户端设备、中继设备和服务端设备的通信系统，所述方法包括：

所述中继设备接收所述客户端设备发送的第一请求报文；

所述中继设备向所述客户端设备发送第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括目标文件；

响应于所述第一应答报文，所述中继设备向所述客户端设备传输所述目标文件。

18.根据权利要求17所述的方法，其特征在于，所述第一请求报文包括第二指示信息，所述第二指示信息用于指示所述客户端设备请求所述目标文件。

19.根据权利要求17或18所述的方法，其特征在于，所述中继设备向所述客户端设备传输所述目标文件之前，所述方法还包括：

所述中继设备向所述服务端设备发送第二请求报文；

所述中继设备接收所述服务端设备发送的第二应答报文，所述第二应答报文为所述第二请求报文的应答，所述第二应答报文包括第三指示信息，所述第三指示信息用于指示所述服务端设备包括所述目标文件；

所述中继设备根据所述第三指示信息下载所述目标文件。

20.根据权利要求19所述的方法，其特征在于，所述第二请求报文包括第四指示信息，所述第四指示信息用于指示所述中继设备请求所述目标文件。

21.根据权利要求17所述的方法，其特征在于，所述中继设备向所述客户端设备发送第一应答报文之前，所述方法还包括：

所述中继设备根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

22.一种文件传输方法，其特征在于，应用于包括客户端设备、中继设备和服务端设备的通信系统，所述方法包括：

所述服务端设备接收所述中继设备发送的第一请求报文；

所述服务端设备生成第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述服务端设备包括目标文件；

所述服务端设备向所述中继设备发送所述第一应答报文。

23.根据权利要求22所述的方法，其特征在于，所述第一请求报文包括第二指示信息，所述第二指示信息用于指示所述中继设备请求所述目标文件。

24.根据权利要求22所述的方法，其特征在于，所述服务端设备生成第一应答报文之前，所述方法还包括：

所述服务端设备根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

25.一种客户端设备，其特征在于，所述客户端设备包括：

发送单元，用于发送请求报文；

接收单元，用于接收所述中继设备发送的应答报文，所述应答报文为所述请求报文的应答，所述应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括目标文件；

下载单元，用于根据所述第一指示信息从所述中继设备下载所述目标文件。

26.根据权利要求25所述的客户端设备，其特征在于，所述客户端设备还包括：

处理单元，用于确定所述目标文件的类型与所述客户端设备的类型满足匹配条件。

27.根据权利要求25所述的客户端设备，其特征在于，所述目标文件为系统软件或者补丁文件，所述客户端设备还包括：

处理单元，用于根据所述系统软件进行升级；或者，根据所述补丁文件加载补丁。

28.一种中继设备，其特征在于，所述中继设备包括：

接收单元，用于接收客户端设备发送的第一请求报文；

发送单元，用于向所述客户端设备发送第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述中继设备包括目标文件；

传输单元，还用于响应于所述第一应答报文，向所述客户端设备传输所述目标文件。

29.根据权利要求28所述的中继设备，其特征在于，所述发送单元，还用于向所述服务端设备发送第二请求报文；

所述接收单元，还用于接收所述服务端设备发送的第二应答报文，所述第二应答报文为所述第二请求报文的应答，所述第二应答报文包括第三指示信息，所述第三指示信息用于指示所述服务端设备包括所述目标文件；

所述传输单元，还用于根据所述第三指示信息下载所述目标文件。

30.根据权利要求29所述的中继设备，其特征在于，所述第二请求报文包括第四指示信息，所述第四指示信息用于指示所述中继设备请求所述目标文件。

31.根据权利要求28所述的中继设备，其特征在于，所述中继设备还包括：

处理单元，用于根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

32.一种服务端设备，其特征在于，所述服务端设备包括：

接收单元，用于接收中继设备发送的第一请求报文；

处理单元，用于生成第一应答报文，所述第一应答报文为所述第一请求报文的应答，所述第一应答报文包括第一指示信息，所述第一指示信息用于指示所述服务端设备包括目标文件；

发送单元，用于向所述中继设备发送所述第一应答报文。

33.根据权利要求32所述的服务端设备，其特征在于，所述处理单元，还用于根据所述客户端设备的类型确定所述目标文件，所述目标文件的类型与所述客户端设备的类型满足匹配条件。

34.一种通信系统，其特征在于，所述通信系统包括如权利要求25至27中任一项所述的客户端设备、如权利要求28至31中任一项所述的中继设备以及如权利要求32至33中任一项所述的服务端设备。

Images