FTP通訊模式PORT PASV EPRT EPSV 在IPV6與IPv4下區別

PORT模式：

1 2 3 4

當FTP的Client以PORT模式鏈接FTP Server時，它動態的選擇一個Port X(注意這個Port必定是 1024 以上的，由於 1024 之前的Port都已經預先被定義好，被一些典型的服務使用，固然有的還沒使用，也是保留給之後會用到這些端口的資源服務)來鏈接FTP Server的 21 端口，當通過TCP的三次握手後，鏈接（控制信道）被創建。          如今用戶要列出FTP Server上的目錄結構(使用ls或dir命令)，那麼首先就要創建一個數據通道，由於只有數據通道才能傳輸目錄和文件列表，此時用戶會發出PORT指令告訴FTP Server鏈接本身的Port Y來創建一條數據通道（這個命令由控制信道發送給服務器）。當FTP Server接到這一指令時，FTP Server會使用 20 端口鏈接用戶在PORT指令中指定的Port Y，用以發送目錄的列表.      當完成這一操做時，FTP Client也許要下載一個文件，那麼就會發出 get 命令，請注意，這時Client再次發送PORT指令，告訴服務器鏈接他的哪一個「新」端口。（你能夠先用netstat -na這個命令驗證，上一次使用的Y已經處於TIME_WAIT狀態。）      當這個新的數據傳輸通道創建後(在微軟的系統中，客戶端一般會使用連續的端口，也就是說這一次客戶端會用Y+ 1 這個端口)，就開始了文件傳輸的工做。

PASV模式：

1 2 3 4 5 6

在初始化鏈接這個過程，即鏈接FTP Server這個過程和PORT模式是同樣的。 然而，當FTP Client以PASV模式鏈接FTP Server，FTP Client發送ls、dir、 get 等這些要求數據返回的命令時，當狀況就有些不一樣了。      FTP Client不向服務器發送PORT指令而是發送PASV指令，在這個指令中，Client告訴FTP Server本身要鏈接服務器的某一個端口:          1 > 若是這個服務器上的這個端口是空閒的可用的，那麼服務器會返回ACK的確認信息，以後數據傳輸通道被創建並返回用戶所要的信息（根據用戶發送的指令，如ls、dir、 get 等）；          2 > 若是服務器的這個端口被另外一個資源所使用，那麼服務器返回UNACK的信息，那麼這時，FTP客戶會再次發送PASV命令，這也就是所謂的鏈接創建的協商過程。      爲了驗證這個過程咱們不得不借助CUTEFTP Pro這個FTP客戶端軟件，由於微軟自帶的FTP命令客戶端，不支持PASV模式。雖然你可使用QUOTE PASV這個命令強制使用PASV模式，可是當你用ls命令列出服務器目錄列表，你會發現它仍是使用PORT方式來鏈接服務器的。

PS：更詳細的說明，請查閱http://www.microsoft.com/china/community/Column/70.mspx

 

EPRT/EPSV模式出現的緣由：

     FTP僅僅提供了創建在IPv4上進行數據通訊的能力，它基於網絡地址是32位這一假設。可是，當IPv6出現之後，地址就比32位長許多了。原來對FTP進行的擴展在多協議環境中有時會失敗。咱們必須針對IPv6對FTP再次進行擴展。

    EPRT、EPSV是Extended Port/Pasv的簡寫。

EPRT模式：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

EPRT考慮到數據鏈接的擴展地址問題，擴展地址必須包括網絡協議以及網絡和傳輸地址。格式以下： EPRT<空格><d><網絡協議><d><網絡地址><d><TCP端口><d> EPRT後要跟空格，空格後面必須是分隔符<d>，分隔符必須在ASCII的 33 到 126 範圍以內。推薦使用|，除非它已有它用。網絡協議是一個數字，它指出使用的是什麼協議。具體數據以下： 1 =IPv4； 2 =IPv6； 網絡地址是在指定網絡協議下的相應地址，在IPv4和IPv6下地址分別以下格式： IPv4= 132.235 . 1.2 ；IPv6= 1080 :: 8 : 800 :200C:417A TCP端口指的是協議在哪個TCP端口上偵聽數據鏈接。下面是兩個EPRT命令的例子： EPRT | 1 | 132.235 . 1.2 | 6275 | EPRT | 2 | 1080 :: 8 : 800 :200C:417A| 5282 | 第一個命令在TCP端口 6275 上用IPv4打開主機 "132.235.1.2" ； 第二個命令在TCP端口 5282 上用IPv6打開主機 "1080::8:800:200C:417A" 。 在接收到合法的EPRT命令後，服務器必須返回 200 （命令合法）。標準的錯誤代碼 500 和 501 已經足夠處理大部分錯誤了，可是還須要一個錯誤代碼，代碼 522 指定服務器不支持請求的網絡協議，新錯誤代碼的解釋以下： 5yz 交換信息結束 x2z 鏈接 xy2 擴展端口錯誤：未知的網絡協議       響應的文本部分必須說明服務器運行的協議是什麼，響應串的格式以下： <說明不支持的網絡的字符串> /（協議 1 ，協議 2 ，...，協議n） 上述的數字代碼和在括號內的協議信息由軟件自動控制接收響應；而在數字代碼和 '(' 之間的內容供人類用戶處理。其後的協議表中的協議應該以逗號分隔。下面是兩個響應串的例子： Network protocol not supported,  use  ( 1 ) Network protocol not supported,  use  ( 1 , 2 )

 

EPSV模式：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

EPSV格式以下： EPSV<空格><網絡協議> 若是請求的網絡協議是服務器支持的，那就必須使用此協議；若是不支持，則返回 522 。最後，EPSV命令可使用參數 "ALL" 經過網絡地址翻譯器，EPRT命令再也不使用。下面是例子： EPSV<空格>ALL 接收到此命令後，服務器要拒絕除了EPSV之外全部創建鏈接的命令。 對於全部在兩臺相同機器間創建控制和數據鏈接的FTP傳輸來講，必須使用EPSV。使用它能夠減小經過防火牆和網絡地址翻譯器（NAT）對效率的影響。有些文章推薦在防火牆後使用被動命令，所以防火牆一般不容許主動鏈接。在本文中定義的EPSV命令不須要NAT在傳輸時對網絡地址進行改變。若是使用EPRT，NAT必須改變網絡地址。若是客戶發送了 "EPSV ALL" 命令，NAT可以將鏈接變爲快速方式，只要再不使用EPRT，就不須要對數據段的數據部分進行改變。若是客戶但願進行兩路FTP傳輸，應該使用這條命令，若是後來客戶須要創建三種FTP傳輸，必須新打開了個FTP會話。      EPSV請求服務器在一個數據端口上偵聽等待鏈接，它能夠帶參數。對它的響應是TCP端口號。響應的格式與EPRT參數的很象。這對實現上有很大的方便。並且響應還留下了網絡協議和/或網絡地址的空位，能夠供之後使用。使用擴展地址進行被動模式的響應碼必須是 229 ，對它的解釋以下： 2yz 主動完成 x2z 鏈接 xy9 進行擴展的被動模式 響應的格式以下： <指示服務器已經進入初擴展的被動模式> /(<d><d><d><TCP端口><d>) 包括在括號內的字符串必須是EPRT打開數據鏈接的端口。具體如上所未，這裏就很少說了。數據鏈接使用的協議必須和控制鏈接使用的協議和地址一致，下面是響應的一個例子： Entering Extended Passive Mode (||| 6446 |) 標準錯誤代碼 500 和 501 對EPSV已經足夠了（不支持EPSV）。在EPSV命令沒有使用參數時，服務器會基於控制鏈接所使用的協議選擇數據鏈接使用的網絡協議。可是在有代理的狀況下，這種機制可能不合適。所以客戶也須要可以要求一個指定協議。若是服務器返回說明它在指定端口不支持此協議，客戶必須發送ABOR（放棄）命令使服務器關閉鏈接，而後客戶再使用EPSV命令要求使用特定的網絡協議