- - PR -
HTTPとFTPはどっちがファイル転送向き？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2002-10-18 18:49
FTPは転送向きか？ ですが、FTPはデータ転送用コネクションと制御用
コネクションが別なので、データ転送の途中でエラーが起こっても、 （いつでも）制御用コネクションを使って、すぐにエラーをお互いに伝えたり、 中断したりできます。が、HTTPは１コネクションですべてやっているので、 エラーの通知や中断などがちょっと難しい、からではないでしょうか？ まぁ、おかげでFTP通すためにはちょっとややこしいというデメリットもあるのですが。 ところで http://www.vector.co.jp って、Server: Netscape-Enterprise/3.6 SP3 って返ってくるんですけど、ほんとにこんな古い（？）サーバ使ってるん でしょうかねぇ？ だとすると、マシンも古そうなので、ほんとに負荷を 抑えたいので、 FTPを推奨してるのではないでしょうか。 ちなみにFTPは、NcFTPd ってやつらしいです。 [ メッセージ編集済み 編集者: Uchiko 編集日時 2002-10-18 19:18 ] | ||||
|
投稿日時: 2002-10-18 22:20
切れにくい、切れやすい、については、プロトコル上では同じでしょう。要は、クライアントがどれだけ待つか、といった話だと思います。FTPでは、Uchikoさんの発言通り、制御リンクを使って細かなエラー通知や、転送の中断(ABOR)、転送ステータスの処理(STAT)が可能です。
ケーブルを抜いても、自動継続するかどうかについても同様に、クライアントが再接続の機能を持つかどうかの違いでしかありません。リンク切れの場合の定義は、どちらにもありませんので、クライアント側の実装の違いです。 RESTについては、959の定義では、ブロックモードと圧縮モードのみですが、現実的にはほとんどのFTPdにおいて、ストリームモードでのRESTコマンド（ファイルポインタの移動）をサポートしています。この実装は、現在internet draftで正式化のために論議されています。（もしかしたらもうRFCになったかもしれません）もちろん、HTTPではファイルの一部分取得が可能です。 というわけで、ことanonymousのダウンロードに関して言えば、FTPとHTTPではプロトコル上で有為な違いはありません。 FTPとHTTPのプロトコルの違いは、こうした全体の中の、ごくごく一部の機能を切り出して優劣を比較する論議では明らかにはなりません。「テレビとラジオ、音を出すにはどっちが良いですか？」という話に意味がないのと同じです。 そもそも、HTTPサーバー単体ではアップロードは難しいですし、細かなユーザー管理も煩雑になります。また、大規模なダウンロードサイトの場合、管理ログ（例えば、ベクターであればダウンロードの実績数が月ごとに送られてきます）をHTTPと別に取ったり、複数のFTPdがある場合にはサーバー間転送を使うことで効率的にミラーリングが可能です。また、制御リンクとデータリンクが別であるため、ダウンロード先のコンピュータにShellがない場合でもFTPdさえ動いていれば、ダム端末や、Telnetクライアント（ポート指定ができるもの）を使ってファイル転送が出来ます。 FTPdに、Webブラウザを接続させれば、htmlファイルを綺麗に表示させることは可能ですが、サーバー側にスクリプトを動かしたり、動的なサービスは無理でしょう。（昔のFTPdではSiteコマンドで出来るものもありましたが、セキュリティ上の理由から現在はほとんど使用できません。） | ||||
|
投稿日時: 2002-10-19 00:08
つまり、
FTPの方がエラー処理を実装をしやすいプロトコルで、FTPクライアントがエラー処理をきちんとしている実装になっていることが多いので、ファイルを確実に転送できる確率が高い。 だから、多くのダウンロードサイトではFTPを推奨している。ということなんでしょうね。 （IBMのサイトで、ブラウザでのFTPではなくFTPコマンドを推奨しているあたりをみるとブラウザのFTPクライアントはそのあたりの処理が甘い？）
そうですよね。アップロードの必要があるとか、FireWallの中から使うこともあるとか、そういうさまざま要因を総合してこの場合はFTPの方が優れているとかHTTPの方が優れているという判断をすべきで、一般的にどっちが優れているというのは難しいですよね。 | ||||
|
投稿日時: 2002-10-31 16:29
ブラウザベースでのファイル転送だとあまり差を感じませんが、
PIによる実装があるFTPのほうがサーバ側に溜まるログやCSVの取得なんかをする際、 処理の自動化がしやすい、というメリットがあるかと。 またHTTPではASCIIとBINARYを明確にわけて転送できるのでしょうか。 #FTPクライアントの多くもサフィックス依存とは思いますが・・・ | ||||
|
投稿日時: 2002-10-31 22:32
興味深く読んでいます。そうですね、何に対して向いているかで微妙に評価も変わりますよね。
そもそもFTPはHTTPも何も無かった頃に「とにかくファイル転送できるプロトコルがいるよね」ってことで出来た訳で、別に向いているとは主張していないように思います(それしか名前の付けようが無かったと)。 とは言え現在でもファイル転送の主流に位置しているのは、FTPのデータコネクションがUDPである点は見逃せないと思います。HTTPのTCPに比べると転送効率も上がりますよね(ロストには弱いかも知れませんが)。多数のデータ転送が起こり得て帯域を出来るだけシェアしたい場合にはこちらの選択がいいのではないでしょうか。 一方HTTP1.1のContent Codingでの例えばGzip圧縮をすれば圧倒的にデータ量も減りますが、よくあるようにデータがランダムなバイナリデータや、そもそも圧縮されているデータなどではこのメリットは出てきません。 従って、HTTPではContent Codingを前提にして、テキストとかコンテンツ系であればHTTPを、バイナリ?系であればFTPがそれぞれ優れていると言えるんじゃないでしょうか。 # ま、一般論ですけどね。最近はデータコネクションがTCPの場合もある?みたいですし。 | ||||
|
投稿日時: 2002-11-01 03:28
えっ、FTPって、（最初からずっと）TCPですよね？ UDPなのは、TFTPなのでは？ それにTFTPは、いちいちAckが要るのであんまりパフォーマンスは 出ませんよね（さすがにインターネットでこんなのを使うやつは いないだろうが） | ||||
|
投稿日時: 2002-11-01 08:21
いい加減なこと書いてしまいました。すみません。転送効率の点では変わらないということですね。 ということで、コンテンツ系の圧縮を前提にするならHTTP(1.1)、他は変わらないってことになるかと思います。 | ||||
|
投稿日時: 2002-11-29 17:07
こん＊＊は。
私は制御ポートとデータ転送用ポートが分かれている ことにより、（1つのポートですべてをやりとりしている プロトコルよりも）パフォーマンスが良い事が一番の メリットだと思っていました。 勉強になりました。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。