共計 1787 個字符,預計需要花費 5 分鐘才能閱讀完成。
如何理解 Raysync 文件傳輸協議,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
文件傳輸協議(FTP)在 RFC 959 中定義,于 1985 年 10 月發布。文件傳輸協議(FTP)被設計成為一個跨平臺的、簡單且易于實現的協議。文件傳輸協議(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)曾經顯赫一時,但現在已經過時了,它是一個既不不安全,也不不友好,而且效率低下的協議,勢必被取而代之。
關于如何理解 Raysync 文件傳輸協議問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注丸趣 TV 行業資訊頻道了解更多相關知識。