TCPはエンドツーエンド接続、つまりホスト間が直接通信することを想定して設計されました。確かにその間にはブリッジやルーターが存在しましたが、それらのデバイスはTCPヘッダーやペイロードには触れませんでした。しかし、現在では状況が異なります。 現在では、ネットワークアドレス変換装置（NAT）、ファイアウォール、侵入防止システム（IPS）、ネットワークアクセラレータなどが存在します。これらはいずれもTCPヘッダーを改変したり、確認応答やリセットを送信したり、あるいは単にパケットを破棄したりする可能性があります。さらに厄介なことに、これらの装置はネットワークの両端に配置されるだけでなく、時には中間にも設置されるのです。
ネットワークB上のホストAがネットワークZ上のホストYと接続しているケースを想定してください。ネットワークBの前段にはWANアクセラレータが配置されており、ホストYからの確認応答を偽装することでスループットを向上させます。これによりホストAは可能な限り高速でデータを送信できます。バッファリングと再送信はすべてアクセラレータが処理します。 しかし残念ながら、ネットワークZの前に配置された侵入防止システムが、ホストAからの無害だが不審に見えるパケットを破棄している。ホストYはそのパケットを認識しないため、応答を送信しない。ネットワークBの前にあるWANアクセラレータは再送信を試みるが、当然ながらパケットは再び破棄される。アクセラレータは最終的にタイムアウトし、ホストAとホストYに対してリセットを送信する。
ホストAのシステム管理者は、ユーザーからの苦情を受けて何が起きているのかを調べようとしたとき、何を見るでしょうか？ホストAから送信されたパケットがホストYによって確認応答されるものの、ホストYからのアプリケーション層の応答がなく、その後ホストYが接続をリセットする様子を見ます。問題の兆候やホストYが接続をリセットした理由を示すものは何もありません。 ホストYのシステム管理者は何を見るか？ホストAがパケット送信を突然停止し、その後リセットを送信した様子を見る。ここでも、問題の発生やホストAが接続をリセットした理由を示すものは何もない。
ホストAがホストYと直接通信しているという前提は誤りであり、この前提が各管理者に接続障害の原因を相手側のシステムに帰する原因となっている。
何が起きているのかを把握するには、IPヘッダーのトレースデータにおいて「重要でない」フィールドの値に注目する必要があります。具体的には「サービス種別（Type of service）」、ID、フラグ、および「生存時間（Time to Live：TTL）」といったフィールドです。 これらのフィールドの変化（例：データを含むパケットのTTLが47であるのに対し、データを含まないパケットのTTLが127である場合）は、パケットが2つの異なる送信元から発信されていることを示唆します。
ホストAとホストYの両方のトレースを比較することで、問題点を明確に把握できます。一方のトレースにのみ存在するパケットを確認できるだけでなく、重要でないIPヘッダーフィールドやTCPポート番号、シーケンス番号の変化は、これらのホストが直接通信していないことを100%確実に示します。
ネットワークアクセラレータや侵入防止システムを無効化できない場合もある（また、無効化すべきでない場合もある）が、それらの存在と動作内容を把握しておくことで、問題発生時に状況を理解し修正する可能性が高まる。