Raysync檔案傳輸協議(FTP)

Raysync鐳速發表於2019-05-29


在RFC 959中定義,於1985年10月釋出。 檔案傳輸協議(FTP) 被設計成為一個跨平臺的、簡單且易於實現的協議。 檔案傳輸協議(FTP) 有一個漫長的演化史,是網際網路上最重要的應用之一,但時至今日,卻已江河日下。本文作者從各方面列舉了一些 檔案傳輸協議(FTP) 為人詬病的缺點。


1、資料傳輸模式不合理


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


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


2、工作方式設計不合理


可以在主動模式(PORT)或被動模式(PASV)下工作,這決定了資料連結建立的方式。


在主動模式下,客戶端首先向伺服器端傳送IP地址和埠號,然後等待伺服器端建立TCP連結。在被動模式下,客戶端同樣首先建立到伺服器的連結,但伺服器端會開啟一個埠(1024到5000之間),等待客戶端傳輸資料。


檔案傳輸協議(FTP)中最讓人不可思議的是,客戶端會偵聽伺服器端!


3、與防火牆工作不協調


誕生在網路地址轉換(NAT)和防火牆之前,那時的網路還不存在惡意攻擊。今天大多數終端使用者的IPv4地址已不可路由,這是因為防火牆的使用和IPv4地址的短缺。


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


如果伺服器端的IP地址也不可路由,或者位於防火牆之後呢?FTP將無法進行資料傳輸!


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


4、密碼安全策略不完善


在網際網路早期, 並沒有對密碼安全作出規定。在FTP客戶端和伺服器端,資料以明文的形式傳輸,任何對通訊路徑上的路由具有控制能力的人,都可以透過嗅探獲取你的密碼和資料。


我們當然可以使用SSL封裝FTP,但FTP是透過建立多次連結進行資料傳輸的,我們即便是保護了密碼安全,也很難保護資料傳輸的安全性。


自文 釋出以來,安全的資料傳輸也經歷了長足發展,推薦使用SCP取代FTP進行檔案傳輸。


5、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連線中 。


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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69925049/viewspace-2646041/,如需轉載,請註明出處,否則將追究法律責任。

相關文章