1. 序章

TCPは、ある種の信頼できるコネクション型データストリームを目標として持つように設計されました。 そうすることで、ベストエフォート型のIPプロトコル設計の制限のいくつかを克服できます。 その意味で、フローおよび輻輳制御、優先度フラグ付け、エラー検出、および回復があります。  また、必要に応じて、大きなパケットをフラグメントに分割することもできます。 この場合、フラグメントは宛先で再アセンブルされます。

したがって、TCPはある程度エラーを検出できるはずです。 それはどのようにそれをしますか？  そしてそれはどれほど効果的ですか？ 検出に失敗する可能性はありますか？ もしそうなら、どうすればそれを回避できますか？

このチュートリアルでは、これらの質問を調査し、TCP依存システムの堅牢性を向上させてエラー検出や訂正を改善する方法について説明します。

2. TCPパケットのチェックサム

次の表に、TCPパケットヘッダーを示します。 ご覧のとおり、というフィールドがありますチェックサム。 このフィールドは、 16ビットチェックサム。 1の補数を使用して計算されますの一部の IPヘッダー、TCPヘッダー （チェックサムフィールドはゼロであると想定されます）、およびパケットのペイロード。

1の補数を使用したチェックサムは、当時最も堅牢なエラー検出アルゴリズムではありませんでした。 ただし、の評価は非常に高速で、メモリのオーバーヘッドはほとんどありません。 インターネットプロトコルが最初の数日間、速度とメモリの複雑さが差し迫った問題でした。

     

受信エンドポイントがチェックサムの不一致を検出すると、受信したパケットを破棄します。 結果として、送信者はその確認応答を取得することはありません。 したがって、送信者はタイムアウト後にパケットの送信を再試行します。 これは、TCPのスリーウェイハンドシェイクの予想される動作です。 したがって、TCP / IPでのあらゆる種類のデータ損失と同様に、これによりデータフローに遅延とランダムな遅延が発生します。

3. 衝突

1の補数は、おそらく開発された最初の主要なハッシュアルゴリズムです。 ハッシュアルゴリズムを評価するときに生じる重要な概念の1つは、 衝突。 衝突は、2つの異なるオブジェクトがまったく同じハッシュコードに評価されるときに発生します 。 これは、ハッシュコードがエラー検出に使用される場合、またはオブジェクト表現を一意に識別する場合に特に有害です。

ハッシュに依存するアプリケーションでは、衝突は、システムが2つの異なる情報が同じであると誤解する可能性があることを意味します。 たとえば、パスワードは通常、ある種のハッシュとして保存されます。 そのコンテキストでは、衝突は、攻撃者が正確なパスワードを推測するだけでなく、同じハッシュコードに評価される他のバイトシーケンスを推測することによってもアクセスを取得する可能性があることを意味します。 そうすれば、ブルートフォース攻撃に必要な試行回数はやや少なくなる可能性があります。

いずれにせよ、TCPは16ビットのチェックサムを使用しますが、これは良いですか？ 実際、主なチェックサムの批判は、同じハッシュコードを生成するためのパケットの差が非常に小さいということです。 パケットの16の異なるビットの倍数は、同じチェックサムになります。 より堅牢なアルゴリズムでは、衝突を作成するためにかなり異なるパッケージが必要になります。

衝突の場合、変更されたビットがパケットヘッダーにあると、受信者はペイロードデータのぎこちない動作からデータをまったく受信しない動作に至る可能性があることに注意してください。 ただし、実際のリスクは、パケットが流れるインターネットルートの信頼性によって異なります。 ビットエラーレートが低く、高品質のリンクを使用すると、同じパケットで16ビットの倍数が誤って検出される可能性が低くなります。

4. アプリケーション層の回避策

4.1. エラー検出の改善

もちろん、エラーが検出されない可能性を少しでも残したくないアプリケーションもあります。 この場合、アプリケーション層メッセージにさらに堅牢なエラー検出を追加できます。 比較的高速で信頼性の高い巡回冗長検査– CRC32 アルゴリズム（たとえば、ZIPファイルで使用）を使用できます。 さらに、より高い保護を実現するために、SHA-256（一部の既知の暗号通貨で使用されているものと同じ）など、さらに強力なハッシュアルゴリズムを使用できます。

検出の堅牢性が高いほど、オーバーヘッドが大きくなり、遅延と計算能力が高くなります。 アプリケーション層でのCRC保護の非常に良い例の1つは、 HTTP圧縮アルゴリズム（RFC 7231で定義）です。 アプリケーションが独自の設計のアプリケーション層プロトコルを使用している場合、プレーンCRC 、 CRC保護データ圧縮、さらには暗号化ハッシュを追加することは難しくありません。コード。

ハッシュアルゴリズムを選択する際には、必要な保護を確保するためにどこまで進む必要があるかを決定する必要があります。 MD5 のように、かつては安全であると信じられていたアルゴリズムは、長い間クラックされてきました。 ターゲットハッシュコードと衝突するバイトシーケンスをすばやく作成できるツールがあります（hashcatおよびjohntheripperを参照）。

もう1つの方法は、 Stream Control Transmission Protocol – SCTP（RFC 4960で定義）を使用することです。 TCPを置き換えるように設計されており、CRC32ハッシュコードを使用したフォールトトレランスが向上しています。 ただし、その使用は誇大広告を満たしていません。 また、あまり一般的に使用されていないため、厳密な構成でファイアウォールで保護されたネットワークを通過する際に問題が発生する可能性があります。

4.2. エラー訂正の改善

さらに進んで、データに冗長性を追加することで、エラーを検出するだけでなく、前方誤り訂正と呼ばれる手法を使用して再送信せずに回復することもできます。 エラー訂正アルゴリズムは、必要な堅牢性、より堅牢で冗長なデータ、およびオーバーヘッドを任意に定義するように設計できるためです。

ちなみに、TCPで最も一般的なパケットエラーは、ネットワークカーネルサブシステムによるパケット破棄に確実につながります。 したがって、再送信を強制します。 再送信を一切回避するために、エラー検出メカニズムをより適切に制御できるトランスポートプロトコルを使用する必要があります。

たとえば、 UDP を使用して、オプションのチェックサムなしでアプリケーション上で直接パケットを作成できます。 最新のオペレーティングシステムは、デフォルトで、UDPのオプションの16ビットチェックサムフィールドを埋めるために必要になります。

5. 結論

このチュートリアルでは、実際、TCPでエラー検出が失敗する可能性が比較的低いことを確認しました。 ただし、ほとんどのアプリケーション層のプロトコルまたはファイルタイプはすでにセキュリティを強化しているため、一般的なシナリオでは、実際には問題になりません。

いずれにせよ、堅牢性の保証が必要な場合、または独自のミッションクリティカルなアプリケーションを設計している場合は、関連するオーバーヘッドに余裕があれば、あらゆる要件に合わせて信頼性を任意に向上させることができます。