はじめに#
私たちのウェブ開発の旅を始める前に、まずはウェブとは何かについてお話ししましょう。これにより、皆さんが感覚的に理解できることを願っています。まず、ウェブを複雑な都市の交通ネットワークに例えることができます。ウェブのクライアントは、この都市の中のあなたの家のようなもので、サーバーはあなたが行きたい都市の中の特定の店舗のようなものです。これを基に、ウェブの用語や構成要素をこの文脈に当てはめてみましょう:
- ネットワーク接続:インターネット上でデータを送受信することを可能にします。これは、あなたの家と店舗をつなぐ通りのように考えることができ、一定量の交通量(データ流)を運ぶことができます。
- 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 プロトコルの実装方法を知る必要はありません。異なる層間の通信形式 - インターフェースについて合意すれば、各自が自分の役割を果たせば良いのです)。
- 構成ファイル:ウェブページは多くの異なるタイプのファイルで構成されており、これは店舗の異なるカテゴリの商品に似ています。これらのファイルは大きく二つのタイプに分けられます:
- コード:ウェブページは主に 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/)。ここでは、多くの技術的詳細や用語についての権威ある解説を見ることができます。
ウェブのマクロな説明を経て、次にウェブの世界におけるいくつかの専門用語や重要な技術を一つずつ深掘りしていきましょう(意味の正確な伝達を保証するため、以下の内容には一部英語の原文が残されています。皆さんが読む際には大きな障害にはならないと思います)。
ワールドワイドウェブ#
ウェブサーバー#
ウェブサーバー(Web server)は、ハードウェアまたはソフトウェア、またはそれらが協調して動作する全体を指すことができます。
- ハードウェア部分(商場に商品を保管する棚): ウェブサーバーは、ネットワークサービスソフトウェアやウェブサイトの構成ファイル(例えば、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
オブジェクトはページの主要な「入口点」です。これを使用して、ページ上の任意の内容(HTML タグの JavaScript における表現形式)を変更または作成できます。
実際に試してみましょう:
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、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