- - PR -
HTTPとFTPはどっちがファイル転送向き？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-10-17 22:41
BUBUさんの
というのはリンク先をhttp://サーバ名:100/・・・等にしてしまえばいいだけですからわざわざ(?)FTPを用意するメリットが感じられません。前にも書いたとおり、みんなHTTPにしてしまえばいいのではないでしょうか。それにこれではFireWallの設定によっては弾かれてしまうってこともある気がするんですが・・・。 うーん、とりあえずRFCをあたってから出直すことにします。 | ||||||||
|
投稿日時: 2002-10-18 01:47
ファイアウォール等の関係でFTP/HTTP転送の両方をサポートする以外の話だと、
「ブラウザでHTTP転送だと化けやすいからFTPで」とは聞いたことがあります。 ただしそれがどの部分での話なのかは残念ながら分かりません。 が、同じFTPでも例えば、 http://www-6.ibm.com/jp/aspc/fixgatt.html では、ブラウザでのFTPではなくFTPコマンドを推奨しています。 つまりプロトコルベースの話ではなく、ここらあたりの実用上の話が あるのかもしれません。 参考まで。 | ||||||||
|
投稿日時: 2002-10-18 01:54
> というのはリンク先をhttp://サーバ名:100/・・・等にしてしまえばいいだけですから
> わざわざ(?)FTPを用意するメリットが感じられません。前にも書いたとおり、みんな > HTTPにしてしまえばいいのではないでしょうか。それにこれではFireWallの設定に > よっては弾かれてしまうってこともある気がするんですが・・・。 これ、私も賛成です。 FTPをHTTPの代わりにしたいのだったら下手な小細工は無意味です。 ざっと眺めてて気づいたのですが、FTPにはレジュームがありますね。 HTTPにもあったっけな。 | ||||||||
|
投稿日時: 2002-10-18 02:52
FTPにresumeなんてありましたっけ？ RESTART (REST)のことでしょうか？
HTTPならbyte-rangeで指定範囲だけを取り直したりできますが、HTTP1.0には ないので、これではすべての人にメリットがあるとは思えません。 FTPでは、１ファイルごとに１つのTCPコネクションを確立してファイルの 内容を転送し、終わったら、すぐにコネクションクローズしてしまいますよね？ ですので、やっぱりオーバーヘッドは最小だと思います。サーバもクライアントも シンプルですし。実際、うまくいけば、TCPの最速の速度（ほぼワイヤースピード に近い速度）でデータを転送できますし。 （GET時には、自動的にTCP Windowsサイズを拡大するというFTPコマンドも ありましたよね。いまどきはデフォルトで大きなウィンドウサイズになって いるので、あまり必要性はないようですが） これに比べるとHTTPでの転送は、やはり最初にHTTPでのコマンドやパラメータなど のやり取りのシーケンスが入るので（場合によってはさらにエンコードなども）、 ほんの少しオーバヘッドがあります。HTTPサーバとFTPサーバでは、やはりこの 解釈の分だけサーバの負荷が多くなるので（その分プロセスもでかい？）、 ファイル転送はやはり軽いFTPで主にやってもらいたい、と思ってFTPも 残しているのではないでしょうか？ 現在新規にダウンロードサイトを 用意する場合はHTTPだけで十分でしょうけど、ベクタは最初はFTPしか 使えなかったような？ 違いましたっけ？ それに、FTPならば自動巡回したりするツールも多くあるので、急にFTPをやめると 苦情が出そうだから（？）残しているのかも知れません。人によっては、 ftp://ftp.vector.co.jp/ を毎日自動で巡回している人がいるかもしれませんし。 それにFTPならば、ミラーサイト作るのも（いろいろノウハウが豊富なので） 簡単でしょうし。 とはいうものの、結局のところは過去との互換性のためにFTPが残っている、 というのが本当のところなのではないでしょうか？ ところで、転送の途中でケーブルを抜いたら……、という話がありましたが、それは サーバ側、ローカル側どちらを抜いたのでしょうか？ Windows 2000やXPでは、ケーブル を抜いてリンクが途切れると、TCP/IPのプロトコルスタックそのものが無効（ディセーブル 状態）になり、それが上位アプリケーションに伝わって、アプリケーションが実行を 中断したりします。ですので、通信障害の実験をするならば、リンクを活かしたまま 途中のパケットを落とすようにしないと、まずいのではないでしょうか？ ただ、コマンドプロンプト上のFTPコマンドは、そんな高尚な（？）イベントには 対応していないでしょうから、（コネクションが生きていれば）勝手に復活しても おかしくないような気がします。 | ||||||||
|
投稿日時: 2002-10-18 13:38
> FTPにresumeなんてありましたっけ？ RESTART (REST)のことでしょうか？
そです。マーカーを指定して途中からGETできそうな印象だったので。 実際にはどうなのかわからないまま書いてます。 間違ってたら申し訳ありません。 HTTPのリクエストの解析よりはFTPのコマンドのほうが処理は楽そうですね。 その分が「軽い」ということになるようにも見えます。 1回1回はほんの少しのオーバーヘッドかもしれませんが、ダウンロードサイトなどでは 結構な量になりそうな。 となるとFTPが残っていたり、推奨されててもわかる気がします。 | ||||||||
|
投稿日時: 2002-10-18 13:58
http://www.ipa.go.jp/security/awareness/administrator/remote/capter4/2.html
こんなページがありました。 FTPは、HTTPに比べて回線が混んでいても切れにくい、 途中切断したことが分かるなどのメリットがあるそうです。 | ||||||||
|
投稿日時: 2002-10-18 15:43
Vectorは古いサイトですから過去との互換性という意味では納得です。そういえば最近流行(?)のWebストレージサービス（用途はちょっと違いますが）とかはアップロードもダウンロードもHTTPのような・・・。とすると最近立ち上がったサイトなんかは結構HTTPだけで実現しているところが多いのでしょうかね。
このような話は聞いたことがあります。ただ、私が知りたいのはこれが「なぜ」そうなのか？ということなんです。 とりあえずRFC959(FTP)をざっと眺めてみたところ、「3.5. ERROR RECOVERY AND RESTART」という項目があったのですが、 The restart procedure is defined only for the block and compressed modes of data transfer. となっていました。IISではSTREAM MODE以外は実装されていないみたいで、このような処理はできないみたいです。 LANケーブルを抜くテストはクラアントがNT4.0 + IE6（FTP、HTTPともに）、サーバがWin2000 + IISという環境で、クライアント側のLANケーブルをHUBから抜いてみた結果です。 > Windows 2000やXPでは、ケーブルを抜いてリンクが途切れると、TCP/IPのプロトコルスタックそのものが無効（ディセーブル状態）になり・・・ というのはNT4.0では起こらないため、ケーブルを再び接続した際に転送が再開されたと考えられるということでしょうか。 | ||||||||
|
投稿日時: 2002-10-18 17:48
サービス提供者の都合じゃないでしょうか。
httpdよりftpdの方がサーバの転送制御機能が豊富じゃなかったかな。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。