Web技術基礎とは
要点
- Webは、買い物やSNS、検索など、誰もが当たり前に生活の一部として使っている仕組みです。
- その「当たり前」を裏側で支えているのが、「リクエスト・レスポンス」「プロトコル」「ドメイン」「Cookie」「セッション」「キャッシュ」といった技術です。
- これらがどのような要素で構成され、どのような技術で動いているのかを理解しましょう。
ぽち先生も、毎日こんな風にWebを使っています
そもそも「Web」とは
Webは、世界中のサーバーに置かれた情報を、ブラウザから閲覧・操作できる仕組みです。
「クライアント」(利用者が操作する端末やブラウザなど)と、情報を提供する「サーバー」という2つの役割で成り立っています。クライアントがサーバーに「情報をください」とお願いし、サーバーが応答を返す、というやり取りが繰り返されています。
(PC・スマホ・タブレットなど)
←「はい、どうぞ」
ぽち先生のヒントこれはお店に入ると、店員さんが席に案内してメニューを渡してくれるのに似ているよ。クライアントがサーバーを訪れると、サーバーが必要な情報を用意して見せてくれるんだ。
リクエストとレスポンス
ブラウザがサーバーに送る依頼を「リクエスト」、それに対するサーバーの返答を「レスポンス」と呼びます。
リクエストには「種類」があり、これを「メソッド」と呼びます。代表的なのは、ページの情報を取得するときに使う「GET」と、フォームの入力内容などを送信するときに使う「POST」です。例えばこのページを開いたときはGET、お問い合わせフォームを送信するときはPOSTが使われています。
例えば、ブラウザで https://hassan-learning-portal.com/ を開くと、次の4ステップが発生します。
(データなし)
同じHTMLを準備
受信
表示
(データを添えて)
データを処理
レスポンス受信
表示
ぽち先生のヒントレストランで席に座ると、注文しなくても水やおしぼりが出てくるよね。これがGET。でも料理は「これをください」と注文しないと出てこない——それがPOSTなんだ。
HTTPとは
HTTP(HyperText Transfer Protocol)は、ブラウザとサーバーが情報をやり取りする際の共通のルール(プロトコル)です。前のスライドで説明した「リクエスト」「レスポンス」のやり取りや、GET・POSTといったメソッドも、すべてこのHTTPというルールの中で定められています。
URLの先頭についている「http」は、「このURLとはHTTPプロトコルでやり取りしてください」という意味を表しています。「https」の場合は、暗号化された安全な方法でやり取りするという意味になります(詳しくは後のスライドで説明します)。
サーバーからのレスポンスには、次のような「ステータスコード」が付きます。
ぽち先生のヒントステータスコードは、お店の店員さんからの返事のようなものだよ。「ご用意できました(200)」「ご注文の内容にちょっと問題があるようです(400番台)」「今は対応できません(500番台)」など、結果を一言で伝えてくれるんだ。
URLとドメインの仕組み
普段、何気なく使っているURLですが、実は分解すると次のような構成になっています。
URLは「どのサーバーの、どの情報にアクセスするか」を示す住所のようなものです。
https://プロトコルhassan-learning-portal.comドメイン/topics/web-fundamentals/overview.htmlパスドメインは「サーバーの住所」、パスは「そのサーバーの中にあるコンテンツの場所」を表しています。同じサーバー(ドメイン)でも、パスが違えば表示されるページが変わります。詳しくはドメインの個別トピックで解説します。
ぽち先生のヒントドメインは「建物の住所」、パスは「建物の中の部屋番号」に例えられるよ。同じ住所(ドメイン)でも、部屋番号(パス)が違えば案内される先(表示されるページ)が変わるんだ。
HTTPは「状態を覚えない」
HTTPには「ステートレス」という性質があり、1回のやり取りごとに関係がリセットされます。つまり、サーバーは基本的に「さっき誰が何を送ってきたか」を覚えていません。
アクセス
「初めまして」と対応
再度アクセス
また「初めまして」
同じクライアントからのアクセスであっても、サーバー側にはそれを見分ける手がかりがありません。しかし皆さんが普段利用しているWebでは、そんなことは起きていないはずです。一度ログインすれば、ログイン状態はそのまま持続しますし、カートに追加した商品もそのまま保持されています。これを実現しているのが「セッション」という仕組みです。
ぽち先生のヒント毎回「初めまして」と言ってくる、記憶力のないお店の店員さんをイメージしてみて。前回何を注文したか覚えていないから、そのままでは常連さん扱いができないんだ。
セッション管理の仕組み
利用者を継続して識別するために使われるのが「セッション」という仕組みです。まずサーバーが利用者ごとに「セッションID」という識別用の番号を発行し、クライアントに渡します。クライアントは、次回以降のリクエストにこのセッションIDを含めて送ることで、サーバーは「さっきの人だ」と個人を認識できるようになります。
セッションIDを発行
セッションIDを保持
セッションIDを添えて送信
本人と認識
でも、セッションIDを通知された覚えも、自分で入力した覚えもないですよね。それに、ここまでの説明を覚えている人なら「あれ?」と思ったかもしれません——GETリクエストはデータを送らないはずなのに、どうやってセッションIDをサーバーに伝えているのでしょうか?この謎を、次の「Cookie」の仕組みで解き明かします。
ぽち先生のヒント病院の「受付番号」に似ているよ。受付でもらった番号を会計や薬局の窓口でも見せれば、「さっきの人だ」とすぐに分かってもらえるよね。
Cookieとセッションの役割
Cookieは、ブラウザ側に小さなデータを保存させておく仕組みで、対象のドメイン宛のリクエストには基本的にCookieが同封されてサーバーへ送られます(有効期限切れやセキュリティ設定によっては送られないこともあります)。
Cookieはドメインごとに作成され、サーバー側だけでなく、クライアント側(JavaScriptなど)からも書き換えることができます。
前のスライドで説明した「セッションID」は、実はこのCookieに保存されています。サーバーが発行したセッションIDをCookieとして保持しておくことで、クライアントは次回以降のリクエストにそのセッションIDを添えて送信できるのです。
アクセス
セッションIDを発行
書き込んで返却
Cookieを送信
確認
特定
この2つの組み合わせによって「ログインしたままページを移動できる」という体験が実現しています。詳しくはCookie・セッションの個別トピックで解説します。
ぽち先生のヒント遊園地の「リストバンド」に似ているよ。入場時に番号を書き込んだリストバンドを着けてもらえば、以降はいちいち見せなくても、通るたびに係員がサッと確認してくれるんだ。
キャッシュの役割
キャッシュとは、一度取得したデータを一時的に保存しておき、次回以降は再利用する仕組みです。
サーバーへ取得しに行く
手元に保存
保存分を再利用
データを作成
保持
保持分を再利用
キャッシュには、データを手元に保持しておく「クライアント側のキャッシュ」と、一度作成したデータをサーバー側で保持しておく「サーバー側のキャッシュ」があります。それぞれ、速くなる仕組みが異なります。
クライアント側のキャッシュは、手元にあるデータをそのまま再表示することで、そもそもサーバーへのリクエスト自体を省略します。一方サーバー側のキャッシュは、保存しておいたデータをそのまま返却することで、毎回作り直す処理時間を短縮します。詳しくはキャッシュの個別トピックで解説します。
ぽち先生のヒントよく使う調味料をいちいち買いに行かず、キッチンの棚にストックしておくイメージだよ。手元にあるものはすぐ使えるから、買い出し(サーバーへの問い合わせ)の手間が省けるんだ。
まとめ
Webは、買い物やSNS、検索など、誰もが当たり前に使っている仕組みです。その裏側では、「リクエスト・レスポンス」「プロトコル」「ドメイン」「Cookie」「セッション」「キャッシュ」といった技術が動いています。
クライアントとサーバーは「リクエスト」と「レスポンス」をやり取りしており、そのルールを定めているのが「プロトコル(HTTP)」です。アクセス先を示すのが「ドメイン」、ログイン状態などを維持する仕組みが「Cookie」と「セッション」、そして表示を高速化する仕組みが「キャッシュ」でした。
それぞれの仕組みは、以下の個別トピックでさらに詳しく学べます。
関連トピック: