NET // communication networks
LESSON 06 / 基礎編

WWW と HTTP

毎日のように見ている Web ページ。アドレスバーに URL を入れて Enter を押すと、なぜページが表示されるのでしょうか。WWW(ワールドワイドウェブ)の正体、ブラウザとサーバが交わす「ちょうだい/これだよ」の会話、URL が指しているもの、そして HTTPS の鍵マークまで。Web の基本を、図とミニ実験で理解します。

学習目標

本講を終えると、以下の問いに答えられるようになる。

本講は 第3回(プロトコルと階層モデル) の アプリケーション層 の代表例にあたる。第1回 で扱ったブラウザ・サーバの話を、もう一段ふみこんで「具体的にどんな会話をしているのか」を見ていきます。HTTP の細かいヘッダや HTTP/2・HTTP/3 の中身は 標準 編で詳しく扱います。

このレッスンの目次

01 WWWとは WWW(World Wide Web、ワールドワイドウェブ) は、世界中のコンピュー… 02 ブラウザとサーバ Web の世界には、はっきりと役割の違う2つの登場人物がいます。 ブラウザ(クライア… 03 URL のしくみ Webページには 世界に1つの「住所」 がついていて、それを URL(Uniform… 04 HTTP の役割 HTTP(HyperText Transfer Protocol、エイチティーティー… 05 表示までの流れ アドレスバーに https://www.example.com/news.html … 06 ページの部品 実は、Webページは 1つのファイルだけ でできているわけではありません。 HTML… 07 HTTPS アドレスバーの URL の左に 🔒 鍵のマーク がついていることに気づいたことがあ… 08 まとめと用語 本講の重要語句を整理 09 確認問題 理解度を問題でチェック

WWW(ワールドワイドウェブ)とは何か

WWW(World Wide Web、ワールドワイドウェブ) は、世界中のコンピュータに置かれた文書(Webページ)が、 互いにリンクでつながっている 巨大な情報空間のことです。略して Web(ウェブ) とも呼びます。「インターネット = WWW」と思いがちですが、正確には インターネットの上で動いている1つのサービス が WWW です。
POINT WWW の特徴は ハイパーテキスト = 文書のなかに別の文書へのリンクを埋め込めること。クリック1回で、世界中のどのWebページにも飛んでいける。これが「Web(=蜘蛛の巣)」と呼ばれるゆえん。

身近なたとえ:本のなかから別の本へジャンプ

ふつうの本では、本文に「○○については別の本のXXページを参照」と書いてあっても、あなたはその本を自分で探しに行かないといけません。Web の世界では、文中の 下線が引かれた青い文字(リンク) をクリックするだけで、別のWebページへ 瞬時に飛べる のです。これが ハイパーテキスト の力です。

記事の中のリンクをクリックすると、別のページへ移動できる ページA: ニュース記事 Webの記事 用語の解説 関連ニュース ページB 用語の解説 リンク先の別ページ ページC 関連ニュース 別のリンク先 クリックで移動

図の見方:ページAの記事本文の中にリンクがあり、そのリンクをクリックするとページBやページCのような別ページへ移動できる。文書の中に別の文書への道筋を埋め込めることが ハイパーテキスト の特徴。

WWW を支える3つの仕組み

WWW は、次の3つの取り決めの組み合わせで成り立っています。今回はこの3つを順番に見ていきます。

役割名前ざっくり言うと
場所を指すURL「世界のどこにある何のページか」を表す住所
やり取りのルールHTTPブラウザとサーバの「ちょうだい/これだよ」の会話の手順
ページの書き方HTMLページの中身(見出し・段落・リンクなど)を記述する言葉

考えてみよう: WWW は1989年にイギリス出身の研究者ティム・バーナーズ=リーが提案したのが始まりです。その後30年あまりで、世界中の誰もが毎日使う情報基盤になりました。最初に作られたWebページは、いまも公開されているそうです。

情報Iで覚えることWWW(Web) はインターネット上で動く1つのサービスで、ハイパーテキスト(リンクで文書同士をつなぐしくみ) によって成り立っている。支える3つの要素は URL・HTTP・HTML。

ブラウザとサーバ:Web の基本構造

Web の世界には、はっきりと役割の違う2つの登場人物がいます。 ブラウザ(クライアント) と Webサーバ です。あなたが Chrome や Safari でページを見るとき、裏ではこの2人が 「ちょうだい」「これだよ」 という会話を繰り返しています。
POINT Web の基本形は クライアント・サーバ型。
クライアント(ブラウザ) = 「下さい」と 要求(リクエスト) する側
サーバ(Webサーバ) = ページを蓄えていて、要求があったら 応答(レスポンス) で返す側
ブラウザが先に頼み、Webサーバが答える ブラウザ (クライアント) 利用者の操作で リクエストを送る Webサーバ (サーバ) HTMLや画像を 保管して返す 1 URLを入力 https://example.com/news.html 2 HTTPリクエスト GET /news.html 「ページちょうだい」 3 ファイルを探す HTML / CSS / 画像など 4 HTTPレスポンス 200 OK + HTML/画像 「これだよ」 画面表示
ステップ1.URLを入力する。 利用者がアドレスバーに URL を入れると、ブラウザは「どのサーバの、どのファイルがほしいか」を読み取ります。
ステップ2.ブラウザがリクエストを送る。 Webの会話は、まずクライアントであるブラウザから始まります。ここでは GET /news.html という要求を送っています。
ステップ3.Webサーバが探す。 サーバは要求されたパスを見て、対応する HTML や画像などのファイルを準備します。サーバは要求が来るまで待っている側です。
ステップ4.Webサーバがレスポンスを返す。 見つかったページを 200 OK と一緒に返し、ブラウザは受け取った内容を画面に表示します。
1 / 4

図の見方:「次へ」ボタンで、URL入力 → リクエスト → サーバ側の準備 → レスポンスの順に進む。Webの会話はいつもブラウザが先に話しかけ、Webサーバが答える。

ブラウザとサーバの違いをひとことで

ブラウザ(クライアント)

「見たい人」 の道具。
・URL を受け取って、サーバに「これちょうだい」と問い合わせる
・返ってきた HTML や画像を 並べて表示する
・私たちが普段操作しているのはこちら
・例: Chrome / Safari / Firefox / Edge

Webサーバ

「見せる側」 のコンピュータ。
・常時電源を入れたまま、リクエストを 待ち続けている
・要求されたページ(ファイル) を見つけて返す
・1台で1日に何百万回も応答することもある
・例: Apache / Nginx などのサーバソフトが動いている

つながる知識: 「クライアント・サーバ型」という考え方は Web だけのものではありません。メール(第7回で学習予定)、オンラインゲーム、銀行のATMなど、世の中のシステムの大半はこの形をしています。「お客さん(クライアント)」と「お店(サーバ)」をイメージするとわかりやすいです。

情報Iで覚えることWebは クライアント・サーバ型。ブラウザ(クライアント) が リクエスト を送り、Webサーバ が レスポンス を返す、という1往復の会話で成り立つ。

URL:Webページの住所

Webページには 世界に1つの「住所」 がついていて、それを URL(Uniform Resource Locator) といいます。ブラウザのアドレスバーに表示されている長い文字列のことです。「どのサーバの、どのファイルを見たいか」を1行で表しています。
POINT URL は3つの主な部品でできている:
https:// = scheme(やり方) どのプロトコルで取りに行くか
www.example.com = host(どのサーバ) 世界のどのコンピュータか
/news/2026/article.html = path(中のどこ) サーバ内のどのファイルか

URL の中身を分解してみる

https:// www.example.com /news/2026/article.html scheme どのプロトコル? → HTTPS で取りに行く host(ホスト) どのサーバ? → 世界中で1つの名前 path(パス) そのサーバの中のどこ? → ファイルへの道のり たとえ: [方法] + [場所] + [詳しい位置]

図の見方:URL は「やり方:どこの:何を」の3点セット。これだけ書いてあれば、世界中のどのページでも一意に指し示せる。長く見える URL も、よく見るとこの3つの部品の組み合わせ。

もっと身近な例で

たとえばこんな URL を考えてみましょう。

もっと詳しく:URL のその他の部分

URL には他にも書ける要素があります。すべて覚える必要はありませんが、見かけたときに「あ、こういうものか」と分かれば十分です。

このページの目次タブの URL も www-http-l1.html#url のように # 付き。これがフラグメントです。

小問:URL の先頭にある https:// は何を意味しているでしょう?
正解:B。https:// は URL の scheme(スキーム) 部分で、「このページを取りに行くときに使うプロトコル(取り決め)」を表しています。https なら暗号化された HTTP で、http なら暗号化なしの HTTP で取りに行く、という指示です。Aは host が担う情報、C・D は URL とは関係ありません。
情報Iで覚えることURL はWebページの「住所」で、scheme(プロトコル)・host(サーバ名)・path(サーバ内の場所) の3つの部品からなる。例:https://www.example.com/news.html。

HTTP:ブラウザとサーバの会話のルール

HTTP(HyperText Transfer Protocol、エイチティーティーピー) は、ブラウザとWebサーバが Webページをやり取りするための取り決め です。「プロトコル」 = 取り決め(第3回)、と思い出してください。HTTP は アプリケーション層のプロトコル の代表選手です。
POINT HTTP の 1回のやり取り はいつも2通の往復:
1. ブラウザ → サーバ:HTTPリクエスト(「これください」)
2. サーバ → ブラウザ:HTTPレスポンス(「はい、これです」または「ありません」)
この往復1回で、Webページの「1つの部品」が運ばれる。
注意: ここでは「1往復で1部品」というシンプルな形で説明していますが、実際のWebでは リダイレクト(別のURLへ案内される)、認証(IDやパスワードの確認)、1ページ分の複数ファイル(HTML・CSS・画像・JS)の取得、同じ接続を何度も使い回す(接続の再利用) など、1つのページ表示でも 何度もリクエスト・レスポンスが行き来します。本講では基本の1往復に焦点を当て、こうした応用は省略しています。

リクエストとレスポンスの中身を見てみよう

本物のメッセージには色々な情報が書かれていますが、ここでは 「何が書かれているか」のイメージ をつかめば十分です。順に見ていきましょう。

HTTPリクエスト(ブラウザ→サーバ)

ブラウザが送る「ちょうだい」のメッセージ。先頭に「何のページがほしいか」、続いて「自分はこういうブラウザです」などの自己紹介が並びます。

GET /news/article.html          ← 「これがほしい」(リクエスト行)
Host: www.example.com           ← 「どのサーバの?」
User-Agent: Chrome              ← 「私はChromeから来ました」
Accept-Language: ja             ← 「日本語のページがあれば」
                            ← (空行で「以上です」)

このように、 1行目に用件、その下に 追加情報(ヘッダ) が並ぶ、というシンプルな構造です。

GET / POST という名前について: リクエストの先頭にある GET は「取得したい」という意味。フォームに入力した内容を送るときは POST(送信)が使われます。「Webページを見るときは GET、何か投稿するときは POST」と覚えれば十分です。詳しい使い分けは 標準 編で。

HTTPレスポンス(サーバ→ブラウザ)

サーバが返す「これですよ」のメッセージ。先頭に 結果の合図(うまくいったか/失敗したか)、続いて「これは HTML ファイルです」などの説明、最後に 本文(ページの中身そのもの) が入っています。

200 OK                          ← 「うまくいきました」(ステータス行)
Content-Type: text/html         ← 「中身はHTMLです」
Content-Length: 1234            ← 「サイズは1234バイトです」
                            ← (空行で「ここから本文」)
<html>
<body>
<h1>ニュース</h1>...
</body>
</html>                       ← 本文(HTMLそのもの)

レスポンスの先頭にある 200 は「成功」のしるし。もしページが見つからないときは、よく耳にする 404 Not Found という数字が返ってきます。

並べて見る

並べて見ると、リクエストとレスポンスはとても 似た形 をしているのがわかります。両方とも「1行目に用件 → ヘッダ(追加情報) → 空行 → 本文(あれば)」という共通の作り。

リクエスト行 (GET=取得) ヘッダ部(Host, User-Agent…) 追加情報を1行ずつ並べる ボディ部(POST のときだけ) 送信するデータ HTTPリクエスト ステータス行 (200 OK=成功) ヘッダ部(Content-Type…) 追加情報を1行ずつ並べる ボディ部(HTMLや画像など) ページの中身そのもの HTTPレスポンス

図の見方:両者とも同じ「1行目 + ヘッダ + 空行 + 本文」のパターン。違うのは1行目の意味だけ。リクエストは「何がほしいか」、レスポンスは「うまくいったか」。

「ヘッダ」と「本文」って?

HTTP のメッセージは、ヘッダ(管理用の付箋) と 本文(運ぶ中身) の2階建てだとイメージしてください。

第3回(プロトコル)で出てきた 「カプセル化」 を思い出してください。HTTP の世界でも、本文の前に「付箋(ヘッダ)」が付いてくる、という同じパターンが現れています。プロトコルのデザインはどの層でもよく似ているのです。

発展 やってみよう(開発者ツール): 試しに普段使っているブラウザの「開発者ツール」を開き(F12 キーや右クリック「検証」)、「ネットワーク」タブを表示しながらページを更新してみよう。ブラウザが何十個もの HTTPリクエストを送って、何十個もレスポンスを受け取っていることが、本当に観察できます。(開発者ツールはネットワーク単元の中心からは外れる補足です。)

情報Iで覚えることHTTP はブラウザとWebサーバの会話のルール(アプリケーション層のプロトコル)。HTTPリクエスト(ちょうだい)と HTTPレスポンス(これだよ)の往復で1つの部品が運ばれる。

URL を入れてから画面に表示されるまで

アドレスバーに https://www.example.com/news.html と入力して Enter を押した瞬間、ブラウザは目にも止まらぬ速さで いくつもの仕事 を順番にこなしています。ステップで追ってみましょう。
POINT 一見「URL を入れたら出てきた」だけの動作のうしろで、ブラウザは 名前を調べ、サーバへ接続し、HTTP で会話し、受け取ったページを描画する という4種類の仕事をこなしている。

ステップで見る

ブラウザ DNSサーバ 名前↔IPの帳簿 Webサーバ 1 URL入力 入力されたURL https://www.example.com/news.html 2 名前→IP問い合わせ 3 接続 4 HTTPリクエスト: GET /news.html 5 HTTPレスポンス: 200 OK + HTML 6 画面に表示
ステップ1.URL を入力する
あなたが https://www.example.com/news.html をアドレスバーに入力して Enter を押します。ブラウザはこの URL を3つの部品(scheme / host / path)に分解します。
ステップ2.名前を IP アドレスに変換(DNS)
ブラウザは「www.example.com っていう名前のサーバ、世界のどこにいるんだっけ?」と DNSサーバ に尋ねます。DNS は名前から IP アドレス(例:93.184.216.34)を教えてくれる「電話帳」のような仕組みです。詳しくは 第5回(DNS) で。
ステップ3.サーバに接続する
IP アドレスが分かったら、ブラウザはそのサーバに対して 「これから話しかけますよ」 と接続のあいさつをします。HTTPS の場合はここで 暗号化のための鍵交換 も行います(後述)。
ステップ4.HTTPリクエストを送る
接続ができたら、ブラウザは 「/news.html ください」 という HTTPリクエストを送ります。第4節で見たあのメッセージです。
ステップ5.HTTPレスポンスを受け取る
サーバはファイルを探し出し、「200 OK、これです」 と HTMLを乗せて返します(無ければ「404 Not Found」)。
ステップ6.画面に表示する(描画)
ブラウザは受け取った HTML を読み解き、必要なら 追加で画像や CSS をリクエスト し(=ステップ4・5の繰り返し)、最終的にきれいに整えて画面に表示します。あなたがページを見ている、というのはここまで全部終わった後の話。
1 / 6

図の見方:URL入力からページ表示までは、6ステップに分けて考えるとすっきりする。多くの場合、ステップ2〜5までが 1秒未満 で終わっている。普段気にしていないが、裏ではこんな会話が高速で行われている。

考えてみよう: もし途中のステップ2(DNS)が止まったら、何が起きるでしょうか? → 名前から IP に変換できない ので、ブラウザは「サーバが見つかりません」というエラーを出します。「インターネットがつながらない」と感じるトラブルの多くは、実はこのステップ2の問題です。

情報Iで覚えることURLを入れてからページが表示されるまで、ブラウザは (1)DNSで名前→IPを問い合わせ → (2)サーバに接続 → (3)HTTPで会話 → (4)受け取ったページを描画 という流れを高速にこなしている。

1ページ = いくつもの部品の組み合わせ

実は、Webページは 1つのファイルだけ でできているわけではありません。HTML という骨組みのファイルを核にして、その中で「この画像も使ってね」「この見た目の指示書も読んでね」と 別のファイルを呼び出している のです。だから1ページの表示で HTTPの会話が何回も行われる ことになります。
POINT Webページを構成する代表的な部品:
HTML = ページの 骨組み(見出し・段落・リンクなどの構造)
CSS = ページの 見た目(色・フォント・レイアウト)
画像 / 動画 = 写真・イラスト・ロゴ・動画
JavaScript = ページに 動き をつけるプログラム
これらを HTML が「使ってね」と並べる。

ページが組み立てられる流れ

HTMLを受け取り、HTMLに書かれた部品を追加で取りに行く ブラウザ Webサーバ 保存されているファイル index.html style.css photo.jpg app.js 1. GET /index.html 2. index.html が返る HTML を受け取る 3. 参照を読む <link> style.css <img> photo.jpg <script> app.js 4. CSS・画像・JSを追加リクエスト 必要な部品が返る 部品ごとに HTTP の往復が起きる 5. そろった部品で画面を組み立てる
ステップ1. まずブラウザは、ページの出発点になる index.html をサーバへリクエストする。
ステップ2. サーバは HTML を返す。HTML はページの骨組みで、見出し・段落・リンクなどの構造が書かれている。
ステップ3. ブラウザは HTML を読み、CSS・画像・JavaScript など、別ファイルへの参照を見つける。
ステップ4. 見つけた部品をそれぞれ追加で取りに行く。ここで HTTP のリクエストとレスポンスが何回も発生する。
ステップ5. HTML・CSS・画像・JavaScript がそろうと、ブラウザが組み合わせて画面として表示する。
1 / 5

図の見方:ブラウザはまず HTML ファイルを受け取る。HTML の中に CSS・画像・JavaScript などへの参照が書かれているので、それを読んで必要な部品を 追加でリクエスト する。部品がそろったあと、ブラウザが画面として組み立てる。

ブラウザの中で起きていること 発展

Q. ブラウザは何でできていると思いますか? 受け取った HTML をどうやって「絵」にしているのでしょう。自分なりに考えてからクリック。
(以下は Web開発寄りの内容です。情報I基礎では参考程度で構いません。)

つながる知識: リンクをクリックして次のページに進むときも、いま見たのと まったく同じ流れ がもう一度走ります。新しい URL で DNS問い合わせ → 接続 → HTTPリクエスト → レスポンス → 描画。私たちが「ページを移動する」と感じる動作は、実は 「また別のHTTP通信を1セット」 起こしているだけなのです。

情報Iで覚えること1つのWebページは HTML(骨組み)・CSS(見た目)・画像/動画・JavaScript(動き) など複数の部品でできており、それぞれが別々のHTTPリクエストで取得される。

HTTPS:鍵マークの意味

アドレスバーの URL の左に 🔒 鍵のマーク がついていることに気づいたことがありますか? これは HTTPS(HTTP Secure) でやり取りしているという目印です。HTTPS は、いま見てきた HTTP に 「暗号化」 という1枚の保護を加えたものです。
POINT HTTP と HTTPS の違い:
HTTP = メッセージが そのまま 流れる(誰かが盗み見たら読めてしまう)
HTTPS = メッセージが 暗号化されて 流れる(盗み見ても意味不明な文字列にしか見えない)
やり取りされる中身(リクエスト/レスポンス)は同じ HTTP のまま。包んでいる「封筒」が暗号化されているだけ。
ブラウザ サーバ HTTP POST = 入力内容を送るHTTPメソッド POST /login HTTP/1.1 本文: password=secret123 ↑ 通り道で覗くと中身がそのまま読める! ブラウザ サーバ HTTPS x9!@#$kP%a^&*…7zQw3 (暗号化された中身) ↑ 鍵で守られた通信路。盗み見ても意味不明

図の見方:HTTP は通信路が「丸見えのチューブ」。HTTPS は「鍵で守られたチューブ」。中を流れている HTTPメッセージは同じだが、外から見えるかどうかが違う。だからログインや決済をするページでは HTTPS が必須。

なぜ鍵マークが大事なのか

もし HTTP のままパスワードや クレジットカード番号を送ると、途中の経路でそれを盗み見られる可能性があります(無料Wi-Fiなどでは特に注意)。HTTPS なら、暗号化されているので、たとえ通信路で盗まれても 意味のわからない文字列 にしか見えません。

現在の主要ブラウザ(Chrome / Safari / Firefox / Edge)は、HTTPS でないページに「保護されていない通信」と警告を出します。世界中のWebは、この十数年で ほぼ全部 HTTPS に移行しました。

HTTPS のしくみ(暗号鍵をどうやって安全に渡しているのか) は 第8回(暗号の基礎) でくわしく扱います。今回は 「HTTPS = HTTPに鍵をかけたもの」 とだけ覚えておけば十分です。

考えてみよう: URL が http:// で始まるサイトでパスワードを入力するのは、はがきにパスワードを書いて投函する ようなもの。https:// なら 封筒に入れて鍵をかけて 送るイメージ。配達手順(HTTP)は同じでも、外から覗かれるかどうかが大きく違う。

情報Iで覚えることHTTPS = HTTP + 暗号化。アドレスバーの 鍵マーク は通信が暗号化されている目印で、ログインや決済など個人情報を扱うページでは必須。

まとめと用語チェック

SUMMARY 1. WWW = ハイパーテキストでつながった世界中のWebページ群。インターネット上で動く1つのサービス
2. Webは クライアント・サーバ型:ブラウザがリクエスト → サーバがレスポンス
3. URL = scheme(やり方) + host(どのサーバ) + path(中のどこ) でできた住所
4. HTTP はブラウザとサーバの会話の取り決め。リクエストとレスポンスは「1行目 + ヘッダ + 空行 + 本文」の形
5. URL入力からページ表示まで:URL分解 → DNS → 接続 → HTTPリクエスト → HTTPレスポンス → 描画
6. 1ページの中で HTML / CSS / 画像 / JavaScript が組み合わさり、HTTPの往復は何十回も発生
7. HTTPS = HTTP + 暗号化。中身は HTTP のまま、通信路が暗号化されている

用語チェック

用語1行説明
WWW(World Wide Web)インターネット上の、リンクでつながったWebページの集合体。略してWeb
ハイパーテキスト文書中に別の文書へのリンクを埋め込める仕組み
クライアントサービスを「ください」とお願いする側。Webではブラウザのこと
サーバ要求を待っていて応答を返す側。Webサーバはページを蓄えている
ブラウザWebページを表示するためのソフト。Chrome / Safari / Firefox / Edge など
URLWebページの住所。scheme + host + path でできている
HTTPブラウザとWebサーバの会話のルール(アプリケーション層プロトコル)
HTTPリクエストブラウザがサーバに送る「これください」のメッセージ
HTTPレスポンスサーバがブラウザに返す「これですよ/ありません」のメッセージ
ヘッダHTTPメッセージの管理情報部分(本文の前にある付箋)
本文(メッセージボディ)HTTPメッセージで本当に運びたい中身(HTMLや画像など)
HTMLWebページの骨組みを記述する言語(見出し・段落・リンクなどの構造)
CSSWebページの見た目(色・フォント・配置)を指定する言語
JavaScriptページに動きや対話的な機能をつけるプログラミング言語
HTTPS暗号化された HTTP。鍵マークの正体
200 OK / 404 Not Foundレスポンスの結果コード。200=成功、404=見つからない
NEXT: 次回(第7回)は、Web と並んでインターネットの代表的なサービスである 電子メール を扱います。メールの裏側で動いている SMTP / POP / IMAP といったプロトコルがどんな役割をしているのか、HTTP と比べながら学んでいきます。

確認問題

問1. WWW(ワールドワイドウェブ)の説明として最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. インターネットそのもの。両者はまったく同じ意味の言葉である
B. メールをやり取りするための仕組み
C. インターネット上で、リンクで互いにつながったWebページの集合体
D. ブラウザの会社が運営する有料サービスの名前
正解:C
WWW は「インターネット上で動いている1つのサービス」。インターネット(=世界中のコンピュータをつなぐ通信網)そのものではなく、その上に乗っている ハイパーテキストでつながった文書群 を指す。Aは混同しやすい誤り、Bはメール(別のサービス)、Dは無関係。

問2. URL https://www.example.com/news/article.html の www.example.com の部分は何にあたるか。

次の選択肢から最も適切なものを選択してください。
A. scheme(プロトコル)
B. host(ホスト名:どのサーバか)
C. path(サーバ内のどのファイルか)
D. ブラウザの種類を表す情報
正解:B
www.example.com は host 部分で、「世界中のどのサーバか」を表す。https:// が scheme、/news/article.html が path。Dの「ブラウザの種類」は URL ではなく HTTPリクエストのヘッダ(User-Agent)に書かれる別の情報。

問3. ブラウザでWebページを開いたときの基本的な順序として正しいものはどれか。

次の選択肢から最も適切なものを選択してください。
A. ブラウザがレスポンスを送る → サーバがリクエストを返す
B. サーバがリクエストを送る → ブラウザがレスポンスを返す
C. サーバが勝手に最新ページを送りつけてくる
D. ブラウザがリクエストを送る → サーバがレスポンスを返す
正解:D
Webの会話は必ず クライアント(ブラウザ)が先に話しかける。サーバは要求があるまで待っていて、要求が来たらレスポンスで返す。サーバから自発的にページを送ることはない。Aは方向が逆、Bは役割が逆、Cはクライアント・サーバ型の前提と異なる。

問4. 1つのWebページを開いたとき、ブラウザがサーバとやり取りする HTTPリクエスト・レスポンスの回数として、最も実情に近いものはどれか。

次の選択肢から最も適切なものを選択してください。
A. 1ページの中で何十回も(画像や CSS、JSも別々に取りに行くため)
B. 1ページにつき必ずちょうど1回だけ
C. 1日につき1回だけ
D. ユーザがマウスを動かした回数だけ
正解:A
Webページは HTML だけでなく、CSS・画像・JavaScript など 多数の部品 で構成されている。それぞれが別の HTTPリクエストとして取りに行かれるため、1ページの表示で 10〜100回 程度のHTTP往復が起きるのは普通。Bは誤解(HTML本体は1回だが部品はそれぞれ別)、C・Dは無関係。

問5. HTTP と HTTPS の違いについて、最も適切な説明はどれか。

次の選択肢から最も適切なものを選択してください。
A. HTTPS では HTML の代わりに別の言語でページを書かなければならない
B. HTTPS は HTTP のやり取りを暗号化して、通信路で盗み見されても中身が読めないようにしたもの
C. HTTPS の方が必ずページの読み込みが遅くなる(暗号化のため使うべきではない)
D. HTTPS は専用の高速回線でしか動かない、特別な企業向けプロトコル
正解:B
HTTPS は HTTP に「暗号化」という保護を加えたもの。やり取りされるメッセージ自体は HTTP のままで、外側を暗号で包んで通信路を流れる。これにより通信路で盗み見されても意味不明な文字列にしか見えない。Aは誤り(ページの書き方は同じ)、Cは現代では実質的な遅延差はほぼ無視できる、Dも誤り(誰でも普通に使う標準技術)。
← PREV
第5回 DNS の役割
NEXT →
第7回 電子メール