tftp - 簡單文件傳輸協(xié)議
TFTP（Trivial File Transfer Protocol,簡單文件傳輸協(xié)議）是TCP/IP協(xié)議族中的一個用來在客戶機與服務(wù)器之間進行簡單文件傳輸?shù)膮f(xié)議，提供不復(fù)雜、開銷不大的文件傳輸服務(wù)。端口號為69。傳輸中有三種模式：netascii，這是8位的ASCII碼形式，另一種是octet，這是8位源數(shù)據(jù)類型；最后一種mail已經(jīng)不再支持，它將返回的數(shù)據(jù)直接返回給用戶而不是保存為文件。
目的
TFTP是一個傳輸文件的簡單協(xié)議，它其于UDP協(xié)議而實現(xiàn)，但是我們也不能確定有些TFTP協(xié)議是基于其它傳輸協(xié)議完成的。此協(xié)議設(shè)計的時候是進行小文件傳輸?shù)摹Ｒ虼怂痪邆渫ǔ５腇TP的許多功能，它只能從文件服務(wù)器上獲得或?qū)懭胛募荒芰谐瞿夸?，不進行認證，它傳輸8位數(shù)據(jù)。傳輸中有三種模式：netascii，這是8位的ASCII碼形式，另一種是octet，這是8位源數(shù)據(jù)類型；最后一種mail已經(jīng)不再支持，它將返回的數(shù)據(jù)直接返回給用戶而不是保存為文件。
概況
任何傳輸起自一個讀取或?qū)懭胛募恼埱?，這個請求也是連接請求。如果服務(wù)器批準此請求，則服務(wù)器打開連接，數(shù)據(jù)以定長512字節(jié)傳輸。每個數(shù)據(jù)包包括一塊數(shù)據(jù)，服務(wù)器發(fā)出下一個數(shù)據(jù)包以前必須得到客戶對上一個數(shù)據(jù)包的確認。如果一個數(shù)據(jù)包的大小小于512字節(jié)，則表示傳輸結(jié)構(gòu)。如果數(shù)據(jù)包在傳輸過程中丟失，發(fā)出方會在超時后重新傳輸最后一個未被確認的數(shù)據(jù)包。通信的雙方都是數(shù)據(jù)的發(fā)出者與接收者，一方傳輸數(shù)據(jù)接收應(yīng)答，另一方發(fā)出應(yīng)答接收數(shù)據(jù)。大部分的錯誤會導(dǎo)致連接中斷，錯誤由一個錯誤的數(shù)據(jù)包引起。這個包不會被確認，也不會被重新發(fā)送，因此另一方無法接收到。如果錯誤包丟失，則使用超時機制。錯誤主要是由下面三種情況引起的：不能滿足請求，收到的數(shù)據(jù)包內(nèi)容錯誤，而這種錯誤不能由延時或重發(fā)解釋，對需要資源的訪問丟失（如硬盤滿）。TFTP只在一種情況下不中斷連接，這種情況是源端口不正確，在這種情況下，指示錯誤的包會被發(fā)送到源機。這個協(xié)議限制很多，這是都是為了實現(xiàn)起來比較方便而進行的。
特點
因為TFTP使用UDP，而UDP使用IP，IP可以還使用其它本地通信方法。因此一個TFTP包中會有以下幾段：本地媒介頭，IP頭，數(shù)據(jù)報頭，TFTP頭，剩下的就是TFTP數(shù)據(jù)了。TFTP在IP頭中不指定任何數(shù)據(jù)，但是它使用UDP中的源和目標端口以及包長度域。由TFTP使用的包標記（TID）在這里被用做端口，因此TID必須介于0到65,535之間。對它的初始化我們在后面討論。TFTP頭中包括兩上字節(jié)的操作碼，這個碼指出了包的類型下面我們看看大體上的TFTP包格式，相關(guān)的內(nèi)容我們在后面的章節(jié)中進行討論。
—————————————————
| Local Medium | Internet | Datagram | TFTP |
—————————————————
?包頭次序
初始連接
初始連接時候需要發(fā)出wrq（請求寫入遠程系統(tǒng)）或RRQ（請求讀取遠程系統(tǒng)），收到一個確定應(yīng)答，一個確定可以寫出的包或應(yīng)該讀取的第一塊數(shù)據(jù)。通常確認包包括要確認的包的包號，每個數(shù)據(jù)包都與一個塊號相對應(yīng)，塊號從1開始而且是連續(xù)的。因此對于寫入請求的確定是一個比較特殊的情況，因此它的包的包號是0。如果收到的包是一個錯誤的包，則這個請求被拒絕。創(chuàng)建連接時，通信雙方隨機選擇一個TID，因此是隨機選擇的，因此兩次選擇同一個ID的可能性就很小了。每個包包括兩個TID，發(fā)送者ID和接收者ID。這些ID用于在UDP通信時選擇端口，請求主機選擇ID的方法上面已經(jīng)說過了，在第一次請求的時候它會將請求發(fā)到TID69，也就是服務(wù)器的69端口上。應(yīng)答時，服務(wù)器使用一個選擇好的TID作為源TID，并用上一個包中的TID作為目的ID進行發(fā)送。這兩個被選擇的ID在隨后的通信中會被一直使用。下例是一個寫入的例子，其中WRQ，ACK和DATA代表寫入請求，確認和數(shù)據(jù)。
1. 主機A向主機B發(fā)出WRQ，其中端口為69
2. B機向A機發(fā)出ACK，塊號為0，包括B和A的TID
此時連接建立，第一個數(shù)據(jù)包以序列號1從主機開始發(fā)出。以后兩臺主機要保證以開始時確定的TID進行通信。如果源ID與原來確定的ID不一樣，這個包會被認識為發(fā)送到了錯誤的地址而被拋棄。錯誤的包是被發(fā)送到正確端口的，但是包本身有錯誤。設(shè)想發(fā)送方發(fā)出一個請求，這個請求在網(wǎng)絡(luò)的那個設(shè)備中被復(fù)制成兩個包，接收方先后接收到兩個包。接收方會認為為這是兩個獨立的請求，會返回兩個應(yīng)答。當(dāng)這兩個應(yīng)答其中之一被接收到時，連接已經(jīng)建立。第二個應(yīng)答再到達時，這個包會被拋棄，而不會因為接收到第二個應(yīng)答包而導(dǎo)致第一個建立的連接失敗。
TFTP包
TFTP支持五種類型的包，我們在以上已經(jīng)說明這五種類型的包：
opcode operation
1 Read request - RRQ
2 Write request - WRQ
3 Data - DATA
4 Acknowledgment - ACK
5 Error - ERROR
包頭中包括了這個包所指定的操作碼。
2 bytes string 1 byte string 1 byte
————————————————
| Opcode | Filename | 0 | Mode | 0 |
————————————————
RRQ/WRQ包
RRQ和WRQ包（代碼分別為1和2）的格式如上所示。文件名是NETASCII碼字符，以0結(jié)束。 而MODE域包括了字符串"netascii"，"octet"或"mail"，名稱不分大小寫。接收到NETASCII格式數(shù)據(jù)的主機必須將數(shù)據(jù)轉(zhuǎn)換為本地格式。OCTET模式用于傳輸文件，這種文件在源機上以8位格式存儲。假設(shè)每個機器都存在一個8位的格式，這樣的假設(shè)是最一般的。比如DEC-20，這是一種36位機，我們可以假設(shè)它是4個8位外加另外4位而構(gòu)成。如果機器收到OCTET格式文件，返回時必須與原來文件完全一樣。在使用MAIL模式時，用戶可以在FILE處使用接收人地址，這個地址可以是用戶名或用戶名@主機的形式，如果是后一種形式，允許主機使用電子郵件傳輸此文件。如果使用MAIL類型，包必須以WRQ開始，否則它與NETASCII完全一樣。我們的討論建立在發(fā)送方和接收方都在相同模式的情況下，但是雙方可以以不同的模式進行傳輸。例如一個機器可以是一臺存儲服務(wù)器，這樣一臺服務(wù)器需要將NETASCII格式轉(zhuǎn)換為自己的格式。另外，我們可以設(shè)想DEC-20這種機器，它使用36位字長，用戶這邊可以使用特殊的機制一次讀取36位，而服務(wù)器卻可以仍然使用8位格式。在這兩種情況下，我們看到了兩臺機器使用不同格式的情況。可以在兩臺主機間定義其它的傳輸方式，但是定義要小心，因為這種傳輸方式不為人知，而且也沒有權(quán)威機構(gòu)為其指定名稱或定義它的模式。
2 bytes 2 bytes n bytes
———————————-
| Opcode | Block # | Data |
———————————-
DATA包
數(shù)據(jù)在數(shù)據(jù)包中傳輸，其格式如上圖所示。數(shù)據(jù)包的OP碼為3，它還包括有一個數(shù)據(jù)塊號和數(shù)據(jù)。數(shù)據(jù)塊號域從1開始編碼，每個數(shù)據(jù)塊加1，這樣接收方可以確定這個包是新數(shù)據(jù)還是已經(jīng)接收過的數(shù)據(jù)。數(shù)據(jù)域從0字節(jié)到512字節(jié)。如果數(shù)據(jù)域是512字節(jié)則它不是最后一個包，如果小于512字節(jié)則表示這個包是最后一個包。除了ACK和用于中斷的包外，其它的包均得到確認。發(fā)出新的數(shù)據(jù)包等于確認上次的包。WRQ和DATA包由ACK或ERROR數(shù)據(jù)包確認，而RRQ數(shù)據(jù)包由DATA或ERROR數(shù)據(jù)包確認。下圖即是一個ACK包，操作碼為4。其中的包號為要確認的數(shù)據(jù)包的包號。
2 bytes 2 bytes
———————
| Opcode | Block # |
———————
Figure 5-3: ACK包
WRQ數(shù)據(jù)包被ACK數(shù)據(jù)包確認，WRQ數(shù)據(jù)包的包號為0。
2 bytes 2 bytes string 1 byte
—————————————–
| Opcode | ErrorCode | ErrMsg | 0 |
—————————————–
Figure 5-4: ERROR包
一個ERROR包，它的操作碼是5，它的格式如上所示。此包可以被其它任何類型的包確認。錯誤碼指定錯誤的類型。錯誤的值和錯誤的意義在附錄中。錯誤信息是供程序員使用的。
相關(guān)應(yīng)用
1．主機A向主機B發(fā)出WRQ，其中端口為69
2．?B機向A機發(fā)出ACK，塊號為0，包括B和A的TID
此時連接建立，第一個數(shù)據(jù)包以序列號1從主機開始發(fā)出。以后兩臺主機要保證以開始時確定的TID進行通信。如果源ID與原來確定的ID不一樣，這個包會被認識為發(fā)送到了錯誤的地址而被拋棄。錯誤的包是被發(fā)送到正確端口的，但是包本身有錯誤。設(shè)想發(fā)送方發(fā)出一個請求，這個請求在網(wǎng)絡(luò)的那個設(shè)備中被復(fù)制成兩個包，接收方先后接收到兩個包。接收方會認為為這是兩個獨立的請求，會返回兩個應(yīng)答。當(dāng)這兩個應(yīng)答其中之一被接收到時，連接已經(jīng)建立。第二個應(yīng)答再到達時，這個包會被拋棄，而不會因為接收到第二個應(yīng)答包而導(dǎo)致第一個建立的連接失敗。
5．?TFTP包
TFTP支持五種類型的包，我們在以上已經(jīng)說明這五種類型的包：
opcode?operation
1．Read?request? - RRQ
2．Write?request? - WRQ
3．Data? - DATA
4．Acknowledgment? - ACK
5．Error? - ERROR
包頭中包括了這個包所指定的操作碼。
2．bytes?string?1?byte?string?1?byte
|?Opcode?|?Filename?|?0?|?Mode?|?0
Figure?5-1:?RRQ/WRQ包
RRQ和WRQ包（代碼分別為1和2）的格式如上所示。文件名是NETASCII碼字符，以0結(jié)束。而MODE域包括了字符串"netascii"，"octet"或"mail"，名稱不分大小寫。接收到NETASCII格式數(shù)據(jù)的主機必須將數(shù)據(jù)轉(zhuǎn)換為本地格式。OCTET模式用于傳輸文件，這種文件在源機上以8位格式存儲。假設(shè)每個機器都存在一個8位的格式，這樣的假設(shè)是最一般的。比如DEC-20，這是一種36位機，我們可以假設(shè)它是4個8位外加另外4位而構(gòu)成。如果機器收到OCTET格式文件，返回時必須與原來文件完全一樣。在使用MAIL模式時，用戶可以在FILE處使用接收人地址，這個地址可以是用戶名或用戶名@主機的形式，如果是后一種形式，允許主機使用電子郵件傳輸此文件。如果使用MAIL類型，包必須以WRQ開始，否則它與NETASCII完全一樣。我們的討論建立在發(fā)送方和接收方都在相同模式的情況下，但是雙方可以以不同的模式進行傳輸。例如一個機器可以是一臺存儲服務(wù)器，這樣一臺服務(wù)器需要將NETASCII格式轉(zhuǎn)換為自己的格式。另外，我們可以設(shè)想DEC-20這種機器，它使用36位字長，用戶這邊可以使用特殊的機制一次讀取36位，而服務(wù)器卻可以仍然使用8位格式。在這兩種情況下，我們看到了兩臺機器使用不同格式的情況。可以在兩臺主機間定義其它的傳輸方式，但是定義要小心，因為這種傳輸方式不為人知，而且也沒有權(quán)威機構(gòu)為其指定名稱或定義它的模式。
2．bytes?2?bytes?n?byte
|?Opcode?|?Block?#?|?Data?|
Figure?5-2:?DATA包
數(shù)據(jù)在數(shù)據(jù)包中傳輸，其格式如上圖所示。數(shù)據(jù)包的OP碼為3，它還包括有一個數(shù)據(jù)塊號和數(shù)據(jù)。數(shù)據(jù)塊號域從1開始編碼，每個數(shù)據(jù)塊加1，這樣接收方可以確定這個包是新數(shù)據(jù)還是已經(jīng)接收過的數(shù)據(jù)。數(shù)據(jù)域從0字節(jié)到512字節(jié)。如果數(shù)據(jù)域是512字節(jié)則它不是最后一個包，如果小于512字節(jié)則表示這個包是最后一個包。除了ACK和用于中斷的包外，其它的包均得到確認。發(fā)出新的數(shù)據(jù)包等于確認上次的包。WRQ和DATA包由ACK或ERROR數(shù)據(jù)包確認，而RRQ數(shù)據(jù)包由DATA或ERROR數(shù)據(jù)包確認。下圖即是一個ACK包，操作碼為4。其中的包號為要確認的數(shù)據(jù)包的包號。
2．bytes?2?bytes
———————
|?Opcode?|?Block?#?|
———————
Figure?5-3:?ACK包
WRQ數(shù)據(jù)包被ACK數(shù)據(jù)包確認，WRQ數(shù)據(jù)包的包號為0。
2．bytes?2?bytes?string?1?byte
|?Opcode?|?ErrorCode?|?ErrMsg?|?0?|
Figure?5-4:?ERROR包
一個ERROR包，它的操作碼是5，它的格式如上所示。此包可以被其它任何類型的包確認。錯誤碼指定錯誤的類型。錯誤的值和錯誤的意義在附錄中。錯誤信息是供程序員使用的。
正常終止
傳輸?shù)慕Y(jié)束由DATA數(shù)據(jù)標記，其包括0-511個字符。這個包可以被其它數(shù)據(jù)包確認。接收方在發(fā)出對最后數(shù)據(jù)包的確認后可以斷開連接，當(dāng)然，適當(dāng)?shù)牡却潜容^好的，如果最后的確定包丟失可以再次傳輸。如果發(fā)出確認后仍然收到最后數(shù)據(jù)包，可以確定最后的確認丟失。發(fā)送最后一個DATA包的主機必須等待對此包的確認或超時。如果響應(yīng)是ACK，傳輸完成。如果發(fā)送方超時并不準備重新發(fā)送并且接收方有問題或網(wǎng)絡(luò)有問題時，發(fā)送也正常結(jié)束。當(dāng)然實現(xiàn)時也可以是非正常結(jié)束，但無論如何連接都將被關(guān)閉。
早終結(jié)
如果請求不能被滿足，或者在傳輸中發(fā)生錯誤，需要發(fā)送ERROR包。這僅是一種傳輸友好的方式，這種包不會被確認也不會被重新傳輸，因此這種包可能永遠不會被接收到。因此需要用超時來偵測錯誤。
附錄
包頭的次序
2 bytes
———————————————————-
| Local Medium | Internet | Datagram | TFTP Opcode |
———————————————————-
TFTP格式
Type Op # 沒有包頭的格式
2 bytes string 1 byte string 1 byte
———————————————–
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ ———————————————–
2 bytes 2 bytes n bytes
———————————
DATA | 03 | Block # | Data |
———————————
2 bytes 2 bytes
——————-
ACK | 04 | Block # |
——————–
2 bytes 2 bytes string 1 byte
—————————————-
ERROR | 05 | ErrorCode | ErrMsg | 0 |
—————————————-
讀文件的初始連接
1. 主機A發(fā)RRQ到A，包括源=A的ID和目的=69
2. 主機B發(fā)送DATA，其中包號=1，這個包被傳送到A，源=B的ID，目的=A的ID
錯誤碼
Value Meaning
0 未定義，請參閱錯誤信息（如果提示這種信息的話）
1 文件未找到
2 訪問非法
3 磁盤滿或超過分配的配額
4 非法的TFTP操作
5 未知的傳輸ID
6 文件已經(jīng)存在
7 沒有類似的用戶
Internet用戶數(shù)據(jù)報頭
（TFTP不一定非要在UDP上實現(xiàn)。）
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
域的值
Source Port 由傳輸發(fā)起方選擇
Dest. Port 由目的地選擇（如果是RRQ或WRQ，其值為69）
Length 包括UDP包頭的包長度
Checksum 校驗碼，如果是0，則未使用校驗
注意：TFTP將傳輸標記TID傳送給UDP作為源和目的端口
安全問題
因為TFTP沒有安全控制機制，因此安全問題應(yīng)該多加考慮。通常TFTP允許下載數(shù)據(jù)而不允許上傳數(shù)據(jù)。
FTP使用精萃–FTP的內(nèi)部命令
FTP命令是Internet用戶使用最頻繁的命令之一，不論是在DOS還是UNIX操作系統(tǒng)
下使用FTP，都會遇到大量的FTP內(nèi)部命令。熟悉并靈活應(yīng)用FTP的內(nèi)部命令，可
以大大方便使用者，并收到事半功倍之效。
FTP的命令行格式為：ftp-v-d-i-n-g[主機名]，其中
-v顯示遠程服務(wù)器的所有響應(yīng)信息；
-n限制ftp的自動登錄，即不使用；
.netrc文件；
-d使用調(diào)試方式；
-g取消全局文件名。
ftp使用的內(nèi)部命令如下 - 中括號表示可選項:
1.![cmd[args>：在本地機中執(zhí)行交互shell，exit回到ftp環(huán)境，如：!ls*
.zip.
2.$macro-ame[args]：執(zhí)行宏定義macro-name.
3.account[password]：提供登錄遠程系統(tǒng)成功后訪問系統(tǒng)資源所需的補充口
令。
4.appendlocal-file[remote-file]：將本地文件追加到遠程系統(tǒng)主機，若
未指定遠程系統(tǒng)文件名，則使用本地文件名。
5.ascii：使用ascii類型傳輸方式。
6.bell：每個命令執(zhí)行完畢后計算機響鈴一次。
7.bin：使用二進制文件傳輸方式。
8.bye：退出ftp會話過程。
9.case：在使用mget時，將遠程主機文件名中的大寫轉(zhuǎn)為小寫字母。
10.cdremote-dir：進入遠程主機目錄。
11.cdup：進入遠程主機目錄的父目錄。
12.chmodmodefile-name：將遠程主機文件file-name的存取方式設(shè)置為mo
de，如：chmod777a.out。
13.close：中斷與遠程服務(wù)器的ftp會話 - 與open對應(yīng)。
14.cr：使用asscii方式傳輸文件時，將回車換行轉(zhuǎn)換為回行。
15.deleteremote-file：刪除遠程主機文件。
16.debug[debug-value]：設(shè)置調(diào)試方式，顯示發(fā)送至遠程主機的每條命令
，如：debup3，若設(shè)為0，表示取消debug。
17.dir[remote-dir][local-file]：顯示遠程主機目錄，并將結(jié)果存入本地
文件local-file。
18.disconnection：同close。
19.formformat：將文件傳輸方式設(shè)置為format，缺省為file方式。
20.getremote-file[local-file]：將遠程主機的文件remote-file傳至本
地硬盤的local-file。
21.glob：設(shè)置mdelete，mget，mput的文件名擴展，缺省時不擴展文件名，
同命令行的-g參數(shù)。
22.hash：每傳輸1024字節(jié)，顯示一個hash符號 - #。
23.help[cmd]：顯示ftp內(nèi)部命令cmd的幫助信息，如：helpget。
24.idle[seconds]：將遠程服務(wù)器的休眠計時器設(shè)為[seconds]秒。
25.image：設(shè)置二進制傳輸方式 - 同binary。
26.lcd[dir]：將本地工作目錄切換至dir。
27.ls[remote-dir][local-file]：顯示遠程目錄remote-dir，并存入本地
文件local-file。
28.macdefmacro-name：定義一個宏，遇到macdef下的空行時，宏定義結(jié)束
。
29.mdelete[remote-file]：刪除遠程主機文件。
30.mdirremote-fileslocal-file：與dir類似，但可指定多個遠程文件，
如：mdir*.o.*.zipoutfile。
31.mgetremote-files：傳輸多個遠程文件。
32.mkdirdir-name：在遠程主機中建一目錄。
33.mlsremote-filelocal-file：同nlist，但可指定多個文件名。
34.mode[modename]：將文件傳輸方式設(shè)置為modename，缺省為stream方式
。
35.modtimefile-name：顯示遠程主機文件的最后修改時間。
36.mputlocal-file：將多個文件傳輸至遠程主機。
37.newerfile-name：如果遠程機中file-name的修改時間比本地硬盤同名
文件的時間更近，則重傳該文件。
38.nlist[remote-dir][local-file]：顯示遠程主機目錄的文件清單，并存
入本地硬盤的local-file。
39.nmap[inpatternoutpattern]：設(shè)置文件名映射機制，使得文件傳輸時
，文件中的某些字符相互轉(zhuǎn)換，如：nmap$1.$2.$3[$1，$2].[$2，$3]，則傳輸
文件a1.a2.a3時，文件名變?yōu)閍1，a2。該命令特別適用于遠程主機為非UNIX機的
情況。
40.ntrans[inchars[outchars>：設(shè)置文件名字符的翻譯機制，如ntrans
1R，則文件名LLL將變?yōu)镽RR。
41.openhost[port]：建立指定ftp服務(wù)器連接，可指定連接端口。
42.passive：進入被動傳輸方式。
43.prompt：設(shè)置多個文件傳輸時的交互提示。
44.proxyftp-cmd：在次要控制連接中，執(zhí)行一條ftp命令，該命令允許連
接兩個ftp服務(wù)器，以在兩個服務(wù)器間傳輸文件。第一條ftp命令必須為open，以
首先建立兩個服務(wù)器間的連接。
45.putlocal-file[remote-file]：將本地文件local-file傳送至遠程主機
。
46.pwd：顯示遠程主機的當(dāng)前工作目錄。
47.quit：同bye，退出ftp會話。
48.quotearg1，arg2…：將參數(shù)逐字發(fā)至遠程ftp服務(wù)器，如：quotesys
t.
49.recvremote-file[local-file]：同get。
50.regetremote-file[local-file]：類似于get，但若local-file存在，則
從上次傳輸中斷處續(xù)傳。
51.rhelp[cmd-name]：請求獲得遠程主機的幫助。
52.rstatus[file-name]：若未指定文件名，則顯示遠程主機的狀態(tài)，否則顯
示文件狀態(tài)。
53.rename[from][to]：更改遠程主機文件名。
54.reset：清除回答隊列。
55.restartmarker：從指定的標志marker處，重新開始get或put，如：res
tart130。
56.rmdirdir-name：刪除遠程主機目錄。
57.runique：設(shè)置文件名唯一性存儲，若文件存在，則在原文件后加后綴..
1，.2等。
58.sendlocal-file[remote-file]：同put。
59.sendport：設(shè)置PORT命令的使用。
60.sitearg1，arg2…：將參數(shù)作為site命令逐字發(fā)送至遠程ftp主機。
61.sizefile-name：顯示遠程主機文件大小，如：siteidle7200。
62.status：顯示當(dāng)前ftp狀態(tài)。
63.struct[struct-name]：將文件傳輸結(jié)構(gòu)設(shè)置為struct-name，缺省時使
用stream結(jié)構(gòu)。
64.sunique：將遠程主機文件名存儲設(shè)置為唯一 - 與runique對應(yīng)。
65.system：顯示遠程主機的操作系統(tǒng)類型。
66.TENEX：將文件傳輸類型設(shè)置為TENEX機的所需的類型。
67.tick：設(shè)置傳輸時的字節(jié)計數(shù)器。
68.trace：設(shè)置包跟蹤。
69.type[type-name]：設(shè)置文件傳輸類型為type-name，缺省為ascii，如：
typebinary，設(shè)置二進制傳輸方式。
70.umask[newmask]：將遠程服務(wù)器的缺省umask設(shè)置為newmask，如：umask
3。
71.useruser-name[password][account]：向遠程主機表明自己的身份，需
要口令時，必須輸入口令，如：useranonymousmy@email。
72.verbose：同命令行的-v參數(shù)，即設(shè)置詳盡報告方式，ftp服務(wù)器的所有響
應(yīng)都將顯示給用戶，缺省為on.
初始連接
初始連接時候需要發(fā)出WRQ（請求寫入遠程系統(tǒng)）或RRQ（請求讀取遠程系統(tǒng)），收到一個確定應(yīng)答，一個確定可以寫出的包或應(yīng)該讀取的第一塊數(shù)據(jù)。通常確認包包括要確認的包的包號，每個數(shù)據(jù)包都與一個塊號相對應(yīng)，塊號從1開始而且是連續(xù)的。因此對于寫入請求的確定是一個比較特殊的情況，因此它的包的包號是0。如果收到的包是一個錯誤的包，則這個請求被拒絕。創(chuàng)建連接時，通信雙方隨機選擇一個TID，因為是隨機選擇的，因此兩次選擇同一個ID的可能性就很小了。每個包包括兩個TID，發(fā)送者ID和接收者ID。這些ID用于在UDP通信時選擇端口，請求主機選擇ID的方法上面已經(jīng)說過了，在第一次請求的時候它會將請求發(fā)到TID?
69，也就是服務(wù)器的69端口上。應(yīng)答時，服務(wù)器使用一個選擇好的TID作為源TID，并用上一個包中的TID作為目的ID進行發(fā)送。這兩個被選擇的ID在隨后的通信中會被一直使用。下例是一個寫入的例子，其中WRQ，ACK和DATA代表寫入請求，確認和數(shù)據(jù)。