- 掛牌上市企業
- 60秒人工響應
- 99.99%連通率
- 7*24h人工
- 故障100倍補償
一些文件傳輸協議為人詬病的缺點 |
| 發布時間: 2012/8/4 21:07:36 |
|
文件傳輸協議（FTP）有一個漫長的演化史，是互聯網上最重要的應用之一，但時至今日，卻已江河日下。本文作者從各方面列舉了一些文件傳輸協議（FTP）為人詬病的缺點。 1.數據傳輸模式不合理 不考慮文件自身的內容，一味使用ASCII模式傳輸數據是不合理的。文件傳輸協議（FTP）應該具有自動檢測功能，當然用戶也可以進行自定義。 雖然現在許多Linux和Windows客戶端已經支持自動傳輸模式，但多達數代的UNIX和Windows客戶端都默認使用ASCII傳輸模式，這種傳輸模式甚至會造成文件損壞。 2.工作方式設計不合理 文件傳輸協議（FTP）可以在主動模式（PORT）或被動模式（PASV）下工作，這決定了數據鏈接建立的方式。 在主動模式下，客戶端首先向服務器端發送IP地址和端口號，然后等待服務器端建立TCP鏈接。在被動模式下，客戶端同樣首先建立到服務器的鏈接，但服務器端會開啟一個端口（1024到5000之間），等待客戶端傳輸數據。 文件傳輸協議（FTP）中最讓人不可思議的是，客戶端會偵聽服務器端！ 3.與防火墻工作不協調 在文件傳輸協議（FTP）誕生在網絡地址轉換（NAT）和防火墻之前，那時的網絡還不存在惡意攻擊。今天大多數最終用戶的IPv4地址已不可路由，這是因為防火墻的使用和IPv4地址的短缺。 這對FTP意味著什么呢？這意味著如果FTP客戶端IP地址不可路由，或者位于防火墻之后，那么就只能使用被動傳輸模式進行數據傳輸。 如果服務器端的IP地址也不可路由，或者位于防火墻之后呢？FTP將無法進行數據傳輸！ 現在，許多防火墻適用于NAT環境，可以使用一些特殊的技巧（hacks）允許FTP在防火墻之后正常工作。當然，這需要對防火墻進行配置。 4.密碼安全策略不完善 在互聯網早期，文件傳輸協議（FTP）并沒有對密碼安全作出規定。在FTP客戶端和服務器端，數據以明文的形式傳輸，任何對通訊路徑上的路由具有控制能力的人，都可以通過嗅探獲取你的密碼和數據。 我們當然可以使用SSL封裝FTP,但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連接中傳輸文件。 綜上所述，雖然文件傳輸協議（FTP）曾經顯赫一時，但現在已經過時了，它是一個既不不安全，也不不友好，而且效率低下的協議，勢必被取而代之。 本文出自：億恩科技【www.endtimedelusion.com】 |
0371-60135900
京公網安備41019702002023號
香港服務器租用
美國服務器租用
電信骨干機房
聯通骨干機房
