知識マップ: TCPでSendした単位ごとにReceiveできるという誤解 ── バイトストリームとして扱うための受信設計

記事「TCPでSendした単位ごとにReceiveできるという誤解 ── バイトストリームとして扱うための受信設計」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

TCP通信で、送信側がSend/Writeした単位ごとに受信側でReceive/Readできるという思い込みが、分割・結合・文字化け・プロトコル破損を引き起こすことを扱う。TCPが運ぶのは順序付きのバイトストリームであり、メッセージ境界は保証されないため、受信側はアプリケーションプロトコルとしてフレーミング(固定長・区切り文字・長さプレフィックス・自己記述形式)でメッセージ境界を決める必要がある。Socket.NoDelayやDataAvailable、TLSのレコード単位はいずれもメッセージ境界の代わりにはならない。実装では、Read/Receiveの戻り値のバイト数だけを信用し、必要バイト数を読み切るまでループする設計と、本番でだけ壊れる不具合をWiresharkやpktmonで観測する手順が実務の要点になる。

flowchart LR
    accTitle: TCPのバイトストリームとフレーミング設計の知識マップ
    accDescr: TCPがバイトストリームでありSend単位を保証しないこと、フレーミング方式の種類、NoDelayやDataAvailableやTLSレコードが境界の代わりにならないこと、WiresharkやpktmonでのAudit手順との関係を示す図
    tcp_byte_stream["TCPのバイトストリーム性"]
    application_framing["アプリケーションプロトコルのフレーミング"]
    length_prefix_framing["長さプレフィックス方式"]
    message_boundary_mismatch["送信区切りと受信区切りのずれ(分割・結合)"]
    fixed_length_framing["固定長方式"]
    delimiter_framing["区切り文字方式"]
    self_describing_framing["自己記述形式"]
    nagle_algorithm["Nagleアルゴリズム(Socket.NoDelay)"]
    socket_dataavailable["NetworkStream.DataAvailable"]
    tls_record["TLSレコード"]
    concurrent_write_interleaving["並行Writeによるアプリケーションレベルの混線"]
    io_loop_until_complete["必要バイト数まで読み切る/書き切るループ"]
    asynchronous_io["非同期I/O"]
    wireshark["Wireshark"]
    pktmon["Packet Monitor(pktmon)"]
    npcap["Npcap"]
    tcp_byte_stream -->|"原因になり得る"| message_boundary_mismatch
    application_framing -->|"防止する"| message_boundary_mismatch
    fixed_length_framing -->|"実装を担う"| application_framing
    delimiter_framing -->|"実装を担う"| application_framing
    length_prefix_framing -->|"実装を担う"| application_framing
    self_describing_framing -->|"実装を担う"| application_framing
    length_prefix_framing -->|"推奨される対応"| tcp_byte_stream
    nagle_algorithm -->|"用いるのは非推奨"| application_framing
    socket_dataavailable -->|"用いるのは非推奨"| application_framing
    tls_record -->|"用いるのは非推奨"| application_framing
    concurrent_write_interleaving -->|"原因になり得る"| message_boundary_mismatch
    io_loop_until_complete -->|"防止する"| message_boundary_mismatch
    io_loop_until_complete -.->|"利用する"| asynchronous_io
    message_boundary_mismatch -->|"で確認できる"| wireshark
    message_boundary_mismatch -->|"で確認できる"| pktmon
    length_prefix_framing -->|"前提とする"| io_loop_until_complete
    fixed_length_framing -->|"前提とする"| io_loop_until_complete
    delimiter_framing -->|"前提とする"| io_loop_until_complete
    wireshark -.->|"前提とする"| npcap

概念間の関係(全19件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• TCPのバイトストリーム性は送信区切りと受信区切りのずれ(分割・結合)の原因になることがあります。TCPは送ったバイト列の順序・重複なし・欠落なしの到達だけを保証し、Sendした単位がReceiveの単位として保存されることは保証しないため、分割や結合が起こり得る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• アプリケーションプロトコルのフレーミングは送信区切りと受信区切りのずれ(分割・結合)を防ぎます。受信側でメッセージ境界を判断する仕組み(フレーミング)を設ければ、分割・結合によるメッセージ境界のずれに正しく対応できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 固定長方式はアプリケーションプロトコルのフレーミングの実装を担います。固定長方式は、常に決まったバイト数を1メッセージとすることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 区切り文字方式はアプリケーションプロトコルのフレーミングの実装を担います。区切り文字方式は、改行など特定のバイト列までを1メッセージとすることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 長さプレフィックス方式はアプリケーションプロトコルのフレーミングの実装を担います。長さプレフィックス方式は、先頭に本文長を置きそのバイト数だけ本文を読むことでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 自己記述形式はアプリケーションプロトコルのフレーミングの実装を担います。自己記述形式は、HTTPのContent-Lengthのように形式内に長さや終端の情報を持たせることでフレーミングを実現する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 長さプレフィックス方式はTCPのバイトストリーム性に対する本記事の推奨です。独自プロトコルを作るなら、本文に任意のバイナリを含められ、受信側の実装が明確で、最大サイズ制限も入れやすい長さプレフィックス方式がまず検討候補になる / 確度: 確立した関係 / 確認日: 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 出典
• 並行Writeによるアプリケーションレベルの混線は送信区切りと受信区切りのずれ(分割・結合)の原因になることがあります。同じTCP接続に複数タスクが同時にフレームを書き込むと、ヘッダーと本文が混ざるアプリケーションレベルの混線が起き、受信側のフレーム復元が壊れる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 必要バイト数まで読み切る/書き切るループは送信区切りと受信区切りのずれ(分割・結合)を防ぎます。Read/Receiveの戻り値のバイト数だけを信用し、必要なバイト数を読み切るまでループすることで、途中で切れた受信を1メッセージとして誤処理しない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 必要バイト数まで読み切る/書き切るループは非同期I/Oを利用します。ReadAsync/WriteAsyncのような非同期I/Oを使う場合でも、要求サイズに届くまで読み書きを繰り返すという考え方は同じである / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 送信区切りと受信区切りのずれ(分割・結合)はWiresharkで確認できます。Follow > TCP Streamで復元したバイト列を見て、送信側のフレーム組み立てと受信側の復元処理のどちらが壊れているかを切り分けられる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 送信区切りと受信区切りのずれ(分割・結合)はPacket Monitor(pktmon)で確認できます。Windows標準のpktmonでキャプチャしたETLをpcapngに変換し、Wiresharkで開いて同様に確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 長さプレフィックス方式は必要バイト数まで読み切る/書き切るループを前提とします。4バイトヘッダーも本文も分割され得るため、ヘッダーと本文それぞれを読み切るまでのループが前提になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 固定長方式は必要バイト数まで読み切る/書き切るループを前提とします。固定長方式でも、1回のReadAsyncで指定バイト数がすべて返るとは限らないため、読み切るまでのループが必要になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 区切り文字方式は必要バイト数まで読み切る/書き切るループを前提とします。改行が来るまでバイトを蓄積し、1行分そろってからデコードするなど、区切りが確認できるまで読み続ける実装が必要になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WiresharkはNpcapを前提とします。Windowsでループバック(127.0.0.1)を見るにはNpcapが必要になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

TCPのバイトストリーム性

TCPが保証するのは送ったバイト列が順序を保って重複・欠落なく届くことだけであり、送信側のSend単位を受信側のReceive単位として保存することは保証しないという性質である。

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

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

長さプレフィックス方式

メッセージの先頭に本文長を置き、そのバイト数だけ本文を読むフレーミング方式で、任意のバイナリを含められ最大サイズ制限も入れやすい。

固定長方式

常に決まったバイト数を1メッセージとするフレーミング方式で、境界は明確だが可変長データを扱いにくい。

区切り文字方式

改行など特定のバイト列までを1メッセージとするフレーミング方式である。

自己記述形式

HTTPのContent-Lengthやchunkedのように、形式そのものの中に長さや終端を表す情報を持たせるフレーミング方式である。

Nagleアルゴリズム(Socket.NoDelay)

小さな送信をまとめて送るかどうかを調整するアルゴリズムで、Socket.NoDelayをtrueにすると無効化できる送信遅延・効率に関する設定である。

NetworkStream.DataAvailable

その瞬間にローカルの受信バッファに読み取り可能なデータがあるかどうかだけを示す、.NETの NetworkStreamのプロパティである。

TLSレコード

TLSが暗号化通信を運ぶ際に使う内部的な伝送単位で、アプリケーションメッセージの境界とは一致しない。

並行Writeによるアプリケーションレベルの混線

同じTCP接続に対して複数のタスクが同時にフレームを書き込むと、ヘッダーと本文の順序が混ざってしまう問題である。

必要バイト数まで読み切る/書き切るループ

Read/ReceiveやSend/Writeの戻り値が要求したサイズより少ないことがあるため、目的のバイト数に達するまで繰り返し呼び出す実装パターンである。

送信区切りと受信区切りのずれ(分割・結合)

TCPの送信単位と受信単位が一致しないために、1メッセージが複数回の受信に分割されたり、複数メッセージが1回の受信に結合されたりする現象である。

Wireshark

キャプチャしたパケットをパケット詳細ペインとバイト列ペインで対応づけて表示できる、パケット解析ツール。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

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