はじめに
こんにちは！リンクアンドモチベーションの宮田です！
本記事はリンクアンドモチベーション Advent Calendar 2024の16日目を担当しています🎄
最近イラスト図解式 この一冊で全部わかるWeb技術の基本 第2版を読んだのですが、自分でも実際に手を動かして理解を深めようということで、今回は以下の画像（Googleの検索画面のロゴ）がどのようにブラウザに取得されているのか、またその際のHTTPリクエストとHTTPレスポンスに含まれる情報について調べてみました。
↑↑ こいつの裏側で何が動いているのか👀
まずHTTPとは
実際にGoogleのロゴを見る前に、ざっくりHTTPについて確認していきます。
HTTPとは Hyper Text Transfer Protocolの略で、WebブラウザとWebサーバー間でWeb情報をやりとりするためのプロトコル（通信規則） です。
ウェブの基盤となる技術であり、ウェブページの取得やデータ送信など、インターネット上の多くのサービスに利用されています。
HTTPの特徴
HTTPはステートレス（stateless） なプロコトルと言われていて、
各リクエストは独立して処理され、過去のリクエスト情報を保持しません。というのは、言い換えると個々のクライアントの情報を持たないということです。
このおかげで、複数の問い合わせに対する処理を効率的に行うことができています。
リクエスト処理マシーンになれるということですね。
ただ、実現したいサービスによってはステートレスがあだとなるパターンもありそうだということは意識しておきたいです。
HTTP
- WebブラウザとWebサーバー間でWeb情報をやりとりするためのプロトコル
- ステートレス（個別の情報をもたない）
HTTPリクエスト
WebブラウザからWebサーバーに送られるもので以下のような構成になっています。
| リクエストライン |
|---|
| HTTPヘッダー |
| 空行 |
| メッセージボディ |
HTTPリクエストの最初の行のリクエストラインで、サーバーに対して行う操作（メソッド）や対象のリソース、通信プロトコルのバージョンを指定します。
# HTTPリクエストライン
GET/index.html/HTTP/1.1
メソッド/パス名/バージョン
「クライアントがサーバーに対して、HTTPバージョン1.1を使用して /index.html というファイルを取得するリクエストを送信する。」
HTTPレスポンス
WebサーバーからWebブラウザに送られるもので、以下のような構成になっています。
| ステータスライン |
|---|
| HTTPヘッダー |
| 空行 |
| メッセージボディ |
HTTPレスポンス ステータスライン
HTTP/1.1/200/OK
バージョン/ステータスコード/テキストフレーズ
バージョンってなんだ、ステータスってなんだ、という場合は簡単にまとめてみたので以下を確認してみましょう。
HTTPのバージョン
1. HTTP/1.1
- 最も普及しているバージョン
- パイプライン（複数リクエストを同時に送信）
- キャッシュ制御の強化（
Cache-Control）
もともとはリクエストを送信したらそのレスポンスが返ってくるまで、次のリクエストを送信することはできませんでしたが、パイプラインのおかげでリクエストを複数同時送信できるようになりました。しかし、送った順番にリクエストを処理するので、一つ詰まると処理が止まってしまうのが弱点です。
2. HTTP/2
- HTTP/1.1の課題（遅延や帯域幅の無駄）を解消
- バイナリプロトコル：効率的なデータ送信
- マルチプレキシング：複数リクエストを同時に処理
- ヘッダー圧縮：通信量を削減。差分を送信するみたいな手法
HTTP/1.1の弱点を補うように、マルチプレキシング（ストリーム処理）によって複数のリクエスト→レスポンスを並列で処理できるようになりました。
3. HTTP/3
- 新しいプロトコルで、QUIC（UDPベース）を採用。
- 接続の高速化。
ステータスコード
ステータスコードはクライアントからサーバーのリクエストに対して、サーバーがどのように処理したかを数字で伝える仕組み。以下のような種類があります。
| ステータスコード | カテゴリ | 説明 |
|---|---|---|
| 1XX | Continue | リクエスト中 |
| 200 | OK | リクエストが正常に処理されたことを通知する |
| 3XX | Redirection | リダイレクト |
| 301 | Moved Permanently | リクエストされたコンテンツが移動したことを通知 |
| 302 | Found | リクエストされたコンテンツが一時的に移動したことを通知 |
| 303 | See Other | リクエストされたコンテンツが未更新であることを通知する |
| 304 | Not Modified | クライアントが以前に取得したリソースが変更されていないことを示し、キャッシュされたリソースを再利用する |
| 4XX | Client Error | クライアントエラー |
| 400 | Bad Request | リクエストが不正 |
| 401 | Unauthorized | 認証情報が得られない |
| 403 | Forbidden | コンテンツへのアクセス権がないことを通知 |
| 404 | Not Found | リクエストしたコンテンツが未検出であることを通知 |
| 5XX | Server Error | サーバーエラー |
| 500 | Internal Server Error | リクエスト処理中にサーバー内部でエラーが発生したことを通知 |
| 502 | Bad Gateway | 有効な応答を受け取れなかった場合に発生 |
| 503 | Service Unavailable | アクセス集中やメンテナンスなどの理由で一時的に処理不可であることを通知 |
開発者ツールで見てみる
Googleの画面で開発者ツールを開いてみて、
Googleのロゴの情報を取得している部分を確認してみます。
全般：概要を表示してくれている感じでしょうか
上から確認していきます。
要求URL（リクエストURL） :
https://www.google.co.jp/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
どんな構造かというと、
# スキーム
https://
# ドメイン（ホスト）
www.google.co.jp
# パス
/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
- スキームとはURLの先頭につく要素で、「どのプロトコルを使って通信をするのか」 を指定する役割を持っています。
プロコトルには他にも
httphttpsftp-
smtpなどがあります。
-
ドメインはIPアドレスを人間が読みやすいようにしたものなので、インターネットやローカルネットワーク上でコンピュータやデバイスを識別するための「住所」です。今回はGoogleのサーバーを指定しています。
-
パスはGoogleサーバーの特定のファイルの場所を表してくれています。このような階層構造です。
ルート（https://www.google.co.jp/）
└── images/
└── branding/
└── googlelogo/
└── 2x/
└── googlelogo_color_272x92dp.png
まとめると、
「暗号化した通信で、Googleサーバーのこのパスが示すファイルを下さい」
と言っているはずです。
なので、以下のリクエストを送信すると、Googleのロゴ画像が見れるはずです。
次です。
Request Method :
GETメソッド：データを取得するためのメソッドです。
データの送信するときは、URLの後ろにクエリパラメータとしてデータを付与して送信するという特徴があります。
比較対象として、POSTメソッドは、データをHTTPリクエストのメッセージボディに含めて送信するという特徴があります。主にデータの送信・登録が目的です。
状態コード
「200 OK」と書いてありますが、これは先ほど紹介したHTTPステータスコードを表しています。
リモート アドレス : [2404:6800:4004:825::2003]:443
これはIPアドレスとポート番号を表しています。
このIPアドレスはGoogleのサーバーを示していて、443はHTTPS通信に使われる標準的なポート番号です。
ポート番号は特定のサービスやプロトコルを識別するための仕組みです。
IPアドレスで特定したサーバー内の「どのサービス（アプリケーションやプロコトル）」を利用するかを識別するために使われます。
IPアドレスは建物の住所で、ポート番号は部屋番号みたいな例えがあると思いますが、
今回の例でいうと、
「Googleサーバーの安全にウェブを見に行く部屋に行ってくる」
と言っているはずです。
ちなみに、
HTTP通信はポート番号：80 です。
リクエストヘッダーを見てみる
authority : ホストはwww.google.com
method: GETメソッド
path : /images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
scheme: https
Cache-Control: no-cache
Cookie: 長々となんか書いてある
先ほどまでの説明で上の4つは大体わかるはずです。
Cache-Controlヘッダーは、キャッシュに関する指示をサーバーに伝えます。
no-cache は、キャッシュされたコンテンツを使わず、必ずサーバーに対して新しいリソースをリクエストすることを意味します。 ここでは、クライアントが最新のリソースを確実に取得したいという要求が示されています。
更新頻度の高い情報にアクセスするときなどに使われます。
Cookie
Cookieはブラウザを識別するために使われます。
WebサーバーがCookieを渡し、Webブラウザが接続時、サーバーにそのCookieを送信することで相手を識別することができる。
レスポンスヘッダーを確認してみる
たくさんありますが、一部抜粋しながら解説していきます。
Cache-Control
-
private:クライアントのみがリソースをキャッシュできるようにしています -
max-age=秒数:キャッシュが有効な秒数を指定しています。今回は315360000秒＝1年間のキャッシュができることを表しています。
Expires :
- キャッシュの有効期限を具体的な日時で指定しています。
- ただし、
Cache-Controlのmax-ageと併用された場合、Cache-Controlが優先されます。
Last-Modified :
- リソースが最後に変更された日時を示します。
- これは条件付きリクエストとして利用されます。クライアントがリソースを再取得する場合、
If-Modified-Sinceヘッダーを送ることで、変更があった場合のみリソースを再送信するという仕組みができます。実際のデータのやり取りではないので処理が軽く効率的というメリットがあります。
最後に
まだまだHTTPヘッダーの中でも一部しか確認できていないと思いますが、少しずつ意味を理解して、活用できる幅を広げていきたいと思います。
最後までお読みいただきありがとうございました！
おまけ
一見上で紹介したのと同じ画像ですが、この画像のURLは以下のようになっています。
https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924509/4f9936d3-22e1-1643-807a-d6f8208232f7.png
このURLのドメインは、Qiitaが画像などのファイルを AWS S3 サービスを使用して、東京リージョン（ap-northeast-1) で保存し、提供していることを示しています。
Qiitaの記事に画像を張り付けると、Googleのサーバーに存在する画像ファイルを参照しに行くのではなくて、Qiita側（AWS側）に画像データが登録されて、そこを参照しに行くみたいですね。
面白いですね
参考文献