駆け出しエンジニアが知っておくべきWeb技術の基本用語(その2)
はじめに
以前、「駆け出しエンジニアが知っておくべきWeb技術の基本用語」という記事を投稿しましたが、今回はその第2弾です。
前回取り上げた用語は、プログラミング学習の前段階で知っておくべきような内容のものでしたが、今回はより実践寄りの用語を掲載しています。
Web技術の用語は、実際に自らサイトやシステムを構築する中で、これらの知識が必要になった時に改めて振り返ることで、
本当の意味でその内容を理解できると思います。
今回は、未熟ながらも普段フロントエンドエンジニアとして働いている自分自身の知識を整理する意味もあったりします。
もし書いている内容で間違っている点などありましたら、コメントで指摘して頂けると非常に助かります。
1. ステートフル (Stateful):
システムやプロトコルが前回の状態やアクションを覚え、それに基づいて次の動作を判断する性質を指します。これは、連続するアクションやリクエストに対して特定の状態が保持され、その状態が後続のアクションやリクエストに影響を与えるという考え方です。
ステートフルなシステムは、ユーザーの活動やセッション情報などをトラッキングし、それに基づいて個々のユーザーやクライアントに対して異なる振る舞いをすることがあります。
特徴:
- 状態の保持:
ステートフルなシステムは、ユーザーのセッション情報や特定の状態を保持します。これにより、連続するアクションやリクエストにおいて一貫性を保ちながら振る舞いが変わります。
- コンテキストの理解:
システムが前回のユーザーアクションを記憶しているため、ユーザーのコンテキストを理解し、よりパーソナライズされた体験を提供できます。
- セッション管理:
ユーザーセッションをトラッキングし、ログイン状態やセッションの有効期限などを管理することができます。
使用例:
- ログインセッション:
ウェブアプリケーションでのユーザーのログインセッションはステートフルな例です。ユーザーがログインすると、その情報がセッションに保存され、後続のリクエストにおいてユーザーが認証された状態が維持されます。
- カートの管理:
オンラインショッピングサイトにおいて、ユーザーが商品をショッピングカートに追加すると、その情報がセッションに保存され、ユーザーがサイトを閉じても再度開いた際にカートの中身が維持されます。
利点:
- パーソナライズされた体験:
ユーザーごとに異なる状態を保持できるため、パーソナライズされた体験を提供しやすいです。
- セキュリティ向上:
セッション情報やユーザーステートを管理することで、セキュリティを向上させることができます。
欠点:
- サーバー負荷:
サーバーはセッション情報を保持する必要があるため、大量のユーザーが同時に利用する場合、サーバー負荷が増加する可能性があります。
- スケーラビリティの課題:
ステートフルな設計はスケーラビリティの課題を引き起こすことがあり、大規模なシステムでは管理が難しくなることがあります。
ステートフルな設計は、特定の用途や要件に応じて有効であり、ウェブアプリケーションやセッションベースのアプリケーションなどで一般的に使用されています。
2. ステートレス (Stateless):
システムやプロトコルが前回の状態を覚えず、各リクエストやアクションを独立して処理する性質を指します。このアプローチでは、各リクエストはその都度独立して処理され、前回の状態や情報は保持されません。これにより、システムは特定のユーザーの過去の活動や状態に依存せず、各リクエストを個別に処理することが可能です。
特徴:
- 状態の非保持:
ステートレスなシステムでは、前回の状態やセッション情報が保持されません。各リクエストは独立して処理されます。
- 独立性:
各リクエストは前回のリクエストとは無関係であり、それぞれが個別に処理されるため、相互の影響が少ないです。
使用例:
- HTTPプロトコル:
HTTPはステートレスなプロトコルであり、各HTTPリクエストは他のリクエストとは無関係に処理されます。これにより、ウェブサーバーはクライアントの状態を保持せずにリクエストに応じたレスポンスを生成します。
- RESTful API:
RESTfulなAPIは通常ステートレスなデザインを採用しています。クライアントがAPIに対してリクエストを送り、サーバーがそれに対してレスポンスを返すが、クライアントの前回のリクエストに基づいてサーバーが状態を保持することはありません。
利点:
- スケーラビリティ:
ステートレスなアーキテクチャはスケーラビリティが向上しやすいです。各リクエストが独立しているため、負荷分散や並列処理がしやすくなります。
- シンプルな実装:
ステートレスなシステムは状態を保持する必要がないため、実装がシンプルになりがちです。各リクエストを単純に処理することができます。
欠点:
- 情報の共有が難しい:
各リクエストが独立しているため、クライアントやサーバー間で前回の情報を共有するのが難しい場合があります。
- セッション管理の複雑さ:
ステートレスなシステムではセッション管理が複雑になりがちで、一連の操作を追跡するための手段が必要です。通常はクライアントがセッション情報を持つことがあります。
ステートレスなデザインは一般的に、分散システムやクラウドベースのアプリケーション、マイクロサービスなどで利用されることがあります。それにより、システムが柔軟で拡張性があり、単純なリクエスト/レスポンスモデルを実現できます。
3. リクエスト (Request):
クライアントがサーバーに向けて特定のアクションやデータの提供を要求するための通信メッセージです。主にクライアント(要求者)が行い、それに対してサーバー(受信者)が応答します。リクエストは通信プロトコルによって構造化され、要求された操作やデータの詳細が含まれています。
リクエストの構成要素:
- HTTPメソッド:
リクエストが実行したい操作を示すためのメソッドです。代表的なHTTPメソッドには、GET(データの取得)、POST(データの送信)、PUT(データの更新)、DELETE(データの削除)などがあります。
- URI(Uniform Resource Identifier)またはURL(Uniform Resource Locator):
リクエストが対象とするリソース(データやサービス)を識別するための識別子です。URIやURLは、サーバー上の特定のエンドポイントやリソースを指定します。
- ヘッダー(Headers):
リクエストに関連するメタ情報や設定が含まれる部分です。例えば、ブラウザの種類、クライアントが受け入れ可能なコンテンツタイプ、認証情報などが含まれます。
- ボディ(Body):
リクエストにデータが含まれる場合、それがボディに格納されます。主にPOSTやPUTメソッドで利用され、フォームデータ、JSON、XMLなどがボディに含まれます。
具体例:
- HTTP GETリクエスト:
ウェブブラウザが特定のウェブページにアクセスするときのGETリクエストは以下のようになります。
GET /example-page HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
この例では、GETメソッドが使用され、/example-pageがリクエスト対象のURIです。
- HTTP POSTリクエスト:
フォームデータをサーバーに送信するPOSTリクエストの例は以下のようになります。
POST /submit-form HTTP/1.1 Host: www.example.com Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 username=johndoe&password=secretpassword
この例では、POSTメソッドが使用され、ボディにはフォームデータが含まれています。
リクエスト処理の流れ:
(1) クライアントがリクエストを生成:
クライアント(通常はブラウザやアプリケーション)がユーザーの操作や特定のイベントに基づいてリクエストを生成します。
(2) リクエスト送信:
クライアントが生成したリクエストが対象のサーバーに送信されます。この際、URI、HTTPメソッド、ヘッダー、ボディなどが含まれます。
(3) サーバーがリクエストを処理:
サーバーは受け取ったリクエストを解釈し、対応する処理を行います。これにはデータの取得、処理、保存などが含まれます。
(4) サーバーからのレスポンス:
サーバーは処理結果を含んだレスポンスを生成し、それがクライアントに送信されます。
リクエストとレスポンスは通信プロトコルに基づいて標準的な形式でやり取りされ、これによりクライアントとサーバーが相互にコミュニケーションを行います。
4. レスポンス (Response):
サーバーがクライアントに対して送るデータや情報のことです。通常、クライアントがサーバーに送ったリクエストに対する結果や処理のステータスが含まれます。レスポンスは通信プロトコルに基づいて構造化され、HTTPプロトコルの場合、ステータスコード、ヘッダー、ボディなどの要素が含まれます。
レスポンスの構成要素:
- ステータスコード (Status Code):
レスポンスの処理結果や状態を示す3桁の数字です。例えば、200は成功を示し、404はリソースが見つからないことを示します。ステータスコードはクライアントに対して、リクエストが成功したかどうかや何らかのエラーが発生したかを通知します。
- ヘッダー (Headers):
レスポンスに関連するメタ情報や設定が含まれる部分です。例えば、コンテンツタイプ、サーバータイプ、クッキーなどが含まれます。
- ボディ (Body):
レスポンスにデータが含まれる場合、それがボディに格納されます。HTML、JSON、画像データなど、様々な形式のデータがボディに含まれます。ボディは必ずしも含まれるとは限らず、例えばリダイレクト時のレスポンスなどではボディが空であることもあります。
具体例:
- HTTP 200 OKのレスポンス:
ウェブブラウザがウェブサーバーに特定のページのデータを要求し、成功した場合のレスポンスは以下のようになります。
HTTP/1.1 200 OK Content-Type: text/html Date: Wed, 01 Dec 2023 12:00:00 GMT <!DOCTYPE html> <html> <head> <title>Example Page</title> </head> <body> <h1>Hello, World!</h1> </body> </html>
この例では、ステータスコードが200で成功を示し、HTML形式のデータが含まれています。
- HTTP 404 Not Foundのレスポンス:
ユーザーが存在しないページにアクセスした場合のエラーレスポンスは以下のようになります。
HTTP/1.1 404 Not Found Content-Type: text/html Date: Wed, 01 Dec 2023 12:05:00 GMT <!DOCTYPE html> <html> <head> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> <p>The requested page was not found on this server.</p> </body> </html>
この例では、ステータスコードが404でリソースが見つからなかったことを示しています。
レスポンス処理の流れ:
(1) サーバーがリクエストを受信:
サーバーがクライアントからのリクエストを受信し、それに対する処理を開始します。
(2) レスポンス生成:
サーバーは処理結果やデータを含んだレスポンスを生成します。これにはステータスコードの設定、ヘッダーの追加、ボディの構築などが含まれます。
(3) レスポンス送信:
サーバーは生成したレスポンスをクライアントに送信します。これには通信プロトコルに基づく特定のルールに従います。
(4) クライアントがレスポンスを処理:
クライアントは受け取ったレスポンスを処理し、ユーザーエクスペリエンスを構築します。例えば、ウェブブラウザはHTMLデータを解釈してページを表示します。
レスポンスは通信の成否やデータの取得などにおいて非常に重要であり、クライアントとサーバーの間の信頼性を確保する役割を果たします。
5. クッキー (Cookie):
クッキー(Cookie)は、ウェブブラウザがユーザーのコンピュータに保存する小さなデータの塊であり、主にウェブサイトがユーザーに関する情報を保持し、利用者を識別するために使用されます。クッキーはユーザーエクスペリエンスの向上やセッション管理、パーソナライズされた広告などに広く活用されています。
クッキーの構成要素:
- 名前 (Name):
クッキーの識別子として使われる名前です。名前を指定することで、ウェブサイトは特定のクッキーを識別できます。
- 値 (Value):
クッキーに関連付けられたデータや情報の値です。これがクッキーに保存される実際のデータです。
- 有効期限 (Expires):
クッキーの有効期限を示す時間情報です。有効期限が切れると、ブラウザはそのクッキーを削除します。指定されていない場合、クッキーはセッション終了時に無効になります。
- ドメイン (Domain):
クッキーが送信される対象のドメインを指定します。この設定により、同じドメイン内の異なるページ間でクッキーが共有されることがあります。
- パス (Path):
クッキーが有効であるパスを指定します。通常、特定のディレクトリ階層やパス以下のページでのみクッキーが有効になります。
- セキュア属性 (Secure):
セキュアな接続(HTTPS)の場合にのみ、クッキーが送信されるようにする属性です。これにより、クッキーが暗号化された通信経路でのみ送信され、セキュリティが向上します。
- HttpOnly属性:
クッキーへのアクセスをJavaScriptから制限する属性です。これにより、クロスサイトスクリプティング(XSS)攻撃などのセキュリティリスクが軽減されます。
クッキーの使用例:
- セッション管理:
ウェブサイトはクッキーを使用して、ユーザーがサイト上でのセッションを維持します。ユーザーがログインすると、サーバーはセッションIDなどをクッキーに保存し、それによってユーザーを識別します。
- パーソナライズされた体験:
クッキーを使用して、ユーザーの設定や好みを保持し、パーソナライズされた体験を提供します。例えば、ウェブサイトがユーザーの言語設定やテーマの選択をクッキーに保存し、次回訪れた際にそれに基づいた表示を行います。
- 広告ターゲティング:
クッキーを利用して、ユーザーの興味や行動履歴に基づいて広告をターゲティングします。これにより、ユーザーにより関連性の高い広告を表示することが可能です。
クッキーの利点:
- ユーザーエクスペリエンスの向上:
クッキーを使用することで、ユーザーは個々の設定やカスタマイズを保持しながらウェブサイトを利用できます。
- セッション管理:
クッキーを使ってセッション情報を保存することで、ユーザーのログイン状態やカートの内容を維持できます。
クッキーの注意点:
- プライバシーの懸念:
クッキーはユーザーのブラウジング情報を追跡するため、プライバシーの懸念があります。一部のユーザーはクッキーを無効にしていることもあります。
- セキュリティリスク:
クッキーは悪意のある攻撃者によって悪用される可能性があります。セキュアな実装が必要です。
クッキーは一般的に利用されていますが、プライバシーやセキュリティに対する配慮が求められることもあります。最近では、同様の目的でローカルストレージやセッションストレージなども利用されています。
6. プロトコル (Protocol):
異なるコンピュータやシステムが情報を共有し合うための取り決めや規則のセットです。コンピュータネットワークや通信システムにおいて、データの送受信、通信の確立や制御、エラーの処理などを一貫した方法で行うためにプロトコルが使用されます。プロトコルは通信のスタンダードな枠組みを提供し、異なる機器やシステムが互いに理解し合えるようにします。
プロトコルの種類:
データの送受信や通信の確立を規定するプロトコルです。例えば、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)などがあります。これらはインターネットでの通信において広く利用されています。
- ネットワークプロトコル:
コンピュータネットワークでのデータの送受信や経路の選択を定義するプロトコルです。例えば、IP(Internet Protocol)やICMP(Internet Control Message Protocol)があります。IPはデータパケットの送信と受信を、ICMPはネットワーク上のエラーメッセージの通知を担当しています。
- アプリケーション層プロトコル:
特定のアプリケーションでのデータのやり取りや通信手順を定義するプロトコルです。例えば、HTTP(HyperText Transfer Protocol)やSMTP(Simple Mail Transfer Protocol)があります。HTTPはウェブブラウザとウェブサーバーの間でのデータ転送に使用され、SMTPは電子メールの送信に使用されます。
プロトコルの要素:
- シンタックス (Syntax):
データの形式や構造、通信のフレームワークなど、プロトコルが定める文法規則や形式のことです。これにより、通信相手がデータを正しく解釈できるようになります。
- セマンティクス (Semantics):
データの意味や内容に関するルールや取り決めのことです。これにより、通信相手がデータを理解し、適切に処理できるようになります。
- タイミング (Timing):
データの送信や受信、通信の確立や切断など、時間的な制約や順序を規定する要素です。これにより、通信が一貫した手順で行われるようになります。
プロトコルの例:
インターネットで使用される主要なプロトコルスイートであり、TCPやIPを含むさまざまなプロトコルから成り立っています。これにより、異なるコンピュータやネットワークが相互に通信できます。
- HTTP (HyperText Transfer Protocol):
ウェブブラウザとウェブサーバーの間でのハイパーテキスト文書の転送に使用されるプロトコルです。クライアントがリクエストを送り、サーバーがそれに対してレスポンスを返す仕組みを提供します。
- SMTP (Simple Mail Transfer Protocol):
電子メールの送信に使用されるプロトコルで、メールサーバー間でメールの転送を行います。発信メールサーバーが宛先メールサーバーにメールを送信するための取り決めを提供します。
プロトコルの重要性:
- 相互運用性:
プロトコルは異なる機器やシステムが共通の言語を理解し、相互に通信できるようにするため、相互運用性を確保します。
- セキュリティ:
セキュリティプロトコルは、データの暗号化や認証などのセキュリティ機能を提供し、通信の安全性を確保します。
- 標準化:
プロトコルの標準化により、異なるベンダーや開発者が同じ仕様に基づいてシステムを開発できるため、規模の大きなネットワークやシステムの構築が容易になります。
プロトコルはコンピュータネットワークや通信において基本的な概念であり、異なるコンポーネントやシステムが円滑に協力して動作するために必要不可欠です。
7. ポート番号 (Port Number):
コンピュータネットワーク上で特定のプロセスやサービスにアクセスするために使用される識別子です。TCPやUDPといったトランスポート層のプロトコルを使用する通信において、データがどのプロセスやサービスに届くかを区別するためにポート番号が割り当てられます。ポート番号は0から65535までの範囲で指定され、一部は標準的に使われるものがあります。
ポート番号の種類:
- ウェルノウンポート(Well-Known Ports):
0から1023までのポート番号で、一般的なサービスやプロトコルに割り当てられています。例えば、HTTP(80番ポート)、HTTPS(443番ポート)、FTP(21番ポート)などがあります。
- 登録済みポート(Registered Ports):
1024から49151までのポート番号で、一般的なアプリケーションやサービスに対して登録されています。例えば、MySQL(3306番ポート)、SSH(22番ポート)などが含まれます。
- ダイナミック・プライベート・ポート(Dynamic and/or Private Ports):
49152から65535までのポート番号で、一般的なアプリケーションやサービスに対して登録されていない範囲です。これはクライアントからの一時的な接続に使用されることがあります。
ポート番号の重要性:
- プロセス識別:
ポート番号を使用することで、同じホスト上で複数のネットワークサービスやプロセスが同時に実行されていても、正確に特定されます。
- サービスの区別:
ポート番号により、どのサービスやプロトコルが通信しているかを区別できます。これにより、異なるサービスが同じホスト上で同時に動作できます。
ポート番号の例:
- HTTP (HyperText Transfer Protocol):
標準的なウェブブラウジングに使用されるポート番号は80番です。例えば、http://example.com:80。
- HTTPS (HyperText Transfer Protocol Secure):
セキュアなウェブブラウジングに使用されるポート番号は443番です。例えば、https://example.com:443。
- FTP (File Transfer Protocol):
ファイル転送に使用されるポート番号は21番です。例えば、ftp://example.com:21。
- SSH (Secure Shell):
リモートシェルアクセスやセキュアなデータ通信に使用されるポート番号は22番です。例えば、ssh example.com。
- MySQL Database Server:
MySQLデータベースサーバーに接続するためのポート番号は通常3306番です。例えば、mysql -h example.com -P 3306。
ポート番号の利用:
- プログラミング:
プログラミング言語やフレームワークを使用して、特定のポート番号を指定してネットワークプログラムを開発することがあります。
- システム管理:
システム管理者は、サーバーやネットワークデバイスにおいて特定のポート番号を監視し、トラフィックを制御することがあります。
- ネットワーク構成:
ネットワーク機器やファイアウォールなど、ネットワーク構成においてポート番号を設定して通信を管理することがあります。
ポート番号はネットワーク通信において非常に重要であり、正確なポートの使用は通信の正常な機能とセキュリティを確保する上で不可欠です。