イラスト図解式 この一冊で全部わかるWeb技術の基本を読んだので，その書評を書きます．
読むのにかかった時間は合計8時間でした．
本書の概要
公式サイトの紹介文を引用します。
Webの全体像から、HTTPでやりとりする仕組み、さまざまなデータ形式、Webアプリケーションの開発、セキュリティ、システムの構築・運用まで、これからWebにかかわる人が知っておきたい知識をこの一冊で丸ごと解説！
すべての項目の解説は、徹底的にイラスト図解化。
これから仕事に必要な知識を学ぶ方に、すばやく、たのしく知識を身につけていただけるよう、読みやすさ、わかりやすさにこだわって制作しています。・知識ゼロから全体像がつかめる！
・よく使われる用語の意味がわかる！
・技術の仕組みがスムーズに学べる！
実務に生かせる知識が、確実に身につく、これから学ぶ人のベストな一冊です！
＜主な対象読者＞
・これからIT系の仕事に就かれる方
・これから社内の情報システムを担当される方
・Webシステムに関連する技術と実務を、幅広く、バランスよく学びたい方
■目次：
Chapter1 Web技術とは
Chapter2 Webとネットワーク技術
Chapter3 HTTPでやりとりする仕組み
Chapter4 Webのさまざまなデータ形式
Chapter5 Webアプリケーションの基本
Chapter6 Webのセキュリティと認証
Chapter7 Webシステムの構築と運用
まさに紹介文の通りで，知識ゼロの自分でもそこまで苦労せずに読むことができました．それでいて，広範な内容をカバーしていて，それぞれの技術や用語の全体像をつかむのに役立ちました．技術の詳細や仕組みといった部分は全くといっていいほど触れられていないので，その点は留意して読む必要があります．
前提
筆者について
- 大学4年生．
- 来年度から情報系（数理）の大学院に進学予定
- コンピュータサイエンスについてはあまり詳しくない
- プログラミングの経験，数理とその関連分野（グラフ理論，最適化，アルゴリズムなど）の知識はある
- 一方，ネットワーク，データベース，OS, etc.については，ほとんど知識がない
読書の背景
情報系の大学院へ進学が決まり，ソフトウェアエンジニアにも興味があるので，コンピュータサイエンスを基礎から学びたいと考えました．また，web技術（HTTP，webAPI）について興味があり，これまでインターンシップなどでも触れる機会があったが，基礎的な部分が抜けていると感じたため，書籍などできちんと勉強したいと考えていました．
本書を選んだ理由
Webを支える技術 ―― HTTP，URI，HTML，そしてRESTという有名な本があり，常々読みたいと考えていました．しかし，その前にまずはweb技術の概観をさらりと掴もうと考え，本書を選びました．
感想
さらりと読み流してしまっては，すぐに忘れてしまいそうだと感じたので，読みながら適宜メモを取っていました．イラストを紙で書いたり，メモをとったりしながら読むと，飽きずに読み進められるのでおすすめです．
良かった点
ネットワークの基礎，web技術のトレンド，セキュリティ関連の基本的なことなど，とにかく幅広い内容をカバーしている点が良かったです．また，各ページの半分説明，半分イラスト図解という構成のおかげで，読みやすく理解しやすかったです．
イマイチだった点
仕方ないことではありますが，各項目の説明がかなり簡潔なため，概念の名前と概略だけではイメージがつかみきれないものも多々ありました．それらの項目については，適宜ネットで簡単な解説記事を調べたりしながら読み進めました．例えば，6章のOAuthの項目については，一番分かりやすい OAuth の説明を読みました．
次に読みたい本
満を持して，Webを支える技術 ―― HTTP，URI，HTML，そしてRESTを読みたいと考えています．また，Go言語の標準ライブラリでだけでwebアプリを作るGoプログラミング実践入門 標準ライブラリでゼロからWebアプリを作るにも興味があります．
こんな人におすすめ
公式にあるように，以下のような方におすすめです．
・これからIT系の仕事に就かれる方
・これから社内の情報システムを担当される方
・Webシステムに関連する技術と実務を、幅広く、バランスよく学びたい方
それに加えて，個人開発などの形でこれからweb開発をやってみようと考えている学生の方にもおすすめだと感じました．
各章ごとの自分のメモ
一応，各章ごとの自分のメモを残しておきます．
各章ごとの自分のメモ
- 1章
- Webとインターネットは別々に生まれ，のちにwebがインターネットで使えるようになった．
- URL：Uniform Resource Locator
- HTMLはブラウザが解釈（レンダリング）して，webページを表示．
- コンテンツ転送一回につき，ファイルは1つ
- ブラウザがwebサーバーにHTMLを要求
- HTMLが返ってくる
- HTMLの中に画像を発見したら，画像を転送してもらうように，リクエスト
- 画像が返ってくる
- 画像をHTMLに嵌め込んで表示する
- サーバーサイドスクリプト：Python，PHP，など．
- バックエンドで使われる言語
- クライアントサイドスクリプト：ほとんどJavaScript
- フロントエンドで使われる言語
- CGI：Common Gateway Interface
- リクエスト処理(API)とHTML作成をどっちも行う．最近はあんまり使われていない
- W3C：web標準化を進める団体．webの創設者が作った
- REST(REpresentational State Transfer) : APIの設計思想の一つ．満たすべき4つの原則を定めている．
- これを満たすものをRESTfulなAPIなどという．
- 統一インターフェース
- アドレス可能性
- 接続性
- ステートレス性：マルコフ性みたいなもの．現在のリクエスト内容がこれまでの履歴に依存しない
- 2章
- ISP: Internet Service Provider：インターネットサービスプロバイダ
- プロトコルは「狼煙」に例えられる
- 事前に取り決めておくと，煙を見た人は情報を受け取れる
- DNS：名前解決
- 階層構造になっていると，効率良い？二分探索的な？
- 名前解決にすらいろんなサーバーを行き来しないといけないのに，Google検索とかどうしてるんだ．
- http: hypertext transfer protocol
http://example.com:80/index.html-
httpなら，ポート番号80と取り決めがあるので，ポート番号は省略可能
- 3章
- webブラウザはサーバーにHTTPリクエストを送り，サーバーはHTTPレスポンスを返す
- HTTPの最新バージョンは3．ただし，ブラウザとサーバーの両方が対応しているバージョンが利用されるので，まだまだ2も多い
- TCP(transmission control protocol)
- SYNパケット（Synchronize）：通信を送るときに，まず相手に「通信を始めるよ」という合図を送る
- ACKパケット（Acknowledge）：相手からの合図（SYNパケット）を受け取ったら，「了解しました」という合図を返す
- TCPでコネクション確立するときには次の3ウェイハンドシェイクが行われる．
- 1．クライアントからサーバーにSYNパケットを送る
- 2．サーバーからクライアントにSYNパケットとACKパケットを送る
- 3．クライアントからサーバーにACKパケットを送る
- 通信が終わるときには，FINパケット（Finish）を送る．
- HTTP1.1
- リクエスト側
- リクエスト行：
GET /index.html HTTP/1.1など - HTTPヘッダ
- 空行
- メッセージボディ
- リクエスト行：
- レスポンス側
- ステータス行：
HTTP/1.1 200 OKなど - HTTPヘッダ
- 空行
- メッセージボディ
- ステータス行：
- HTTPメソッド
- GET：リソースの取得
- POST：リソースの送信（フォームの送信など）
- PUT：リソースの更新（ブラウザ側でwebサイトを改変できてしまうので，権限が与えられないことも多い）
- DELETE：リソースの削除（ブラウザ側でwebサイトを改変できてしまうので，権限が与えられないことも多い）
- HEAD：ヘッダのみ取得
- OPTIONS：許可されているメソッドの取得
- TRACE：リクエストのループバックテスト
- CONNECT：プロキシ経由での接続
- ステータスコード
- 1xx：情報
- 2xx：成功
- 3xx：リダイレクト
- 4xx：クライアントエラー
- 404 Not Found
- 403 Forbidden
- 400 Bad Request
- 5xx：サーバーエラー
- HTTPヘッダ
- 一般ヘッダフィールド
- リクエストヘッダ
- Host
- User-Agent
- Accept
- Accept-Language
- Accept-Encoding
- Connection
- レスポンスヘッダ
- Date
- Server
- Content-Type
- Content-Length
- Connection
- HTTPキープアライブ
- 元々はHTTPリクエストとレスポンスのひと組ごとにコネクション確立していた．
- これでは，多数の画像などをやり取りするときにいちいちコネクション確立するのが非効率
- そこで，HTTP1.1では，コネクションを維持しておくことができるようになった．これをHTTPキープアライブという．
- 元々はHTTPリクエストとレスポンスのひと組ごとにコネクション確立していた．
- HTTPパイプライン
- HTTPリクエストに対するHTTPレスポンスを待つことなく，複数のHTTPリクエストを送信することができる．
- リクエスト側
- HTTP/2
- Googleが提案したSPDYプロトコルをベースにしている
- ストリームによる多重化
- 「HTTPパイプライン」では，HTTPリクエストの順番通りにレスポンスを返さねばならなかった
- →前の処理に時間がかかると，後続の処理も遅れる．（HOLブロッキング; Head of Line Blocking）
- そこで，「ストリーム」を使って，並列的にのHTTPリクエストとHTTPレスポンスのやり取りが行えるようになった．
- 「HTTPパイプライン」では，HTTPリクエストの順番通りにレスポンスを返さねばならなかった
- バイナリ形式の利用
- 元々はテキスト形式だった
- ヘッダ圧縮
- ヘッダの圧縮を行うことで，通信量を削減
- ヘッダ情報は毎度，重複する内容が多い
- →ヘッダ情報の中から差分だけを送るHPACK
- サーバープッシュ
- クライアントがリクエストしなくても，サーバーがクライアントに対してリソースをプッシュできる
- クライアントがリクエストする前に，サーバーがリソースをプッシュしておくことで，通信の効率化が図れる
- 例：
index.htmlをリクエストしたら，style.cssも一緒にプッシュしておく
- 例：
- HTTP/3
- QUICプロトコル
- UDPを使っている
- モバイルデバイスによるインターネット利用を考慮した機能が備わっている
- コネクションマイグレーション
- ネットワークが切り替わった際でも接続を継続できる
- モバイルデバイスではメリットが大きい
- QUICプロトコル
- HTTPS; HTTP Secure or HTTP over SSL/TLS
- SSL（Secure Sockets Layer）
- TLS（Transport Layer Security）
- 盗聴防止（暗号化通信）
- データを暗号化してやり取りする
- 改ざん防止
- データのハッシュ値を持っておいて，改ざんを検知する
- なりすまし防止
- Webサーバーに設置された，SSLサーバー証明書の発行元が信頼できるかどうかを確認する
- 信頼された認証局なら，そのSSLサーバー証明書は信頼できる
- Webサーバーに設置された，SSLサーバー証明書の発行元が信頼できるかどうかを確認する
- SSL/TLSハンドシェイク
- 暗号化方式の確認，公開鍵のやりとり，SSL証明書の送信
- ステートレス，ステートフル
- ステートレス：HTTPレスポンス，リクエストの組が互いに独立していること．（過去の履歴を持たない）
- ステートフル：各クライアントの履歴を持つ．クライアントの数が多いと，負担が大きい
- でも，一連の操作（お気に入り→買い物かご→決済画面→．．．）では各ユーザの履歴を保持しておきたい
- →Cookie
- 初回のHTTPレスポンスに含まれるSet-Cookieヘッダで，クライアントにCookieを送信
- 以降のHTTPリクエストには，CookieヘッダでクライアントからサーバーにCookieを送信
- これはつまり，APIの鍵を増やしただけ?
- セッションCookie：ブラウザを閉じると消えるCookie
- セッション：一連の操作
- セッションID（SID）をCookie（・URL・フォームなどもある）に埋め込むことで管理
- セッション：一連の操作
- URI（Uniform Resource Indentifier）
- URL（Uniform Resource Locator）：リソースの場所を示す
- URN（Uniform Resource Name）：リソースの名前を示す
- 例：書籍の管理を行うISBN
- パーセントエンコーディング
- URIでは使える文字が限られる
- 日本語など，使えない文字を使うには，
%xxの形で16進数の文字コードを使う
- 4章
- HTML
- タグ：
<h1>,<p>,<img>,<a>など - 要素：各タグで囲われた部分全体
- 属性：
<a href="http://example.com">のhrefなど -
media属性を用いれば，メディアタイプごとに表示を変えられる- 用いるcssファイルを変えたりする
- タグ：
- 画像形式
- JPEG（Joint Photographic Experts Group）：写真などの画像に適している．非可逆圧縮
- PNG（Portable Network Graphics）：可逆圧縮．
- GIF（Graphics Interchange Format）：色が少ない
- WebP（ウェッピー）：Googleが開発．小さいサイズで高画質
- SVG（Scalable Vector Graphics）：XMLで記述された画像
- JavaScript
- 元々，MozillaとMicrosoftが別々に開発していたもの
- ECMA（European Computer Manufacturers Association）がECMAScriptとして標準化したものがJavaScriptと呼ばれている
- XMLとHTML
- 元々はどちらもSGML（Standard Generalized Markup Language）から派生
- CSS
- webページの構造と見た目とを，HTMLとCSSでそれぞれ分離することができる
- DOM（Document Object Model）
- HTMLやXML文書をプログラムから操作するためのAPI
- 構文解析木的な？
- JSON（JavaScript Object Notation）
- XMLみたいなもの
- ただし，JavaScriptから直接扱える
- DOMを介さなくてOK
- だから，web APIのレスポンスとしてよく使われる
- フィード：webサイトの更新情報を配信するためのファイル
- RSS（Rich Site Summary）
- Atom
- フィードリーダー：フィードを購読して，新着情報を受け取る
- マイクロフォーマット
- Webページの各要素に意味を表す記述を埋め込む書式
- 例：
<span class="location">など - セマンティックWebへの第一歩か？
- 意味を持たせることで，機械が理解できるようにする
- ただし，現状フォーマットは統一されていない
- 音声，動画の配信
- ダウンロード配信：ユーザーがコンテンツを手元のデバイスにダウンロードしたのち，再生．
- 著作権的に問題あり．
- 時間もかかる
- プログレッシブダウンロード：ダウンロードしながら再生
- ストリーミング配信：ファイルを細切れにして再生，再生したものはすぐに破棄するので，著作権的に問題ない
- コーデック：データを圧縮するためのソフトウェア
- MP3（MPEG Audio Layer 3）：音声データの圧縮
- FLAC
- MPEG-4
- WMV
- ダウンロード配信：ユーザーがコンテンツを手元のデバイスにダウンロードしたのち，再生．
- HTML
- 5章
- webアプリケーション
- 3層構造（3層アーキテクチャ）：「プレゼンテーション層」，「アプリケーション層」，「データ層」
- プレゼンテーション層：UIを担当．webブラウザとwebサーバー．リクエスト処理．
- アプリケーション層：アプリケーションサーバー．ビジネスロジックを担当．
- データ層：データベースサーバー．データ処理．
- APサーバーとwebサーバーの違いがわからない
- webサーバーはクライアントの窓口．静的ページならwebサーバーだけで返せる
- apサーバーは，動的処理などのビジネスロジックを担当
- 適切に層を分けることで，負荷を分散できる．改修のコストも抑えられる．（各パーツが独立しているため）
- MVCモデル：Model, View, Controller
- Model：データと業務処理
- View：ユーザーへの出力処理
- Controller：ModelとViewをつなぐ部分
- これにより，各部分を独立して開発できる
- 3層アーキテクチャとMVCモデルは根本的に異なる概念なので注意．
- 3層アーキテクチャは階層構造．最下層と最上位層はやり取りしない
- MVCでは，互いにやり取りする．
- MVCモデルのMVCは，三層アーキテクチャでいえば，アプリケーション層とデータ層に相当する
- プレゼンテーション層はMVCモデルとユーザーの間にある
- 3層構造（3層アーキテクチャ）：「プレゼンテーション層」，「アプリケーション層」，「データ層」
- フレームワーク：一般的な処理の流れを雛形として準備してあるもの．
- 例：JavaベースのSpring Boot, JavaScripベースのReact, Vue.js, RubyベースのRuby on Rails
- Webサーバー：webアプリにおいて，webクライアントに対する窓口の役割を果たす
- webサーバーが動作しなくなると，サービスが完全に止まってしまう．→冗長化しておく．
- 複数台のサーバーがあるときには，きちんと同期できるようにしておく．
- webクライアント：セッション管理webサーバーへリクエストを送り，レスポンスを受け取って，それを解釈する機能を持つ．主にはwebブラウザ.
- ユーザーの操作をリクエストの形に変換する．レスポンスをわかりやすく表示する，など．ユーザーとwebサーバーとの橋渡し．
- webブラウザは汎用的なwebクライアントだが，特化した機能を持っているwebクライアントもある．こういうプログラムは専用クライアントor専用ブラウザと呼ばれる．例えばデスクトップアプリ，スマホアプリなども専用クライアント．
- アプリケーションサーバー（APサーバー）：webアプリケーションの中核を担う．ユーザーのデータを受け取り，データ加工したり，データベースからデータを検索したりする．
- 三層アーキテクチャでは最も多機能なサーバー
- セッション管理機能：セッションIDを発行して，同じクライアントからの通信をセッション単位で管理する．
- HTTPはステートレスなプロトコルなので，セッション管理機能が必要
- ざっくり，ログインからログアウトまでが1つのセッション
- セッション中で行われる一連の作業をトランザクションという．
- 予約手続きのように，「すべてのやりとりが成功するまで完了しない」処理
- DBサーバー
- データの保全は重要なので，冗長化構成を取る．しかし，頻繁に更新も行われるので，同期が重要．
- 冗長化の種類
- ミラーリング：プリンシパル（正）とミラー（副）を作っておく．プリンシパルが更新命令を受けると，プリンシパルからミラーにも更新命令を転送する．プリンシパルがダウンしたら，ミラーに切り替える．
- レプリケーション：プライマリ（主）とレプリカ（副）を作っておく．プライマリが更新命令を受けると，レプリカにも更新履歴（命令ではない）を転送する．ミラーリングとは異なり，直ちに更新されるとは限らない．
- シェアードストレージ：データベースを共用のストレージに置いておく．
- キャッシュサーバー
- キャッシュ：リクエストに対するレスポンスの記憶．
- コンテンツキャッシュ：画像などのコンテンツを保存
- webクライアントとwebサーバーの間にいる
- クエリキャッシュ：DBMSのデータ検索要求の結果を保存
- APサーバーとDBMSの間にいる
- コンテンツキャッシュ：画像などのコンテンツを保存
- キャッシュには有効期限を定めておく
- CDN(Contents Delivery Network)：キャッシュサーバーを世界中に配置して，ユーザーに近い場所からコンテンツを配信する
- キャッシュ：リクエストに対するレスポンスの記憶．
- webアプリケーション
- 6章
- 情報セキュリティの三要素
- 1．機密性：情報を見ては行けない人に見せない
- 2．完全性：情報を他人に改ざん・消去させない
- 3．可用性：情報を見られる人は容易に見られるようにする
- 色々な攻撃
- パスワードクラッキング
- 辞書型：事前に使われやすいパスワードをリスト化しておいて，それを使って総当たり攻撃
- ブルートフォース型：全て総当たり攻撃
- DoS（Denial of Service）攻撃
- SYN Flood攻撃
- TCP通信のSYNパケットのみ送り続ける→サーバーがスリーハンドシェイク待ち状態になって．ユーザーがアクセスできなくなる
- F5攻撃
- ページ再読み込みなどのリクエストを大量にサーバーに送って，負荷をかける攻撃
- f5キーでページ再読み込みできることからこの名前がついた
- 対策：不審なIPアドレスからのアクセスを遮断する
- SYN Flood攻撃
- セッションハイジャック：SIDやCookieを盗み，セッションを乗っ取る．乗っ取られると，「ログイン状態」でなんでもやり放題
- ディレクトリトラバース
- traverse：横断する
- 通常は
GET index.htmlなどで，webサーバーのディレクトリ内のファイルを取得するが，GET ../../etc/passwdなどで，サーバー内のファイルを読み取る
- XSS（Cross Site Scripting）：掲示板サイトのようなユーザの入力内容を表示するタイプのサイトで，ユーザが入力したスクリプトをそのまま表示してしまうと，そのスクリプトが実行されてしまう
- CSSRF（Cross Site Request Forgery）：ユーザが意図しないリクエストを送信させる
- forgery: 偽造
- 本人になりすましてログインの必要なサイトを操作する
- パスワードを変更する，など
- SQLインジェクション：ユーザから送信された内容に，DBサーバーが解釈できる内容を混ぜ込んで，DBサーバーを操作させる
- パスワードに
aaa or "1+1=2"を入力すると，パスワードが正しい，と認識されてしまい，ログインできてしまう．
- パスワードに
- パスワードクラッキング
- 脆弱性
- セキュリティホール：セキュリティの脆弱性
- ゼロデイ攻撃：まだ脆弱性が公表されていない状態で攻撃される
- ファイアーウォール：インターネットと内部ネットワークとの間に設置するセキュリティ設備
- パケットフィルタ型：パケットの送信元や送信先を見て，通信を許可するかどうかを判断
- 特定のIP/ポートからの通信のみを許可する
- 攻撃の手段を限定できるので，ポート番号を制限するだけでも有効
- パケットフィルタ型：パケットの送信元や送信先を見て，通信を許可するかどうかを判断
- IDS(Intrusion detection system)，IPS(Intrusion prevention system)
- Intrusion：侵入
- IDS：侵入を検知する
- 検知するだけなので，防ぐことはできない
- IPS：侵入を検知して，防ぐ
- 正常な通信を防いでしまうこともある．これは可用性を下げる
- IDSとIPSはシステムの用途や性質によって使い分ける
- シグネチャ型：基地の攻撃パターンを事前に登録しておいて，それに一致する通信を遮断する
- アノマリ型：通常の通信パターンを学習して，それに一致しない通信を遮断する
- ただし，XSSやSQLインジェクションなどの攻撃は，通信パターンとしては正常なので，検知できない→WAF
- WAF(Web Application Firewall)
- webアプリケーションに特化したファイアーウォール
- 高機能だが，導入，運用にコストがかかる
- ブラックリスト形式とホワイトリスト形式がある
- ネガティブセキュリティモデル（ブラックリスト）：攻撃パターンを登録しておいて，それに一致する通信を遮断
- ポジティブセキュリティモデル（ホワイトリスト）：正常な通信パターンを登録しておいて，それ以外の通信を遮断
- ホワイトリスト形式の方がセキュリティは高いが，運用コストが高い
- プロキシサーバー：webクライアントとwebサーバーの間にサーバーを一つ置いて，リクエスト・レスポンスを中継する
- プロキシ（proxy）：代理
- フォワードプロキシ：webクライアントの出口に設置．webクライアント利用者側が管理
- 不審なwebサーバーへのアクセスや，ウイルスのブロックを行える
- webサーバーへの通信の記録をログとして残せるので，多くの企業で利用されている
- LAN内におく？
- リバースプロキシ：webシステムの入り口に設置．webサーバー側が管理
- 直接webサーバーに接続させないことでセキュリティUP
- リクエストに関する前処理も行える．
- ロードバランサーもリバースプロキシの一種
- 暗号化
- 通信経路の暗号化：https
- サーバーに保存するデータは暗号化しておく
- 使うたびに都度複合化する
- パスワードのように，「一致するか否か」が分かれば良いものはハッシュ化しておく
- 公開鍵証明書（SSL証明書，とも言われる）
- 証明書は，公開鍵の持ち主が誰かを証明すること，公開鍵の持ち主が存在することの証明
- 認証
- 認証API：Googleなどの認証システムを利用した認証．webアプリの開発者は，提供されたAPIを利用して，認証機能を実装する
- 企業ごとに仕様が違ったりして大変
- OpenID：認証処理を標準化したプロトコル
- 認証API：Googleなどの認証システムを利用した認証．webアプリの開発者は，提供されたAPIを利用して，認証機能を実装する
- 認可：認証の結果を用いて，ユーザーにサービスを利用する権限を与えること
- OAuth（オーオース）：サイトを跨いだ認可のための標準化されたプロトコル
- リソース：利用したいサービス
- トークン：サービス利用のための合言葉
- 一番分かりやすい OAuth の説明
- OAuth（オーオース）：サイトを跨いだ認可のための標準化されたプロトコル
- CAPTCHA（Completely Automated Public Turing Test To Tell Computers and Humans Apart）
- プログラムと人間を区別するためのテスト
- いたちごっこと化している
- 情報セキュリティの三要素
- 7章
- webシステムを構築するときには，「サービスの内容」，「アプリケーションに必要な機能，デザイン」，「システム基盤に必要な機能」を順に検討する
- 技術選定
- サーバーのOS：LinuxかWindowsか
- DBMS
- Oracle：高機能，高価
- MySQL，PostgrSQL, SQLite：無償，シンプルな機能
- SQL Server：Windowsに特化
- Webサーバー
- Apache：オープンソース，古くからある
- nginx：高速，軽量
- IIS：Windowsに特化
- ネットワーク
- 内部ネットワーク：企業内部のネットワーク
- APサーバー
- DBサーバー，など
- 外部ネットワーク：インターネットに晒される部分．ファイアウォールの外側
- DMZ（DeMillitized Zone）
- 非武装地帯，という意味
- Webサーバー
- IDS，IPS
- WAF，など
- 耐障害性能を高めるには，機器を複数設置して冗長化する
- 内部ネットワーク：企業内部のネットワーク
- ロードバランサー：webサーバーよりインターネット側に置く．リクエストを全て受け取って，適切にwebサーバーに振り分けることで負荷を分散する
- サーバー基盤
- オンプレミス：自分で機器を購入して利用する
- 自社運用，を表す
- メリット：構成が自由，個人情報などを他社に預ける不安がない
- デメリット：運用が大変，機器の知識がいる
- レンタルサーバー：他社が構築して，貸し出しているサーバーを間借りする
- メリット：運用や構築の手間がない．場所も確保しなくてOK
- デメリット：構成の自由度がほとんどない．そのため，個人利用されることが多く，企業ではほぼ使われない
- クラウド：仮想的なサーバー環境にサーバーを設置する．現在の主流
- オンプレミス：自分で機器を購入して利用する
- クラウドサービス
- IaaS（Infrastructure as a Service）：インフラを提供するサービス
- 例：AWS，Azure，GCP
- PaaS（Platform as a Service）：プラットフォームを提供するサービス
- 例：APサーバー，DBサーバー
- SaaS（Software as a Service）：ソフトウェアを提供するサービス
- 例：Gmailなど．APIとして提供される場合もある
- IaaS（Infrastructure as a Service）：インフラを提供するサービス
- 負荷分散：ロードバランサーが行う．が，Apacheなどのソフトウェアにも負荷分散機能があるものもある．
- ラウンドロビン方式：各サーバーに順番にリクエストを割り振る方式．各リクエストの処理の複雑さと，各サーバーの処理能力が同じ場合に有効．
- 動的分散方式：サーバーの負荷を監視し，負荷の低いサーバーにリクエストを割り振る方式．負荷として見られるのはCPU利用率やメモリ使用量，ストレージ負荷，コネクション数
- パーシステンス：同一クライアントからのアクセスは同一サーバーに転送する．セッション情報を保持するため
- データベース設計
- 論理設計：必要なデータと，それらデータ同士の関連性を定義する．データのことを「エンティティ」という
- 物理設計：論理設計をもとに，定義されたデータを実際のデータベース内にどのように格納するかを決める．データの型やインデックスの設定，データベースに割り当てるストレージはどのくらいか，など
- アプリケーション設計
- 基本設計（外部設計）：機能や画面レイアウトなどを定義する
- 詳細設計（内部設計）：基本設計をもとに，プログラムの詳細な設計を行う．これをもとに実装を進めていく
- テスト：単体テスト（モジュールごとのテスト），連結テスト（モジュール同士がうまく連携しているか）
- バックアップ運用
- データセンターの被災，サーバーの故障，不正アクセスによるデータ改竄などに備える
- ログ運用
- システムログ：OSがイベントやエラーを記録する
- アプリケーションログ：ミドルウェアなどのアプリが動作履歴を記録する
- アクセスログ：webサーバーが受けたリクエストを記録する
- ログは故障の原因やサイバー攻撃の形跡など，有益な情報が読み取れるため，バックアップしておく．
- だが，何もしないと膨大なサイズになって可読性も下がるので，メンテナンスが必要
- ログローテーション：ログを時間単位で区切る
- アクセスログ解析：アクセスログを解析して，サービス向上に役立てる
- webサイトのパフォーマンス
- パフォーマンス：応答時間，表示完了時間，ページ読み込み時間，可用性，など
- パフォーマンスやサーバーの負荷状態を監視しておき，日々サービスの向上に役立てる
- 監視ツールもいくつかある