TCPヘッダにはデータ長のフィールドはありませんが、UDPヘッダには存在すると思います。なぜTCPにはなく、UDPにはあるのでしょうか？

まず、TCPは、所謂バイトストリーム・サービスです。

telnetの様に、ユーザの入力を逐次送信していくことも可能で、コネクション開始時にトータルのデータサイズは決まっていません。ですので、そういう意味でのデータ長をヘッダに含めることは出来ません。

データは適宜IPパケットに分割されて送られ、そのサイズはそれぞれのIPヘッダにあります。TCPとしてはACKを送り合うことで、どこまで受け取っているかを交換し合い、FINを送り合う事で通信の終了を通知し合います。

つぎに、UDPの方ですが、こちらはなぜヘッダにデータ長が含まれているか、実際の所分かりません。

UDPは、所謂データグラム・サービスで、ある一塊のデータは一つのデータグラムとして、基本的には一つのパケットとして送出されます。

したがって、UDPを送る際にはデータサイズが既に決まっており、UDPヘッダにデータ長を書き込むことは可能です。しかし、IPヘッダにもデータ長はあり、そこから算出は可能です。フラグメント化により複数パケットに分割されることもありえますが、その際も、全てのパケットが揃えば算出可能です（揃わなければ破棄されるので必要ありません）。

手元に「詳解 TCP/IP」のVol.1があるのですが、それにも「このUDPデータ長は冗長である」と書かれています。

UDPはRFC 768に仕様がありますが、そこでも言及されていません。

そのため、なぜデータ長を含めたのかは分かりませんが、可能性として、

• 下位レイヤにIP以外を使用する
• 一つのIPパケットに複数のUDP(もしくは別のプロトコル)を相乗りさせる

といった将来の拡張の可能性を考慮したとか、

• ヘッダ長を４オクテットの倍数にするのに2オクテット残っていたので
• チェックサムと対的な感じがするからついでに

とか、もしかしたらあるのかもしれません。

ヘッダ長とか、そういうのに４オクテットの倍数が多いのは、VAXとか32bit機があったとおもうので、念のため最小公倍数的なアライメントを考えたのかもしれません。

もしかしたら

• なにもかんがえずに

と言うのもあるかもしれませんが。

元々、IPヘッダにもパケット長を示すフィールドがあります。

そこからIPヘッダとTCPヘッダのサイズを引くとデータサイズを求められます。

TCPヘッダサイズだけであれば、データ長に16ビット必要な所が、4ビットで済み、情報をそれほど増やさずにすみます。そのため、TCPにはデータ長が存在しません。

それに対し、UDPはリアルタイム処理向けのプロトコルなので、

低速なシステムでも計算に時間をかけなくとも済むようにヘッダにデータ長が含まれています。