TCP上のチェックサム

Question

TCPは、転送中に損失などが発生するために必要なことを行うことによって、ストリーム上でストリームがそのまま送信されるようにする責任を負いませんか？

適切な仕事をしていませんか？

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

Answer 1

TCPには独自のチェックサムが含まれていますが、それは16ビットのチェックサムであり、マルチビット送信エラーがTCPチェックサムメカニズムによってスリップする可能性は確かです。これは非常にまれですが、まだ可能です（実際には数十年に一度か二度）。

強力なプロトコルは、送信データの整合性を保証するために、より高いレベルのハッシュ関数を使用することを望みます。だが、少量のデータを送信する多くのアプリケーションがこの問題に陥るわけではない。一括転送アプリケーション（パッケージマネージャや自動更新メカニズムなど）では、通常、暗号のハッシュ関数を使用してデータの整合性を保証します。

Answer 2

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

上位レベルのプロトコルでは、TCPが確実に動作し（公平な前提）、独自のチェックサムなどを使用して、上位レベルのデータストリームが安全に到着したことを確認します。私は自分のより高いレベルのバッファを壊し、アプリケーションデータストリームを混乱させたたくさんのバギーソケットアプリケーションを書いてきました！

堅牢なアプリケーションを使用しているプロダクショングレードのTCP/IPスタックでは、接続が切断されるという問題があると確信できると思います。または、バグのあるアプリケーションがあるかもしれませんが、フェッチ/ウィジェットがバグだとは思わないでしょう。