IIS7批量FTP管理功能说明：
1、可批量导入，导出FTP信息
2、其他ftp工具有的功能，我们也有
3、特色功能：可以定时上传下载
4、数据信息列表化、一眼就能知道那个是那个
5、批量连接标签页式切换方便快捷
6、7大连接模式更多好的兼容
7、内嵌编辑器有效解决普通txt记事本乱码
8、锁屏功能当程序有规定时间内没人操作，则自动锁程序。输入密码才可以正常操作
本产品适用于：懒得记录FTP信息和有批量定时备份，上传下载的运维或站长。
图片：
前言
最近因项目需要，需要把一定数量的中等文件从开发板上传到电脑上，分别选择了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)、更多的数量等等，因时间有限不做测试了。不过通过上面的分析，考虑各个因素对速度的影响，也大概可以选择出比较优的方案。如有机会再测试分析。
原文：https://www.cnblogs.com/qinwanlin/p/9963186.html
