【入門編】HTTP/1.1における100 Continueの挙動 – HTTPプロトコル・通信規格実践ガイド

「とりあえず送る」から「確認してから送る」へ。HTTPの賢い作法『100 Continue』の正体

ネットワークの世界へようこそ!Webサイトを見たり、APIを叩いたりする際、私たちは当たり前のように「リクエスト」を送っていますよね。

でも、想像してみてください。もしあなたが、中身がギチギチに詰まった巨大な荷物を、相手が受け取れるかどうかも分からないうちに送りつけたらどうなるでしょう?もし相手が「今は受け取れないよ!」と言ったら、その重い荷物を運んだ労力はすべて無駄になってしまいます。

実は、HTTP通信にもこれと同じことが起こり得ます。そこで登場するのが、今回解説する『100 Continue』という、なんとも気が利く仕組みです。

—

なぜ「確認」が必要なのか?

私たちが普段使うHTTP/1.1という規格では、クライアント(ブラウザやプログラム)からサーバーへ巨大なデータ(ファイルアップロードなど)を送る際、何も言わずにいきなりデータを投げつけるのがデフォルトです。

しかし、もしサーバー側でこんなことが起きていたらどうでしょう?

  • 「認証に失敗したから、そもそもこのデータは受け付けないよ」
  • 「容量オーバーだよ」
  • 「今、サーバーがめちゃくちゃ混んでて処理できないよ」

この場合、クライアントは一生懸命データを送ったのに、サーバーからは「はい、拒否!」と冷たい返事が来るだけ。通信帯域も時間も、完全に無駄になってしまいます。

そこで、「このデータを送ってもいいですか?」と事前に伺いを立てるのが『100 Continue』の役割なのです。

—

郵便配達で例える「100 Continue」の仕組み

このやり取りを、郵便配達に例えてみましょう。

1. 【Expect: 100-continue】(伺い)
「すみません、この大きな荷物を届けたいのですが、受け取ってもらえますか?」と、封筒だけ先に送ります。
2. 【100 Continue】(承諾)
サーバーは中身を見て、「ああ、その荷物ならOKだよ!持ってきて!」と返事をします。
3. 【データ送信】(本番)
クライアントは、ここで初めて重い荷物(リクエストボディ)を運びます。

もしサーバーが「ダメだよ」と言えば、クライアントは荷物を運ぶ必要がなくなるので、ネットワークの無駄な通信をバッサリカットできるというわけです。非常に合理的ですよね!

—

実際にコードで見てみよう

さて、エンジニアとしてこの挙動をどう扱うか、簡単な例を見てみましょう。例えば、何らかのプログラムからリクエストを送る際、以下のようなヘッダーを付与します。

クライアントからサーバーへの「伺い」
POST /upload HTTP/1.1
Host: example.com
Expect: 100-continue # 「このヘッダーが、サーバーへの確認の合図です」
Content-Length: 1048576 # 送りたいデータのサイズ(1MB)

これを受け取ったサーバーが、受け入れOKなら以下のようなレスポンスを返します。

サーバーからの「送っていいよ」という返事
HTTP/1.1 100 Continue

このレスポンスが返ってきたことを確認してから、クライアントは実際のデータ(ボディ)を送信します。

—

現場で気をつけるべきポイント:常に使うべき?

「じゃあ、すべてのリクエストに『100 Continue』をつけるべき?」と思うかもしれませんが、実はそうとも限りません。

  • 小さなデータには不要: 小さなテキストデータなら、確認している間にサッと送ってしまったほうが早いです。
  • サーバーの対応状況: サーバー側がこの仕組みをサポートしていない場合、無駄な待機時間が発生してしまうこともあります。

最近のライブラリやブラウザは、ある程度のデータサイズを超えない限り、自動的にこの最適化を行うか判断してくれることがほとんどです。私たちがデバッグする際は、「巨大なファイルをアップロードしているのに、なぜか途中で止まる(または拒否される)」といったトラブルの際に、「ああ、Expectヘッダーが正しく処理されていないのかも?」と疑う視点を持つことが大切です。

—

まとめ:ネットワークの「対話」を楽しもう

HTTP/1.1の『100 Continue』は、無駄な通信を減らし、効率的にやり取りするための「大人の会話」のようなものです。

ネットワークのトラブルシューティングをしていると、パケットの流れがまるで生き物のように感じられる瞬間があります。「なぜここで止まっているのか?」「相手はどんな返事を期待しているのか?」という問いかけを繰り返すことで、インフラエンジニアとしての勘は確実に養われていきます。

難しいプロトコルの仕様書も、こうして「現実世界のやり取り」に置き換えてみると、途端に親しみやすく感じられませんか?

これからも、パケットの旅を追いかけながら、一緒にネットワークの深淵を楽しんでいきましょう!

コメント

タイトルとURLをコピーしました