一.简单文件传输协议介绍
文件传输协议规范了本地从远程服务器上访问文件的方式。
文件传输协议分为两类：1.online-access 和 2.whole file copying。前者的代表协议为NFS，类似于共享文档，在本地对文件的修改会影响服务器上的文件。而后者本质上是复制：向服务器上传文件（把本地文件copy到服务器上）和从服务器下载文件（把文件copy到本地）。对一个副本的修改，不会影响原本的文件。
TFTP的全称为Trivial File Transfer Protocol，与FTP相比较为简单：
1.基于UDP设计的应用层协议。端口为69。当然也支持其他的传输层协议，比如TCP。
2.没有access control，即没有登陆验证。
3.没有文件夹，所有的文件都放在根目录下。
4.设计的理念就是简单简单再简单，所以开销很小，常用于无盘工作站和对内存要求苛刻（可用内存小）的环境。
二.TFTP packet format
TFTP packet由TFTP header和TFTP data组成。首部中有一个两字节的opcode标注了该TFTP packet的类型，总共有5种。我们会逐一介绍。
2.1 RRQ(read request)
opcode = 01(十进制意义上的)，表明该packet为RRQ型，用于本地向服务器申请下载文件。文件名由filename字段指定，为ASCII码字符串，可变长，以NULL结尾。mode字段也是一个可变长的ASCII码字符串，以NULL结尾，其限定了文件的传输模式（不同格式的文件的传输模式，或说方式肯定是不同的，比如二进制文件和txt文件），我们后面会讲。
2.2 WRQ(write request)
用于本地向服务器申请上传文件，opcode为02。其余和RRQ一致。
2.3 DATA(data)
opcode = 03。用于上传或是下载文件时的数据传输。文件过大，则会被拆分为多个数据段进行传输。block#字段标识了数据段的序号，方便后续数据的重组。data字段放置0-512字节的数据。对于大小不为512字节倍数的文件而言，最后一个data packet的data字段的大小小于512字节；对于恰好为512字节倍数大小的文件，最后往往会发一个data field为0字节的data packet，以避免一个data field为512字节大小的data packet作为该文件的最后一个data packet。
2.4 ACK(acknowledgement)
opcode = 04。用于服务器对于本地传输的data packet的响应。比如本地传来一个block#为xxx的data packet，服务器收到后则会进行确认，返回一个block#字段也为xxx的data packet。
注意仅仅是对data packet的确认，对WRQ和RRQ等其他类型不会返回ACK。
2.5 ERROR(error)
opcode = 05。errcode字段指明了错误类型，errorstring字段给出错误提示。其中errorstring是以ASCII码字符串的形式给出错误提示的，其可变长，且以NULL结尾。
2.6 transfer mode说明
介绍用于传输txt文件的Netascii和传输二进制文件的Octet模式。
Netascii模式用于传输txt格式的文件，其按行传输。发送方会在每一行结尾加上\r\n，而接收方会把它去掉。
Octet用于二进制文件的传输，是按照字节传输的，不需要发送方和接收做类似的增添除去处理。
3.TFTP协议说明
TFTP协议的packet format已经说明，下面说明TFTP的operations。
我们知道TFTP是用于点对点的简单文件传输，这两点实际上是对称的，均可作为服务器或是客户端。TFTP是基于UDP设计的，这一点非常奇怪，尤其是考虑文件传输需要保证可靠性，而UDP不保证可靠性。那么文件传输的可靠性由谁保证呢？自然是应用层的TFTP协议，其用ACK型packet保证data packet传输的可靠性。
3.1 TFTP传输文件的基本过程和可靠性的保证
我们仅考虑数据传输的过程（仅考虑ACK和DATA packet），暂时不考虑WRQ和RRQ等packet。
记住两个事实：
1.首先，server和client端各自维护了一个计时器，用于判断其发送的数据是否超时。
2.另外，server和client端传输数据采取stop and wait方式，没有收到对上一个数据的确认，不发下一个。
Server端发送data[1]，并开始计时，希望得到client端ack(1)的响应。若计时器timeout后仍未收到ack(1)，则server端认为data[1]丢失，并重传；在时限内一旦收到ack(1)，server会立刻发送ack(2)。
Client端接收到data(1)，立刻发送ack(1)，并开始计时，希望收到server端data(2)的响应。若计时器timeout之后仍未收到data(2)，则client端认为ack(1)丢失，并重传；在时限内一旦受到data(2)，client端会立刻发送ack(2)。
3.2 SAS(sorcerer's apprentice syndrome)
这代表原来TFTP协议的缺陷。原来的TFTP协议设计：client端一旦收到ack(n)，不论是否接收过，都立刻发送data(n+1)，即使data(n+1)已经发送过了；server端一旦受到data(n)，不论是否接收过，都立刻发送ack(n)。而dealyed but not lost ack会引发SAS，使得后续的data均被传输两遍。
解决办法就是在sender端算法里面再加一个判断，若ack(n)重复，则不发数据data(n+1)。
3.3 状态转移图
五种packet中没有标志传输结束的，需要依靠DATA packet隐式地表示（data域不足512B）。
为了避免SAS，可以把server端的ACK(n)改为：ACK(n) and not duplicate。
