はじめに
今回はWebの仕組みついてインプットを行ったので内容の整理も兼ねて記事を作成します。
この記事では普段私達が見ているWebページのデータはどこに存在するのか?
またそれをどうやって特定しているのか?に焦点を当てて紐解いていこうと思います。
データは遠くにあるが繋がっている
私達が普段見ているWebページのデータはWebサーバと呼ばれるコンピュータに保存されています。
Webサーバは世界中に点在しており、Webサーバが相互に接続され情報やデータのやり取りが可能な仕組みをネットワークと呼びます。
このネットワークにWebクライアントと呼ばれるPCやスマホを通して接続し、Webサーバから受け取ったデータをChromeやSafariなどのWebブラウザが画面に描画することでWebページを見ることが出来るのです。
URLとは何なのか
ネットワークのおかげでWebクライアントからWebサーバにアクセスできる事が分かりましたが、データは数あるWebサーバの中の1つに格納されているため、このサーバを特定する必要があります。 その役割を担うのが URL (uniform resource locator)です。
URLは次にように構成されています。
http://www.example.jp/home/index.html
- スキーム (http)
- どの通信プロトコルを使用するかを表します。
- ローカル名 (www)
- Webサーバの名前を表します。
- ドメイン名 (example.jp)
- Webサーバの位置を示します。
- パス名 (/home/index.html)
- Webサーバ内のデータの位置を示します。
主要な用語の説明を行なっていきます。
通信の決まり事
通信プロトコルとはコンピュータ同士が通信を行う上での規則・ルールの事です。
httpの前にTCP/IPの説明を行います。
TCP/IPはネットワーク全体でデータを送受信するための基盤のプロトコルで、データのパケット化(データの分割)やIPアドレスからWebサーバの住所の特定など、ネットワーク通信を行う上で必要不可欠なプロトコルです。
httpプロトコルはこのTCP/IPプロトコルの中の1つで、シンプルなプロトコルである事が特徴です。
このようにhttpはただただリクエストされたコンテンツをレスポンスするだけのシンプルなプロトコルです。
正直プロトコルに関してはルールと言えどざっくりとし過ぎていて、表面上しか理解できていません。
時が来たら勉強したいですね。
Webブラウザに表示されるURLは仮の姿
Webサーバの位置は本来IPアドレスと呼ばれる3桁の数字×4つで構成された番号によって特定できます。
192.168.255.255
ですがURLにその様な数字は見当たりません。
これはIPアドレスが人の目には識別が難しいためドメイン名に置き換えられているからなんです。
当然このドメイン名ではWebサーバの位置を特定できませんので、IPアドレスに変換する必要があります。
そこでDNSサーバと呼ばれるドメイン名とそれに関連付けられたIPアドレスのマッピングを持つサーバに「このドメイン名のIPアドレスを教えてください」と問い合わせることで、DNSサーバがこっそりと教えてくれます。
この問い合わせはユーザが手動で行う必要はなく、リクエスト時に自動で行われます。
普段私たちがあまり目にする事はありませんが、実はまだURLには位置を表す文字が隠されています。 Webサーバの位置とデータの位置まで分かってるのにこれ以上何が必要なんだ!?と驚かれるかもしれませんが、それを理解するためにはWebサーバの構造を知る必要があります。
Webサーバの構造
まずWebサーバはコンピュータであり、それ単体ではレスポンスを返す事は出来ません。 皆さんのPCやスマホもアプリケーションを通して動画を見たりゲームをしたりしますよね。 Webサーバにもアプリケーションが組み込まれており、そのアプリケーションでWebクライアントのリクエストを処理したり、レスポンスを返したりしているわけです。
ややこしいのですが、Webサーバ(コンピュータ)にはWebサーバ(アプリケーション)が入っており、このWebサーバ(アプリケーション)がHTTPリクエストを処理しています。
そしてアプリケーションはWebサーバだけでなく、アプリケーションサーバやデータベースサーバなど複数のアプリケーションが稼働している事が一般的です。
Webサーバ内にはたくさんのアプリケーションが稼働しているんですね。
「Webブラウザに表示されるURLは仮の姿」で説明した通り、URLからサーバの位置、データの位置まで特定する事が出来ましたよね。
ですがこの章でWebサーバ内には複数のアプリケーションが存在する事がわかり新たな問題が生まれます。
そうです。Webサーバの位置を特定してもどのアプリケーションにリクエストを送ればいいのか分からないのです!
この問題に対処するためにURLにはアプリケーションを区別するポート番号が隠されています。
アプリケーション毎に規格化されたポート番号があり、たとえばHTTPは通常80番ポートを使用します。
http://www.example.jp/home/index.html:80
このためスキームとして"http"が指定されている場合、ポート番号":80"は自動的にURLの末尾に追加されるようになっています。
これで本当にデータの位置まで特定する事ができましたね。
次に本来の話の趣旨とはズレますが、Webブラウザがどうやってデータを保持しているか説明します。
Cookieで状態を管理する
httpはシンプルな通信プロトコルであると説明しましたが、そのシンプルさが故に状態を管理する事ができません。
例えばユーザがショッピングサイトでログインページからログインしたとします。ですがhttpは過去の情報を保持していないので、ユーザが新たにリクエストするとWebサーバはユーザがログインしているのか、していないのか判断できないのです。
このように状態を保持しないプロトコルをステートレス・プロトコルといい、逆にFTPなど状態を保持するプロトコルはステートフル・プロトコルと呼ばれます。
ですが普段皆さんが使っているWebアプリではログインすれば商品を買い物カゴに追加できるし、購入することもできますよね。これはCookieと呼ばれる技術でデータを保存しているからなんです。
Cookieの仕組みを説明します。
- Webクライアントはログインデータを含めたhttpリクエストをWebサーバに送ります。(Webサーバにデータを送る方法としてGETメソッド、POSTメソッドが挙げられますがここでは割愛します)
- Webサーバは受け取ったログインデータをユーザリストの照合にかけ、照合が成功した場合Cookieにログインデータを格納します。このCookieはhttpレスポンスヘッダに格納され、Webクライアントへと送られます。
- WebクライアントはhttpレスポンスヘッダからCookieを取り出し、Webブラウザへ保存します。
- 再度Webクライアントがリクエストを送る時に、httpリクエストヘッダから受け取ったCookieをそのまま格納します。
- WebサーバはhttpリクエストヘッダからCookieを取り出し、再びユーザリストの照合にかける事でユーザがログインしているか判断します。
この一連のサイクルにより、一度ログインするとCookieにデータが保存され状態の管理を実現しています。
ここではログイン画面を例に出しましたが、現代ではセキュリティの観点からCookieにユーザIDやパスワードを直接保存する事はありません。
セッションIDと呼ばれるユーザ情報に紐付けられたIDを発行しCookieに保存するのが主流です。
このセッションIDを仮に盗聴されたとしても、紐付けられたデータが無いと何の意味も無いからですからね。
最後に
かなり省略しましたが、Webの基本的な仕組みが少しでも伝わっていれば嬉しいです。
この分野はかなり奥が深いと思うので、少しずつ学習していければいいなかなと思っています。
また学習した際には記事に纏めたいと思います。