一种改进的简单文件传输协议SFTP及其Java实现
彭立志1，高斌2，杨波1
(1 济南大学信息科学与工程学院，山东济南250022    2 济南市自考办，山东济南250001)
E-mail:***********
摘要本文就简单但有可靠性要求的文件传输情况，对TCP/IP协议体系中的TFTP协议进行了可靠性和数据吞吐量方面的改进，形成一种新的简单文件传输协议SFTP。并基于Java的非阻塞套接字（socket）技术实现了这种协议。
关键词文件传输协议，TFTP协议，Java，非阻塞套接字
1.前言
文件传输是计算机网络非常重要的一个应用，几乎所有的网络协议体系中都定义了其应用层上的文件传输协议。ISO的开放系统互联七层模型（OSI）中就在其应用层上定义了一个FTAM文件传输协议。TCP/IP协议体系是伴随着因特网成长起来的一个协议体系，并且已经成为业界事实计算机网络协议标准，TCP/IP协议体系在其成长过程中，为满足实际需要，产生了丰富的功能强大的应用层协议，从简单的TELNET,TFT
P到适应各种复杂需要的HTTP,FTP,SNMP,SMTP/POP3等协议，TCP/IP协议体系中定义了大量的应用层协议，也正是这些功能丰富的应用层协议使得TCP/IP协议体系更加具有旺盛的生命力。
FTP和TFTP协议就是TCP/IP协议体系中为满足不同需要而产生的两个文件传输协议。FTP（FileTransferProtocol）协议是文件传输的Internet标准[1]，类似TELNET协议，FTP最早的设计是用于两台不同的主机，这两个主机可能运行在不同的操作系统下、使用不同的文件结构、并可能使用不同字符集。但不同的是，TELNET获得异构性是强制两端都采用同一个标准：使用7比特ASCII码的NVT。而FTP是采用另一种方法来处理不同系统间的差异。FTP 支持有限数量的文件类型（ASCII，二进制，等等）和文件结构（面向字节流或记录）。图1描述了使用FTP进行文件传输的过程：
TFTP(TrivialFileTransferProtocol)即简单文件传送协议，最初打算用于引导无盘系统（通常是工作站或X终端）。和FTP不同，为了保持简单和短小，TFTP使用UDP。TFTP的代码（和它所需要的UDP、IP和设备驱动程序）都能适合只读存储器。
然而，在许多实际应用中，FTP和TFTP协议还是无法很好地满足需要，例如在一个相对简单，但又需要比较可靠的文件传输需求下，若使用复杂的FTP协议将大大增加开发工作量，而且调试和维护环节的复杂性也必将加大；而如果使用TFTP协议，则无法保证文件传输的可靠性，传输文件的长度也受到严格的限制。在这种“中型传输”情况下，采用FTP 和TFTP协议都是不合适的，因而需要新的比较灵活的解决
方案。本文就这种“中型传输”需求，对TFTP协议作了一系列改进，使其适应这种传输容量大并有可靠性要求的简单文件传输需要，形成一种新的简单文件传输协议SFTP(Simple File Transfer Protocol)，并基于Java的非阻塞socket技术实现了这种协议。
图1. FTP文件传输过程
2.TFTP协议简介[2]
socket通信报文格式在开始工作时，TFTP的客户与服务器交换信息，客户发送一个读请求或写请求给服务器。
在一个无盘系统进行系统引导的正常情况下，第一个请求是读请求（RRQ）。图2显示了5
种TFTP报文格式（操作码为1和2的报文使用相同的格式）。
TFTP报文的头两个字节表示操作码。对于读请求和写请求（WRQ），文件名字段说明客户要读或写的位于服务器上的文件。这个文件字段以0字节作为结束（见图15-1）。模式字段是一个ASCII码串netascii或octet（可大小写任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR/LF）作为行结束符。这两个行结束字符在这种格式和本地主机使用的行定界符之间进行转化。octet
则将数据看作8bit一组的字节流而不作任何解释。
每个数据分组包含一个块编号字段，它以后要在确认分组中使用。以读一个文件作为例
子，TFTP客户需要发送一个读请求说明要读的文件名和文件模式(mode)。如果这个文件能被这个客户读取，TFTP服务器就返回一个块编号为1的数据分组。TFTP客户又发送一个块编号为1的ACK。TFTP服务器随后发送块编号为2的数据。TFTP客户发回块编号为2的ACK。重复这个过程直到这个文件传送完。除了最后一个数据分组可含有不足512字节的数据，其他每个数据分组均含有512字节的数据。当TFTP客户收到一个不足512字节的数据分组，就知道它收到最后一个数据分组。
在写请求的情况下，TFTP客户发送WRQ指明文件名和模式。如果该文件能被该客户写，
TFTP服务器就返回块编号为0的ACK包。该客户就将文件的头512字节以块编号为1发出。服务器则返回块编号为1的ACK。
这种类型的数据传输称为停止等待协议。它只用在一些简单的协议如TFTP中。在20.3节中将看到TCP提供了不同形式的确认，能提供更高的系统吞吐量。TFTP的优点在于实现的简单而不是高的系统吞吐量。
最后一种TFTP报文类型是差错报文，它的操作码为5。它用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。差错编号字段给出一个数字的差错码，跟着是一个ASCII表示的差错报文字段，可能包含额外的操作系统说明的信息。
图2. TFTP报文格式
既然TFTP使用不可靠的UDP，TFTP就必须处理分组丢失和分组重复。分组丢失可通过发送方的超时与重传机制解决（注意存在一种称为“魔术新手综合症(sorcerer’ sapprentice syndrome)”的潜在问题，如果双方都超时与重传，就可能出现这个问题。和许多UDP应用程序一样，TFTP报文中没有检验和，它假定任何数据差错都将被UDP的检验和检测到。
3.SFTP对TFTP协议的改进
SFTP的设计目标是既要保持TFTP的简单性，又要提高其可靠性和传输的吞吐量，因而对TFTP协议各改进主要是在可靠性和吞吐量两个方面，并提供了简单的断点续传机制。
3.1 可靠性
由于TFTP协议基于不可靠的UDP协议，尽管它有超时与重传机制，但由于UDP协议本身的缺陷，使得TFTP无法提供可靠的文件传输服务。所以在可靠性要求较高的情况下，就需要采用可靠的TCP协议进行传输。SFTP将TFTP协议移植至TCP协议上，使得其具有了可靠的传输保证，并结合了TFTP的传输应答机制，这样就解决了TFTP的可靠性的问题。但不同于FTP，FTP在客户进程和服务器进程之间使用两个T C P连接—一个控制连接，它一直持续到客户进程与服务器进程之间的会话完成为止；另一个按
需可以随时创建和撤消的数据连接。SFTP服务器监听端口为6543，数据传送和控制信息都在一个连接中进行，这样做既不
影响基本的可靠性，也能简化协议的复杂性。
3.2 吞吐量
TFTP设计的初衷是保持简单短小，它的每一个数据分组包含一个2字节的块编号，数据容量为512字节，这样也就意味着TFTP传输的最大的文件长度为216×512＝32M字节。这样的文件长度对于TFTP最初设计的应用对象——无盘工作站来说是足够的，但对于其他文件传送的场合则远远不够。
SFTP数据包中块编号扩展为4个字节，同时，为减少应答次数而提高实际传输效率，并考虑TCP协议的传输能力，数据段的容量也扩展至2048字节。这样，SFTP理论上能传输的文件长度达到了232×2048＝8T字节，这样的文件长度对于绝大部分传输场合是足够了。
3.3 续传
SFTP协议设计了简单的断点续传机制，这种续传机制依靠数据块编号定位续传点，定义专门续传请求包，采用单个线程进行续传。
3.4 协议
3.4.1 协议概述
SFTP基于面向连接的TCP协议。服务器监听端口为6543端口。其完整IP包结构如下：
一个典型的SFTP文件传输过程如图3所示：
图3 SFTP文件传输过程
3.4.2 SFTP数据包格式：
每个SFTP数据包的第一个字段为操作码字段，表示数据包的类型。SFTP数据包共有五种类型：上传请求包，数据包，确认包，错误信息包和续传请求包，其操作码分别为2，3，4，5，6。
上传请求包
数据包
确认包

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。