NET // communication networks
LESSON 15 / 標準編

アプリ層 ─ FTP(ファイル転送)

Web より古い、インターネットの黎明期から使われてきたファイル転送プロトコル FTP。制御接続 と データ接続 を分けるという独特な設計、NAT 越えで主流になった Passive モード、ASCII/バイナリ転送の考え方までを扱います。本講では 第3回 プロトコルと TCP/IP 階層 のアプリケーション層の代表例として、FTP のしくみそのものに集中します。平文 FTP の危険性や FTPS / SFTP / SCP、現代の代替手段は アプリ層プロトコルのセキュア化 で扱います。

学習目標

本講を終えると、以下の問いに答えられるようになる。

本講は 第3回 プロトコルと TCP/IP 階層 の応用、メール詳細 と並ぶ「アプリ層プロトコル詳細」シリーズの1つです。FTP の問題点とセキュア化版(FTPS、SFTP、SCP)は TLS や SSH の知識が前提なので、アプリ層プロトコルのセキュア化 でまとめて扱います。NAT の振る舞いの詳細は IP・NAT の回で深掘りします。

このレッスンの目次

01 FTP の役割 FTP (File Transfer Protocol、RFC 959 / 1985… 02 二本のTCP接続 FTP がほかのアプリ層プロトコルと一線を画すのは、 1つのファイル転送に対して T… 03 主要コマンド FTP のコマンドは SMTP 同様 大文字 4 文字以内のニーモニック 、サーバ応… 04 Active vs Passive FTP の最大の山場が、データ接続を どちらから張るか という問題です。RFC 95… 05 接続フロー Active モードの動きを、5 ステップで時系列に追ってみましょう。Passive… 06 セキュリティへ接続 FTP は平文なので、安全化や現代の代替手段はセキュア化回で整理します… 07 まとめと用語 本講の重要語句を整理 08 確認問題 理解度を問題でチェック

FTP とは ─ Web より古いファイル転送プロトコル

FTP(File Transfer Protocol、RFC 959 / 1985 年) は、その名のとおり ファイルをネットワーク越しに送受信する ためのアプリケーション層プロトコルです。HTTP よりも約 10 年古く、インターネットの前身 ARPANET 時代から使われてきた老舗です。当時はまだ Web もブラウザもなく、研究者がプログラムやデータセットを別の大学の計算機に送るための「現役の道具」でした。
POINT FTP = ファイルの一覧取得(LIST)・ダウンロード(RETR = Retrieve)・アップロード(STOR = Store)を行うプロトコル。
・トランスポート層は TCP(信頼性必須なので UDP は使わない)
・制御チャネル と データチャネル を 別の TCP 接続 で持つのが最大の特徴

使われていた場面・今でも残っている場面

近年は HTTPS によるダウンロード や クラウドストレージの API(S3、GCS、Dropbox など)に押されて、Web で生身の FTP を見る機会は激減しました。ただし「ファイル転送のプロトコル設計の古典」として、ネットワークの教科書では必ず登場します。

もっと詳しく:anonymous FTP とは

誰でもユーザ名 anonymous(またはユーザ名なし)、パスワード欄に 自分のメールアドレスを慣習で入れる だけでログインできる、公開ダウンロード用 FTP の運用形態。1990 年代までは Linux カーネルや GNU ツールの配布の主流で、ftp.kernel.org や ftp.gnu.org といった有名サーバが多数稼働していました。現在はほとんどが HTTPS ミラーに置き換わり、anonymous FTP のサービス停止も相次いでいます(GNU プロジェクトは 2024 年頃に主要 FTP を縮小した、など [要確認])。

考えてみよう: 同じ「ファイルをやり取りする」目的なら、HTTP でも十分できそうですよね。実際 HTTP で GET /file.zip すれば似たことができます。なぜわざわざ FTP という別プロトコルが必要だったのか? ─ 答えは「ファイル転送に特化した一覧表示・アップロード・ディレクトリ操作」が HTTP より使いやすかったから、そして HTTP の登場(1991)よりも FTP のほうが先(1971/1985) だからです。

FTP の二本立て ─ 制御接続とデータ接続

FTP がほかのアプリ層プロトコルと一線を画すのは、1つのファイル転送に対して TCP 接続を2本 使う点です。これを Out-of-band(帯域外)制御方式 と呼びます。HTTP のように1本の TCP の中でコマンドもデータも流す方式は In-band(帯域内) と呼ばれます。
POINT 制御接続(control connection) ─ ポート 21/tcp。USER、PASS、LIST、RETR などのコマンドと、3桁数字の応答コードがやり取りされる。セッション中ずっと開いたまま。
データ接続(data connection) ─ Active モードでは 20/tcp(サーバ側)、Passive モードでは 動的に決まったポート。実際のファイル本体・ディレクトリ一覧の中身がここを流れる。制御接続上の指示をきっかけに開き、転送が終わるたびに切断 される。

データ接続は制御接続で準備してから開く

データ接続は、最初から勝手に開いているわけではありません。まず 21/tcp の制御接続 でログインし、ファイル一覧や転送が必要になったときに、制御接続上で PASV または PORT を使って「どちらが、どのポートへデータ接続を張るか」を決めます。そのうえで LIST、RETR、STOR などのコマンドを送ると、別の TCP 接続としてデータ接続が開き、そこに一覧やファイル本体が流れます。

FTP は2本の TCP 接続を使い分ける FTP クライアント FileZilla 等 FTP サーバ vsftpd 等 制御接続(Control) ─ 21/tcp USER / PASS / LIST / RETR / STOR …(常に開いたまま) データ接続(Data) ─ 20/tcp(Active) または 動的ポート(Passive) ファイル本体やディレクトリ一覧が流れる(転送ごとに開閉) 制御接続で「次のデータ接続」を準備 PASV / PORT で向き・ポートを決め、LIST / RETR / STOR で転送開始 /home/alice/ ~/Downloads/ ※ HTTP と違い、コマンドの「指令」と「中身」を別の TCP 接続に分ける

図の見方:青い実線が 制御接続、赤い破線が データ接続。制御接続は接続中ずっと張りっぱなしで、ログインや PASV/PORT、LIST/RETR などの指示を運びます。その指示をきっかけに、ファイル本体や一覧を運ぶためのデータ接続が別に開かれ、転送が終わると閉じられます。

なぜわざわざ分けたのか

分離する設計の利点はいくつかあります。

ただしこの設計が、後の NAT / ファイアウォール時代 に深刻な問題を引き起こします(セクション4で詳述)。1985 年当時はまだ NAT も普及していなかったため、その視点で設計されていなかったのです。

Q. HTTP は1本の TCP に詰め込むのに、FTP はなぜ2本要る? 自分の言葉で説明してみよう。

主要コマンドと応答コード

FTP のコマンドは SMTP 同様 大文字 4 文字以内のニーモニック、サーバ応答は 3 桁数字 + メッセージ という対話プロトコルです。覚えるべき主役は7〜8個ほど。telnet で 21 番ポートに繋いで、人間が手で打っても動くシンプルさです。

クライアントから送る代表コマンド

コマンド意味例
USERユーザ名を申告USER alice
PASSパスワードを送る(平文)PASS p@ssw0rd
PWD現在のディレクトリを表示PWD
CWDディレクトリ移動(Change Working Dir)CWD /pub/data
LISTファイル一覧を取得(データ接続が必要)LIST
RETRダウンロード(Retrieve)RETR report.pdf
STORアップロード(Store)STOR upload.zip
PORTActive モード:クライアントが待ち受けるポートをサーバに通知PORT 192,168,1,5,7,210
PASVPassive モードに切替を要求PASV
TYPE転送モード切替(A=ASCII / I=バイナリ)TYPE I
ABOR進行中の転送を中断ABOR
QUITセッション終了QUIT

サーバの応答コード(SMTP と同じ思想)

ASCII モード vs バイナリモード

FTP には2つの転送モードがあります。歴史的事情があり、現代では基本的に バイナリ(IMAGE / TYPE I) を使えば事故が少ない、と覚えてください。

ASCII モード(TYPE A)

  • テキストファイル専用。改行コードを 受信側 OS の流儀に変換 して転送する
  • 例:Unix(LF)から Windows(CRLF)に送ると、自動で \n → \r\n に変換される
  • 古い時代に「改行コード問題」を吸収するために用意された
  • 注意:バイナリ(画像・ZIP・実行ファイル)を ASCII モードで送ると 0x0A バイトが書き換わって壊れる

バイナリモード(TYPE I、IMAGE)

  • 1 バイトたりとも変換しない、生のまま転送する
  • 画像・動画・実行ファイル・圧縮ファイル ─ テキスト以外は全部こちら
  • テキストでも、改行コードの自動変換がいらないなら(または自前で扱うなら)バイナリで OK
  • 現代の GUI クライアントは 既定でバイナリ。事故防止の常識

つながる知識: SMTP 本文の MIME(第15回)では Base64 や Quoted-Printable で「ASCII の枠に押し込む」方向の解決を採用していました。FTP は逆に「最初からバイナリ転送モードを用意する」発想。同じ「テキストとバイナリの溝」を、プロトコルごとに違う方法で解決している好例です。

Active モードと Passive モード ─ どちらがデータ接続を張るか

FTP の最大の山場が、データ接続を どちらから張るか という問題です。RFC 959 の本来仕様は Active モード(サーバ側から開く)で、現代の主流は Passive モード(クライアント側から開く)。違いはたった「どちら向きに TCP の SYN を投げるか」ですが、これが NAT・ファイアウォール時代に大きな分岐を生みました。
POINT Active モード(PORT) ─ クライアントが PORT コマンドで「自分の m 番ポートを開けて待つから、そこに来て」と通知。サーバ側がクライアントに対して 20/tcp 発で データ接続を張る。
Passive モード(PASV) ─ クライアントが PASV コマンドで「待ち受けポートを教えて」と頼む。サーバが空きポート n 番で待ち受け、その番号を返答。クライアントが サーバの n 番に データ接続を張る。

2つのモードをステップで比べる

データ接続を張る向きが違う Active モード(PORT) 古典的 / NAT で失敗しやすい クライアント 待受 m 番 NAT / FW 外→内を遮断 FTP サーバ 21 / 20 Passive モード(PASV) 現代の主流 / 外向き接続で通りやすい クライアント ランダムポート NAT / FW 内→外は許可 FTP サーバ 21 / 動的 n 制御接続: client → server 21 制御接続: client → server 21 PORT m: 「クライアントの m 番へ来て」 データ接続: server 20 → client m 外から内への新規接続なので NAT/FW に止められやすい PASV: 「サーバ側の待受ポートを教えて」 227: 「n 番で待っている」 データ接続: client → server n クライアント発の外向き接続なので NAT/FW を通りやすい
ステップ1:どちらも制御接続から始まる。 Active でも Passive でも、まずクライアントから FTP サーバの 21/tcp へ制御接続を張ります。ログインやコマンドはこの青い接続を通ります。
ステップ2:Active では PORT で待受を知らせる。 クライアントは PORT コマンドで「自分の m 番ポートを開けて待つので、そこへ来て」とサーバへ伝えます。
ステップ3:Active のデータ接続はサーバ発。 サーバが 20/tcp 発 でクライアントの m 番へデータ接続を張ります。家庭や企業の NAT/FW から見ると「外から内への新規接続」なので、ここで止まりやすくなります。
ステップ4:Passive では PASV でサーバ側の待受を尋ねる。 クライアントは PASV コマンドで「ファイル転送用に、サーバ側のどのポートへ接続すればよいか」を聞きます。
ステップ5:サーバが待受ポートを返す。 サーバは 227 応答で「動的ポート n 番で待っている」と返します。Passive ではこの n 番がデータ接続の宛先になります。
ステップ6:Passive のデータ接続はクライアント発。 クライアントからサーバの n 番へデータ接続を張ります。制御接続と同じく外向き接続なので、NAT/FW を通りやすく、現代ではこちらが主流です。

図の見方:上段が Active、下段が Passive。青は制御接続、紫はモード指定、緑はサーバからの応答、赤い破線はデータ接続です。違いの本質は、赤いデータ接続を サーバから張る のか、クライアントから張る のかです。

Passive が主流になった理由(NAT・ファイアウォール問題)

1990 年代後半から、家庭・企業からインターネットへの接続は NAT(IPv4 アドレス節約) と ファイアウォール(セキュリティ) でくるまれるのが標準になりました。NAT は性質上、「内側から外への接続要求」を覚えておいて、それに対応する戻り通信だけを通す 仕組みです。

Active モードの「サーバ側からクライアントへの新規接続」は、NAT から見ると 覚えのない外からの SYN。誰のものか分からないので捨てるしかありません。ファイアウォールも同様に、無断のインバウンド接続は遮断します。結果、Active FTP は家庭・企業のクライアントから動かない、ということが頻発しました。

これを解決したのが Passive モード。データ接続も クライアントから張る 設計に変えれば、NAT を素直に通り抜けられます。現代のブラウザ・GUI FTP クライアントは PASV を既定 にしており、コマンドラインの ftp も passive サブコマンドや -p で切り替えられます。

もっと詳しく:NAT 越えで Passive が必要な理由(踏み込み版)

NAT は「内→外」の TCP SYN を見つけると、ローカル (192.168.1.5, 50001) ↔ グローバル (203.0.113.7, 60001) といった 変換テーブル に登録します。返信パケットがそのテーブル登録に 合致するときだけ 内側の機器に転送します。

Active モード(3)で発生する「サーバ 20/tcp → クライアント m/tcp」のパケットは、NAT のテーブルにない 未知のフロー です。NAT は内側のどの機器に届ければいいか分からないので破棄。結果、データ接続が成立しません。

さらに古い ALG(Application Layer Gateway)では、NAT 機器が制御接続の PORT コマンド本文を覗き見して、IP アドレス書き換え + テーブル事前登録で凌いでいました。が、これは制御接続が暗号化されると機能しません(FTPS で問題化)。解決策が「最初から外向きに張る Passive」、というわけです。

Passive 側にも問題はあります。サーバが返す 227 応答に含まれる「待受ポート n」をブラウザが信じて開きにいくため、FW 管理者は 動的ポート範囲(例:60000〜60100)を事前に許可 しておく必要があります。これを Extended Passive Mode(EPSV、RFC 2428、IPv6 対応)と組み合わせて運用するのが現代の定石です。

小問:家庭の Wi-Fi(ルータの NAT 越し)から Active モード FTP がうまく動かないことがあるのはなぜ?
正解:B。Active モードのデータ接続は サーバ側からクライアントに新規 TCP を張る 仕組み。NAT は内側のどのホストへ届けるかを覚えていないので、その SYN を捨てる(または ICMP unreachable を返す)。A は誤り(FTP は TCP)、C は別の話(Active モードは元来平文)、D は誤り(認証局は無関係)。

接続フローを1ステップずつ追う(Active モード)

Active モードの動きを、5 ステップで時系列に追ってみましょう。Passive と並べて見ると「(3) でデータ接続をどちらから張るか」だけが本質的な違いだとわかります。「次へ」ボタンで進めてください。
クライアント ランダム m / m+1 FTP サーバ 21 / 20 (1) 制御接続:client m → server 21 [SYN] 220 Welcome to vsftpd FTP service. USER alice → 331 Please specify the password. PASS p@ss → 230 Login successful. PORT 192,168,1,5,p1,p2 (p1*256+p2 = m+1) 200 PORT command successful. RETR aaa.txt サーバ 20 → クライアント m+1(データ接続) 226 Transfer complete. QUIT → 221 Goodbye.
ステップ1:制御接続を張る. クライアントは自分のランダムなポート m(例:50001)から、サーバの 21/tcp に TCP の3way ハンドシェイクで接続。サーバは挨拶として 220(Service ready)を返します。
ステップ2:ログイン(USER / PASS). クライアントは USER alice を送信、サーバは 331(パスワードを送ってください)で応答。続けて PASS p@ss を送ると 230(ログイン成功)。注意:このパスワードは 平文 でネットワーク上を流れます(後述の弱点)。
ステップ3:PORT で待受を通知. Active モードではクライアント自身が もう1つのポート(m+1 など) を開いて待ち受け、その IP とポート番号を PORT コマンドで通知します。書式は PORT a1,a2,a3,a4,p1,p2 でカンマ区切り。IP は4オクテット、ポート番号は p1×256 + p2 で表現します。
ステップ4:RETR とデータ接続の確立. ファイル名を指定して RETR aaa.txt を送ると、サーバは 自分の 20/tcp 発で クライアントの待受ポートに新規 TCP 接続を張ります(ここが Active の特徴)。データ接続が確立したら、ファイル本体がそのチャネルに流れていきます。
ステップ5:転送完了と QUIT. 転送が終わるとデータ接続は閉じられ、サーバは制御接続上で 226 Transfer complete. を返します。次のファイルを取りたければまた PORT/RETR を繰り返し、終わるなら QUIT で 221 Goodbye. を受けて切断。1セッションが完了します。
1 / 5

図の見方:左がクライアント、右がサーバ。時間は上から下。青の実線が制御接続、紫が PORT 通知、赤の破線がデータ接続です。Passive モードに変えると、ステップ3 が PASV、ステップ4 のデータ接続が「クライアント→サーバの動的ポート」に変わるだけ。骨格は同じです。

telnet による生の対話例

FTP は文字ベースの対話なので、telnet でも動作確認できます(教育目的)。Passive モード(PASV)を選ぶと、サーバが返した「ホスト + ポート番号」を読み取って 別のターミナルから手動でデータ接続を張る こともできます。

$ telnet localhost 21 S: 220 Welcome to blah FTP service. C: USER anonymous # 匿名ユーザでログイン S: 331 Please specify the password. C: PASS # パスワードはなしなので空白 S: 230 Login successful. C: PASV # パッシブモードに変換 S: 227 Entering Passive Mode (127,0,0,1,38,168). # → 38*256+168 = 9896 番で待ち受け C: RETR aaa.txt S: 150 Opening BINARY mode data connection for aaa.txt (63 bytes). S: 226 Transfer complete. C: QUIT S: 221 Goodbye.

2行目以降の「別ターミナルで telnet localhost 9896 して中身を覗く」というのが古典的な実習で、ファイル本体が 本当に別 TCP 接続で流れている ことを目視確認できます。

FTP の安全化はセキュリティ回で扱う

FTP は仕組みとしては分かりやすい一方、もともと 平文プロトコル です。パスワード・ファイル本体・サーバ確認の問題、そして FTPS / SFTP / SCP や HTTPS 配布・rsync・クラウド API への置き換えは、TLS や SSH の理解と合わせて セキュア化回 に回します。
POINT この回では FTP の二本立て構造・コマンド・Active/Passive に集中する。
「なぜ生の FTP を使い続けないのか」「代わりに何を選ぶのか」は FTPS / SFTP のところで整理する。
話題扱う場所
平文 FTP の危険性FTPS ─ FTP に TLS を被せる
FTPS と SFTP / SCP の違いSFTP / SCP は別系統
HTTPS 配布・rsync・クラウド API などの現代的な選び方ファイル転送の選び方

まとめと用語チェック

SUMMARY 1. FTP(RFC 959)は 制御接続(21/tcp) と データ接続(20/tcp ほか) を分ける Out-of-band 設計
2. 主要コマンド:USER / PASS / LIST / RETR / STOR / PORT / PASV / TYPE / QUIT
3. Active モード はサーバから、Passive モード はクライアントからデータ接続を張る
4. NAT・FW 普及により Passive モードが現代の主流(外向き接続だけで完結する)
5. FTP は 平文 であるため、危険性や FTPS / SFTP / SCP への置き換えは セキュア化回 でまとめて扱う

用語チェック

用語1行説明
FTPFile Transfer Protocol(RFC 959)。アプリ層のファイル転送プロトコル
制御接続FTP のコマンド・応答が流れる TCP 接続(21 番)
データ接続FTP の実データ(ファイル/一覧)が流れる TCP 接続(20 番ほか)
Out-of-band制御とデータを 別接続 に分ける方式(FTP の設計)
In-band制御とデータを 同一接続 に乗せる方式(HTTP など)
Active モードサーバ側からクライアントへデータ接続を張る(PORT)
Passive モードクライアント側からサーバへデータ接続を張る(PASV)
ASCII モードテキスト用、改行コードを変換して転送(TYPE A)
バイナリモード無変換で転送(TYPE I)
anonymous FTPパスワードなしで誰でも読み出せる公開 FTP の運用形態
NEXT: このあと第17回でサーバの実体(プロセスとポート)を整理し、第18回でトランスポート層の役割(多重化・ソケット・ポート)を体系化します。FTP・HTTP・メールが TCP に頼ってきた仕組みを、第19回で TCP の信頼性として、第20回で対極の UDP として深掘りしていきます。

確認問題

問1. FTP の「制御接続」と「データ接続」に関する説明として最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. 制御接続もデータ接続も 21 番ポート1本で多重化される
B. 制御接続は UDP、データ接続は TCP の 20 番を使う
C. 制御接続は TCP 21 番でコマンド・応答をやり取りし、データ接続は別の TCP 接続(Active なら 20 番、Passive なら動的ポート)でファイル本体を流す
D. 制御接続は HTTP、データ接続は SMTP を流用している
正解:C
FTP の特徴は Out-of-band 制御方式。1つのファイル転送に対して 2 本の TCP 接続を使う。コマンド対話用の制御接続(21 番、開きっぱなし)と、ファイル本体用のデータ接続(転送ごとに開閉)。A は誤り(別接続)、B も誤り(両方 TCP)、D は完全に誤り(別プロトコル)。

問2. FTP の Passive モードが Active モードよりも現代では多く使われる理由として、最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. Passive モードのほうが TLS 暗号化を強制できるから
B. データ接続もクライアントからサーバへの「外向き接続」となるため、NAT・ファイアウォール環境でも通り抜けやすいから
C. Passive モードはサーバが直接ハードディスクを読まずに済むので転送が高速になるから
D. Passive モードは TCP の代わりに UDP を使うのでヘッダが小さくなるから
正解:B
Active モードはサーバ側からクライアントに新規 TCP を張るため、家庭・企業の NAT・ファイアウォールに「未知の外→内」として捨てられる。Passive モードはデータ接続もクライアント発のため、外向き接続だけで完結し NAT を通過できる。これが普及の決定打。A は誤り(暗号化は別の話)、C も誤り(性能要因ではない)、D も誤り(両方 TCP)。

問3. 次のうち、FTP のコマンドと意味の対応として 誤っている ものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. RETR ─ サーバからファイルをダウンロードする
B. STOR ─ サーバへファイルをアップロードする
C. PASV ─ Passive モードに切り替えるよう要求する
D. USER ─ パスワードを暗号化して送るためのコマンド
正解:D(これが誤り)
USER はユーザ名を申告するコマンドで、暗号化は一切しない。パスワードは続く PASS で 平文のまま 送られる。これが FTP の致命的弱点。A・B・C はいずれも正しい説明。

問4. FTP の PASV コマンドに対するサーバ応答 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2) から、データ接続用ポート番号を求める式として正しいものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. p1 + p2
B. p1 * 256 + p2
C. p2 * 256 + p1
D. p1 * 100 + p2
正解:B
ポート番号は 16 ビット(0〜65535) なので、上位 8 ビット(p1)と下位 8 ビット(p2)に分けて返す。p1 * 256 + p2 で復元する。この値が応答にそのまま埋め込まれているため、NAT 越しに「サーバ側 IP」が嘘になる ── これが Active モード以外でも FTP が NAT と相性が悪い古典的な悩みどころ。

問5. FTP で画像・ZIP・実行ファイルなどを壊さず送るために適切な転送モードはどれか。

次の選択肢から最も適切なものを選択してください。
A. TYPE A の ASCII モード
B. TYPE I のバイナリ(IMAGE)モード
C. USER コマンドの直後に送るモード
D. Active モードなら自動的に壊れない
正解:B
TYPE I は 1 バイトも変換せずに送るバイナリ転送です。画像・ZIP・PDF・実行ファイルのような非テキストデータはこれを使います。ASCII モードは改行コードを変換するため、バイナリデータを壊すことがあります。
← PREV
第14回 メール詳細
NEXT →
第16回 telnet で覗くアプリ層