【入門編】SPDYにおけるストリームとフレームの概念 – HTTPプロトコル・通信規格実践ガイド

HTTPの進化を読み解く：SPDYが変えた「郵便」の仕組み

こんにちは！ネットワークの世界に飛び込んだ皆さん、ようこそ。

普段、私たちがブラウザでWebサイトを見るとき、裏側では膨大な数の「パケット」という小さな手紙が世界中を駆け巡っています。今日は、Webの歴史における「革命」とも呼べるSPDY（スピーディ）というプロトコルが、なぜこれほどまでに重要なのか、そしてそれが現代のHTTP/2へとどう繋がっているのかを、身近な「郵便配達」に例えて紐解いていきましょう。

—

1. HTTP/1.1の時代：行列のできる郵便局

まずは、SPDYが登場する前のHTTP/1.1のお話です。この時代の通信を「郵便配達」に例えるなら、「一度に一つの荷物しか運べない配達員」のような状態でした。

Webページには、HTMLだけでなく、画像やCSS、JavaScriptといったたくさんの部品が必要です。HTTP/1.1では、これらを一つずつ順番に受け取る必要がありました。

問題点： 「あ、画像も必要だった！」と思っても、前の荷物の配達が終わるまで、次の荷物を頼めない。これを「ヘッド・オブ・ライン・ブロッキング（先頭の荷物が邪魔で後ろが詰まる現象）」と呼びます。

これでは、Webサイトがなかなか表示されませんよね。当時のエンジニアたちは、この行列を解消するために、こっそりとブラウザを並列で動かして、複数の配達員を無理やり走らせるような工夫（ドメインシャーディングなど）をして耐えていました。

—

2. SPDYの登場：魔法の「コンテナ」と「多重化」

そんな閉塞感を打ち破ったのが、Googleが開発したSPDYです。SPDYは、HTTPの「テキスト（人間が読める文字）」という制限を取り払い、「バイナリフレーム」という仕組みを導入しました。

郵便配達に例えると？

HTTP/1.1： 一つの箱に、手紙（データ）を一つずつ入れる。中身を確認するために、いちいち封筒を開封して「これは画像だ」「これは文字だ」と確認しなければならない。
SPDY： 巨大なコンテナを用意し、その中に小さな箱（フレーム）を詰め込む。コンテナには「これは画像用の箱」「これは文字用の箱」という目印（ストリームID）がついており、配達員は一つのコンテナの中で複数の荷物を同時に、かつ並列に運べるようになった！

これが「ストリーム多重化」です。バラバラの荷物を一つの大きな流れ（ストリーム）の中に効率よく詰め込むことで、通信の無駄を極限まで減らしたのです。

—

3. バイナリフレームって何？

「バイナリ」という言葉、少し難しそうに聞こえますよね。でも、安心してください。一歩ずつ理解していきましょう。

テキスト（HTTP/1.1）： 「GET /index.html HTTP/1.1」というような、人間が読める文字で通信していました。これだと、コンピュータが理解するために、毎回「この文字は何の意味だ？」と解析（パース）する時間が必要です。
バイナリ（SPDY）： 0と1の数字の羅列で構成された「型」が決まったデータです。コンピュータにとっては、文字を読むよりも圧倒的に速く処理できます。

例えば、データが流れるとき、SPDYはこんな風に「荷札」を貼ります。

擬似的なデータ構造イメージ
[フレームタイプ: 1] # 01はデータですよ、という型
[ストリームID: 5] # 5番目の荷物ですよ、という目印
[長さ: 1024バイト] # 荷物のサイズ
[データ本体] # 実際の画像やHTMLの断片

コンピュータは、この「荷札」の場所が決まっているため、中身を詳しく読まなくても「お、これは5番目の荷物だ！」と瞬時に判断できます。これが、高速化の最大の秘訣です。

—

4. なぜこれが「現代」に活きているのか

SPDYで確立された「バイナリフレームによる多重化」という考え方は、現在の標準規格であるHTTP/2にそのまま引き継がれました。

今、皆さんがWebサイトを快適に閲覧できているのは、SPDYが先陣を切って「郵便のルール」を変えてくれたおかげなのです。

実務で知っておきたいこと

もし皆さんがWebサーバーのログを見たり、ブラウザのデベロッパーツール（F12キー）を触ったりする機会があれば、通信のプロトコルが「h2（HTTP/2）」になっているか確認してみてください。そこでは、昔のような行列待ちではなく、コンテナに詰め込まれた荷物が効率よく飛び交っている様子が見えるはずです。

—

まとめ：ネットワークの旅は続く

「テキストベースの非効率なやり取り」から「バイナリによるスマートな多重配送」へ。SPDYがもたらしたこの進化は、単なる技術的な変更ではなく、「いかにしてユーザーにストレスを与えず、データを届けるか」という、インフラエンジニアの情熱そのものと言えます。

難しいプロトコルも、こうして身近な仕組みに置き換えると、少しだけ親近感が湧いてきませんか？

次回は、この多重化した通信をさらに加速させる「HTTP/3（QUIC）」の魔法についてお話ししましょう。それでは、また次回の記事でお会いしましょう！