■ データコネクション接続

さてさて、FTPコマンドの続きを話そう。
まず、データコネクションの接続からだ。

データコネクションの接続？
データを転送するのに使う、FTPのもう１つのコネクションですよね。

うむ。何回か説明しているが、制御コネクションとデータコネクションは別物、だな。
どうやってデータコネクションを接続するかというと…。

データコネクションはサーバ側から接続される、よって、PORTコマンドで待ち受けポートを指定する。

ははぁ。
クライアントが待ち受けていないと、サーバから接続しようとしてもできませんからねぇ。

そういうことだ。そのPORTコマンドは以下の形になる。

ぽーと、クライアントのIPアドレス、ポート番号上位8ビット？下位８ビット？
なんです、これは？

うむ。ネット君、ポート番号は何ビットだ？

え〜っと。16ビットです。

うむうむ。その上位８ビットを10進数にしたものと、下位8ビットを10進数にしたものをPORTコマンドに入れるのだ。
つまり、こう。

2746というポート番号を2進数化して、前8ビットと後ろ8ビットにわけた、と。
右の計算式は簡単にわかるように書いたものだ。

ははぁ。
なんでこんな面倒な形なんですかね？

さぁ？

「さぁ」って博士。

うむ。すなおに「2746」と書いてもいい気がするしな、確かに。
なんか知らんが、この形なのだよ。

はぁ。そういうものなのですね。

そういうことにしておけ。過酷な世の中を生き抜くための知恵だ。
さて、データコネクションを開く前には使用するデータタイプを指定する必要がある。

でーたたいぷっていうと、あれですか。ASCIIとかIMAGEとかの。

そう。それだ。

TYPE A でASCII、TYPE I でIMAGEが設定される。

そのまんまですね。

そのまんまだな。
ちなみに今回は話の流れでPORT、TYPEと説明したが、実際はTYPE、PORTの順で実行する。

データタイプを指定してから、ポートの指定、ですね。

■ パッシブオープン

PORTコマンドでクライアントがポートを開き、そこへサーバが接続する。
これはこれでいいのだが、実は問題がある。

問題？

うむ。内部LANを守るファイアウォールを使った場合の問題だ。

ふぁいあうぉーる、って。
なんですか？

む。どっかで説明した記憶があるが…。
まぁいい。内部LANを守る壁だ。

外部からのTCP接続は不正アクセスなんですか？

詳しくはファイアウォールの時に説明するが、普通はそう判断する。
ネット君、TCP接続が確立されるということは、データ転送が可能になるということだな？

TCPを使うなら、そうですよね。
スリーウェイハンドシェイクでコネクションを確立して。

うむ。よって、外部からのSYN(TCP接続要求)を内部に送ってしまうと、外部からのデータが内部に流れ込むことになる。

そう、なりますね。
コネクションが確立されちゃうわけですから。

なので、ファイアウォールは外部からのSYNを内部に送らない。それにより外部からのアクセスを遮断するわけだ。
まぁ、DMZなどの例外はあるがな。

なるほど。
でもこれだと、ファイアウォールがあるとFTPができないってことになっちゃいますよね。

そうだ。
何故こんなことが起きるのだ？ それを回避する方法は？

何故起きるって…。
ファイアウォールがあるから？

なるほど。
それは確かに正しい。

ですよね、えへへ。

「交通事故は何故起こるのか？」「自動車があるから」
ネット君。君の問題提起能力には非常に疑問がある。

うぅぅ。

もう少し違う理由を考えたまえ。
つまり、データコネクションの特徴は？ どうやって確立される？

…。
サーバからコネクションを開始することが原因だってことですか？

そうだ。なので、クライアントからデータコネクションを開始してやればいい。

クライアントから開始…、そんなんありなんですか？

もちろん。これをパッシブオープンという。
パッシブオープンを行うためのコマンドは、以下のコマンドだ。

PASVコマンドを受け取ったサーバの動作と、コネクションの確立は以下の通り。

レスポンスコード227、ですか。

うむ。レスポンスコード2xxは「肯定的完了」。x2xは「コネクション」に関する応答。
「パッシブオープンしますよ」というレスポンスだな。

なるほど。

サーバによってはパッシブオープンしか駄目だったり、そういうこともある。
ちなみにパッシブオープンを使わなくても大丈夫なファイアウォールもある。

へぇ、どういうファイアウォールですか？

どういう、と言われても特に名前はないのだが。
FTPが非常に標準的なプロトコルなので、FTPのデータコネクションに関してはOKとしてしまう、という話だ。

FTPはよく使われるプロトコルだからな。
いちいちパッシブオープンにしなくてもよいように設定を変えてくれるわけだ。

ははぁ、こっちの方が便利ですね、クライアントで設定変更する必要がないですから。

■ ファイル転送

無事にデータコネクションが確立されたのなら、ファイルの転送だ。
サーバからファイルを受け取るコマンドがRETR。

サーバにファイルを送るコマンドがSTOR。

受けとるのがRETR、送るのがSTOR。
なんか紛らわしいですね。

つまり、サーバから受け取る[Retrieve]、サーバに保管する[Store]だな。

[Retrieve]と[Store]なんですか。
てっきり[Recive]と[Send]かな〜と思ってましたよ。

[Recive]だとRECVになってしまうな。
ともかく、動作はこのような形になる。

聞いてた通り、データコネクションでファイルを。制御コネクションでファイルのやり取りの内容を転送するんですね。
なんか納得です。

うむ。さて、このファイル転送の仕組みのポイントは２つ。
１つ目は、ファイルそのものを送るわけではないということだ。

はい？ ファイルを送るんですよね。どういうことです？

実際のところの話、だ。つまりファイルの中身だけを送り、それを受け取った受信側は受信側のファイル形式に合った形で、その中身を持つファイルを作成するのだよ。

ファイルを…作成する？

そうだ。
その際、RETR・STORコマンドで送られたファイル名で作成することになる。

送られた中身を、自分の形で、ファイルを作成する。

まぁ、見た目上はファイルをそのまま送った形になるがな。

ははぁ。
本当は「送って保存」、ではなく「送ったのを作成して保存」になるわけですね。

そういうことだ。
ホストそれぞれのファイル形式の違いを忘れるな。

了解です。

もう１つのポイントは、データコネクションの切断のタイミングと、レスポンスコード226を送る順番だな。

え〜っと。
切断してから、226が届くって感じですか？

うむ。
ファイル構造のストリームモード、ということだな。

ファイル構造のストリームモード？

前回やっただろう？
ファイル構造のストリームモードでは、データコネクション切断のFINがEOFになると。

ファイル構造の場合は、特にEOFのデータを付加しないんでしたっけ。

うむ。データコネクションの切断が全データの終了を意味する。
よってレスポンスコード226は、データコネクションの切断後に「すべて完了」という意味で送られる、ということだ。

は〜。なるほど。

うむ。
さて、今回はこれぐらいにしておこう。

あ、はい。

次回は、残りの主要なFTPコマンドの説明をする。

いぇっさ〜。
３分間ネットワーキングでした〜♪