ユーザーがgoogle.comをブラウザーに駆動すると実際に何が起こるか

この記事は、インタビューの古い質問に答えようとする試みです。「アドレスバーにgoogle.comと入力してEnterキーを押すとどうなりますか？」1つの詳細を逃さずに、できるだけ詳細に把握しようとします。



注：この 出版物は、 何が起こるか...リポジトリの内容に基づいています



提示されたコンテンツには多数の用語が豊富にあり、それらの一部の翻訳にはさまざまな不正確さがあります。 翻訳に誤りがある場合は、個人的なメッセージを書いてください。修正します。



翻訳をGitHubリポジトリに転送し、素材の作成者にプルリクエストを送信しました。編集はテキストのままにしてください。一緒にすれば、大幅に改善できます。

1. gキーを押します

記事の残りの部分には、物理​​キーボードとオペレーティングシステムの中断に関する情報が含まれています。 しかし、多くのことが起こります。これに加えて、「g」キーを押すと、ブラウザがイベントを受け取り、自動置換メカニズムが開始されます。 ブラウザのアルゴリズムとそのモード（「シークレット」機能が有効かどうか）に応じて、URLバーの下のドロップダウンウィンドウで、ユーザーは自動置換のための特定の数のオプションを提供されます。



ほとんどの自動置換アルゴリズムは、検索履歴と残っているブックマークに基づいて推奨事項をランク付けします。 一部のブラウザ（例：Rockmelt）では、Facebookの友達プロフィールも提供しています。 ユーザーがアドレスバーに「google.com」と入力する場合、上記のいずれも重要ではありませんが、それでも大量のコードが実行され、新しい文字が印刷されるたびに推奨事項が更新されます。 おそらくブラウザは、ユーザーがアドレス全体をヒットする前に、google.comにアクセスすることを提案します。

2. Enterキーを最後まで押します

特定のゼロポイントとして、キーボードのEnterキーが最後まで押されて下の位置にある瞬間を選択できます。 この時点で、このキーの電気回路が閉じ、少量の電流がキーボード配線図に送られます。この配線図では、各キースイッチの状態をスキャンし、信号を整数キーコード（この場合は13）に変換します。 キーボードコントローラーは、コンピューターに送信するためにキーコードを変換します。 原則として、転送はUSBまたはBluetooth経由で、キーボードがPS / 2またはADBコネクタを使用してコンピューターに接続される前に行われます。



USBキーボードの場合：

• 操作には、キーボードのUSB回路に5ボルトの電力が必要です。これは、コンピューターのUSBコントローラーを介して供給されます。
• 生成されたキーコードは、キーボードの内部メモリレジスタに保存され、「エンドポイント」（エンドポイント）と呼ばれます。
• コンピューターのUSBコントローラーはこのエンドポイントを10マイクロ秒ごとにポーリングし、そこに保存されているキーコードを受け取ります。
• 次に、この値はUSB SIE（シリアルインターフェイスエンジン）に送信され、低レベルUSBプロトコルを使用して形成される1つ以上のUSBパケットに変換されます。
• これらのパケットは、HIDデバイス（Human Interface Device）が常に「低速」であるため、さまざまな電気信号を使用して、最大速度1.5 Mb / sでD +およびD-コンタクトを介して送信されます。
• このシリアル信号は、コンピューターのUSBコントローラーでデコードされ、HIDデバイス（キーボード）のユニバーサルドライバーによって解釈されます。 次に、キーコード値がオペレーティングシステムの「鉄」レベルの抽象化に転送されます。

仮想キーボード（タッチスクリーン）の場合：

• ユーザーが最新の静電容量式タッチスクリーンに指を置くと、少量の電流が指に流れます。 これにより、導電層の静電界によって回路が閉じられ、画面のこのポイントで電圧降下が発生します。 次に、画面上のコントローラーが「クリック」座標を報告する割り込みを開始します。
• 次に、モバイルOSは、GUI要素の1つ（この場合は仮想キーボードのボタン）でクリックイベントを現在開いているアプリケーションに通知します。
• 仮想キーボードにより、ソフトウェア割り込みが発生し、「キーが押されました」というメッセージがOSに返されます。
• この割り込みは、現在開いているアプリケーションに「キーを押す」イベントの発生を通知します。

2.1中断が発生した[USBキーボードではない]

キーボードは信号を「割り込み要求ライン」（IRQ）に送信し、その後、割り込みコントローラーによって「割り込みベクトル」（整数）にマッピングされます。 プロセッサは、「割り込み記述子テーブル」（IDT）を使用して、割り込みベクトルをカーネルの機能（「割り込みハンドラー」）にマップします。 割り込みが発生すると、プロセッサ（CPU）はIDTを割り込みベクターで更新し、対応するハンドラーを起動します。 したがって、コアが機能します。

2.2（Windowsの場合） WM_KEYDOWN



メッセージがアプリケーションに送信されました

HIDは、押されたキーイベントをKBDHID.sys



ドライバーに送信し、ドライバーはそれをスキャンコードに変換します 。 この特定のケースでは、スキャンコードはVK_RETURN



（ 0x0D



）です。 KDBHID.sys



ドライバーは、 KBDCLASS.sys



ドライバー（キーボードクラスドライバー）と通信します。 彼は、すべてのキーボード入力を安全に処理する責任があります。 将来、このドライバーはWin32K.sys



呼び出しWin32K.sys



（インストールされているサードパーティのキーボードフィルターを介したメッセージ送信の可能性の後）。 これはすべてカーネルモードで行われます。



Win32K.sysは、 GetForegroundWindow()



関数を使用して、現在アクティブなウィンドウを判別します。 このAPIは、ブラウザのアドレスバーウィンドウの処理を提供します。 次に、Windowsのメインの「メッセージポンプ」がSendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam)



呼び出します。 lParam



は、キーストロークに関する詳細情報を示すビットマスクです。再試行カウンター（この場合は0）、現在のスキャンコード（OEMに依存する場合がありますが、 VK_RETURN



は通常これに依存しません）、情報追加のキー（たとえば、Alt、Shift、Ctrl-この場合はそうではありませんでした）およびその他のデータ。



Windows APIには、特定のウィンドウハンドラー（ hWnd



）のメッセージをキューにSendMessage



関数があります。 その後、 hWnd



ハンドラーに割り当てられたメインのメッセージ処理関数（ WindowProc



）がhWnd



れ、キュー内のすべてのメッセージが処理されます。



現在アクティブなウィンドウ（ hWnd



）は処理の制御であり、この場合、WindowsProcにはWM_KEYDOWN



メッセージのハンドラーがWM_KEYDOWN



ます。 このコードは、 SendMessage (wParam)



に含まれる3番目のパラメーターを調べ、 VK_RETURN



であるため、ユーザーがEnterキーを押したことを理解します。

2.3（OS Xの場合） NSEVent KeyDown



がアプリケーションに送信されました

割り込み信号は、キーボードI / Oキットドライバーで割り込みイベントをトリガーします。 ドライバーは信号をキーボードコードに変換し、それがWindowServer



というOS Xプロセスに渡されます。 その結果、 WindowsServer



は、イベントがキューに入れられているMachポートを介して、適切な（アクティブまたは「リスニング」）アプリケーションにイベントを渡します。 その後、 mach_ipc_dispatch



関数を呼び出すのに十分な特権を持つスレッドによって、このキューからイベントを読み取ることができます。 ほとんどの場合、これは発生し、 NSEventype KeyDown



NSEvent



を介してメインNSApplication



ループを使用して処理されます。

2.4（GNU / Linuxの場合）Xorgサーバーはキーボードコードをリッスンします

グラフィカルXサーバーの場合、一般的なevdev



イベントドライバーがキーストロークの受信に使用されます。 キーボードコードをスキャンコードに再割り当てするには、特別なルールとXサーバーカードを使用します。 押されたキーのスキャンコードのマッピングが完了すると、Xサーバーはその文字をウィンドウマネージャー（DWM、metacity、i3）に送信し、ウィンドウマネージャーはその文字をアクティブウィンドウに送信します。 文字を受け取ったウィンドウのグラフィカルAPIは、目的のフィールドに対応するフォント文字を印刷します。

3. URL解析

ブラウザには、次のURL情報があります。

プロトコル「HTTP」

ハイパーテキスト転送プロトコルを使用する



リソース「/」

メイン（インデックス）ページを表示

3.1これはURLですか、それとも検索クエリですか？

ユーザーがプロトコルまたはドメイン名を入力しない場合、ブラウザーはユーザーが入力した内容をデフォルトの検索エンジンに「フィード」します。 多くの場合、特別なテキストがURLに追加されるため、情報が特定のブラウザーのURLバーから送信されることを検索エンジンが理解できます。

3.2 HSTSチェックリスト

• ブラウザは、「プリロードされたHSTS（HTTP Strict Transport Security）」のリストを確認します。 これは、HTTPS経由でのみアクセスする必要があるサイトのリストです。
• 目的のサイトがこのリストにある場合、ブラウザはHTTPではなくHTTPSを介してリクエストを送信します。 それ以外の場合、最初の要求はHTTP経由で送信されます。 （同時に、サイトはHSTSポリシーを使用できますが、HSTSリストには含まれません-この場合、最初のHTTP要求には、HTTPS経由で要求を送信する必要があるという応答が送信されます。ただし、これにより、ユーザーはダウングレード攻撃に対して脆弱になります-ブラウザでは回避し、HSTSリストを含めます）。

3.3非ASCII Unicode文字のホスト名への変換

• ブラウザは、ホスト名でaz
  
  
  
  、 AZ
  
  
  
  、 0-9
  
  
  
  、 -
  
  
  
  、または.
  
  
  
  。
• google.comドメイン名の場合、問題はありませんが、ドメインに非ASCII文字が含まれている場合、ブラウザはURLのこの部分にPunycodeエンコードを使用します。

4. DNSの定義

• ブラウザは、キャッシュ内のドメインの存在を確認します。
• ドメインが存在しない場合、ブラウザはライブラリ関数gethostbyname
  
  
  
  （異なるオペレーティングシステムによって異なります）を呼び出して、目的のアドレスを見つけます。
• DNSを使用してドメインを探す前に、 gethostbyname
  
  
  
  はhosts
  
  
  
  で目的のアドレスを見つけようとしhosts
  
  
  
  （その場所はオペレーティングシステムによって異なります）。
• ドメインがどこにもキャッシュされておらず、 hosts
  
  
  
  にない場合、 gethostbyname
  
  
  
  はネットワークDNSサーバーに要求を送信します。 通常、これはローカルルーターまたはインターネットプロバイダーのDNSサーバーです。
• DNSサーバーが同じサブネット上にある場合、 ARP要求がこのサーバーに送信されます。
• DNSサーバーが別のサブネット上にある場合、ARP要求はデフォルトゲートウェイのIPアドレスに送信されます。

4.1 ARP要求を送信するプロセス

ブロードキャストARP要求を送信するには、ターゲットIPアドレスと、ARP要求の送信に使用されるインターフェイスのMACアドレスを見つける必要があります。



各宛先IPアドレスのARPキャッシュがチェックされます-アドレスがキャッシュ内にある場合、ライブラリ関数は結果を返します： Target IP = MAC



。



キャッシュエントリがない場合：

• ルーティングテーブルがチェックされます-これは、ローカルテーブルのサブネットのいずれかに目的のIPアドレスがあるかどうかを確認するために行われます。 存在する場合、要求はこのサブネットに関連付けられたインターフェイスを使用して送信されます。 テーブルにアドレスが見つからない場合は、デフォルトゲートウェイサブネットインターフェイスが使用されます。
• 選択したネットワークインターフェイスのMACアドレスが決定されます。
• ARP要求が送信されます（2番目のスタックレベル）：

ARP要求：



Sender MAC: interface:mac:address:here





Sender IP: interface.ip.goes.here





Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)





Target IP: target.ip.goes.here







コンピューターとルーター（ルーター）の間にあるハードウェアの種類に応じて：



直接接続：

• コンピューターがルーターに直接接続されている場合、このデバイスはARP応答（ARP応答）を送信します。

それらの間ハブ（ハブ）：

• コンピューターがネットワークハブに接続されている場合、このハブはすべてのポートからブロードキャストARP要求を送信します。 ルータが同じ「ワイヤ」を介して接続されている場合、ARP応答を送信します。

それらの間にスイッチ（スイッチ）：

• コンピュータがネットワークスイッチに接続されている場合、このスイッチはローカルCAM / MACテーブルをチェックして、そのポートのどのポートに目的のMACアドレスがあるかを調べます。 目的のアドレスがテーブルにない場合、すべてのポートにブロードキャストARP要求を再度送信します。
• テーブルに目的のエントリがある場合、スイッチは目的のMACアドレスでポートにARP要求を送信します。
• ルーターがスイッチと「同じ回線上」にある場合、ルーターは応答します（ARP応答）。

ARP回答：



Sender MAC: target:mac:address:here





Sender IP: target.ip.goes.here





Target MAC: interface:mac:address:here





Target IP: interface.ip.goes.here







これで、ネットワークライブラリには、DNSサーバーまたはデフォルトゲートウェイのIPアドレスがあり、ドメイン名の解決に使用できます。

• ポート53が開き、UDP要求をDNSサーバーに送信します（応答サイズが大きすぎる場合は、TCPが使用されます）。
• ローカルまたはプロバイダー側​​のDNSサーバーが目的のアドレスを「知らない」場合、再帰検索が要求され、SOAレコードが見つかるまで上位レベルのDNSサーバーのリストを検索し、結果が返されます。

5.ソケットを開く

ブラウザーは、宛先サーバーのIPアドレスを受け取ると、URL（HTTPの場合は80、HTTPSの場合は443）から使用されたポートのこの情報とデータを取得し、システムライブラリのsocket



関数を呼び出し、TCPソケットストリームAF_INET



およびSOCK_STREAM



を要求します。

• この要求は、最初にTCPセグメントが向かうトランスポート層を通過します。 宛先ポートがヘッダーに追加され、ソースポートが動的カーネルプール（Linuxではip_local_port_range
  
  
  
  ）から選択されます。
• 結果のセグメントはネットワーク層に送信され、そこに追加のIPヘッダーが追加されます。 宛先サーバーのIPアドレスと現在のマシンのアドレスも含まれます-その後、パケットが生成されます。
• パケットはデータリンク層に送信されます。 コンピューターのネットワークインターフェイスカード（NIC）のMACアドレスと、ゲートウェイ（ローカルルーター）のMACアドレスを含むフレームヘッダーが追加されます。 前の手順と同様に、カーネルがゲートウェイのMACアドレスについて何も知らない場合、ブロードキャストARP要求が送信されてそれを見つけます。

この時点で、パケットは次を介して送信する準備ができています。

• イーサネット
• Wifi
• 携帯電話

インターネット接続の場合、ほとんどの個人ユーザーまたは中小企業は、コンピューターからローカルネットワークを介してパッケージを送信し、モデム（ MOdulator/DEModulator



）を介して、デジタルユニットとゼロを電話回線、ケーブル、またはワイヤレス電話接続。 接続の反対側には、アナログ信号をデジタルデータに変換し、それらを次のネットワークノードに渡す別のモデムがあります 。ここで、送信者と受信者に関するデータのさらなる分析が行われます。



最終的に、パケットはローカルサブネットを管理するルーターに到達します。 その後、宛先サーバーに到達するまで、あるルーターから別のルーターに移動し続けます。 途中の各ルーターは、IPヘッダーから宛先アドレスを抽出し、パケットを次のホップに送信します。 IPヘッダーのTTL（有効期間）フィールドの値は、各ルーターを通過するたびに減少します。 TTLフィールドの値がゼロに達すると、パケットはドロップされます（これは、ルーターが現在のキューにスペースを持たない場合にも発生します-たとえば、ネットワークの輻輳が原因です）。



TCP接続中に、多くの同様の要求と応答が発生します。

5.1 TCP接続のライフサイクル

a。 クライアントは、初期シーケンス番号（ISN）を選択し、SYNビットが設定されたパケットをサーバーに送信して接続を開きます。



b。 サーバーはSYNビットを含むパケットを受信し、接続を確立する準備ができている場合は、次のことを行います。

• 独自の開始シーケンス番号を選択します。
• SYNビットを設定して、初期シーケンスの選択を示します。
• ACKフィールドにクライアントのISN +1をコピーし、ACKフラグを追加して、最初のパケットの受信の確認を示します。

c。 クライアントはパケットを送信して接続を確認します。

• 初期シーケンスの数を増やします。
• 受領確認番号を増やします。
• ACKフィールドを設定します。

d。 データは次のように送信されます。

• 一方がNバイトを送信すると、この数だけSEQフィールドの値が増加します。
• 相手側がこのパケット（またはパケットのチェーン）の受信を確認すると、ACKフィールド値が最後に受信したシーケンスに等しいACKパケットを送信します。

e。 接続の閉鎖：

• 接続を閉じたいパーティは、FINパケットを送信します。
• 反対側は（ACKを使用して）FINを確認し、独自のFINパケットを送信します。
• 接続ターミネーターは、独自のACKを送信してFINの受信を確認します。

6. TLSハンドシェイク

• クライアントコンピューターは、 TLSプロトコルのバージョン、サポートされている暗号化アルゴリズムとデータ圧縮方法のリストと共に、 ClientHello
  
  
  
  メッセージClientHello
  
  
  
  サーバーに送信します。
• サーバーは、TLSバージョン、選択した暗号化方式、選択した圧縮方式、および認証局によって署名されたパブリックサービス証明書を含むServerHello
  
  
  
  メッセージでクライアントに応答します。 証明書には、対称キーが合意されるまで、クライアントがハンドシェイク手順の残りを暗号化するために使用する公開キーが含まれています。
• クライアントは、認証局のリストを使用してサーバー証明書を検証します。 証明書がリストからセンターによって署名されている場合、サーバーは信頼され、クライアントは擬似ランダムバイトの文字列を生成し、サーバーの公開キーを使用して暗号化します。 これらのランダムバイトを使用して、対称キーを決定できます。
• サーバーは、プライベートキーを使用してランダムバイトを復号化し、これらのバイトを使用して対称マスターキーのコピーを生成します。
• クライアントは、 Finished
  
  
  
  メッセージをサーバーに送信し、対称キーで転送ハッシュを暗号化します。
• サーバーは独自のハッシュを生成し、クライアントから受信したハッシュを解読して、それが自身のハッシュと一致するかどうかを確認します。 一致が見つかった場合、サーバーはクライアントにも独自のFinished
  
  
  
  応答を送信し、これも対称キーで暗号化されます。
• その後、TLSセッションは、確認済みの対称キーを使用して暗号化されたアプリケーションデータ（HTTP）を送信します。

7. HTTPプロトコル

使用するブラウザがGoogleによって作成された場合、ページを受信するためにHTTPリクエストを送信する代わりに、HTTPからSPDY （「速度」）にプロトコルを「アップグレード」するためにサーバーと「ネゴシエート」する要求を送信します。



クライアントがHTTPプロトコルを使用し、SPDYをサポートしていない場合、次の形式でサーバーにリクエストを送信します。



GET / HTTP/1.1





Host: google.com





Connection: close





[ ]







ここで、 [ ]



は一連のキーです。値のペアは改行で分割されます。 （ここでは、使用されているブラウザにHTTP仕様に違反するエラーがないことを前提としています。ブラウザがHTTP/1.1



使用していると想定されます。そうでない場合、リクエストにHost



ヘッダーが含まれず、GETリクエストに応答して返されるバージョンがHTTP/1.0



またはHTTP/0.9



）。



HTTP/1.1



は、送信者の接続を閉じる（「閉じる」）オプションを定義します-その助けを借りて、応答が完了した後に接続が閉じられるという通知が行われます。 例：

接続：閉じる

永続的な接続をサポートしないHTTP/1.1



アプリケーションでは、すべてのメッセージに閉じるオプションを含める必要があります。



リクエストとヘッダーを送信した後、ブラウザは単一の空の行をサーバーに送信し、メッセージが終了したことを通知します。



サーバーは、要求のステータスを示す特別なコードで応答し、次の形式の応答が含まれます。



200 OK





[ ]







その後、空の行が送信され、HTMLページwww.google.comの残りのコンテンツが送信されます。 サーバーは接続を閉じることができます。または、クライアントから送信されたヘッダーで必要な場合は、接続を開いたままにして、次の要求で使用できるようにします。



Webブラウザーから送信されたHTTPヘッダーに、サーバーがブラウザーにキャッシュされているファイルのバージョンを判断するのに十分な情報が含まれ、このファイルが最後の要求以降変更されていない場合、応答は次の形式を取ります：



304 Not Modified





[ ]







それに応じて、コンテンツはクライアントに送信されず、代わりにブラウザがキャッシュからHTMLを「プル」します。



HTMLを解析した後、ブラウザー（およびサーバー）は、HTMLページが参照する各リソース（画像、スタイル、スクリプト、favicon.icoなど）に対してダウンロードプロセスを繰り返しますが、各リクエストのアドレスはGET / HTTP/1.1



変更されGET / HTTP/1.1



に GET /$( URL www.google.com) HTTP/1.1



GET /$( URL www.google.com) HTTP/1.1







HTMLがgoogle.com以外のドメインでホストされているリソースを参照している場合、ブラウザはドメイン名の解決を含む手順に戻り、プロセスを現在の状態に再実行しますが、別のドメインに対して実行します。 リクエスト内のgoogle.comの代わりにHost



ヘッダーが目的のドメイン名に設定されます。

7.1サーバーでのHTTPリクエストの処理

HTTPD



（HTTPデーモン）は、サーバー側の要求/応答処理ツールの1つです。 最も一般的なHTTPDサーバーは、Linuxの場合はApacheまたはNginx、Windowsの場合はIISです。



-HTTPD（HTTPデーモン）は要求を受け取ります。



-サーバーは、次のパラメーターに従って要求を解析します。

• HTTPリクエストメソッド（ GET
  
  
  
  、 POST
  
  
  
  、 HEAD
  
  
  
  、 PUT
  
  
  
  またはDELETE
  
  
  
  ）。 ユーザーがブラウザーの行に入力したURLの場合、GET要求を処理しています。
• ドメイン この場合、google.com。
• 要求されたパス/ページ、この場合- /
  
  
  
  （要求されたパスなし、 /
  
  
  
  -これはデフォルトのパスです）。

-サーバーは、google.comに一致する仮想ホストの存在を確認します。



-サーバーは、google.comがGETリクエストを受け入れることができることを確認します。



-サーバーは、クライアントにこの方法を使用する権利があるかどうかを確認します（IPアドレス、認証などに基づいて）。



-書き換えモジュールがサーバーにインストールされている場合（Apacheの場合はmod_rewrite



、IISの場合はURL Rewrite



）、構成されたルールの1つと要求を照合します。 一致するルールが見つかった場合、サーバーはそれを使用してリクエストを書き換えます。



-サーバーはリクエストに一致するコンテンツを見つけます。この場合、インデックスファイルを調べます。



-次に、サーバーはハンドラーを使用してファイルを解析（「解析」）します。 GoogleがPHPを実行している場合、サーバーはPHPを使用してインデックスファイルを解釈し、結果をクライアントに送信します。

8.ブラウザの舞台裏

ブラウザのタスクは、選択したWebリソースをユーザーに表示し、サーバーからそれらをリクエストして、表示ウィンドウに表示することです。 通常、このようなリソースはHTMLドキュメントですが、PDF、画像、またはその他の種類のコンテンツでもかまいません。 リソースの場所は、URLを使用して決定されます。



ブラウザがHTMLファイルを解釈および表示するために使用する方法は、HTMLおよびCSS仕様に記載されています。 これらのドキュメントは、Web標準化コンソーシアムであるW3C（World Wide Wib Consortium）によって開発およびサポートされています。



ブラウザインターフェイスは互いに非常に似ています。 多数の同一の要素があります。

• URLが挿入されるアドレスバー。
• 前のページと次のページに戻るためのボタン。
• ブックマークを作成する機能。
• ページの更新（更新）および現在のドキュメントの読み込みを停止するボタン。
• ユーザーをホームページに戻すホームボタン。

高レベルのブラウザ構造

ブラウザには次のコンポーネントが含まれています。

• ユーザーインターフェイス ：アドレスバー、前後のボタン、ブックマークのメニューなどが含まれます。 これには、Webページが実際に表示されるウィンドウを除くすべての要素が含まれます。
• ブラウザエンジン ：レンダリングエンジンとユーザーインターフェイスの間でアクションを分散します。
• 「エンジン」レンダリング ：要求されたコンテンツの表示を担当します。 , HTML, «» HTML CSS, .
• : , HTTP-, .
• (UI) : , - .
• JavaScript : JavaScript-.
• : (, cookie). , , localStorage
  
  
  
  , IndexedDB
  
  
  
  , WebSQL



FileSystem
  
  
  
  .

9. HTML

. , 8. HTML- .



(«parse tree») — DOM- . DOM — Document Object Model



. HTML- HTML- « » (, JavaScript-). «».

HTML- «» ( ). :

• ;
• , HTML.
• . , , , HTML (, , document.write()
  
  
  
  ) , .

, HTML. HTML5 .



: .

, (, , ).



, , «» : , . « complete



» (« load



»).



: «Invalid Syntax»



, «» .

10. CSS

• CSS-, <style>
  
  
  
  «style» c « CSS ».
• CSS- StyleSheet
  
  
  
  , CSS CSS.
• CSS , .

11.

• DOM- CSS- « » (Render Tree Frame Tree).
• — , , .
• - ( ).
• - — , , .
• ( ).
• , . .
• , . ( ) .
• .
• (/) . (GPU) D2D/SkiaGL.
• , , .
• -, ( , iframe-, addon-).
• Direct3D/OpenGL . GPU .

12. GPU

• (GPU).
• , GPU , .

13. -

, JavaScript- ( Google) ( ). Flash Java ( Google). , , .