• FTP和TCP的文件传输效率对比测试分析


    前言

    最近因项目需要,需要把一定数量的中等文件从开发板上传到电脑上,分别选择了FTP和TCP自定义协议两种方式进行传输,进行了简单的对比测试,故做如下记录。

    测试环境

    开发板:Linux,ARMv7 单核,内存512M

    PC:winodw, i7,8G内存,SSD

    网络:100M,局域网

    文件:大小4.06M,数量50个

    四种方案简述

    1、FTP上传,短连接,单线程

    2、FTP上传,长连接,单线程

    3、TCP上传,短连接,单线程

    4、TCP上传,短连接,多线程

    5、TCP上传,长连接,单线程

    说明

    1、这里提的TCP上传,是指使用自定义协议TCP方式上传。

    2、短连接是指每上传一个文件就连接一次,传完后就关闭连接。

    3、长连接是指先连接,再上传多个文件,到退出程序时再关闭连接。

    4、单线程是指所有文件的连接、发送、关闭都是在一个线程内完成。

    5、多线程是指一个文件对应一个线程,多个文件同时使用多个线程发送。

    自定义文件传输协议

    自定义文件协议设计得非常简单。

    客户端发送数据包 = 128B文件名 + 4B文件长度 + 文件数据

    服务端响应数据包 = OK

    之所以如此设计,列如下几点原因:

    1、固定文件名长度,方便处理,也方便定位到文件长度字段。

    2、4字节文件长度刚好和整型相等,在两个32位小端机器上直接拷贝发送,代码简单。

    3、文件长度字段可以方便检查数据是否接收完全,解决粘包问题。

    4、局域网内网络相对比较好,所以没带文件校验。

    测试结果

    方案1,2分钟

    方案2,45秒

    方案3,20秒

    方案4,20秒

    方案5,20秒

    结果分析

    分析之前,先计算一下理论的传输速度应该是多少,文件总大小约为203M,按100M网络计算,速度应该是203/(100/8) = 16秒。所以说20秒是一个比较不错的速度了,毕竟还有一些文件操作等操作,需要占用一些时间。

    方案1和方案2比较

    FTP建立连接相对复杂,不断的连接和断开肯定消耗不少时间,所以长连接比短连接传输速度快也是应该的。

    FTP方案和TCP方案比较

    FTP方案整体上比TCP方案慢得多,毕竟FTP协议肯定比自定义的文件传输协议要复杂得多,交互指令越多,速度越慢。

    方案3和方案4比较

    两个方案的差别在于是否使用多线程发送。从结果来看,速度相差不大。因为网络的极限速度就是100M,同时发送再多的数据也没有用,都会阻塞在网络上。即使发送的速度可能快一点点,但开启多个线程、线程同步锁等也需要时间,可能相抵消了。

    方案3和方案5比较

    两个方案的差别在于是否使用长连接。从结果来看,速度相关不大。和上面分析一样,网络的极限速度是100M,而TCP在局域网内建立连接(三次握手)、关闭都非常快。对于发送大量数据的情况,是否使用长连接影响都不大。

    从上面的测试和分析结果来看,在本项目中使用方案3或5(TCP上传,单线程),是比较合适的。首先传输速度上表现不错,而且避免使用多线程,不需要线程同步,代码设计更简单,越简单越容易做得更可靠。

    当然上面的测试是不充分的,对于其他情况没有进行测试分析。例如,使用FTP多线程发送、更小的文件(小于1k)、更大的文件(大几百M)、更多的数量等等,因时间有限不做测试了。不过通过上面的分析,考虑各个因素对速度的影响,也大概可以选择出比较优的方案。如有机会再测试分析。

    欢迎各位评论,指出不足之处。

  • 相关阅读:
    JavaScript DOM 编程艺术(第2版)读书笔记(3)
    JavaScript DOM 编程艺术(第2版)读书笔记(1)
    css杂记
    2020年11月15日
    2020年11月14日
    2020年11月13日
    2020年11月12日
    《代码大全》阅读笔记04
    2020年11月11日
    2020年11月10日
  • 原文地址:https://www.cnblogs.com/qinwanlin/p/9963186.html
Copyright © 2020-2023  润新知