はじめに

10月からWeb開発エンジニアに転職したそらです！
今までは組み込み開発やWindowsアプリ開発がメインで、Webについて基礎知識が乏しいので、学習内容をまとめていきます。
今回は、［改訂新版］プロになるためのWeb技術入門を読んだので、Webシステムの全体像をまとめてみます！

Webシステムの全体像

Webシステムは、「クライアントサイド」・「サーバサイド」・「インターネット」の３つの領域から成り立っている。
サーバサイドで用意されたWebコンテンツ（文字や画像などの情報のこと）がインターネットを経由して、クライアントサイドに届くことで情報として見ることができる。

Webコンテンツ

Webコンテンツは、「静的コンテンツ」「動的コンテンツ」の２つがある

静的コンテンツ	Webサイトの制作者があらかじめ用意した情報 ex) ブログ記事、商品紹介ページ
動的コンテンツ	ユーザの入力によって表示される結果が変わる情報 ex) 予約システム、検索システム

クライアントサイド

クライアントサイド＝Webブラウザと言える。
Webブラウザは、HTTP通信を利用してサーバサイドとやり取りし、その結果を表示するためのアプリケーション。

HTTPクライアント

サーバとのHTTP通信を担うプログラムのこと。
URLに対応する相手のサーバと情報をやり取りする。
受け取った情報をレンダリングエンジンに渡す。

レンダリングエンジン

HTTPクライアントから受け取った情報（HTML,CSSなど）を画面に表示するソフトウェア。

JavaScriptエンジン

JavaScriptで書かれたプログラムを実行するためのソフトウェア。

サーバサイド

サーバサイドの実態はシステムによって異なる。
基本はHTTPサーバという機能を組み込んだ複数のソフトウェアで構成されている。
動的コンテンツの比重が増してきたため、Webアプリの開発が始まった。

Webアプリケーションの実行方式

プロセス起動方式
- HTTPリクエストの処理のたびに、アプリケーションを都度実行する
- 毎回プロセス起動されるため、処理に時間がかかる
モジュール方式
- Webサーバに実行用モジュールを組み込んで実行する
- プロセス起動方式よりも処理が高速になる
分離型独立プロセス方式
- WebアプリケーションがWebサーバとは独立プロセスとして常に実行される
- Webサーバは静的コンテンツを提供し、Webアプリケーションは動的コンテンツを提供する
- WebサーバとWebアプリケーションの連携が必要になるため、システムが大掛かりになる
一体型独立プロセス方式
- Webアプリケーションで静的コンテンツ、動的コンテンツのどちらも提供する
アプリケーションサーバ方式
- 複数のWebアプリを稼働・管理する機能を提供するアプリケーションサーバを用いて実行する

ネットワーク

クライアントサイドとサーバサイドの物理的な隔たりを繋げる役割。
Webアプリの通信は「HTTP」で統一され、ネットワークを通じてやり取りされる。

ロードバランサ

Webシステムのリクエストを複数のサーバへ割り振る負荷分散装置のこと。

CDN(Content Delivery Network)

コンテンツを高速かつ効率的に配信するためのシステム。
通信遅延の時間を短縮することができる。

エッジサーバ	Webシステム本体のサーバの代わりにコンテンツを配信するために世界各地に設置されるサーバ
オリジンサーバ	Webコンテンツのオリジナルを保持するサーバ

URL

URLは、インターネットにおける情報の住所のことで、一般的にはhttp://example.com/index.htmlのように表す。
ただ、RFC3986が定める詳細な構造は、http://user:password@example.com:8080/index.html?name=hoge#fuga となっている。

URLの構造

スキーム(Scheme)

http 部分をスキームと呼び、情報にアクセスするための方法を示している。
HTTP以外のプロトコル(file, mailtoなど)も包括的に表現するために導入された。

ユーザとパスワード

user:password 部分には、サーバへアクセスするための認証情報を指定する。
ただ、パスワードをURLに含めるのはセキュリティとして危険ため、非推奨である。
HTTP以外のスキームでは、認証情報を表すためにこの形式が使用されることもある。

ホスト(Host)

example.com 部分をホストと呼び、接続先のコンピュータを示している。
ドメイン名で表現されることがほとんどで、DNSという仕組みで対応するIPアドレスへ変換し、相手のコンピュータにアクセスしている。

ポート(Port)

8080 部分はホストと組み合わせて指定される。
コンピュータ内にあるプログラムが使用しているポートを指定して通信する。
0 ~ 1023番はウェルノウンポートと呼ばれ、重要なサービスが使用するために予約されている。

ウェルノウンポート
ポート番号	プロトコル名
20	FTP(データ転送)
21	FTP(コントロール)
22	SSH
23	Telnet
25	SMTP
53	DNS
80	HTTP
110	POP3
443	HTTPS

パス(Path)

index.html 部分をパスと呼び、コンピュータにおける情報の位置を示している。

クエリ(Query)

?name = hoge の部分をクエリ(クエリパラメータ)と呼び、Webサーバに渡すパラメータを示している。
パラメータ名 = 値 の形式で記述する。
複数のパラメータを渡す場合は、& で区切って記述する。

フラグメント(Fragment)

#fuga の部分をフラグメントと呼び、HTMLの特定位置を示している。
ブラウザがこの情報を元に、特定の位置を表示するために使用される。
フラグメントの参照先を アンカー(Anchor) と呼び、id属性をつけることで指定できる。

URLに使える文字

URLでは、以下の文字列のみを自由に利用できる。

アルファベットの大文字
アルファベットの小文字
数字
ハイフン(-)
ピリオド(.)
アンダースコア(_)
チルダ(~)

日本語を使いたい場合はパーセントエンコーディングと呼ばれる仕様を使うことで表現できる。
パーセントエンコーディングとは、文字コードを%に続けて記載すること。

HTTP通信

クライアントが HTTPリクエスト を送信し、受け取ったサーバが HTTPレスポンス を返すことで情報のやり取りを行う通信方式。

HTTPリクエスト

HTTPリクエストは、リクエストライン・リクエストヘッダフィールド・メッセージボディから構成される。

リクエストライン

サーバに対して、どのような方法で、何を要求するかを表す。
メソッド・リクエストターゲット・HTTPバージョンから構成される。

メソッド
HTTPリクエストの種類を表し、サーバに対してどのような処理を要求するかを表す。
９種類のメソッドが定義されている

HTTPメソッド
メソッド名	処理内容
GET	指定したリソースを要求する
POST	リソースに新しい情報を作成・追加する
PUT	指定したリソースを新しい内容に置き換える
PATCH	指定したリソースの一部を変更する
DELETE	指定したリソースを削除する
HEAD	指定したリソースのヘッダだけを要求する
OPTIONS	サーバが利用可能なメソッドの一覧を返す
CONNECT	中継サーバへの接続に使用する
TRACE	受信したリクエストをそのまま返す

リクエストターゲット
HTTPサーバの要求するファイルがあるパスを表す。
基本的に、URLのパスとクエリ部分が入る。
HTTPバージョン
HTTPリクエストがどのバージョンに沿っているかを表す。
基本的に、HTTP/1.1 で固定と考えてOK。

リクエストヘッダフィールド

リクエストラインを補足する情報を表す。
フィールドラインによって情報を記載していく。

フィールドライン
フィールドラインは、name:value の形式で情報を記載していく。
代表的なリクエストヘッダは下記の通り。

リクエストヘッダ
ヘッダ	内容
Host	リクエスト送信先のドメイン名とポート番号
Connection	レスポンスを受け取った後、ネットワーク接続を切断するかどうか
Cookie	サーバへ送信するCookie
Content-type	サーバへ送信する情報の種類
Authorization	サーバへ送信する認証情報
Origin	リクエスト発生元

メッセージボディ

HTTPサーバへ送信する情報の本体部分を表す。
POSTやPUTなどのメソッドで送信する情報が格納されている。

HTTPレスポンス

HTTPレスポンスは、ステータスライン・レスポンスヘッダフィールド・レスポンスボディから構成される。

ステータスライン

リクエストの処理結果を端的に表す。
HTTPバージョン・ステータスコード・リーズンフレーズから構成される。

ステータスコード
リクエストの結果を３桁の数字で表す。

ステータスコード
ステータス	結果	説明
1xx	情報	処理の継続を表す
2xx	成功	処理の成功を表す
3xx	リダイレクト	他のURLを参照すべきことを表す
4xx	クライアントエラー	クライアント側起因の処理の失敗を表す
5xx	サーバエラー	サーバ側起因の処理の失敗を表す

リーズンフレーズ

ステータスコードの意味を英語で表したもの。

レスポンスヘッダフィールド

レスポンスを補足する情報を表す。
リクエストヘッダフィールドと同じ構成。

レスポンスボディ

クライアントからの要求に対する情報の本体部分を表す。
基本的に、HTMLやCSS,画像などのファイル内容が入っている。

セッション

ネットワークを通じた一連の通信をセッションと呼ぶ。
コンテキストと呼ばれる付随する情報を保存する仕組みが提供されるが、HTTPはステートレスな通信のためこの考え方がない。
これを解決するために、HTTP Cookieを利用する。

Cookie

サーバとクライアントの間で状態を管理するために考えられたメカニズム。

Expires属性
Cookieの有効期限を示す属性で、有効期限となる日時形式で示す。
指定された日時以降は、そのCookieを使用しない。
Max-Age属性
Cookieの有効期限を示す属性で、有効期限までの秒数を示す。
ゼロまたは負の値となった場合に、期限切れとなる。
Expires, Max-Ageのどちらも設定されていない場合は、セッションクッキーと呼ばれブラウザが終了するまで有効となる。
Domain属性
どのサーバにアクセスした時にCookieを送信するかを指定する。
発行元ドメイン、Domain属性、HTTPリクエストの送信先のドメインの組み合わせによって、Cookieの送信可否が変わる。

ケース	発行元ドメイン	Domain属性	アクセス先	クッキーの送信可否
1	example.jp	（未指定）	example.jp	送信される
2			foo.example.jp	送信されない
3			bar.example.jp	送信されない
4			example.com	送信されない
5		example.jp	example.jp	送信される
6			foo.example.jp	送信される
7			bar.example.jp	送信される
8			example.com	送信されない
9	foo.example.jp	example.jp	example.jp	送信される
10			foo.example.jp	送信される
11			bar.example.jp	送信される
12	example.jp	example.com	-	ブラウザは受け付けない

Path属性
Domain属性で指定したサーバのどのパスにアクセスした時にCookieを送信するか指定する。
Secure属性
暗号化されたHTTPS通信の時のみ、Cookieを送信するように指定する。
HttpOnly属性
基本的にブラウザが保存しているCookieはJavaScriptから読み書きができるが、HttpOnly属性が付与された場合、JavaScriptからのアクセスが禁止される。
クロスサイト・スクリプティングなどで内容を盗み取られるのを防ぐ。

Web API(Application Programming Interface)

APIとは、プログラム同士が互いに連携するための取り決めのことで、ライブラリやコンポーネントと呼ばれる。呼び出すための名前・与えるパラメータ・得られる結果を決める必要がある。
WebAPIは、HTTPによってネットワーク越しに呼び出せるようにしたAPIのこと。

REST

WebAPIのアーキテクチャスタイルの一つで、６つの特徴がある。

クライアントとサーバが分かれていること
ステートレスであること
キャッシュによって通信量が削減されること
インタフェースが統一されていること
システム全体が階層化できること
プログラムをDLして実行できること

RESTful API

WebAPIでも、RESTの考え方を高いスコアで満たすものをRESTful APIと呼ぶ。

リソースの示し方：アドレス可能性
リソースに対してURLを与えることで、その場所を指し示せるようにすること。
リソースの辿り方：接続性
アプリケーションにあるリソースから別のリソースを辿れるようになっていること。
リソースの操作方法：統一インタフェース
統一された方法でリソースを操作すること。
リソース操作の手順：ステートレス性
サーバに状態を持たせず、必要な情報を全てリクエストに入れること。

クロスオリジン通信

自身の取得元とは異なるドメインに対してリクエストを送信すること。
ブラウザはこのようなリクエストを危険と判断し、「CORS error」としてレスポンスを渡さないようにする。

CORS(Cross-Origin Resource Sharing)

オリジン間のリクエストを許可するために作られた仕組みのこと。
HTTPヘッダを通じて、ブラウザが開いてサーバに対してリクエストを送信してもいいか確認する。

終わりに

まだ完全に理解できていないところですが、全体のイメージは掴めたかなと思います！
開発するにあたって、この辺りの基礎知識は必要になってくると思うので、復習しながらしっかりと身につけていきたいと思います。
HTTPメソッドやレスポンスなどもう少し詳しく理解しておいた方がいいところもありそうなので、他の書籍や実際にアプリを作りながら理解を深めていきます。