簡単にわかる Web サーバーの仕組み？
簡単にわかる Web サーバーの仕組み？
2021年5月26日
簡単にわかる Web サーバーの仕組み？
Web サーバーはインターネットなどのネットワーク上で Web サイトのサービスを提供するためのサーバーです。「サーバー」という言葉はよく利用されますが、簡単に言えば「何かのサービスを提供する」という意味です。 Web サーバーの場合は、インターネットの Web サイトの仕事を提供する「物」ということになります。
実際は、Web サイトのサービスを提供するためのシステム（コンピュータとソフトウエア）をまとめて Web サーバーと呼ぶ場合が多いようです。
Web サイトの仕組み
Web サイトの仕組みを簡単に説明すると、Web サイトの情報を保存しているコンピュータとその情報をネットワークを通じて提供するためのソフトウエアで成り立っています。
Web サーバーはネットワークを経由して送られてくる、Web ブラウザからのリクエストに対して、リクエストされたページ（これが URL と呼ばれる物です）の情報を提供するようになっています。このネットワーク上で Web ブラウザと Web サーバーでやり取りするための仕組みを「プロトコル」と読んでいて、Web サーバーの場合「HTTP」というプロトコルを利用しています。
Web ブラウザが表示できるのは、「HTML」と呼ばれる方法で書かれた情報です。従って、基本は、要求された HTML の情報を渡すのが Web サーバーの仕事になります。
HTML ファイルには、その体裁を記述した CSS ファイルや、画像（写真や動画、イラスト）のファイル、また Javascript のファイルなどが含まれているので、そうした情報も一緒に Web サーバーに送っています。
シンプルな Web サイトの場合は、HTML のファイルや必要な CSS ファイルや、画像情報、Javascript のファイルを予め保存しておいて、指定された HTML とそれに付随する情報を提供しています。
Web ブラウザは、Web サーバーからの情報を受け取って表示を行います。 表示する際に、付随する画像を表示したり、画面の体裁を読み込んだりして、送られてきた Javascript を実行するという感じです。
Web サイトの仕組みを簡単に説明すると、Web サイトの情報を保存しているコンピュータとその情報をネットワークを通じて提供するためのソフトウエアで成り立っています。
Web サーバーはネットワークを経由して送られてくる、Web ブラウザからのリクエストに対して、リクエストされたページ（これが URL と呼ばれる物です）の情報を提供するようになっています。このネットワーク上で Web ブラウザと Web サーバーでやり取りするための仕組みを「プロトコル」と読んでいて、Web サーバーの場合「HTTP」というプロトコルを利用しています。
Web ブラウザが表示できるのは、「HTML」と呼ばれる方法で書かれた情報です。従って、基本は、要求された HTML の情報を渡すのが Web サーバーの仕事になります。
HTML ファイルには、その体裁を記述した CSS ファイルや、画像（写真や動画、イラスト）のファイル、また Javascript のファイルなどが含まれているので、そうした情報も一緒に Web サーバーに送っています。
シンプルな Web サイトの場合は、HTML のファイルや必要な CSS ファイルや、画像情報、Javascript のファイルを予め保存しておいて、指定された HTML とそれに付随する情報を提供しています。
Web ブラウザは、Web サーバーからの情報を受け取って表示を行います。 表示する際に、付随する画像を表示したり、画面の体裁を読み込んだりして、送られてきた Javascript を実行するという感じです。
URL とは何か？
URL は、Web ブラウザが Web サーバーにリクエストを送る際に指定するもので、この中に、Web サーバー（コンピュータ）の場所と、表示するページの場所が含まれています。
このサーバーの場所を示すのが「ドメイン」と呼ばれるものです。このドメインは「世界で一つ」なので、どのサーバーか特定できるようになっています。実はこのドメインは「ニックネーム」のようなものです。実は、サーバー（コンピュータ）には、住所に相当する番号が割り当てられていて、これを「IP アドレス」と読んでいます。ドメインは人間にわかりやすいように、IP アドレスをドメイン名というニックネームに置き換えて使っています。このドメイン名を IP アドレスに変換する仕組みがあって、これが DNS（Domαin Name Service:ドメインネームサービス）と呼ばれるものです。
このニックネームから住所に変換する仕事をしているサーバーがあって、このサーバを DNS サーバーと呼んでいます。インターネットにアクセスする端末（PC やスマホ）にも IP アドレスが割り当てられていて、最近はほとんどの場合、ネットワークに接続すると自動的に割り当てられるようになっています。（この仕組みは DHCP サービスと呼ばれています。）
IP アドレス（住所）だけではなく、ドメインはその IP アドレスに辿り着くための経路もわかる様になっています。これをルーティングと呼んでいますが、実際には効率的に転送を行うためにいろいろ工夫がされていますが、基本は「バケツリーレー」で情報が伝達される仕組みになっています。
ドメインの名前は、「abc.co.jp」の様に「.(ドット)」で区切られていますが、これは実際の住所に似ていて、「XXX 県 OOO 市###１ − ２ − ３」の様な記述と似ています。 「jp(日本)/co(企業)の abc というコンピュータ」という感じになります。従って、このサーバーにアクセスするには、まず日本に送って、その中の企業担当に転送されて、そこから abc というコンピュータに転送されるようになっています。
いつも手軽に利用している Web サイトですが、裏方では結構色々な仕組みを組み合わせて目的の情報を取得しています。
URL は、Web ブラウザが Web サーバーにリクエストを送る際に指定するもので、この中に、Web サーバー（コンピュータ）の場所と、表示するページの場所が含まれています。
このサーバーの場所を示すのが「ドメイン」と呼ばれるものです。このドメインは「世界で一つ」なので、どのサーバーか特定できるようになっています。実はこのドメインは「ニックネーム」のようなものです。実は、サーバー（コンピュータ）には、住所に相当する番号が割り当てられていて、これを「IP アドレス」と読んでいます。ドメインは人間にわかりやすいように、IP アドレスをドメイン名というニックネームに置き換えて使っています。このドメイン名を IP アドレスに変換する仕組みがあって、これが DNS（Domαin Name Service:ドメインネームサービス）と呼ばれるものです。
このニックネームから住所に変換する仕事をしているサーバーがあって、このサーバを DNS サーバーと呼んでいます。インターネットにアクセスする端末（PC やスマホ）にも IP アドレスが割り当てられていて、最近はほとんどの場合、ネットワークに接続すると自動的に割り当てられるようになっています。（この仕組みは DHCP サービスと呼ばれています。）
IP アドレス（住所）だけではなく、ドメインはその IP アドレスに辿り着くための経路もわかる様になっています。これをルーティングと呼んでいますが、実際には効率的に転送を行うためにいろいろ工夫がされていますが、基本は「バケツリーレー」で情報が伝達される仕組みになっています。
ドメインの名前は、「abc.co.jp」の様に「.(ドット)」で区切られていますが、これは実際の住所に似ていて、「XXX 県 OOO 市###１ − ２ − ３」の様な記述と似ています。 「jp(日本)/co(企業)の abc というコンピュータ」という感じになります。従って、このサーバーにアクセスするには、まず日本に送って、その中の企業担当に転送されて、そこから abc というコンピュータに転送されるようになっています。
いつも手軽に利用している Web サイトですが、裏方では結構色々な仕組みを組み合わせて目的の情報を取得しています。
サーバーでの処理は？
Web サーバーまでリクエストが届くと、サーバーはどの情報が要求されているかを見てその情報をリクエスト元に送り返すという仕事をしています。
「abc.co.jp/test.html」と指定されただけの場合は、そのサーバーの「test.html」のファイルと、その中で使われている他のファイルと一緒にリクエスト元に送ります。郵便と同じでリクエスの中にはリクエスト元の IP アドレス（住所）が入っているので、その IP アドレス宛に情報を返送します。
シンプルなサイトの場合は、単に HTML のファイルとそれに付随する情報を返すだけですが、Next や Nuxt などのようにサーバーでレンダリングする場合は、リクエストされた「場所」に相当する「HTML」の情報をサーバー側で作ります。 この場合は、「HTML ファイル」はサーバーにないので、相当する HTML の情報をデータベースからデータを取り出したり、計算したりして、必要な HTML の情報を作って渡します。
Web ブラウザで表示する HTML の情報は以下の３つに大きく分けられます。
- 予め HTML ファイルを作成してサーバーに置く（静的ファイル、静的コンテンツ）
- Web ブラウザで Javascript を実行して作成（フロントエンドレンダリング）
- Web サーバーで作成して Web ブラウザに送る（サーバーサイドレンダリング）
の３種類です。
フロントエンドレンダリングでは、HTML の雛形を用意しておいて、そこにダウンロードしてきた Javascript で中身を作成して雛形に埋め込むという処理を Web ブラウザで行っています。
Web サーバーまでリクエストが届くと、サーバーはどの情報が要求されているかを見てその情報をリクエスト元に送り返すという仕事をしています。
「abc.co.jp/test.html」と指定されただけの場合は、そのサーバーの「test.html」のファイルと、その中で使われている他のファイルと一緒にリクエスト元に送ります。郵便と同じでリクエスの中にはリクエスト元の IP アドレス（住所）が入っているので、その IP アドレス宛に情報を返送します。
シンプルなサイトの場合は、単に HTML のファイルとそれに付随する情報を返すだけですが、Next や Nuxt などのようにサーバーでレンダリングする場合は、リクエストされた「場所」に相当する「HTML」の情報をサーバー側で作ります。 この場合は、「HTML ファイル」はサーバーにないので、相当する HTML の情報をデータベースからデータを取り出したり、計算したりして、必要な HTML の情報を作って渡します。
Web ブラウザで表示する HTML の情報は以下の３つに大きく分けられます。
- 予め HTML ファイルを作成してサーバーに置く（静的ファイル、静的コンテンツ）
- Web ブラウザで Javascript を実行して作成（フロントエンドレンダリング）
- Web サーバーで作成して Web ブラウザに送る（サーバーサイドレンダリング）
の３種類です。
フロントエンドレンダリングでは、HTML の雛形を用意しておいて、そこにダウンロードしてきた Javascript で中身を作成して雛形に埋め込むという処理を Web ブラウザで行っています。
どこで HTML を作るかで処理の負荷が変わる！
Web ホスティングをするサーバーの性能の話を数日前にポストしましたが、どこで HTML を作るかでサーバーで行う処理の量が変わってきます。
静的なコンテンツを扱う場合は、既にサーバーにおいてあるファイルの中身をリクエスト元に送るだけなので、サーバー側の処理はシンプルです。一度にアクセスが集中するとサーバーに負荷がかかります。従って、考慮するのはどれくらい同時のアクセスがあるかだけです。
これは、フロントエンドレンダリングでも同様で、基本は、ファイルを Web ブラウザに送って Web ブラウザで Javascript を実行してページを作るので、サーバー側の負荷はファイルを送るだけなので、静的コンテンツとあまり変わりません。
ところが、サーバー側でレンダリングをする、つまりサーバー側で HTML を作る場合には、サーバー側の処理が増える事になります。データを準備するための処理や、HTML を作るための処理など、単純にファイルの中身を渡す場合より、処理する内容が増えます。この処理をサーバーで行う必要があるため、静的コンテンツやフロントエンドレンダリングの場合よりはサーバーの負荷が大きくなります。
従って、サーバーサイドのレンダリングを行う場合は、同時アクセスの数に加えて、サーバーの処理の負荷も考慮する必要が出てきます。同時に数件の処理ならば余り問題になることは少ないと思いますが、一度に数万件のアクセスがあると処理の負荷もかなり大きなものになります。
比較的アクセスの少ないサイトの場合は大きな問題ではありませんが、人気のサイトで同時に大量のアクセスが想定されるサイトの場合、ホスティングを行う Web サーバーの性能や負荷を考慮しないと、サーバーの負荷がかかりすぎて処理できない事などが想定されます。特に必要なメモリ容量が十分でないと、サーバー自体の処理ができなくなって、障害に繋がる可能性が高くなります。
従って、一つの処理で想定される使用メモリ容量と、同時に発生するアクセス数も元に必要なメモリ容量を見積もるなどサービスの設計時に考慮する必要が出てきます。こうした問題は、開発時には見えないことが多く、試験が十分でない場合や、実際の運用条件に近い環境での試験ができない場合には稼働後に発生する可能性があります。
Web ホスティングをするサーバーの性能の話を数日前にポストしましたが、どこで HTML を作るかでサーバーで行う処理の量が変わってきます。
静的なコンテンツを扱う場合は、既にサーバーにおいてあるファイルの中身をリクエスト元に送るだけなので、サーバー側の処理はシンプルです。一度にアクセスが集中するとサーバーに負荷がかかります。従って、考慮するのはどれくらい同時のアクセスがあるかだけです。
これは、フロントエンドレンダリングでも同様で、基本は、ファイルを Web ブラウザに送って Web ブラウザで Javascript を実行してページを作るので、サーバー側の負荷はファイルを送るだけなので、静的コンテンツとあまり変わりません。
ところが、サーバー側でレンダリングをする、つまりサーバー側で HTML を作る場合には、サーバー側の処理が増える事になります。データを準備するための処理や、HTML を作るための処理など、単純にファイルの中身を渡す場合より、処理する内容が増えます。この処理をサーバーで行う必要があるため、静的コンテンツやフロントエンドレンダリングの場合よりはサーバーの負荷が大きくなります。
従って、サーバーサイドのレンダリングを行う場合は、同時アクセスの数に加えて、サーバーの処理の負荷も考慮する必要が出てきます。同時に数件の処理ならば余り問題になることは少ないと思いますが、一度に数万件のアクセスがあると処理の負荷もかなり大きなものになります。
比較的アクセスの少ないサイトの場合は大きな問題ではありませんが、人気のサイトで同時に大量のアクセスが想定されるサイトの場合、ホスティングを行う Web サーバーの性能や負荷を考慮しないと、サーバーの負荷がかかりすぎて処理できない事などが想定されます。特に必要なメモリ容量が十分でないと、サーバー自体の処理ができなくなって、障害に繋がる可能性が高くなります。
従って、一つの処理で想定される使用メモリ容量と、同時に発生するアクセス数も元に必要なメモリ容量を見積もるなどサービスの設計時に考慮する必要が出てきます。こうした問題は、開発時には見えないことが多く、試験が十分でない場合や、実際の運用条件に近い環境での試験ができない場合には稼働後に発生する可能性があります。
まとめ
この記事では、Web サイトの仕組みを簡単にまとめて見ました。 プログラミングの技術的な側面では、フロントエンドでレンダリングする React や Vue とサーバーサイドでレンダリングするサーバーサイドのレンダリングのフレームワーク Next や Nuxt と大差がないように見えます。
しかし、実際のサーバー側の処理をきちんと理解していないと、稼働した後で問題が発生する可能性があります。特に人気のサイトなど、一度に大量のアクセスがあるようなサイトの場合、サーバー側での処理が多くなると問題に繋がる可能性が高くなります。
Web サービスや Web アプリの開発・設計では、単にプログラミングの知識や技術だけではなく、システム全体をみて無理のない設計をする必要があります。そういう意味でサーバー側でレンダリングを行う Next や Nuxt を利用した本格的な実装にはプログラミングの枠を超えた注意が必要です。
初心者に、フロントエンドでのレンダリングを推奨する理由はこの辺にもあります。Web 開発には、こうしたプログラミングの枠を超えた知識や学習が必須になります！
この記事では、Web サイトの仕組みを簡単にまとめて見ました。 プログラミングの技術的な側面では、フロントエンドでレンダリングする React や Vue とサーバーサイドでレンダリングするサーバーサイドのレンダリングのフレームワーク Next や Nuxt と大差がないように見えます。
しかし、実際のサーバー側の処理をきちんと理解していないと、稼働した後で問題が発生する可能性があります。特に人気のサイトなど、一度に大量のアクセスがあるようなサイトの場合、サーバー側での処理が多くなると問題に繋がる可能性が高くなります。
Web サービスや Web アプリの開発・設計では、単にプログラミングの知識や技術だけではなく、システム全体をみて無理のない設計をする必要があります。そういう意味でサーバー側でレンダリングを行う Next や Nuxt を利用した本格的な実装にはプログラミングの枠を超えた注意が必要です。
初心者に、フロントエンドでのレンダリングを推奨する理由はこの辺にもあります。Web 開発には、こうしたプログラミングの枠を超えた知識や学習が必須になります！
コメント
コメントを投稿