coca
2004-11-19, 07:48
這一篇推薦給想要了解FTP（檔案傳輸通訊協定）的人閱讀，是為一篇paper。
實驗名稱：
FTP連線觀測與分析
實驗目的:
本實驗藉由實際操作 NetXRay 或 Surveyor 等網路監控軟體，觀察 FTP 連線時，在網路 TCP 層的封包出現情形，並加以分析各封包之出現原因。
實驗原理:
FTP跟一般的應用程式不同，它使用兩條連線 (connection) 來完成一個檔案傳輸。
1.Control connection：跟平常的client-server架構一樣，server會在一well-known的port (21) 等待連線 (passive open)，而client則是主動的向server建立連線，而這條連線就是control connection，它會一直存在著直到client完全跟server斷線。此連線主要是用於client對server下命令 (command)，以及server對client的回應 (reply)。
此連線的IP’s type-of-service 應該要設定為 “minimize delay”，因為control connection的資料一般是由使用者所下的，必須有短的回應時間。
2. Data connection：每當client和server之間有檔案要傳輸，就會建立一條這樣的連線。
此連線的IP’s type-of-service 應該要設定為 “maximize throughput”，因為 data connection 是提供給檔案傳輸的。
上圖表示使用者無須處理經過 control connection 的命令及回應，這
些細節都交由 protocol interpreter 處理，而 user interface 則是將使用者
的命令轉為 FTP control connection 的命令，同樣的，它也會將control
connection 的回應轉為使用者可瞭解的形式。
建立連線:
在一開始，建立連線所使用的 Channel 是 Control Channel，值得一提的是，Control Channel 乃是使用跟 telnet protocol 相同的機制。換句話說，我們也可以利用 telnet 的 client 程式，經由一定的程序，進行 ftp 的連結。
命令溝通:
正如前面所述，FTP 的 Control Connection 所使用的協定跟 telnet 是相同的。所有的命令也是透過相同的機制來傳送。
一般而言，當 server 接收到一個 client 端所發出的命令，在處理完畢之後，會再送出一個對應的回覆，通知 client 端。
FTP 所定義的命令如下:
Access Control Commands
User Name (User)、Password (Pass)、Account (Acct)、Change Working Directory (Cwd)、Change To Parent Directory (Cdup)、Structure Mount (Smnt)、Reinitialize (Rein)、Logout (Quit)
Transfer Parameter Commands
Data Port (Port)、Passive (Pasv)、Representation Type (Type)、File Structure (Stru) 、Transfer Mode (Mode)
Ftp Service Commands
Retrieve (Retr)、Store (Stor)、Store Unique (Stou)、Append (With Create) (Appe)、Allocate (Allo) 、Restart (Rest)、Rename From (Rnfr)、Rename To (Rnto)、Abort (Abor) 、Delete (Dele)、Remove Directory (Rmd)、Make Directory (Mkd) 、Print Working Directory (Pwd)、List (List)、Name List (Nlst)、Site Parameters (Site)、System (Syst)、Status (Stat)、Help (Help)、Noop (Noop)。
而針對以上各命令，也都有相對的回覆。如211 表System status 之回覆，而530 表示Not logged in. 等等。
資料傳輸:
當 ftp 過程中，有大筆資料需要傳輸的話 （例如傳送目錄資訊，傳送大量訊息, 或傳送資料本身），都需要重新建立連線。此處所謂之建立連線, 乃是建立 data connection。
data connection 建立之後，即利用 sequence number，與對應之 acknowledge number 做查核封包，以確認接收方完整接收所需之資料，並將下一筆未傳輸完成的資料繼續傳送。
在我們於 ftp client 端，做 get 或 put 的指令，或是利用Cute-FTP 做拖曳檔案的動作，都會先建立 data connection。而一般 data connection 的 port 都會設定在 port 20。
結束連線:
當我們資料傳輸完成，要結束 FTP 連線的時候, client 端會送出 FIN
之封包，要求中斷連結。當 server 端收到這個要求的時候，會回覆一個 ack 及另外一個 FIN 封包。當 client 端收到此兩個封包之後，再度回覆一個 ACK 封包，連線即宣告結束。
162
Client à Server
DP=21，SP=1032
SEQ=994093831 ACK=61879
FIN
163
Serverà Client
DP=1032，SP=21
SEQ=61879 ACK=994093832
164
Serverà Client
DP=1032，SP=21
SEQ=61879 ACK=994093832
FIN
165
Client à Server
DP=21，SP=1032
SEQ=994093832 ACK=61880
四、實驗設備：
PC三部，Client 端，Server 端，與觀測端，NetXRay軟體，無線網路卡。
五、實驗步驟：
實驗環境是由R227的dcl-13 (140.123.111.43) 做為 client 端，而網路組的eeipc3 (140.123.107.56) 則做為FTP server，並記錄從登入到傳檔，傳檔案到登出的所有封包。
1.執行 Sniffer程式
2.開啟Capture Filter，因為我們要觀察的是兩台電腦（client，ftp server）之間的FTP溝通行為，所以過濾掉其他我們不感興趣的封包。
3.我們由 dcl-13 （無線網路卡，FreeBSD，FTP Client） FTP 到 eeipc3 (FTP Server)，登入後，抓取一檔案 (104resume.doc)，完成後離開。
4.回到 Sniffer，停止抓封包，分析 FTP 整個過程所收送的封包。
六、實驗結果分析：
連線&登錄:
(Control Connection的建立)
一開始，Client 端會向 Server 發出要求建立連線的 request。
FTP 固定使用 port 21。故 Client 端自行取一個 port (如 1032)，再跟 Server 端的 port 21 要求建立連線。(剛開始之 Sequence Number 亦自取， Acknowledge Number 則設為0 )
要求建立連線之封包，內容的 SYN 旗標被設為TRUE。表示這是要求建立連線之封包。
當 Server 端收到建立連線之要求，會回覆一個 SYN+ACK 的封包，表示同意建立連線。
當 Client 端收到 Server 的回覆之後，也再度回覆一個 ACK 封包，以確認連線。至此完成 Three way hand-shaking 的連線程序。
當 Server 端收到Client 端的ACK 封包後，會主動發出 Server Ready (FTP command 220) 的封包，表示準備接受 FTP 動作。
Client 端此時發出含有 User name 的封包進行登入。
Server 端收到含 User name 的封包後，發出 Password Request (FTP command 331) 封包。
Client 端接著發出含有 Password 的封包，我們用 NetXRay 可以完整的看到密碼，完全沒有加密。
此時建立連線與登入 FTP Server程序已完成。
傳檔 (get 104resume.doc) :
(Data Connection的建立與結束)
首先，dc1-13 會先送出 FTP command type I，表示要求 eeipc3 以binary的方式傳檔，然後 eeipc3 會發出 type set to I 的回應給 dcl-13。
接下來dcl-13會詢問 104resume.doc 的檔案大小，同樣的 eeipc3 會回應 (115712)。
dcl-13傳送自己的 ip 及 等一下準備用來建立data connection 的 port (256*156+89=40025) 給 eepic3 知道，而 eeipc3 收到後會回應 PORT command successful。
dcl-13送出 RETR 104resume.doc，表示做好接收資料的準備了。
至此都還是利用 control connection 做連繫，當 dcl-13 做好準備後，必
須再建立一條 data connection 做為檔案傳輸之用，底下就是 data connection
建立及結束的流程圖。
eeipc3 收到 dcl-13 的 RETR command 之後，會開始做建立連線的動作，而所用的 destination port number 就是以剛才 dcl-13 所告知的 40025 做為依據。
eeipc3 送出 SYN，DP (Destination Port) = 40025，SP (Source Port) = 20。
dcl-13 送出 SYN+ACK，DP = 20，SP = 40025。
eeipc3 送出 ACK，DP = 40025，SP = 20。
…
eeipc3 送出最後一筆資料，並送出 FIN，DP = 40025，SP = 20。
dcl-13 回 ACK，DP = 20，SP = 40025。
dcl-13 送出 FIN，DP = 20，SP = 40025。
eeipc3 回 ACK，DP = 40025，SP = 20。
至此，data connection 已結束，dcl-13 接下來會詢問檔案的日期及時間，以完成整個檔案的傳輸工作。
dcl-13 送出 FTP Command MDTM 104resume.doc，DP = 21，SP = 1032。
eeipc3 送出 FTP Command 213 20000411191703，DP = 1032，SP = 21，應該是該檔案的最新存取日期及時間。
登出 (bye):
接下來就是登出的過程，我們以下面的圖來做說明。
dcl-13 送出 FTP Command Quit，DP = 21，SP = 1032 (control connection)。
eeipc3 回應 FTP Command 221 Goodbye，DP = 1032，SP = 21。
eeipc3 送出 FIN，DP = 1032，SP = 21，並等待 dcl-13 回應。
dcl-13 也送出 FIN，DP = 21，SP = 1032，並等待 eeipc3 回應。
此時 eeipc3 收到dcl-13 所送出的 FIN (step 4.)，而不是想要的 ACK (step 3.) ，所以對 dcl13 回應 FIN+ACK。
此時 dcl-13 收到eeipc3 所送出的 FIN (step 3.)，而不是想要的 ACK (step 4.) ，所以對 eeipc3 回應 FIN+ACK。
eeipc3 收到 dcl-13 所送出的 FIN+ACK (step 5.)，並送出 ACK 以回應dcl-13 所送出的 FIN+ACK。
dcl-13 收到 eeipc3 所送出的 FIN+ACK (step 6.)，並送出 ACK 以回應eeipc3 所送出的 FIN+ACK。
此次實驗的結果並沒有如我們所預料的跟著課本 Finite state machine 走，而參考另一本 Stevens 的書 [3] 也是如此，以 Stevens 的為例，當雙方都正好發出 FIN 的訊息時，表示 Simultaneous Close ，兩者都應該回送 ACK 而後進入 “CLOSING” state。但在我們實驗中卻發現回應的是 FIN+ACK (step 5. and 6.)，所以我們推測 FreeBSD 2.2.8 所使用Finite State Machine 跟課本所提及的略有不同，至少在 Simultaneous Close 的情形是如此。而 Simultaneous Close 的發生則可能是當 eeipc3 送出 FIN 時，Access Point 的延遲所造成的結果，因為我們發現在eeipc3 送出 FIN 後，dcl-13 過了 27 msec 才送出 FIN，而不是 ACK (passive close)。
另外，我們觀察 eeipc3 的 FIN 及 FIN+ACK，它們兩者的 Sequence Number 都是 1291705591，所以FIN+ACK也有可能是因為 Time-Out 造成的 Retransmission，而導致 ”看起來” 跟課本的 Finite State Machine 不同。(我們會這樣解釋觀察到的情形是因為 Wireless LAN Card 在收送封包時必須經過 Access Point，而 Access Point 是使用 Store and Forward 的方式將封包轉送到 Ethernet，這其中浪費了很多的時間，而且我們在 Client-Server 皆為 Ethernet 時沒有看到此種情況)，所以若以加入Retransmission 的觀念來看，雙方原本在 “FIN_WAIT_1” state，由於重送 (FIN+ACK) 的關係，而使得雙方進入 “TIME_WAIT” state，並回送 ACK，這使得我們觀測到的數據又可跟課本的 Finite State Machine互相印證了。
其他:
除了以上三個主要的 FTP 程序以外，我們在此次實驗中還發現一些 FTP相關的 Command，將在下面說明之。
當登入 eeipc3 之後：
1. dcl-13 發出 FTP Command SYST (控制命令: System. 用來找出 Server 端的作業系統型態.)
2. eeipc3 回應FTP Command 215 UNIX Type: L8 Version: BSD-199506 (控制回覆: 針對上一個控制命令 (SYSY) 的回覆.)
當 dcl-13 發出 RETR 104resume.doc 命令，eeipc3 會與 dcl-13建立 data connection，當 eeipc3 確定建好連線後，會發出 150 Opening BINARY mode connection for ‘104resume.doc’ 以回應 dcl-13 所發出的RETR 104resume.doc 命令。
另外值得注意的一點，除了下 get 或 put 的 shell 命令才會建 data connection 外，ls 等的命令也會建立一條暫時的 data connection。
五、實驗討論:
續傳功能之探討：
我們現在使用 FTP 來存取檔案時，會發現有些 server 有續傳的功能，這是如何做到的呢？
我們對此進行了實驗，server (140.123.107.30) 為 server-U 應用軟體，client (140.123.107.80) 為 cute-FTP 應用軟體。在傳遞一檔案時故意使其中斷 (client 發出)，在重新傳輸時，發現確實有續傳的功能，無論我們是使用在應用程式中發出停止，或是拔掉網路線，之後都仍然保有續傳之能力。
它的原理是利用 Server 的 Restart command 350 來達成，而整個動作要如何進行呢？我們看下面的圖來解釋：
(1).
Server 送出的第一筆資料封包的 Sequence Number 為 15999320。
(2).
當 Server 送出 Sequence Number 為 16003700 的封包時，我們將程式中斷。此時 Server 已送出 16003700 – 15999320 = 4380 (bytes) 的資料。
(3).
從圖中可以看到 Client 會記錄欲傳遞之檔案已接收的 bytes 數目，發出 FTP REST 4380，Server 則會回應 FTP 350 Restarting at 4380 訊息，並開始傳送。
在我們的實驗中，我們比較了Server 端軟體 - Windows NT FTP Server、FreeBSD FTP Server、與 Server-U 應用程式，以及 Client端軟體 - CuteFTP、FreeBSD FTP 指令，發現 Server 端只有Server-U支援續傳功能，而 Client 端則是 Windows FTP Application 支援，FreeBSD FTP 程式不支援。由此我們可以得知續傳功能須要Server 端與Client 端兩方同時支援，而由 Client 端記錄資訊。
2. 總結：
藉由實際觀察封包，我們了解到 TCP/IP 協定的真實運作情形。有許多東西是課本不一定會提到的，也因為親手去操作、觀察，讓我們對理論與實際的結合有更深的體會。
本次的實驗，除了讓我們更了解 FTP 檔案傳輸協定的詳細運作情形之外，也讓我們了解到 Ethernet 的不可靠性。任何人皆可藉由抓取同網域之封包，來窺視他人的連線，包括密碼、資料等等。換句話說，在 Ethernet 上，幾乎沒有隱私性可言。
或許數位簽章、數位加密的技術逐漸成熟，可以解決一部份這樣的問題，但對使用者的教育，以及我們的自我充實，才能夠徹底防止網路竊密的事情發生。
六、參考文獻:
RFC 959 FILE TRANSFER PROTOCOL (FTP) , 1985.
Douglas E. Comer & David L. Stevens , Internetworking With TCP/IP Volume 1: Principles Protocols, and Architecture, third edition, 1995. PRENTICE HALL.
W. Richard Stevens, TCP/IP Illustrated Volume 1, 1994. Addison Wesley.
http://64.233.167.104/search?q=cache:I9I0yFLAGpoJ:eeipc3.cn.ee.ccu.edu.tw/e88/m8833/course/com_proto/ftp-1.doc+port+20&hl=zh-TW&lr=lang_zh-TW&inlang=zh-TW
實驗名稱：
FTP連線觀測與分析
實驗目的:
本實驗藉由實際操作 NetXRay 或 Surveyor 等網路監控軟體，觀察 FTP 連線時，在網路 TCP 層的封包出現情形，並加以分析各封包之出現原因。
實驗原理:
FTP跟一般的應用程式不同，它使用兩條連線 (connection) 來完成一個檔案傳輸。
1.Control connection：跟平常的client-server架構一樣，server會在一well-known的port (21) 等待連線 (passive open)，而client則是主動的向server建立連線，而這條連線就是control connection，它會一直存在著直到client完全跟server斷線。此連線主要是用於client對server下命令 (command)，以及server對client的回應 (reply)。
此連線的IP’s type-of-service 應該要設定為 “minimize delay”，因為control connection的資料一般是由使用者所下的，必須有短的回應時間。
2. Data connection：每當client和server之間有檔案要傳輸，就會建立一條這樣的連線。
此連線的IP’s type-of-service 應該要設定為 “maximize throughput”，因為 data connection 是提供給檔案傳輸的。
上圖表示使用者無須處理經過 control connection 的命令及回應，這
些細節都交由 protocol interpreter 處理，而 user interface 則是將使用者
的命令轉為 FTP control connection 的命令，同樣的，它也會將control
connection 的回應轉為使用者可瞭解的形式。
建立連線:
在一開始，建立連線所使用的 Channel 是 Control Channel，值得一提的是，Control Channel 乃是使用跟 telnet protocol 相同的機制。換句話說，我們也可以利用 telnet 的 client 程式，經由一定的程序，進行 ftp 的連結。
命令溝通:
正如前面所述，FTP 的 Control Connection 所使用的協定跟 telnet 是相同的。所有的命令也是透過相同的機制來傳送。
一般而言，當 server 接收到一個 client 端所發出的命令，在處理完畢之後，會再送出一個對應的回覆，通知 client 端。
FTP 所定義的命令如下:
Access Control Commands
User Name (User)、Password (Pass)、Account (Acct)、Change Working Directory (Cwd)、Change To Parent Directory (Cdup)、Structure Mount (Smnt)、Reinitialize (Rein)、Logout (Quit)
Transfer Parameter Commands
Data Port (Port)、Passive (Pasv)、Representation Type (Type)、File Structure (Stru) 、Transfer Mode (Mode)
Ftp Service Commands
Retrieve (Retr)、Store (Stor)、Store Unique (Stou)、Append (With Create) (Appe)、Allocate (Allo) 、Restart (Rest)、Rename From (Rnfr)、Rename To (Rnto)、Abort (Abor) 、Delete (Dele)、Remove Directory (Rmd)、Make Directory (Mkd) 、Print Working Directory (Pwd)、List (List)、Name List (Nlst)、Site Parameters (Site)、System (Syst)、Status (Stat)、Help (Help)、Noop (Noop)。
而針對以上各命令，也都有相對的回覆。如211 表System status 之回覆，而530 表示Not logged in. 等等。
資料傳輸:
當 ftp 過程中，有大筆資料需要傳輸的話 （例如傳送目錄資訊，傳送大量訊息, 或傳送資料本身），都需要重新建立連線。此處所謂之建立連線, 乃是建立 data connection。
data connection 建立之後，即利用 sequence number，與對應之 acknowledge number 做查核封包，以確認接收方完整接收所需之資料，並將下一筆未傳輸完成的資料繼續傳送。
在我們於 ftp client 端，做 get 或 put 的指令，或是利用Cute-FTP 做拖曳檔案的動作，都會先建立 data connection。而一般 data connection 的 port 都會設定在 port 20。
結束連線:
當我們資料傳輸完成，要結束 FTP 連線的時候, client 端會送出 FIN
之封包，要求中斷連結。當 server 端收到這個要求的時候，會回覆一個 ack 及另外一個 FIN 封包。當 client 端收到此兩個封包之後，再度回覆一個 ACK 封包，連線即宣告結束。
162
Client à Server
DP=21，SP=1032
SEQ=994093831 ACK=61879
FIN
163
Serverà Client
DP=1032，SP=21
SEQ=61879 ACK=994093832
164
Serverà Client
DP=1032，SP=21
SEQ=61879 ACK=994093832
FIN
165
Client à Server
DP=21，SP=1032
SEQ=994093832 ACK=61880
四、實驗設備：
PC三部，Client 端，Server 端，與觀測端，NetXRay軟體，無線網路卡。
五、實驗步驟：
實驗環境是由R227的dcl-13 (140.123.111.43) 做為 client 端，而網路組的eeipc3 (140.123.107.56) 則做為FTP server，並記錄從登入到傳檔，傳檔案到登出的所有封包。
1.執行 Sniffer程式
2.開啟Capture Filter，因為我們要觀察的是兩台電腦（client，ftp server）之間的FTP溝通行為，所以過濾掉其他我們不感興趣的封包。
3.我們由 dcl-13 （無線網路卡，FreeBSD，FTP Client） FTP 到 eeipc3 (FTP Server)，登入後，抓取一檔案 (104resume.doc)，完成後離開。
4.回到 Sniffer，停止抓封包，分析 FTP 整個過程所收送的封包。
六、實驗結果分析：
連線&登錄:
(Control Connection的建立)
一開始，Client 端會向 Server 發出要求建立連線的 request。
FTP 固定使用 port 21。故 Client 端自行取一個 port (如 1032)，再跟 Server 端的 port 21 要求建立連線。(剛開始之 Sequence Number 亦自取， Acknowledge Number 則設為0 )
要求建立連線之封包，內容的 SYN 旗標被設為TRUE。表示這是要求建立連線之封包。
當 Server 端收到建立連線之要求，會回覆一個 SYN+ACK 的封包，表示同意建立連線。
當 Client 端收到 Server 的回覆之後，也再度回覆一個 ACK 封包，以確認連線。至此完成 Three way hand-shaking 的連線程序。
當 Server 端收到Client 端的ACK 封包後，會主動發出 Server Ready (FTP command 220) 的封包，表示準備接受 FTP 動作。
Client 端此時發出含有 User name 的封包進行登入。
Server 端收到含 User name 的封包後，發出 Password Request (FTP command 331) 封包。
Client 端接著發出含有 Password 的封包，我們用 NetXRay 可以完整的看到密碼，完全沒有加密。
此時建立連線與登入 FTP Server程序已完成。
傳檔 (get 104resume.doc) :
(Data Connection的建立與結束)
首先，dc1-13 會先送出 FTP command type I，表示要求 eeipc3 以binary的方式傳檔，然後 eeipc3 會發出 type set to I 的回應給 dcl-13。
接下來dcl-13會詢問 104resume.doc 的檔案大小，同樣的 eeipc3 會回應 (115712)。
dcl-13傳送自己的 ip 及 等一下準備用來建立data connection 的 port (256*156+89=40025) 給 eepic3 知道，而 eeipc3 收到後會回應 PORT command successful。
dcl-13送出 RETR 104resume.doc，表示做好接收資料的準備了。
至此都還是利用 control connection 做連繫，當 dcl-13 做好準備後，必
須再建立一條 data connection 做為檔案傳輸之用，底下就是 data connection
建立及結束的流程圖。
eeipc3 收到 dcl-13 的 RETR command 之後，會開始做建立連線的動作，而所用的 destination port number 就是以剛才 dcl-13 所告知的 40025 做為依據。
eeipc3 送出 SYN，DP (Destination Port) = 40025，SP (Source Port) = 20。
dcl-13 送出 SYN+ACK，DP = 20，SP = 40025。
eeipc3 送出 ACK，DP = 40025，SP = 20。
…
eeipc3 送出最後一筆資料，並送出 FIN，DP = 40025，SP = 20。
dcl-13 回 ACK，DP = 20，SP = 40025。
dcl-13 送出 FIN，DP = 20，SP = 40025。
eeipc3 回 ACK，DP = 40025，SP = 20。
至此，data connection 已結束，dcl-13 接下來會詢問檔案的日期及時間，以完成整個檔案的傳輸工作。
dcl-13 送出 FTP Command MDTM 104resume.doc，DP = 21，SP = 1032。
eeipc3 送出 FTP Command 213 20000411191703，DP = 1032，SP = 21，應該是該檔案的最新存取日期及時間。
登出 (bye):
接下來就是登出的過程，我們以下面的圖來做說明。
dcl-13 送出 FTP Command Quit，DP = 21，SP = 1032 (control connection)。
eeipc3 回應 FTP Command 221 Goodbye，DP = 1032，SP = 21。
eeipc3 送出 FIN，DP = 1032，SP = 21，並等待 dcl-13 回應。
dcl-13 也送出 FIN，DP = 21，SP = 1032，並等待 eeipc3 回應。
此時 eeipc3 收到dcl-13 所送出的 FIN (step 4.)，而不是想要的 ACK (step 3.) ，所以對 dcl13 回應 FIN+ACK。
此時 dcl-13 收到eeipc3 所送出的 FIN (step 3.)，而不是想要的 ACK (step 4.) ，所以對 eeipc3 回應 FIN+ACK。
eeipc3 收到 dcl-13 所送出的 FIN+ACK (step 5.)，並送出 ACK 以回應dcl-13 所送出的 FIN+ACK。
dcl-13 收到 eeipc3 所送出的 FIN+ACK (step 6.)，並送出 ACK 以回應eeipc3 所送出的 FIN+ACK。
此次實驗的結果並沒有如我們所預料的跟著課本 Finite state machine 走，而參考另一本 Stevens 的書 [3] 也是如此，以 Stevens 的為例，當雙方都正好發出 FIN 的訊息時，表示 Simultaneous Close ，兩者都應該回送 ACK 而後進入 “CLOSING” state。但在我們實驗中卻發現回應的是 FIN+ACK (step 5. and 6.)，所以我們推測 FreeBSD 2.2.8 所使用Finite State Machine 跟課本所提及的略有不同，至少在 Simultaneous Close 的情形是如此。而 Simultaneous Close 的發生則可能是當 eeipc3 送出 FIN 時，Access Point 的延遲所造成的結果，因為我們發現在eeipc3 送出 FIN 後，dcl-13 過了 27 msec 才送出 FIN，而不是 ACK (passive close)。
另外，我們觀察 eeipc3 的 FIN 及 FIN+ACK，它們兩者的 Sequence Number 都是 1291705591，所以FIN+ACK也有可能是因為 Time-Out 造成的 Retransmission，而導致 ”看起來” 跟課本的 Finite State Machine 不同。(我們會這樣解釋觀察到的情形是因為 Wireless LAN Card 在收送封包時必須經過 Access Point，而 Access Point 是使用 Store and Forward 的方式將封包轉送到 Ethernet，這其中浪費了很多的時間，而且我們在 Client-Server 皆為 Ethernet 時沒有看到此種情況)，所以若以加入Retransmission 的觀念來看，雙方原本在 “FIN_WAIT_1” state，由於重送 (FIN+ACK) 的關係，而使得雙方進入 “TIME_WAIT” state，並回送 ACK，這使得我們觀測到的數據又可跟課本的 Finite State Machine互相印證了。
其他:
除了以上三個主要的 FTP 程序以外，我們在此次實驗中還發現一些 FTP相關的 Command，將在下面說明之。
當登入 eeipc3 之後：
1. dcl-13 發出 FTP Command SYST (控制命令: System. 用來找出 Server 端的作業系統型態.)
2. eeipc3 回應FTP Command 215 UNIX Type: L8 Version: BSD-199506 (控制回覆: 針對上一個控制命令 (SYSY) 的回覆.)
當 dcl-13 發出 RETR 104resume.doc 命令，eeipc3 會與 dcl-13建立 data connection，當 eeipc3 確定建好連線後，會發出 150 Opening BINARY mode connection for ‘104resume.doc’ 以回應 dcl-13 所發出的RETR 104resume.doc 命令。
另外值得注意的一點，除了下 get 或 put 的 shell 命令才會建 data connection 外，ls 等的命令也會建立一條暫時的 data connection。
五、實驗討論:
續傳功能之探討：
我們現在使用 FTP 來存取檔案時，會發現有些 server 有續傳的功能，這是如何做到的呢？
我們對此進行了實驗，server (140.123.107.30) 為 server-U 應用軟體，client (140.123.107.80) 為 cute-FTP 應用軟體。在傳遞一檔案時故意使其中斷 (client 發出)，在重新傳輸時，發現確實有續傳的功能，無論我們是使用在應用程式中發出停止，或是拔掉網路線，之後都仍然保有續傳之能力。
它的原理是利用 Server 的 Restart command 350 來達成，而整個動作要如何進行呢？我們看下面的圖來解釋：
(1).
Server 送出的第一筆資料封包的 Sequence Number 為 15999320。
(2).
當 Server 送出 Sequence Number 為 16003700 的封包時，我們將程式中斷。此時 Server 已送出 16003700 – 15999320 = 4380 (bytes) 的資料。
(3).
從圖中可以看到 Client 會記錄欲傳遞之檔案已接收的 bytes 數目，發出 FTP REST 4380，Server 則會回應 FTP 350 Restarting at 4380 訊息，並開始傳送。
在我們的實驗中，我們比較了Server 端軟體 - Windows NT FTP Server、FreeBSD FTP Server、與 Server-U 應用程式，以及 Client端軟體 - CuteFTP、FreeBSD FTP 指令，發現 Server 端只有Server-U支援續傳功能，而 Client 端則是 Windows FTP Application 支援，FreeBSD FTP 程式不支援。由此我們可以得知續傳功能須要Server 端與Client 端兩方同時支援，而由 Client 端記錄資訊。
2. 總結：
藉由實際觀察封包，我們了解到 TCP/IP 協定的真實運作情形。有許多東西是課本不一定會提到的，也因為親手去操作、觀察，讓我們對理論與實際的結合有更深的體會。
本次的實驗，除了讓我們更了解 FTP 檔案傳輸協定的詳細運作情形之外，也讓我們了解到 Ethernet 的不可靠性。任何人皆可藉由抓取同網域之封包，來窺視他人的連線，包括密碼、資料等等。換句話說，在 Ethernet 上，幾乎沒有隱私性可言。
或許數位簽章、數位加密的技術逐漸成熟，可以解決一部份這樣的問題，但對使用者的教育，以及我們的自我充實，才能夠徹底防止網路竊密的事情發生。
六、參考文獻:
RFC 959 FILE TRANSFER PROTOCOL (FTP) , 1985.
Douglas E. Comer & David L. Stevens , Internetworking With TCP/IP Volume 1: Principles Protocols, and Architecture, third edition, 1995. PRENTICE HALL.
W. Richard Stevens, TCP/IP Illustrated Volume 1, 1994. Addison Wesley.
http://64.233.167.104/search?q=cache:I9I0yFLAGpoJ:eeipc3.cn.ee.ccu.edu.tw/e88/m8833/course/com_proto/ftp-1.doc+port+20&hl=zh-TW&lr=lang_zh-TW&inlang=zh-TW