インターネット経由でファイルを転送する場合、それぞれの利点 (または制限) は何ですか?
(私は両方のプロトコルの安全な形式を認識しています。パフォーマンス、信頼性、ファイル サイズの制限などに関して、個人的な経験を通じて比較を聞きたいです。)
インターネット経由でファイルを転送する場合、それぞれの利点 (または制限) は何ですか?
(私は両方のプロトコルの安全な形式を認識しています。パフォーマンス、信頼性、ファイル サイズの制限などに関して、個人的な経験を通じて比較を聞きたいです。)
両者の性能比較はこちら。HTTP は小さなファイルの要求応答に対してより応答性が高くなりますが、適切に調整されていれば、大きなファイルに対しては FTP の方が優れている場合があります。FTP は、一般的に高速であると考えられていました。FTP では、TCP 状態以外に制御チャネルと状態を維持する必要がありますが、HTTP では必要ありません。FTP ではデータの転送が開始されるまでに 6 つのパケット転送がありますが、HTTP では 4 つだけです。
適切に調整された TCP レイヤーは、アプリケーション レイヤー プロトコル間の違いよりも速度に大きな影響を与えると思います。Sun Blueprint Understanding Tuning TCPに詳細があります。
各プロトコルの個々の特性の別の良い比較を次に示します。
FTP と HTTP の両方を介したファイル転送のベンチマークを行いました。
結果:
fdm
): 1 分したがって、基本的に「実生活」の状況では:
1) 1 つの大きなファイルをダウンロードする場合、HTTP は FTP よりも高速です。
2) HTTP は並列チャンク ダウンロードを使用できるため、ネットワークの状態によっては FTP の 6 倍の速度になります。
多くのファイアウォールは、ポート 80 または 443 (http および https) 以外へのアウトバウンド接続をドロップします。HTTP(S) ではないポートへの接続をドロップするものさえあります。アクティブ/PASVモードは言うまでもなく、FTPは許可される場合と許可されない場合があります。
また、HTTP/1.1 では、より優れた部分リクエスト (「バイト 123456 からファイルの最後までのみ送信」)、条件付きリクエストとキャッシング (「コンテンツが変更された場合/最終変更日が変更された場合にのみ送信」)、およびコンテンツ圧縮が可能です。 (gzip)。
HTTP は、プロキシ経由で使用する方がはるかに簡単です。
私の事例証拠から、HTTP は切断された/遅い/不安定な接続で動作する方が簡単です。たとえば、転送を (再) 開始する前にログイン セッションを (再) 確立する必要はありません。
OTOH、HTTP はステートレスであるため、認証を行い、「誰がいつ何をしたか」の証跡を自分で作成する必要があります。
私が気づいた速度の唯一の違いは、多数の小さなファイルを転送することです。パイプラインを使用した HTTP の方が高速です (ラウンドトリップが減少し、特に高遅延ネットワークで顕著になります)。
HTTP/2はさらに多くの最適化を提供しますが、FTP プロトコルは何十年も更新されていないことに注意してください(さらに、FTP の拡張機能でさえ、ユーザーによる利用はわずかです)。したがって、タイム マシンを介してファイルを転送する場合を除き、HTTP が勝ったようです。
(接線的に: や BitTorrent など、ファイル転送により適したプロトコルがありますrsync
が、HTTP は Everywhere™ であるのに対し、それらはそれほど多くのマインドシェアを持っていません)。
1 つの考慮事項は、FTP が非標準のポートを使用する可能性があることです。これにより、ファイアウォールの通過が困難になる可能性があります (特に SSL を使用している場合)。通常、HTTP は既知のポート上にあるため、これが問題になることはめったにありません。
FTP を使用することに決めた場合は、必ずActive FTP と Passive FTPについて読んでください。
パフォーマンスに関しては、結局のところ、どちらも TCP 接続でファイルを直接吐き出しているため、ほぼ同じになるはずです。
どちらもトランスポート プロトコルとして TCP を使用しますが、HTTP は永続的な接続を使用するため、TCP のパフォーマンスが向上します。