TCP はエンド・ツー・エンドの接続、つまり、あるホストが別のホストと直接通信することをサポートするように設計されていました。確かに、その間にはブリッジやルータがありましたが、それらのデバイスはTCPヘッダやペイロードには触れていませんでした。しかし、現在はそうではありません。現在では、ネットワーク・アドレス・トランスレータ、ファイアウォール、侵入防止システム、ネットワーク・アクセラレータのようなものがあります。これらはすべて、TCPヘッダを変更したり、確認応答やリセットを送信したり、パケットをビットバケットに落としたりします。さらに悪いことに、これらのデバイスはネットワークの各端にあり、時には中間にもあります。
ネットワークB上のホストAがネットワークZ上のホストYに接続している場合を想像してみてください。ネットワークBの前には、ホストYからの謝辞を偽装することでスループットを向上させるWANアクセラレータがあります。バッファリングや再送の処理はすべてアクセラレータが行います。残念なことに、ネットワークZの前にある侵入防止システムは、ホストAから無実だが不審に見えるパケットを落としています。ネットワークBの前のWANアクセラレータは再送しますが、もちろんパケットは再びドロップされます。アクセラレータは最終的にタイムアウトし、ホストAとホストYに戻ってリセットを送信します。
ホストAのシステム管理者は、ユーザが苦情を言った後に何が起こっているのかを理解しようとするとき、何を見ますか?彼は、ホストAからのパケットがホストYによって確認され、ホストYからのアプリケーション層の応答がなく、ホストYが接続をリセットしているのを見ていますが、何か問題があるのか、なぜホストYが接続をリセットしたのかを示すものは何もありません。ホストYのシステム管理者は何を見ていますか？彼女は、ホストAがパケットの送信を停止し、リセットを送信したことを見ていますが、これも何の問題も、ホストAが接続をリセットした理由を示すものは何もありません。
ホストAがホストYと直接通信しているという仮定は誤りであり、その仮定をすることで、各管理者は接続失敗の原因を他のシステムのせいにしてしまうことになります。
何が起こっているのかを把握するためには、IPヘッダのトレースデータの中の"興味のない"フィールド、"サービスの種類"、ID、フラグ、"Time to Live" (TTL)のようなフィールドの値に注意を払う必要があります。これらのフィールドの変化、例えば、データのあるパケットはTTLが47で、データのないパケットはTTLが127であるなど、パケットが2つの異なるソースから発信されていることを伝えることができます。
ホスト A とホスト Y の両方のトレースを比較することで、問題にスポットライトを当てることができます。一方のトレースで他方のトレースにないパケットを見ることができるだけでなく、興味のないIPヘッダフィールドやTCPポートやシーケンス番号の変化は、これらのホストがお互いに直接通信していないことを100%の確信を持って示します。
ネットワークアクセラレータや侵入防止システムをオフにすることはできないかもしれませんが（それも良いアイデアではないかもしれません）、それらが存在し、何をしているのかを知ることで、問題が発生したときに問題を理解し、修正する機会を増やすことができます。