通訊網路/檔案傳輸協議

檔案傳輸協議 (FTP) 是一種標準網路協議，用於透過基於 TCP/IP 的網路（例如 網際網路）交換和操作檔案。FTP 建立在客戶端-伺服器架構之上，並在客戶端和伺服器應用程式之間使用單獨的控制和資料連線。FTP 也經常用作應用程式元件，以自動傳輸檔案以供程式內部功能使用。FTP 可以與基於使用者的密碼身份驗證或匿名使用者訪問一起使用。

目的

FTP 的目標，如其 RFC 所述，是

• 促進檔案共享（計算機程式和/或資料）。
• 鼓勵間接或隱式使用遠端計算機。
• 遮蔽使用者在不同主機之間檔案儲存系統上的差異。
• 可靠且高效地傳輸資料。
• 授予終端使用者可讀性。

連線方法

FTP 執行在傳輸控制協議 (TCP) 之上。通常，FTP 伺服器在眾所周知的埠號 21（IANA 保留）上偵聽來自客戶端的傳入連線。與來自 FTP 客戶端的此埠的連線形成控制流，命令透過該控制流傳遞到 FTP 伺服器，並收集響應。FTP 使用帶外控制；它在其他埠號上開啟專用的資料連線。資料流的引數取決於具體請求的傳輸模式。資料連線通常使用埠號 20。

在主動模式中，FTP 客戶端開啟一個動態埠，在控制流上向 FTP 伺服器傳送它正在偵聽的動態埠號，並等待來自 FTP 伺服器的連線。當 FTP 伺服器啟動與 FTP 客戶端的資料連線時，它將源埠繫結到 FTP 伺服器上的埠 20。

為了使用主動模式，客戶端傳送一個 PORT 命令，其中包含 IP 和埠作為引數。IP 和埠的格式為“h1,h2,h3,h4,p1,p2”。每個欄位是主機 IP 的 8 位的十進位制表示，後面跟著所選的資料埠。例如，具有 IP 地址 192.168.0.1 的客戶端，它在埠 49154 上偵聽資料連線，將傳送命令“PORT 192,168,0,1,192,2”。埠欄位應解釋為 p1×256 + p2 = 埠，或者在本例中為 192×256 + 2 = 49154。

在被動模式中，FTP 伺服器開啟一個動態埠，透過控制流向 FTP 客戶端傳送要連線的伺服器 IP 地址和它正在偵聽的埠（一個分成高位元組和低位元組的 16 位值，如上所述），並等待來自 FTP 客戶端的連線。在這種情況下，FTP 客戶端將連線的源埠繫結到動態埠。

要使用被動模式，客戶端傳送PASV命令，伺服器將以類似於“227 Entering Passive Mode (127,0,0,1,192,52)”的響應進行回覆。IP 地址和埠的語法與 PORT 命令引數的語法相同。

在擴充套件被動模式中，FTP 伺服器的操作方式與被動模式完全相同，但它只傳輸埠號（而不是分成高位元組和低位元組），客戶端應該假定它連線到最初連線的同一個 IP 地址。

當透過資料流傳輸資料時，控制流處於空閒狀態。這會導致透過防火牆進行大型資料傳輸出現問題，因為防火牆會在長時間的空閒後超時會話。雖然檔案可能已成功傳輸，但防火牆可能會斷開控制會話，從而導致生成錯誤。

FTP 協議支援使用 REST 命令恢復中斷的下載。客戶端將已接收的位元組數作為引數傳遞給 REST 命令，然後重新啟動傳輸。例如，在某些命令列客戶端中，有一個經常被忽略但很有價值的命令“reget”（表示“重新獲取”），它會導致在通訊中斷後繼續中斷的“get”命令，希望能夠完成。

恢復上傳並不容易。雖然 FTP 協議支援 APPE 命令將資料追加到伺服器上的檔案，但客戶端不知道傳輸中斷的確切位置。它必須透過其他方式獲取檔案的大小，例如透過目錄列表或使用 SIZE 命令。

在 ASCII 模式（見下文）中，如果客戶端和伺服器使用不同的行尾字元，恢復傳輸可能會很麻煩。

資料格式

在透過網路傳輸資料時，可以使用多種資料表示形式。兩種最常見的傳輸模式是

• ASCII 模式
• 二進位制模式：在“二進位制模式”下，傳送機器逐位元組地傳送每個檔案位元組，因此接收者按接收到的方式儲存位元組流。（FTP 標準稱之為“IMAGE”或“I”模式）

在 ASCII 模式下，任何形式的非純文字資料都會被破壞。當使用 ASCII 型別的傳輸傳送檔案時，單個字母、數字和字元使用其 ASCII 字元程式碼傳送。接收機器將這些程式碼儲存到適當格式的文字檔案中（例如，Unix 機器將其儲存為 Unix 格式，Windows 機器將其儲存為 Windows 格式）。因此，如果使用 ASCII 傳輸，可以假定傳送的是純文字，接收計算機將其儲存為自己的格式。文字格式之間的轉換可能需要用目標平臺上的行尾和檔案尾字元替換源平臺上使用的字元，例如，從 Unix 機器接收檔案的 Windows 機器將用回車換行對替換換行符。它也可能涉及字元轉換；例如，當從 IBM 大型機傳輸到使用 ASCII 的系統時，大型機上使用的 EBCDIC 字元將轉換為其 ASCII 等效項，而當從使用 ASCII 的系統傳輸到大型機時，ASCII 字元將轉換為其 EBCDIC 等效項。

預設情況下，大多數 FTP 客戶端使用 ASCII 模式。一些客戶端嘗試透過檢查檔名或內容，或確定伺服器是否執行具有相同文字檔案格式的作業系統，來確定所需的傳輸模式。

FTP 規範還列出了以下傳輸模式

• EBCDIC 模式 - 此模式傳輸位元組，但它們使用 EBCDIC 而不是 ASCII 編碼。因此，例如，ASCII 模式伺服器
• 本地模式 - 此模式專為與面向字而不是面向位元組的系統一起使用而設計。例如，模式“L 36”可用於在兩臺 36 位機器之間傳輸二進位制資料。在 L 模式下，字被打包成位元組，而不是被填充。一些 FTP 伺服器接受“L 8”作為“I”的等效項。

實際上，這些額外的傳輸模式很少使用。但是，它們仍然被一些舊的大型機系統使用。

文字（ASCII/EBCDIC）模式也可以使用所用回車控制的型別進行限定（例如，TELNET NVT 回車控制，ASA 回車控制），儘管現在很少使用。

請注意，術語“模式”在技術上是不正確的，儘管 FTP 客戶端經常使用它。在 RFC 959 中，“MODE”是指協議資料流的格式（STREAM、BLOCK 或 COMPRESSED），而不是底層檔案的格式。通常稱為“模式”的實際上是“TYPE”，它指定檔案的格式而不是資料流的格式。FTP 還支援檔案結構的規範（“STRU”），它可以是 FILE（面向流的檔案）、RECORD（面向記錄的檔案）或 PAGE（專為與 TENEX 一起使用而設計的特殊型別）。PAGE STRU 對於非 TENEX 系統來說實際上沒有用處，RFC 1123 第 4.1.2.3 節建議不要實現它。

FTP 返回碼

FTP 伺服器返回碼透過其中的數字指示其狀態。下面簡要說明了各種數字的含義

• 1xx：正向初步回覆。正在啟動請求的操作，但在開始之前將有另一個回覆。
• 2xx：正向完成回覆。請求的操作已完成。客戶端現在可以發出新命令。
• 3xx：正向中間回覆。命令已成功，但需要進一步命令才能使伺服器對請求採取行動。
• 4xx：瞬態負向完成回覆。命令未成功，但客戶端可以自由地嘗試重新執行該命令，因為該錯誤只是暫時的。
• 5xx：永久性負向完成回覆。命令未成功，客戶端不應嘗試再次執行該命令。
• x0x：錯誤是由於語法錯誤造成的。
• x1x：此響應是對資訊請求的回覆。
• x2x：此響應是對與連線資訊相關的回覆。
• x3x：此響應是對與記賬和授權相關的回覆。
• x4x：尚未指定
• x5x：這些響應指示伺服器檔案系統相對於請求的傳輸或其他檔案系統操作的狀態。

匿名 FTP

提供 FTP 服務的主機可能還會提供匿名 FTP 訪問。使用者通常在被提示使用者名稱時使用“匿名”帳戶登入。雖然通常會要求使用者提供他們的電子郵件地址代替密碼，但實際上對所提供資料的驗證很少或根本沒有進行。

由於現代 FTP 客戶端通常會隱藏匿名登入過程，因此 ftp 客戶端會提供虛擬資料作為密碼（因為使用者的電子郵件地址可能對應用程式未知）。例如，以下 ftp 使用者代理為匿名登入指定了列出的密碼

• Mozilla Firefox (3.0.7) — mozilla@example.com
• KDE Konqueror (3.5) — anonymous@
• wget (1.10.2) — -wget@
• lftp (3.4.4) — lftp@

命令

在 Windows 中輸入 ftp /?，或在 Unix 中輸入 ftp --help，以獲取命令引數。

連線到伺服器後，輸入 help 以顯示不同的可用命令。

要使用滑鼠操作檔案，請下載一個好的 FTP 客戶端，它將提供介面（例如 這個 Filezilla 不需要任何安裝）。