自分自身の学習記録として記録しています。
今回は「Webサービス」についてです。
独学エンジニアで学んだことを記録しています。
私たちの暮らしを豊かにしているWebサービスですが、
そもそもどのような仕組みで動いているのかをご存知でしょうか？
また、どのようなルールが存在し、
どのようにしてアプリケーションが動いているのか知っていきましょう。
※私をはじめ初学者の方は知っておくと勉強の基礎として役立てていただけます。
この記事は以下の構成で記載していきます。
ざっと見ていただき、言葉で説明できるようであれば飛ばしていただいて結構です。
わからない方は、だいぶ噛み砕いた説明になりますが参考になさってみてください。
1.Webの歴史
2.Webを支える技術
3.URIとは
4.HTTPとは
5.通信の届く仕組み
6.HTTPメソッドについて
7.HTTPステータスコード
8.Webアプリケーションの構成要素
1.Webの歴史
そもそも私たちがよく知る「インターネット」はアメリカの国防総省により1969年に原型が誕生しました。
※ちなみにインターネットとは世界中のコンピュータ同士を相互接続したネットワーク網のことを指します
当時は大学教授や研究者のみがインターネットを利用しており、一般の方には普及していませんでした。
理由としてはコンピューターやネットワーク資源が高価であることや、
用途がファイルの転送やメール送信など機能が地味であり、不便と言ったことが挙げられます。
研究者たちは研究成果等を共有する際、都度のファイル転送や資料の検索に時間がかかっていたのですが、
それらをより改善することができないかと考え、誕生したのが「Web」です！
「WWW（World Wide Web）」は1989年にCERN（欧州原子核研究所）に在籍していた、
ティム・バーナーズ・リー氏によって開発されました。Webはインターネット（ネットワーク網）を
利用してHTMLで書かれた文書などの情報を公開・閲覧するための”仕組み”です。
今ではよく知られているWebはあくまで仕組みのことを指しているというのは意外ですよね。
Webの誕生により、研究者たちは研究成果をHTMLという統一された書式で記載するようになり、
そこにハイパーテキストという仕組みを使用するようになりました。※ハイパーテキストはリンクのことですね
その結果、インターネット上に公開された研究成果にはリンクがあり、それをクリックすれば
参考文献等も探す手間などが無くなり、お互いの情報共有等も簡単に閲覧できるようになったのです。
ただ、当時はテキストのみの表示しかなく非常にWebページ自体も質素なものでした。
ですが、「Mosaic」というブラウザの誕生により、画像も表示されるようになった事や、
そもそものHTML自体の構造も難しくなかったため、一般の方の興味を引くようになっていきました。
その事により、多くのかたがWebの技術進歩に貢献する事で進化を続けてきたのです。
その後、パーソナルコンピュータの普及やネット回線の改善、スマホの登場などにより、
現在に至るようにWebは爆発的な進化を遂げてきました。これがざっくりとしたWebの歴史です。
2.Webを支える技術とは
ではWeb自体はどのような技術で構成されているのでしょうか。
大きく分けてWebは３つの技術に支えられています。
①URI...HTML上に記載されたリンクの宛先（URLと思ってもOK）。情報の場所のこと。
②HTML...Web上で見ることができる共通の書式のこと
③HTTP...プロトコル（約束事の１種）。情報の取得や公開の際の事前の取り決め。
そもそもWebの構造はどのようになっているのでしょうか。
Webの構造はサーバー・クライアントモデルになっています。
単純ですが、クライアント（依頼人）のリクエストに対して、
サーバー（対応者）にレスポンスを返す構造ですね。
つまり、
①どのデータが欲しいか → URI
②データは何か → HTML
③データのやり取りはどうする → HTTP と言った感じですね。このような技術でWebは成り立っています。
ではここでWebを情報システムとしてみた際はどうなるでしょうか。
大きく分けて、「ハイパーメディア」と「分散システム」に分けることができます。
ハイパーメディア・・・文書や画像、映像などをハイパーリンクで結びつけたシステム。高機能だが扱いが難しい
分散システム・・・複数のコンピュータで処理をこなすシステム。決まった内容しかやり取りできない閉じたシステム。
これらをWebが改善し、シンプルに誰でも（HTML）、様々なコンテンツを不特定多数の人が所持しているマシンに依存することなく（HTTP・URI）見ることができるようになりました。
このよう
3.URIとは
URI（Uniform Resource Identifier）。
URIはインターネット上のデータを一意に特定するための仕組みのこと。
クライアントがサーバーに対して「〇〇のデータちょうだい！」と指定するために使用するものですね。
URIはスキーム、ホスト名、パス名から構成されています。
例
http(スキーム)://example.jp(ホスト名)/usr/index.html(パス名)
スキーム・・・データを取得するための方法（HTTP、HTTPSなど）
ホスト名・・・データが存在するコンピュータの名前。※ホストとはインターネットにつながっているコンピュータのこと
パス名・・・ホスト名で指定されたコンピュータ上にあるデータの位置のこと
URIを用いることで「どのコンピュータの、どのディレクトリの、どのファイル」が特定できるようになる。
さらに、URIにはポート番号、クエリパラメータ、URIフラグメントをつける事ができます。
例
http: //example.jp：50080(ポート番号)/usr/index.html?tag=top(クエリパラメータ)#middle(URIフラグメント)
ポート番号・・・どのアプリケーション宛か指定する際に使用、PCの中にあるアプリケーション指定する際は必要だが省略もできる
クエリパラメータ・・・？の後に名前＝値が続き、パラメータを渡す。検索パラメータを使用する際などに使う。
URIフラグメント・・・URIリソースのさらに具体的な部分の指定。目次のリンクなどクリックしてその場所に移動する際などがよくある例。
URIはクライアントとサーバーがやり取りする際は必須のものです。
これによりサーバー上、インターネット上のファイルの特定などが非常に容易になりました。
4.HTTPとは
HTTP(Hyper Text Transfer Protocol)。
Web上でクライアントとサーバーが通信する際のプロトコル（約束事）。
お互いのOSやマシンの構成などが違ったとしても、決まった形式でやりとりをすることを決めておけば、
内容を理解し合う事ができますよね。※要は事前に決まったフォーマットでやりとりしよう！というルールです
では具体的にどのような決まり事があるのでしょうか？
クライアントはサーバーに対し、HTTPリクエストを投げ、サーバーはHTTPレスポンスをクライアントに返します。
実はHTTPというのは決められた書式に則って、テキスト情報をやり取りするよ！というものになります。
やり取り内容に関しては細かく書くと長くなってしまうので割愛します。
ちなみにHTTPの構造を見るのは、クロームの検証ツール内「Network」から内容を見る事ができます。
5.通信の届く仕組み
HTTPなどを使用する事で、なぜサーバーに通信が届くのかをざっくりと見ていきましょう。
クライアントがHTTPリクエストをすると、宛先を特定し、TCP/IPがデータを小分けにして送信します。
①宛先の特定
HTTPリクエスト内のHostに記載されている箇所からドメイン名を取得し、
DNSでIPアドレスに変換し、サイトの宛先を特定する。
※ドメイン名とはインターネット上で使われるユニークな名前の事（IPアドレスだと覚えにくいので）
※DNSとは、ドメイン名をIPアドレスに変換する仕組み事です。
サーバーにアクセスする前にDNSサーバーにアクセスして、IPアドレスを教えてもらっています
※IPアドレスとはインターネット上の住所のようなもの。ネットワーク上の機器を識別するためのものです。
実際はIPアドレスに合わせてつくポート番号を確認する事で、どのアプリケーション宛かを確認します。
例：IPアドレス（会社の住所）。ポート番号（担当者の氏名）みたいなニュアンスです。
②小分けにして送信
宛先が特定できたら、リクエスト内の情報をサーバーに対して送信する。
※TCP/IPとはインターネットを構築する上で必要なプロトコル群の総称のことを指します。
特定した宛先へ通信を届ける役割などを担っています。（郵便配達員のようなイメージです）
※小さく小分けしたデータをパケットと言います。
※一度に大きなデータを送る際に途中でエラーなどが発生すると再送にも時間がかかってしまうため、
小分けにすることで万が一エラーが起きても小さいデータを再送するだけなので、時間があまり
かからなくなるため結果的に効率が良いからです。
以上の２つの手順で、場所の特定とデータの通信を行っています。
6.HTTPメソッドについて
HTTPメソッドとは、リソース（URIを持っているWeb上の情報）に対して行いたいアクションの種類のことです。
以下の９種類です。
GET...リソースの取得
POST...リソースの作成
PATCH...リソースの部分修正
DELETE...リソースの削除
PUT...リソースの更新
HEAD...リソースのヘッダ取得
OPTIONS...リソースの利用可能なメソッドの取得
TRACE...リクエストメッセージを返す試験を実行
CONNECT...プロキシ動作のトンネル接続への変更
よく使うのは最初の４つです。PATCHとPUTは似てますが一部変更が全て変更かの違いです。
このシンプルさ故に、Webは広まっていったと言われています。
7.HTTPステータスコードについて
これらは、HTTPリクエストが正常の完了したかを示すレスポンス３桁の数字のことを言います。
ステータスコードによって、ブラウザの表示内容が変わるので適切に使える事が大切です。
ステータスコードは先頭の数字によって、大きく５つに分類できます。
1xx ... 情報 リクエストを受け取って処理中という状態
2xx ... 成功 リクエストが成功
3xx ... リダイレクト 他のリソースへアクセスする際など
4xx ... クライアントエラー クライアント側の問題を表示
5xx ... サーバーエラー サーバー側に問題を表示
その上でよく使われるものは以下の物になります。
リクエストが成功したことを表す
200 ... OK ...成功しました！という意味
201 ... Created ... 作ったよ！という意味
204 ... No Content ...返す物ないよ！という意味
リダイレクトを表す。追加の処理が必要
301 ... Moved Permanently ... URI変わったよ！という意味
クライアントエラーを表す。リクエスト側の問題のことです。
400 ... Bad Request ... お前さん、リクエスト間違ってるぞ？という意味
401 ... Unauthorized ... お前さん、何者？という意味
403 ... Forbidden ... お前さん、お前さんはダメだよ？という意味
404 ... Not Found ... お前さん、それないよ？という意味
サーバーエラーを表す
500 ... Internal Server Error ... わし、調子悪いという意味
503 ... Service Unavailable ... 忙しすぎて目が回ってますという意味
ざっくりで良いので上記を覚えておくとエラーが起きた際に状況把握に便利ですね。
8.Webアプリケーションの構成要素
Webアプリケーションはよく３層構成と言われています。
これらを知っておくと、アプリケーションを俯瞰して見ることができるようになると思います。
1.Webサーバー
2.アプリケーションサーバー
3.データベースサーバー
当初はWebサーバーのみの構成でした。
静的なコンテンツ（内容に変化がない）を配信するのみでしたので、これでも十分でした。
現在でも静的コンテンツのみを配信しているサイトなどはあります。
※会社のHPやLPなど
しかし、ECサイトなどでは在庫状況などが把握できていないと困ります。
そのためWebアプリケーションの追加により、動的なコンテンツ（内容に変化がある）が配信できるように
なりました。※表示内容をその時々で変えられるようになったわけです
例：Amazonなどのユーザーによっておすすめ商品を変えて表示する場合など
しかし、大量のデータを扱う場合などは効率的ではありません。そこで生まれたのがデータベースです。
データベースの追加により、大量のデータを効率的に検索、安全に保管できるようになりました。
ですが、Webサーバー内に全てを格納して運用すると、ユーザーが増えたり、在庫が増えすぎたりすると
サーバーのディスク容量を圧迫し、レスポンスの遅延やサーバーダウンなどを起こしかねません。
そのため、DBサーバーを別に設け、それぞれのサーバー内で処理を分離することで負担を軽減します。
また、それぞれのWebサーバー内でDBを持つよりもDBサーバーを分離することでデータを１箇所で
統一的に管理することもできるようになります。
しかし、これでもアクセスが大量に集中すると（静的コンテンツと動的コンテンツのリクエスト）、
一つのWebサーバー内で完結する事が難しくなります。そこで対策としては、Webサーバーと
アプリケーションサーバーに更に分けます。
Webサーバーでは静的なコンテンツを受け取り処理を行いますが、動的なコンテンツのリクエストが
あればアプリケーションサーバーに依頼し処理をしてもらいます。
言ってしまえば状況に合わせた役割分担を行い、効率的に処理をこなしていくわけですね。
このように３つのサーバーに分かれた構成を3層構成と言います。
役割ごとにサーバーを特化させる事で、システムの拡張性が増すわけですね。
※もちろん、レスポンスの向上や動作の安定性を確保する意味でもGoodです
何でもかんでも３層構成にすれば良いというわけではありませんので、
システム要件をしっかりと定義し、それを満たせる構成を考えた上で設計してきましょう！
長々とかいてしまいました。
自身が見直した際に分かりやすく掻い摘んで書いているだけなので、
読む方によっては見辛く感じるかもしれません。また誤りがあればお教え頂けると幸いです。
ご覧いただきありがとうございました。