tcp - TCPのチェックサム

Question

TCPは、転送中に損失などが発生したときに必要になる可能性のあることを実行することによって、ストリームがネットワークを介して無傷で送信されることを確認する責任を負いませんか？

それはそれの適切な仕事をしませんか？

上位のアプリケーション層プロトコルとそのア​​プリケーションが引き続きチェックサムを実行するのはなぜですか？

Answer 1

TCPには独自のチェックサムが含まれていますが、これは16ビットのチェックサムにすぎず、マルチビットの伝送エラーがTCPチェックサムメカニズムによってスリップする可能性は確かにあります。これは非常にまれですが、それでも可能であり、実際にそれが発生するのを見てきました（20年に1回または2回）。

堅牢なプロトコルでは、送信データの整合性を確保するために、より高レベルのハッシュ関数を使用する必要があります。そうは言っても、少量のデータを送信するアプリケーションの多くはこの問題に直面しません。一括転送アプリケーション（パッケージマネージャーや自動更新メカニズムなど）は通常、暗号化ハッシュ関数を使用してデータの整合性の保証を強化します。

Answer 2

TCP は、チェックサムを使用して送信中に発生したエラーをトラップし、必要に応じて失われたパケットや破損したパケットを再送信することで、TCP パケットが確実に配信されるようにします。パケットが送信されると、ピア ホストが受信を確認するまで再送信キューに保持されます。特定のタイムアウト期間内に確認応答が受信されない場合、パケットは再送信されます。しかし、ホストは永遠にパケットを再送信し続けるわけではありません。パケットが繰り返し失敗すると、TCP は最終的にあきらめて接続を閉じます。

高レベルのプロトコルは、TCP が確実に機能することを前提としており (公正な仮定)、独自のチェックサムなどを使用して、高レベルのデータ ストリームが安全に到着したことを確認します。私は、独自の高レベル バッファを台無しにし、アプリケーション データ ストリームを台無しにするバグのあるソケット アプリケーションをたくさん書いてきました。

堅牢なアプリケーションを備えた製品グレードの TCP/IP スタックでは、問題は接続がドロップアウトしていることだと確信できると思います。または、バグのあるアプリケーションを使用している可能性がありますが、fetch/wget にバグがあるとは思えません。