文件传输和访问协议

文件传输和访问协议（通用8篇）

篇1：文件传输和访问协议

相信没有比FTP文件传输协议更为基础的协议了，那么对于这种协议，想必大家也多少有所接触。那么很多服务器和站点的建设都将用到它，如果你还不清楚它的细节，那就来看看文章吧。

1. FTP文件传输协议概述

FTP是文件传输协议(File Transfer Protocol )的简称?FTP是TCP IP的一种具体应用,它工作在OSI模型的第七层,TCP模型的第四层上,即应用层,使用TCP传输而不是UDP,FTP连接是可靠的,而且是面向连接,为数据的传输提供了可靠的保证?

FTP工作模式与客户/服务器模式相似?与大多数的其他TCP应用不相同的是,FTP在客户与服务器之间使用两个TCP连接?D?D控制连接和数据连接,控制连接在客户与服务器交互的整个过程中一直存在,而数据连接只在有文件或目录传输的时候才被创建,用完了后就被关闭了?控制连接用于发送指令给服务器以及等待服务器响应;数据连接是用来建立数据传输通道的?

2.FTP文件传输协议的Port模式

根据是使用Port模式还是Passive模式,FTP使用不同的TCP端口号?

FTP Port模式

Port模式的FTP文件传输协议步骤如下:

1 客户端发送一个TCPSYN(TCP同步)包给服务器段众所周知的FTP控制端口21,客户端使用暂时的端口作为它的源端口;

2 服务器端发送SYN ACK(同步确认)包给客户端,源端口为21,目的端口为客户端上使用的暂时端口;

3 客户端发送一个ACK(确认)包;客户端使用这个连接来发送FTP文件传输协议命令,服务器端使用这个连接来发送FTP应答;

4 当用户请求一个列表(List)请求或者发起一个要求发送或者接受文件的请求,客户端软件使用PORT命令,这个命令包含了一个暂时的端口,客户端希望服 务器在打开一个数据连接时候使用这个暂时端口;PORT命令也包含了一个IP地址,这个IP地址通常是客户自己的IP地址,而且FTP也支持第三方 (third-party)模式,第三方模式是客户端告诉服务器端打开与另台主机的连接;

5 服务器端发送一个SYN包给客户端的暂时端口,源端口为20,暂时端口为客户端在PORT命令中发送给服务器端的暂时端口号;

6 客户端以源端口为暂时端口,目的端口为20发送一个SYN ACK包;

7 服务器端发送一个ACK包;

8 发送数据的主机以这个连接来发送数据,数据以TCP段(注:segment,第4层的PDU)形式发送(一些命令,如STOR表示客户端要发送数据,RETR表示服务器端发送数据),这些TCP段都需要对方进行ACK确认(注:因为TCP协议是一个面向连接的协议);

9 当数据传输完成以后,发送数据的主机以一个FIN命令来结束数据连接,这个FIN命令需要另一台主机以ACK确认,另一台主机也发送一个FIN命令,这个FIN命令同样需要发送数据的主机以ACK确认;

10 FTP文件传输协议中规定，客户端结束后,客户端以FIN命令来关闭一个控制连接,服务器端以ACK包来确认客户端的FIN,服务器同样也发送它的FIN,客户端用ACK来确认?

篇2：文件传输和访问协议

ftp是通过TCP/IP网络进行可靠文件传输的标准格式。ftp提供了丰富的命令，可以让用户比较方便地查看远程目录的内容，上传和下传文件，删除一个文件等。FTP支持两(三)种方式的传输：文本(ASCII)方式和二进制(Binary)方式。通常文本文件的传输采用ASCII方式，而图象、声音文件、加密和压缩文件等非文本文件采用二进制方式传输，如果为了从一个系统上传输文件而使用了与本地系统不同的计算机字节位数，那么就必须使用Tenex模式。FTP以ASCII方式作为缺省的文件传输方式。

。open 打开一个通向远程主机的连接

。close 关闭当前打开的连接

。quit 关闭当前打开的连接并退出ftp

。binary 把文件表示的形式设为二进制形式

。ascii 把文件表示的形式设为ASCII码形式

。hash 为每个传输块显示一个#字符

。put 从本地向远程主机传输一个文件

。mput 从本地向远程主机传输多个文件

。get 从远端主机向本地传输一个文件

。mget 从远端主机向本地传输多个文件

。cd 改变远程主机上当前目录

。lcd 改变本地主机上当前目录

。cdup 将远程主机上的当前目录改变成其父目录

。dir 列出远程主机当前目录中内容

。pwd 列出远程主机目录名

。mkdir 在远程主机上创建一个目录

。rmdir 在远程主机上删除一个目录

。rename 改变远程主机上文件或目录名

。delete删除远程主机上一个文件

。mdelete 删除远程主机上多个文件

。? 获得有关ftp的帮助

。! 返回到shell中

在ftp交互过程中，若想在本地机的shell环境下执行shell命令，可通过在该命令前加!号完成。例如：ftp>!date

注意：值得一提的是，mget命令要求每次都要输入“y”来确认是否继续进行文件传输，在FTP用户命令中有一个可以禁止掉这些询问，这就是prompt。

匿名FTP访问可使在FTP服务器上无帐号的用户也可以与该服务器建立会话，在身份验证时，用户使用anonymous作为用户名，并使用其电子邮件地址作为口令，

商业版本的UNIX一般都预装了ftp服务器，其名字一般为ftpd，其可执行文件的路径为/usr/sbin/。UNIX上的合法用户都能使用ftp服务。默认时，任何在UNIX主机上具有有效帐号的用户都可以与该主机上的ftpd进行会话，向该主机拷贝文件或从该主机上取文件(还要取决于用户的权限)系统管理员要想禁止某用户使用FTP服务，可以将其用户名列入文件/etc/ftpusers文件中。该文件是一个文本文件，列出了本机上不能使用ftp服务的用户清单。考虑安全性，该文件中应该包含用户root和UUCP。若/etc/ftpusers文件不存在，那么可登录到本主机的用户都可以使用本系统的FTP服务。有时用户名没有出现在/etc/ftpusers中，但他也无法使用FTP服务。这是因为该用户是从一个/etc/Shell文件中没有包含的shell中登录到本系统的。这说明只有身份验证通过的用户，而且他所使用的Shell类型包含在/etc/Shell文件中才可以使用主机的FTP服务。

大多数UNIX系统都提供ftpd守护进程，一般都是不带参数启动的，为了使用ftpd的高级功能，通常需要在启动时带几个相应的参数。Ftpd命令的基本格式是：

/etc/ftpd[-a][-A][-d][-i][-K][-o-][-l][-L][-ttimeout][-Tmaxtimeout][-v]

-a指定访问控制文件/etc/ftpaclearcase/“ target=”_blank“ >ccess，通常这是ftpd的缺省操作

-A忽略访问控制文件/etc/ftpaccess

-d把调试信息写入syslog文件中

-K打开严格的kerberos认证，如果认证失败，即身份认证失败，连接请求被拒绝

-l把所有的ftp会话都写入系统日志文件中

-L把远程用户的所有命令都写入系统的日志文件中

-t超时(timeout)，指定不活动的会话的超时时间，一般缺省为15分钟

-T最大超时时间，缺省为2个小时。

需要注意的是，在修改了ftpd参数以后，需要重新启动.netd。

lozity 回复于：-05-09 17:08:34好东西，顶

yuanfly 回复于：2004-05-09 17:48:45谢了：)

篇3：文件传输和访问协议

采用反馈确认机制的传统TCP协议[1]适用于较低误码率条件下的网络通信。在具有高误码、长延时特点的卫星链路,TCP会错误地把丢包视为拥塞,降低发送速率;卫星链路的长延时增大了TCP往返时延,延迟了反馈控制信息到达,降低吞吐量,造成卫星有限资源的严重浪费[2]。针对TCP协议应用于卫星链路的特点,提出一种高误码卫星链路下的可靠文件传输协议RFTP-S。文章首先分析了卫星链路应用TCP协议存在问题、目前主要解决办法及实现难点,进而从文件下载时间、反馈信道信息量及系统开销等方面对新提出的RFTP-S协议进行仿真对比分析,验证了RFTP-S协议的优越性能。

2 TCP协议改进方法及问题分析

TCP协议最初是为有线网络设计的,而卫星网络与地面有限网络存在着显著差别,TCP协议应用于卫星网络存在许多不足。为了改善卫星TCP的性能,目前主要的解决办法有端到端的协议修改[3]、分段连接机制[4]、跨层联合设计[5,6]、代理方案[7]等,这些解决方案功能不同,有的能够充分利用链路可用带宽,有的在随机误码情况下表现较好,但在卫星网络环境下TCP协议表现出的性能仍然不能令人满意。

归纳起来,TCP协议应用于卫星网络存在的技术难点主要有:

1)包丢失原因的辨别

包丢失原因的辨别对于提高TCP的传输性能极为重要,特别是对于误码率高的链路。TCP假定所有丢失都是由拥塞造成,并将丢失作为拥塞的指示。当出现数据包丢失时,TCP会降低发送速率以缓解网络中出现的拥塞。如果丢失是由于传输错误造成的,本来TCP应该快速重传,但是TCP却降低发送速率的做法显然是不合适的,降低了本来就已紧张的信道资源利用率。文献[8]仿真表明,当TCP能够辨别造成丢失的原因时,其传输性能确实有所提高。

2)反向链路应答拥塞

卫星链路通常都是上行功率受限,所以卫星网络不采用地面网络的对称方式,而是采用链路以一种非对称的方式工作。卫星网络前向链路和反向链路带宽的不对称性达到一定程度时,会产生用于传送应答确认的低速反向链路上的ACK应答拥塞。反向链路的容量限制导致了ACK确认信息的排队等待甚至丢失,影响窗口的更新速度或引起不必要的重传。低速反向信道会引起ACK丢失或压缩,随着非对称性的增加,吞吐率将按指数规律急剧下降。这种非对称性极大地影响了TCP协议的传输性能。

综上所述,由于TCP协议的工作机理,使得TCP不适合工作在具有高误码、长延时、非对称特性的卫星网络环境,必须寻找一种全新的完全适合卫星网络环境的文件传输协议。

为了验证TCP协议性能,搭建了基于TCP协议应用的客户端/服务器模式的FTP文件下载仿真平台,如图1所示。在不同丢包率和不同TCP协议版本下,下载5 Mbyte的文件,TCP发送段序号的仿真结果如图2所示。

随着链路误码率或丢包率的增加,收到ACK确认段的时间逐渐增大,等待时间越来越大于传输数据段的时间,造成在单位时间内,传输的数据段数量逐渐减小,即传输速率降低。由图2所知,在丢包率较小时,不同TCP协议下发送的TCP段序号差别不大,采用SACK机制的TCP协议要比传统TCP协议性能表现优越,表现在图2中曲线反应的下载时间不同。但是随着丢包率的增加,曲线总体逐渐变得平坦且抖动,抖动说明TCP发生了数据重传,曲线的斜率表示数据传输速率逐渐下降,直至TCP连接中断。这种变化趋势主要是由于启动开始阶段TCP处于慢启动阶段,当发送窗口大于慢启动门限窗口后,便进入了拥塞避免过程,当拥塞发生时,在大丢包率情况下,ACK确认分组丢失严重,重复确认几乎不会收到,超时成为引起拥塞的主要原因,慢启动门限进一步降低,拥塞窗口设置为一个报文段,这样TCP就长期处于慢启动过程,分组进入网络的传输速率长期保持在一个相当低的水平上,如图2最下方两条曲线,TCP建立连接的过程十分缓慢最终导致连接中断,FTP文件在有限时间内无法完成下载。

3)RFTP-S传输协议

笔者提出的可靠文件传输协议RFTP-S基于喷泉编码理论,完全适合卫星网络环境。喷泉码[9]是一种新颖的信道编码技术。可以由K个原始数据分组生成无限数量的编码分组,而用户只要收到其中任意M(M>K)个编码分组,即可通过译码以高概率成功恢复全部原始数据分组。RFTP-S协议通过仿真分析表明该协议具有较短的下载时间、极低的反向链路吞吐量和适当的系统开销。有效克服了TCP协议应用于卫星传输存在的技术难点问题。保证了文件传输的可靠性,特别适合于长延时、高误码率条件下的卫星通信。

采用RFTP-S文件传输,首先需要把被传输的文件相关信息即文件预处理信息传输到接收端,然后才能按传输数据包的包格式进行文件传输,其文件预处理信息的包格式如图3所示。

按RFTP-S协议进行文件传输的每个数据包的包格式如图4所示。

基于RFTP-S协议的文件传输方法按如下步骤进行文件传输:

1)在发送端进行设定,比如发送目的地,数据包长和发送速率等;

2)发送端把需要发送的原始文件按预先设定的文件片段分割成N份(N≥1),形成文件预处理信息,信息内容如图3所示;

3)发送端把文件预处理信息按喷泉编码的方法编码后发送到接收端,接收端接收到文件预处理信息后,向发送端发送接收完毕应答;

4)发送端收到接收端发送的接收文件预处理信息完毕的应答后,开始按喷泉编码方法发送第一个文件片断;

5)接收端收到第一个文件片断后进行喷泉译码,译码并正确接收后向接收端发送接收完毕应答;

6)发送端收到第一个文件片断接收完毕应答后,开始发送第二个文件片断,按此方法,直到发送完最后一个文件片断,接收端收到后,译码合并所有文件片断,文件接收成功。

4 RFTP-S协议仿真与性能分析

为验证高误码率卫星链路下采用RFTP-S协议进行可靠文件传输的可行性和可靠性,笔者与现有标准TCP协议进行仿真比较分析,模拟客户端/服务器模式,仿真平台框架如图1所示,完成FTP文件的下载仿真。

对于包长的选择,根据文献[10]结论,虽然数据分组传输成功概率存在着关于分组有效载荷长度的极值点,但是通过近似分析,极值点附近不具有实用价值,传输成功概率都是随着分组有效载荷长度的减小而单调增大,因此实际使用中尽量选取较短的分组有效载荷长度。同时考虑到分组开销和链路层数据帧长度选取范围等因素,仿真数据分组长度统一选取500 byte。

仿真参数如表1所示,TCP接收窗口大小设置为64 kbyte,链路延时为0.26 ms,对FTP文件下载分别采用TCP协议和采用RFTP-S协议进行传输,相当于在成功下载5 Mbyte大小文件所需要时间内进行仿真,仿真结果如图5所示。

从图5可以看出,当采用传统TCP协议,比如New Reno和SACK,在误码率为4×10-5即相当于丢包率为18%时,下载全部5 Mbyte文件需要将近6 000 s,即约100 min时间,这在实际应用中几乎不能忍受,而且当网络链路丢包率达到20%或以上时,TCP连接中断。

但是,当采用RFTP-S协议进行文件传输下载时,从图5中可以看出,当链路误码率达到4×10-4相当于丢包率达到80%的情况下,依然可以在较短时间内(455 s)顺利下载5 Mbyte文件。这是目前所有其他TCP及其改进版本的协议远无法完成的。RFTP-S协议可以在不可靠的网络上(只要网络不完全中断)完成正常通信。

基于RFTP-S的文件传输协议采用半反馈确认方式,仿真框架如图1所示,仿真结果如图6所示。当采用TCP协议时,随着丢包率逐渐增加,ACK报文进一步丢失,RTT逐渐增大。在TCP慢启动/拥塞控制阶段,均是以RTT为单位进行拥塞窗口调整,较大的RTT直接导致了窗口内的调整速度较低,吞吐量进一步降低。同时另一方面,因为TCP流量控制的基础是自同步机制,ACK的接收速率决定数据报文的发送速率,反向信道的拥塞会造成对TCP在前向信道报文发送的抑制,对吞吐率产生负面影响,表现为图6中TCP-SACK曲线逐渐平坦,吞吐量逐渐降低。

但是当采用RFTP-S协议时,只有当接收端正确收到文件信息包、文件片段及全部文件时才通过反向信道向发送端发送ACK确认信息,而不必对每个收到的数据包发送反馈确认信息,甚至可以不发送确认信息,因此反向信道吞吐量极小。而且发送端发送信息速率不依赖于反馈信息,没有因为数据拥塞或丢失而重传发送数据的机制。图6中最下方RFTP-S代表的曲线(为清晰起见,图6纵坐标起始点为-100 kbit/s)。反馈信息量明显低于采用TCP协议产生的反馈信息量。因此,尤其适用于高误码率长延时的卫星通信需求。

采用RFTP-S协议进行文件传输时会产生一定的系统开销,通过搭建如图1所示的仿真平台,设置源文件大小为5 Mbyte,观察在不同链路丢包率下系统的开销情况,如图7所示。其中,系统开销代表在一定时间内收到的数据包(Pocket)数量。

如图7所示,当采用不同的文件传输协议传输同样大小的文件时产生的系统开销有很大的区别。当链路的误码率为零或者很小时,用TCP协议传输时需要重传的数据量很小;而采用RFTP-S协议时,由于协议固有的算法,系统开销不会因为链路误码率减小而相应减小,相反,RFTP-S协议产生的系统开销与链路误码率基本上成线性关系。因此,在仿真误码率较小时,TCP协议在系统开销方面表现的要比RFTP-S协议性能优越。但是随着误码率的增加,TCP会因为协议算法原因造成大量的数据重传进而使系统开销急剧上升,而此时RFTP-S协议因为与链路误码率之间良好的线性关系,其产生的系统开销较小。在链路误码率足够大时,使用TCP协议已经无法完成正常的文件传输,但是RFTP-S协议能够顺利完成文件传输。虽然采用RFTP-S协议会产生额外的系统开销负担,但换来的是在恶劣网络环境下系统良好的可靠性。因此RFTP-S协议非常适用于高误码率卫星链路下的可靠文件传输。

5 小结

针对目前TCP协议应用于卫星通信尤其是高误码率条件下卫星通信的性能缺陷,提出了更适合这种卫星通信环境的RFTP-S可靠文件传输协议。RFTP-S协议较传统TCP传输控制协议有本质区别,具有很多明显的优势。比如高误码条件下较短的接收时间、极小的反馈信息量以及适当的系统开销代价等。这些特性使RFTP-S协议都非常适合高误码率条件下的卫星通信。通过模拟实际卫星网络传输中使用RFTP-S协议进行文件传输,通过控制地面干扰设备人为增加干扰使其链路丢包率达到80%甚至更高,成功接收了预定传输文件,而在同等条件下使用基于TCP连接的FTP进行文件传输时则完全不能成功接收。因此,本文中的RFTP-S可靠文件传输协议在高误码、非对称卫星传输环境下具有广阔的应用前景。

摘要：设计了一种TCP的替代协议,即基于喷泉编码的半反馈可靠文件传输协议,称为针对卫星链路的可靠文件传输协议(RFTP-S)。仿真结果表明,在误码率为4×10-4环境下,RFTP-S能够以19%的系统开销在455s内成功下载完成5Mbyte大小的文件,与TCP协议相比,有效提高了链路利用率和网络吞吐量,特别适合高误码、长延时卫星网络环境。

关键词：传输协议,卫星网络,高误码率

参考文献

[1]STEVENS W R.TCP/IP illustrated,volume1:the Protocols[M].[S.l.]:Addison-Wesley Professional,1994.

[2]叶斌,胡谷雨,雷鸣.卫星网络TCP性能研究[J].电视技术,2005(S1):132-134.

[3]FALL K,FLOYD S.Simulation based comparisons of Tahoe,Reno and SACK TCP[J].Computer Communications Review,1996,26(3):521.

[4]吴结,高随详.基于分段连接机制实现卫星TCP性能的改善[J].计算机系统应用,2006(7):33-37.

[5]顾明,张军.适用于卫星网络的TCP跨层改进机制[J].电子与信息学报,2008(8):1815-1819.

[6]俞一帆,纪红,乐光新.针对无线上行链路的TCP跨层改进机制[J].电路与系统学报,2008(2):104-108.

[7]曾斌,李之棠.面向卫星网络的TCP代理[J].软件学报,2007(7):1695-1704.

[8]SAMARAWEERA N K G,FAIRHURST G.Reinforcement of TCP error recovery for wireless communication[J].ACM SIGCOMM Computer Communication Review,1998,28(2):30-38.

[9]LUBY M.LT codes[C]//Proc.the43rd Annual IEEE Symposium on Foundations of Computer Science.[S.l.]:IEEE Press,2002:271-282.

篇4：文件传输和访问协议

关键词：蓝牙无线技术；蓝牙协议：RBTFT

中图分类号：TN925

1 蓝牙无线技术的重要性概述

蓝牙技术相比其他电子设备而言，是一种成本低、科技含量高的非封闭式的无线通讯技术，其使用范围受距离限制明显，只能在短距离范围内与电脑、便携设备、打印机、数码相机、键盘、电脑鼠标等实现无线连接。当前，受科学技术进步的推动和资源节约型社会的影响，无线连接技术发展迅速，受到社会欢迎。蓝牙无线技术的发展应用对于无线移动数据通信业务的发展起到了促进作用，蓝牙无线技术普遍采用的2.4G赫兹频带为全球通用标准，能保证蓝牙无线技术在世界各地的推广使用。换句话来说，蓝牙无线技术使得各种电子数码产品之间实现无线沟通，净化了空间和节约了资源。整合蓝牙无线技术，可以在设备方圆九米的范围内实现电脑、便携设备、收集、打印机、键盘等设备的无线连接，拓展无线通信网络道路。当前，蓝牙无线技术主要采取分散式网络结构和快跳频、短包技术，实现点对点及点对多点通信。

2 蓝牙协议的概念

蓝牙协议的目的是使符合该协议的各种设备之间能够传递信息。两个相互之间传递信息设备需要使用相同的协议栈。蓝牙协议栈采用的结构是用来完成数据流的过滤和传输以及跳频和数据帧传输的分层结构。当然不同设备可以在不同的协议栈上实行。但是，必须遵循一个共同的原则，那就是所有的协议栈都要使用蓝牙协议中的数据层和物理层。支持蓝牙使用模式的应用层在协议中的最高位置。有的应用不要用到协议中的所有内容。相反，应用仅用在蓝牙协议栈中垂直方向的协议。基带，链路管理，逻辑链路控制与适应协议和服务搜索协议是蓝牙的核心协议的四个组成单元。（1）基带协议可以确保互相连接的蓝牙设备射频连接，以形成一个微小的网络。（2）在蓝牙各设备间连接的建立和设置需要链路管理协议。链路管理协议通过发起连接，进行身份验证和加密，通过协调确定基带数据大小；无线设备的节能模式和工作周期需要链路管理协议控制，以及那个微小网络内设备的连接状态也是由该协议所控制的。（3）逻辑链路控制和适配协议（L2CAP）可以说是基带的上层协议，L2CAP与链路管理协议是一个并列的关系，两个协议是并行工作的。但是这两个协议也有一定的区别，当业务数据不经过链路管理协议时，这个时候适配协议会提供上层服务。（4）服务搜索协议（SDP），使用该协议可以查询到相应的设备信息和服务类型，各蓝牙设备间在此基础上建立相应的连接。所谓的支持协议主要指的是蓝牙协议层，包括逻辑链路控制和适配协议（L2CAP）、无线射频通信（RFCOMM）和业务搜索协议（SDP）。L2CAP提供分割和重组业务。RFCOMM是用于传统串行端口应用的电缆替换协议。SDP包括一个客户/服务器架构，负责侦测或通报其它蓝牙设备。

3 RBTFT协议的研究与实现

3.1 RBTFT协议的可靠性和稳定性

RBTFT协议（Reliable Bluetooth File Transfer的简称）是指在RFC0MM协议基础之上建立的一条端到端（或点到点）的文件传输协议。该协议的主要目标在于在蓝牙设备和其他数码设备之间建立一条无线连接通道，该通道应具有可靠性和稳定性，以便践行文件的可靠传输。该协议目前通常采用的开发应用程序是VC++，以WIN98/2000/NT为应用平台，但RBTFT协议并不受VC++这一具体编程语言和WIN98/2000/NT操作系统的限制，它支持不同工作形式，包括一次传输多个文件、断点续传、CRC校验等等，其设计思想源是在传统的帧传输方式得到启发的（这中方式在数据传送过程中要求一帧一帧地发送，而不是整体发送）。为了确保文件传送的可靠性，RBTFT协议明确了RBTFT帧的定义，规定帧由报头和数据子包两部分组成，其中报头指明帧的类型（同时携带CRC校验信息），数据子包有不同的子包结束符构成，并明确是否有后续包等情况。RBTFT协议在进行数据传输时，采用发送---应答---握手---失败的传输方式，即在发送文件时一帧为单位，每发送一帧数据收到一个应答，说明此次发送是成功的。

蓝牙技术在利用RBTFF协议传送文件时，最先要做的工作是进行串口初始化操作，如果这个操作成功，成功报告将通过异步消息RBTFF—CONNECT向应用程序发送，告知系统文件传输通信线路连接已经建立。开始是连接通信线路，接通成功后开始发送数据，此时实际数据发送的多少将根据内部缓冲区的内存来决定，数据信息在内部缓冲区内被暂时存储起来，根据RBTFF协议将这些数据以一帧帧的文件形式，并在文件里加入了帧信息和CRC校验信息。接收方在接收文件的过程中，每成功接收一份文件，接收方系统将对接收的文件进行CRC校验。如果文件接收不成功，将通过RBTFF协议后重发或协商，如果发送成功的前提下，不会向应用程序系统发送任何信息报告，如果发送不成功，系统会自动放弃此链接线路，同时错误报告向发送给应用程序。应用程序将自我重新复位此链接线路，也可以进行其他对应的程序处理。在文件传输过程中，无论是文件发送方还是文件接收方，任何一方断开文件链接，应用系统内部都将接收到文件传输关闭的信息，断开文件传输链接线路。在文件接收方的按帧发送的数据将被去掉枕头并重新回入接收缓冲区，重新组合为原来的传输整体文件。之后再继续下一个文件的传输，直至文件完全传送。提高蓝牙无线传送文件的可靠性，在应用层面主要依靠RBTFF协议支持断点续传。断点续传的原理在于RBTFF数据帧在报头中携带有一个信息，该信息会指明文件数据在文件具体某个位置开始的偏移量。当发生错误或连接中断时，接收方发送一个带有偏移量的信息帧，使得应用程序系统能自动识别文件发送方重新传送文件的意思，这种技术在文件数据量大的时候效果明显。

3.2 RBTFT协议发送文件的过程

蓝牙文件传输RBTFF协议发送单个文件的详细过程可以这么理解：当相互之间传递信息的设备，开始的时候设备要进行重试次数计数器的初始化，也就是计数器归零。当收发设备双方建立连接，发送方设备搜寻文件指针，读取文件长度并设置并发送报头，这个报头里包含有文件名称以及大小。接收方会发来的响应报头信息。此时若接收方返回“已经准备接收”，则开始发送第一个数据包，当然接收方可以拒绝接收并信息返回。接收方返回确认信息后发下一个数据包；若尝试连接过中重试20次后，还不能恢复连接，则放弃需要重新建立连接。当接收方发送带有偏移量的信息帧时，发送方接收该信息帧后，会自动跳到指定偏移量处继续传送，接收方放弃传输，文件传输完毕。“文件传输完毕”这样的提示信息会在设备屏幕上输出来。

4 结束语

蓝牙无线文件传输协议RBTFT的研究与实现对于蓝牙技术的发展有重要作用，明晰RBTFT的工作原理和发送文件过程，有利于更好地实现蓝牙无线文件传输的发展。

参考文献：

[1]王楠，侯紫峰，宋建平等.蓝牙无线连接可靠性措施的研究与实现[J].小型微型计算机系统，2003（05）.

[2]刘任庆.蓝牙技术的抗干扰性与可靠性分析[J].技术交流，2009（03）.

作者简介：李莉（1980.04-），女，吉林人，教师，讲师，硕士，研究方向：计算机科学与技术。

篇5：文件传输和访问协议

Linux用户们在进行远程文件的传输时，经常会使用scp和sftp命令来进行，不过这两个命令也会让我们的电脑存在一些风险，因此在不需要远程传输文件的时候，我们就可以将它们关闭。那么该如何禁止scp和sftp呢?下面就是具体的方法了。

sftp介绍

sftp是Secure File Transfer Protocol的缩写，安全文件传送协议。可以为传输文件提供一种安全的加密方法。sftp 与 ftp 有着几乎一样的语法和功能

scp介绍

两台主机之间传输文件一般使用scp命令,通常用scp命令通过ssh获取对方linux主机文件的时候都需要输入密码确认，方法差不多了。

禁止scp和sftp命令

系统:centos 5.x

1.先禁止scp

rpm -qa|grep openssh-*

yum remove openssh-clients -y

删除了openssh-clients后,再执行scp,就会报下面的错误:

-bash: scp: command not found

2.禁止sftp

vi /etc/ssh/sshd_config

Subsystem sftp /usr/libexec/openssh/sftp-server

把这行注释了,如下:

#Subsystem sftp /usr/libexec/openssh/sftp-server

退出保存后,重启sshd:

service sshd restart

以上就是Linux系统中禁止scp和sftp命令的方法了，

篇6：文件传输和访问协议

关键词：单向传输,UDP传输,可靠性

0 引言

随着计算机网络技术的快速发展, 带来的网络安全问题非常严峻[1]。公共网的环境复杂, 充斥着木马、病毒和黑客攻击等威胁, 可以说只要与公共网直接连接, 就有可能出现信息安全问题。因此, 国家规定涉密信息系统必须与公共网物理隔离[2]。物理隔离将内部网络和外部网络的物理信道隔断, 确保这两个网络系统是两个完全独立的物理系统, 无疑可确保信息的保密性。但也为涉密系统获取公共网的信息带来了不便。本文提出的单向传输系统即适合于在涉密网与非涉密网之间使用。

1 BLP 模型简介

1.1 基本概念

BLP模型是Bell-La Padula模型的简称, 它是D.Elliott Bell和Leonard J.La Padula创立于1973年的一种计算机操作模型, 模拟了军事安全策略。BLP模型是第一个对安全策略进行形式化描述和证明的数学模型, 是一个状态机模型, 用状态变量表示系统的安全状态, 用状态转换规则来描述系统的变化过程。

1.2 BLP 模型的安全特性

强制安全策略由*—特性和简单安全性组成。所有的主体和客体都由系统分配了一个访问类的属性[3]。它包括客体和主体的范畴和密级。系统用一定的方法比较客体和主体的强制访问类属性, 通过比较的结果来限制主体对客体的访问的权限。

假设主体S的密级为C[s]。客体O的密级为C[o]。

(1) 简单安全性:

简单安全性可以表述为:O能够被S读取, S拥有对O的自主的读权限 (条件是当C[o]≤C[s]) 。简单安全性可以被称为“不向上读”, 意思就是安全级别高的主体可以读取安全级别低的客体, 不能进行写操作[4]。

(2) *—特性:

S可以写O。S拥有对O的主动写权限 (条件是当且仅当C[s]≤C[o]) 。*—特性一般被称为“不向下写”, 意思就是安全级别低的主体可以向安全级别高的客体进行写操作, 不能读操作。

2 文件单向传输系统模型

在图1中, 外端机连接非涉密网络。外端机仅安装发送设备, 内端机仅安装接收设备, 用一根单向光纤连接内端机和外端机, 除此之外无其他物理连接。非涉密网络中的信息通过外端机发出, 内端机接收从外端发送过来信息。因为单向光纤的特性和外端机、内端机的设计, 文件传输只能从外端机通过单向光纤传输到内端机, 非涉密网络不能获取内端机上的保密信息, 这符合BLP模型中的“不向上读”的简单安全性。同时, 信息无法从内端机发送到外端机, 这与BLP模型中的“不向下写”的*—特性相符。

3 可靠 UDP 传输的研究

单向传输系统基于UDP协议, 而UDP是不可靠的传输协议, 不能保证传输的质量。在系统中, 外端机不能收到内端机发送的任何反馈信息, 这也包括了UDP的应答信息。以上情况决定了在使用UDP从外端机向内端机发送数据时存在着三个问题:包错误、包丢失和流量控制。

3.1 包错误的解决方案

由于发送端无接收端的反馈信息, 传输过程中若数据包出错, 发送端不清楚发生的情况, 故只能在接收端进行错误检测。若数据包发生错误, 接收端直接丢弃错误包, 等待发送端重传。针对包错误的情况, 在发送端对数据包进行散列值计算, 将计算出的散列值同数据一起发送, 然后在接收端对数据包散列值进行校验[5]。

3.2 包丢失解决方案

UDP协议没有提供错误重传机制, 需提供一套数据重传服务来保证包丢失之后能够及时重传。在发送端使用主动重传技术, 无论数据包是否有丢失的情况, 在每次发送数据后, 都进行重传。重传可分为两种情况, 一种是单包重传, 即每发送一个数据包后, 将该数据包重传。另一种称作多包重传, 即在连续发送一定量的数据包后, 将该批数据包重传。这两种重传方式实际上是适用于不同的网络情况。经验证, 多包重传的平均效率要高于单包重传, 单向传输系统中采用多包重传机制[5]。

3.3 流量控制解决方案

在单向传输系统中, 由于UDP协议的局限性和单向传输系统无反馈信息的特性, 且发送端发送数据的速度和接收端接收数据的速度不一定是同步的[6]。发送端不能通过接收端的反馈信息来进行流量控制。若发送端发送数据的速率大于接收端接收处理数据的能力, 则会导致接收端来不及处理到达的数据, 从而会导致数据包被丢弃。目前比较合适的解决方法有以下两个:1) 在接收端设置缓冲区[7]。2) 提高接收端处理数据的能力。

4 单向传输系统的设计

在一些保密性要求高的环境中, 要求计算机不能直接连接互联网, 甚至连移动存储设备都不允许接入。这就给该计算机的使用带来了诸多不便, 如软件更新、数据资料导入的不便。为解决以上问题, 同时又保证涉密机器的安全, 可采用单向传输的方式让涉密机上网, 即互联网的文件可传给涉密机, 但涉密机里的内容无法外泄。

4.1 硬件设计

单向传输系统的硬件构成分为三个部分:外端机、内端机、单向传输线路。

1) 外端机为一台普通计算机, 与互联网直接连接。

2) 内端机即为涉密计算机, 与外端机通过单向传输线路连接。

3) 单向传输线路连接外端机和内端机, 从物理上保证数据单向地从外端传输到内端。

4.2 软件设计

文件单向传输系统的软件分为两个部分:内端软件部分和外端软件部分。由外端软件和内端软件共同实现U盘传输功能。

U盘传输模块可以分为发送端和接收端两个部分, 其中发送端在非涉密机上, 只能进行数据的发送;接收端在涉密机上, 只能进行数据的接收, 不能发送反馈信息。

U盘传输模块的流程图如图2和图3所示。

5 结束语

基于UDP协议的文件单向传输系统的研究从BLP模型、可靠UDP传输等几个方面较为全面地分析了所需要的理论知识, 并设计了一个简易的具有U盘传输功能的单向传输系统。该系统还存在诸多缺陷, 整体结构的设计不是很合理, U盘传输的效率和传输质量也有待进一步完善, 以保证在大数据量的情况下也能正常工作。

参考文献

[1]席荣荣, 云晓春, 金舒原, 张永铮.网络安全态势感知研究综述[J].计算机应用, 2012, 32 (1) :1-4, 59.

[2]刘波, 陈曙辉.一种基于Bell-La Padula模型的单向传输通道[J].计算机科学, 2012, 39 (10) :26-29.

[3]丁慧丽, 陈麟, 李霞.基于BLP模型的单向传输系统安全性分析[J].计算机安全, 2010 (06) :8—10.

[4]陈旺, 李中学.BLP模型及其研究方向[J].计算机工程与应用, 2006 (13) :136-138.

[5]陈麟, 林宏刚, 胡勇.移动存储设备数据安全导入系统[J].四川大学学报 (工程科学版) , 2009, 41 (2) :216-220.

[6]鲁宏伟.基于UDP协议的包丢失和失序处理[J].计算机工程与应用, 2001 (2) :48-55.

篇7：文件传输和访问协议

TFTP(Trivial File Transfer Protocol,简单文件传输协议)是一个传输简单文件的协议,它是基于U D P协议实现的一种传输协议。TFTP协议是FTP(File Transfer Protocol)的简化版本,不提供目录浏览,只能完成发送和接收功能。它虽然不提供像FTP那样强大的功能,但是它传送数据长度固定且较小,是一个非常易用的、紧凑的协议,很适合在一些上传下载的场合使用。本文通过研究TFTP协议,设计了基于TFTP协议的简单文件传输系统,实现了多客户端与服务器的文件传输功能,并解决了丢包、超时等问题,具有一定的容错能力。

1 TFTP协议简介

利用TFTP简单文件传输协议可以实现TFT server与TFTP client之间的文件传输,包括多客户的下载和上传请求。TFTP传输文件的包的大小最大为512字节,如果在传输过程中,发现包数据小于512字节,则默认为该文件传输完毕[1]。

在TFTP文件的传输过程中,通常都要求有一定的容错能力。大部分的错误都会导致连接中断。假如错误由一个错误的数据包引起,则这个包将不被确认,也不会被重新发送,因此,另一方将无法接收到。如果错误包丢失,则将使用超时机制。错误主要由下面三种情况引起:1)不能满足请求,如文件不存在,访问受限等;2)收到的数据包内容错误,这种错误不能由延时或重发解释,如格式不正确的包;3)对需要资源的访问丢失,如硬盘满、访问拒绝。

2 基于TFTP协议的简单文件传输系统的体系结构

基于TFTP协议的简单文件传输系统实现多客户端和服务器之间的传输,其体系结构如图1所示。

3 基于TFTP协议的简单文件传输系统的通信流程设计

3.1 上传/下载功能的工作流程

系统的任何传输都是从一个上传或下载文件的请求开始,它表示通信的建立。客户端向服务端的默认服务端口发送一个上传或下载文件的请求,如果服务器接受此请求,则它会打开另外一个端口(假设2045端口)专门用于处理此客户端的请求,直到通信完成后释放20245端口,服务器端的默认服务端口则继续等待其它客户端的请求。数据以定长512字节传输,服务器发出下一个数据包之前必须得到客户对上一个数据包的确认。如果一个数据包小于512字节(包括0字节),则表示传输结束。如果数据包在传输过程中丢失,发出方会在超时后重新传输最后一个未被确认的数据包。

通信的双方都可以是数据的发送者与接收者,一方传输数据并接收应答,另一方发出应答并接收数据。其文件上传/下载的通信流程如图2、图3所示。

3.2 通信关闭及错误处理

一般情况下,通信在最后一个数据包发送完毕并且得到ACK回复后,通信正常关闭。简单文件传输系统的两端各自实现超时重传,如果发送端超时,它将重传丢失的数据块。如果负责确认的一端超时,它将重传丢失的确认。让两端都参与重传有助于保证在丢失单个分组时传送不会失败。

在传输过程中,如果出现错误,服务器端会向客户端发送一个ERROR包,如果客户端收到ERROR包,则通信关闭,如果客户端没有收到,则需要启动超时检测机制。对于ERROR包,服务器端和客户端都不会重传,也不需要ACK确认。

4 基于TFTP协议简单文件传输系统的实现

4.1 客户端实现

客户端主要实现向服务器端发送上传/下载文件请求并实现上传/下载的功能。系统首先初始化客户端程序,创建请求处理任务,然后根据上传/下载命令执行不同的任务。客户端执行流程如图4所示。

4.1.1 文件上传功能的实现

文件上传功能的执行流程如图5所示。

(1)客户端向服务器端发送WRQ写请求报文;

(2)服务器端创建Replysocket、分配新的端口,并发送ACK给客户端;

(3)客户端接收报文,更改socket端口,从文件中读取数据,并发送给服务器端;

(4)服务器端收到数据包后,解析数据并存储到本地文件,并发送ACK给客户端;

(5)客户端接收ACK报文,从文件中读取数据,并发送给服务器端。如此进行,直到文件上传完毕。

图5文件上传功能的执行流程(参见下页)

4.1.2 文件下载功能的实现

文件下载功能的执行流程如图6所示。

(1)客户端向服务器端发送RRQ读请求报文;

(2)服务器端创建Replysocket、分配新的端口,并发送数据给客户端;

(3)客户端接收报文,更改socket端口,解析数据并存储到本地文件,返回ACK;

(4)服务器端收到ACK后,发送下一个数据包;

(5)客户端接收报文,解析数据并存储到本地文件,返回ACK。如此进行,直到文件下载完毕。

图6下载文件功能的执行流程(参见下页)

4.2 服务器端实现

服务器端主要实现响应多个客户端上传/下载文件请求的功能。为了实现对客户端请求及时响应而又不影响其他客户端请求的功能,服务器端采取了多种策略来实现,如采用为客户端重新分配socket和端口、创建链表来保存socket描述信息、消息重传、超时控制等。服务器端执行流程如图7所示。

图7服务器端执行流程(参见右栏)

首先,服务器端初始化一个Msocket,用来响应客户端的请求。如果客户端请求到来,服务器端则会为它重新创建一个Replysocket,并分配新的端口,将其描述信息保存在连接信息队列里。然后分析该请求类型,如果是下载请求,则启动一个下载文件任务;如果是上传请求,则启动一个上传文件任务。其上传/下载文件任务的具体执行过程类似客户端的文件上传/下载功能,这里不再赘述。

5 小结

本文通过研究TFTP协议,实现了基于TFTP协议的简单文件传输系统。TFTP服务器端通过采取创建Replysocket和分配新端口等措施实现了多客户端与服务器的文件传输功能。该系统通过采取超时重传、socket信息保存、上一条消息暂存等方法解决了丢包、多任务执行等问题,具有一定的容错能力。下一步的任务就是实现基于TFTP协议的跨平台的简单文件传输系统,使之无障碍地应用到Vx Works、windows等多种操作系统之上。

参考文献

篇8：文件传输和访问协议

为适应空间网络的文件传输需求,空间数据系统咨询委员会( consultative committee for space data systems,CCSDS) 提出了CCSDS文件传输协议( CCS- DS file delivery protocol,CFDP) 协议,通过四种否定确认机制实现可靠传输［3］,在空间环境下性能大幅优于TCP/FTP协议［4，5］。在CFDP协议的基础上, 文献[6—9]提出了基于喷泉码的半反馈传输协议,避免了反馈重传,但是引入喷泉码需要付出处理延时和硬件开销的代价。文献[10]提出了重复发送错误数据包的机制,它将发生错误需要重传的数据包进行多次重复传输,以增加发送延时为代价,降低了重传次数。结合以上改进的CFDP协议在深空通信( 极长延时) 条件下性能优异,但是在往返延时不那么长( 例如低轨卫星) 的空间网络中,通过降低往返次数获得的收益不足以抵消协议的额外开销。

本文提出了一种基于延时否定确认机制的RF- PP( remote file process protocol,远程文件管理协议) 协议,它采用信令纠错、否定确认( negative acknowl- edgment,NAK) 快速重传和NAK帧结构压缩机制, 降低了重传次数、等待时间和发送延时。分析表明, RFPP比CFDP传输效率更高。

1文件传输协议特征分析

TCP协议采用正确接收回传确认机制实现可靠传输。对于每个成功接收的包,接收端都会回传相应的ACK( acknowledgment,确认) 。空间链路的长延时使TCP发送窗口增长缓慢; 高误码率造成的丢包会使得发送端误认为链路拥塞,减小发送窗口。 这都导致TCP在空间网络中的吞吐量减小、传输效率降低,性能明显下降。

CFDP文件传输协议分为可靠传输与不可靠传输两种方式,其中可靠传输又分为延时否定、立即否定、提示否定和异步否定四种机制［12］。与TCP协议不同,CFDP协议采用否定确认方式保证传输可靠性。接收端对未能正确接收的包,发送NAK包请求重传。延时否定方式下接收端在文件片段全部发送完毕后,回传表示全部丢包的NAK包。它相比于TCP协议,发送窗口不受延时和误码率的影响。但在链路误码率较高,链路速率非对称情况下,CFDP协议存在信令误包率较高( 未对信令进行保护) 、反向链路开销较大等问题,性能仍有提升空间。

2 RFPP文件传输协议

RFPP文件传输协议是一种基于否定应答的文件传输协议,它包括上传和下载两部分主要功能,协议框架如下。

2. 1帧结构

RFPP传输过程包括两种帧: 命令帧和数据帧, 选取与链路层适配的定长帧结构,如图1所示。

2. 2工作流程

RFPP协议中,文件可分为若干个文件片段,文件片段可分为多个数据包,数据包以图1中的数据帧形式传输,是RFPP协议中基本的数据传输单元。 RFPP协议下载流程可概括为以下步骤( 上传过程类似) :

1) 接收端发送文件片段下载请求。

2) 发送端应答此请求并直接发送数据,以EOF ( end of file,文件结束) 命令帧结尾。

3) 发送端完成发送全部数据后,接收端校验是否全部正确接收,如果全部正确接收则转到步骤5) ; 否则发送下载补包请求NAK,并开启NAK计时器。如果计时器到期接收端仍未收到补包,则重发补包请求。补包请求使用图1中的命令帧格式,一个命令帧中可以表示的最多补包数有限,如果请求补包数量超过此上限则继续发送补包请求命令帧, 直到表示完全部补包。

4) 发送端收到补包请求后,根据要求补包的编号,重新发送相应数据包。重复步骤3) ~ 4) 直到所有数据包全部正确接收。

5) 接收端全部正确接收后,发送FIN( finished, 结束) 命令帧,表示当前片段下载成功,请求结束当前片段下载。

6) 发送端收到成功接收命令帧后,发送结束片段下载应答,标志着一次完整的片段下载过程结束。

7) 如果接收端所下载文件多于1个片段,则重复步骤1) ~ 5) ,完成目标文件的下载。

2. 3性能优势

RFPP协议相比于CFDP协议的传输效率提升体现在以下三种机制中。

2. 3. 1信令纠错

这里的信令包括EOF包和FIN包。 EOF和FIN包在每个文件片段传输过程中各传输1次。信令包一旦发生错误,就会带来1个信令计时器的额外延时。通常信令计时器设置为信令发送延时、信令应答发送延时与RTT( round- trip time,往返时间) 之和,可见信令包带来的额外延时较高。与此同时,由于链路层一般采用定长帧结构,对信令进行冗余编码实际上利用了链路适配的填充字节,一般情况下并不增加额外开销。经过信令纠错处理后,可降低信令误包率,提升传输效率。

2. 3. 2 NAK快速重传

图2表示接收端发送NAK请求补包的过程。 接收端在发送NAK后会开启NAK计时器,其目的是触发下一次NAK包( 或FIN包) 的发送。CFDP的NAK计时器设置为图中的timer3:

式中Tprop表示传播延时,TPDU表示数据包发送延时,TNAK表示NAK包发送延时,NL表示请求重传包数。CFDP协议只能等待timer3到期才能发送下个NAK。但如果NAK出现误包,接收端仍需等待timer3到时才能重传。RFPP协议将它拆分为两个计时器timer1和timer2:

timer1的作用是快速重传NAK,timer2的作用是触发下次NAK发送。

只要NAK被发送端正确接收,发送端就会发送回传补包。不论第一个包是否发生误码,此计时器到期时,接收端都应收到数据包。如果收到(不论对错)就开启timer2,准备触发下次NAK(或FIN)发送;否则说明NAK包未被发送端正确接收,应立刻重传上个NAK包,并开启新的timer1。这样在NAK误包时,RFPP协议相比CFDP少等待了一个timer2,提高了传输效率。

2.3.3 NAK帧结构压缩

CFDP协议中NAK包为变长,分别用2个4字节指针来表示一个丢失的数据段的起始和结束偏移量。在RFPP协议中,NAK包采用定长包,用包编号表示丢包,每个丢包占2字节。若丢包数不足包长则填充,若超过则再发送NAK包,直到所有丢包都请求完毕。因此,RFPP协议的NAK包平均长度小于CFDP协议,降低了NAK包发送延时,提高了传输效率。非对称链路中,反向链路速率较低,NAK帧结构压缩能够提高的传输效率更多。

3协议性能分析

3. 1理论吞吐量极限

理想情况下,即信道无误码,链路速率无穷大时,TCP协议的最大吞吐量为W/RTT。其中W为最大发送窗口,RTT为往返时间,TCP协议规定W为64KB。RFPP、CFDP协议的理论吞吐量计算方法相同,但协议并未限制窗口大小,则W对应为发送端buffer大小。发送端buffer大于64 KB的情况很常见,因此RFPP、CFDP协议理论吞吐量性能优于TCP协议。

在非理想条件下,上文已提到TCP协议受链路误码影响更大,会使发送窗口进一步减小,降低吞吐量。此时TCP协议的吞吐量性能与RFPP、CFDP协议相差更大。

3. 2文件传输时间理论分析

各变量含义见表1。RFPP与CFDP的文件片段传输总时间均可表示为以下4部分:

3. 2. 1数据包发送总时间T1

3. 2. 2信令EOF、FIN包传输总时间T2

因为成功发送一个包所需要的次数服从几何分布,从而得到:

3. 2. 3成功回传NAK带来的总延时T3

接收端每成功发送一个NAK包,都会使发送端发送补包,因此

设Y表示某个包的重传次数,X表示最大重传次数,即NAK成功回传次数。

3. 2. 4 NAK误包带来的总延时T4

NAK误包率为: Pp － NAK= 1 - ( 1 - Pb B)LNAK。

以上四部分之和即为文件片段传输总时间:

RFPP协议的三种机制中,采用信令纠错机制进行重复编码后,可将信令的误包率由1-(1-Pb)L减小为,即降低了式(2)中的Pp-EOF和Pp-FIN,从而降低T2;采用NAK快速重传机制后,可在NAK丢包后将计时器减小,即减小了式(4)中的TNAK-TM,从而降低T4;采用NAK帧结构压缩机制后,NAK平均包长由变为了,其中为平均每次重传包数,P为重传包中平均连续错误段数与错误包数的比值。此P值无法给出解析解,通过数值方法计算得出在链路误码率小于10-4时,P均大于0.9,即RFPP的NAK平均包长更小。因此通过NAK帧结构压缩机制,使NAK平均包长变小,即缩短了式(3)中的LNAK从而降低T3。此外NAK平均长度的减小使NAK的误包率由1-(1-Pb B)LNAK-CFDP减为1-(1-Pb B)LNAK-RFPP,即减小了式(4)中的Pp-NAK,从而降低T4。RFPP协议通过这三方面体现出比CFDP协议更低的文件传输时间,即更高的传输效率。

4仿真分析

RFPP协议与CFDP协议均可用于不同空间文件传输场景,这里以低轨卫星星地文件传输为例进行仿真分析。仿真场景为卫星与地面站两个节点, 卫星轨道高度为800 km,倾角为98°,地面站从卫星下载文件。文件片段为1 MB,链路层采用定长帧( 报文长度120字节) ,前向链路速率为2 Mbps,信道误码为随机误码。以上仿真参数是为了模拟RF- PP协议实际应用而选,其它参数在具体仿真场景中给出。

4. 1 RFPP、CFDP、TCP吞吐量对比

前、反向链路误码率均为10－ 5; 链路非对称,反向链路速率为10 Kbps。

图3为各协议发送同样长度文件片段时前向链路吞吐量变化曲线。可以看出RFPP和CFDP在文件发送过程中( 从开始发送到等待重传之前,图中RFPP和CFDP吞吐量降为0表示发送端等待回传NAK) 均可达到满吞吐量( 2 Mbps) ,而TCP则远未达到。高误码率使TCP协议的发送窗口不断波动, 又因为往返延时较高,TCP协议发送文件时进行的多次往返降低了它的吞吐量。图中可以看出TCP的文件片段传输时间远大于RFPP和CFDP,这就是由吞吐量的差距导致的。对比图中RFPP与CFDP的文件片段传输时间,可以发现RFPP因等待NAK的时间更短,而使总时间更短。这是由于RFPP的NAK快速重传、NAK帧结构压缩机制,使发送端更早地完成数据包的重传,降低了文件片段传输时间, 提升了传输效率。由于链路状况相同,RFPP与CFDP发送及重传的总包数( 数据量) 相同,而RFPP更早地完成了传输,因此RFPP的平均吞吐量更高。

4. 2非对称链路对RFPP、CFDP性能影响

前、反向链路误码率均为10－ 5; 反向链路速率分为1 Mbps和10 Kbps,分别对应链路速率对称和非对称情况。NAK平均长度由蒙特卡洛方法得出。

将仿真参数带入式( 1) ~ 式( 5) 可计算得到如表2所示结果。同样参数下,仿真得出结果如表3所示。

对比两表可发现,仿真结果与理论计算均可得到RFPP协议的文件片段传输时间低于CFDP。在非对称链路中,相差更大,此时,RFPP的传输时间比CFDP的降低了,即总的传输效率提高了7.6%。

4. 3链路误码对RFPP、CFDP性能影响

前、反向链路误码率相同且由10－ 8~ 10－ 4变化,对应到数据包误包率为10－ 5~ 10－ 1; 链路非对称,反向链路速率为10 Kbps。RFPP与CFDP的文件片段传输时间与误包率关系曲线如图4所示。

可以看出,RFPP的文件片段传输时间总小于CFDP,且误包率越大,二者之差越大。此性能优势是由上文提到的三种机制得到的。下面通过仿真分析并验证RFPP三种机制所带来的传输效率提升。

4. 3. 1信令纠错

链路非对称,反向链路速率为10 Kbps。

图5为发送端一次EOF误包对发送端发包情况的影响(FIN与EOF情况相同,RFPP与CFDP也相同)。EOF误包后,发送端需等待EOF计时器到期,再重传EOF。所以图中出现了一段不发送数据的时间,图中所标两点之差即为EOF计时器长度。因此信令误包会导致文件片段传输时间上升和平均吞吐量下降。采用信令纠错机制,可大幅降低信令误包率,提升吞吐量和传输效率。

4. 3. 2 NAK快速重传

将反向链路速率设为无穷大进行仿真,这样可以消除NAK帧结构压缩机制的影响因素,仅体现NAK快速重传机制的效果。图6中为一次NAK误包对发送端发包情况的影响。NAK误包后,发送端需等待NAK计时器到期,再重传NAK包。由图中可以看出,采用了NAK快速重传机制后,发送端更早的重传了错误数据包。这是由于接收端更早的重传了NAK包所致,所提前的时间即为timer2,图中所标两点之差即为timer2长度。采用NAK快速重传机制,可降低发送端等待时间,提生平均吞吐量和传输效率。

4. 3. 3 NAK帧结构压缩

前、反向链路误码率均为10－ 5; 链路非对称,反向链路速率为10 Kbps。

图中可以看出,CFDP的反向链路吞吐量远大于RFPP。RFPP采用NAK帧结构压缩机制后,使得NAK平均长度减小,对反向链路的占用也变少。 RFPP较小的NAK包能更快地发送完毕,从而提升了传输效率。在反向链路速率较小时,提升更为明显。

综上,RFPP协议通过信令纠错、NAK快速重传和NAK帧结构压缩三种机制获得了相对于CFDP协议更高的吞吐量和传输效率。其在链路速率不对称的情况下更为明显,且随着链路误包率增大而增大。

5结论

空间文件传输存在高误码、长延时、链路速率不对称等问题。本文提出了基于延时否定确认机制的RFPP协议: 采用信令纠错机制以降低信令错误率及重传次数; 采用NAK快速重传机制以减少在NAK误包后的等待时间; 采用NAK帧结构压缩机制以降低NAK平均包长。理论和仿真分析表明, RFPP比CFDP具有更高的吞吐量和传输效率。尤其在链路速率不对称情况下优势明显( 低轨卫星非对称链路速率情况下,传输效率提高了7. 6% ) 。 RFPP协议已应用于低轨卫星灵巧通信试验卫星中,实测吞吐特征与仿真( 图3) 类似,峰值信道利用率接近100% ,性能良好。

摘要：针对空间网络中存在的高误码率、长延时、链路速率非对称等问题,提出了一种基于否定确认机制的远程文件管理协议(remote file process protocol,RFPP)协议。RFPP协议采用了信令纠错、否定确认(negative acknowledgment,NAK)快速重传和NAK帧结构压缩等机制,分析表明RFPP比CCSDS文件传输协议(CCSDS file delivery protocol,CFDP)具有更高的传输效率。在低轨卫星非对称链路仿真场景下,RFPP比CFDP的效率提高了7.6%。RFPP协议已成功应用于灵巧通信试验卫星,实测信道利用率大于90%。