FTP 檔案傳輸協議必將消亡

檔案傳輸協議（ftp）在rfc 959中定義，於2023年10月發布。檔案傳輸協議（ftp）被設計成為乙個跨平台的、簡單且易於實現的協議。檔案傳輸協議（ftp）有乙個漫長的演化史，是網際網路上最重要的應用之一，但時至今日，卻已江河日下……

本文作者從各方面列舉了一些檔案傳輸協議（ftp）為人詬病的缺點。

不考慮檔案自身的內容，一味使用ascii模式傳輸資料是不合理的。檔案傳輸協議（ftp）應該具有自動檢測功能，當然使用者也可以進行自定義。

雖然現在許多linux和windows客戶端已經支援自動傳輸模式，但多達數代的unix和windows客戶端都預設使用ascii傳輸模式，這種傳輸模式甚至會造成檔案損壞。

檔案傳輸協議（ftp）可以在主動模式（port）或被動模式（pasv）下工作，這決定了資料鏈結建立的方式。

在主動模式下，客戶端首先向伺服器端傳送ip位址和埠號，然後等待伺服器端建立tcp鏈結。在被動模式下，客戶端同樣首先建立到伺服器的鏈結，但伺服器端會開啟乙個埠（1024到5000之間），等待客戶端傳輸資料。

檔案傳輸協議（ftp）中最讓人不可思議的是，客戶端會偵聽伺服器端！

在檔案傳輸協議（ftp）誕生在網路位址轉換（nat）和防火牆之前，那時的網路還不存在惡意攻擊。今天大多數終端使用者的ipv4位址已不可路由，這是因為防火牆的使用和ipv4位址的短缺。

這對ftp意味著什麼呢？這意味著如果ftp客戶端ip位址不可路由，或者位於防火牆之後，那麼就只能使用被動傳輸模式進行資料傳輸。

如果伺服器端的ip位址也不可路由，或者位於防火牆之後呢？ftp將無法進行資料傳輸！

現在，許多防火牆適用於nat環境，可以使用一些特殊的技巧（hacks）允許ftp在防火牆之後正常工作。當然，這需要對防火牆進行配置。

我們當然可以使用ssl封裝ftp，但ftp是通過建立多次鏈結進行資料傳輸的，我們即便是保護了密碼安全，也很難保護資料傳輸的安全性。

自檔案傳輸協議（ftp）發布以來，安全的資料傳輸也經歷了長足發展，推薦使用scp取代ftp進行檔案傳輸。

從ftp伺服器上檢索乙個檔案，包含繁複的交換握手步驟：

客戶端建立到ftp伺服器端控制埠的tcp socket鏈結，並等待tcp握手完成

客戶端等待伺服器端傳送回執

客戶端向伺服器端傳送使用者名稱並等待響應

客戶端向伺服器端傳送密碼並等待響應

客戶端向伺服器端傳送syst命令並等待響應

客戶端向伺服器端傳送type i命令並等待響應

如果使用者需要在伺服器端切換目錄，客戶端仍然傳送命令並等待響應

主動模式下，客戶端需要傳送port命令到伺服器端，然後等待響應（被動模式與主動模式相反）

建立資料傳輸鏈結（需要經過三次握手，建立一條tcp socket連線）

通過鏈結傳輸資料

客戶端等待伺服器端從控制連線傳送2xx指令，以確保資料傳輸成功

客戶端傳送quit命令，並等待伺服器響應

同樣的情形，我們來看看http協議：

http客戶端向http伺服器端建立一條tcp socket連線

http客戶端向http伺服器端傳送get命令，包含url、http協議版本、虛擬主機名等等，並等待響應

http伺服器端的響應包含了所有想要的資料，完成！

傳輸乙個檔案，ftp需要往復10次，而http只需要2次！如果傳輸多個檔案，ftp可以省略傳送使用者名稱和密碼的步驟，而http則可以使用固定的套接字（socket），在相同的tcp連線中傳輸檔案。

綜上所述，雖然檔案傳輸協議（ftp）曾經顯赫一時，但現在已經過時了，它是乙個既不不安全，也不不友好，而且效率低下的協議，勢必被取而代之。