ファイルをダウンロードするときにチェックサムを比較するのが良い習慣なのはなぜですか？

ダウンロード用のISOファイルを提供するWebサイトは、それらのファイルのmd5チェックサムを頻繁に提供します。このチェックサムを使用して、ファイルが正しくダウンロードされ、破損していないことを確認できます。

なぜこれが必要なのですか？TCPのエラー修正プロパティで十分です。パケットが正しく受信されない場合、再送信されます。TCP / IP接続の性質そのものがデータの整合性を保証しないのですか？

他の人が指摘しているように、送信側でチェックサムが計算される前に破損がすでに発生している場合、ストリームをインターセプトおよび変更するMITMなど、トランスポート層でのチェックサムが役に立たないデータ破損の可能性が多くありますチェックサムとして）、受信側でチェックサムを検証した後に破損が発生するなど。

これらの他のすべての可能性を無視し、TCPチェックサム自体の詳細と、データの整合性の検証に関して実際に行うことに焦点を当てると、このチェックサムのプロパティは、エラーの検出という点ではまったく包括的ではないことがわかります。このチェックサムアルゴリズムの選択方法は、速度（1970年代後半）と組み合わせた速度の要件を反映しています。

これは、TCPチェックサムの計算方法です。

チェックサム：16ビット

チェックサムフィールドは、ヘッダーとテキスト内のすべての16ビットワードの補数の合計の16ビットの補数です。セグメントにチェックサムされる奇数のヘッダーとテキストオクテットが含まれる場合、最後のオクテットの右側にゼロが埋め込まれ、チェックサム用の16ビットワードが形成されます。パッドはセグメントの一部として送信されません。チェックサムの計算中、チェックサムフィールド自体はゼロに置き換えられます。

これは、この方法でデータを合計するときにバランスをとる破損が検出されないことを意味します。これにより許可されるデータの破損には多くのカテゴリがありますが、単なる些細な例です。16ビットワードの順序を変更すると、常に検出されなくなります。

実際には、多くの典型的なエラーをキャッチしますが、完全性を保証するものではありません。また、ローカルリンクでの送信のみであるにもかかわらず、L2レイヤーが整合性チェック（例：イーサネットフレームのCRC32）を行う方法、および破損したデータの多くのケースがTCPスタックに渡されることもありません。

強力なハッシュ、またはできれば暗号署名を使用してデータを検証することは、データの整合性を確保するという点でまったく異なるレベルにあります。2つはほとんど比較することさえできません。

md5sumをチェックするべき理由はおそらく無数にありますが、いくつかは思い浮かびます：

• 悪意のあるアクティビティ-サーバーからの途中でISOが改ざんされている可能性があります
• ページ自体はスプーフィングされています（md5sumsにも署名するのが最善です:)）
• 壊れたダウンロード（TCPエラー訂正にもかかわらず）（チェックこのアウト）
• ISOが正しく焼き付けられていない

とにかく数秒しかかかりません。

TCP / IPはデータの整合性を保証します*。ただし、ファイルの100％がダウンロードされたことを保証するものではありません。これが起こる理由はたくさんあります。例：途中のどこかで1バイトまたは2バイトが欠落しているISOをマウントできる可能性があります。破損している1つまたは2つの特定のファイルが必要になるまで、問題はありません。チェックサムを比較することで、ファイル全体が本当にダウンロードされたことを確認できます。

*コメントを参照

TCPチェックサムは16ビットのみです。これは、他のチェックサムがない場合、65536個の破損パケットごとに1個が非破損として受け入れられることを意味します。たとえば、破損率1％でノイズの多いリンクを介して8GBのDVDイメージをダウンロードした場合、81個の検出不能な破損パケットが予想されます。

MD5は、128ビットの非常に大きなチェックサムです。オリジナルと同じチェックサムを持つ何かを生成するこれらの81パケットのオッズは、1,000,000,000,000,000,000,000,000,000,000,000分の1です。

HTTP経由でダウンロードしたファイルのチェックサムを検証する理由はいくつかあります。

• ファイル全体を受け取ったことを確認する
  • Firefoxなどの一部のクライアントは、中断された接続をダウンロードの成功として扱い、切り捨てられたファイルを残しますが、ダウンロードは正常であると主張する場合があります
• 正しいファイルを受け取ったことを確認する
  • たとえば、バグのあるサーバー、侵害されたサーバー、または悪意のあるサーバーが何か他のものを送信する可能性があります
  • 誰かが転送を改ざんする可能性があります（man-in-the-middle攻撃）-たとえば、システムがSuperfishによって危険にさらされたり、使用されている暗号化方式が弱い場合、HTTPSでも安全ではありません。
  • また、偽のダウンロードページが表示されるだけなので、実サーバーに接続することすらできません（ただし、この場合、同じ偽サーバーからチェックサムを取得しても、チェックサムはあまり役に立ちません）。
  • 多くのISPが、さまざまな理由でJavascriptを送信中のページに挿入していることがわかっています¹。これがどれだけうまく実装されているかに応じて、いくつかのファイルのダウンロードも混乱させる可能性があります
  • ミラーが古いバージョンのファイルをホストしているか、管理者が間違ったファイルをアップロードした可能性があります
• TCPが検出できないものによってファイルが破損していないことを確認する
  • たとえば、ファイルがサーバー上で破損している可能性があるため、TCPは、既に破損しているファイルが送信中にさらに破壊されないようにするだけです。
  • または、障害のあるメモリ/ディスク、バグのあるファイルシステムドライバなどによって、あなたの側に到着した後に破損する可能性があります
  • TCPチェックサムは16ビットのみであるため、破損したパケットが検出されない可能性は天文学的なものではありません（65536に1つ）
• ISOを使用して、ディスクが正しく書き込まれたことを確認する

^1件のコメントソース

ダニエル、ISOダウンロードに使用しているツールによって異なります。Firefoxの場合：ファイルのダウンロードが表示される場合があります。ただし、完全なISOをそのまま保持していない場合があります。焼き付けてから使用しようとすると、情報が失われる可能性があります。これは、ファイルをホストするさまざまなWebサーバーで時々発生します。

少なくともファイルサイズ（合計バイトまたはビット）を比較して、それらが一致することを確認することをお勧めします。Windowsでは、ファイルのバイトカウントがLinuxとは異なります。MD5サムチェックでは、使用されているOSに関係なく同じ値が表示されます。これが少し役立つことを願っています。乾杯...

私は多くの興味深い答えに気づきましたが、最後に考慮すべきことがあります。2人の将軍の問題

2つの将軍の問題とビザンチン将軍の問題は、信頼できないチャネルを介して情報を確実に転送することの意味を特に考慮します。

チェックサムは、「信頼性の向上」の別のレイヤーにすぎず、障害が発生する可能性が非常に低いレイヤーです。これがとても人気がある理由です。