TCPまたはUDPの観点から、パケットにはIPアドレスが含まれていません（IPはその下のレイヤーです）。
したがって、適切なチェックサムを実行するために、「疑似ヘッダー」が含まれています。これは、UDPデータグラムの実際の部分ではないため、「疑似」です。これには、IPヘッダーの最も重要な部分、つまり、送信元アドレスと宛先アドレス、プロトコル番号、およびデータ長が含まれています。
これは、UDPチェックサムがこれらのフィールドを確実に考慮に入れるためです。
「馬の口からまっすぐに」という答えに最も近いのは、次のリンクのDavid P.Reedからです。
http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html
答えの短いバージョンは、「疑似ヘッダーは歴史的な理由で存在します」です。
もともと、TCP/IPは単一のモノリシックプロトコル（単にTCPと呼ばれる）でした。彼らがそれをTCPとIP（およびその他）に分割することを決定したとき、彼らは2つをそれほどきれいに分離しませんでした：IPアドレスはまだTCPの一部として考えられていましたが、彼らはTCPヘッダーで繰り返されるのではなく、IP層から「継承」されただけです。TCPチェックサムがIPヘッダーの一部（を含む）で動作する理由IPアドレス）は、暗号化を使用してTCPペイロードを暗号化および認証することを意図しており、疑似でIPアドレスおよびその他のTCPパラメーターが必要だったためです。ヘッダーは認証コードで保護されます。これにより、途中の男性がIPの送信元アドレスと宛先アドレスを改ざんすることは不可能になります。中間ルーターは改ざんに気づきませんが、TCP =エンドポイントは、署名を検証しようとしたときのことです。
さまざまな理由で、その壮大な暗号化計画はいずれも成立しませんでしたが、代わりに行われたTCPチェックサムは、それが実行するのに役立つかのように、疑似ヘッダー上で動作します。はい、それはランダムエラーに対する保護が少し強化されますが、それが存在する理由ではありません。率直に言って、それがない方がよいでしょう。TCPとIPの間の結合は、 IPを変更するとTCP）が再定義されます。したがって、IPv6の定義には、TCPおよびUDP疑似ヘッダーの新しい定義が含まれます（RFC 2460、s8.1を参照）。 ）IPv6設計者が、この結合を廃止するのではなく、永続化することを選択した理由は、私を超えています。
「疑似ヘッダーを使用する目的は、UDPデータグラムが正しい宛先に到達したことを確認することです。疑似ヘッダーを理解するための鍵は、正しい宛先が特定のマシンとそのマシン内の特定のプロトコルポートで構成されていることを理解することにあります。 。UDPヘッダー自体はプロトコルポート番号のみを指定します。したがって、宛先を確認するために、送信側マシンのUDPは、宛先IPアドレスとUDPデータグラムをカバーするチェックサムを計算します。疑似ヘッダーはUDPで送信されません。データグラムも、長さにも含まれていません。」
E. Comer-TCP/IP第4版を使用したインターネットワーキング。
これらのプロトコルが設計されていたとき、彼らの深刻な懸念は、そうでないときにそれが彼らのものであると考えてパケットを受信するホストでした。転送中にIPヘッダーで数ビットが反転し、パケットのコースが変更された場合（ただし、IPチェックサムはまだ正しい）、リダイレクトされた受信者のTCP/UDPスタックはパケットを拒否することを認識できます。
疑似ヘッダーは層の分離のイディオムを破りましたが、信頼性の向上には許容できると見なされました。
疑似IPヘッダーには、送信元IP、宛先IP、プロトコル、および全長フィールドが含まれます。現在、これらのフィールドをTCPチェックサムに含めることで、ネットワーク層とトランスポート層の両方でこれらのフィールドのチェックサムを検証し、データが正しい場所に配信されていることを確認するためにダブルチェックを実行しています。ホスト。