FTPは純粋なTCP接続プロトコルであるため、TCPファイル転送オプションを検討するときにAFAIKは「できるだけ早く」取得します。FTPよりも速いファイル転送
しかし、TCP経由で動作しない他の製品もあります。たとえば、BI.DAN-GUN、faspおよびFileCatalystの商品があります。後者の製品はproblems with pure TCPを指摘しています。もう1つはWikipediaでもっと読むことができます。 Network Congestionから開始します。
その他の代替手段はありますか？ ..特にオープンソースのもの？また、これはソートのRFCであるべきだと思うでしょう - 標準 UDP上でおそらく実行しているlargeish-file-transfer-specificプロトコル。そのような議定書またはイニシアチブを知っている人は誰ですか？ （Google SPDYは面白いですが、高速ファイル転送には直接対処しません）
UDP経由のファイル転送に取り組んでいる多くのオープンソースプロジェクトがあります。 UFTP、津波またはUDTを見てください。それぞれのプロジェクトは異なる開発段階にあります。
各プロジェクトでは、帯域幅と作業中のポケット・ロスによって、それぞれのプロジェクトによって異なる結果が生成されます。 3つのプロジェクトを比較しようとするブログ記事があります。http://www.filecatalyst.com/open-source-fast-file-transfers
なぜTCPを使用すると転送が遅くなると思いますか？ TCPは通常、利用可能なすべての帯域幅を使用できます。代わりにUDPを使用する方が速くなる可能性は低いです。実際、信頼できるUDPベースのファイル転送をしようとすると、信頼性を自分で実装する必要があるため、TCPの劣った代替手段を実装する可能性があります。
はです。FTPの問題は、転送するすべてのファイルに対して複数の同期要求応答コマンドを実行し、すべてのファイルに対して新しいデータ接続を開くことです。大量の小さなファイルが転送されると、実際にデータを転送するのではなく、要求/応答の待機やデータ接続の確立に多くの時間が費やされるため、非常に非効率な転送になります。
この問題を回避する簡単な方法は、ファイル/フォルダをアーカイブにまとめることです。もちろん、アーカイブを作成したり、FTPなどで送信したり、反対側で解凍したりすることもできますが、パッキングとアンパックに費やされる時間は許容できません。オンラインで梱包や開梱を行うことで、この遅延を回避することができます。私はそのようなオンラインパッキング/アンパックを統合するソフトウェアは認識していません。あなたは、しかし、単に（Cygwinを使用するWindows上でLinux、）パイプラインでncとtarプログラムを使用することができます受信機に
最初の実行：
nc -l -p 7000 | tar x -C <destination_folder>
これは、受信機が接続を待つようになります
cd /some/folder
tar c ./* | nc -q0 <ip_address_of_receiver>:7000
これで、送信者が受信者に接続し、転送が開始されます。送信者はtarアーカイブを作成し、それを受信者に送信します。受信者はこれをすべて同時に抽出します。必要に応じて、（受信者を送信者に接続させることによって）送信者と受信者の役割を入れ替えることができます。
このオンラインタールアプローチには、FTPのパフォーマンス上の2つの問題はありません。要求応答コマンドを実行せず、単一のTCP接続のみを使用します。
ただし、これは安全ではありません。私たちの送信者が自分のtarアーカイブを送る前に誰でも受信機に接続することができます。これが問題であれば、適切なファイアウォールルールと組み合わせてVPNを使用できます。
EDIT：TCPパフォーマンスの問題としてパケット損失が報告されました。これは、FileCatalystページを信じることが重要な問題です。TCPが高いパケットロスリンクで非最適に実行できることは事実です。これは、TCPは通常、パケット損失に積極的に反応します。なぜなら、損失は輻輳によるものだと仮定しているためです。 Additive_increase/multiplicative_decreaseを参照してください。私はカスタムプロトコルでこれを克服しようとするフリー/オープンソースのファイル転送プログラムは認識していません。あなたは別のTCP congestion avoidance algorithmsを試してみてください。具体的には、Vegasを試してください。ではなく、はパケット損失を伝送速度を低下させる信号として使用します。
UDPベースのファイル転送を検討すると、AFTP（Accelerated File Transfer Protocol）という独自のプロトコルを実装したJSCAPE MFT Serverがあります。このリンクを確認してください：
http://www.jscape.com/blog/bid/80668/UDP-File-Transfer-up-to-100x-Faster-than-TCP
JSCAPEのAFTPは、ネットワークの遅延を持つ長距離接続を介して最適に動作することを覚えておいてください。ネットワークの待ち時間がない場合、AFTPは通常の通常のFTP（over TCP）よりも優れたパフォーマンスを発揮しません。
はい私はJSCAPE LLCで働いています。
オープンソースではありませんが、Asperaの転送速度はチェックアウトする価値があり、パケット損失やネットワーク遅延の影響を受けません。 You can see a chart here。 また、faspという独自のプロトコルも使用しています。
私は含まれているリンクをチェックしましたか？転送する500GBのファイルがある場合、FTPの制御接続はまったく無視できます。結局のところ、未加工のTCPパフォーマンスです。これは、大容量のファイルをできるだけ速く転送するために必ずしも調整されているわけではありません。特に、パケット損失のあるリンクを超えたものではありません。私が組み込んだリンクの製品は、明らかに信頼性を実装しています。 – stolsvik
@stolsvikあなたはインターネットでまれなAFAIKである高損失リンクは言及していません。私はそれについて何かを加えました。 –
実際、TCPプロトコルは実際には一方向のバルク転送用に設計されていません。確かにそれを行うことができますが、TCPは、短いストールを引き起こすような方法で戻りパケットを必要とし、本当に最適な速度のためにバッファサイズとウィンドウサイズを選択するバランスのとれた動作になる可能性があります。また、実装では、さまざまなオプション設定で実際に想定されていることを常に行うとは限りません。 –