アプリケーションプロトコルのフレーミング

受信側が、受け取ったバイト列のどこからどこまでが1メッセージなのかを判断する、アプリケーションプロトコル側の仕組みである。

概念URI

https://comcomponent.com/knowledge/application-framing/

別名・表記

フレーミング / メッセージ境界の決定

最終確認日

2026-08-01

機械可読データ

JSON-LD

この概念が関わる関係

• アプリケーションプロトコルのフレーミングは送信区切りと受信区切りのずれ(分割・結合)を防ぎます。受信側でメッセージ境界を判断する仕組み(フレーミング)を設ければ、分割・結合によるメッセージ境界のずれに正しく対応できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 固定長方式はアプリケーションプロトコルのフレーミングの実装を担います。固定長方式は、常に決まったバイト数を1メッセージとすることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 区切り文字方式はアプリケーションプロトコルのフレーミングの実装を担います。区切り文字方式は、改行など特定のバイト列までを1メッセージとすることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 長さプレフィックス方式はアプリケーションプロトコルのフレーミングの実装を担います。長さプレフィックス方式は、先頭に本文長を置きそのバイト数だけ本文を読むことでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 自己記述形式はアプリケーションプロトコルのフレーミングの実装を担います。自己記述形式は、HTTPのContent-Lengthのように形式内に長さや終端の情報を持たせることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Nagleアルゴリズム(Socket.NoDelay)をアプリケーションプロトコルのフレーミングに用いることは推奨されません。Socket.NoDelay(Nagleアルゴリズムの無効化)は送信の遅延・効率の調整であり、メッセージ境界を保存する設定ではないため、フレーミングの代わりにはならない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• NetworkStream.DataAvailableをアプリケーションプロトコルのフレーミングに用いることは推奨されません。DataAvailableはその瞬間にローカル受信バッファに読み取り可能なデータがあるかを示すだけで、アプリケーション上の1メッセージが完了したことを意味しない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TLSレコードをアプリケーションプロトコルのフレーミングに用いることは推奨されません。TLSレコードは内部的な伝送単位であり、アプリケーションメッセージの境界ではないため、TLS化してもアプリケーション層でのフレーミング設計は必要になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典

この概念を扱う記事

• TCPでSendした単位ごとにReceiveできるという誤解 ── バイトストリームとして扱うための受信設計(主要トピック)

一次資料

• https://www.rfc-editor.org/rfc/rfc9293.html

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。