CN114629891A - 文件传输方法、装置、电子设备及计算机可读存储介质 - Google Patents

文件传输方法、装置、电子设备及计算机可读存储介质 Download PDF

Info

Publication number
CN114629891A
CN114629891A CN202111552811.9A CN202111552811A CN114629891A CN 114629891 A CN114629891 A CN 114629891A CN 202111552811 A CN202111552811 A CN 202111552811A CN 114629891 A CN114629891 A CN 114629891A
Authority
CN
China
Prior art keywords
file
block
transmitted
client
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111552811.9A
Other languages
English (en)
Inventor
黎永基
欧阳晔
李旭平
陈计威
王宝红
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Asiainfo Technologies China Inc
Original Assignee
Asiainfo Technologies China Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Asiainfo Technologies China Inc filed Critical Asiainfo Technologies China Inc
Priority to CN202111552811.9A priority Critical patent/CN114629891A/zh
Publication of CN114629891A publication Critical patent/CN114629891A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1806—Go-back-N protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例提供了一种文件传输方法、装置、电子设备及计算机可读存储介质，涉及网络传输领域。包括：通过与服务器建立的TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的UDP端口；接着，基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号；接着，根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功。自定义一套通过TCP连接传输少量控制信息、通过UDP连接传输文件块的特殊文件传输机制，高效利用网络带宽传输文件。

Description

文件传输方法、装置、电子设备及计算机可读存储介质
技术领域
本申请涉及网络传输技术领域，具体而言，本申请涉及一种文件传输方法、装置、电子设备及计算机可读存储介质。
背景技术
随着互联网技术的发展，互联网传输的数据越来越多，客户端与服务器之间的数据交互或文件交互更加频繁，传输的文件也越来越多、越来越大，这也导致了较高的掉线率。在高掉线率网络环境下，使用TCP(Transmission Control Protocol，传输控制协议)协议传输文件，容易导致大量的断线、丢包和重传，从而导致整体的文件传输效率下降。在大数据环境下传输文件或超大文件的过程中，TCP协议的丢包重传进一步加剧了传输效率低下的问题。
发明内容
本申请实施例提供了一种文件传输方法、装置、电子设备及计算机可读存储介质，可以解决大数据环境下传输文件的传输效率低下的问题。技术方案如下：
根据本申请实施例的一个方面，提供了一种文件传输方法，该方法应用于客户端，包括：
通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口；
基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号；
根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功。
在一种可能的实现方式中，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，包括：利用零拷贝方法，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号；和/或，
通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，包括：利用零拷贝方法，通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，通过UDP端口从服务器接收待传输文件的每个文件块，包括：
通过UDP端口，从服务器接收待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，在根据每个文件块的校验码对每个文件块进行校验之前，还包括：
通过与预定压缩方法相对应的解压缩方法对每个文件块进行解压缩、以及通过与预定加密方法对应的解密方法对每个文件块进行解密。
在一种可能的实现方式中，在根据每个文件块的校验码对每个文件块进行校验之后，还包括：
通过TCP连接，接收服务器发送的用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
响应于请求消息，通过TCP连接，向服务器返回未接收成功的文件块的块编号，以使得服务器根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
根据本申请实施例的另一个方面，提供了一种文件传输方法，该方法应用于服务器，包括：
通过与客户端建立的TCP连接，向客户端发送待传输文件的属性信息，并通过TCP连接从客户端接收用于传输待传输文件的用户数据包协议UDP端口；
基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，以使得客户端根据每个文件块的校验码对每个文件块进行校验，来确认每个文件块是否接收成功。
在一种可能的实现方式中，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，包括：利用零拷贝方法，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号；和/或，
通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，包括：利用零拷贝方法，通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，通过UDP端口向客户端发送待传输文件的每个文件块，包括：
通过预定压缩方法对待传输文件的每个文件块进行压缩，以及通过预定加密方法对待传输文件的每个文件块进行加密；
通过UDP端口，向客户端发送待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，在基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号之后，还包括：
通过TCP连接，向客户端发送用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
接收客户端针对请求消息返回的响应消息，响应消息携带有客户端未接收成功的文件块的块编号；
根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
根据本申请实施例的另一个方面，提供了一种文件传输装置，该装置应用于客户端，包括：
第一处理模块，用于通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口；
接收模块，用于基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号；
第二处理模块，根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功。
在一种可能的实现方式中，接收模块用于：利用零拷贝方法，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号；和/或，接收模块用于：利用零拷贝方法，通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，接收模块用于：通过UDP端口，从服务器接收待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，该装置还包括第一预处理模块，该预处理模块用于：通过与预定压缩方法相对应的解压缩方法对每个文件块进行解压缩、以及通过与预定加密方法对应的解密方法对每个文件块进行解密。
在一种可能的实现方式中，该装置还包括第一传输模块，该第一传输模块用于：
通过TCP连接，接收服务器发送的用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
响应于请求消息，通过TCP连接，向服务器返回未接收成功的文件块的块编号，以使得服务器根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
根据本申请实施例的又一个方面，提供了一种文件传输装置，该装置应用于服务器，包括：
第三处理模块，用于通过与客户端建立的TCP连接，向客户端发送待传输文件的属性信息，并通过TCP连接从客户端接收用于传输待传输文件的用户数据包协议UDP端口；
第四处理模块，用于基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，以使得客户端根据每个文件块的校验码对每个文件块进行校验，来确认每个文件块是否接收成功。
在一种可能的实现方式中，第四处理模块用于：利用零拷贝方法，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号；和/或，第四处理模块用于：利用零拷贝方法，通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，第四处理模块用于：
通过预定压缩方法对待传输文件的每个文件块进行压缩，以及通过预定加密方法对待传输文件的每个文件块进行加密；
通过UDP端口，向客户端发送待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，该装置还包括第二传输模块，该传输模块用于：
通过TCP连接，向客户端发送用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
接收客户端针对请求消息返回的响应消息，响应消息携带有客户端未接收成功的文件块的块编号；
根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
根据本申请实施例的另一个方面，提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，处理器执行计算机程序以实现上述的文件传输方法的步骤。
根据本申请实施例的再一个方面，提供了一种计算机可读存储介质，计算机程序被处理器执行时实现上述的文件传输方法的步骤。
根据本申请实施例的一个方面，提供了一种计算机程序产品，计算机程序被处理器执行时实现上述的文件传输方法的步骤。
本申请实施例提供的技术方案带来的有益效果是：通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，并重传未成功接收的文件块，最终完成所有文件块的成功接收。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的一种文件传输方法的流程示意图；
图2为本申请实施例提供的另一种文件传输方法的流程示意图；
图3为本申请实施例提供的服务器传输文件的整体流程示意图；
图4为本申请实施例提供的客户端传输文件的整体流程示意图；
图5为本申请实施例提供的一种文件传输装置的结构示意图；
图6为本申请实施例提供的另一种文件传输装置的结构示意图；
图7为本申请实施例提供的一种电子设备的结构示意。
具体实施方式
下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”指示实现为“A”，或者实现为“A”，或者实现为“A和B”。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
先对本申请涉及的几个名词进行介绍和解释：
TCP：Transmission Control Protocol，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是面向连接的，旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。
UDP：User Datagram Protocol，用户数据包协议。UDP为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法。UDP是面向无连接的，它除了给应用程序发送数据包功能并允许它们在所需的层次上架构自己的协议之外，几乎没有做什么特别的事情。
传统的TCP传输协议带有网络流量和拥塞控制机制，可实现普通文件可靠高效的传输。然而，在高掉线率下传输大件时却无法充分利用网络带宽。其核心原因是大量掉线导致了重传和拥塞控制而主动下调了网络传输速度，最终导致网络带宽的浪费。
现有UDP协议是一个非可靠传输协议，并且没有网络流量和拥塞控制机制。基于UDP协议也可以实现文件可靠传输，然而，其基本实现原理与TCP协议的重传机制保持一致，很多UDP协议也通过时间窗口进行重传控制，制约了网络带宽的充分利用。究其原因是这些基于UDP协议进行文件传输的方案参考了TCP协议的重传和拥塞控制，基于某个时间窗口内的数据传输时延、丢包率等统计值进行传输速度的控制。
对于大文件传输而言，除了需要解决传输速度和效率问题，还要考虑实现方案的内存占用问题。因为，文件非常大的情况下，接收缓冲区往往较大，致使内存占用太高，容易导致程序崩溃，如果缓冲区太小又可能导致客户端接收效率下降，进一步导致整体网络带宽利用率的下降。其中，内存占用高的原因是文件的数据需要多次复制才可以传输到发送方网卡的缓冲区：第一次从磁盘复制到内核态缓冲区，第二次从内核态缓冲区复制到用户程序的缓冲区(用户态)，第三次从用户程序复制到socket接口的缓冲区，最后一次从socket接口的缓冲区复制到网卡缓冲区；从网卡接收数据时情况类似，只是方向相反。
针对上述情况，本申请提出一种文件传输的方案，通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，并重传未成功接收的文件块，最终完成所有文件块的成功接收。
个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。
图1为本申请实施例提供的文件传输方法的流程示意图，如图1所示，该方法应用于客户端，包括：
步骤S110：通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向所述服务器发送用于接收待传输文件的用户数据包协议UDP端口。
在实际应用中，客户端先与服务器通过TCP协议建立TCP连接，客户端与服务器建立TCP连接以后，客户端可以通过其与服务器建立的TCP连接进行信息传输，尤其是进行数据量比较小的控制信息的传输。比如，客户端可以通过其与服务器建立的TCP连接，从服务器接收待传输文件的属性信息，即客户端接收服务器通过建立的TCP连接发送的待传输文件的属性信息。又比如，客户端通过其与服务器建立的TCP连接，向服务器发送用于接收待传输文件的UDP端口，即将客户端接收待传输文件的UDP端口告知服务器。
在一个示例中，待传输文件的属性信息包括但不限于待传输文件的文件名、待传输文件的总大小(例如200M、2G、1T等等)、待传输文件的每文件块的大小(20M、60M、100M等等)、待传输文件的加密方式等。其中，待传输文件的属性信息可以算是数据量比较小的控制信息中的一种；客户端接收待传输文件的UDP端口也算是数据量比较小的控制信息中的一种。
步骤S120：基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号。
客户端接收到待传输文件的属性信息后，基于该属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，即通过UDP端口接收服务器发送的待传输文件的每个文件块和每个文件块的块编号。其中，客户端接收到服务器发送的待传输文件的每个文件块和每个文件块的块编号后，可以将每个文件块和每个文件块的块编号对应存储起来，即文件块和文件块的块编号是一一对应的。
在实际应用中，服务器在向客户端发送待传输文件(例如文件F1)之前，可以先对待传输文件进行文件分块处理，比如把待传输文件分隔为预定大小的若干个文件块，其中，每个文件块的大小是固定的，比如每个文件块的大小固定为5M、10M、20M等等，本申请实施例不对其作限制。在一个示例中，假如待传输文件是F1，且F1的大小是2G，则服务器在向客户端发送F1之前，可以先把F1分隔成预定大小为20M的若干个文件块。
在实际应用中，服务器将待传输文件分隔为预定大小的若干个文件块后，为了便于标识各个文件块，可以为各个文件块标记各自相应的块编号。比如，可以将F1的各个文件块分别记作B1、B2、...、B100，B1、B2、...、B100分别为相应文件块的块编号，其中，B1代表第1个文件块(即第1个文件块的块编号是B1)，B2代表第2个文件块(即第2个文件块的块编号是B2)，以此类推，B100代表第100个文件块(即第100个文件块的块编号是B100)。
需要说明的是，如果服务器在将待传输文件分隔成预定大小(例如20M)的若干个文件块的过程中，若出现最后一个文件块的实际大小(例如10M)小于上述的预定大小(例如20M)时，在一种情况下，可以保留该最后一个文件块的实际大小(例如10M)，即保持最后一个文件块的实际大小(例如10M)，而无需填充至预定大小(例如20M)；在另一种情况下，可以不保留该最后一个文件块的实际大小(例如10M)，而是将该最后一个文件块的大小(例如10M)填充至预定大小(例如20M)。
服务器将待传输文件分隔为预定大小的若干个文件块之后，可以通过通过UDP端口将待传输文件的每个文件块和每个文件块的块编号发送给客户端。在一个示例中，服务器将第1个文件块及第1个文件块的块编号(例如B1)、第2个文件块及第2个文件块的块编号(例如B2)、...、第100个文件块及第100个文件块的块编号(例如B100)通过UDP端口发送给客户端。
服务器通过UDP端口向客户端发送各个文件块及各个文件块各自对应的块编号的同时，会通过先前与客户端建立的TCP连接，向客户端发送待传输文件的每个文件块的校验码和每个文件块的块编号。需要说明的是，服务器将待传输文件分隔为预定大小的若干个文件块后，除了用相应的块编号标识各个文件块外，还会生成各个文件块各自对应的校验码。
以上述的文件块B1、B2、...、B100为例，服务器会生成第1个文件块的校验码(例如C1)、第2个文件块的校验码(例如C2)、...、第100个文件块的校验码(例如C100)。在生成各个文件块各自对应的校验码后，服务器通过先前与客户端建立的TCP连接，待传输文件的每个文件块的校验码和每个文件块的块编号发送给客户端，便于客户端利用接收到的各个文件块各自对应的校验码，对相应的各个文件块进行校验，例如，利用校验码C1对第1个文件块进行校验，利用校验码C2对第2个文件块进行校验，以此类推，利用校验码C100对第100个文件块进行校验。
在一个示例中，客户端接收到服务器发送的待传输文件的每个文件块的校验码和每个文件块的块编号后，可以将每个文件块的校验码和每个文件块的块编号对应存储起来，即文件块的校验码和文件块的块编号是一一对应的。
需要说明的是，上述的校验码可以是HASH(哈希)校验码，该HASH(哈希)校验码可以是利用MD5或SHA生成的。当然，除了上述的HASH(哈希)校验码外，还可以是其他可行的校验码，本申请实施例不对其作限制。HASH(哈希)校验码除了可以是MD5或SHA生成的之外，还可以是由其它加密方式生成的，本申请实施例同样不对其作限制。
步骤S130：根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功。
换言之，客户端可以根据每个文件块的校验码对每个文件块进行校验，来确定每个文件块是否被成功接收，也即确定是否已成功接收到每个文件块。
在实际应用中，客户端可以通过文件块的块编码号查找到对应的校验码，同时可以通过文件块的块编号查找到对应的文件块，从而可以利用该查找到的校验码对应该查找到的文件块进行校验，以确定该文件块是否被成功接收。在一个示例中，如果通过一个文件块的校验码(例如C5)对该一个文件块(例如B5)进行校验、且校验通过，则说明该一个文件块已被成功接收；如果通过一个文件块的校验码(例如C8)对该一个文件块(例如B8)进行校验、且校验不通过，则说明该一个文件块未被成功接收。
其中，客户端可以根据需要记录已被成功接收的文件块和未被成功接收的文件块。在实际应用中，可以根据需要，将未被成功接收的文件块和已被成功接收的文件块分开存储，例如：一个记录表(Table1)用于记录未被成功接收的文件块的块编号，另一个记录表(Table2)用于记录已被成功接收的文件块的块编号。
本申请实施例提供的方法，通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，并重传未成功接收的文件块，最终完成所有文件块的成功接收。
在本申请实施例的一种可能的实现方式中，可以利用零拷贝方法，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号；和/或，利用零拷贝方法，通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号。
其中，零拷贝方法(或零拷贝技术)是指数据从文件系统到发送缓冲区并没有经过多次的拷贝，而是通过直接把内核态缓冲区数据传输到socket接口的缓冲区或者反方向，因此大大降低内存的占用。例如在java语言中使用NIO调用就可以使用零拷贝技术。在其他程序设计语言中也有类似的系统调用，可以支持内核态缓冲区的直接使用。
此外，零拷贝是指计算机操作的过程中，CPU不需要为数据在内存之间的拷贝消耗资源。通常是指计算机在网络上发送文件时，不需要将文件内容拷贝到用户空间(UserSpace)而直接在内核空间(Kernel Space)中传输到网络的方式。
采用零拷贝方法可以减少甚至完全避免不必要的CPU拷贝，从而让CPU解脱出来去执行其他的任务，可以减少内存带宽的占用，还能够减少用户空间和操作系统内核空间之间的上下文切换。
需要说明的是，零拷贝技术在实际的实现中并没有真正的标准，而是取决于操作系统如何实现。零拷贝技术完全依赖于操作系统，操作系统支持，就可以采用零拷贝技术；操作系统不支持，就不能采用零拷贝技术，而不依赖于Java本身。
本申请实施例，在服务器和客户端之间的发送和接收过程中使用多线程发送和接收，并使用硬件系统的零拷贝技术降低内存使用率或占用率，通过使用零拷贝技术加强了服务器和客户端程序的健壮性，提高系统健壮性，有效避免了常规技术中大文件传输导致的文件缓冲区占用大量内存，及其导致的系统不稳定情况。
在本申请实施例的一种可能的实现方式中，通过UDP端口从服务器接收待传输文件的每个文件块的步骤，具体可以是：通过UDP端口，从服务器接收待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在实际应用中，由于待传输文件或待传输文件块所携带的信息量越来越大，考虑到其在输过程中的安全性以及占用的带宽资源，为了更快、更好的传输，同时可保护文件不受损坏，服务器在发送待传输文件的每个文件块之前，可以先对待传输的文件块进行压缩和加密，然后再通过UDP端口将经过压缩和加密后的文件块发送给客户端。相对应地，客户端通过UDP端口，接收服务器发送的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一个示例中，服务器可以先采用预定压缩方法对待传输文件块进行压缩，得到压缩后的文件块，再对经过压缩后的文件块采用预定加密方法进行加密，得到经加密后的文件块，然后，服务器再通过UDP端口将经加密后的文件块发送给客户端。相对应地，客户端通过UDP端口，接收服务器发送的先经过预定压缩方法压缩后的、再经过预定加密方法加密后的每个文件块。
在另一示例中，服务器可以采用预定加密方法对待传输文件块进行加密，得到加密后的文件块，再对经过加密后的文件块采用预定压缩方法进行压缩，得到经压缩后的文件块，然后，服务器再通过UDP端口将经压缩后的文件块发送给客户端。相对应地，客户端通过UDP端口，接收服务器发送的先经过预定加密方法加密后的、再经过预定压缩方法压缩后的每个文件块。
上述的预定压缩方法除了可以是LZ4、Gzip等外，还可以是当前比较常用的其它压缩方法，本申请实施例不对其作限制。上述的预定加密方法不仅可以是MD5、SHA1(哈希算法的一种)、RSA(非对称加密算法)、AES(Advanced Encryption Standard，高级加密标准)、DES(Data Encryption Standard，数据加密标准)等，还可以是当前比较常用的其它加密方法，本申请实施例不对其作限制。
在本申请实施例的一种可能的实现方式中，在根据每个文件块的校验码对每个文件块进行校验之前，可以采用如下处理：通过与预定压缩方法相对应的解压缩方法对每个文件块进行解压缩、以及通过与预定加密方法对应的解密方法对每个文件块进行解密。
在一个示例中，客户端通过UDP端口，接收到服务器发送的先经过预定压缩方法压缩后的、再经过预定加密方法加密后的每个文件块后，要对接收到的文件块先进行解密，再对解密后的文件块进行解压缩。其中，客户端在对接收到的文件块进行解密时，需要采用与服务器端的加密方法相对应的解密方法进行解密，同样地，客户端在对解密后的文件块进行解压缩时，需要采用与服务器端的压缩方法相对应的解压缩方法进行解压缩。
在另一示例中，客户端通过UDP端口，接收到服务器发送的先经过预定加密方法加密后的、再经过预定压缩方法压缩后的每个文件块后，要对接收到的文件块先进行解压缩，再对解压缩后的文件块进行解密。其中，客户端在对接收到的文件块进行解压缩时，需要采用与服务器端的压缩方法相对应的解压缩方法进行解压缩，同样地，客户端在对解压缩后的文件块进行解密时，需要采用与服务器端的加密方法相对应的解密方法进行解密。
在一种可能的实现方式中，在根据每个文件块的校验码对每个文件块进行校验之后，还可以采用如下处理：
通过TCP连接，接收服务器发送的用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
响应于请求消息，通过TCP连接，向服务器返回未接收成功的文件块的块编号，以使得服务器根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
服务器发送完待传输文件的所有文件块后，可以通过TCP连接向客户端发送一个请求消息，该请求消息用于向客户端请求确认待传输文件的每个文件块是否均已接收成功，即请求确认待传输文件的所有文件块是否均已被客户端成功接收。其中，客户端根据一个文件块的校验码对该一个文件块校验通过的，则认为该一个文件块已被客户端成功接收，否则，认为该一个文件块未被客户端成功接收。
客户端响应于服务器的请求消息，会返回相应的响应消息，该响应消息也通过TCP连接发送给服务器，且该响应消息携带未被客户端成功接收的文件块的块编号，在一示例中，该响应消息可以携带一个未成功接收表格(例如Table1)，该表格记录了未被客户端成功接收的各个文件块各自对应的块编号。
在一个示例中，当客户端已成功接收待传输文件的所有文件块时，即未被客户端成功接收的文件块为0，也即表格中的记录为空时，客户端同样会返回一个响应消息，只不过该响应消息中携带的表格(例如Table1)的记录为空。相应地，服务器接收到携带记录为空的表格的响应消息时，即可判定待传输文件的所有文件块均被客户端成功接收。
在一个示例中，当客户端存在未成功接收待传输文件的某个或某几个文件块时，比如，文件块B5、文件块B20、文件块B50及文件块B98未被成功接收，客户端会在未成功接收表格(例如Table1)中记录未被成功接收的文件块的块编号(即B5、B20、B50及B98)。当客户端接收到服务器发送的请求消息后，响应于该请求消息会返回一个响应消息，该响应消息携带了记录未被成功接收的文件块的块编号的表格(例如Table1)。相应地，服务器接收到该响应消息后，会根据其携带的未成功接收的文件块的块编号，确定出没有被成功接收的文件块，并针对未被成功接收的文件块进行重传，即再次通过UDP端口将未被成功接收的文件块及未被成功接收的文件块的块编号一并发送给客户端，以便客户端最终成功完成整个待传输文件的所有文件块的接收。
图2为本申请实施例提供的文件传输方法的流程示意图，如图2所示，该方法应用于服务器，包括：
步骤S210，通过与客户端建立的TCP连接，向客户端发送待传输文件的属性信息，并通过TCP连接从客户端接收用于传输待传输文件的用户数据包协议UDP端口；
步骤S220，基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，以使得客户端根据每个文件块的校验码对每个文件块进行校验，来确认每个文件块是否接收成功。
本申请实施例所提供的服务器侧的文件传输方法，是与本申请实施例提供的客户端侧的文件传输方法相对应地，因此，可以理解的是，服务器侧的文件传输的处理步骤是与客户端侧的文件传输的步骤相对应的，即客户端侧的文件传输的步骤的相关内容同样适应于服务器侧的文件传输的处理步骤，在此不再对服务器侧文件传输的处理步骤进行赘述，其中，客户端侧的文件传输的相应步骤的具体描述可以参见前文中的相应描述。
本申请实施例提供的方法，通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，并重传未成功接收的文件块，最终完成所有文件块的成功接收。
在本申请实施例的一种可能的实现方式中，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，包括：利用零拷贝方法，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号；和/或，
通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，包括：利用零拷贝方法，通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号。
在本申请实施例的一种可能的实现方式中，通过UDP端口向客户端发送待传输文件的每个文件块，包括：
通过预定压缩方法对待传输文件的每个文件块进行压缩，以及通过预定加密方法对待传输文件的每个文件块进行加密；
通过UDP端口，向客户端发送待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在本申请实施例的一种可能的实现方式中，在基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号之后，还包括：
通过TCP连接，向客户端发送用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
接收客户端针对请求消息返回的响应消息，响应消息携带有客户端未接收成功的文件块的块编号；
根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
需要说明的是，本申请实施例所提供的服务器侧的文件传输方法，是与本申请实施例提供的客户端侧的文件传输方法相对应地，因此，可以理解的是，服务器侧的文件传输的处理步骤是与客户端侧的文件传输的步骤相对应的，即客户端侧的文件传输的步骤的相关内容同样适应于服务器侧的文件传输的处理步骤，在此不再对服务器侧文件传输的处理步骤进行赘述，其中，客户端侧的文件传输的相应步骤的具体描述可以参见前文中的相应描述。
下面通过具体示例，对本申请实施例的文件传输方法进行具体介绍：
如图3所示，给出了服务器进行文件传输的整体流程的一个示例，具体为：
步骤S301，服务器启动，相当于服务器处于工作状态，为文件传输做好准备。
步骤S302，与客户端建立TCP连接并发送待传输文件的属性信息，即服务器先与客户端通过TCP协议建立TCP连接，服务器与客户端建立TCP连接以后，服务器可以通过其与客户端建立的TCP连接传输待传输文件的属性信息。待传输文件的属性信息包括但不限于待传输文件的文件名、待传输文件的总大小、待传输文件的每文件块的大小、待传输文件的加密方式等。
步骤S303，准备文件分块列表，即服务器在向客户端发送待传输文件(例如文件F1)之前，可以先对待传输文件进行文件分块处理，比如把待传输文件分隔为预定大小的若干个文件块，其中，每个文件块的大小是固定的。
步骤S304，读取一个文件块，即服务器从基于个文件块中确定出一个将要传输给客户端的文件块。
步骤S305，压缩和加密文件块，即服务器在发送待传输文件的某个文件块之前，可以先对该某个文件块进行压缩和加密处理，得到压缩和加密处理后的文件块。
步骤S306，计算校验码，即服务器生成压缩和加密后的文件块的校验码，校验码可以是前文提到的HASH校验码。
步骤S307，通过TCP连接向客户端发送文件块的校验码和块编号，即服务器通过TCP连接向客户端发送经压缩和加密后的某个或某几个文件块的校验码和该某个或某几个文件块各自对应的块编号。
步骤S308，通过UDP端口向客户端发送文件块和文件块的块编号，即服务器可以通过通过UDP端口将待传输文件的每个文件块和每个文件块的块编号发送给客户端，其中，该文件块是经过压缩和加密后的。
步骤S309，判断文件分块列表中所有文件块是否都已发送完毕，如果判定所有文件块均已发送完毕，则执行步骤S310，如果判定尚有文件块没有发送完毕，则重复执行步骤S304至步骤S308。
步骤S310，通过TCP连接向客户端请求确认是否全部接收到所有文件块，即服务器通过TCP连接向客户端发送一个请求消息，该请求消息用于向客户端请求确认待传输文件的每个文件块是否均已接收成功。其中，客户端响应于服务器的请求消息，会返回相应的响应消息。如果接收到客户端返回的未成功接收的文件块的块编号，则重复执行步骤S303至步骤S309，来重传该未被客户端成功接收的文件块及其块编号。如果未接收到客户端返回的块编号或接收到客户端返回的结果为空的响应，则说明客户端已成功接收待传输文件的所有文件块，此时执行步骤S311服务器结束文件传输。
如图4所示，给出了客户端进行文件传输的整体流程的一个示例，具体为：
步骤S401，通过与服务器建立的TCP连接接收待传输文件的属性信息，即服务器先与客户端通过TCP协议建立TCP连接，服务器与客户端建立TCP连接以后，服务器可以通过其与客户端建立的TCP连接传输待传输文件的属性信息，相应地，客户端接收通过与服务器建立的TCP连接接收待传输文件的属性信息。待传输文件的属性信息包括但不限于待传输文件的文件名、待传输文件的总大小、待传输文件的每文件块的大小、待传输文件的加密方式等。
步骤S402，打开UDP端口接收文件块和对应的块编号，即客户端通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号。
步骤S403，检测接收到的文件块的块编号是否已通过校验，如果判定接收到的文件块的块编号是已通过校验的块编号，则说明该块编号对应的文件块不是首次传输，而是服务器的重复传输，此时可以执行步骤S404丢弃文件块，否则，执行步骤S405。
步骤S404，丢弃文件块，即对已经成功接收的文件块不再进行重复接收。
步骤S405，对接收到的文件块进行解压缩和解密。在实际应用中，由于待传输文件或待传输文件块所携带的信息量越来越大，考虑到其在输过程中的安全性以及占用的带宽资源，为了更快、更好的传输，同时可保护文件不受损坏，服务器在发送待传输文件的每个文件块之前，可以先对待传输的文件块进行压缩和加密，然后再通过UDP端口将经过压缩和加密后的文件块发送给客户端。相对应地，客户端通过UDP端口，接收服务器发送的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
步骤S406，写入文件缓冲区，即客户端将已经解压缩和解密后的文件块存储至缓冲区中。
步骤S407，检测是否已接收到已经解压缩和解密后的文件块的校验码，其中，若已接收该校验码，则执行步骤S412，若未接收到该校验码，则执行步骤S408。
步骤S408，接收校验码，即客户端通过与服务器建立的TCP连接，接收各个文件块各自对应的校验码，接收到校验码后，可以将各个文件块与其对应的校验码进行对应存储，或者建立两者之间的一一对应关系。
步骤S409，利用校验码校验文件块，即客户端根据接收到的块编号查找对应的校验码，并利用该校验码来校验该块编号对应的文件块，比如利用块编号B1对应的校验码，来校验块编号B1对应的文件块。
步骤S410，检测是否通过校验，即客户端检测其利用接收到的块编号对应的校验码，来校验该块编号对应的文件块时，检测是否通过校验，如果校验通过则执行步骤S411，否则执行步骤S412。
步骤S411，标记文件块是通过校验的，即记录该文件块是已经通过校验的，比如客户端可以在列表中记录已通过校验的文件块的块编号。
步骤S412，标记文件块未通过校验，即客户端记录该文件块是未通过校验的，比如客户端可以在列表中记录未通过校验的文件块的块编号。
步骤S413，判断接收到的消息是否为服务器请求客户端确认是否全部接收到所有文件块的消息，若是，则执行步骤S416，否则执行步骤S414。因为，服务器不仅可以通过其与客户端建立的TCP连接传输请求消息，该请求消息用于请求客户端确认待传输文件的每个文件块是否均已接收成功，还可以通过其与客户端建立的TCP连接传输待传输文件的每个文件块的校验码和块编号，因此，客户端可以根据需要检测一下该消息。
步骤S414，记录接收到的校验码，客户端执行这一步说明客户端判定步骤S413接收到的消息是用于传输待传输文件的每个文件块的校验码和块编号的，此时客户端可以记录接收到的校验码。
步骤S415，返回未校验通过的文件块的块编号，即客户端通过TCP连接，向服务器返回未接收成功的文件块的块编号，以使得服务器根据未接收成功的文件块的块编号重新发送该未接收成功的文件块和对应的块编号。
步骤S416，检测列表是否为空，即客户端检测用于记录未成功接收的文件块(即未校验通过的文件块)的块编号的列表是否为空，如果该列表为空，说明客户端已成功接收待传输文件的所有文件块，可以执行步骤S417，否则说明客户端仍有未成功接收的待传输文件的文件块，需要服务器继续重复执行步骤S402，来重传该未接收到的文件块。
步骤S417，停止接收，即客户端停止接收服务器发送的文件块，因为已成功接收待传输文件的所有文件块，所以客户端可以停止接收相应的文件块。
步骤S418，判断接收到的块编号对应的文件块是否已经接收到，即客户端在接收到某个块编号(例如B2)对应的校验码后，可以进一步检测该块编号(例如B2)对应的文件块是否已经被接收到，如果判定该文件块已经接收到，则执行步骤S409，否则执行步骤S402。
本申请实施例提供了一种文件传输装置，如图5所示，该装置500可以包括第一处理模块501、接收模块502及第二处理模块503，其中，
第一处理模块501，用于通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口；
接收模块502，用于基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号；
第二处理模块503，根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功。
在一种可能的实现方式中，接收模块用于：利用零拷贝方法，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号；和/或，接收模块用于：利用零拷贝方法，通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，接收模块用于：通过UDP端口，从服务器接收待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，该装置还包括第一预处理模块，该预处理模块用于：通过与预定压缩方法相对应的解压缩方法对每个文件块进行解压缩、以及通过与预定加密方法对应的解密方法对每个文件块进行解密。
在一种可能的实现方式中，该装置还包括第一传输模块，该第一传输模块用于：
通过TCP连接，接收服务器发送的用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
响应于请求消息，通过TCP连接，向服务器返回未接收成功的文件块的块编号，以使得服务器根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
本申请实施例的文件传输装置，通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，实现重传未成功接收的文件块，最终完成所有文件块的成功接收。
本申请实施例的文件传输装置可执行本申请上述实施例所示的文件传输方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。
本申请实施例提供了一种文件传输装置，如图6所示，该装置600可以包括第三处理模块601及第四处理模块602，其中，
第三处理模块601，用于通过与客户端建立的TCP连接，向客户端发送待传输文件的属性信息，并通过TCP连接从客户端接收用于传输待传输文件的用户数据包协议UDP端口；
第四处理模块602，用于基于属性信息，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号，以使得客户端根据每个文件块的校验码对每个文件块进行校验，来确认每个文件块是否接收成功。
在一种可能的实现方式中，第四处理模块用于：利用零拷贝方法，通过UDP端口向客户端发送待传输文件的每个文件块和每个文件块的块编号；和/或，第四处理模块用于：利用零拷贝方法，通过TCP连接向客户端发送待传输文件的每个文件块的校验码和块编号。
在一种可能的实现方式中，第四处理模块用于：
通过预定压缩方法对待传输文件的每个文件块进行压缩，以及通过预定加密方法对待传输文件的每个文件块进行加密；
通过UDP端口，向客户端发送待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
在一种可能的实现方式中，该装置还包括第二传输模块，该传输模块用于：
通过TCP连接，向客户端发送用于确认待传输文件的每个文件块是否均已接收成功的请求消息；
接收客户端针对请求消息返回的响应消息，响应消息携带有客户端未接收成功的文件块的块编号；
根据未接收成功的文件块的块编号重新发送未接收成功的文件块和对应的块编号。
本申请实施例的文件传输装置，通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，实现重传未成功接收的文件块，最终完成所有文件块的成功接收。
本申请实施例的文件传输装置可执行本申请上述实施例所示的文件传输方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。
本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现确定网络覆盖的方法的步骤，与现有技术相比可实现：通过与服务器建立的传输控制协议TCP连接，从服务器接收待传输文件的属性信息，并通过TCP连接向服务器发送用于接收待传输文件的用户数据包协议UDP端口，为后续文件高效传输提供前提保障；基于属性信息，通过UDP端口从服务器接收待传输文件的每个文件块和每个文件块的块编号，以及通过TCP连接从服务器接收待传输文件的每个文件块的校验码和块编号，从而自定义了一套通过TCP连接传输少量的控制信息、通过UDP连接传输文件块的特殊文件传输机制，不需要额外的握手机制，且能够充分利用UDP的顺序无关特性，无需等待文件前面部分传输完成即可继续发送文件后面部分，抛弃了传统的网络流量和拥塞控制机制，使得在高掉线率网络环境下，可以高效利用网络带宽可靠、高速的传输大文件的能力，有效避免因数据传输时延、丢包率等而下调数据传输速度；通过根据每个文件块的校验码对每个文件块进行校验，以确认每个文件块是否接收成功，便于快速、准确地确定出未成功接收的文件块，并重传未成功接收的文件块，最终完成所有文件块的成功接收。
在一个可选实施例中提供了一种电子设备，如图7所示，图7所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。
处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。
总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。
存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。
本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。
本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。
应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。
以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (14)

1.一种文件传输方法，其特征在于，应用于客户端，包括：
通过与服务器建立的传输控制协议TCP连接，从所述服务器接收待传输文件的属性信息，并通过所述TCP连接向所述服务器发送用于接收所述待传输文件的用户数据包协议UDP端口；
基于所述属性信息，通过所述UDP端口从所述服务器接收所述待传输文件的每个文件块和每个文件块的块编号，以及通过所述TCP连接从所述服务器接收所述待传输文件的每个文件块的校验码和块编号；
根据所述每个文件块的校验码对所述每个文件块进行校验，以确认所述每个文件块是否接收成功。
2.根据权利要求1所述的方法，其特征在于，所述通过所述UDP端口从所述服务器接收所述待传输文件的每个文件块和每个文件块的块编号，包括：利用零拷贝方法，通过所述UDP端口从所述服务器接收所述待传输文件的每个文件块和每个文件块的块编号；和/或，
所述通过所述TCP连接从所述服务器接收所述待传输文件的每个文件块的校验码和块编号，包括：利用零拷贝方法，通过所述TCP连接从所述服务器接收所述待传输文件的每个文件块的校验码和块编号。
3.根据权利要求1或2所述的方法，其特征在于，所述通过所述UDP端口从所述服务器接收所述待传输文件的每个文件块，包括：
通过所述UDP端口，从所述服务器接收所述待传输文件的经过预定压缩方法压缩后的、以及经过预定加密方法加密后的每个文件块。
4.根据权利要求3所述的方法，其特征在于，在所述根据所述每个文件块的校验码对所述每个文件块进行校验之前，还包括：
通过与所述预定压缩方法相对应的解压缩方法对所述每个文件块进行解压缩、以及通过与所述预定加密方法对应的解密方法对所述每个文件块进行解密。
5.根据权利要求1-4任一项所述的方法，其特征在于，在所述根据所述每个文件块的校验码对所述每个文件块进行校验之后，还包括：
通过所述TCP连接，接收所述服务器发送的用于确认所述待传输文件的每个文件块是否均已接收成功的请求消息；
响应于所述请求消息，通过所述TCP连接，向所述服务器返回未接收成功的文件块的块编号，以使得所述服务器根据所述未接收成功的文件块的块编号重新发送所述未接收成功的文件块和对应的块编号。
6.一种文件传输方法，其特征在于，应用于服务器，包括：
通过与客户端建立的TCP连接，向所述客户端发送待传输文件的属性信息，并通过所述TCP连接从所述客户端接收用于传输所述待传输文件的用户数据包协议UDP端口；
基于所述属性信息，通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块和每个文件块的块编号，以及通过所述TCP连接向所述客户端发送所述待传输文件的每个文件块的校验码和块编号，以使得所述客户端根据所述每个文件块的校验码对所述每个文件块进行校验，来确认所述每个文件块是否接收成功。
7.根据权利要求6所述的方法，其特征在于，所述通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块和每个文件块的块编号，包括：利用零拷贝方法，通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块和每个文件块的块编号；和/或，
所述通过所述TCP连接向所述客户端发送所述待传输文件的每个文件块的校验码和块编号，包括：利用零拷贝方法，通过所述TCP连接向所述客户端发送所述待传输文件的每个文件块的校验码和块编号。
8.根据权利要求6或7所述的方法，其特征在于，所述通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块，包括：
通过预定压缩方法对所述待传输文件的每个文件块进行压缩，以及通过预定加密方法对所述待传输文件的每个文件块进行加密；
通过所述UDP端口，向所述客户端发送所述待传输文件的经过所述预定压缩方法压缩后的、以及经过所述预定加密方法加密后的每个文件块。
9.根据权利要求6-8任一项所述的方法，其特征在于，在所述基于所述属性信息，通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块和每个文件块的块编号，以及通过所述TCP连接向所述客户端发送所述待传输文件的每个文件块的校验码和块编号之后，还包括：
通过所述TCP连接，向所述客户端发送用于确认所述待传输文件的每个文件块是否均已接收成功的请求消息；
接收客户端针对所述请求消息返回的响应消息，所述响应消息携带有所述客户端未接收成功的文件块的块编号；
根据所述未接收成功的文件块的块编号重新发送所述未接收成功的文件块和对应的块编号。
10.一种文件传输装置，其特征在于，应用于客户端，包括：
第一处理模块，用于通过与服务器建立的传输控制协议TCP连接，从所述服务器接收待传输文件的属性信息，并通过所述TCP连接向所述服务器发送用于接收所述待传输文件的用户数据包协议UDP端口；
接收模块，用于基于所述属性信息，通过所述UDP端口从所述服务器接收所述待传输文件的每个文件块和每个文件块的块编号，以及通过所述TCP连接从所述服务器接收所述待传输文件的每个文件块的校验码和块编号；
第二处理模块，根据所述每个文件块的校验码对所述每个文件块进行校验，以确认所述每个文件块是否接收成功。
11.一种文件传输装置，其特征在于，应用于服务器，包括：
第三处理模块，用于通过与客户端建立的TCP连接，向所述客户端发送待传输文件的属性信息，并通过所述TCP连接从所述客户端接收用于传输所述待传输文件的用户数据包协议UDP端口；
第四处理模块，用于基于所述属性信息，通过所述UDP端口向所述客户端发送所述待传输文件的每个文件块和每个文件块的块编号，以及通过所述TCP连接向所述客户端发送所述待传输文件的每个文件块的校验码和块编号，以使得所述客户端根据所述每个文件块的校验码对所述每个文件块进行校验，来确认所述每个文件块是否接收成功。
12.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现权利要求1-5任一项所述方法的步骤，或者，所述处理器执行所述计算机程序以实现权利要求6-9任一项所述方法的步骤。
13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-5任一项所述的方法的步骤，或者，所述计算机程序被处理器执行时实现权利要求6-9任一项所述的方法的步骤。
14.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-5任一项所述方法的步骤，或者，所述计算机程序被处理器执行时实现权利要求6-9任一项所述方法的步骤。
CN202111552811.9A 2021-12-17 2021-12-17 文件传输方法、装置、电子设备及计算机可读存储介质 Pending CN114629891A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111552811.9A CN114629891A (zh) 2021-12-17 2021-12-17 文件传输方法、装置、电子设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111552811.9A CN114629891A (zh) 2021-12-17 2021-12-17 文件传输方法、装置、电子设备及计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN114629891A true CN114629891A (zh) 2022-06-14

Family

ID=81897862

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111552811.9A Pending CN114629891A (zh) 2021-12-17 2021-12-17 文件传输方法、装置、电子设备及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN114629891A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116599953A (zh) * 2023-07-13 2023-08-15 苏州浪潮智能科技有限公司 一种文件上传的方法、装置、系统、设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100734247B1 (ko) * 2007-03-12 2007-07-02 주식회사 셀런 유디피를 이용한 에프티피 전송 방법
US20100306311A1 (en) * 2009-05-29 2010-12-02 Thales Method of Downloading Large Size Data to a Large Number of Networked Client Machines from a Single Server
WO2016000138A1 (zh) * 2014-06-30 2016-01-07 北京新媒传信科技有限公司 一种数据传输方法、终端和服务器
CN105959298A (zh) * 2016-06-24 2016-09-21 乐视控股（北京）有限公司 数据传输方法及数据传输装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100734247B1 (ko) * 2007-03-12 2007-07-02 주식회사 셀런 유디피를 이용한 에프티피 전송 방법
US20100306311A1 (en) * 2009-05-29 2010-12-02 Thales Method of Downloading Large Size Data to a Large Number of Networked Client Machines from a Single Server
WO2016000138A1 (zh) * 2014-06-30 2016-01-07 北京新媒传信科技有限公司 一种数据传输方法、终端和服务器
CN105580334A (zh) * 2014-06-30 2016-05-11 北京新媒传信科技有限公司 一种数据传输方法、终端和服务器
CN105959298A (zh) * 2016-06-24 2016-09-21 乐视控股（北京）有限公司 数据传输方法及数据传输装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116599953A (zh) * 2023-07-13 2023-08-15 苏州浪潮智能科技有限公司 一种文件上传的方法、装置、系统、设备及可读存储介质
CN116599953B (zh) * 2023-07-13 2024-02-02 苏州浪潮智能科技有限公司 一种文件上传的方法、装置、系统、设备及可读存储介质

Similar Documents

Publication Publication Date Title
US10715451B2 (en) Efficient transport flow processing on an accelerator
US20190140979A1 (en) NIC with Programmable Pipeline
US9906630B2 (en) Processing data packets in performance enhancing proxy (PEP) environment
JP4743894B2 (ja) データ・パケットを伝送しながらセキュリティを改良するための方法及び装置
US20130080651A1 (en) Message acceleration
US20230156102A1 (en) Packet processing method, network device, and related device
CN114629891A (zh) 文件传输方法、装置、电子设备及计算机可读存储介质
CN113986811B (zh) 一种高性能内核态网络数据包加速方法
CN113810397B (zh) 协议数据的处理方法及装置
US7181616B2 (en) Method of and apparatus for data transmission
US20070263876A1 (en) In-memory compression and encryption
CN107592361B (zh) 一种基于双ib网络的数据传输方法、装置、设备
CN110958216A (zh) 安全的在线网络分组传输
JP2015216450A (ja) 情報処理装置、情報処理システム及び中継プログラム
US8868674B2 (en) Streaming and bulk data transfer transformation with context switching
CN107770018B (zh) 用于串行通信系统的通信方法及设备
WO2020103420A1 (zh) 一种数据传输方法、接收方法、装置及系统
EP1868351B1 (en) File distribution system
CN111031055A (zh) 一种IPsec加速装置及实现方法
US20230269311A1 (en) Method and device for data transmission and storage medium
CN115914417B (zh) 暗网威胁情报的获取方法、装置、设备及介质
CN115348254B (zh) 文件打包下载方法、装置、电子设备及存储介质
CN115189969B (zh) 一种网络加密通信方法、装置、介质及设备
CN116155974A (zh) 一种建立数据连接的方法、装置及电子设备
CN114827125A (zh) 高性能计算云平台并行数据传输方法、系统及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination