時々、ftp を介して (特に大きな) ファイルをダウンロードすると、エラーが発生します。それが、すべての主要なサイトがダウンロードとともに外部チェックサムを公開している理由の一部でもあると思います。
ftp が TCP を通過する場合、これはどのように可能でしょうか? TCP にはチェックサムが組み込まれており、データが破損して送信された場合にデータが再送信されます。
これは、TCP プロトコルの CRC の長さが短い (私が思うに 16 ビットか、またはそのようなもの) ためであり、衝突が頻繁に発生しているためであると主張することができます。しかし、1) これが真であるためには、CRC の衝突が存在する必要があるだけでなく、ランダムなネットワーク エラーによって、パケット内の CRC とパケット自体の両方が変更され、CRC が新しいパケットに対して有効になる必要があります。 . 16 bitCRC でも、そんな可能性はありますか? 2) たとえば、TCPIP も経由する Web のブラウジングでは、多くのエラーがないように見えます。
FTP は ASCII データと BINARY データを区別し、それに応じてデータ ストリームを変更できます。これが、破損した FTP ダウンロードで遭遇した最も一般的な理由です。(TCP チェックサムは変更されたデータで計算されるため、TCP レベルで問題が発生することはありません。)
次に多いのは、タイムアウトやその他のネットワーク エラーが原因で転送が途中で切れてしまうことだと思います。その場合、TCP チェックサムはローカルでは正しいですが、部分的にダウンロードされたファイルは破損しています。
FTP プロトコルは、外部ホストが予測できないポート番号で接続し直す可能性があるため、ファイアウォールにやや不向きですが、通常は、ダウンロードが破損するのではなく、何も転送できないという形で現れます。
ASCII と BINARY の問題以外に、FTP 接続が破損した転送の影響を受けやすくなる理由が思い浮かびません。それらはバイナリや圧縮ファイルのようなものであり、ビットごとに完全で正確である必要があり、そうでない場合は大きな醜いエラーメッセージが表示されるため、もっと気付くかもしれません. たとえば、広告ネットワークへの接続がタイムアウトしたために Web ページに表示されていない広告に気付く可能性ははるかに低くなります。
16 ビットのチェックサムは、特にソフトウェアのダウンロードなどの FTP 転送のサイズを考慮すると、驚くほど強力ではありません。ただし、下位層にはそれを補う CRC などがあります。
私自身、今世紀中に破損した FTP ダウンロードがあったとは思いません。