①はじめに
ウェブサービスの知識を学んでアウトプットするために記事を書きました。全体の仕組みを知ることでアプリケーションからインフラまで対応できるようになりたいと思います。
②WEBの歴史
webとはインターネットを利用して「文書や画像を公開閲覧できる仕組み」。元々は当時の一部のインターネットを利用した研究者が研究成果や文献を共有することを目的に発展した。元々は共有するため電子メールやファイル転送をインターネットを利用してHTMLとして研究成果を簡単に閲覧できるようになった。これがwebの始まり。
→そのうち、ブラウザの発展によって一般の人に広まった。現在はPCの低価格化、ネット回線の普及、スマホの登場によってwebは爆発的な普及となった。
③WEBを支える技術
webを支えているのが「HTML」、「URI（URL）」、「HTTP」になる
HTMLのアクセス先を示したのが「URL」、「HTTP」が通信するための約束事
webの構造はサーバー／クライアントモデル
webはクライアントがリクエストを送り、サーバーがレスポンスを返す構造になっている
どのデータ？→URL
データは何？→HTML
どうやってデータのやり取りを実施？→HTTP
webは情報システムで見るとハイパーメディアと分散システム
ハイパーメディア：文書、画像、映像などのメディアをハイパーリンクで構築したシステム
分散システム：複数のコンピューターで処理を分担してこなすシステム
④URI（Uniform Resource Identifier）の仕組み
インターネット上のデータを一意に特定するための仕組み。
URIはスキーム、ホスト名、パス名から構成
例：http://example.jp/usr/index.html
スキーム：データを取得する方法 http
ホスト名：データが存在するコンピューターの名前 example.jp
パス名：ホスト名で指定されたコンピューター上のデータの位置 usr/index.html
他にもポート番号、クエリパラメーター、URIフラグメントからなる
Apacheはポート番号80番
クエリパラメータは検索条件など
URIはHTMLのページの位置を特定できる
⑤HTTP（Hyper Text Transfer Protocol）
web上でクライアントとサーバーが通信するときのプロトコル（約束事）。決められて書式に則り、クライアントがHTTPリクエストを送り、サーバーがHTTPレスポンスを返す。
HTTPリクエストメッセージの構造
GET：通信種類。「/」はトップページ
HTTP/1.1：HTTPのバージョン1.1
ヘッダ：ホスト名、ポート番号が書いてある
形式：text/html
HTTPレスポンスの構造
ステータスライン：通信結果（200は通信成功）
HTTPリクエスト、レスポンスはgoogle chomeの検証→ネットワークで見れる
⑥HTTPリクエストが起きると何が起こる？
宛先を特定してドメイン名（インターネット上で使われるユニークな名前）をIPアドレスとポート番号に変換、TCP/IPがデータを小分けにして送信
TCP/IP：インターネットを構築するときに必要なプロトコル群の総称。宛先へ小分け（パケット）にして通信を届ける役割がある
なぜ小分け？→小分けにできないとエラーになるネットワークがあるので小分けにする
⑦HTTPメソッドについて
HTTOメソッドはリソースに対して実行したいアクションの種類を指す以下の4種類がよく使われる
- GET 指定したリソースの情報を取得する。
- POST リソースを作成する。フォームの値をJSON形式で送信するときによく使う
- PATCH リソースの更新を行う。似たようなアクションとして、PUTがある。違いはPATCH一部、PUTはすべて更新する
- DELETE
リソースの削除
⑧HTTPステータスコード
HTTPリクエストが正常に完了したか示すレスポンス。3桁の数字で示され、大きく5種類
- 1XX情報
- 2XX：成功 200（GET成功時）、201（POST成功時）、204（DELETE時） 3XX：リダイレクト
- 301、URI変わった時
- 4XX：クライアントエラー 400：リクエスト違い 401：認証されてないのにログインしようとした時 403：権限がない時 404：ページが存在しない時
- 5XX：サーバーエラー
500：サーバーの不調 503：サーバーの負荷が大きいor改修中
⑨webアプリケーションの構成要素
webアプリケーションは主にwebサーバー、アプリケーションサーバ0、DBサーバーの3層構造になっている。その前に歴史的な流れを学んでいく
- 最初のwebアプリケーション 最初はwebサーバーのみの構成。単純な静的なHTMLを表示したい場合（会社サイトのようなもの）はこの構造だが、ECサイトのような動的なものはできない 
- アプリケーション、データベースの追加
webアプリケーションの追加により、動的コンテンツを配信できるようになった（下図のwebサーバーはApacheのことを指す）。
しかし、大量のデータを取り扱うにはwebサーバーでは対応できないため、データベースを追加することで大量のデータを扱うことが可能になった。
しかし、同じサーバー内にDBがある場合、大量のデータを保管したり、ユーザーなどがログインしたりするとディスク容量やCPUの圧迫されてシステムが正常に作動しないことがある。そこでデータベースを別のサーバーに移すことで負荷を分散、データの一括管理ができて効率的になる。
- アプリケーションサーバーの追加
大量のアクセスがあった場合、たくさんのHTTPリクエストが発行される（CSSや画像ファイルのような静的なリクエストとDBとの連携で得られるもの）。このような種類の違うHTTPリクエストを大量に捌くのが困難なのでアプリケーションを分離してアプリケーションの箱としてAPサーバーが誕生し、webサーバーとAPサーバー、DBサーバーの3層構造になった。webサーバーがHTTPリクエストの受け口になって静的コンテンツのレスポンスを、一方で動的コンテンツはAPサーバーへ渡して処理を実施してDBサーバーへアクセスしてデータのやり取りを実施し、処理が終わったらwebサーバーへレスポンスを返す。
読書ログは以下の構成となっている
まず、クライアント（自分のPCやスマホ）がHTTPリクエストをwebサーバー（dockerではappコンテナ）に送られ、Apacheが処理をPHPに任せる。PHPがDBへデータのやり取りを実施し、そのデータを元にPHPがHTMLファイルを生成してApacheに渡してHTTPレスポンスを返すようになっている。