ファイル転送プロトコル

ファイル転送プロトコル（FTP ）は、コンピュータネットワーク上でサーバーからクライアントにコンピュータファイルを転送するために使用される標準通信プロトコルです。FTPは、クライアントとサーバーの間で別々の制御接続とデータ接続を使用するクライアントサーバーモデルアーキテクチャ上に構築されています。^[1] FTPユーザーは、通常ユーザー名とパスワードの形式であるプレーンテキストのサインインプロトコルを使用して自分自身を認証しますが、サーバーがそれを許可するように構成されている場合は匿名で接続できます。ユーザー名とパスワードを保護し、コンテンツを暗号化する安全な転送のために、FTPは多くの場合SSL / TLS（FTPS ）で保護されるか、 SSHファイル転送プロトコル（SFTP）に置き換えられます。

最初のFTPクライアントアプリケーションは、オペレーティングシステムにグラフィカルユーザーインターフェイスが搭載される前に開発されたコマンドラインプログラムであり、現在でもほとんどのWindows、Unix、Linuxオペレーティングシステムに同梱されています。^{[2] [3]それ以来、}デスクトップ、サーバー、モバイルデバイス、ハードウェア向けに多くの専用FTPクライアントと自動化ユーティリティが開発され、FTPはHTMLエディターやファイルマネージャーなどの生産性アプリケーションに組み込まれています。

FTPクライアントは、以前はウェブブラウザに統合されることが一般的で、ファイルサーバはURIプレフィックス「ftp://」で参照されていました。2021年に、2つの主要なウェブブラウザベンダーであるGoogle ChromeとFirefox ^{[4] [5]}は、 より安全なSFTPとFTPSに取って代わられたため、FTPサポートを廃止しました。ただし、どちらも新しいプロトコルを実装していません。^{[6] [7]}

ファイル転送プロトコルの元の仕様は、Abhay Bhushanによって書かれ、1971 年 4 月 16 日にRFC  114として公開されました。1980 年まで、FTP はTCP/IPの前身であるNCP上で動作していました。^[2]このプロトコルは後に TCP/IP バージョンのRFC  765 (1980 年 6 月) とRFC  959 (1985 年 10 月) に置き換えられ、これが現在の仕様です。提案されたいくつかの標準はRFC  959 を修正します。たとえば、RFC  1579 (1994 年 2 月) はファイアウォール フレンドリ FTP (パッシブ モード) を有効にし、RFC  2228 (1997 年 6 月) はセキュリティ拡張を提案し、RFC  2428 (1998 年 9 月) はIPv6のサポートを追加し、新しいタイプのパッシブ モードを定義します。^[8]

FTPはアクティブモードまたはパッシブモードで実行され、データ接続の確立方法を決定します。^[9]（この「モード」の意味は、FTPプロトコルのMODEコマンドの意味とは異なります。）

• アクティブモードでは、クライアントはポートMでサーバーからのデータ接続の受信を待ち受けます。クライアントはFTPコマンドPORT ^[10] Mを送信して、どのポートで待ち受けているかをサーバーに通知します。サーバーは、FTPサーバーのデータポートであるポート20からクライアントへのデータチャネルを開始します。
• クライアントがファイアウォールの背後にあり、TCP接続を受け付けられない状況では、パッシブモードが使用されることがあります。このモードでは、クライアントは制御接続を使用してサーバーにPASVコマンドを送信し、サーバーからサーバーのIPアドレスとサーバーのポート番号を受信します。^[9]クライアントはこれを使用して、任意のクライアントポートから受信したサーバーのIPアドレスとサーバーのポート番号へのデータ接続を開きます。^[11]

両モードは1998年9月にIPv6をサポートするために更新されました。その際にパッシブモードにさらなる変更が導入され、拡張パッシブモードに更新されました。^[12]

サーバーは制御接続を介して、オプションのテキスト メッセージを含む3 桁のASCII ステータス コードで応答します。たとえば、「200」(または「200 OK」) は、最後のコマンドが成功したことを意味します。数字は応答のコードを表し、オプションのテキストは人間が読める説明または要求を表します (例: <ファイルの保存にはアカウントが必要です>)。^[1]データ接続を介して進行中のファイル データの転送は、制御接続を介して送信される割り込み メッセージを使用して中止できます。

FTP には 2 つのポート (送信用と受信用) が必要です。これは、元々 FTP がネットワーク制御プロトコル(NCP) の上で動作するように設計されたためです。NCP は、 2 つのポート アドレスを使用して2 つの接続を確立し、双方向通信を行う単純プロトコルでした。奇数ポートと偶数ポートは、アプリケーション層アプリケーションまたはプロトコルごとに予約されていました。TCP と UDP の標準化により、アプリケーションごとに 2 つの単純ポートを使用する必要が 1 つの二重ポートにまで削減されましたが、^{[13] : 15} FTP プロトコルは 1 つのポートのみを使用するように変更されることはなく、下位互換性のために 2 つのポートを使用し続けました。

FTPは通常、クライアントがPORTコマンドを送信した後、サーバーをクライアントに接続させることでデータを転送します。これは、インターネットから内部ホストへの接続を許可しないNATとファイアウォールの両方にとって問題となります。 ^[14] NATの場合、さらに複雑なのは、PORTコマンドのIPアドレスとポート番号の表現が、NATのパブリックIPアドレスとポートではなく、内部ホストのIPアドレスとポートを参照することです。

この問題を解決するには 2 つの方法があります。1 つは、FTP クライアントと FTP サーバーが PASV コマンドを使用して、FTP クライアントからサーバーへのデータ接続を確立する方法です。^[14]これは、最近の FTP クライアントで広く使用されています。もう 1 つの方法は、NAT が PORT コマンドの値を変更する方法で、この目的のためにアプリケーション レベルのゲートウェイを使用します。^[14]

ネットワーク上でデータを転送する際には、5つのデータ型が定義されます。^{[2] [3] [8]}

• ASCII (タイプ A): テキストに使用されます。データは、必要に応じて、送信ホストの文字表現から「8 ビット ASCII」に変換されてから送信され、(必要に応じて)改行を含む受信ホストの文字表現に変換されます。したがって、このモードは、ASCII 以外のデータを含むファイルには適していません。
• イメージ (TYPE I、一般にバイナリモードと呼ばれる): 送信マシンは各ファイルをバイト単位で送信し、受信者は受信したバイト ストリームを保存します(イメージ モードのサポートは、FTP のすべての実装で推奨されています)。
• EBCDIC (タイプ E): EBCDIC 文字セットを使用するホスト間のプレーンテキストに使用されます。
• ローカル (TYPE L n ): 8 ビット バイトを使用しないマシン (例: DEC PDP-10などの36 ビット システム)間のファイル転送をサポートするように設計されています。たとえば、「TYPE L 9」は 9 ビット バイトでデータを転送するために使用され、「TYPE L 36」は 36 ビット ワードでデータを転送するために使用されます。最近のほとんどの FTP クライアント/サーバーは、I に相当する L 8 のみをサポートしています。
• UTF-8を使用したUnicodeテキストファイル（TYPE U）：期限切れのインターネットドラフト^[15]で定義されていますが、RFCにはならなかったものの、いくつかのFTPクライアント/サーバーで実装されています。

これらのデータ タイプは一般に「モード」と呼ばれますが、あいまいなことに、この単語はアクティブ通信モードとパッシブ通信モード (上記を参照) や、FTP プロトコルの MODE コマンドによって設定されるモード (下記を参照) を指すためにも使用されます。

テキスト ファイル (タイプ A およびタイプ E) の場合、ファイルの印刷方法を制御するために、次の 3 つの異なる形式制御オプションが提供されます。

• 非印刷（TYPE ANおよびTYPE EN） – ファイルにはプリンタ用のキャリッジ制御文字が含まれていません。
• Telnet (TYPE AT および TYPE ET) – ファイルには Telnet (つまり ASCII C0) のキャリッジ制御文字 (CR、LF など) が含まれています。
• ASA (TYPE AA および TYPE EA) – ファイルには ASA キャリッジ制御文字が含まれています

これらの形式は主にライン プリンタに関連しており、ほとんどの最新の FTP クライアント/サーバーは N のデフォルトの形式制御のみをサポートしています。

ファイル構成は STRU コマンドを使用して指定されます。次のファイル構造は RFC959 のセクション 3.1.1 で定義されています。

• Fまたは FILE 構造 (ストリーム指向)。ファイルは、任意のバイト、文字、または単語のシーケンスとして表示されます。これは、Unix システムや CP/M、MS-DOS、Microsoft Windows などの他のシステムでの通常のファイル構造です。(セクション 3.1.1.1)
• Rまたは RECORD 構造 (レコード指向)。ファイルは、固定長または可変長のレコードに分割されていると見なされます。このファイル構成は、レコード指向ファイルシステムをサポートする MVS、VM/CMS、OS/400、VMS などのメインフレームおよびミッドレンジ システムで一般的です。
• Pまたは PAGE 構造 (ページ指向)。ファイルはページに分割され、ページにはデータまたはメタデータが含まれます。各ページには、さまざまな属性を示すヘッダーが含まれる場合もあります。このファイル構造はTENEXシステム用に特別に設計されたもので、通常は他のプラットフォームではサポートされていません。RFC1123 セクション 4.1.2.3 では、この構造を実装しないことを推奨しています。

最近のほとんどの FTP クライアントとサーバーは STRU F のみをサポートしています。STRU R は、メインフレームやミニコンピュータのファイル転送アプリケーションで今でも使用されています。

データ転送は3つのモードのいずれかで行うことができます: ^{[1] [2]}

• ストリーム モード (MODE S): データは連続ストリームとして送信され、FTP が処理を行う必要がなくなります。すべての処理はTCPに任されます。データがレコードに分割されない限り、ファイル終了インジケーターは必要ありません。
• ブロックモード（モードB）：主にレコード指向ファイル（STRU R）の転送用に設計されていますが、ストリーム指向（STRU F）テキストファイルの転送にも使用できます。FTPは各レコード（または行）のデータを複数のブロック（ブロックヘッダー、バイト数、データフィールド）に分割し、TCPに渡します。^[8]
• 圧縮モード（MODE C）：ランレングス符号化を使用したデータ圧縮によりMODE Bを拡張します。

現代の FTP クライアントとサーバーのほとんどは、MODE B または MODE C を実装していません。ただし、メインフレームとミニコンピュータのオペレーティング システム用の FTP クライアントとサーバーは例外です。

一部のFTPソフトウェアは、DEFLATEベースの圧縮モードも実装しており、これを有効にするコマンドにちなんで「モードZ」と呼ばれることもあります。このモードはインターネットドラフトで説明されましたが、標準化されていません。^[16]

GridFTPはMODE Bの拡張として MODE E ^[17]とMODE X ^[18]という追加モードを定義しています。

最近のFTPの実装では、Modify Fact: Modification Time (MFMT)コマンドがサポートされており、クライアントはファイル属性をリモートで調整して、ファイルをアップロードするときにその属性を保持することができます。^{[19] [20]}

リモートファイルのタイムスタンプを取得するには、 MDTMコマンドがあります。一部のサーバー（およびクライアント）は、 2つの引数を持つMDTMコマンドの非標準構文をサポートしており、 MFMT ^[21]と同じように機能します。

FTP ログインでは、通常のユーザー名とパスワード方式を使用してアクセスを許可します。^[2]ユーザー名は USER コマンドを使用してサーバーに送信され、パスワードは PASS コマンドを使用して送信されます。^[2]このシーケンスは「ネットワーク上で」暗号化されていないため、ネットワークスニッフィング攻撃に対して脆弱である可能性があります。^[22]クライアントによって提供された情報がサーバーによって受け入れられると、サーバーはクライアントに挨拶を送信し、セッションが開始されます。^[2]サーバーがサポートしている場合、ユーザーはログイン資格情報を提供せずにログインできますが、同じサーバーがそのようなセッションに対して制限されたアクセスのみを許可する場合があります。^[2]

FTPサービスを提供するホストは、匿名FTPアクセスを提供する場合があります。^[2]ユーザーは通常、ユーザー名の入力を求められたときに「匿名」（一部のFTPサーバーでは小文字で大文字と小文字が区別されます）アカウントでサービスにログインします。ユーザーは一般的にパスワードの代わりにメールアドレスを送信するように求められますが、 ^[3]実際には提供されたデータに対して検証は実行されません。^[23]ソフトウェア更新を提供することを目的とする多くのFTPホストは、匿名ログインを許可します。^[3]

多くのファイルマネージャにはFTPアクセスが実装されており、Microsoft Windowsのファイルエクスプローラ（旧Windowsエクスプローラ）などがその例です。このクライアントは、専用のクライアントソフトウェアに比べて制限があるため、サーバーからの小さなファイル転送にのみ推奨されます。^[24] SFTPはサポートされていません。^[25]

Linux上のKDEのネイティブファイルマネージャ（ DolphinとKonqueror）はどちらもFTPとSFTPをサポートしています。^{[26] [27]}

Androidでは、 Samsung GalaxyのMy FilesファイルマネージャーにFTPおよびSFTPクライアントが組み込まれています。^[28]

長い間、ほとんどの一般的なウェブブラウザはFTPサーバーにホストされているファイルを取得できましたが、FTPSなどのプロトコル拡張をサポートしていないものもありました。^{[3] [29]} HTTPではなくFTPのURLが指定されると、リモートサーバー上のアクセス可能なコンテンツは、他のウェブコンテンツに使用されるものと同様の方法で表示されます。

Google ChromeはChrome 88でFTPサポートを完全に削除し、Microsoft Edgeなどの他のChromiumベースのブラウザにも影響を与えました。^[30] Firefox 88はデフォルトでFTPサポートを無効にし、Firefox 90ではサポートが完全に廃止されました。^{[31] [4]}

FireFTPは、 Firefox内で実行されるフル機能のFTPクライアントとして設計された廃止されたブラウザ拡張機能ですが、FirefoxがFTPのサポートを中止したときに、拡張機能の開発者はWaterfoxの使用を推奨しました。^[32]テキストベースのLynxなどの一部のブラウザは、まだFTPをサポートしています。^[33]

FTP URL 構文はRFC  1738 で説明されており、次の形式をとります(括弧部分はオプションです)。 ftp://[user[:password]@]host[:port]/[url-path]

たとえば、URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt は、 FTP リソースとしてサーバーpublic.ftp-servers.example.com上のディレクトリmydirectoryにあるファイルmyfile.txtを表します。URL ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt は、このリソースにアクセスするために使用する必要があるユーザー名とパスワードの指定を追加します。

ユーザー名とパスワードの指定に関する詳細は、ブラウザのドキュメント（Firefox ^[34]やInternet Explorer ^[35]など）に記載されています。デフォルトでは、ほとんどのWebブラウザはパッシブ（PASV）モードを使用しており、エンドユーザーのファイアウォールをより簡単に通過できます。

ユーザーのルート以外のホームディレクトリがある場合、ブラウザによってパス解決の扱い方に多少の違いがある。^[36]

最も一般的なダウンロードマネージャーはFTPサーバーにホストされているファイルを受信できますが、FTPサーバーにホストされているファイルを取得するためのインターフェイスを提供するものもあります。DownloadStudioでは、 FTPサーバーからファイルをダウンロードできるだけでなく、FTPサーバー上のファイルのリストを表示することもできます。^[37]

LibreOfficeは7.4リリースからFTPサポートを非推奨と宣言しましたが、これは後に24.2リリースで削除されました。^{[38] [39]}

FTPは安全なプロトコルとして設計されておらず、多くのセキュリティ上の弱点があります。^[40] 1999年5月、RFC  2577の作成者は、次の問題に対する脆弱性をリストしました。

• ブルートフォース攻撃
• FTPバウンス攻撃
• パケットキャプチャ
• ポート盗用（次に開いているポートを推測し、正当な接続を奪取する）
• なりすまし攻撃
• ユーザー名の列挙
• DoS または DDoS

FTPはトラフィックを暗号化しません。すべての送信は平文で行われ、ユーザー名、パスワード、コマンド、データは、ネットワーク上でパケットキャプチャ（スニッフィング）を実行できる人なら誰でも読み取ることができます。 ^{[2] [40]この問題は、} TLSやSSLなどの暗号化メカニズムが開発される前に設計された多くのインターネットプロトコル仕様（ SMTP、Telnet、POP、IMAPなど）に共通しています。^[8]

この問題の一般的な解決策は次のとおりです。

1. 安全でないプロトコルの安全なバージョンを使用します。たとえば、 FTP の代わりにFTPS、Telnet の代わりに TelnetS を使用します。
2. SSH ファイル転送プロトコルやセキュア コピー プロトコルなど、ジョブを処理できる別のより安全なプロトコルを使用します。
3. Secure Shell (SSH) や仮想プライベート ネットワーク(VPN)などの安全なトンネルを使用します。

FTP over SSHは、通常のFTPセッションをセキュアシェル接続上でトンネリングする手法です。^[40] FTPは複数のTCP接続を使用するため（現在も使用されているTCP/IPプロトコルとしては異例）、SSH上でトンネリングするのは特に困難です。多くのSSHクライアントでは、制御チャネル（ポート21での最初のクライアントからサーバーへの接続）のトンネルを設定しようとすると、そのチャネルしか保護されません。データが転送されると、両端のFTPソフトウェアが新しいTCP接続（データチャネル）を設定するため、機密性や整合性は保護されません。

それ以外の場合は、SSH クライアント ソフトウェアが FTP プロトコルに関する特定の知識を持ち、FTP 制御チャネル メッセージを監視および書き換え、FTP データ チャネルの新しいパケット転送を自動的に開く必要があります。このモードをサポートするソフトウェア パッケージには、次のものがあります。

• SSH Communications SecurityのソフトウェアスイートのTectia ConnectSecure（Win/Linux/Unix）^[41]

FTP over SSH をSSH ファイル転送プロトコル(SFTP) と混同しないでください。

明示的 FTPS は、クライアントが FTP セッションの暗号化を要求できるようにする FTP 標準の拡張機能です。これは、「AUTH TLS」コマンドを送信することで実行されます。サーバーは、TLS を要求しない接続を許可または拒否するオプションを持ちます。このプロトコル拡張機能は、RFC  4217 で定義されています。暗黙的 FTPS は、SSL または TLS 接続の使用を必要とする FTP の古い標準です。これは、プレーン FTP とは異なるポートを使用するように指定されていました。

SSH ファイル転送プロトコル (2 つのプロトコルのうち、年代順に 2 番目、略称は SFTP) は、ファイルを転送し、ユーザー向けの同様のコマンド セットを備えていますが、ファイルの転送にはSecure Shellプロトコル (SSH) を使用します。FTP とは異なり、コマンドとデータの両方を暗号化し、パスワードや機密情報がネットワーク上で公開されて送信されるのを防ぎます。一部の FTP クライアント ソフトウェアは SSH ファイル転送プロトコルもサポートしていますが、FTP ソフトウェアと相互運用することはできません。

TFTP (Trivial File Transfer Protocol) は、クライアントがリモート ホストからファイルを取得したり、リモート ホストにファイルを配置したりできる、シンプルなロック ステップ FTP です。TFTP は実装が非常に簡単なため、主にローカル エリア ネットワークから起動する初期段階で使用されます。TFTP には、ファイル転送プロトコルなどのより堅牢なファイル転送プロトコルが提供するセキュリティと高度な機能のほとんどがありません。TFTP は 1981 年に初めて標準化され、プロトコルの現在の仕様はRFC  1350 に記載されています。

RFC  913で定義されている Simple File Transfer Protocol (最初のプロトコルは SFTP と略記) は、TFTP と FTP の中間の複雑さのレベルの (セキュリティ保護されていない) ファイル転送プロトコルとして提案されました。インターネットで広く受け入れられることはなく、現在はIETFによって Historic ステータスが割り当てられています。ポート 115 を介して実行され、多くの場合SFTPという頭文字で呼ばれます。11 のコマンド セットがあり、ASCII、バイナリ、連続の 3 種類のデータ転送をサポートしています。ワード サイズが 8 ビットの倍数であるシステムの場合、バイナリと連続の実装は同じです。プロトコルは、ユーザー ID とパスワードによるログイン、階層フォルダー、ファイル管理 (名前の変更、削除、アップロード、ダウンロード、上書きによるダウンロード、追加によるダウンロードを含む) もサポートしています。

以下は、 FTPサーバーから返される可能性のあるFTP 応答コードの概要です。これらのコードは、IETF によってRFC 959で標準化されています 。応答コードは 3 桁の値です。最初の桁は、成功、失敗、またはエラーまたは不完全な応答のいずれかの結果を示すために使用されます。

• 2yz – 成功の返信
• 4yz または 5yz – 失敗の応答
• 1yz または 3yz – エラーまたは不完全な返信

2 番目の数字はエラーの種類を定義します。

• x0z – 構文。これらの応答は構文エラーに関するものです。
• x1z – 情報。情報要求に応答します。
• x2z – 接続。制御接続とデータ接続を参照する応答。
• x3z – 認証とアカウンティング。ログイン プロセスとアカウンティング手順に対する応答。
• x4z – 定義されていません。
• x5z – ファイル システム。これらの応答は、サーバー ファイル システムからのステータス コードを中継します。

応答コードの 3 桁目は、2 桁目で定義された各カテゴリについて追加の詳細を提供するために使用されます。

• RFC  697 – FTP の CWD コマンド。1975 年 7 月。
• RFC  959 – (標準) ファイル転送プロトコル (FTP)。J. Postel、J. Reynolds。1985 年 10 月。
• RFC  1579 – (情報) ファイアウォールフレンドリー FTP。1994 年 2 月。
• RFC  1635 – (情報) 匿名 FTP の使用方法。1994 年 5 月。
• RFC  1639 – ビッグ アドレス レコード (FOOBAR) 経由の FTP 操作。1994 年 6 月。
• RFC  1738 – Uniform Resource Locators (URL)。1994 年 12 月。
• RFC  2228 – (提案標準) FTP セキュリティ拡張。1997 年 10 月。
• RFC  2389 – (提案標準) ファイル転送プロトコルの機能ネゴシエーション メカニズム。1998 年 8 月。
• RFC  2428 – (提案標準) IPv6、NAT、拡張パッシブ モードの拡張。1998 年 9 月。
• RFC  2577 – (情報) FTP セキュリティに関する考慮事項。1999 年 5 月。
• RFC  2640 – (提案標準) ファイル転送プロトコルの国際化。1999 年 7 月。
• RFC  3659 – (提案標準) FTP の拡張。P. Hethmon。2007 年 3 月。
• RFC  5797 – (提案標準) FTP コマンドおよび拡張レジストリ。2010 年 3 月。
• RFC  7151 – (提案標準) 仮想ホストのファイル転送プロトコル HOST コマンド。2014 年 3 月。
• IANA FTP コマンドおよび拡張機能レジストリ – FTP コマンドおよび拡張機能の公式レジストリ

• Wikibooks の通信ネットワーク/ファイル転送プロトコル
• FTP サーバー オンライン テスター 認証、暗号化、モード、接続。
• 国別コードTLD別の匿名FTPサーバー（2012年）：「Offbeat Internet - Public Access - FTP」。www.jumpjet.info。2012年。2023年3月28日時点のオリジナルよりアーカイブ。2020年1月16日閲覧。