この記事の狙い
Webエンジニアを目指す過程で基礎として必要になってくるWeb技術周りの用語に関してまとめていく。
記事としてまとめアウトプットすることで自分としても整理して覚えよう、というのが狙い。
今回取り扱う用語
上記の用語がわかるように例を交えながら順序立てて説明していきます。
そもそもどうやってWebページを見ているのか
今や皆さん毎日当たり前のようにGoogleで検索したりしてWebページ(Yahoo!とかこのブログとか)を見ていると思います。この流れの中でディスプレイの向こう側ではどのような仕組みで動いてページを表示しているのか、まずは簡単に書いてみましょう。
『クライアント・サーバ』と『リクエスト・レスポンス』
まず、大きく分けて2人がやり取りしてると思って大丈夫です。
その2人とはクライアントとサーバ
クライアント(Client)とは英語で『顧客やお客、依頼人』という意味でイメージとしてはレストランで注文するお客さん。
サーバ(Server)とは英語で『仕える人、給仕人』という意味でイメージとしては注文に対して食事・飲み物等を給仕する・供給してくれる人(＝ウェイター・ウェイトレスさん)。
この場合、
お客さん(クライアント)のがウェイターさん(サーバ)に対して注文する、
これがリクエスト
そのリクエスト(注文)に対してウェイターさん(サーバ)が注文通り食事を給仕する、
これがレスポンス
これをWebに置き換えるとこうなる
Yahoo!のトップページを見たい時
パソコンやスマホを使って皆さん(クライアント)がサーバに、
『Yahoo!のトップページを見せてください(このURLのHTMLをください)』←リクエスト
サーバが『YaHoo!のトップページですね！はいどうぞ(HTMLを返す)』←レスポンス
このやり取りを繰り返してWebページを見ている。
つまり、Webページを見ている間にたくさんのリクエストとレスポンスがクライアントとサーバの間でラリーを続けている感じ。
ちなみにみんな何気なく認識しているURLは、
Uniform-Resource-Locator
の頭文字を取ってURLです。日本語で書くと、『統一資源位置子』
これは日本語に訳したら逆に意味わからんパターンですが、
要は、資源(サーバに置かれているHTMLファイル達)の位置を特定するための統一的な記述方法
って感じですかね。住所みたいなもんです。詳しくは次で
URLとHTTPなどのプロトコルについて
では実際のURLを見ながら。
Yahoo!ニュースのスポーツページのトップ
https://news.yahoo.co.jp/categories/sports
上で書いたように『統一的な記述方法』なのでルールが存在します。
大きく分けて3つ、それぞれに名前がある
https → スキーム
news.yahoo.co.jp → ホスト名
categories/sports → パス名
まずスキーム(Scheme)とは翻訳すると『機構・体系・仕組み』のような意味。
イメージ的には仕組みというか約束事に近く、Recource(サーバにあるHTML)を取得する方法を宣言してる感じ。
httpsっていう方法でHTMLを取りに行くよという風に。
このスキームの部分はいくつか種類がある中で代表的なのを以下にまとめる。見たことある物もあると思う。
| スキーム名 | 説明 |
|---|---|
| http | HyperText Transfer Protocolという意味のhttp通信を表すスキーム |
| ftp | File Transfer Protocolという意味のファイル転送を行うプロトコルを表すスキーム |
| https | Hypertext Transfer Protocol Secureという意味、httpの後ろにs(セキュア)がついておりセキュリティを高めたhttp通信を表すスキーム |
お気づきだと思うが、全て名前内に"プロトコル"が入ってる。プロトコルの意味は公式な規則や手順、みたいな意味
全てプロトコルとしてまとめられたスキームであり、プロトコルは通信方法なのです。
https → https通信を使って
news.yahoo.co.jp → という場所のサーバーの
categories/sports → カテゴリフォルダ内のスポーツ
を入手したい、というリクエストを送ってサーバにレスポンスしてもらう流れです。
この時、どういうスキームで通信したいかのプロトコルをサーバに宣言しないとサーバはどういう方法で返せばいいかわからない、といった感じなのでURLには必ずスキームを書くようになっている。
ポート番号について
プロトコルには対応したポート番号が存在します。
ポート番号は、サーバの中の部屋番号のようなものです。何号室の部屋に行けばいいか、みたいなイメージです。
代表的なプロトコルの場合は予めポート番号が決まっています。これをウェルノウンポートといいます。
| プロトコル | ポート番号 |
|---|---|
| ftp (ファイル転送) | 20,21 |
| HTTP | 80 |
| HTTPS | 443 |
これによりクライアントはサーバの中のどのポート番号にリクエストを送ればよいか迷わずやり取りが出来ます。
HTTPSの場合、443番のポート番号にリクエストを送れば、サーバはHTTPS通信だと認識し、HTTPSのプロトコルに従って解釈して処理を行いレスポンスをする、という流れです。
ウェルノウンポートはスキームで番号が決まっているので大抵のURLでは省略されていますが、省略されているだけで
ステートレスとステートフル
現代人のほとんどはインターネットショッピングを利用したことや、何かしらのサイトでログインをしてその状態でWebサービスを受けていると思います。
ここでいきなりなんですが、httpプロトコルは『状態』を保つことを想定して作られてないのです。どういう意味？と思うと思いますが、簡単に言うとリクエストに対してレスポンスを返して用が済んでしまうのでリセットされる、といった感じでしょうか。
なのでいちいちクライアントのことを覚えていてくれません。先ほど上げたログイン機能を例にすると、ログインのIDとパスワードを渡したらサーバーからはいログインページです、と返されたあともう一度リクエストする際にクライアントがログインしている『状態』を維持できないのです。
ネットショッピングを例にあげれば、買い物かごに商品を入れるリクエストを送ってレスポンスを返してくれても次のラリーでは買い物かごに物が入ってる状態を維持できないため空っぽになってしまいます。
これにより、httpはステートレス・プロトコル(ステートがレス＝状態がない)と呼ばれています。
しかし皆さんのアドレスバーを見ればわかりますが、httpプロトコルを使ったサイトでログインして買い物してますよね？つまり対義語の、
ステートフル・プロトコルを実現してるじゃないかと。
ステートレス・プロトコルなhttpでも状態を維持できるよう、いくつか方法がありそれを活用しています。
Cookie
そこで考えられたのがCookieという技術です。
クライアントからのリクエストに対するレスポンス内にCookieという物を入れ込みます。このCookieにログイン情報(ユーザーID, パスワード)を付随し、Cookieを受け取っとクライアントは同じサーバに次回またリクエストを送る際、Cookieを入れて送ります。サーバー側はCookie内のユーザーID, パスワードを調べることでこのクライアントは誰かを認識し、ログインなどの『状態』を維持できるという技術です。
ちなみに仮にサーバ(A)という名前のサーバからCookie(A)を貰ったとしても、サーバ(A)と違うURLの違うサーバ(B)にはCookie(A)は送らず、別のCookie(B)を貰うため情報が漏れる心配はありません。
セッション
ただし上記の方法だとCookieでも問題点はあります。
Cookieに個人情報であるユーザーID, パスワードを直接入れることになるので、リクエスト・レスポンス内を不正に覗かれると個人情報が簡単に流出してしまいます。
そこで考えられたのが セッション と呼ばれる仕組みです。クライアントはサーバからCookieとしてユーザーID, パスワードではなくセッションIDを付与されます。病院や銀行の受付番号みたいなものです。サーバとしてはそれぞれのセッションIDを誰に渡したか管理しているので番号札(セッションID)を持っていれば認識し、『状態』を維持しながらのやり取りを実現できます。
ちなみに病院や銀行のように『16番』や『355番』のような数字ではなく、桁数の多いランダムな文字列ですので他のユーザーと重複する恐れはありません。
ただし、セッションIDはセッションIDでそれ自体を盗まれる危険性もあり、絶対に安全というわけではないのが難しいところです。
おわりに
以上、初学者が初学者なりにまとめてきました。
自分で書いてるときに再確認と言うか再認識でき、流れがわかってきたと感じています。
皆さんも勉強はインプットだけではなくどこかでアウトプットして効率よく勉強していきましょう。
