
はじめに#
私たちのウェブ開発の旅を始める前に、まずは ウェブ とは何かについてお話ししましょう。これにより、皆さんが感覚的に理解できることを願っています。まず、ウェブは複雑な都市交通ネットワークのようなもので、ウェブのクライアントはこの都市の中のあなたの家のようなものであり、サーバーはあなたが行きたい都市の中のある店舗のようなものです。そこで、ウェブの用語や構成要素をこのような文脈に当てはめてみましょう:
- ネットワーク接続:インターネット上でデータを送受信することを可能にし、あなたの家と店舗をつなぐ通りのように考えることができます。これは一定量の車両(データ流)を運ぶことができます。
- TCP/IP: 転送制御プロトコル (Transmission Control Protocol) とインターネットプロトコル (Internet Protocol) は、データがどのように転送されるかを定義する通信プロトコルです。これは、店舗で買い物をする際に使用する交通手段(自動車や自転車など)に似ています。関連する交通ルール(プロトコル)は、どのような車両が通行できるか(データ形式)、車両がどのように運転されるか(データがどのように伝達されるか)を規定しています。渋滞や事故などの予期しない状況もネットワーク伝送中にしばしば発生します(ただし、ネットワークの世界では、科目一から科目四までの試験を受ける必要はありません、ハハ)。
https://en.wikipedia.org/wiki/Internet_protocol_suite - DNS: ドメインネームシステム (Domain Name System) サーバーは、ウェブサイトの電話帳のようなもので、ドメイン名と IP アドレスの対応関係を記録しています。ブラウザに URL を入力すると、ブラウザはウェブページを取得する前に対応するドメインネームシステムを確認し、ドメイン名を認識可能な IP アドレスに翻訳します。これにより、ブラウザはあなたが欲しいウェブページを保存しているサーバーを見つけ、正しい場所に HTTP リクエストを送信することができます。これは、あなたが行きたい店舗を決めた後、その具体的な地理的位置を知り、地図上でその位置を見つけることに似ています。
https://developer.mozilla.org/zh-CN/docs/Learn/Common_questions/What_is_a_domain_name - HTTP: ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol) は、クライアントとサーバー間の通信を定義する言語のプロトコルで、アプリケーション層のプロトコルに属し、TCP/IP が位置するトランスポート層よりも一段上の層です(詳細は本文末尾の OSI モデル図を参照)。これは、オンラインショッピングで注文をする際に記入するフォームのようなもので、あなたの連絡方法、受取先住所、商品情報などを詳細に説明します。このプロセスでは、商品が具体的にどのように輸送されるかを心配する必要はなく、商人と取引を成立させて注文を成功させれば、安心して自宅で配達を待つことができます(これが抽象化です!HTTP はより高いレベルの抽象化であり、低レベルの TCP/IP プロトコルの実装方法を知る必要はありません。異なる層間の通信形式 — インターフェースを合意し、その後各自が自分の役割を果たせば良いのです)。
- 構成ファイル:ウェブページは多くの異なるタイプのファイルで構成されており、店舗の異なるカテゴリの商品に似ています。これらのファイルは大きく分けて 2 種類に分類できます:
- コード:ウェブページは主に HTML、CSS、JavaScript で構成されていますが、後の内容でさらに多くの異なる技術を見ることができます。
- リソース:ウェブページを構成する他の静的ファイルの集合で、画像、音楽、動画、Word 文書、PDF ファイルなどがあります。一度決定されると、ほとんど変更されることはありません。

https://developer.mozilla.org/zh-CN/docs/Learn/Getting_started_with_the_web/How_the_Web_works
MDN を多く訪れてみてください (https://developer.mozilla.org/)。ここでは多くの技術的詳細や用語の権威ある解説を見ることができます。
ウェブのマクロな説明を経て、次はウェブの世界のいくつかの専門用語や重要な技術を一つずつ深掘りしていきましょう(意味の正確な伝達を保証するために、以下の内容には一部英語の原文が残されています。皆さんは読むのにそれほど障害はないと思いますが)。
ワールドワイドウェブ#
ウェブサーバー#
ウェブサーバーはハードウェアまたはソフトウェア、またはそれらが協調して動作する全体を指すことができます。
- ハードウェア部分(商場に商品を保管する棚):ウェブサーバーは、ネットワークサービスソフトウェアとウェブサイトの構成ファイル(HTML 文書、画像、CSS スタイルシート、JavaScript ファイルなど)を保存しているコンピュータです。インターネットに接続されており、他のインターネットに接続されたデバイスとの物理データの相互作用をサポートします。
- ソフトウェア部分(商場内部の商品の在庫管理システムで、e コマースプラットフォームと接続可能):ウェブサーバーには、ホストされているファイルへのネットワークユーザーのアクセスを制御するいくつかの部分が含まれており、少なくとも HTTP サーバーである必要があります。HTTP サーバーは、URL と HTTP を理解できるソフトウェアです。サーバー上に保存されているウェブサイトのドメイン名(例えば mozilla.org)を通じてこのサーバーにアクセスでき、異なるユーザーのデバイスにその内容を配信することができます。
基本的に、ブラウザがネットワークサーバー上にホストされているファイルを必要とする場合、ブラウザは HTTP を介してそのファイルを要求します。この要求が正しいネットワークサーバー(ハードウェア)に到達すると、HTTP サーバー(ソフトウェア)がその要求を受け取り、要求された文書を見つけ(文書が存在しない場合は 404 応答を返します)、その文書を HTTP を介してブラウザに送信します(これはオンラインショッピングでの注文受け取りのプロセスに似ています)。後で Spring Boot を学ぶと、このプロセスについてより深く理解できるでしょう。
https://developer.mozilla.org/zh-CN/docs/Learn/Common_questions/What_is_a_web_server
ウェブブラウザ(クライアント)#
ブラウザは、URL を介してウェブリソースを取得し、それをユーザーのデバイスに視覚的に表示するアプリケーションソフトウェアです。ウェブの世界には、ホスト環境という概念があります。簡単に言うと、これは私たちが書いた JavaScript コードが実行される具体的な環境、または実行時環境(runtime environment)です。ブラウザはその一つであり、他にもNode.jsなどのサーバーサイドのホスト環境があります。興味のある方は自分で調べてみてください。
ブラウザに関する詳細は、後の「ブラウザにおけるページのレンダリングプロセス」セクションで紹介します。
一意のリソースロケータ(URL)#
URI (Uniform Resource Identifier) の一形態であり、リソースのパスまたは位置を提供します。
フォーマット
- 一般フォーマット: Scheme(プロトコル、例: http/https)://ドメイン名 /path:ポート
- 特殊フォーマット: file://path-to-document(「file」は文書がブラウザを実行しているマシンに存在することを示します)
テキスト http:// は、リソースを取得するために HTTP を使用する必要があることを示します。次に URL にはサーバーの完全修飾ホスト名(例: www.deitel.com)が続きます。これはリソースが存在するウェブサーバーコンピュータの名前です。ホスト名 www.deitel.com はIPアドレスに変換されます。これはインターネット上でサーバーを一意に識別する数値です。インターネットドメインネームシステム(DNS)サーバーは、ホスト名とそれに対応する IP アドレスのデータベースを維持し、自動的に変換を行います。
ヒント
- サーバーが他のポート番号を使用するように設定されている場合、そのポート番号を URL のホスト名に付加する必要があります(例: HTTP の場合は:80、HTTPS の場合は:443)。
- 埋め込まれたスペースや(; , &)は URL に含まれることはできません(サンノゼがドメイン名の場合、San%20Jose と入力する必要があります。20 はスペースの 16 進 ASCII コードです)。

自己学習: URI, URL, URN の関係と違い
パス#
絶対パス: すべてのディレクトリを含むパス
相対パス: サーバーの設定ファイルで指定されたベースパスに対する相対パス
ヒント
- http://www.gumboco.com/departments/(末尾のスラッシュは指定された文書がディレクトリであることを意味します)
- http://www.gumboco.com/(サーバーはディレクトリのトップレベルで_index.html_を探します)
マルチパーパスインターネットメール拡張(MIME)ファイルタイプ#
サーバーから受信した文書の形式を指定します(文書の先頭にサーバーによって添付され、サーバーはファイル名拡張子をキーとしてタイプのテーブルを使用して文書のタイプを決定します)。
形式: type/subtype(例: text/html, text/plain)
自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types
今、あなたはウェブ技術の全貌についてある程度理解できたと思います。HTTP というウェブの基盤プロトコルについて深く掘り下げる時が来ました(ウェブ原理の精髄部分)。このプロトコルの詳細を理解することは、フロントエンド開発やバックエンド開発の両方にとって非常に重要です!
ただし、コースの長さの制限により、多くの HTTP の派生技術点をここで一つずつ展開することはできません。興味のある方は、関連する内容の下にあるリンクを参照してください。
ハイパーテキスト転送プロトコル(HTTP)#
ハイパーテキスト転送プロトコル(HTTP)は、TCP プロトコルに基づいて超メディア文書(例: HTML)を転送するためのアプリケーション層プロトコルです(最上位のプロトコルとして、ネットワーク層やトランスポート層の詳細を隠蔽しています。詳細はボーナスの OSI モデルを参照)。これは、ウェブブラウザとウェブサーバー間の通信を制約 / 規範化するために設計されていますが、他の目的にも使用できます。HTTP は古典的なクライアント - サーバーモデルに従い、クライアントはリクエストを発行するために接続を開き、その後サーバーからの応答を受け取るまで待機します。これは、二人が会話をする際の質問と回答のターン制形式に似ています。HTTP はステートレスプロトコルであり、これはサーバーが二つのリクエスト間でデータ(状態)を保持しないことを意味します。つまり、一般的にサーバーは複数のリクエストの発信者を識別することができません。

自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Overview
メッセージは HTTP でデータを転送する最も重要な形式の一つであり、自身の規範化されたデータ形式を持っています。これらがどのような部分で構成されているのか見てみましょう(これは私たちが普段の会話で使用する言語のように、独自の文法と意味を持っています。これを理解することは、クライアントとサーバー間の情報交流を理解するのに非常に役立ちます)。
リクエストフェーズ#
- HTTP メソッド、URL のドメイン部分、HTTP バージョン
- ヘッダーフィールド
- 空行
- メッセージボディ

リクエストメソッド#
| メソッド | 説明 |
|---|---|
| GET | 指定された文書の内容を返します |
| POST | 添付されたデータを使用して指定された文書を実行します |
| HEAD | 指定された文書のヘッダー情報を返します |
| PUT | 添付されたデータで指定された文書を置き換えます |
| DELETE | 指定された文書を削除します |
自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods
ヘッダーフィールド#
- 一般ヘッダー: 日付などの一般情報用
- リクエストヘッダー: リクエストヘッダーに含まれます
例:- Accept: text/plain(要求された文書の MIME タイプに対するブラウザの好みを指定します)
- Host: ホスト名
- If-Modified-Since: 日付(指定された日付以降に変更された場合のみ要求されたファイルを送信することを指定します)
- レスポンスヘッダー: レスポンスヘッダー用
- エンティティヘッダー: リクエストとレスポンスヘッダーの両方で使用されます
自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers
レスポンスフェーズ#
- ステータスライン(例: HTTP/1.1 200 OK)
HTTP ステータスコードの最初の数字:最初の数字 カテゴリー 1 情報提供 2 成功 3 リダイレクト 4 クライアントエラー 5 サーバーエラー - レスポンスヘッダーフィールド
- 空行
- レスポンスボディ(.html)

自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status
リクエストとレスポンスのメッセージを比較してみましょう。

HTTPS#
HTTPS = HTTP + SSL/TLS(Transport Layer Security)セッション層プロトコルです。
HTTPS には二つの役割があります。一つはリクエストの対象サーバーの身元を確認すること、もう一つは転送されるデータがネットワーク中間ノードによって盗聴または改ざんされないことを保証することです。
HTTPS は、HTTP の内容を転送するために暗号化されたチャネルを使用します。つまり、HTTPS はまずサーバーとの間に TLS 暗号化チャネルを確立します。TLS は TCP プロトコルの上に構築されており、実際には転送される内容を一度暗号化します(非対称暗号化)。したがって、転送内容の観点から見ると、HTTPS と HTTP には何の違いもありません。
自己学習: https://zh.wikipedia.org/wiki/ 超文本传输安全协议
キャッシング(HTTP キャッシュ)#
キャッシュは、リソースのコピーを保存し、次回のリクエスト時にそのコピーを直接使用する技術です(時間を節約するためのスペースの交換)。ウェブキャッシュが要求されたリソースがすでに保存されていることを発見すると、リクエストを遮断し、そのリソースのコピーを返します。サーバーから再ダウンロードすることはありません。ウェブサイトにとって、キャッシュは高性能を達成するための重要な要素です。同時に、キャッシュは適切に構成する必要があります。すべてのリソースが永続的に不変であるわけではないため、リソースのキャッシュは次回変更が発生するまで有効であるべきです(期限切れのリソースをキャッシュしてはいけません)。
自己学習: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching
HTTP の歴史的進化:HTTP/0.9 → HTTP/1.0 → HTTP/1.1 → HTTP/2.0 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
実際に試してみましょう:
https://developer.chrome.com/docs/devtools/network/ | Chrome ブラウザのネットワークビューアツール、F12 を押すと、魔法が起こります!
https://hoppscotch.io/ | 使いやすいオンラインパケットキャプチャツール、メッセージを見るのがとても便利です!
プログラミングのワールドワイドウェブ(第 8 版)
インターネットとワールドワイドウェブのプログラミング(2011)
前の内容が少し圧倒されるかもしれませんが、心配しないでください。次はこれらの知識を_ブラウザのレンダリング_という実際のシーンに置き、論理的な順序でつなげて、彼らの関係を明確にし、適切な拡張を行います(この部分ではフロントエンドの三大要素に関する内容が含まれ、次のコースの予熱としても機能します。完全に理解できなくても大丈夫です)。
ブラウザにおけるページのレンダリングプロセス#
実際に、ブラウザにウェブページのアドレスを入力してエンターキーを押すと、ブラウザの処理プロセスは次のようになります:
- DNS ドメイン名解決(ここでは DNS のアドレス解決プロセスが関与します)、ウェブページが保存されているサーバーを見つけます。
- ブラウザはサーバーと TCP 接続を確立します。
- ブラウザは HTTP リクエストを発行します。
- サーバーは HTTP リクエストに応答し、そのページの HTML 内容を返します。
- ブラウザは HTML コードを解析し、HTML コード内のリソース(JavaScript、CSS、画像など)を要求します(ここでは HTTP キャッシュが関与する可能性があります)。
- ブラウザはページをレンダリングし、ユーザーに表示します(ここではブラウザのレンダリング原理が関与します)。
さらに分析すると、ブラウザにおけるページのレンダリングプロセスは二つの大きな部分に分けることができます(詳細はボーナスを参照)。
- ページナビゲーション: ユーザーが URL を入力し、ブラウザプロセスがリクエストと準備を行います。
- ページレンダリング: 関連リソースを取得した後、レンダラープロセスが現在のタブ内のレンダリング処理を担当します。
ブラウザレンダリングの全体的な流れを理解した後、ウェブページが 0 から 1 になるライフサイクルを深く見ていきましょう(ブラウザが提供する二つの重要な API - DOM と BOM について事前に理解しておきましょう。どのフロントエンドフレームワークもこの二つと関わりを持っています!あ、そうそう、ブラウザのイベントメカニズムも、優れたフロントエンドエンジニアはこれをマスターすべきです!)。



ブラウザオブジェクトモデル(Browser Object Model)、略してBOMは、ブラウザ(ホスト環境)が提供する文書(document)以外のすべての内容を処理するための他のオブジェクトを表します(JavaScript におけるブラウザの表現形式)。
文書オブジェクトモデル(Document Object Model)、略してDOMは、すべてのページ内容を変更可能なオブジェクトとして表現します。documentオブジェクトはページの主要な「入口点」です。これを使用してページ上の任意の内容を変更または作成できます(JavaScript における HTML タグの表現形式)。

実際に試してみましょう:
F12 を押して、コンソールで window または document を入力して、何が表示されるか見てみましょう。
自己学習: https://developer.mozilla.org/zh-CN/docs/Web/API/Document_Object_Model/Introduction

イベント(Event-driven)
- ブラウザイベント: ページの読み込みが完了したときやページがアンロードされるときなど
- ネットワークイベント: サーバーからの応答(Ajax イベント、サーバーサイドイベント)
- ユーザーイベント: マウスクリック、マウス移動、キー押下など
- タイマーイベント: タイムアウトが切れたときやインターバルが発生したとき(setTimeout、setInterval)
自己学習:
https://zh.javascript.info/introduction-browser-events
https://zh.javascript.info/event-loop
JavaScript 忍者の秘密(第 2 版) - JOHN RESIG BEAR BIBEAULT and JOSIP MARAS
https://zh.javascript.info/browser-environment | JavaScript を学ぶには、このサイトがあれば十分です。
ボーナス#
追加のセクション、必要に応じてどうぞ~
ソフトウェアアーキテクチャデザインパターン#
MVC (Model View Controller)
MVP (Model View Presenter)
MVVM (Model View View-Model)(現代のフロントエンドエンジニアが理解すべき View-Model の双方向バインディング)
https://github.com/livoras/blog/issues/11
ワールドワイドウェブコンソーシアム(W3C)#
ウェブ分野の布教者および標準制定者として、W3C 組織はすべてのウェブプログラマーが知っておくべき組織です。ウェブプログラミングは比較的自由でオープンですが、異なる技術の創造者と使用者を制約する統一された標準がなければ、その自由は厄介な混乱に変わるでしょう。
責任と使命
- 非独占的で相互運用可能な技術をワールドワイドウェブのために開発することに専念しています。
- 障害、言語、文化に関係なく、ウェブを普遍的にアクセス可能にすること。W3C のホームページ(www.w3.org)は、インターネットおよびウェブ技術に関する広範なリソースを提供しています。
標準制定
W3C によって標準化されたウェブ技術は推奨事項と呼ばれます(これらの標準は強制的ではありません)。現在および今後の W3C 推奨事項には、ハイパーテキストマークアップ言語 5 (HTML5)、カスケーディングスタイルシート 3 (CSS3)、および拡張可能マークアップ言語 (XML) が含まれます。推奨事項は実際のソフトウェア製品ではなく、技術の役割、構文ルールなどを指定する文書です。
ページナビゲーションプロセス#
ユーザーがアドレスバーに内容を入力すると、ブラウザ内部で次の処理が行われます:
- まず、ブラウザプロセスの UI スレッドが処理を行います。URI であれば、ネットワークリクエストを発起してウェブサイトの内容を取得します。そうでなければ、検索エンジンに入ります。
- ネットワークリクエストを発起する必要がある場合、リクエストプロセスはネットワークスレッドによって完了します。HTTP リクエスト応答が HTML ファイルであれば、データはレンダラープロセスに渡されます。他のファイルであれば、これはダウンロードリクエストを意味し、その場合はデータがダウンロードマネージャーに渡されます。
- リクエスト応答が HTML 内容であれば、ブラウザは要求されたサイトにナビゲートし、ネットワークスレッドは UI スレッドにデータが準備完了であることを通知します。
- 次に、UI スレッドはウェブページのレンダリングを行うためのレンダラープロセスを探します。データとレンダラープロセスが準備できたら、HTML データは IPC(プロセス間通信)を介してブラウザプロセスからレンダラープロセスに渡されます。
- レンダラープロセスは HTML データを受け取った後、リソースの読み込みを開始し、ページをレンダリングします。
- レンダラープロセスがレンダリングを完了すると、IPC を介してブラウザプロセスにページが読み込まれたことを通知します。

ページレンダリングプロセス#
- 解析 (Parser): HTML/CSS/JavaScript コードを解析します。
- レイアウト (Layout): 座標とサイズ、改行の有無、さまざまな position/overflow/z-index 属性などの計算を行います。
- 描画 (Paint): 要素のレンダリング層の順序を判断します。
- ラスタライズ (Raster): 計算された情報を画面上のピクセルに変換します。
自己学習: https://coolshell.cn/articles/9666.html
OSI (Open Systems Interconnection) 七層ネットワークモデル#
