インターネットの「速さ」の秘密：HTTP/3のSTREAMフレームと「迷子にならない郵便配達」の話
こんにちは！ネットワークの世界へようこそ。
普段、私たちが何気なくWebサイトを見ているとき、背後ではものすごい速さでデータがやり取りされています。最近の主流である「HTTP/3」。これ、何がそんなに凄いのかというと、一言でいえば「とにかく止まらないし、速い」んです。
今日は、そのHTTP/3の心臓部ともいえる「STREAM（ストリーム）フレーム」と、データがバラバラになっても正しく届く「オフセット」の仕組みを、身近な郵便配達に例えて紐解いていきましょう。
—
1. なぜUDPを使うの？「信頼」と「速度」のジレンマ
HTTP/2までは、TCPという「お堅い配達員」を使っていました。TCPは「届いた？」と常に確認し合うので確実ですが、一つでも荷物が紛失すると、届くはずの別の荷物まで待たされてしまうという弱点がありました。
そこでHTTP/3は、UDPという「とりあえず送るよ！」という身軽なプロトコルを採用しました。でも、UDPは「送るだけ」なので、そのままではデータがぐちゃぐちゃになってしまいます。そこで登場するのが「STREAMフレーム」です。
2. 「STREAMフレーム」の秘密：パズルを組み立てる仕組み
HTTP/3では、大きなデータを送るとき、それを小さな「小包」に分けます。これが「STREAMフレーム」です。
このとき、小包には必ず「オフセット（Offset）」というラベルが貼られます。これが今回の主役です。
オフセット＝「本のページ番号」
想像してみてください。分厚い小説を1ページずつバラバラの封筒に入れて送るとします。受け取った側は、どのページから読めばいいか分かりませんよね？
ここで「オフセット」が大活躍します。
- オフセット 0: 「これは1ページ目です」
- オフセット 100: 「これは101文字目から始まる内容です」
このように、「データの何番目から始まるか」という住所（位置情報）が書かれているので、たとえ郵便が届く順番が前後しても、受け取った側は「あ、これは後のページだな、まだ置いとこう」「あ、これがあればパズルが完成する！」と判断できるのです。
3. なぜ「オフセット」があると再送が怖くないのか？
もし、途中のパケットが消えてしまったらどうなるのでしょうか？
例えば、1〜100バイト目まで届いたのに、101〜200バイト目が届かない。次に201〜300バイト目が届いたとします。
ここでオフセットの出番です。受け取り側はこう考えます。
「101〜200バイト目が欠けているから、まだデータは完成しない。でも、201〜300バイト目は先に預かっておこう！」
このように、欠けている部分だけを「再送して！」とピンポイントでお願いすればいいのです。これがHTTP/3が「止まらない」理由です。前のパケットが来ないと次が処理できない……なんていう無駄な待ち時間は、もう必要ないんですね。
—
4. 実践！データ構造を覗いてみよう（擬似コード）
エンジニアとして現場に出たとき、パケットキャプチャツール（Wiresharkなど）で覗くと、このような構造が見えてきます。
// HTTP/3のSTREAMフレームのイメージデータ
{
stream_id: 1, // どの通信の小包か？
offset: 1024, // データの「何バイト目から」の内容か？（ここが重要！）
length: 512, // データの長さ
data: “…” // 実際のデータの中身
}
// 解説：
// もし、オフセット「0」から「1023」が既に届いているなら、
// このパケットは「1024バイト目から」のデータとして、
// バッファ（一時保管場所）の正しい位置にパチっとはめ込まれます。
このように、ネットワークのプロトコルは意外と「整理整頓」の連続なんです。
—
5. まとめ：ネットワークは「思いやり」でできている
HTTP/3のSTREAMフレームとオフセットの仕組み、なんとなくイメージできましたか？
- データは細かく分ける
- 「何番目のデータか」をオフセットで明記する
- 届いた順ではなく、正しい順序で組み立てる
この仕組みがあるおかげで、私たちは電波が不安定なカフェのWi-Fiでも、動画を止めることなく快適に楽しめているのです。
最初は難しく見えるパケットの羅列も、実は「相手が困らないように、順番を教えてあげる」という、とても人間味のある配慮から生まれているんですよ。
もし次にトラブルシューティングでパケットを眺める機会があれば、ぜひ「オフセット」の数値に注目してみてください。そこには、データたちが必死に迷子にならないよう工夫している姿が見えてくるはずです。
それでは、また次回の深掘りでお会いしましょう！
コメント