TCP環境下でのファイル破損は起こるのか？

質問

ふと思った事なのですが、フリーソフト等ダウンロードをＦＴＰで行った際、たまに「ファイルが破損」しています。
といったエラーになる場合があります。

再ダウンロードするとうまく動く（解凍できたり）のです。

そこで質問なんですが、
ＦＴＰはＴＣＰを使用していると思っています。
ＴＣＰというと参考書などには「再送制御？」なるものがあり、
確実なファイル転送がおこなえるような記述がなされています。

ＴＣＰ環境下でビットの欠落が起こるえるんでしょうか？

よろしくお願いします。

回答No.4

chie65536 · ベストアンサー

大事な事が抜けていました。

「確実なパケット転送」の意味ですが、これは「送ろうとしたパケットが確実に相手に転送される」と言う意味ではありません。そんな保証はどこにもありませんし誰も保証してくれません。

「確実なパケット転送」の本当の意味は「転送を試みた後に『転送成功』と言われたパケットは、パケットの内容が元と違ってたり化けてたり欠落していたりせずデータが正しいのは保証する。だが『転送失敗』と言った場合は『失敗したのは保証する』けども、その他は一切保証しない。データの中身もどうなってるか判らない」と言う意味です。

つまり「転送を試みたら失敗と言われた」とか「転送を試みたらいつまで経っても転送が終らず、結果待ちしてるうちに接続が切れる」と言う事もある、と言う事です。

これもやっぱり「TCPエラーやTCPタイムアウトに対してソフトウェアがどういう挙動を取るか」の問題になります。

補足

回答ありがとうございます。

ダウンローダーは「正常終了」になっています。
ということは

・パケットはきちんと送られているが、パケットを結合するクライアントソフト側に問題がある。
・パケットの転送失敗とＴＣＰではなっているが、クライアントソフトがエラーをスルーしてしまう？などクライアントソフトの仕様に問題がある。

ということでよろしいのでしょうか。

回答No.6

a-saitoh

FTPにはいくつかの転送モードがありますが、一番使われているのは、ファイルをそのままTCPで送り、TCP接続を閉じることによってファイル末を示すというものです。
この場合、何らかのトラブルでデータ転送のTCP接続が途中終了してしまった場合と最後まで転送し終わって接続をクローズした場合とが区別できない事があります。結果として、正常終了したのに尻切れトンボのファイルがクライアント側に残る、と思います。
詳しくはFTPのRFCを読んでください。

回答No.5

noname#56568

ブラウザでのFTP転送に失敗しているのなら、始めからそう書いた方がよくありませんか？
またブラウザ搭載のダウンローダー？なら、そのダウンローダー名とバージョンも必要でしょう。

サーバー上にあるファイルは破損していない事が大前提ですが、その確認はとれていますか？
UDPで転送しているのなら兎も角、TCPで転送しているのに破損してしまうのはchie65536さんが書いたように、ソフトウェアが起因している可能性大です。

普通のブラウザでFTP接続してDLしてみましたか？

補足

ブラウザ搭載以外にも専用ソフトでも経験しています。

回答No.3

chie65536

問題の切り分けが出来ていません。

FTPは「ファイルのアップロードやダウンロードが途中で中断され完了しないで終り、転送先に尻切れになったファイルが作られる事もある」と言う前提で設計されています。

その為、一部のFTPサーバーには「中断した転送を再開するオプション」があります。

あくまでも、これは「FTPのプロトコルがそういう風に設計されている」のが原因で、TCPとかは無関係の話です。

TCPが保証しているのは「確実なファイル転送」ではなくて「確実なパケット転送」な筈です。

もちろん、パケットのビット欠落が起きればちゃんと再送制御が行われますし、接続が切れない限りは相手に「パケットが」確実に届きます。

ですので、FTPサーバーソフトやFTPクライアントソフトがファイルを幾つものパケットに分割して転送する際、１つ１つのパケットがパケット単位で確実に転送されるのがTCPにより保証されます。

しかし、全部のパケットが全部キッチリ正しい順番で転送されるかどうかは、TCPにとっては「俺はそんなの知ったこっちゃない。俺にパケット転送依頼してる上位のソフトウェアに文句言え」なのです。

「全部のパケットが全部キッチリ転送されて、転送されたパケットが正しい順番になって、ローカルディスクにちゃんとセーブされて、正しいファイル名が付く」かどうかは、FTPサーバーソフトとFTPクライアントソフトが保証すべき問題であり、ストレートに言えば「ソフトウェアの問題」です。

回答No.2

noname#56568

TCP接続を行っていたとしても、パケットの欠落はありますよ。
TCPプロトコルはデータの抜けや重複、送信側で送ったデータがそのままの順序で正しく受信側へ届くという“信頼性”があるだけで“完全”ではありません。

確かに送信側から受信側へ正しく届かなかった場合は再送する事になっていますが、その再送もうまくいかず結果的に破損した状態になってしまう事があります。

結局はネットワークの状態に因るところが大きいです。

お礼

回答ありがとうございます。

ブラウザ搭載のダウンローダによりおこなっていますが、
「正常終了」しているのに「ファイル破損」状態になってしまいます。
これは「正常終了」とするクライアントソフト側の問題であり、ＴＣＰ側は転送エラーのようなものを出力して終わり。
というイメージでよろしいでしょうか。

回答No.1

cocodoco5656

いくつ物要因がありますが
よくある要因のひとつとして
ファイルをDL中になんらかの理由で
タイムアウトを起こしたとします。
(回線の混雑だったりサーバがこけたり
いろいろな要因で)
そのようなファイルは壊れたファイルになりますよね。

補足

回答ありがとうございます。

ファイルは正常終了で生成されている（例えばlzh）が、
解凍するとファイル破損になる。
という状況なのですが

回答者様が言われている「タイムアウト」は
「パケット一つ一つ」の「タイムアウト」ということでよろしいでしょうか。

他回答者さまのをみると、その場合、タイムアウトと表示するのはクライアントソフト次第ということでしょうか。