ストリームとフレーミング — TCP の send と recv はずれる

TCP は正しく動いているのに、データが「壊れる」

ここまでの 5 章で、TCP は 3 つの約束を見事に守ることを見てきました。ところが実務では、TCP の上で「たまに受信データが欠ける」「2 つのメッセージがくっついて届く」という不具合が頻発します。パケットキャプチャを見ても再送もロスもない。TCP は完全に正常。それでもアプリのデータは壊れて見える — なぜでしょうか。

答えは、TCP が届けるものの正体にあります。TCP が約束したのは「同じバイト列を、同じ順序で」であって、「同じ切れ目で」ではありません。第 3 章で見たとおり、TCP の主役はセグメントではなくバイトです。send() を 300 バイト・200 バイトの 2 回に分けて呼んでも、ネットワークを旅するうちに 1 つのセグメントにまとまるかもしれないし、120 + 380 に切り直されるかもしれません。受信側の recv() が返す塊の切れ目は、送信側の send の切れ目と無関係なのです。

この性質をバイトストリーム（メッセージ境界を保存しない）と呼びます。ソケットは手紙の束を運ぶ郵便屋ではなく、切れ目のない水道管です。水道管に「1 杯目の水」と「2 杯目の水」の境目が残らないのと同じです。

切れ目が変わる 2 つの現場

切れ目はどこで変わるのでしょうか。代表的な現場が 2 つあります。

どちらも TCP にとっては正しい最適化です。開発環境（ローカル、低遅延、小さなデータ）では偶然「1 send = 1 recv」が成立し続けるため、この前提のバグは本番でだけ、たまに発火します。「再現しない不具合」の名産地です。

フレーミング — 境界はアプリが自分で作る

メッセージの境界が必要なら、境界の情報をバイト列そのものの中に埋め込むしかありません。これをフレーミングと呼びます。定番は 2 つです。

どちらの方式でも、受信側のコードは同じ型になります — recv で届いた分をバッファに追記し、完成したメッセージだけを切り出し、余りは次に持ち越す。recv の回数や切れ目には一切依存しないループです。逆に言えば、このループさえ正しければ、TCP がどんな切れ目で届けようとアプリは壊れません。

覚え方: TCP に「1 通」という概念はありません。「1 通」を発明するのは、いつもアプリ側の仕事です。既製のプロトコルやライブラリを使うときも、その下でこのフレーミングが動いています。

この章で持ち帰ること

• TCP はバイトストリーム — 約束は「同じバイト列を同じ順序で」。send の切れ目は保存されない
• 切れ目は結合（Nagle）と分割（MSS）で日常的に変わる。「1 send = 1 recv」は開発環境の偶然
• 境界が要るならフレーミング — 長さプレフィックスか区切り文字。区切り文字にはエスケープの設計が必須
• 受信側の型は「貯めて、そろった分だけ切り出し、余りは持ち越す」。recv の切れ目に依存しない

これで部品はすべて揃いました。最終章では、実務風の 8 つの障害ケースを「どの章の話か」に翻訳しながら切り分けます。