TCPで「1メッセージ」を区切る ― length prefixをlocalhostで試す

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。RFC 9293と.NET Socket APIを確認し、TCP byte streamへ長さ情報を付ける考え方をlocalhostで観察できる形に整理しています。

検証ステータス：📘 RFC・.NET公式仕様確認済み・実機未確認

TCPにはアプリのメッセージ境界がありません。そこで本文の前に「次は何byteか」を置くlength prefixを最小データで体験します。

まず試す

$msg='HELLO'
$body=[Text.Encoding]::UTF8.GetBytes($msg)
$prefix=[BitConverter]::GetBytes([Net.IPAddress]::HostToNetworkOrder($body.Length))
"prefix=$([BitConverter]::ToString($prefix)) body=$msg"
$len=[Net.IPAddress]::NetworkToHostOrder([BitConverter]::ToInt32($prefix,0))
"receiver expects $len bytes"

ここを見る

受信側は本文を読む前に5 bytesと知れます。SendやReadの回数ではなく、アプリ自身が境界を定義するのがポイントです。

1か所変えてみる

HELLOをこんにちはへ変更し、文字数ではなくUTF-8のbyte数がprefixになることを確認します。

なぜそうなる

TCPが保証するのは順序付きbyte streamです。固定長、区切り文字、length prefixなどのframingは上位プロトコル側の責任です。

graph LR
L[4-byte length] --> B[payload bytes]
B --> R[receiver reads exactly length]

仕事で使うなら

実装ではprefix自体が分割受信される場合も考え、「4byte揃うまで読む」「宣言長ぶん揃うまで読む」が必要です。巨大な宣言長を無条件に確保せず上限も設けます。

RFC 9293: https://www.rfc-editor.org/rfc/rfc9293

Microsoft NetworkStream.Read: https://learn.microsoft.com/dotnet/api/system.net.sockets.networkstream.read