「イラスト図解式 この一冊で全部わかるWeb技術の基本」まとめ
テキストと図でWebの基本を網羅的に解説してくれる入門書を再読しました。
本書の内容としては「Web技術とは」から始まり、ネットワークやTCP/IP、HTTP、HTML、JSON、Webアプリの基本など、webエンジニアなら知っていて当たり前の知識が書かれています。
webを全く知らない人でも、図があるので理解しやすいのではと思っています。
本書を気になっている方に向けて、本記事では内容を整理してみました。
Chapter1
WWW
ワールドワイドウェブ（WWW）は、インターネット上で提供される情報を組織化し、ハイパーリンクを通じてアクセス可能にするシステムです。ウェブページはHTMLで書かれ、ウェブブラウザを通じて閲覧できます。
ハイパーテキスト
ハイパーテキストは、テキスト中の単語やフレーズにリンクを埋め込むことで、関連する情報に直接ジャンプできるようにしたテキストです。これにより、非線形の情報の閲覧が可能となります。
ハイパーリンク
ハイパーリンクは、ハイパーテキストの一部で、一つのウェブページから別のウェブページ（または同じページ内の異なる部分）に直接ジャンプすることを可能にするリンクです。
HTMLタグ
HTMLタグは、HTML（Hyper Text Markup Language）で使用されるマークアップの要素です。タグは"<"と">"の間に配置され、テキストや他の要素を囲むことで、その内容に特定の意味を与えます。
HTTP
HTTP（Hyper Text Transfer Protocol）は、ウェブブラウザとウェブサーバー間でウェブページやその他のデータを送受信するためのプロトコルです。
静的ページ
静的ページは、サーバー上に既に完成形で存在し、ユーザーがリクエストするたびにそのまま送信されるウェブページです。HTML、CSS等で書かれ、動的に変更されることはありません。
動的ページ
動的ページは、ユーザーのリクエストに応じてサーバー側で内容が生成・変更されるウェブページです。CGIやPHP、ASPなどのサーバーサイドスクリプトを利用して、リクエストの都度内容が動的に生成されます。
CGI
CGI（Common Gateway Interface）は、webクライアントの要求に応じてwebサーバーがプログラムを呼び出し、プログラムの処理結果がHTTPでクライアントに送信される仕組み。
webブラウザに表示するページにおいて、その内容を動的に変更させる時などに使用する。
ちなみにJSはwebクライアントで実行され、CGIはサーバ側で実行する。
JavascriptとCGIの違い
JavaScript： JavaScriptは、ウェブブラウザ上で実行されるスクリプト言語です。これはクライアントサイド（ユーザーのコンピュータ上）で動作し、ウェブページに対してインタラクティブな要素を追加するために主に使われます。JavaScriptのコードは、HTMLドキュメントに直接埋め込まれ、ユーザーのブラウザによって解釈され実行されます。
JavaScriptを使うことで、ユーザーがウェブページと対話する方法を大幅に向上させることができます。例えば、リアルタイムのフォーム検証、動的なコンテンツの更新（AjaxやFetch APIを使用した非同期通信）、アニメーションやゲームなどの高度なユーザーインターフェースの要素を可能にします。
CGI： 一方、CGIはサーバーサイドの技術です。CGIはウェブサーバがクライアント（通常はウェブブラウザ）からのリクエストを受け取り、それに対して動的なレスポンスを生成するための一連の規約です。CGIスクリプトはサーバ上で実行され、ウェブサーバと対話します。CGIは言語に依存しないので、Perl、Python、Ruby、C、C++など、多くのプログラミング言語で書くことができます。
CGIを使うと、ウェブページのコンテンツを動的に生成したり、データベースへのクエリを実行したり、フォームから送信されたデータを処理したりするなど、様々な操作を実現できます。
したがって、JavaScriptとCGIの主な違いは、JavaScriptがクライアントサイド（ブラウザ）で実行され、ウェブページのユーザーインターフェースとインタラクティビティを制御するのに対し、CGIがサーバーサイドで実行され、クライアントからのリクエストに対して動的なレスポンスを生成することにあります。
RESTの原則
REST（Representational State Transfer）の原則とは、ネットワーク上のリソースを効率的に操作するためのアーキテクチャスタイルです。
以下の6つの原則に基づいています。
クライアント-サーバー（Client-Server）：この原則は、ユーザーインターフェースとデータストレージを分離することを提唱します。これにより、クライアントとサーバーは独立して進化することができ、互いの変更に影響を受けることが少なくなります。
ステートレス（Stateless）：サーバーはクライアントからの各リクエスト間に状態情報を保存してはいけません。すべての必要な情報は、クライアントからの各リクエスト内に含まれている必要があります。
キャッシュ可能（Cacheable）：レスポンスをキャッシュすることが可能であるべきです。これは、クライアントが以前のレスポンスを再利用できることを意味します。これにより、クライアントのパフォーマンスが向上し、サーバーの負荷が軽減されます。
レイヤードシステム（Layered System）：クライアントは直接通信しているレイヤーにのみ関心を持つべきです。その間にいくつかのレイヤー（インターミディエイト・サーバーやプロキシ）が存在するかどうか、クライアントは知る必要がありません。
コードオンデマンド（Code on Demand, オプション）：この原則は、必要に応じてコード（JavaScriptなど）をクライアントに送信できることを指します。これはオプショナルな原則であり、すべてのRESTサービスで必要とされるわけではありません。
ユニフォームインターフェース（Uniform Interface）：RESTの基本的な原則の一つで、システム全体の一貫性を保つための重要な要素です。この原則には、リソースの識別、リソースの操作の自己説明性、メッセージの自己説明性、そしてHATEOAS（Hypermedia As The Engine Of Application State）などの概念が含まれています。
RESTfulなシステム
RESTfulなシステムは、RESTの原則に基づいて設計・構築されたシステムのことです。これにより、システム間の相互作用が簡素化され、拡張性や信頼性、パフォーマンスが向上します。
TCP/IP
TCP/IP（Transmission Control Protocol/Internet Protocol）は、インターネットでデータの送受信を行うための基本的なプロトコル（通信規約）です。TCPはデータの送受信を制御し、IPはデータパケットのルーティングを担当します。
Chapter3
メッセージヘッダー
メッセージヘッダーは、HTTPメッセージの開始部分に位置し、リクエストやレスポンスに関する情報を含んでいます。例えば、使用されているHTTPのバージョン、リクエストのメソッド、レスポンスのステータスコードなどがあります。
一般ヘッダーフィールド
一般ヘッダーフィールドは、リクエストとレスポンスの両方で使用されるヘッダーで、メッセージ全体に関連する情報を持つ。例えば、Date（メッセージの生成日時）、Connection（接続の制御）、Cache-Control（キャッシングの制御）などがあります。
リクエストヘッダーフィールド
リクエストヘッダーフィールドは、リクエストに特定の情報を含むヘッダーです。クライアントからサーバーへのリクエストに付加され、例えばUser-Agent（クライアントのソフトウェア情報）、Accept（受け入れ可能なメディアタイプ）などの情報を提供します。
レスポンスヘッダーフィールド
レスポンスヘッダーフィールドは、レスポンスに特定の情報を含むヘッダーです。サーバーからクライアントへのレスポンスに付加され、例えばServer（サーバーのソフトウェア情報）、Location（リダイレクト先）などの情報を提供します。
エンティティヘッダーフィールド
エンティティヘッダーフィールドは、メッセージボディ（実際のデータ部分）に関する情報を含むヘッダーです。例えばContent-Type（メディアタイプ）、Content-Length（ボディの長さ）などがあります。
コネクション
コネクションとは、ネットワーク上の2つのエンドポイント間の通信チャンネルを指します。TCP/IPネットワークでは、コネクションはTCPプロトコルにより確立、管理、終了されます。
SYNパケット
SYNパケットは、TCPコネクションを開始するために使用されるデータパケットです。これは3ウェイハンドシェイク（通信の開始手続き）の一部として送信されます。
ACKパケット
ACKパケットは、TCP通信においてデータが正しく受信されたことを通知するためのパケットです。ACKパケットの送信により、送信元はデータが正しく受信されたことを確認できます。
ストリーム
2つのアプリが、お互いに、連続したデータ列を送受信するための機能。
データを送信する際、それは一つの連続したストリームとして送られます。このストリームは、一連のバイト（情報の最小単位）で構成されています。TCPは、このバイトのストリームを送受信するためのプロトコルであり、そのためには、バイトがどの順序で送られてきたかを追跡します。つまり、送信元から送られてきたデータの順序が逆になったり、混乱したりすることなく、それが受信側で正確に再構成されることを保証します。
また、TCPは信頼性が高い通信を提供します。つまり、データが失われたり、破損したりすることなく、正確に送受信されることを確認します。もし何か問題が起きた場合（例えば、データが途中で失われた場合など）、TCPはその問題を自動的に検出し、データの再送を行います。
HPACK
HPACKは、HTTP/2で導入された新しいヘッダー圧縮形式です。これにより、ヘッダーのサイズを縮小し、ネットワークのオーバーヘッドを減らすことが可能となりました。
サーバープッシュ
サーバープッシュは、HTTP/2の機能で、クライアントが明示的にリクエストする前にサーバーからリソースを送信することができます。これにより、ページの読み込み速度を向上させることができます。
SSL/TLS
SSL（Secure Sockets Layer）およびその後継であるTLS（Transport Layer Security）は、インターネット上でのデータ通信を暗号化し、保護するためのプロトコルです。これにより、通信内容の秘密性と完全性が保たれます。
メッセージダイジェスト
メッセージダイジェストは、メッセージ（データ）から生成される固定長のハッシュ値です。これは一方向性を持ち、元のメッセージから生成されますが、ダイジェストから元のメッセージを復元することは非常に困難です。
Cookie
Webサイトがユーザーのブラウザに一時的に保存する小さなテキストファイルです。
これにより、Webサイトはユーザーのブラウザを識別し、その状態や設定を追跡できます。クッキーの一般的な用途は、ログイン情報の記録、カート内のアイテムの記録、ユーザープリファレンスの保存などです。
クッキーはセッションクッキーとパーシステントクッキーの2種類に分類されます。セッションクッキーはブラウザが開かれている間だけ存在し、ブラウザを閉じると消えます。対して、パーシステントクッキーは設定された有効期限が来るまでブラウザに残ります。
セッションID
セッションIDは、サーバーがクライアントのセッション（ユーザーの一連のリクエスト）を識別するために使用する一意の識別子です。通常はクッキーを介してクライアントに送られ、クライアントはそれを使ってサーバーに自身を識別します。
CookieとセッションIDの違い
クッキーは、ウェブサイトがユーザーのブラウザに保存する小さなデータ片です。それに対して、セッションIDはクッキーを通じてユーザーを一意に識別するために使用される特定の情報です。つまり、セッションIDはクッキーの中に格納されることが多いです。
Chapter4
XHTML
XHTMLは、HTMLとXMLの要素を組み合わせたウェブページのマークアップ言語です。より厳格な文法規則を持ち、HTMLよりも厳密に書かれる必要があります。
ECMAscript
ECMAScriptは、JavaScriptの標準化されたバージョンで、JavaScriptの基礎となるコア機能を定義しています。これにより、異なる環境でJavaScriptが一貫して動作するようになります。
DOM
DOM（Document Object Model）は、HTMLやXML文書の構造を表すモデルで、プログラムから文書の内容や構造を操作するためのインターフェースを提供します。
DOMツリーは、DOMの階層的な表現で、文書の各要素をノードとして表現します。
フィード
フィードは、ウェブサイトの新しいコンテンツを定期的に提供するメカニズムです。RSSやAtomなどのフォーマットを使用し、ユーザーが定期的にウェブサイトを訪れる代わりに新しいコンテンツを取得できます。
RSS
RSSは、ウェブサイトの更新情報を配信するためのXMLベースのフォーマットです。ユーザーはRSSリーダーを使ってRSSフィードを購読し、新しいコンテンツを自動的に取得できます。
Chapter５
MVCモデル
MVC（Model-View-Controller）は、アプリケーションの設計パターンで、データ管理（Model）、ユーザーインターフェース（View）、データとユーザーインターフェースの間の制御（Controller）を分離します。これにより、開発とメンテナンスが容易になります。
アプリケーションサーバー
アプリケーションサーバーは、ネットワーク上でビジネスロジックを実行するサーバーです。クライアントからのリクエストを受け取り、適切な応答を生成するためにデータベースや他のリソースと連携します。
セッション管理
セッション管理は、ウェブアプリケーションがユーザーの一連のリクエスト（セッション）を追跡するためのメカニズムです。これにより、ユーザーの状態（例：ログイン状態）を一定期間保持できます。
トランザクション管理
トランザクション管理は、複数の操作を一連の作業単位（トランザクション）として扱うことで、データの一貫性と完全性を保つためのプロセスです。例えば、データベースの更新操作では、全ての操作が成功するか、全てが失敗して元に戻る（ロールバック）かのどちらかとなります。
ミラーリング
ミラーリングは、データの可用性と耐障害性を高めるための手法で、データを二つ以上のディスクに同時に書き込むことで一つのディスクが故障してもデータを保護します。
レプリケーション
レプリケーションは、データベースのコピーを複数の場所に作成し、データの可用性を高めるとともに、パフォーマンスを向上させる手法です。これにより、一つの場所が故障した場合でもデータが利用可能であり続けます。
シェアードディスク
シェアードディスクは、複数のコンピューターが同時にアクセスできるストレージのことを指します。これにより、データの共有とコラボレーションが可能になります。
Ajax
Ajax（Asynchronous JavaScript and XML）は、ページ全体を再読み込みすることなく、ウェブページの一部を更新する技術です。JavaScriptを使用してサーバーと非同期通信を行い、ユーザーエクスペリエンスを向上させます。
Web API
Web APIは、ウェブサービスが提供する機能を他のアプリケーションから利用するためのインターフェースです。HTTPを通じてデータをリクエストし、多くの場合はJSONまたはXML形式でデータを取得します。
AJP
AJP（Apache JServ Protocol）は、Webサーバーとアプリケーションサーバー間でデータを効率的に交換するためのプロトコルです。AJPは主にApache HTTPサーバーとTomcatサーバーの間の通信で使用されます。
WebSocket
WebSocketは、ウェブブラウザとサーバー間の双方向通信を可能にするプロトコルです。HTTPと異なり、WebSocketは接続が開始されるとその接続が維持され、データのリアルタイムな双方向転送を可能にします。
ODBC
ODBC（Open Database Connectivity）は、アプリケーションがデータベース管理システム（DBMS）と対話するための標準インターフェースです。ODBCを使用すると、アプリケーションはDBMSの種類に関係なく、データベースにアクセスできます。
Chapter６
CSRF
CSRF（Cross-Site Request Forgery）は、ウェブサイトのセキュリティ上の脆弱性で、攻撃者がユーザーの偽装したリクエストをサイトに送信し、ユーザーの意図しない操作を行わせる攻撃です。
XSS
XSS（Cross-Site Scripting）は、ウェブサイトのセキュリティ上の脆弱性で、攻撃者がウェブページに悪意のあるスクリプトを注入し、他のユーザーに対してそのスクリプトを実行させる攻撃です。
IDS
IDS（Intrusion Detection System）は、ネットワークやシステムに対する不正なアクセスや攻撃を検出するシステムです。異常な活動や攻撃のパターンを検出するために使用されます。
IPS
IPS（Intrusion Prevention System）は、不正なアクセスや攻撃を検出するだけでなく、それらを阻止するシステムです。IDSと組み合わせて、ネットワークのセキュリティを強化することができます。
フォールトトレランス
フォールトトレランスは、システムがハードウェア故障やソフトウェアの問題に耐え、その機能を継続できる能力を指します。これにより、システムのダウンタイムを最小限に抑えることができます。
シグネチャ型
シグネチャ型は、セキュリティシステムが既知の攻撃のパターン（シグネチャ）を識別することで、不正なアクティビティを検出する方法です。シグネチャ型は、ウイルス対策ソフトウェアや侵入検出システム（IDS）でよく使用されます。
アノマリー型
アノマリー型は、セキュリティシステムが正常なシステムの行動を学習し、そのパターンからの逸脱を不正なアクティビティとして検出する方法です。未知の攻撃や新しい脅威を検出するために使用されます。
OAuth
OAuthは、ユーザーが自身の資格情報を直接共有せずに、サードパーティアプリケーションにリソースへの限定的なアクセスを許可する方法を提供する開放規格です。TwitterやGoogleのようなサービスでよく使用されます。
リソースオーナー
リソースオーナーは、OAuthにおいて、一定のリソース（データ）に対するアクセス許可を持つエンティティを指します。ほとんどの場合、リソースオーナーはエンドユーザー自身です。
リソースサーバー
リソースサーバーは、OAuthにおいて、ユーザーのデータやサービスをホストし、それらを保護するサーバーを指します。リソースサーバーは、適切なアクセストークンを持つクライアントのみがリソースにアクセスできるようにします。
トークン
トークンは、セキュリティ認証で使用されるデジタルなクレデンシャルです。OAuthでは、アクセストークンは、クライアントがリソースサーバーからリソースを取得するための「鍵」の役割を果たします。
OpenID Connect
OpenID Connectは、ユーザー認証のためのオープンな標準です。これは、ユーザーが一度ログインすれば複数のサービスやアプリケーションに対してその認証状態を共有するものです。
OAuthとOpenID Connectの違い
OAuthとOpenID Connectはどちらもオープンな認証規格であり、ウェブサイトやアプリケーションがユーザーを認証し、特定のサービスに対するアクセスを許可するために使用されますが、役割と目的に違いがあります。
OAuth：
OAuth 2.0は認可フレームワークです。これは、ユーザーが第三者アプリケーションに自分のアカウントの特定の情報へのアクセスを許可することを可能にします。一般的な例は、FacebookやGoogleを使って他のアプリケーションにログインする機能です。ユーザーは、自分のFacebookまたはGoogleの資格情報を直接第三者アプリケーションに提供する代わりに、FacebookやGoogleから特定の情報へのアクセス許可を第三者アプリケーションに付与します。
ただし、OAuthは「誰が誰であるか」を明らかにすることはありません。つまり、認証（ユーザーが誰であるかの確認）ではなく、認可（ユーザーが何をすることを許されているか）に関するものです。
OpenID Connect：
一方、OpenID Connectは、OAuth 2.0の上に構築された認証レイヤーです。これは、ユーザーが誰であるかをアプリケーションに確認するための方法を提供します。OpenID Connectを使用すると、ユーザーは認証プロバイダ（FacebookやGoogleなど）を通じて自分自身をアプリケーションに確認できます。
OpenID Connectは、「誰が認証され、その人物が誰であるか」についての情報（一般的には「IDトークン」と呼ばれる）を提供します。つまり、認証（ユーザーが誰であるかの確認）を目的としています。
要するに、OAuthは認可（何が許されているか）に焦点を当て、OpenID Connectは認証（誰が誰であるか）に焦点を当てています。これらはしばしば一緒に使用され、ユーザーが誰であるか（OpenID Connectによる認証）とそのユーザーが何を許可されているか（OAuthによる認可）を同時に管理します。
この記事が気に入ったらサポートをしてみませんか？