まず、これがやや単純な質問であると思われる場合はお詫び申し上げます。
によるとこの答えTCPパケットが破損しているいつもチェックサムで捕捉されない。
これが頻繁に起こるのに、なぜもっと目立たないのでしょうか? これによって、画像が破損したり、スクリプト ファイルに間違った ASCII 文字が含まれるようになるのではないですか?
もちろん、重要なファイルでは md5 チェックサムを実行する傾向がありますが、平均的な日常的なネットワーク アプリケーションでは、なぜこれが思ったよりも大きな混乱を引き起こさないのでしょうか? (実際には起こっていないように見えますが、その回答の統計とロジックは正しいです)
答え1
こんなことが頻繁に起こるとしたら…
そうではありませんし、あなたが参照している回答もそうであると主張していません。」頻繁「多数のパケットが破損していることを意味する」相対的転送されたパケットの絶対数に関係しています。しかし、これは事実ではありません。あなたが参照している回答では、多くのパケットが破損している場合、破損は依然としてレアと比較して絶対転送されたパッケージの数。
それ以外にも、TCP 上に追加の保護が存在する場合があります。たとえば、TLS (HTTPS で使用) は、データ操作の検出に使用される HMAC が TCP で使用される単純な CRC よりもはるかに堅牢であるため (ただし、オーバーヘッドも大きくなります)、事実上すべてのデータ破損を検出します。この段階で問題を検出しても、TCP チェックサム エラーの場合のようにデータの再送信は行われませんが、接続が切断されたと単純に判断されるため、日常的に発生する接続切断による他の多くのエラーと区別がつきません。同様に、画像形式の仕組みにより、画像内の破損したデータは通常、実質的に目に見えないか、画像全体が破損する (レンダリングに失敗するか、途中で切れる) かのいずれかになり、これも一般的な接続の問題に似ています。
答え2
あなたが説明しているのは、サンプリング バイアスです。TCP の使用時に個人的に破損の問題に気付いたことがないからといって、それが常に発生しないというわけではありません。常に発生します。リンク先の回答は、この問題に関してかなり完全です。