CN115801298A - 文件传输的方法、系统、设备和存储介质 - Google Patents

Abstract

本申请提供了一种文件传输的方法、系统、设备和存储介质，属于数据传输技术领域。该方法包括：第一端与第二端建立基于QUIC协议的FTP会话，在FTP会话内，第一端基于第一QUIC stream向第二端发送至少一个第一FTP文件。采用本申请，FTP文件传输基于QUIC协议实现，能够在保证安全性的同时，简化建立FTP会话的过程，进而简化文件传输过程。

Description

文件传输的方法、系统、设备和存储介质

本申请要求于2021年09月10日提交的申请号为202111060797.0、发明名称为“一种基于QUIC的文件传输方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及数据传输技术领域，特别涉及一种文件传输的方法、系统、设备和存储介质。

背景技术

文件传输协议(file transfer protocol，FTP)是用于在网络上进行文件传输的一套标准协议，FTP是基于传输控制协议(transmission control protocol，TCP)的客户端(client)/服务端(server)通信模式。在进行文件传输时，client与server会建立控制通道(control channel)和数据通道(data channel)。控制通道用于传输FTP命令，数据通道用于传输目录和文件数据。

在使用FTP传输文件时，传输控制协议采用TCP，在此基础上使用安全传输层协议(transport layer security，TLS)进行密钥协商保证文件传输的安全性，导致文件传输过程比较复杂。

发明内容

本申请提供了一种文件传输的方法、系统、设备和存储介质，能够在保证安全性的同时，简化文件传输过程。技术方案如下：

第一方面，本申请提供了一种文件传输的方法，该方法包括：第一端与第二端建立基于QUIC协议的FTP会话；在FTP会话内，第一端基于第一QUIC流(stream)向第二端发送至少一个第一FTP文件。

本申请所示的方案，第一端与第二端传输文件时，建立基于QUIC协议的FTP会话，在该FTP会话内，第一端使用第一QUIC stream向第二端发送至少一个第一FTP文件，第一QUIC stream指基于QUIC协议的stream，至少一个第一FTP文件包括一个或多个第一FTP文件，第一FTP文件为基于FTP的文件。这样，由于第一端与第二端传输FTP文件时，是基于QUIC协议，不仅能够快速建立传输协议层的连接，而且QUIC高度集成TLS，使得在建立传输协议层的连接时，就完成密钥协商，不需要像TCP一样三次握手，而且也不需要单独使用TLS进行密钥协商，所以能够简化文件传输过程。

在一种可能的实现方式中，第一端与第二端建立基于QUIC协议的FTP会话，包括：第一端与第二端建立第一QUIC连接；第一端基于第一QUIC stream向第二端发送至少一个第一FTP文件，包括：第一端确定第一QUIC连接内的至少一个数据stream；第一端基于至少一个数据stream向第二端发送至少一个第一FTP文件。

本申请所示的方案，第一端与第二端建立第一QUIC连接，第一QUIC连接关联一个FTP会话。第一端在向第二端发送至少一个第一FTP文件前，确定第一QUIC连接内的至少一个数据stream，数据stream是第一QUIC连接内用于传输FTP文件的stream。第一端使用至少一个数据stream向第二端发送至少一个第一FTP文件。这样，能够使用QUIC连接内的stream发送FTP文件。

在一种可能的实现方式中，至少一个数据stream的数目为N，至少一个第一FTP文件的数目为N，N为大于1的整数，第一端基于至少一个数据stream向第二端发送至少一个第一FTP文件，包括：第一端通过N个数据stream向第二端发送N个第一FTP文件，N个第一FTP文件中的第一FTP文件与N个数据stream中的数据stream一一对应。

本申请所示的方案，将待传输的FTP文件映射至QUIC连接内的数据stream，至少一个数据stream的数目为N，在至少一个数据stream的数目与至少一个第一FTP文件的数目相同的情况下，第一端可以使用N个数据stream分别发送N个第一FTP文件，每个数据stream用于发送一个第一FTP文件。

在一种可能的实现方式中，第一端通过N个数据stream向第二端发送N个第一FTP文件，包括：第一端通过N个数据stream向第二端并行发送N个第一FTP文件；或者，第一端通过N个数据stream向第二端串行发送N个第一FTP文件。

本申请所示的方案中，第一端使用N个数据stream向第二端并行发送N个第一FTP文件，这样，能够并行发送N个FTP文件，提升批量文件传输效率。或者第一端使用N个数据stream向第二端串行发送N个第一FTP文件，这样，在一个QUIC连接内，可以串行传输多个FTP文件。

在一种可能的实现方式中，至少一个数据stream为第一数据stream，第一端基于至少一个数据stream向第二端发送至少一个第一FTP文件，包括：第一端通过第一数据stream向第二端串行发送至少一个第一FTP文件。这样，第一端可以使用一个数据stream向第二端串行发送一个第一FTP文件，或者多个第一FTP文件。

在一种可能的实现方式中，目标FTP文件的第一个报文中包括传输目标FTP文件的数据stream的stream标识，第一个报文为目标FTP文件的第一个数据块所在的报文，目标FTP文件为至少一个第一FTP文件中的任一个FTP文件。这样，在目标FTP文件相关的首个报文中携带传输FTP文件的数据stream的stream标识，能够使得第二端将数据stream与FTP文件对应。

在一种可能的实现方式中，该方法还包括：在FTP会话内，第一端基于QUIC控制stream向第二端发送控制信息，控制信息包括N个第一FTP文件与N个数据stream的对应关系。

本申请所示的方案，QUIC控制stream指QUIC连接中的stream，被设置为用于传输控制信息。在第一端向第二端传输多个FTP文件的情况下，第一端可以使用QUIC控制stream向第二端发送控制信息，指示N个第一FTP文件与N个数据stream的对应关系，使得第二端能够将接收到的FTP文件与数据stream对应。

在一种可能的实现方式中，第一QUIC连接还包括至少一个控制stream，至少一个控制stream用于发送控制信息，第一端与第二端建立基于QUIC协议的FTP会话，还包括：第一端通过至少一个控制stream与第二端建立FTP会话。

本申请所示的方案，控制stream与数据stream均是第一QUIC连接内的stream，只不过功能不相同，被设置为传输控制信息的stream称为控制stream，被设置为传输FTP文件的stream称为数据stream。第一端使用至少一个控制stream与第二端建立FTP会话。

在一种可能的实现方式中，第一端与第二端建立基于QUIC协议的FTP会话，还包括：第一端与第二端建立第二QUIC连接，第二QUIC连接包括至少一个控制stream，至少一个控制stream用于发送控制信息；第一端通过至少一个控制stream与第二端建立FTP会话。

本申请所示的方案，第一端与第二端建立第二QUIC连接，第二QUIC连接与第一QUIC连接对应一个FTP会话。第二QUIC连接包括至少一个控制stream，第一端可以使用该至少一个控制stream与第二端建立FTP会话。这样，使用不同QUIC连接内的数据stream与控制stream分别传输FTP文件与控制信息。

在上述方案中，FTP会话内的控制stream和数据stream隔离，具体的，控制stream与数据stream分别为第一QUIC连接内的不同stream，或者，控制stream与数据stream分别为第一QUIC连接和第二QUIC连接内的stream。通过控制stream和数据stream的隔离，控制信息与FTP文件分开发送，能够减少队头阻塞(head-of-line block)的情况发生，即避免FTP文件数据阻塞FTP指令(command)或回复码(Reply Code)的传输。

在一种可能的实现方式中，第一QUIC连接对应一条路径(path)，任一数据stream对应的用户数据报协议(user datagram protocol，UDP)报文与任一控制stream对应的UDP报文不相同；或者，第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。第一QUIC连接可以映射至一条或多条路径，当第一QUIC连接映射至一条路径时，控制信息与FTP文件通过不同的UDP报文发送，当第一QUIC连接映射至多条路径时，控制信息与FTP文件通过不同的路径发送。这样，控制信息与FTP文件分开发送，能够减少head-of-line block的情况发生。

在一种可能的实现方式中，第一QUIC连接和第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。这样，控制信息与FTP文件分开发送，能够减少head-of-line block的情况发生。

在一种可能的实现方式中，当至少一个数据stream的数目为N时，在多条path的数目等于N+1的情况下，N个数据stream对应的path不相同。这样，在控制信息与FTP文件分开发送的基础上，不同的FTP文件使用不同的path，各个FTP文件的传输均不会出现head-of-line block的情况。

在一种可能的实现方式中，通过控制stream发送的控制信息包括文件上传请求和/或文件下载请求。

在一种可能的实现方式中，该方法还包括：在FTP会话内，第一端接收第二端基于第二QUIC stream发送的至少一个第二FTP文件。这样，第一端也能接收FTP文件，而不仅仅是发送FTP文件，在一个FTP会话内，第一端和第二端可以双向传输文件。

在一种可能的实现方式中，第二QUIC stream与第一QUIC stream为相同的流，例如，该stream为双向stream，或者，第二QUIC stream与第一QUIC stream为不同的流，例如，这两个stream为单向stream。这样，可以使用相同的QUIC stream双向传输FTP文件，或者，不同传输方向使用不同QUIC stream传输FTP文件。

在一种可能的实现方式中，该方法还包括：第一端向用户展示至少一个第二FTP文件的接收比例。这样，还能够为用户展示接收比例，用户体验比较好。

在一种可能的实现方式中，第一端和第二端属于一个设备的不同模块；或者，第一端和第二端分别属于不同的设备。这样，同一设备的不同模块可以传输FTP文件，或者不同设备之间可以传输FTP文件。

第二方面，本申请提供了一种文件传输的方法，该方法包括：第二端与第一端建立基于QUIC协议的FTP会话；在FTP会话内，第二端基于QUIC stream接收第一端发送的至少一个FTP文件。

本申请所示的方案，第一端与第二端传输文件时，建立基于QUIC协议的FTP会话，在该FTP会话内，第二端基于QUIC stream接收第一端发送的至少一个FTP文件。这样，由于第一端与第二端传输FTP文件时，是基于QUIC协议，不仅能够快速建立传输协议层的连接，而且QUIC高度集成TLS，使得在建立传输协议层的连接时，就完成密钥协商，不需要像TCP一样三次握手，而且也不需要单独使用TLS进行密钥协商，所以能够简化文件传输过程。

在一种可能的实现方式中，第二端与第一端建立基于QUIC协议的FTP会话，包括：第二端与第一端建立第一QUIC连接，第一QUIC连接包括至少一个数据stream；第二端基于第一QUIC stream接收第一端发送的至少一个FTP文件，包括：第二端基于至少一个数据stream接收第一端发送的至少一个FTP文件。

本申请所示的方案，第二端与第一端建立第一QUIC连接，第一QUIC连接关联一个FTP会话。第二端基于QUIC stream接收第一端发送的至少一个FTP文件。这样，能够使用QUIC连接内的stream接收FTP文件。

在一种可能的实现方式中，至少一个数据stream的数目为N，至少一个FTP文件的数目为N，N为大于1的整数，第二端基于至少一个数据stream接收第一端发送的至少一个FTP文件，包括：第二端通过N个数据stream接收第一端发送的N个FTP文件，N个FTP文件中的FTP文件与N个数据stream中的数据stream一一对应。

本申请所示的方案，将待传输的FTP文件映射至QUIC连接内的数据stream，至少一个数据stream的数目为N，在至少一个数据stream的数目与至少一个FTP文件的数目相同的情况下，第二端可以使用N个数据stream分别接收N个FTP文件，每个数据stream用于接收一个FTP文件。

在一种可能的实现方式中，第二端通过N个数据stream接收第一端发送的N个FTP文件，包括：第二端通过N个数据stream接收第一端并行发送的N个FTP文件；或者，第二端通过N个数据stream接收第一端串行发送的N个FTP文件。

本申请所示的方案，第二端使用N个数据stream接收第一端并行发送的N个FTP文件，这样，能够并行传输N个FTP文件，提升批量文件传输效率。或者第二端使用N个数据stream接收第一端串行发送N个FTP文件，这样，在一个QUIC连接内，可以串行传输多个FTP文件。

在一种可能的实现方式中，至少一个数据stream为第一数据stream，第二端基于至少一个数据stream接收第一端发送的至少一个FTP文件，包括：第二端通过第一数据stream接收第一端串行发送的至少一个FTP文件。这样，第二端可以使用一个数据stream接收第一端串行发送的一个FTP文件，或者多个FTP文件。

在一种可能的实现方式中，该方法还包括：在FTP会话内，第二端基于QUIC控制stream接收第一端发送的控制信息，控制信息包括N个FTP文件与N个数据stream的对应关系。这样，第二端能够获取到N个FTP文件分别使用的N个数据stream。

在一种可能的实现方式中，第一QUIC连接还包括至少一个控制stream，至少一个控制stream用于接收控制信息，第二端与第一端建立基于QUIC协议的FTP会话，还包括：第二端通过至少一个控制stream与第一端建立FTP会话。

本申请所示的方案，控制stream与数据stream均是第一QUIC连接内的stream，只不过功能不相同，被设置为传输控制信息的stream为控制stream，被设置为传输FTP文件的stream为数据stream。第二端使用至少一个控制stream与第一端建立FTP会话。

在一种可能的实现方式中，第二端与第一端建立基于QUIC协议的FTP会话，还包括：第二端与第一端建立第二QUIC连接，第二QUIC连接包括至少一个控制stream，至少一个控制stream用于发送控制信息；第二端通过至少一个控制stream与第一端建立FTP会话。

本申请所示的方案，第二端与第一端建立第二QUIC连接，第二QUIC连接与第一QUIC连接对应一个FTP会话。第二QUIC连接包括至少一个控制stream，第二端可以使用该至少一个控制stream与第一端建立FTP会话。这样，使用不同QUIC连接内的数据stream与控制stream分别传输FTP文件与控制信息。

在一种可能的实现方式中，第一QUIC连接对应一条path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。这样，控制信息与FTP文件分开发送，能够减少head-of-line block的情况发生。

在一种可能的实现方式中，第一QUIC和第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。这样，控制信息与FTP文件分开发送，能够减少head-of-line block的情况发生。

在一种可能的实现方式中，当至少一个数据stream的数目为N时，在多条path的数目等于N+1的情况下，N个数据stream对应的path不相同。这样，在控制信息与FTP文件分开发送的基础上，不同的FTP文件使用不同的path，各个FTP文件的传输均不会出现head-of-line block的情况。

在一种可能的实现方式中，至少一个FTP文件中目标FTP文件的第一个报文中包括传输目标FTP文件的目标数据stream的stream标识，第一个报文为目标FTP文件的第一个数据块所在的报文。这样，在报文中携带传输FTP文件的数据stream的stream标识，能够使得第二端将数据stream与FTP文件对应。

在一种可能的实现方式中，第二端基于至少一个数据stream接收第一端发送的至少一个FTP文件，包括：第二端基于接收到的第一个报文，获得目标数据stream对应的实例；第二端将接收到的目标FTP文件的数据写入该实例对应的缓存区；第二端根据该缓存区的数据获得目标FTP文件。

本申请所示的方案，第二端使用接收到的第一个报文中stream标识，确定目标数据stream对应的实例，该实例为stream实例，该实例对应有缓存区。第二端可以将接收到的目标FTP文件的数据写入该实例对应的缓存区，第二端将缓存区中的连续数据，确定为目标FTP文件。这样，能够使得接收到的数据对应准确的FTP文件。

在一种可能的实现方式中，该方法还包括：第二端向用户展示至少一个FTP文件的接收比例。这样，可以及时了解传输情况，用户体验比较好。

第三方面，本申请提供了一种文件传输的装置，所述装置应用于第一端，所述装置包括：

会话建立模块，用于与第二端建立基于QUIC协议的FTP会话；

发送模块，用于在所述FTP会话内，基于第一QUIC stream向所述第二端发送至少一个第一FTP文件。

在一种可能的实现方式中，所述会话建立模块，用于与所述第二端建立第一QUIC连接；

所述发送模块，用于确定所述第一QUIC连接内的至少一个数据stream；基于所述至少一个数据stream向所述第二端发送所述至少一个第一FTP文件。

在一种可能的实现方式中，所述至少一个数据stream的数目为N，所述至少一个第一FTP文件的数目为所述N，所述N为大于1的整数，所述发送模块，用于通过N个数据stream向所述第二端发送N个第一FTP文件，所述N个第一FTP文件中的第一FTP文件与所述N个数据stream中的数据stream一一对应。

在一种可能的实现方式中，所述发送模块，用于通过所述N个数据stream向所述第二端并行发送所述N个第一FTP文件；或者，通过所述N个数据stream向所述第二端串行发送所述N个第一FTP文件。

在一种可能的实现方式中，所述至少一个数据stream为第一数据stream，所述发送模块，用于通过所述第一数据stream向所述第二端串行发送所述至少一个第一FTP文件。

在一种可能的实现方式中，目标FTP文件的第一个报文中包括传输所述目标FTP文件的数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文，所述目标FTP文件为所述至少一个第一FTP文件中的任一个FTP文件。

在一种可能的实现方式中，所述发送模块，还用于在所述FTP会话内，基于QUIC控制stream向所述第二端发送控制信息，所述控制信息包括所述N个第一FTP文件与所述N个数据stream的对应关系。

在一种可能的实现方式中，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于发送控制信息，所述会话建立模块，还用于通过所述至少一个控制stream与所述第二端建立FTP会话。

在一种可能的实现方式中，所述会话建立模块，还用于与所述第二端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；通过所述至少一个控制stream与所述第二端建立FTP会话。

在一种可能的实现方式中，所述第一QUIC连接对应一条path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，所述第一QUIC连接和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，所述N个数据stream对应的path不相同。

在一种可能的实现方式中，所述装置还包括：接收模块，用于在所述FTP会话内，接收所述第二端基于第二QUIC stream发送的至少一个第二FTP文件。

在一种可能的实现方式中，所述第二QUIC stream与所述第一QUIC stream为相同的流，或者，所述第二QUIC stream与所述第一QUIC stream为不同的流。

在一种可能的实现方式中，所述第一端和所述第二端属于一个设备的不同模块；或者，所述第一端和所述第二端分别属于不同的设备。

第四方面，本申请提供了一种文件传输的装置，所述装置应用于第二端，所述装置包括：建立模块，用于与第一端建立基于QUIC协议的FTP会话；

接收模块，用于在所述FTP会话内，基于QUIC stream接收所述第一端发送的至少一个FTP文件。

在一种可能的实现方式中，所述建立模块，用于与所述第一端建立第一QUIC连接，所述第一QUIC连接包括至少一个数据stream；

所述接收模块，用于基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件。

在一种可能的实现方式中，所述至少一个数据stream的数目为N，所述至少一个FTP文件的数目为所述N，所述N为大于1的整数，所述接收模块，用于通过N个数据stream接收所述第一端发送的N个FTP文件，所述N个FTP文件中的第一FTP文件与所述N个数据stream中的数据stream一一对应。

在一种可能的实现方式中，所述接收模块，用于通过所述N个数据stream接收所述第一端并行发送的所述N个FTP文件；或者，通过所述N个数据stream接收所述第一端串行发送的所述N个FTP文件。

在一种可能的实现方式中，所述至少一个数据stream为第一数据stream，所述接收模块，用于通过所述第一数据stream接收所述第一端串行发送的所述至少一个FTP文件。

在一种可能的实现方式中，所述接收模块，还用于在所述FTP会话内，基于QUIC控制stream接收所述第一端发送的控制信息，所述控制信息包括N个FTP文件与所述N个数据stream的对应关系。

在一种可能的实现方式中，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于接收控制信息，所述建立模块，还用于通过所述至少一个控制stream与所述第一端建立FTP会话。

在一种可能的实现方式中，所述建立模块，还用于与所述第一端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；通过所述至少一个控制stream与所述第一端建立FTP会话。

在一种可能的实现方式中，所述第一QUIC连接对应一条path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，所述第一QUIC和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，所述N个数据stream对应的path不相同。

在一种可能的实现方式中，所述至少一个FTP文件中目标FTP文件的第一个报文中包括传输所述目标FTP文件的目标数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文。

在一种可能的实现方式中，所述接收模块，用于基于接收到的所述第一个报文，获得所述目标数据stream对应的实例；将接收到的所述目标FTP文件的数据写入所述实例对应的缓存区；根据所述缓存区的数据获得所述目标FTP文件。

在一种可能的实现方式中，所述装置还包括：展示模块，用于向用户展示所述至少一个FTP文件的接收比例。

第五方面，本申请提供了一种通信设备，所述通信设备包括处理器和存储器，所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令，使得所述通信设备执行上述第一方面或第一方面任一种可选方式所提供的文件传输的方法。

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

第七方面，本申请提供了一种通信设备，所述通信设备包括处理器和存储器，所述存储器中存储有计算机指令；所述处理器用于执行所述计算机指令，使得所述通信设备执行上述第二方面或第二方面任一种可选方式所提供的文件传输的方法。

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

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

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

第十一方面，本申请一种文件传输的系统，所述系统包括第一端和第二端，其中，所述第一端，用于执行上述第一方面或第一方面任一种可选方式所提供的文件传输的方法；所述第二端，用于执行上述第二方面或第二方面任一种可选方式所提供的文件传输的方法。

附图说明

图1是本申请一个示例性的实施例提供的一种QUIC协议栈的格式示意图；

图2是本申请一个示例性的实施例提供的一种多路径的场景示意图；

图3是本申请一个示例性的实施例提供的一种多路径的实现架构示意图；

图4是本申请一个示例性的实施例提供的一种FTP实现原理示意图；

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

图6是本申请一个示例性的实施例提供的一种QFTP协议栈的格式示意图；

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

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

图9是本申请一个示例性的实施例提供的一种建立基于QUIC协议的FTP会话的流程示意图；

图10是本申请一个示例性的实施例提供的一种get操作的流程示意图；

图11是本申请一个示例性的实施例提供的一种put操作的流程示意图；

图12是本申请一个示例性的实施例提供的一种mget操作的流程示意图；

图13是本申请一个示例性的实施例提供的一种mput操作的流程示意图；

图14是本申请一个示例性的实施例提供的一种文件传输的装置的结构示意图；

图15是本申请一个示例性的实施例提供的一种文件传输的装置的结构示意图。

具体实施方式

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

下面对本申请实施例涉及的一些术语概念做解释说明。

(1)QUIC

QUIC是一种基于UDP的可靠的安全传输协议。QUIC这个术语最初是快速UDP网络连接(Quick UDP Internet Connections)的缩写，但是国际互联网工程任务组(internetengineering task force，IETF)标准化时，不再使用这个缩写，认为QUIC是一个名称，并不是一个首字母缩写(QUIC is a name,not an acronym)，具体解释可参见征求意见(request for comments，RFC)9000。

图1示出了QUIC的协议栈，QUIC运行在UDP之上，与TLS1.3高度集成，提供了与TCP类似的可靠性、拥塞控制等功能。在图1的左侧是传统的超文本传输协议(hyper texttransfer protocol，HTTP)协议栈，从上到下依次是应用(application)、TLS、TCP和互联网协议(internet protocol，IP)，application是HTTP/1.1、HTTP/2或边界网关协议(bordergateway protocol，BGP)。在图1的右侧是QUIC协议的协议栈，从上到下依次是application、QUIC、UDP和IP，application是HTTP/3或BGP，其中，QUIC中集成有TLS1.3。

QUIC除了提供与TCP类似的可靠性、拥塞控制等功能，此外，QUIC还提供了如下一些增强功能：

a)流复用(stream multiplexing)，指的是在单个QUIC连接(connection)中可以同时传输多个字节流，每个字节流称为stream。其中，QUIC连接用于在两个主体之间建立数据传输所需的共享状态。例如，提供了数据传输所需的安全上下文(如身份认证、机密性保护和安全性保护)，安全上下文也可以称为是连接信息。stream用于在QUIC连接所提供的安全上下文中提供数据传输服务。

QUIC连接使用连接标识(connection ID)来唯一标识，ID的英文全称为identity，即每个QUIC连接的connection ID不相同。在一个QUIC连接内，每个stream使用stream标识来唯一标识。stream标识的长度为64比特(bit)，其中，最低2bit标识stream的类型。为了简单起见，可以认为stream标识包含两个部分，即stream的类型(最低2bit)和stream的索引(index)(剩余的62bit)，这说明每个connection可以创建4种不同类型的stream，4种不同类型的stream分别为客户端创建的双向stream类型、服务端创建的双向stream类型、客户端创建的单向stream类型和服务端创建的单向stream类型，表一示出了4种不同类型的stream，客户端创建的双向stream类型的stream ID最低两位是00，服务端创建的双向stream类型的stream ID最低两位是01，客户端创建的单向stream类型的stream ID最低两位是02，服务端创建的单向stream类型的stream ID最低两位是03。每种类型的stream可创建的stream的数量为2⁶²-1，每个stream可以独立为一个应用提供数据传输服务。双向stream类型的stream能够双向传输数据，例如，客户端使用双向stream类型的stream向服务端发送数据，服务端也是用该stream向客户端发送数据。单向stream类型的stream能够单向传输数据。例如，客户端使用单向stream类型的stream向服务端发送数据，服务端使用另一单向stream类型的stream向客户端发送数据。

表一

stream ID的比特位	Stream类型
		0x00	客户端创建的双向stream类型
0x01	服务端创建的双向stream类型
		0x02	客户端创建的单向stream类型
0x03	服务端创建的单向stream类型

本申请中的stream不同于通常的流(flow)。本申请中的stream是QUIC连接内的字节流，使用stream ID标识，而通常的flow主要是针对转发层面而言。不同的flow可以使用不同的五元组标识，还可以使用不同的三元组标识，五元组包括源地址、目的地址、协议、源端口和目的端口，三元组包括源地址、目的地址和协议。

在转发层面不同的flow在被转发时，可以从不同的端口输出。例如，转发设备将第一五元组标识的flow从转发设备的第一端口输出，将第二五元组标识的flow从转发设备的第二端口输出。

b)路径(Path)，是指客户端与服务端之间的一条传输路由，可以由五元组标识，五元组包括源地址，目的地址、源端口、目的端口和协议。对于QUIC而言，源地址和目的地址均可以是IP地址，五元组中的协议可以是UDP。

在QUIC中，path存在单活路径(single-active path)和多活路径(multi-activepath)，multi-active path也能认为是QUIC multi-active path，multi-active path也能简称为多路径(multi-path)。单活路径指在在一个QUIC连接中，任意时刻只允许一条path传输数据。多活路径指在一个QUIC连接中，一个时刻多个path上能够同时传输数据，多活路径可以更充分的利用网络资源，得到更好的传输性能。例如，图2示出了多路径的场景示意图，用户终端(user equipment，UE)同时接入移动网络和蜂窝网(cellular network)，移动网络包括第四代通信技术(the 4Generation mobile communication technology，4G)或第五代通信技术(the 5Generation mobile communication technology，5G)等，蜂窝网包括无线保真(wireless-fidelity，WIFI)等。UE的客户端在移动网络和WIFI下使用不同的IP地址访问服务端，UE在移动网络下访问服务端的五元组为(1.1.1.1,xx,UDP,3.3.3.3,zz)，UE在WIFI下访问服务端的五元组为(2.2.2.2,yy,UDP,3.3.3.3,zz)，其中，1.1.1.1和2.2.2.2为UE的IP地址，3.3.3.3为服务端的IP地址，xx和yy为客户端的UDP端口，zz为服务端的UDP端口。这样，使用多路径，在客户端和服务端之间仅建立一个QUIC连接，就能在多条path上同时并行传输数据。

在QUIC中，数据传输可以通过stream承载，path是数据传输路径，stream承载的数据需要与path关联，以实现数据传输。可选地，在QUIC中，可以通过multi-path调度器将stream的数据与path关联实现数据的发送。图3示出了多路径的实现架构示意图。如图3所示，3条stream将应用的数据传输给multi-path调度器，multi-path调度器将3条stream传输的数据调度至两条path进行传输。

示例性的，multi-path调度器将stream发送的数据与path关联的方式包括如下几种：

业务疏导(traffic streering)，用于在创建一条新的stream时，multi-path调度器根据策略将stream与path关联。例如，stream与path之间是1:1、P：1或P：Q的映射关系，P和Q均为大于1的正整数，在stream与path之间是N：M的映射关系时，multi-path调度器可以使用path当前的负载情况选择负载较少的path发送stream的数据。

业务交换(traffic switching)，用于实现各条path的负载均衡。例如，在QUIC运行过程中，若某条path的负载或时延发生变化，multi-path调度器可以将与该path关联的stream的数据调整到其它path，以实现各条path的负载均衡。

业务分流(traffic splitting)，用于将大量待发送数据分流到多条path。例如，某个stream的数据比较多，且要求比较高的传输性能，可以使用多条path同时传输该stream的数据，即stream与path的比例是1：P。

需要说明的，上述仅是一种将stream的数据与path关联的方案，本申请实施例对此不进行限定。

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

FTP是TCP/IP协议组中的协议之一，是基于TCP使用客户端/服务端通信的模式。FTP使用双通道分别传输控制信息与文件的数据，双通道包括控制通道(control channel)和数据通道(data channel)，控制通道用于传输控制信息，数据通道用于传输文件的数据，数据通道在有数据传输时创建，无数据传输时关闭。控制信息主要包括两类控制信息，两类控制信息分别为FTP命令(command)和FTP应答码(Reply code)。两类控制信息都编码为ASCII字符串，使用回车换行符作为结束标志。示例性，FTP command的格式为<cmd><参数(parameters)>，FTP Reply code的格式为<编码(code)><描述(description)>。

FTP的实现原理为：图4示出了FTP的实现原理，在默认情况下FTP协议使用TCP端口中的端口20和端口21两个端口，其中，端口20用于传输文件的数据，端口21用于传输控制信息，但是否使用端口20作为传输数据的端口与FTP创建数据通道的方式有关系，若客户端使用主动模式(active mode)创建数据通道，则数据传输端口是端口20，若客户端使用被动模式(passive mode)创建数据通道，则数据传输端口由客户端和服务端协商获得。

示例性的，建立控制通道的过程为：服务端在TCP端口21上监听，客户端连接该端口21，建立控制通道。控制通道在建立后始终存在。

通过主动模式建立数据通道的过程为：客户端首先在本地打开某个地址和端口，该地址和端口是随机的，然后客户端使用PORT命令将该地址和端口通告给服务端。服务端使用TCP端口20连接该地址和端口，建立数据通道。

通过被动模式建立数据通道的过程为：客户端向服务端发送PASV命令，请求服务端的监听address/port(称为是协商端口(negotiated port))。服务端分配一个随机端口(random port)作为negotiated port，然后使用FTP Reply Code 227响应监听该address和negotiated port，客户端连接到该address和negotiated port，建立数据通道。

(3)FTP安全扩展

在RFC959中，FTP的控制通道和数据通道都是明文传输的，这样，即使客户端使用用户名/密码(user name/password，USER/PASS)命令进行了密码认证，攻击者也能通过截取报文来获得用户名和认证密码。为此，RFC2228定义了FTP安全扩展规范，该规范中定义了几个新的FTP命令，从而支持对控制通道和数据通道进行认证、完整性和机密性保护。例如，新的FTP命令包括AUTH命令、ADAT命令和CCC命令等，AUTH命令用于在客户端和服务端间协商安全机制，ADAT命令用于传递AUTH命令所协商的安全机制相关的安全数据，CCC命令用于关闭安全保护机制。但是RFC2228所定义的安全机制，并不能保护所有的控制信息和文件的数据，这是由于只有在通过初始用户名和密码认证后，客户端才能发送AUTH命令，这样，使得控制通道和数据通道不能全面安全保护。

在RFC2228的基础上，RFC2773定义了用于控制通道和数据通道的加密算法，使用TLS1.0来保护FTP的控制通道和数据通道，但是仍然存在一些不足：不能提供对FTP会话的整个操作过程提供全面保护，而且也需要使用AUTH TLS命令进行协商，该过程称为是显式安全(explicit security)。

在本申请实施例中，FTP的命令是标准RFC959中定义的标记符。

(4)FTP的常见操作

FTP的常见操作包括获取(get)操作、上传(put)操作、下载多个文件(mget)操作和上传多个文件(mput)操作。get操作用于客户端从服务端下载一个文件的数据。put操作用于客户端向服务端上传一个文件的数据。mget操作用于客户端从服务端下载多个文件的数据。mput操作用于客户端向服务端上传多个文件的数据。

(5)FTP的批量文件传输

FTP使用APPE命令、RETR命令、STOR命令或STOU命令来启动文件传输，包括两个传输方向，一个传输方向为客户端至服务端的方向，另一个传输方向为服务端向客户端的传输方向，但是FTP每次都只能传输一个文件。其中，APPE命令用于指示使用追加的方式上传一个文件，RETR命令用于指示下载一个文件，STOR命令用于指示用覆盖的方式上传一个文件，STOU命令用于指示唯一性上传文件。

在当前的FTP实现中，通常都实现了同时传输多个文件的操作：mget操作和mput操作。mget操作和mput操作的内部实现原理为：将mget操作和mput操作分解为若干APPE命令、RETR命令、STOR命令和STOU命令，在数据通道上，依次对每个文件进行传输。这样，仅有一个数据通道传输文件，而且在该数据通道中传输文件时，是在当前文件的数据传输完成后，才能开始传输下一个文件，导致批量传输文件的效率比较低。

目前文件传输的传输控制协议是TCP，为了保证文件传输安全性，还需要单独使用TLS进行密钥协商保证文件传输的安全性，导致文件传输过程比较复杂，而且使用TLS也不能对FTP会话的整个操作过程进行全面保护。而且由于TCP不支持流复用，在任意时刻每个TCP连接只能传输一个字节流，所以还存在批量传输文件效率较低的问题。基于此，本申请实施例使用QUIC作为FTP的传输层协议，QUIC连接可以基于0个往返时间(round-triptime，RTT)或者1个RTT建立，并且QUIC协议中高度集成有TLS1.3，所以在建立QUIC连接时，即能使用TLS1.3进行安全性保护，使得不需要像TCP一样三次握手(即3个RTT)建立连接后，再使用TLS进行密钥协商，所以不仅能够简化文件传输过程，而且还能实现可靠数据传输服务，为FTP的控制通道和数据通道提供了全面的安全性保护。而且，利用QUIC的流复用和多路径传输能力，实现并行的文件传输，从而提升FTP批量传输文件的效率。

在本申请实施例中，文件传输基于FTP，后续将传输的文件称为是FTP文件。

接下来介绍本申请实施例的执行主体。

本申请实施例的执行主体可以是第一端和/或第二端。可选地，第一端是硬件设备，该硬件设备是通信设备，通信设备是主机、移动终端、服务器等。可选地，第一端是一个软件装置，如运行在硬件装置上的一套软件程序。

可选地，第二端是硬件设备，该硬件设备是通信设备，通信设备是主机、移动终端、服务器等。可选地，第二端是一个软件装置，如运行在硬件装置上的一套软件程序。例如，第一端为客户端，第二端为服务端。

需要说明的是，第一端既可以作为数据发送端，也可以作为数据接收端，第二端既可以作为数据发送端，也可以作为数据接收端。例如，第一端在作为FTP文件的数据发送端时，第二端作为FTP文件的数据接收端。第一端在作为FTP文件的数据接收端时，第二端作为FTP文件的数据发送端。

还需要说明的是，第一端和第二端可以属于一个设备的不同模块，第一端和第二端均是使用标准的协议，在传输文件时不会判断是设备内部的传输还是设备间的传输，而是直接使用设备间的传输方式。示例性的，第一端和第二端分别为一个设备中的两个不同进程；第一端和第二端分别为一个设备中的两个不同容器；第一端和第二端分别为一个设备中的两个不同虚拟机等。第一端和第二端分别为交换机中的主控板和业务板等。

第一端和第二端也可以分别属于两个不同的设备，例如，第一端为用户终端，第二端为服务器。再例如，第一端为服务器，第二端为用户终端等。

在第一端或第二端是硬件设备时，图5示出了设备的结构示意图。设备500包括至少一个处理器501、通信总线502、存储器503以及至少一个网络接口504。

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

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

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

可选地，存储器503用于保存文件的数据等。

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

在具体实现中，作为一种示例，处理器501可以包括一个或多个CPU。

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

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

在一些实施例中，存储器503用于存储执行本申请中文件传输的程序代码5031，处理器501执行存储器503中存储的程序代码5031。也即是，设备500可以通过处理器501以及存储器503中的程序代码5031，来实现方法实施例提供的文件传输的方法。

接下来描述本申请实施例中QUIC协议作为FTP的传输层协议的协议栈。

在本申请实施例中，假设QUIC协议作为FTP的传输层协议用英文表示为FTP overQUIC，简称为QFTP。图6提供了QFTP的协议栈。该协议栈从下到上为网际协议版本4(internet protocol version 4，IPv4)或网际协议版本6(internet protocol version6，IPv6)、UDP、QUIC传输层和TLS1.3握手(Handshake)、TLS1.3警报(Alerts)和FTP。其中，IPv4或IPv6属于网络层，UDP和QUIC属于传输层，FTP属于应用层，TLS1.3 Handshake和TLS1.3 Alerts集成在QUIC。

目前UDP端口20和21已经分配给FTP，并且已经分配应用层协议协商(applicationlayer protocol negotiation，ALPN)＝“ftp”给FTP，因此，可以使用UDP端口20、端口21和ALPN＝“ftp”组合来唯一标识QFTP报文。

在描述文件传输的流程之前，首先介绍stream实例与stream的关系，一个stream对应有一个stream实例，该stream实例是分布性实体，同时分布在第一端和第二端，在全局范围内stream实例使用(connection ID，stream ID)唯一标识，在一个connection范围内，使用stream ID唯一标识。stream实例用于传输一个有序的字节流。每个stream实例类似于stream数据结构中的一个节点，该数据结构为指定connection实例的一个内部数据结构，connection实例也是QUIC connection的分布性实体，同时分布在第一端和第二端。在创建stream实例时，在该数据结构中添加一个节点，在删除stream实例时，从该数据结构中删除该stream实例对应的节点。在该stream实例对应的节点上，维护了所属connection实例的connection ID、stream类型、stream标识、接收缓存区、发送缓存区和运行状态等数据。

接下来描述FTP中的控制通道和数据通道与QUIC连接的映射关系。

在FTP中包括控制通道和数据通道，其中，控制通道传输的是双向字节流，客户端向服务端的方向传输的是FTP command，服务端向客户端的方向传输的是FTP Reply Code。数据通道传输的是单向字节流，对于put操作或mput操作，FTP文件从客户端传输至服务端，对于get操作或mget操作，FTP文件从服务端传输至客户端。

FTP采用控制通道和数据通道的主要目的是为了避免head-of-line block，即为了避免FTP文件阻塞FTP command和FTP Reply code。FTP中的head-of-line block，主要包括两方面的阻塞，其中，一方面是控制通道与数据通道的阻塞，另一方面是数据通道内部的阻塞。

控制通道与数据通道阻塞的情况下，控制信息与FTP文件使用同一个通道传输，FTP文件的数据量与控制信息相比，FTP文件的数据量通常会大很多，因此，控制信息可获得的调度比例比较低。另外，FTP文件在传输过程中丢失，QUIC的传输可靠性机制将导致FTP文件的数据接收端的QUIC必须在接收到重传的FTP文件后，才会向发送端的QUIC返回已经接收到的FTP文件的FTP command或FTP Reply code。这两种阻塞的问题均会导致FTPcommand或FTP Reply code具有较大的传输时延，从而导致用户的体验比较差。

数据通道内部的阻塞指文件传输阻塞，目前对于大多数FTP实现而言，通常只采用一个数据通道，因此，在执行mput操作或mget操作时，由于TCP不支持流复用，即在任意时刻，每个TCP连接只能传输一个字节流，所以只能使用串行方式逐一传输FTP文件，导致FTP文件传输性能低下。

本申请实施例中，对于基于QUIC协议的FTP会话而言，利用QUIC的streammultiplexing和multi-path等机制，实现不同程度的数据隔离，减少head-of-line block。

1)对于stream multiplexing的机制，在基于QUIC协议的FTP会话中，也需要创建两类stream，即创建两类stream实例。其中，一类stream用于传输FTP的控制通道所传输的控制信息，简称为控制stream，对应的stream实例称为是控制stream实例；另一类stream用于传输FTP的数据通道所传输的FTP文件，简称为数据stream，对应的stream实例称为是数据stream实例。需要说明的是，这两类stream本质上没有区别，只不过是分别被设置为传输FTP文件和控制信息。

示例性的，在每个基于QUIC协议的FTP会话中，只存在唯一的控制stream。控制stream与该FTP会话具有完全相同的生命周期，也就是说，在创建该FTP会话时，创建控制stream，在关闭该FTP会话时，删除控制stream。此处，删除控制stream认为是客户端和服务端删除控制stream实例。

在基于QUIC协议的FTP会话中，客户端为主动方，服务端为被动方。例如，客户端请求从服务端下载FTP文件，客户端向服务端上传FTP文件等。这样，控制stream由客户端初始创建，stream类型为0(表示客户端创建的双向stream)。由于控制stream是QUIC连接内创建的第一个stream，因此，stream的索引为0(这是由于QUIC要求每个stream类型的stream索引都是从0开始，逐一单调递增)，对应的二进制数值为b000。客户端在创建控制stream时，实质上创建控制stream实例，服务端在接收到第一个stream标识中索引为0的流(STREAM)帧时，在本地创建控制stream实例，客户端和服务端创建的控制stream实例是一个stream实例的分布性实体。

示例性的，在每个基于QUIC协议的FTP会话中，控制stream可以是传输控制信息的特定stream，可选地，控制stream的stream标识可以是指定stream标识。或者，在每个基于QUIC协议的FTP会话中，控制stream使用指定类型的字段值标识。从而，FTP会话的客户端和服务端均可以通过指定的stream标识或指定类型的字段值标识来识别控制stream。

示例性的，在每个基于QUIC协议的FTP会话中，存在多条控制stream，每条控制stream与该FTP会话具有相同的生命周期。在基于QUIC协议的FTP会话中，客户端为主动方，服务端为被动方，客户端创建一条控制stream，服务端第一次接收到客户端使用该控制stream发送的控制信息后，服务端创建另一条控制stream，用于回复客户端发送的控制信息。此种情况下，控制stream可以是单向stream。

示例性的，对于传输的每个FTP文件，都会对应创建一个数据stream，也就是说，传输的FTP文件的数目和数据stream的数目之间是1:1的映射关系。数据stream是按照需要创建和删除的。例如，在开始传输FTP文件时，需要创建对应的数据stream，在完成FTP文件传输后，可以立即删除对应的数据stream。一个数据stream在客户端和服务端分别对应有数据stream实例。文件发送端在创建数据stream时，实质上创建数据stream实例，文件接收端在接收到本地未对应有数据stream实例的STREAM帧时，在本地创建数据stream实例。STREAM帧中包括stream标识，使用该stream标识即可确定在本地是否对应有stream实例。

示例性的，对于传输的多个FTP文件，对应一个数据stream，也就是说，多个FTP文件使用一个数据stream传输。在此种情况下，第一端使用一个数据stream向第二端传输多个FTP文件时，第一端每传输完一个FTP文件，通知第二端开始传输第二个FTP文件，使得第二端不会将多个FTP文件混淆。

示例性的，对于传输的单个FTP文件，对应多个数据stream，也就是说，一个FTP文件使用多个数据stream传输。在此种情况下，可以将单个FTP文件切分为多个子文件，每个子文件对应一个数据stream。第一端可以通知多个子文件的顺序给第二端，第二端在接收到多个子文件后，将多个子文件进行拼接，获得完整的FTP文件。

需要说明的是，FTP文件是单向传输的，因此，数据stream可能由客户端创建，也可能由服务端创建。例如，数据stream由客户端创建时，对应于客户端向服务端传输FTP文件，即对应于put操作或者mput操作。数据stream由服务端创建时，对应于客户端请求从服务端下载FTP文件，即对应于get操作或者mget操作。在QUIC协议层面，数据stream既可以是单向stream，也可以是双向stream，本申请实施例不做限定。

对于mput操作或者mget操作，由于存在多个FTP文件的同时传输，所以有可能会创建多个数据stream。为了防止FTP文件的数据混淆，客户端和服务端对数据stream与FTP文件的对应关系也应达成一致。此过程可参见后文中的描述，此处不再赘述。

示例性的，一个FTP会话中QUIC连接的数目不同时，控制stream与数据stream所属的QUIC连接也有可能不相同，QUIC连接映射FTP中的控制通道和数据通道的方式不相同，具体方案如下。

方案一，使用两个QUIC连接分别映射控制通道和数据通道。

采用与FTP类似的方案，对于单个基于QUIC协议的FTP会话，创建两个QUIC连接。在其中一个QUIC连接中创建控制stream，在另一个QUIC连接中创建数据stream。在最大化吞吐量的情况下，单个UDP报文中应该包含尽可能少的数据stream对应的FTP文件，以便将head-of-line block降低到最低程度。此处UDP报文是基于QUIC协议的UDP报文，UDP报文中包括一个或多个QUIC报文，每个QUIC报文中包括一个或多个STREAM帧。

需要说明的是，在单个基于QUIC协议的FTP会话内关联两个QUIC连接的情况下，可以是在FTP会话层面管理两个QUIC连接。

还需要说明的是，本申请实施例中，吞吐量是指单位时间内第一端和第二端之间成功传送数据的数据量。

方案二，使用一个QUIC连接内不同的stream映射控制通道和数据通道。

在单个基于QUIC协议的FTP会话中，只建立一个QUIC连接，所有的stream映射到一条path上。

为了获得尽可能大的吞吐量，在单个UDP报文中携带尽可能多的数据，因此单个UDP报文中有可能会包括多个stream对应的FTP文件，但是同时为了避免head-of-lineblock，不同的stream对应的FTP文件应该封装在不同的UDP报文中，因此权衡二者的要求，存在如下策略：对于控制stream，使用独立的UDP报文，并且对于数据stream，在保证最大吞吐量的情况下，单个UDP报文中应该包含尽可能少的数据stream对应的FTP文件。此处UDP报文是基于QUIC协议的UDP报文，UDP报文中包括一个或多个QUIC报文，每个QUIC报文中包括一个或多个STREAM帧。

采用方案二，只需要创建一个QUIC连接，相比目前的FTP能够减少一个连接资源的开销，即减少一个IP地址和一个端口号的开销，相应的也无需使用FTP的PORT或PASV通告数据通道的IP地址或端口号。

2)对于multi-path机制，使用不同path映射控制通道和数据通道。

在QUIC支持multi-path的情况下，可以将控制通道和数据通道映射为不同的path。对于单个基于QUIC协议的FTP会话，只创建一个QUIC连接，根据可用path资源的情况，可以创建多条path，每条path使用一个五元组标识。例如，若同时传输N个FTP文件，需要创建N个数据stream，若存在Q个path资源，可以创建P条path，其中P小于或等于Q。

示例性的，若P＝N+1，则可以将控制stream和每个数据stream分别映射到一条path，即每个stream对应的数据使用一条path传输，此时由于所有stream之间不存在任何head-of-line block问题，所以能够获得最佳的传输性能。若P大于或等于2，且P小于N+1，则可以将控制stream映射到一条path，而将数据stream映射到其它的path，每个数据stream独占一条path，或者与其它数据stream共享一条path。若P等于1，则采用方案二的实现方式。

此处需要说明的是，若采用multi-path机制，需要QUIC协议支持multi-path模式，且存在较多的path资源开销。

接下来结合图7描述第一端向第二端传输文件的流程。第一端为文件传输的数据发送端，第二端为文件传输的数据接收端。第一端为客户端，第二端为服务端，或者第一端为服务端，第二端为客户端。具体如下：

步骤701，第一端与第二端建立基于QUIC协议的FTP会话。

在本实施例中，第一端与第二端传输FTP文件之前，第一端与第二端建立QUIC连接，然后再基于该QUIC连接建立FTP会话。

步骤702，在FTP会话内，第一端基于第一QUIC stream向第二端发送至少一个第一FTP文件。

其中，第一QUIC stream是QUIC连接内的stream。

在本实施例中，在步骤701建立的FTP会话内，第一端使用QUIC连接，向第二端发送至少一个第一FTP文件。

接下来结合图8描述第二端接收第一端传输的FTP文件的流程。具体如下：

步骤801，第二端与第一端建立基于QUIC协议的FTP会话。

在本实施例中，第二端与第一端建立QUIC连接，然后再基于该QUIC连接，建立FTP会话。

步骤802，在FTP会话内，第二端基于第一QUIC stream接收第一端发送的至少一个FTP文件。

在本实施例中，在步骤801建立的FTP会话内，第二端使用QUIC连接，接收第一端发送的至少一个FTP文件。

基于图7和图8所示的流程，在传输FTP文件时，由于可以基于QUIC协议建立FTP会话，所以不需要像TCP一样进行三次握手，所以能够简化文件传输过程。

接下来对图7和图8所示的流程进行进一步说明。

在一种可能的实现方式中，在步骤701中，第一端与第二端之间基于QUIC协议的FTP会话关联一个QUIC连接，或者关联两个QUIC连接。在关联一个QUIC连接的情况下，第一端与第二端建立基于QUIC协议的FTP会话的过程为：

第一端与第二端建立第一QUIC连接，第一端在第一QUIC连接内创建至少一个控制stream，至少一个控制stream用于发送控制信息，第一端通过至少一个控制stream与第二端建立FTP会话。

在本实施例中，第一端与第二端建立QUIC连接，称为是第一QUIC连接，然后第一端在第一QUIC连接内创建一个stream，用于传输控制信息，该一个stream称为是控制stream。第一端在接收到用户输入的用户名和密码后，执行FTP认证，或者用户匿名(Anonymous)登录，第一端执行匿名FTP认证，第一端使用该控制stream向第二端发送认证请求，第二端在认证通过后，第一端与第二端建立起FTP会话，即建立起基于QUIC协议的FTP会话，该FTP会话关联第一QUIC连接。

或者，第一端与第二端建立第一QUIC连接，然后第一端在第一QUIC连接内创建一个stream，用于传输控制信息，该一个stream称为是第一控制stream。第一端在接收到用户输入的用户名和密码后，执行FTP认证，或者用户匿名登录，第一端执行匿名FTP认证，第一端使用第一控制stream向第二端发送控制信息，该控制信息包括认证请求。第二端第一次接收到使用第一控制stream发送的控制信息，第二端创建另一stream(称为是第二控制stream)，使用第二控制stream向第二端回复认证通过的结果，第一端与第二端建立起FTP会话。这样，第一端与第二端使用两个控制stream传输控制信息。

在基于QUIC协议的FTP会话关联两个QUIC连接的情况下，第一端与第二端建立基于QUIC协议的FTP会话的过程为：

第一端与第二端建立第二QUIC连接，第二QUIC连接包括至少一个控制stream，至少一个控制stream用于发送控制信息，第一端通过至少一个控制stream与第二端建立FTP会话。

在本实施例中，第一端与第二端建立QUIC连接，称为是第二QUIC连接，第一QUIC连接与第二QUIC连接不相同。第一端在第二QUIC连接内创建一个stream，该一个stream用于传输控制信息，该一个stream可以称为是控制stream。第一端在接收到用户输入的用户名和密码，执行FTP认证，或者用户匿名登录，第一端执行匿名FTP认证。第一端使用该控制stream向第二端发送认证请求，第二端在认证通过后，第一端与第二端建立起FTP会话，即建立起基于QUIC协议的FTP会话。

或者，第一端与第二端建立第二QUIC连接，然后第一端在第二QUIC连接内创建一个stream，用于传输控制信息，该一个stream称为是第三控制stream。第一端在接收到用户输入的用户名和密码后，执行FTP认证，或者用户匿名登录，第一端执行匿名FTP认证，第一端使用第三控制stream向第二端发送控制信息，该控制信息包括认证请求。第二端第一次接收到使用第三控制stream发送的控制信息，第二端创建另一stream(称为是第四控制stream)，使用第四控制stream向第一端回复认证通过的结果，第一端与第二端建立起FTP会话。这样，第一端与第二端使用两个控制stream传输控制信息。

需要说明的是，第一端与第二端是建立基于QUIC协议的FTP会话的双方，所以在步骤701及其可能的实现方式中描述第一端与第二端建立基于QUIC协议的FTP会话后，第二端与第一端也建立起基于QUIC协议的FTP会话，具体过程参见前文中的说明，此处不再赘述。

示例性的，在FTP会话关联一个QUIC连接或者关联两个QUIC连接时，步骤702和步骤802的处理为：

第一端确定第一QUIC连接内的至少一个数据stream，第一端基于至少一个数据stream向第二端发送至少一个第一FTP文件。第二端基于至少一个数据stream接收第一端发送的至少一个第一FTP文件。

在本实施例中，第一端在第一QUIC连接内创建至少一个数据stream，例如，第一端在第一QUIC连接内创建至少一个数据stream实例。然后第一端使用至少一个数据stream实例向第二端发送至少一个第一FTP文件。第二端使用该至少一个数据stream接收第一端发送的至少一个第一FTP文件。

这样，在FTP会话关联一个QUIC连接的情况下，第一端与第二端使用该一个QUIC连接内的不同stream传输控制信息和FTP文件。在FTP会话关联两个QUIC连接的情况下，第一端与第二端使用第一QUIC连接内的stream传输FTP文件，使用第二QUIC连接内的stream传输控制信息。

示例性的，在至少一个第一FTP文件为多个FTP文件的情况下，每个数据stream用于传输一个FTP文件，步骤702和步骤802的处理为：

第一端通过N个数据stream向第二端发送N个第一FTP文件。第二端通过N个数据stream接收第一端发送的N个FTP文件，N个FTP文件中的第一FTP文件与N个数据stream中的数据stream一一对应。

例如，第一端向第二端并行传输多个FTP文件，处理为：第一端通过N个数据stream向第二端并行发送N个第一FTP文件，第二端通过N个数据stream接收第一端并行发送的N个第一FTP文件。

在本实施例中，在FTP会话内，第一端在第一QUIC连接内创建N个数据stream，使用N个数据stream向第二端并行发送N个第一FTP文件，其中，每个数据stream用于发送一个第一FTP文件，不同的数据stream用于发送不同的第一FTP文件。对于N个第一FTP文件中的任一第一FTP文件，第二端在接收到该第一FTP文件的第一个文件块后，创建该第一FTP文件对应的数据stream实例，该数据stream实例与第一端发送该文件使用的数据stream实例的stream标识相同。第二端将接收到的该第一FTP文件的数据写入该stream实例对应的接收缓存区，后续再通过该数据stream接收到FTP文件的数据时，将该数据写入该接收缓存区，在接收缓存区中的数据连续时，将接收缓存区中的连续数据写入该数据stream对应的第一FTP文件中。

这样，多个FTP文件能够并行从第一端传输至第二端，进而能够提升批量文件传输的效率。

再例如，第一端通过N个数据stream向第二端串行发送N个第一FTP文件，第二端通过N个数据stream接收第一端串行发送的N个第一FTP文件。

在本实施例中，假设要传输N个第一FTP文件，第一端在第一QUIC连接内创建第一数据stream，使用第一数据stream向第二端发送第一个文件的数据。在第一个第一FTP文件传输完成后，第一端关闭第一数据stream，并且在第一QUIC连接内创建第二数据stream，使用第二数据stream向第二端发送第二个第一FTP文件。在第二个第一FTP文件传输完成后，第一端关闭第二数据stream。此处以第一端向第二端传输两个第一FTP文件为例进行说明，传输3个及3个以上的第一FTP文件的过程参见传输两个第一FTP文件的过程。第二端每次接收到一个新的数据stream发送的第一个报文后，创建该数据stream对应的stream实例，将接收到的第一FTP文件的数据写入该stream实例对应的接收缓存区，后续再通过该数据stream接收到FTP文件的数据时，将该数据写入该接收缓存区，在接收缓存区中的数据连续时，将接收缓存区中的连续数据写入该数据stream对应的第一FTP文件中。

示例性的，在至少一个数据stream包括一个数据stream的情况下，第一端可以通过该一个数据stream向第二端传输至少一个第一FTP文件，处理为：

第一端通过第一数据stream向第二端串行发送至少一个第一FTP文件。第二端通过第一数据stream接收第一端串行发送的至少一个第一FTP文件。

在本实施例中，在至少一个第一FTP文件包括一个FTP文件的情况下，第一端通过第一数据stream向第二端发送该一个FTP文件。在至少一个第一FTP文件包括多个FTP文件的情况下，第一端通过第一数据stream向第二端串行发送该多个FTP文件。例如，第一端通过第一数据stream传输第一个FTP文件，在传输完第一个FTP文件后，第一端通知第二端第一个FTP文件传输完成，开始传输第二个FTP文件，依此类推传输完多个第一FTP文件。第二端将接收到的每个第一FTP文件的数据写入对应的第一FTP文件中。

示例性的，在N大于或等于1的情况下，为了使得第二端能够准确将数据stream与FTP文件对应，第一端可以提前通知第二端N个第一FTP文件分别所使用的数据stream，处理为：

在第一端向第二端发送N个第一FTP文件之前，在FTP会话内，第一端基于QUIC控制stream向第二端发送控制信息，控制信息包括N个第一FTP文件与N个数据stream的对应关系。第二端基于QUIC控制stream接收第一端发送的控制信息，控制信息包括N个FTP文件与N个数据stream的对应关系。

在本实施例中，第一端可以使用QUIC控制stream向第二端发送控制信息，控制信息中包括N个第一FTP文件与N个数据stream的对应关系，该对应关系可以为N个第一FTP文件的文件名与N个数据stream的stream标识的对应关系。第二端接收到控制信息后，可以从该控制信息中解析获得N个第一FTP文件与N个数据stream的对应关系。

示例性的，第一端通知第二端N个第一FTP文件分别所使用的数据stream的处理方式有多种，如下提供方式一和方式二两种可行的方式，方式一为直接发送方式，方式二为隐式映射方式。

方式一，第一端使用前文中的控制stream向第二端发送控制信息。第二端接收第一端使用控制stream发送的该控制信息，控制信息包括N个第一FTP文件与N个数据stream的对应关系。

其中，该对应关系可以是携带在QUIC报文中自定义的帧中，且该对应关系中数据stream可以使用stream标识表示，该自定义的帧可以称为是文件映射(FILEMAP)帧。第二端在该帧中读取该对应关系，存储该对应关系，后续按照该对应关系中的stream标识关联到对应的第一FTP文件。

方式二，第一端使用控制stream向第二端发送控制信息，控制信息包括N个第一FTP文件的路径字符串列表，N个数据stream的stream类型相同。

其中，N个文件的路径字符串列表中包括N个第一FTP文件的路径字符串，也就是可以指示出N个第一FTP文件的文件名。

在本实施例中，在N个数据stream均采用相同的stream类型的情况下，将文件路径字符串列表按照字典顺序排序后，与指定的stream类型的stream标识单调递增或者单调递减顺序一一对应。第一端发送的控制信息中包括N个第一FTP文件的路径字符串列表。这样，第二端基于N个第一FTP文件的路径字符串列表能够按照约定的方式，推理获得N个第一FTP文件分别对应的stream标识。

示例性的，除了上述提前发送数据stream与FTP文件的对应关系，为了使得第二端能够准确将数据stream与第一FTP文件对应，可以在每个第一FTP文件的第一个数据块所在的报文中添加stream标识。例如，目标FTP文件为前文中至少一个第一FTP文件中任一个FTP文件，目标FTP文件的第一个报文中包括传输目标FTP文件的数据stream的stream标识，第一个报文为目标FTP文件的第一个数据块所在的报文。这样，第二端基于接收到的该第一个报文，获得目标数据stream对应的stream实例，第二端将接收到的目标FTP文件的数据写入该stream实例对应的缓存区，第二端根据缓存区的数据获得目标FTP文件。

在本实施例中，目标FTP文件的第一个报文中包括传输目标FTP文件的数据stream的stream标识，第二端在接收到的第一个报文中，获取stream标识，该第一个报文中携带的均是该stream标识对应的目标FTP文件的数据。第二端使用该stream标识，确定该stream标识对应的目标数据stream，进而可以确定目标数据stream对应的stream实例。第二端将该stream标识所在的报文中的目标FTP文件的数据，写入该stream实例对应的接收缓存区，在该接收缓存区中数据连续时，将连续的数据写入目标FTP文件中。第二端在接收到指示目标FTP文件传输结束的标识时，确定目标FTP文件传输完成。此处stream标识与FTP文件的对应关系，可以是基于预设的规则配置。

示例性的，除了上述提前发送数据stream与FTP文件的对应关系，为了使得第二端能够准确将数据stream与第一FTP文件对应，可以在每个第一FTP文件的第一个数据块所在的报文中添加第一FTP文件的路径字符串和stream标识，该stream标识指示的数据stream用于传输该第一FTP文件。例如，目标FTP文件为前文中至少一个第一FTP文件中任一个FTP文件，目标FTP文件的第一个报文中包括传输目标FTP文件的数据stream的stream标识和目标FTP文件的路径字符串，第一个报文为目标FTP文件的第一个数据块所在的报文。这样，第二端在接收到该第一个报文后，从中可以获得目标FTP文件的路径字符串和对应的stream标识，可以将报文中FTP文件的数据写入对应的FTP文件中。

例如，单个UDP报文中可以包括一个或多个QUIC报文，在单个QUIC报文中可以包括一个或多个STREAM帧。目标FTP文件的第一个数据块、FTP文件1的第一个数据块和FTP文件2的第一个数据块在一个UDP报文中。该UDP报文中包括这三个FTP文件的路径字符串与stream标识的对应关系。每个STREAM帧中包括该STREAM帧所属的数据stream的stream标识，第二端使用stream标识，在三个FTP文件的路径字符串与stream标识的对应关系中，确定该STREAM帧中的数据所属的FTP文件的路径字符串，进而可以将STREAM帧中的数据准确写入对应的FTP文件中。

在第一个报文中携带stream标识和FTP文件的路径字符串的方式，可以称为是显式映射方式。

需要说明的是，在第一端使用一个数据stream发送多个FTP文件时，一个数据stream对应一个缓存区，在将一个FTP文件的数据从缓存区写入FTP文件后，再将下一个FTP文件的数据写入该缓存区，这样，可以防止不同FTP文件的数据混淆。

示例性的，前面几种实现方式中，第二端在接收FTP文件过程中，是先将FTP文件写入数据stream对应的实例的缓存区，然后将实例的缓存区中的连续数据再写入FTP文件中。在本申请实施例中，还可以是第二端为每个FTP文件划分缓存区，第二端在接收某个FTP文件过程中，先确定该FTP文件对应的缓存区，然后再将该FTP文件对应的缓存区中的连续数据写入该FTP文件中。例如，第二端在接收到使用目标数据stream发送的数据后，确定目标数据stream对应的FTP文件，将使用目标stream发送的数据写入该FTP文件对应的缓存区中，然后再将该FTP文件对应的缓存区中的连续数据写入该FTP文件中。

示例性的，如前文描述，为了防止head-of-line block，在第一QUIC连接对应一条path的情况下，控制stream和数据stream对应不同的UDP报文，也就是说，发送N个第一FTP文件与发送控制信息的UDP报文不相同。在第一QUIC连接对应多条path的情况下，控制stream和数据stream对应不同的path，也就是说，发送N个第一FTP文件与发送控制信息所使用的path不相同，相当于发送N个第一FTP与发送控制信息时对应的五元组不相同，五元组包括源地址、目的地址、协议、源端口和目的端口。对于多个第一FTP文件，在保证吞吐量最大的情况下，在单个UDP报文中应该尽可能包含数目最小的第一FTP文件，具体单个UDP报文中包括几个第一FTP文件的数据，可以根据实际需要设置，本申请实施例不做限定。

在第一QUIC连接对应多条path的情况下，为了使得head-of-line block可能性更低，若多条path的数目等于N+1的情况下，其中一条path用于传输控制信息，其余每条path分别用于传输一个第一FTP文件的数据，也就是说，多条path分别对应控制stream和N个数据stream中的一个stream。这样，由于所有stream之间不存在任何head-of-line block问题，所以可以获得最佳的传输性能。

在第一QUIC连接对应多条path的情况下，为了使得head-of-line block可能性比较低，若多条path的数目小于N+1，且大于或等于3，则存在多个第一FTP文件使用同一条path的情况，为了使得优先级较高的第一FTP文件尽快发送，可以将优先级高于一定阈值的每个第一FTP文件的数据单独使用一条path发送。

此处仅是一种示例，在多条path的数目小于N+1，且大于或等于3的情况下，具体如何发送可以根据实际需要进行处理，本申请实施例不做限定。

在一种可能的实现方式中，第一QUIC连接和第二QUIC连接使用的五元组不相同，相应的第一QUIC连接和第二QUIC连接对应不同的path，第一QUIC连接可以对应多条path，这样，第一QUIC连接和第二QUIC连接对应多条path，任一数据stream对应的path和任一控制stream对应的path不相同，使得FTP文件的传输不会影响控制信息的传输。

示例性的，第一端为客户端，第二端为服务端，在第一端使用数据stream向第二端发送至少一个第一FTP文件之前，第一端使用控制stream向第二端发送文件上传请求，此过程对应的操作可以是put操作或mput操作等。另外，第一端使用控制stream向第二端发送文件上传请求后，接收到第二端发送的确认上传消息后，使用数据stream向第二端发送至少一个第一FTP文件。

第一端为服务端，第二端为客户端，在第一端使用控制stream接收到第二端发送的文件下载请求后，第一端使用数据stream向第二端发送至少一个第一FTP文件。此过程对应的操作可以是get操作或mget操作等。

示例性的，第一端为客户端，第二端为服务端的情况下，第一端向第二端传输N个第一FTP文件，相当于是第一端向第二端上传N个第一FTP文件，第一端还可以向用户展示每个第一FTP文件的上传比例，即上传进度百分比。

在图7所示的流程中，是第一端向第二端传输N个第一FTP文件的过程，在基于QUIC协议的FTP会话中，第二端也可以向第一端传输FTP文件，处理如下：

在FTP会话内，第一端接收第二端基于第二QUIC stream发送的至少一个第二FTP文件。

其中，第一端接收第二端发送的至少一个第二FTP文件，包括两种情况，一种情况下，第一端为客户端，第二端为服务端，相当于是客户端从服务端下载第二FTP文件，相应的，第一端使用控制stream向第二端发送文件下载请求。在另一种情况下，第一端为服务端，第二端为客户端，相当于是客户端向服务端上传第二FTP文件，相应的，第一端使用控制stream接收第二端发送的文件上传请求。

在本实施例中，在FTP会话内，第二端可以使用第二QUIC stream向第一端发送至少一个第二FTP文件。其中，第一QUIC stream与第二QUIC stream为相同的stream，或者不同的stream。在第二QUIC stream与第一QUIC stream为相同的stream时，第一QUIC stream可以是双向stream。在第一QUIC stream与第二QUIC stream为不相同的stream时，第一QUIC stream与第二QUIC stream可以是双向stream，也可以是单向stream。

在一种可能的实现方式中，第二端向第一端发送FTP文件，可以是发送M个第二FTP文件。相应的处理为：

第二端使用M个数据stream向第一端发送M个第二FTP文件。第一端接收第二端使用M个数据stream发送的M个第二FTP文件，M个数据stream属于第一QUIC连接，第二FTP文件与数据stream一一对应，M为大于1的正整数。第二端向第一端发送第二FTP文件的过程，参见前文中第一端向第二端发送第一FTP文件的过程，此处不再赘述。

示例性的，在第一端向第二端请求下载M个第二FTP文件时，还可以显示接收比例，处理为：

第一端使用控制stream向第二端发送M个第二FTP文件的数据量的获取请求，第一端使用控制stream接收第二端发送的M个第二FTP文件的数据量，第一端基于M个第二FTP文件的数据量和当前接收数据的数据量，向用户展示M个第二FTP文件的接收比例。

在本实施例中，第一端在向第二端请求下载M个第二FTP文件时，使用控制stream向第二端发送M个第二FTP文件的数据量的获取请求。第二端使用控制stream向第一端发送M个第二FTP文件中每个第二FTP文件的数据量，第一端在接收M个第二FTP文件的数据时，还可以向用户展示M个第二FTP文件的接收比例，该接收比例可以使用进度百分比表示。

示例性的，上述获取请求可以与文件下载请求一起发送，或者携带在文件下载请求中。

示例性的，第二端接收第一端发送的至少一个第一FTP文件时，还可以显示每个第一FTP文件的接收比例。

在本实施例中，第二端在向第一端请求下载至少一个第一FTP文件时，使用控制stream向第一端发送每个第一FTP文件的数据量的获取请求。第二端向第一端发送每个第一FTP文件的数据量，第二端在接收每个第一FTP文件的数据时，还可以向用户展示每个第一FTP文件的接收比例，该接收比例可以使用进度百分比表示。

示例性的，在步骤802之前，在第一端为客户端，第二端为服务端的情况下，第二端接收第一端使用控制stream发送的文件上传请求。或者，在第一端为服务端，第二端为客户端的情况下，第二端使用控制stream向第一端发送文件下载请求。

上面描述了第一端与第二端传输FTP文件的过程，接下来描述客户端与服务端建立基于QUIC协议的FTP会话的示例，以及客户端与服务端交互执行get操作、put操作、mget操作和mput操作的过程。

在描述建立基于QUIC协议的FTP会话的过程之前，首先介绍客户端和服务端，客户端包括客户端的QUIC模块和客户端的QFTP模块，服务端包括服务端的QUIC模块和服务端的QFTP模块。该QUIC模块用于创建QUIC连接以及创建stream。该QFTP模块用于创建以及管理基于QUIC协议的FTP会话。该QUIC模块和该QFTP模块可以是软件模块。在本申请实施例中，由客户端发起建立基于QUIC协议的FTP会话，参见图9。在图9中描述客户端与服务端建立基于QUIC协议的FTP会话的过程。

步骤901，服务端的QFTP模块请求服务端的QUIC模块创建QUIC连接实例，并且在指定的IP地址(如IP地址为1.1.1.1)和UDP端口21上监听，并指定APLN＝“ftp”。

步骤902，用户接入客户端，执行QFTP的IP地址(步骤901中的1.1.1.1)命令行，请求登录到QFTP服务端。

步骤903，客户端的QFTP模块向客户端的QUIC模块发起建立QUIC连接的请求，其中，目的IP地址为步骤901中的IP地址，目的端口为步骤901中的UDP端口，APLN＝“ftp”。

步骤904，客户端的QUIC模块接收客户端的QFTP模块发送的建立QUIC连接的请求。客户端的QUIC模块与服务端的QUIC模块建立QUIC连接。

在步骤904中，客户端与服务端建立QUIC连接的过程参见RFC9000以及相关RFC，此处不再赘述。

步骤905，服务端的QUIC模块向服务端的QFTP发送QUIC连接创建成功消息，该消息中包括QUIC连接的标识。客户端的QUIC模块向客户端的QFTP发送QUIC连接创建成功消息，该消息中包括QUIC连接的标识。该标识唯一指示建立的QUIC连接。

经过步骤901至步骤905，客户端与服务端建立传输协议层的连接。

步骤906，客户端的QFTP模块在QUIC连接建立成功后，向客户端的QUIC模块发送控制stream实例的创建请求。

步骤907，客户端的QUIC模块创建控制stream实例，指定stream类型为0，stream标识为0。

在步骤907中，客户端的QUIC模块创建的控制stream的类型为0，指示创建的是双向stream。

步骤908，客户端的QUIC模块向客户端的QFTP模块返回控制stream实例的标识。

步骤909，客户端的QFTP模块向用户返回QFTP的IP地址已登录成功的消息。

步骤910，用户提交用户名和密码进行FTP认证，或者执行匿名FTP认证。

步骤911，客户端的QFTP模块使用控制stream实例向服务端的QFTP模块发送FTP认证请求。客户端的QUIC模块使用控制stream实例向服务端的QFTP模块发送FTP认证请求。

在步骤911中，若用户提交用户名和密码，则FTP认证请求中携带该用户名和密码，若用户提交匿名认证，则FTP认证请求中携带匿名标识。

步骤912，服务端的QUIC模块接收FTP认证请求，创建stream实例，该stream实例为控制stream实例。

在步骤912中，创建的控制stream实例与步骤907中创建的stream实例的stream标识相同，属于一个stream。

步骤913，服务端的QUIC模块向服务端的QFTP模块发送FTP认证请求。

步骤914，服务端的QFTP模块接收FTP认证请求，执行认证，请求服务端的QUIC模块使用控制stream实例向客户端的QFTP模块返回用户认证结果。

步骤915，服务端的QUIC模块使用控制stream实例向客户端的QUIC模块返回用户认证结果。

步骤916，客户端的QUIC模块向客户端的QFTP模块返回用户认证结果。

步骤917，客户端的QFTP模块向用户返回用户认证结果。

若用户认证结果为通过，则客户端与服务端建立基于QUIC协议的FTP会话。

需要说明的是，在基于QUIC协议的FTP会话关联一个QUIC连接时，图9所示的流程中建立的QUIC连接为第一QUIC连接。在基于QUIC协议的FTP会话关联两个QUIC连接时，图9所示的流程中建立的QUIC连接为第二QUIC连接，建立第一QUIC连接的过程与建立第二QUIC连接的过程类似。例如，客户端向服务端发送PASV命令或者PORT命令，与服务端协商第一QUIC连接的UDP端口和IP地址。另外，图9所示的流程中是以创建一个控制stream为例进行说明。

接下来分别描述get操作、put操作、mget操作和mput操作，以下以不同stream映射控制通道和数据通道为例进行说明。

(1)get操作，get操作由客户端执行，用于从服务端将指定的单个FTP文件下载到客户端。get操作常见的命令行为“get remote-filename[local-filename]”，其中，参数remote-filename指服务端的文件名，参数local-filename指客户端本地的文件名，参数local-filename是可选的，若未指定，则与remote-filename相同，表示客户端从服务端下载的FTP文件的文件名与服务端该FTP文件的文件名相同。例如，在创建基于QUIC协议的FTP会话后，用户在客户端所在的终端上执行命令行“get sfile.txt cfile.txt”，从服务端下载文件sfile.txt到客户端，并且命名为cfile.txt，文件sfile.txt为FTP文件。get操作的过程参见图10所示的流程。

步骤1001，客户端与服务端建立基于QUIC连接的FTP会话，此过程参见图9所示的流程。

步骤1002，用户执行命令行“get sfile.txt cfile.txt”，“get sfile.txtcfile.txt”指示从服务端下载文件sfile.txt到客户端，并重新命名为cfile.txt。

步骤1003，客户端的QFTP模块使用控制stream实例，向服务端的QFTP模块发送FTPsize命令。FTP size命令用于检查文件sfile.txt是否存在，以及获取文件sfile.txt的数据量。该FTP size命令是一种FTP command。

步骤1004，服务端的QFTP模块接收到FTP size命令后，若确定服务端上存在文件sfile.txt，服务端的QFTP模块使用FTP Reply Code 213返回文件sfile.txt的数据量。

步骤1005，客户端的QFTP模块使用控制stream实例向服务端的QFTP模块发送FTPRETR命令，请求下载文件sfile.txt。

步骤1006，服务端的QFTP模块接收到FTP RETR命令，打开本地文件sfile.txt。

步骤1007，服务端的QFTP模块使用控制stream实例，向客户端的QFTP模块返回FTPReply Code 150，FTP Reply Code 150中携带有sfile.txt的文件名，FTP Reply Code 150用于指示待下载文件已经准备就绪。

步骤1008，服务端的QFTP模块请求服务端的QUIC模块创建数据stream实例，接收服务端的QUIC模块返回的数据stream实例的stream标识。服务端的QTFP模块打开文件sfile.txt，使用数据stream实例，向客户端的QFTP模块传输文件sfile.txt的数据。

在步骤1008中，若发送文件sfile.txt的最后一个数据块，在数据stream实例对应的STREAM帧中设置FIN-bit＝1，用于指示文件sfile.txt的数据已发送完毕。在成功发送文件sfile.txt的所有数据块后，删除本地数据stream实例。

步骤1009，客户端的QUIC模块在接收到数据stream实例发送的数据时，若是文件sfile.txt的第一个数据块，则客户端的QUIC模块在本地新建数据stream实例。客户端的QUIC模块将接收到的数据写入创建的数据stream实例对应的接收缓存区中。

在步骤1009中，客户端的QUIC模块创建的数据stream实例与服务端的QUIC模块创建的数据stream实例的stream标识相同，同属于一个数据stream。

步骤1010，客户端的QUIC模块在接收缓存区中的数据块连续时，将连续的数据块上送给客户端的QFTP模块。

在步骤1010中，在接收到携带有FIN-bit＝1的STREAM帧，且接收到的数据块连续时，确定接收到文件sfile.txt的所有连续数据块，将接收到的所有数据块上送给客户端的QFTP模块。

步骤1011，客户端的QFTP模块接收到文件sfile.txt的第一个数据块时，打开本地文件cfile.txt。然后将接收到的数据块写入cfile.txt中。

步骤1012，客户端的QFTP模块接收到文件sfile.txt的数据块时，客户端的QFTP模块实时计算文件sfile.txt已接收的数据量的进度百分比，并向用户反馈该百分比。

步骤1013，服务端的QFTP模块在删除本地数据stream实例后，使用控制stream实例向客户端的QFTP模块发送FTP Reply Code 226，FTP Reply Code 226指示文件sfile.txt的数据已全部传输完毕，删除数据stream实例。

步骤1014，客户端的QFTP模块请求客户端的QUIC模块删除本地数据stream实例。客户端的QUIC模块删除本地数据stream实例。

在图10的流程中，是客户端的QFTP模块接收到FTP Reply Code 226后，删除本地数据stream实例，在实际操作时，也可能是在步骤1010中，在将接收到的所有数据块上送客户端的QFTP模块后，删除本地数据stream实例。

另外，在图10的流程中，客户端QFTP也可以不请求文件sfile.txt的数据量。

需要说明的是，图10所示的流程是客户端从服务端成功获取到文件sfile.txt的过程，在实际处理时有可能会存在多种异常条件。例如，客户端的可用存储空间不足以存储文件sfile.txt、客户端或服务端的文件系统的访问控制等有可能导致get操作失败。

(2)put操作，put操作由客户端执行，put操作用于将客户端上的一个FTP文件上传到服务端，命令行可以是put local filename，其中，local filename指本地的文件名。例如，用户执行命令行“put pfile.txt”，请求将客户端上文件pfile.txt上传至服务端，文件pfile.txt为FTP文件。put操作的过程参见图11所示的流程。

步骤1101，客户端与服务端建立基于QUIC连接的FTP会话，此过程参见图9所示的流程。

步骤1102，用户执行命令行“put pfile.txt”，命令行“put pfile.txt”用于请求将客户端上的文件pfile.txt上传至服务端。

步骤1103，客户端的QFTP模块使用文件名pfile.txt检查本地文件系统，确定文件pfile.txt是否存在，若存在，则请求客户端的QUIC模块为文件pfile.txt创建一个对应的数据stream实例。客户端的QUIC模块向客户端的QFTP模块返回创建的数据stream的stream标识。若不存在，则向用户返回错误消息。

步骤1104，客户端的QFTP模块使用控制stream实例发送FTP STOR命令，请求将文件pfile.txt上传到服务端上。

步骤1105，服务端的QFTP模块在接收到FTP STOR命令后，检查本地文件系统是否允许接收上传的文件，例如，服务端本地是否存在同名的文件名，若存在同名的文件名，是否允许覆盖等。

步骤1106，若服务端允许接收上传的文件，服务端的QFTP模块向客户端的QFTP模块返回FTP Reply Code 150。

步骤1107，客户端的QFTP模块接收到服务端的QFTP模块返回的FTP Reply Code150后，打开本地文件pfile.txt，使用对应的数据stream实例向服务端的QFTP发送文件pfile.txt的数据。

在步骤1107中，客户端的QFTP模块发送文件pfile.txt的最后一个数据块时，使用数据stream实例对应的STREAM帧中设置FIN-bit＝1。

步骤1108，服务端的QUIC模块在接收到的文件的数据时，若不存在该数据所在的报文中的stream标识的数据stream实例，则创建该stream标识的数据stream实例。将接收到的文件的数据写入数据stream实例的接收缓存区。

步骤1109，服务端的QUIC模块将数据stream实例的接收缓存区中的连续的数据块，向服务端的QFTP模块发送。

在步骤1109中，对于文件pfile.txt，在接收到携带有FIN-bit＝1的STREAM帧，且接收到的数据块连续时，确定接收到该文件的所有连续数据块，将接收到的所有数据块上送给服务端的QFTP模块，删除本地数据stream实例。

步骤1110，服务端的QFTP模块接收到服务端的QUIC模块发送的数据块后，使用stream标识，查找对应的文件名，将接收到的数据块写入该文件名指示的文件中。

步骤1111，客户端的QFTP模块在成功发送文件pfile.txt的一个数据块后，计算并向用户实时反馈文件的数据上传的进度百分比。

步骤1112，客户端的QFTP模块在确定文件pfile.txt的所有数据均上传成功，关闭该文件。

步骤1113，服务端的QFTP模块在接收到文件pfile.txt的所有数据后，使用控制stream实例向客户端的QFTP模块返回FTP Reply Code 226，指示文件pfile.txt已成功上传。

步骤1114，客户端的QFTP模块接收到FTP Reply Code 226，确定文件pfile.txt已上传成功，请求客户端的QUIC模块删除本地文件pfile.txt对应的数据stream实例。

需要说明的是，图11所示的流程是客户端向服务端成功传输一个文件的过程，在实际处理时有可能会存在多种异常条件。例如，服务端的可用存储空间不足以存储客户端上传的文件、客户端或服务端的文件系统的访问控制等有可能导致put操作失败。

图11中所示的流程中，客户端的QFTP模块可以在pfile.txt的第一个数据块所在的报文中，添加pfile.txt的路径字符串与对应的stream标识，也可以使用控制信息向服务端的QFTP模块发送pfile.txt的路径字符串与对应的stream标识。

(3)mget操作，mget操作由客户端执行，用于从服务端将指定的多个FTP文件下载到客户端。mget操作常见的命令行为“get remote-filenames[local-filenames]”，其中，参数remote-filenames指服务端的文件路径字符串列表，参数local-filename指客户端本地的文件路径字符串列表，参数local-filename是可选的，若未指定，则与remote-filename相同，表示客户端从服务端下载的FTP文件的文件名与服务端该FTP文件的文件名相同。例如，在创建基于QUIC协议的FTP会话后，用户在客户端所在的终端上执行命令行“mget a*.txt b*.txt c*.txt”，从服务端下载a*.txt b*.txt c*.txt指示的多个FTP文件到客户端。mget操作的过程参见图12所示的流程。

步骤1201，客户端与服务端建立基于QUIC连接的FTP会话，此过程参见图9所示的流程。

步骤1202，用户执行命令行“mget a*.txt b*.txt c*.txt”，命令行“mget a*.txtb*.txt c*.txt”用于请求从服务端下载a*.txt b*.txt c*.txt指示的多个文件到客户端。

步骤1203，客户端的QFTP模块使用控制stream实例，向服务端的QFTP模块发送FTPsize命令，FTP size命令用于检查请求的文件是否存在，以及获取该文件的数据量。

步骤1204，服务端的QFTP模块接收到每个文件的FTP size命令后，若确定服务端上存在FTP size命令请求的文件，服务端的QFTP模块使用控制stream示例返回Reply Code213，Reply Code 213包括该文件的数据量。

步骤1205，客户端的QFTP模块使用控制stream实例向服务端的QFTP模块发送FTPRETR命令，请求下载a*.txt b*.txt c*.txt指示的多个文件。

步骤1206，服务端的QFTP模块接收到FTP RETR命令，打开a*.txt b*.txt c*.txt指示的多个本地文件，同时请求服务端的QUIC模块创建每个文件对应的数据stream实例。

步骤1207，服务端的QFTP模块使用控制stream实例，向客户端的QFTP模块返回FTPReply Code 150，FTP Reply Code 150用于指示待下载文件已经准备就绪。并且服务端的QFTP模块在传输FTP Reply Code 150的QUIC报文中，添加文件名与数据stream实例的stream标识的映射关系。

示例性的，文件名与数据stream实例的stream标识的映射关系封装在自定义的帧中。

步骤1208，客户端的QFTP模块接收到FTP Reply Code 150以及文件名与数据stream实例的stream标识的映射关系后，保存文件名与数据stream实例的stream标识的映射关系。

步骤1209，对于a*.txt b*.txt c*.txt指示的每个文件，服务端的QFTP模块使用每个文件对应的数据stream实例，向客户端的QFTP模块传输每个文件的数据。

在步骤1209中，对于任一文件，若发送该文件的最后一个数据块，在该文件的数据stream实例对应的STREAM帧中设置FIN-bit＝1，用于指示该文件的数据已发送完毕。在成功发送该文件的所有数据块后，删除该文件的数据stream实例。

步骤1210，客户端的QUIC模块在接收到数据stream实例发送的数据时，如果是某个文件的第一个数据块，则客户端的QUIC模块在本地新建数据stream实例。客户端的QUIC模块将接收到的数据写入创建的数据stream实例对应的接收缓存中区。

步骤1211，客户端的QUIC模块在每个数据stream实例的接收缓存区中的数据块连续时，将连续的数据块上送给客户端的QFTP模块。

在步骤1211中，对于任一文件，在接收到携带有FIN-bit＝1的STREAM帧，且接收到的数据块连续时，确定接收到该文件的所有连续数据块，将接收到的所有数据块上送给客户端的QFTP模块。

步骤1212，对于每个文件，客户端的QFTP模块接收到该文件的第一个数据块时，打开该文件对应的本地文件。然后将接收到的数据块写入该本地文件中。

步骤1213，客户端的QFTP模块接收到每个文件的数据块时，客户端的QFTP模块实时计算每个文件已接收的数据量的进度百分比，并向用户反馈该进度百分比。

步骤1214，服务端的QFTP模块在删除本地数据stream实例后，使用控制stream实例向客户端的QFTP模块发送FTP Reply Code 226，并且携带FILMAP帧(指示相关的文件名和数据stream实例的Stream标识)，FTP Reply Code 226和FILMAP帧指示该文件名的文件的数据已全部传输完毕。

步骤1215，客户端的QFTP模块请求客户端的QUIC模块删除FTP Reply Code 226和FILMAP帧指示的本地数据stream实例。

在图12的流程中，是客户端的QFTP模块接收到FTP Reply Code 226后，删除本地数据stream实例，在实际操作时，也可能是在步骤1211中，在将接收到的某个文件的所有数据块上送客户端的QFTP模块后，删除该文件对应的本地数据stream实例。

另外，在图12的流程中，客户端QFTP也可以不请求每个文件的数据量。

需要说明的是，图12所示的流程是客户端从服务端成功获取到多个文件的过程，在实际处理时有可能会存在多种异常条件。例如，客户端的可用存储空间不足以存储多个文件、客户端或服务端的文件系统的访问控制等有可能导致get操作失败。

(4)mput操作，mput操作由客户端执行，mput操作用于将客户端上的多个FTP文件上传到服务端，命令行可以是mput local filenames，其中，local filenames是由空格分隔的文件路径字符串列表，可以包含通配符，通配符是一种特殊语句，主要有“星号”和“问号”，用来模糊搜索FTP文件。例如，用户执行命令行“mput 1*.txt 2*.txt 3*.txt”，请求将客户端上符合命令行指示的特征的多个FTP文件上传至服务端。mput操作的过程参见图13所示的流程。

步骤1301，客户端与服务端建立基于QUIC连接的FTP会话，此过程参见图9所示的流程。

步骤1302，用户执行命令行“mput 1*.txt 2*.txt 3*.txt”，命令行“mput 1*.txt2*.txt 3*.txt”用于请求将客户端上的多个文件上传到服务端上。

步骤1303，客户端的QFTP模块使用命令行“mput 1*.txt 2*.txt 3*.txt”指示的文件名列表检查本地文件系统，此处若指定了通配符，将其展开为实际的文件名列表。然后客户端的QFTP模块请求客户端的QUIC模块为每个待上传的文件创建一个数据stream实例。客户端的QFTP模块接收每个待上传的文件对应的数据stream实例的stream标识。客户端的QFTP模块存储文件名与数据stream实例的stream标识的映射关系。

步骤1304，对于每个待上传的文件，客户端的QFTP模块使用控制stream实例发送FTP STOR命令，请求将指定的文件上传至服务端。

在步骤1304中，传输FTP STOR命令的QUIC报文中还可以包括文件名与数据stream实例的stream标识的映射关系，示例性的，该映射关系可以添加在自定义的帧(如前文提到的FILEMAP帧)中。此处是以FTP STOR命令与该映射关系一起发送，也可以是FTP STOR命令与该映射关系分别发送。

步骤1305，服务端的QFTP模块在接收到FTP STOR命令和上述映射关系后，检查本地文件系统是否允许接收上传的文件，例如，服务端本地是否存在同名的文件名，若存在同名的文件名，是否允许覆盖等。若允许接收上传的文件，则保存文件名与数据stream实例的stream标识的映射关系。

步骤1306，若服务端允许接收上传的文件，服务端的QFTP模块向客户端的QFTP模块返回FTP Reply Code 150。在FTP Reply Code 150所在的QUIC报文中包含一个自定义的帧，用来指示FTP Reply Code 150所对应的文件名。

在步骤1306中，服务端的QFTP模块可以在单个QUIC报文中返回多个待上传文件的检查结果，此时FTP Reply Code 150由STREAM帧封装。因此，在一个QUIC报文中可以顺序包含多个(STREAM,FILEMAP)帧对，例如，(STREAM 1,FILEMAP 1,STREAM 2,FILEMAP2,…)。

步骤1307，客户端的QFTP模块接收到服务端的QFTP模块返回的FTP Reply Code150后，打开本地待上传的每个文件，分别使用对应的数据stream实例向服务端的QFTP模块发送每个文件的数据。

在步骤1307中，客户端的QFTP模块发送每个文件的最后一个数据块时，在数据stream实例对应的STREAM帧中设置FIN-bit＝1。

步骤1308，服务端的QUIC模块在接收到的文件的数据块时，若不存在该数据所在的报文中的stream标识的数据stream实例，则创建该stream标识的数据stream实例。将接收到的文件的数据写入该数据stream实例的接收缓存区。若存在该数据所在的报文中stream标识的数据stream实例，则直接将接收到的文件的数据写入该数据stream实例的接收缓存区。

步骤1309，服务端的QUIC模块将数据stream实例的接收缓存区中连续的数据块，向服务端的QFTP模块发送。

在步骤1309中，对于某个文件，在接收到携带有FIN-bit＝1的STREAM帧，且接收到的数据块连续时，确定接收到该文件的所有连续数据块，将接收到的所有数据块上送给服务端的QFTP模块，删除本地数据stream实例。

步骤1310，服务端的QFTP模块接收到服务端的QUIC模块发送的数据块后，使用stream标识，查找对应的文件名，将接收到的数据块写入该文件名指示的文件中。

步骤1311，客户端的QFTP模块在成功发送文件的一个数据块后，计算并向用户实时反馈文件数据上传的进度百分比。

步骤1312，客户端的QFTP模块在确定某个文件的所有数据均上传成功，关闭该文件。

步骤1313，对于客户端上传的某个文件，服务端的QFTP模块在接收到该文件的所有数据后，使用控制stream实例向客户端的QFTP模块返回FTP Reply Code 226，并且携带FILEMAP帧(指示相关的文件名和数据stream实例的stream标识)，指示该文件名的文件已成功上传。

步骤1314，客户端的QFTP模块接收到FTP Reply Code 226，并获取到FILEMAP帧，确定FILEMAP帧指示的文件已上传成功，请求客户端的QUIC模块删除本地该文件对应的数据stream实例。

图13所示的流程中，步骤1311和步骤1312没有先后顺序。

图13所示的流程中，每个数据stream实例负责传输一个文件，使得多个文件同时并行向服务端传输，提升批量文件传输效率。

需要说明的是，图13所示的流程是客户端向服务端成功传输多个文件的过程，在实际处理时有可能会存在多种异常条件。例如，服务端的可用存储空间不足以存储客户端上传的文件、客户端或服务端的文件系统的访问控制等有可能导致mput操作失败。

图10至图13分别描述了get操作、put操作、mget操作和mput操作，在一个基于QUIC的FTP会话中，get操作、put操作、mget操作和mput操作中任意一种或多种可以被顺序执行。例如，客户端向服务端上传N个文件后，接下来客户端又从服务端下载M个文件。

在图12和图13所示的流程中，均需要传输路径字符串与stream标识的映射关系。但是在实际使用时，在一些示例中，可以单独传输文件路径字符串列表路径，基于该文件路径字符串列表路径确定出各个文件对应的stream标识，在另外一些示例中，在图12中基于接收到的FTP RETR命令确定文件路径字符串列表，在图13中基于接收到的FTP STOR命令确定文件路径字符串列表，这就不需要单独传输文件路径字符串列表路径。

图10至图13的流程是示例性的流程，不对文件传输的过程进行限定。

从前文中的描述可知，本申请实施例中未对FTP的操作进行修改，使得现有实现和用户接口等可以平滑迁移，使得前向兼容性比较好。而且由于QUIC安全性较高，因此可以对FTP的控制通道和数据通道同时提供了完整的安全保护，包括身份认证、机密性保护和完整性保护，且在保证安全性的同时，无需实现RFC2228、RFC2773、RFC4217等相关的FTP命令，因而可以简化用户接口和协议操作过程。而且利用QUIC的stream-multiplexing(流复用)和multi-path功能，将批量文件传输过程从串行流程优化为并行流程，从而可提升批量文件的传输性能。

下面描述本申请实施例提供的装置。

图14是本申请实施例提供的文件传输的装置的结构图。该装置可以通过软件、硬件或者两者的结合实现成为装置中的部分或者全部。本申请实施例提供的装置可以实现本申请实施例图7所述的流程，该装置应用于第一端，该装置包括：会话建立模块1410和发送模块1420，其中：

会话建立模块1410，用于与第二端建立基于QUIC协议的FTP会话，具体可以用于实现步骤701的会话建立功能以及执行步骤701包含的隐含步骤；

发送模块1420，用于在所述FTP会话内，基于第一QUIC stream向所述第二端发送至少一个第一FTP文件，具体可以用于实现步骤702的发送功能以及执行步骤702包含的隐含步骤。

在一种可能的实现方式中，所述会话建立模块1410，用于与所述第二端建立第一QUIC连接；

所述发送模块1420，用于确定所述第一QUIC连接内的至少一个数据stream；基于所述至少一个数据stream向所述第二端发送所述至少一个第一FTP文件。

在一种可能的实现方式中，所述至少一个数据stream的数目为N，所述至少一个第一FTP文件的数目为所述N，所述N为大于1的整数；

所述发送模块1420，用于通过N个数据stream向所述第二端发送N个第一FTP文件，所述N个第一FTP文件中的第一FTP文件与所述N个数据stream中的数据stream一一对应。

在一种可能的实现方式中，所述发送模块1420，用于通过所述N个数据stream向所述第二端并行发送所述N个第一FTP文件；或者，通过所述N个数据stream向所述第二端串行发送所述N个第一FTP文件。

在一种可能的实现方式中，所述至少一个数据stream为第一数据stream；

所述发送模块1420，用于通过所述第一数据stream向所述第二端串行发送所述至少一个第一FTP文件。

在一种可能的实现方式中，目标FTP文件的第一个报文中包括传输所述目标FTP文件的数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文，所述目标FTP文件为所述至少一个第一FTP文件中的任一个FTP文件。

在一种可能的实现方式中，所述发送模块1420，还用于在所述FTP会话内，基于QUIC控制stream向所述第二端发送控制信息，所述控制信息包括所述N个第一FTP文件与所述N个数据stream的对应关系。

在一种可能的实现方式中，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；

所述会话建立模块1410，还用于通过所述至少一个控制stream与所述第二端建立FTP会话。

在一种可能的实现方式中，所述会话建立模块1410，还用于与所述第二端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；通过所述至少一个控制stream与所述第二端建立FTP会话。

在一种可能的实现方式中，所述第一QUIC连接对应一条path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，所述第一QUIC连接和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，所述N个数据stream对应的path不相同。

在一种可能的实现方式中，所述装置还包括：接收模块，用于在所述FTP会话内，接收所述第二端基于第二QUIC stream发送的至少一个第二FTP文件。

在一种可能的实现方式中，所述第二QUIC stream与所述第一QUIC stream为相同的流，或者，所述第二QUIC stream与所述第一QUIC stream为不同的流。

在一种可能的实现方式中，所述第一端和所述第二端属于一个设备的不同模块；或者，所述第一端和所述第二端分别属于不同的设备。

图14所示的文件传输的装置执行文件传输的的详细过程请参照前面各个实施例中的描述，在这里不进行重复说明。

图15是本申请实施例提供的文件传输的装置的结构图。该装置可以通过软件、硬件或者两者的结合实现成为装置中的部分或者全部。本申请实施例提供的装置可以实现本申请实施例图8所述的流程，该装置应用于第二端，该装置包括：建立模块1510和接收模块1520，其中：

建立模块1510，用于与第一端建立基于QUIC协议的FTP会话，具体可以用于实现步骤801的会话建立功能以及执行步骤801包含的隐含步骤；

接收模块1520，用于在所述FTP会话内，基于QUIC stream接收所述第一端发送的至少一个FTP文件，具体可以用于实现步骤802的接收功能以及执行步骤802包含的隐含步骤。

在一种可能的实现方式中，所述建立模块1510，用于与所述第一端建立第一QUIC连接，所述第一QUIC连接包括至少一个数据stream；

所述接收模块1520，用于基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件。

在一种可能的实现方式中，所述至少一个数据stream的数目为N，所述至少一个FTP文件的数目为所述N，所述N为大于1的整数，所述接收模块1520，用于通过N个数据stream接收所述第一端发送的N个FTP文件，所述N个FTP文件中的FTP文件与所述N个数据stream中的数据stream一一对应。

在一种可能的实现方式中，所述接收模块1520，用于通过所述N个数据stream接收所述第一端并行发送的所述N个FTP文件；或者，通过所述N个数据stream接收所述第一端串行发送的所述N个FTP文件。

在一种可能的实现方式中，所述至少一个数据stream为第一数据stream，所述接收模块1520，用于通过所述第一数据stream接收所述第一端串行发送的所述至少一个FTP文件。

在一种可能的实现方式中，所述接收模块1520，还用于在所述FTP会话内，基于QUIC控制stream接收所述第一端发送的控制信息，所述控制信息包括N个FTP文件与所述N个数据stream的对应关系。

在一种可能的实现方式中，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于接收控制信息，所述建立模块1510，还用于通过所述至少一个控制stream与所述第一端建立FTP会话。

在一种可能的实现方式中，所述建立模块1510，还用于与所述第一端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；通过所述至少一个控制stream与所述第一端建立FTP会话。

在一种可能的实现方式中，所述第一QUIC连接对应一条path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，所述第一QUIC和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

在一种可能的实现方式中，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，所述N个数据stream对应的path不相同。

在一种可能的实现方式中，所述至少一个FTP文件中目标FTP文件的第一个报文中包括传输所述目标FTP文件的目标数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文。

在一种可能的实现方式中，所述接收模块1520，用于基于接收到的所述第一个报文，获得所述目标数据stream对应的实例；将接收到的所述目标FTP文件的数据写入所述实例对应的缓存区；根据所述缓存区的数据获得所述目标FTP文件。

在一种可能的实现方式中，所述装置还包括：展示模块，用于向用户展示所述至少一个FTP文件的接收比例。

图15所示的文件传输的装置执行文件传输的的详细过程请参照前面各个实施例中的描述，在这里不进行重复说明。

另外，图14和图15中的模块划分方式是示例性的划分方式，本申请实施例不做限定。

本申请实施例提供了一种文件传输的系统，该系统包括：第一端和第二端。可选地，第一端为如图5所示的设备500或包括图14所示的文件传输的装置，第二端为如图5所示的设备500或包括图15所示的文件传输装置。

在一些实施例中，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。通信设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该通信设备执行图7所示的流程。

在一些实施例中，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。通信设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该通信设备执行图8所示的流程。

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

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

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

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

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

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

本申请中术语“至少一个”的含义是指一个或多个，本申请中术语“多个”的含义是指两个或两个以上。

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

Claims (43)

1.一种文件传输的方法，其特征在于，所述方法包括：

第一端与第二端建立基于QUIC协议的文件传输协议FTP会话；

在所述FTP会话内，所述第一端基于第一QUIC流stream向所述第二端发送至少一个第一FTP文件。

2.根据权利要求1所述的方法，其特征在于，所述第一端与第二端建立基于QUIC协议的FTP会话，包括：

所述第一端与所述第二端建立第一QUIC连接；

所述第一端基于第一QUIC stream向所述第二端发送至少一个第一FTP文件，包括：

所述第一端确定所述第一QUIC连接内的至少一个数据stream；

所述第一端基于所述至少一个数据stream向所述第二端发送所述至少一个第一FTP文件。

3.根据权利要求2所述的方法，其特征在于，所述至少一个数据stream的数目为N，所述至少一个第一FTP文件的数目为所述N，所述N为大于1的整数，所述第一端基于所述至少一个数据stream向所述第二端发送所述至少一个第一FTP文件，包括：

所述第一端通过N个数据stream向所述第二端发送N个第一FTP文件，所述N个第一FTP文件中的第一FTP文件与所述N个数据stream中的数据stream一一对应。

4.根据权利要求3所述的方法，其特征在于，所述第一端通过N个数据stream向所述第二端发送N个第一FTP文件，包括：

所述第一端通过所述N个数据stream向所述第二端并行发送所述N个第一FTP文件；或者，

所述第一端通过所述N个数据stream向所述第二端串行发送所述N个第一FTP文件。

5.根据权利要求2所述的方法，其特征在于，所述至少一个数据stream为第一数据stream，所述第一端基于所述至少一个数据stream向所述第二端发送所述至少一个第一FTP文件，包括：

所述第一端通过所述第一数据stream向所述第二端串行发送所述至少一个第一FTP文件。

6.根据权利要求2至5任一项所述的方法，其特征在于，目标FTP文件的第一个报文中包括传输所述目标FTP文件的数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文，所述目标FTP文件为所述至少一个第一FTP文件中的任一个FTP文件。

7.根据权利要求3或4所述的方法，其特征在于，所述方法还包括：

在所述FTP会话内，所述第一端基于QUIC控制stream向所述第二端发送控制信息，所述控制信息包括所述N个第一FTP文件与所述N个数据stream的对应关系。

8.根据权利要求2至6任一项所述的方法，其特征在于，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于发送控制信息，所述第一端与第二端建立基于QUIC协议的FTP会话，还包括：

所述第一端通过所述至少一个控制stream与所述第二端建立FTP会话。

9.根据权利要求2至6任一项所述的方法，其特征在于，所述第一端与第二端建立基于QUIC协议的FTP会话，还包括：

所述第一端与所述第二端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；

所述第一端通过所述至少一个控制stream与所述第二端建立FTP会话。

10.根据权利要求8所述的方法，其特征在于，所述第一QUIC连接对应一条路径path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，

所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

11.根据权利要求9所述的方法，其特征在于，所述第一QUIC连接和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

12.根据权利要求10或11所述的方法，其特征在于，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，N个数据stream对应的path不相同。

13.根据权利要求1至12任一项所述的方法，其特征在于，所述方法还包括：

在所述FTP会话内，所述第一端接收所述第二端基于第二QUIC stream发送的至少一个第二FTP文件。

14.根据权利要求13所述的方法，其特征在于，所述第二QUIC stream与所述第一QUICstream为相同的流，或者，所述第二QUIC stream与所述第一QUIC stream为不同的流。

15.根据权利要求1至14任一项所述的方法，其特征在于，所述第一端和所述第二端属于一个设备的不同模块；或者，所述第一端和所述第二端分别属于不同的设备。

16.一种文件传输的方法，其特征在于，所述方法包括：

第二端与第一端建立基于QUIC协议的文件传输协议FTP会话；

在所述FTP会话内，所述第二端基于QUIC流stream接收所述第一端发送的至少一个FTP文件。

17.根据权利要求16所述的方法，其特征在于，所述第二端与第一端建立基于QUIC协议的FTP会话，包括：

所述第二端与所述第一端建立第一QUIC连接，所述第一QUIC连接包括至少一个数据stream；

所述第二端基于第一QUIC stream接收所述第一端发送的至少一个FTP文件，包括：

所述第二端基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件。

18.根据权利要求17所述的方法，其特征在于，所述至少一个数据stream的数目为N，所述至少一个FTP文件的数目为所述N，所述N为大于1的整数，所述第二端基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件，包括：

所述第二端通过N个数据stream接收所述第一端发送的N个FTP文件，所述N个FTP文件中的FTP文件与所述N个数据stream中的数据stream一一对应。

19.根据权利要求18所述的方法，其特征在于，所述第二端通过N个数据stream接收所述第一端发送的N个FTP文件，包括：

所述第二端通过所述N个数据stream接收所述第一端并行发送的所述N个FTP文件；或者，

所述第二端通过所述N个数据stream接收所述第一端串行发送的所述N个FTP文件。

20.根据权利要求17所述的方法，其特征在于，所述至少一个数据stream为第一数据stream，所述第二端基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件，包括：

所述第二端通过所述第一数据stream接收所述第一端串行发送的所述至少一个FTP文件。

21.根据权利要求18或19所述的方法，其特征在于，所述方法还包括：

在所述FTP会话内，所述第二端基于QUIC控制stream接收所述第一端发送的控制信息，所述控制信息包括所述N个FTP文件与所述N个数据stream的对应关系。

22.根据权利要求17至20任一项所述的方法，其特征在于，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于接收控制信息，所述第二端与第一端建立基于QUIC协议的FTP会话，还包括：

所述第二端通过所述至少一个控制stream与所述第一端建立FTP会话。

23.根据权利要求17至20任一项所述的方法，其特征在于，所述第二端与第一端建立基于QUIC协议的FTP会话，还包括：

所述第二端与所述第一端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；

所述第二端通过所述至少一个控制stream与所述第一端建立FTP会话。

24.根据权利要求22所述的方法，其特征在于，所述第一QUIC连接对应一条路径path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者；

所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

25.根据权利要求23所述的方法，其特征在于，所述第一QUIC和所述第二QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

26.根据权利要求24或25所述的方法，其特征在于，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，N个数据stream对应的path不相同。

27.根据权利要求17至26任一项所述的方法，其特征在于，所述至少一个FTP文件中目标FTP文件的第一个报文中包括传输所述目标FTP文件的目标数据stream的stream标识，所述第一个报文为所述目标FTP文件的第一个数据块所在的报文。

28.根据权利要求27所述的方法，其特征在于，所述第二端基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件，包括：

所述第二端基于接收到的所述第一个报文，获得所述目标数据stream对应的实例；

所述第二端将接收到的所述目标FTP文件的数据写入所述实例对应的缓存区；

所述第二端根据所述缓存区的数据获得所述目标FTP文件。

29.根据权利要求16至28任一项所述的方法，其特征在于，所述方法还包括：

所述第二端向用户展示所述至少一个FTP文件的接收比例。

30.一种文件传输的系统，其特征在于，所述系统包括第一端和第二端；

所述第一端用于：与所述第二端建立基于QUIC协议的文件传输协议FTP会话；在所述FTP会话内，基于QUIC流stream向所述第二端发送至少一个FTP文件；

所述第二端用于：与所述第一端建立基于QUIC协议的所述FTP会话；在所述FTP会话内，基于所述QUIC stream接收所述第一端发送的至少一个FTP文件。

31.根据权利要求30所述的系统，其特征在于，所述第一端用于：与所述第二端建立第一QUIC连接；确定所述第一QUIC连接内的至少一个数据stream；基于所述至少一个数据stream向所述第二端发送所述至少一个FTP文件；

所述第二端用于：与所述第一端建立第一QUIC连接；基于所述至少一个数据stream接收所述第一端发送的所述至少一个FTP文件。

32.根据权利要求31所述的系统，其特征在于，所述至少一个数据stream的数目为N，所述至少一个FTP文件的数目为所述N，所述N为大于1的整数，所述第一端用于：通过N个数据stream向所述第二端发送N个FTP文件，所述N个FTP文件中的FTP文件与所述N个数据stream中的数据stream一一对应；

所述第二端用于：通过所述N个数据stream接收所述第一端发送的所述N个FTP文件。

33.根据权利要求32所述的系统，其特征在于，所述第一端用于：通过所述N个数据stream向所述第二端并行发送所述N个FTP文件；或者，通过所述N个数据stream向所述第二端串行发送所述N个FTP文件；

所述第二端用于：通过所述N个数据stream接收所述第一端并行发送的所述N个FTP文件；或者，通过所述N个数据stream接收所述第一端串行发送的所述N个FTP文件。

34.根据权利要求32或33所述的系统，其特征在于，所述第一端还用于：在所述FTP会话内，基于QUIC控制stream向所述第二端发送控制信息，所述控制信息包括所述N个FTP文件与所述N个数据stream的对应关系；

所述第二端还用于：基于QUIC控制stream接收所述第一端发送的所述控制信息。

35.根据权利要求31至34任一项所述的系统，其特征在于，所述第一QUIC连接还包括至少一个控制stream，所述至少一个控制stream用于发送控制信息，所述第一端还用于：通过所述至少一个控制stream与所述第二端建立FTP会话；

所述第二端还用于：通过所述至少一个控制stream与所述第一端建立FTP会话。

36.根据权利要求31至34任一项所述的系统，其特征在于，所述第一端还用于：与所述第二端建立第二QUIC连接，所述第二QUIC连接包括至少一个控制stream，所述至少一个控制stream用于发送控制信息；通过所述至少一个控制stream与所述第二端建立FTP会话；

所述第二端还用于：与所述第一端建立第二QUIC连接；通过所述至少一个控制stream与所述第一端建立FTP会话。

37.根据权利要求35所述的系统，其特征在于，所述第一QUIC连接对应一条路径path，任一数据stream对应的用户数据报协议UDP报文与任一控制stream对应的UDP报文不相同；或者，

所述第一QUIC连接对应多条path，任一数据stream对应的path与任一控制stream对应的path不相同。

38.根据权利要求37所述的系统，其特征在于，当所述至少一个数据stream的数目为N时，在所述多条path的数目等于N+1的情况下，N个数据stream对应的path不相同。

39.一种通信设备，其特征在于，所述通信设备包括处理器和存储器，所述存储器中存储有计算机指令；

所述处理器用于执行所述计算机指令，使得所述通信设备执行如权利要求1至权利要求15中任一项所述的方法。

40.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条计算机指令，所述计算机指令由处理器读取以使通信设备执行如权利要求1至权利要求15中任一项所述的方法。

41.一种通信设备，其特征在于，所述通信设备包括处理器和存储器，所述存储器中存储有计算机指令；

所述处理器用于执行所述计算机指令，使得所述通信设备执行如权利要求16至权利要求29中任一项所述的方法。

42.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条计算机指令，所述计算机指令由处理器读取以使通信设备执行如权利要求16至权利要求29中任一项所述的方法。

43.一种文件传输的系统，其特征在于，所述系统包括第一端和第二端，其中，

所述第一端，用于执行权利要求1至权利要求15中任一项所述的方法；

所述第二端，用于执行权利要求16至权利要求29中任一项所述的方法。

Images