生まれながらにしてインターネットがある世界で育ったデジタルネイティブもそろそろ成人を迎え、
誰もがパソコンやスマートフォンを扱い、インターネットの中で自由に情報を受け取り、発信できることが当たり前の時代になりました。
今日は改めて、ウェブブラウザがウェブページをブラウザに表示するまでの流れを整理してみます。
ウェブページの表示に関係する登場人物
ウェブブラウザがウェブページにアクセスし、その情報が画面に表示されるまでには、通常以下のような登場人物が関係してきます。
- ウェブブラウザ
ウェブページを呼び出し、ページを組み立てるソフトウェアで、クライアントとも呼ばれます。 - DNSサーバ（DNSキャッシュサーバ）
URLとIPアドレスを紐づける役割を果たします。 - ウェブサーバ
ウェブブラウザがリクエストしたURLから特定されるファイルをウェブブラウザに送るソフトウェアです。 - アプリケーションサーバ
ウェブブラウザがリクエストしたURLから特定されるファイルを生成し、ウェブサーバに渡すソフトウェアです。 - データベースサーバ
アプリケーションサーバと通信してデータを提供したり、受け取ったデータを保存したりするソフトウェアです。
以上をその関係と合わせて図示すると次のようになります。
これから①～⑨について、それぞれ見ていきますが、
その前に、今回は以下のURLを具体例として見ていきたいと思います。
(詳しい方々へ、今回はCDNは存在しないものとしますのでご了承ください。)
また、説明に入る前にURLの構成についても整理したいと思います。
URLの構成要素
URLはUniform Resource Locatorの略称で、要求するリソースを一意に特定するための住所であり、次の要素から構成されます。
[プロトコル]://[ホスト部](:[プロトコル])(/[ファイルパス])
※丸括弧の箇所は自明の場合は省略されます。
今回の具体例では次のようになっています。
仮に今回の具体例を省略せずに記載すると次のようになります。
試しにブラウザに入力してみると、上の省略形のURLにリダイレクトされて同じページが表示されるはずです。
※リダイレクトの理屈は本題から外れますので今回は割愛します。
少し解説します。
プロトコル
システムの世界で「通信手順を定めた約束事」のようなもので、これからHTTPSというルールで通信を開始することを宣言しています。
プロトコルの末尾がSになっているものは大抵暗号化プロトコルであることを意味し、HTTPSの場合はHTTPを暗号化したものであることを意味します。
ホスト名
ウェブサーバ（ホスト）を特定する名前です。
インターネットの世界ではIP（Internet Protocol）と呼ばれる32bit（IPv4）または128bit（IPv6）の識別子でサーバを特定しますが、このような識別子を人間が直接使いこなすことは困難であることから、一般的にはそれらと紐づけて人間が理解しやすいようにしたホスト名が用いられます。
そして、ホスト名とIPアドレスの関係はDNSサーバ（またはその情報をキャッシュしたDNSキャッシュサーバ）が保持しており、ホスト名からIPアドレスを取得することを「名前解決」と呼びます。
たまに、企業内のシステムなどでIPアドレスで運用されているシステムを見かけることがあります。
仮想ホスト形式で１つのウェブサーバが複数のウェブサイトをホストしている場合は例外がありますが、基本的にはIPアドレスが分かればウェブサイトは表示可能ですし、直接IPアドレスを指定してアクセスする方が、①②の手順を省略する分、理論上は高速です。
ポート番号
ウェブサーバでは、ウェブサービス以外にも様々な内部サービス、外部サービスが起動しています。
TCP/IPネットワークの下では他のホストにアクセスする際にはIPアドレスの他にポート番号を指定することで、何のサービスを要求しているのかを明確にします。
IPアドレスが外線番号だとすると、ポート番号は内線番号のようなものです。
どのサービスをどのポート番号で起動するかはウェブサーバ側で自由に決めることができるのですが、システムの世界にはウェルノウンポートと呼ばれる「良く知られたポート番号」があり、「普通このサービスはこのポート番号で起動する」というのが決まっています。
HTTPやHTTPSは正にその代表例であり、HTTPは80、HTTPSは443と決められています。
そのため、プロトコルにHTTPSを指定した場合で、ポート番号を明示しなかった場合は、443が指定されたものとサーバ側で判断して処理を行います。
インターネットで一般公開されるウェブサーバを前提とすると、ウェルノウンポート以外のポートでサービスを稼働させた場合、一般的なクライアントは稼働ポートを知り得ないため、アクセスすることが困難となります。
そのためクライアントであるウェブブラウザの立場から見ると、ごく一部の例外的なケースを除き、通常ポート番号は省略されます。
ファイルパス
ウェブサーバ上にホストされているファイルを特定するためのファイルパスとなります。
このファイルパスはウェブサーバの「ルートドキュメント」と呼ばれるディレクトリ（フォルダ）を起点とした相対パスで表され、サブディレクトリ内にあるファイルを要求する場合はスラッシュで区切って指定します。
パラメータ
今回は詳しい説明を省略しますが、ファイルパスの後ろに”?”を挟んで引数を渡すことができます。
ウェブサーバは引数を受け取った場合、アプリケーションサーバに対してファイルと合わせて引数を要求条件として引き渡します。
だいぶ長くなりました。。
さて、ここから漸く①～⑨のお話です。
先ほどと同じ図になりますが、もう一度掲載しておきます。
ウェブブラウザがウェブページを表示するための流れ
①ホスト名の名前解決依頼
ブラウザがホスト名に対応するIPアドレスの情報を持っていない場合、DNSサーバに対してホスト名の名前解決を依頼します。
ブラウザが名前解決を要求するDNSサーバは通常、端末の設定やネットワークのプロキシ設定により定義されています。
また、例えばWindowsパソコンにはhostsファイルというファイルがあり、任意のホスト名とIPアドレスを対応させるための設定を定義することが出来ます。
余談となりますが、hostsファイルやDNSサーバのレコードが意図せず書き換えられた場合、名前解決の結果として偽のIPアドレスが回答されることになります。このような不正行為はDNSスプーフィングと呼ばれます。
②該当するサーバのIPアドレスを回答
ウェブブラウザから名前解決依頼を受けたDNSサーバは管理している情報を検索し、該当するIPアドレスがあればそれを回答します。該当するホスト名が管理DBに存在しない場合、DNSサーバは更に上位のDNSサーバに照会し、該当するIPアドレスが得られた場合にはそのIPアドレスを回答します。
③ファイルの要求
ここまでで問い合わせ先のホスト名が特定できたので、次にウェブブラウザはウェブサーバに対してファイルの要求を行います。
④ファイルの作成要求
今日のウェブサーバは静的なHTMLファイルだけをホストしていることは稀であり、多くの場合は何らかのアプリケーションサーバと連動して動的なページを生成しています。
ウェブサーバはウェブブラウザから要求されたファイルがが、自身が直接管理している静的ファイルである場合には、そのファイルを直接返しますが、それ以外の場合はウェブブラウザから要求されたファイルパスを条件にアプリケーションサーバにファイルの作成を要求します。
⑤ファイルに含めるデータの要求
ウェブサーバから要求を受け取ったアプリケーションサーバはプログラムに基づいてファイルの生成処理を行いますが、多くのケースではアプリケーションサーバのプログラムはファイルのひな型を作成する役割を担い、そこに充て込むデータはデータベースサーバで管理されています。
そのため、プログラムの中で適宜データベースサーバと通信を行い、データを要求する処理が行われます。
この要求はデータベースサーバがRDBMSの場合はSQLという言語によって行われます。
⑥データの提供
データの要求を受け取ったデータベースサーバは、要求された条件に従ってデータベース内を検索し、検索結果をアプリケーションサーバに回答します。
⑦ファイルの提供
データベースサーバからデータの提供を受けたアプリケーションサーバはプログラム処理を継続してファイルを完成させ、そのファイルをウェブサーバに回答します。
ここでの回答は一般的には実ファイルを伴わないソケット通信などの形で行われます。
⑧ファイルの提供
アプリケーションサーバからファイルを受け取ったウェブサーバは実ファイルを生成し、ウェブブラウザに回答します。
⑨画面の描写
実はウェブブラウザで行われる最後のこの処理が重要なのですが、これまでの手順を通じて受け取ったファイルはHTMLファイルであり、テキストファイルとして開くとわかるように、画面そのものではありません。
実はウェブページはHTMLファイルという設計図をウェブブラウザが描写（レンダリングとも言います）して初めて人間が視覚的に理解できるものになります。
そしてこの描写の仕方にはウェブブラウザによって若干の方言があるため、「Chromeではちゃんと見えるのにEdgeだとレイアウトが崩れる」といったような現象が起こるのです。
また、ウェブページを描写するためにはHTMLファイルだけでなく画像ファイルやスタイルシート、javascriptファイルなど様々なファイルが必要であり、①～⑨の手続きは実は何度も繰り返されます。
具体的には1回目にHTMLファイルを受け取った後、ウェブブラウザはそのHTMLファイルを上から解釈していきます。そして解釈の途中で他のファイル（例えば画像ファイル）が必要なことが書かれていた場合は、解釈を中断してそのファイルを取得するため、再度①～⑨の手続きを行います。この作業を延々と繰り返し、必要なファイルをすべて取得し、その結果を描写しきってようやく処理の完了となります。
※実際には各々でキャッシュという概念があるため、すべての手順が繰り返されるわけではありません。また、HTML/1.1の次の規格として普及が始まっているHTTP/2ではウェブブラウザが要求する前にサーバからファイルをプッシュする機能が実装されているなど、この手順は今後変化していく可能性があります。
以上、とても長くなりましたが、若干枝葉の議論は残るものの、
自分なりに一定の整理が付いたので良しとします。