<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
匿名FTP
由于登录FTP需要相应的账号和密码，这对于那些公共的FTP站点不太方便。使用匿名FTP则有效的解决这个问题。所谓匿名FTP，即是任何人都可以使用通用账号Anonymous登录，所需密码为（任意的）自己的email地址。这个密码只是为了方便服务器端log之用。
匿名FTP需要注意的一点就是，在有些FTP实现上，如果客户端的IP无法反向解析到一个主机名称的话，服务器将拒绝登录。
所谓反向解析就是指从一个IP查询其对应的DNS名称的过程。很多主机一般比较注意从DNS名称到IP的正向解析，而对反向则不那么注意。
FTP传输的中断
（出自 R. Stevens 《TCP/IP Illustrated V.1》）
现在看一下FTP客户是怎样异常中止一个来自服务器的文件传输。异常中止从客户传向服务器的文件很容易—只要客户停止在数据连接上发送数据，并发出ABOR命令到控制连接上的服务器即可。而异常中止接收就复杂多了，这是因为客户要告知服务器立即停止发送数据。我们前面提到要使用Telnet同步信号，下面的例子就是这样。
我们先发起一个接收，并在它开始后键入中断键。这里是交互会话，其中初始注册被略去：
ftp > get a . out 取一个大文件
--- > TYPE I //客户和服务器都是8 bit字节的Unix系统
200 Type set to I .
--- > PORT 140 , 252 , 13 , 66 , 4 , 99
200 PORT command successful .
--- > RETR a . out
150 Opening BINARY mode data connection for a . out ( 28672 bytes ).
^ ? //键入的中断键
receive aborted //客户端输出
waiting for remote to finish abort //客户端输出
426 Transfer aborted . Data connection closed .
226 Abort successful
1536 bytes received in 1.7 seconds ( 0.89 Kbytes / s )
在我们键入中断键之后，客户立即告知我们它将发起异常中止，并正在等待服务器完成。服务器发出两个应答： 426和226。这两个应答都是由Unix 服务器在收到来自客户的紧急数据和ABOR命令时发出的。
下面两幅图片显示的就是这个过程。其中左边的bsdi是客户端，IP 140.252.13.66；右边的slip是FTP服务器，IP为140.252.13.65。最左端显示的时间点。开始bsdi向slip发送TYPE I命令，将传输设置为Image，也即Binary模式。途中的实线部分表示控制连接，虚线标志数据连接。
上面是数据开始传输，中断命令发出之前的部分。
报文段13是数据连接上来自服务器的第6个数据报文段，后跟由我们键入的中断键产生的报文段14。客户发出10个字节来异常中止传输：
< IAC,IP,IAC,DM,A,B,R, r, n >
我们看到有两个报文段（14和15)涉及到TCP的紧急指针（我们在图26 - 17中看过对Telnet问题也做相同的处理）。Host Requirements RFC指出紧急指针应指向紧急数据的最后一个字节，而多数伯克利的派生实现使之指向紧急数据最后一个字节后面的第一个字节。了解到紧急指针将（错误地）指向下一个要写的字节（数据标志，DM。在序号为54处），FTP客户进程特意写前3个字节作为紧急数据。首先写下的3字节紧急数据与紧急指针一起被立即发送，紧接着是后面7个字节（BSD FTP 服务器不会出现由客户使用的紧急指针的解释问题。当服务器收到控制连接上的紧急数据时，它读下一个FTP命令，寻找ABOR或STAT，忽略嵌入的Telnet命令）。
注意到尽管服务器指出传输被异常中止（报文段18，在控制连接上），客户进程还要在数据连接上再接收14个报文段的数据（序列号是1537 ~ 5120）。这些报文段可能在收到异常中止时，还在服务器上的网络设备驱动器中排队，但客户打印“收到1536字节”，意思是在发出异常中止后（报文段14和15），略去收到的所有数据报文段。一旦Telnet用户键入中断键，我们看到Unix客户在默认情况下不发出中断进程命令作为紧急数据。因为几乎没有机会用流控制来中止从客户进程到服务器进程的数据流，所以我们说这样就行了。
FTP的客户进程也通过控制连接发送一个中断进程命令，因为两个连接正在被使用，因此没有机会用流控制来中止控制连接。为什么FTP发送中断进程命令作为紧急数据而Telnet不呢？答案在于FTP使用两个连接，而Telnet只使用一个，在某些操作系统上要求一个进程同时监控两个连接的输入是困难的。FTP假设这些临界的操作系统至少提供紧急数据在控制连接上已到达的通知，而后让服务器从处理数据连接切换到控制连接上来。
---完---
参考资料：
RFC 959: File Transfer Protocol
Richard Stevens 《TCP/IP Illustrated, Vol 1 Protocol》Chapter 27