关于前端:要把URL变网页一共分几步

38次阅读

共计 10384 个字符，预计需要花费 26 分钟才能阅读完成。

前言

生存中少不了和浏览器打交道，它就像一个魔法盒子，输出一串网址，就能够失去各式各样的网页，供咱们满足少数日常需要，如：看看直播、买买货色、翻翻掘金、学学前端等等

那么，浏览器是如何工作的？

主题来了，要把 URL 变成网页，一共分几步？

普通人眼中：

  1. 关上浏览器
  2. 把 URL 输出到浏览器的地址栏
  3. 敲下回车，等着

咱们前端搬砖工程师眼中：

  1. 浏览器应用 HTTP  协定或者 HTTPS  协定，向服务端申请页面
  2. 解析申请回来的 HTML  代码，构建 DOM 树 
  3. 计算 DOM 树 上的 CSS  属性
  4. 最初依据 CSS  属性对元素一一进行渲染，失去内存中的 位图
  5. 一个可选的步骤是对位图进行合成，这会极大地减少后续绘制的速度
  6. 合成之后，再绘制到界面上

先看一张图，而后进入正题，搬砖的就是事儿多 …

须要留神的是，从 HTTP  申请回来开始，这个过程并非一步做完再做下一步，而是一条流水线，产生了流式的数据，后续的 DOM 树 构建、CSS  计算、渲染、合成、绘制，都是尽可能地流式解决前一步的产出： 即不须要等到上一步骤齐全完结，就开始解决上一步的输入，这样咱们在浏览网页时，才会看到逐渐呈现的页面

HTTP 协定

HTTP 构造

浏览器首先要做的事就是依据 URL  把数据取回来，取回数据应用的是 HTTP  协定，它的次要构造如下图所示

  • HTTP 是纯正的文本协定，它是规定了应用 TCP 协定来传输文本格式的一个应用层协定，TCP  协定是一条双向的通信通道，HTTP  在其根底上规定了 Request-Response  的模式，这个模式决定了通信必然是由浏览器端首先发动的
  • 大部分状况下，浏览器的实现者只须要用一个 TCP  库，甚至一个现成的 HTTP  库就能够搞定浏览器的网络通讯局部

HTTP 申请过程

应用 TCP 连贯工具 telnet 简略理解一下 HTTP 申请过程

输出命令连贯主机
telnet juejin.im 80

胜利建设 TCP 连贯：Trying 122.14.230.185...
Connected to bgp.xigua-lb-lf.l.bytedns.net.
Escape character is '^]'.

输出以下申请命令，并敲两次回车：GET / HTTP/1.1
Host: juejin.im 

收到服务端响应：HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 18 Sep 2020 05:06:21 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://juejin.im/
x-tt-trace-host: 015296b7920ed693b32e320199940562beabfbd0ff41bbcb80c8d2764bbe1d487104068a81badb0e3febb69b1ec55356f4
x-tt-trace-tag: id=00;cdn-cache=miss

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

  • 申请局部

    • 第一行 对应上图中 Request 分支下的 request line 

      • method 申请办法：GET 
      • path 申请门路：/ 
      • version 申请协定版本：HTTP/1.1 

    • 第二行到第一个空行之间的内容 对应 Request 分支下的 head 

      • 由名称及值组成：Host: juejin.im 

    • 空行上面内容 对应 request 分支下的 body

      • 蕴含申请参数、文件数据等
      • 下面申请命令没有应用参数，所以第二行下无内容

  • 响应局部

    • 第一行 对应上图中 Response 分支下的 response line

      • version 申请协定版本：HTTP/1.1
      • status code 状态码：301 
      • status text 状态文本：Moved Penmanently 

    • 第二行到第一个空行之间的内容 对应 response 分支下的 head 

      • 由名称及值组成的若干行组合

    • 空行上面内容 对应 response 分支下的 body

      • 纯文本 HTML 代码

HTTP Method

简略介绍一下申请办法的品种以及他们的应用场景：

  • GET

    • 通过浏览器地址栏拜访页面

  • POST

    • 通过表单提交数据

  • HEAD

    • 和 GET 相似，只返回响应头，不罕用

  • PUT

    • 语义上为增加资源，无强制束缚，不罕用

  • DELETE

    • 语义上为删除资源，无强制束缚，不罕用

  • CONNECT

    • 用于 HTTPS 和 WebSocket

  • OPTIONS

    • 多用于调试，不罕用，少数线上服务器都不反对

  • TRACE

    • 多用于调试，不罕用，少数线上服务器都不反对

HTTP Status

咱们 比拟罕用 的几种状态码，以及对应的状态文本大略有这么几种：

  • 1xx：长期回应，示意客户端请持续

  • 2xx：申请胜利

    • 200：申请胜利

  • 3xx: 示意申请的指标有变动，心愿客户端进一步解决

    • 301：永久性跳转
    • 302：临时性跳转
    • 304：跟客户端缓存没有更新

  • 4xx：客户端申请谬误

    • 400：参数谬误
    • 403：无权限
    • 404：示意申请的页面不存在
    • 418：It’s a teapot. 这是一个彩蛋，来自 ietf 的一个愚人节玩笑

  • 5xx：服务端申请谬误

    • 500：服务端谬误
    • 502：服务端收到有效响应
    • 503：服务端暂时性谬误，能够一会再试
    • 504：服务端未能及时收到响应

HTTP Head

  • Request Header

  • Response Header

HTTP Body

HTTP  申请的 body  次要用于提交表单场景，也就是 POST 申请，一些常见的格局：

  • application/json
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/xml

应用 HTML 的 form 标签提交申请，默认会产生 application/x-www-form-urlencoded  的数据格式；
有文件上传时，应用 multipart/form-data 

HTTPS

HTTPS  有两个作用：

  1. 确定申请的指标服务端身份，
  2. 保障传输的数据不会被网络两头节点窃听或者篡改

HTTPS  与服务端建设一条 TLS 加密通道（TLS 构建于 TCP 协定之上），对传输的内容做一次加密，从传输内容上与 HTTP 没有区别

HTTP2

HTTP 2  是 HTTP 1.1  的降级版本，2.0 最大的改良有两点：

  1. 反对服务端推送

    • 服务端推送可能在客户端发送第一个申请到服务端时，提前把一部分内容推送给客户端，放入缓存当中，这能够防止客户端申请程序带来的并行度不高，从而导致的性能问题

  2. 反对 TCP 连贯复用

    • 应用同一个 TCP 连贯来传输多个 HTTP 申请，防止了连贯建设时的三次握手开销，和初建连贯时传输窗口小的问题

解析代码

词（token）

先来剖析一段代码

<p class="a">text text text</p>

能够把这段代码顺次拆成词（token）：

  • <p“标签开始”的开始
  • class=“a”属性
  • >“标签开始”的完结
  • text text text 文本
  • </p> 标签完结

状态机

绝大多数语言的词法局部都是用状态机实现的，那么咱们来把局部词（token）的解析画成一个状态机看看

这里的粗略剖析次要为了了解原理，真正残缺的 HTML 词法状态机，比咱们形容的要简单的多；更具体的内容能够参考 HTML 官网文档，文档中规定了 80 个状态（HTML  是惟一一个规范中规定了状态机实现的语言，对大部分语言来说，状态机是一种实现而非定义）

此状态机的初始状态，仅辨别 < 和 非 <：

  • 如果取得一个非 <，则进入了一个文本节点
  • 如果取得一个 <，则进入一个标签状态

标签中存在多种可能性

  • 下一个字符是 !，可能是进入了 正文节点 或者 CDATA 
  • 下一个字符是 /，能够确定进入了一个完结标签
  • 下一个字符是字母，能够确定进入了一个开始标签
  • 要残缺解决各种 HTML 规范中定义的货色，那么还要思考 ? % 等内容

用状态机做词法剖析，其实正是把每个词的 特色字符 一一拆开成 独立状态 ，而后再把所有词的特色字符链合并起来，造成一个 联通图构造

接下来就是代码实现的事件了，咱们把每个函数当做一个状态，参数是承受的字符，返回值是下一个状态函数

function data(c) {switch (c) {
    case '&':
      return characterReferenceInData;

    case '<':
      return tagOpen;

    case '\0':
      error();
      emitToken(c);
      return data;

    case EOF:
      emitToken(EOF);
      return data;

    default:
      emitToken(c);
      return data;
  }
}

function tagOpen(c) {if (c === '/') {return endTagOpen;}
  if (/[a-zA-Z]/.test(c)) {token = new StartTagToken();
    token.name = c.toLowerCase();
    return tagName;
  } else {error(c);
    return data;
  }
}

function tagName(c) {//……}

function characterReferenceInData(c) {//……}

function endTagOpen(c) {//……}

//……

这段代码给出了状态机的两个状态示例：

  • data  为初始状态，
  • tagOpenState  是承受了一个 <  字符，来判断标签类型的状态

这里的状态机，每一个 状态 是一个 函数 ，通过 if else 来辨别下一个字符做 状态迁徙 ，这里所谓的状态迁徙，就是 以后状态函数返回下一个状态函数

状态迁徙：

let state = data;
let char
while(char = getInput())
    state = state(char);

这段代码的要害一句是 state = state(char)，不管咱们用何种形式来读取字符串流，咱们都能够通过 state  来解决输出的字符流，这里用循环是一个示例，实在场景中，可能是来自 TCP 的输入流

状态函数通过代码中的 emitToken  函数来输入解析好的 token（词），咱们只须要笼罩 emitToken，即可指定对解析后果的解决形式：

function HTMLLexicalParser(){
        let state = data;
  
    // 状态函数们……
    function data() {// ……}

    function tagOpen() {// ……}
    // ……
    
    this.receiveInput = function(char) {state = state(char);
    }
}

构建 DOM

把词变成 DOM  树

function HTMLSyntaticalParser(){var stack = [new HTMLDocument];
    this.receiveInput = function(token) {//……};
    this.getOutput = () => stack[0];
}
  • receiveInput  负责接管词法局部产生的 词（token），由 emitToken 来调用
  • 接管同时，开始构建 DOM 树，在 receiveInput 中进行解决
  • 接管完所有输出，stack[0] 就是最初的根节点
  • 简略实现 Node  分为 Element  和 Text 
class Node {}

class Element extends Node {constructor (token) {super(token)
    for (const key in token) {this[key] = token[key]
    }
    this.childNodes = []}
  [Symbol.toStringTag] () {return `Element<${this.name}>`
  }
}

class Text extends Node {constructor (value) {super(value)
    this.value = value || ''
  }
}

后面咱们的 词（token） 中，以下两个是须要成对匹配的：

  • tag start 
  • tag end 
<html maaa=a >
    <head>
        <title>cool</title>
    </head>
    <body>
        <img src="a" />
    </body>
</html>

构建 DOM 树 规定：

  • 以后节点是栈顶元素
  • 遇到属性，增加到以后节点
  • 遇到文本节点，如果以后节点是文本节点则合并，否则入栈成为以后节点的子节点
  • 遇到正文节点，作为以后节点的子节点
  • 遇到 tag start  就入栈一个节点，以后节点就是这个节点的父节点
  • 遇到 tag end  就出栈一个节点（还能够查看是否匹配）

后果展现

残缺代码传送门

输入 词（token） 局部：

StartTagToken {name: 'html', maaa: 'a'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
StartTagToken {name: 'head'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
StartTagToken {name: 'title'}
String(c)
String(o)
String(o)
String(l)
EndTagToken {name: 'title'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
EndTagToken {name: 'head'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
StartTagToken {name: 'body'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
StartTagToken {name: 'img', src: 'a'}
EndTagToken {name: 'img'}
String(\n)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
String(<whitespace>)
EndTagToken {name: 'body'}
String(\n)
EndTagToken {name: 'html'}

输入 DOM 树 构造：

{
  "isDocument": true,
  "childNodes": [
    {
      "name": "html",
      "maaa": "a",
      "childNodes": [
        {"value": "\n"},
        {
          "name": "head",
          "childNodes": [
            {"value": "\n"},
            {
              "name": "title",
              "childNodes": [
                {"value": "cool"}
              ]
            },
            {"value": "\n"}
          ]
        },
        {"value": "\n"},
        {
          "name": "body",
          "childNodes": [
            {"value": "\n"},
            {
              "name": "img",
              "src": "a",
              "childNodes": []},
            {"value": "\n"}
          ]
        },
        {"value": "\n"}
      ]
    }
  ]
}

 

CSS 计算

构建 DOM  的过程是：从父到子，从先到后，一个一个节点结构，并且挂载到 DOM  树上的，在这个过程中顺次拿到上一步结构好的元素，去查看它 匹配到了哪些规定 ，再依据规定的优先级，做笼罩和调整，CSS  选择器 能够看成是 匹配器：

  • 空格 : 后辈，选中它的子节点和所有子节点的后辈节点
  • > : 子代，选中它的子节点
  • +：间接后继选择器，选中它的下一个相邻节点
  • ~：后继，选中它之后所有的相邻节点
  • ||：列，选中表格中的一列

选择器的呈现程序，必然跟构建 DOM  树的程序统一，这是一个 CSS  设计的准则，即保障选择器在 DOM  树构建到以后节点时，曾经能够精确判断是否匹配，不须要后续节点信息

排版

失常流文字排版

失常流是惟一一个文字和盒混排的排版形式，要想了解失常流，咱们首先要回顾一下本人如何在纸上写文章：

  • 首先，纸有固定宽度和固定高度，然而能够通过下一页纸的形式来接续，因而不存在写不下的场景
  • 书写文字时，从左到右顺次书写，每一个字跟上一个字都不重叠，文字之间有肯定间距，当写满一行时，换到下一行
  • 书写中文时，文字的上、下、中轴线都对齐
  • 书写英文时，不同字母的高度不同，然而有一条基线对齐

实际上浏览器环境也很相似，然而因为 浏览器反对扭转排版方向 ，不肯定是从左到右从上到下，所以咱们把文字顺次书写的延长方向称为 主轴 或者 主方向 ，换行延长的方向，跟主轴垂直穿插，称为 穿插轴 或者 穿插方向

咱们个别会从某个字体文件中获取某个特定文字的相干信息，咱们获取到的信息大略相似上面：

纵向版本：

advance  代表 每一个文字排布后在主轴上的后退间隔，它跟文字的宽 / 高不相等，是字体中最重要的属性

除了字体提供的字形自身蕴含的信息，文字排版还受到一些 CSS  属性影响，如 line-height、letter-spacing、word-spacing 

在失常流的文字排版中，少数元素被当作长方形盒来排版

而只有 display  为 inline  的元素，是 被拆成文原本排版 的，此类元素中的文字排版时会被间接排入文字流中，inline  元素主轴方向的 margin  属性和 border  属性也会被计算进排版后退间隔当中（例如主轴为横向时的 margin-left 和 margin-right）

留神，当没有强制指定文字书写方向时，在左到右文字中插入右到左向文字，会造成一个双向文字盒，反之亦然；这样，即便没有元素包裹，混合书写方向的文字也能够造成一个盒构造，咱们在排版时，遇到这样的双向文字盒，会先排完盒内再排盒外

失常流中的盒

在失常流中，display  不为 inline  的元素或者伪元素，会以盒的模式跟文字一起排版。

少数 display  属性都能够分成两局部：

  • 外部的排版

  • 是否 inline 

    • 带有 inline-  前缀的盒，被称作行内级盒

依据盒模型，一个盒具备 margin、border、padding、width/height  等属性，它在主轴方向占据的空间是由对应方向的这几个属性之和决定的，而 vertical-align  属性决定了盒在穿插轴方向的地位，同时也会影响理论行高

所以，浏览器对行的排版，个别是后行内布局，再确定行的地位，依据行的地位计算出行内盒和文字的排版地位

块级盒比较简单，它总是独自占据一整行，计算出穿插轴方向的高度即可

相对定位元素

position  属性为 absolute  的元素，咱们须要依据它的蕴含块来确定地位，这是齐全跟失常流无关的一种独立排版模式，逐层找到其父级的 position  非 static  元素即可

浮动元素排版

浏览器对 float  的解决是先排入失常流，再挪动到排版宽度的最左 / 最右（这里实际上是主轴的最前和最初）

挪动之后，float 元素占据了一块排版的空间，因而，在数行之内，主轴方向的排版间隔产生了变动，直到穿插轴方向的尺寸超过了浮动元素的穿插轴尺寸范畴，主轴排版尺寸才会复原

float  元素排布实现后，此元素所在的行须要从新确定地位

其余排版

如 Flex  排版，反对了 flex  属性，此属性将每一行排版后的残余空间平均分配给主轴方向的 width/height  属性

渲染

浏览器中渲染这个过程，就是把每一个 元素 对应的盒变成 位图：

  • 元素包含 HTML  元素和伪元素，一个元素可能对应多个 盒（比方 inline 元素，可能会分成多行）
  • 每一个 盒对应着 一张位图
  • 位图 就是在内存里建设一张 二维表格，把一张图片的每个像素对应的色彩保留进去

位图信息也是 DOM  树中占据浏览器内存最多的信息，咱们在做内存占用优化时，次要就是思考这一部分

渲染过程能够分成两个大类：

  • 图形

    • 盒的 背景 、 边框 、SVG 元素、 暗影 等个性，都是须要绘制的图形类，须要一个底层库来反对
    • 个别的操作系统会提供一个底层库，比方在 Android  的 Skia，Windows  的 GDI，个别的浏览器会做一个兼容层来解决掉平台差别

  • 文字

    • 盒中的文字，也须要用底层库来反对，叫做字体库
    • 字体库提供读取字体文件的根本能力，它能依据字符的码点抽取出字形，字形分为像素字形和矢量字形两种
    • 通常的字体，会在 6px  8px  等小尺寸提供像素字形，比拟大的尺寸则提供矢量字形
    • 矢量字形自身就须要通过渲染能力持续渲染到元素的位图下来
    • 目前最罕用的字体库是 Freetype，这是一个 C++  编写的开源的字体库

渲染过程中，不会把子元素绘制到渲染的位图上，因而当父子元素的绝对地位发生变化时，能够保障渲染的后果可能最大水平被缓存，缩小从新渲染

合成

渲染过程不会把子元素渲染到位图下面，而合成的过程，就是为一些元素创立一个“合成后的位图”（合成层），把一部分子元素渲染到合成的位图下面

如果把所有元素都进行合成，比方为根元素 HTML 创立一个合成后的位图，把所有子元素都进行合成，一旦扭转了任何一个 CSS  属性，这份合成后的位图就生效了，须要从新绘制所有的元素

如果所有的元素都不合成，相当于每次都必须要从新绘制所有的元素

合成是一个性能考量，那么合成的指标就是进步性能，依据这个指标，咱们建设的准则就是最大限度缩小绘制次数准则

<div id="a">
    <div id="b">...</div>
    <div id="c" style="transform:translate(0,0)"></div>
</div>

假如合成策略可能把 a、b  两个 div  合成，而不把 c  合成，当执行以下代码时，就能够只绘制 a  和 b  合成好的位图和 c，从而缩小了绘制次数

document.getElementById("c").style.transform = "translate(100px, 0)";

在理论场景中，咱们的 b 可能有很多简单的子元素，所以当合成命中时，性能晋升收益十分之高

目前，支流浏览器个别依据 position、transform  等属性来决定合成策略，来“猜想”这些元素将来可能发生变化，这样的猜想准确性无限，所以新的 CSS 规范中，规定了 will-change  属性，能够由业务代码来提醒浏览器的合成策略，灵活运用这样的个性，大大晋升合成策略的成果

绘制

绘制是把 位图最终绘制到屏幕上，变成肉眼可见的图像 的过程

一般来说，浏览器并不需要用代码来解决这个过程，浏览器只须要把最终要显示的位图交给操作系统即可

个别最终位图位于显存中，也有一些状况下，浏览器只须要把内存中的一张位图提交给操作系统或者驱动就能够了，这取决于浏览器运行的环境

咱们把任何位图合成到这个“最终位图”的操作称为绘制

这个过程听下来非常简单，因为在渲染局部曾经失去了每个元素的位图，并且对它们局部进行了合成，那么绘制过程，实际上就是依照 z-index 把它们顺次绘制到屏幕上，然而如果在理论中这样做，会带来极其蹩脚的性能
**
实际上，“绘制”产生的频率比咱们设想中要高得多。

咱们思考一个状况：鼠标划过浏览器显示区域，这个过程中，鼠标的每次挪动，都造成了从新绘制，如果咱们不从新绘制，就会产生大量的鼠标残影，这个时候，限度绘制的面积就很重要了。如果鼠标某次地位凑巧遮蔽了某个较小的元素，咱们齐全能够从新绘制这个元素来实现咱们的指标，当然，简略想想就晓得，这种事件不可能总是产生的

计算机图形学中，咱们应用的计划就是“脏矩形”算法，也就是把屏幕平均地分成若干矩形区域

  • 当鼠标挪动、元素挪动或者其它导致须要重绘的场景产生时，咱们只从新绘制它所影响到的几个矩形区域就够了
  • 比矩形区域更小的影响最多只会波及 4 个矩形，大型元素则笼罩多个矩形
  • 设置适合的矩形区域大小，能够很好地管制绘制时的耗费。设置过大的矩形会造成绘制面积增大，而设置过小的矩形则会造成计算简单
  • 咱们从新绘制脏矩形区域时，把所有与矩形区域有交加的合成层（位图）的交加局部绘制即可

总结

回看前言中咱们前端搬砖工程师眼中的浏览器工作原理，能够将整个过程划分为几大块常识内容，加以补充学习

  • HTTP  协定扩大学习 DNS  TCP  HTTP2 HTTPS 
  • 代码解析及构建 DOM 扩大学习 编译原理
  • 参照上一步内容，能够更好的了解 流式解决 及 CSS 的计算形式
  • 浏览器排版规定
  • 渲染、合成、绘制等 位图操作常识 扩大到 计算机图形学 相干常识

参考资料

  • 重学前端：浏览器实现原理与 API
  • Hypertext Transfer Protocol — HTTP/1.1
  • Hypertext Transfer Protocol (HTTP/1.1): Caching
  • Hypertext Transfer Protocol Version 2 (HTTP/2)
  • HTTP Over TLS — HTTPS
  • 彩蛋：超文本咖啡壶控制协议

正文完
前端
发表至： 前端
2020-09-19
 0
关于前端:SAP-UI5-Tooling-在-i18nproperties-文件里维护中文字符后变成乱码该如何解决
关于前端:极客大学前端实战训练营第0期对标阿里P6敝裘犹带帝京尘
关于前端:百度APP-Android包体积优化实践四Dex注解优化
关于前端:测试Sprint-Boot