2018 年 11 月 17 日

面试-http

先进行了一个简单的自我介绍，主要介绍了一下自己的工作经历和一些技术栈

1. 解释一下浏览器解析 HTTP 的过程

上来就放大招，这个题可深可浅，我整理了一下答案

一次完整的 HTTP 请求过程

当我们在 web 浏览器的地址栏中输入： www.baidu.com，然后回车，到底发生了什么

过程概览

1.对 www.baidu.com 这个网址进行 DNS 域名解析，得到对应的 IP 地址

2.根据这个 IP，找到对应的服务器，发起 TCP 的三次握手

3.建立 TCP 连接后发起 HTTP 请求

4.服务器响应 HTTP 请求，浏览器得到 html 代码

5.浏览器解析 html 代码，并请求 html 代码中的资源（如 js、css 图片等）（先得到 html 代码，才能去找这些资源）

6.浏览器对页面进行渲染呈现给用户

注：

DNS 域名解析采用的是递归查询的方式，过程是，先去找 DNS 缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的 web 浏览器
为什么 HTTP 协议要基于 TCP 来实现？ TCP 是一个端到端的可靠的面相连接的协议，HTTP 基于传输层 TCP 协议不用担心数据传输的各种问题（当发生错误时，会重传）
最后一步浏览器是如何对页面进行渲染的？

a: 解析 html 文件构成 DOM 树，

b: 解析 CSS 文件构成渲染树，

c: 边解析，边渲染，

d: JS 单线程运行，JS 有可能修改 DOM 结构，意味着 JS 执行完成前，后续所有资源的下载是没有必要的，所以 JS 是单线程，会阻塞后续资源下载

下面我们来详细看看这几个过程的具体细节：

　　 1.域名解析

a）首先会搜索浏览器自身的 DNS 缓存（缓存时间比较短，大概只有 1 分钟，且只能容纳 1000 条缓存）

b）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的 DNS 缓存

c）如果还没有找到，那么尝试从 hosts 文件里面去找

d）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，具体过程如下

域名解析

2.TCP 连接（三次握手）

拿到域名对应的 IP 地址之后，User-Agent（一般指浏览器）会以一个随机端口（1024<端口<65535）向服务器的 WEB 程序（常用的有 httpd，nginx）等的 80 端口。这个连接请求（原始的 http 请求经过 TCP/IP4 层模型的层层封包）到达服务器端后（这中间有各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的 TCP/IP 协议栈（用于识别连接请求，解封包，一层一层的剥开），还有可能要经过 Netfilter 防火墙（属于内核的模块）的过滤，最终达到 WEB 程序，最终建立了 TCP/IP 的连接

tcpip

3.建立 TCP 连接之后，发起 HTTP 请求

HTTP 请求报文由三部分组成：请求行，请求头和请求正文

请求行：用于描述客户端的请求方式，请求的资源名称以及使用的 HTTP 协议的版本号（例：GET/books/java.html HTTP/1.1）

请求头：用于描述客户端请求哪台主机，以及客户端的一些环境信息等

注：这里提一个请求头 Connection，Connection 设置为 keep-alive用于说明客户端这边设置的是，本次 HTTP 请求之后并不需要关闭 TCP 连接，这样可以使下次 HTTP 请求使用相同的 TCP 通道，节省 TCP 建立连接的时间

请求正文：当使用 POST, PUT 等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中（GET 方式是保存在 url 地址后面，不会放到这里）

　　 4.服务器端响应 http 请求，浏览器得到 html 代码

HTTP 响应也由三部分组成：状态码，响应头和实体内容

状态码：状态码用于表示服务器对请求的处理结果

列举几种常见的：200（没有问题） 302（要你去找别人） 304（要你去拿缓存） 307（要你去拿缓存） 403（有这个资源，但是没有访问权限） 404（服务器没有这个资源） 500（服务器这边有问题）

若干响应头：响应头用于描述服务器的基本信息，以及客户端如何处理数据

实体内容：服务器返回给客户端的数据

注：html 资源文件应该不是通过 HTTP 响应直接返回去的，应该是通过 nginx 通过 io 操作去拿到的吧

　　 5.浏览器解析 html 代码，并请求 html 代码中的资源

浏览器拿到 html 文件后，就开始解析其中的 html 代码，遇到 js/css/image 等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这是时候就用上 keep-alive 特性了，建立一次 HTTP 连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序。

　　 6.浏览器对页面进行渲染呈现给用户

最后，浏览器利用自己内部的工作机制，把请求的静态资源和 html 代码进行渲染，渲染之后呈现给用户

浏览器是一个边解析边渲染的过程。首先浏览器解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和 repain(重绘)。DOM 节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为 relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为 repain。页面在首次加载时必然会经历 reflow 和 repain。reflow 和 repain 过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少 reflow 和 repain。

JS 的解析是由浏览器中的 JS 解析引擎完成的。JS 是单线程运行，JS 有可能修改 DOM 结构，意味着 JS 执行完成前，后续所有资源的下载是没有必要的，所以 JS 是单线程，会阻塞后续资源下载

　　自此一次完整的 HTTP 事务宣告完成.

总结：

域名解析 —> 发起 TCP 的 3 次握手 —> 建立 TCP 连接后发起 http 请求 —> 服务器响应 http 请求，浏览器得到 html 代码 —> 浏览器解析 html 代码，并请求 html 代码中的资源（如 js、css、图片等） —> 浏览器对页面进行渲染呈现给用户

ps：反正我是凉了一下子没想起来底层的东西，答非所问

2. 页面在进行加载的过程中，做了那些事，link 标签和 scrript 标签在加载的时候是同步的还是异步的

当一个浏览器接收到从服务器发来的 html 页面，在渲染并呈现到屏幕上之前，有很多步骤要做。浏览器渲染页面需要做的一系列行为被称作“关键渲染路径（Critical Rendering Path 简称 CRP）”。

CRP 的知识对于如何提升网站性能是相当有用的。CRP有 6 个步骤：

构建 DOM 树
构建 CSSOM 树
运行 JavaScript
创建渲染树
生成布局
绘制页面

CRP的6个步骤

具体步骤请移驾 https://www.jianshu.com/p/e53141edca6d

2. 1 追问那 script 标签怎样才能实现异步呢？

敲黑板重点：

1、把<script>标签放在<head>中意味着必须等到全部的 js 代码都下载解析和执行完成以后，才开始展现页面内容，为避免这个问题一般把 js 代码全部放在<body>元素内容后面

2、script标签不带 defer 和 async 属性：同步模式，脚本获取和执行都是同步，页面会被阻塞，浏览器都会按照<script>元素在页面中出现的先后顺序对他们依次进行解析

同步模式：又称阻塞模式，会阻止浏览器的后续执行，停止后续解析，只有当前加载完成才能进行下一步操作。

3、async 属性：html5 的新属性，只适合用于外部脚本文件，异步模式

通过 createElement 创建的 script 标签其属性 async 默认为 true

4、defer 属性：异步模式，只适合外部脚本文件，会被延迟到整个页面都解析完毕后再运行，脚本加载不阻塞页面的解析，同时带有 defer 的脚本彼此之间，能保证其执行顺序

补充：

<script>标签打开 defer 或 async 属性，脚本就会异步加载。渲染引擎遇到这一行命令，就会开始下载外部脚本，但不会等它下载和执行，而是直接执行后面的命令。

defer与async的区别是：defer要等到整个页面在内存中正常渲染结束（DOM 结构完全生成，以及其他脚本执行完成），才会执行；async一旦下载完，渲染引擎就会中断渲染，执行这个脚本以后，再继续渲染。一句话，defer是“渲染完再执行”，async是“下载完就执行”。另外，如果有多个defer脚本，会按照它们在页面出现的顺序加载，而多个async脚本是不能保证加载顺序的。

3. 解释一下 webpack 的执行机制，和运行原理

Entry: 入口, webpack 执行构建的第一步将从 Entry 开始，可抽象成输入
Module: 模块，在 webpcak 中一切皆模块，一个模块对应一个文件。webpack 会从配置的 Entry 开始递归找出所有依赖的模块。
Chunk: 代码块，一个 Chunk 由多个模块组合而成，用于代码合并于分割
Loader: 模块转换器，用于将模块的原内容按照需求转换成新内容。
Plugin: 扩展插件，在 webpcak 构建流程中的特定时机注入扩展逻辑，来改变构建结果或做我们想要的事情
Outout: 输出结果，再 webpack 经过一些列处理并得出最终想要的代码后输出结果

webpcak 在启动后会从 Entry 里配置的 Module 开始，递归解析 Entry 依赖的所有 Module.每找到一个 Module,就会根据配置的 Loader 去找出对应的转换规则，对 Module 进行转换后，再解析出当前 Module 依赖的 Module。这些模块会以 Entry 为单位进行分组，一个 Entry 及其所有依赖的 Module 被分到一个组也就是一个 Chunk.最后，webpack 会将所有 Chunk 转换成文件输出。在整个流程中，webpack 会在恰当的时机执行 Plugin 里定义的逻辑。

细则：移驾 webpack 官网： https://webpack.docschina.org/

4. 本地储存 localStorage，sessionStorage，cookies，他们有什么区别？

详情： https://www.cnblogs.com/pengc/p/8714475.html

5. 自身的一个项目，分析一下为什么要用 a 库而不用 b 库，是居于什么样的？

讲一讲个人的一些看法，没什么特点就是聊聊，应该是摸摸你的底，经验什么的

6. 问了一下我学 Typescript 的初衷，和学到什么程度

讲了一下，我为何学 Typescript，和他的趋势，个人看法，这是一个知识帖就不做详细介绍了

Ruoduan' Blog

面试-http

1. 解释一下浏览器解析 HTTP 的过程

一次完整的 HTTP 请求过程

过程概览

下面我们来详细看看这几个过程的具体细节：

1.域名解析

2.TCP 连接（三次握手）

3.建立 TCP 连接之后，发起 HTTP 请求

4.服务器端响应 http 请求，浏览器得到 html 代码

5.浏览器解析 html 代码，并请求 html 代码中的资源

6.浏览器对页面进行渲染呈现给用户

自此一次完整的 HTTP 事务宣告完成.

总结：

2. 页面在进行加载的过程中，做了那些事，link 标签和 scrript 标签在加载的时候是同步的还是异步的

2. 1 追问那 script 标签怎样才能实现异步呢？

敲黑板 重点：

3. 解释一下 webpack 的执行机制，和运行原理

4. 本地储存 localStorage，sessionStorage，cookies，他们有什么区别？

5. 自身的一个项目，分析一下为什么要用 a 库而不用 b 库，是居于什么样的？

6. 问了一下我学 Typescript 的初衷，和学到什么程度

　　 1.域名解析

　　 4.服务器端响应 http 请求，浏览器得到 html 代码

　　 5.浏览器解析 html 代码，并请求 html 代码中的资源

　　 6.浏览器对页面进行渲染呈现给用户

　　自此一次完整的 HTTP 事务宣告完成.

敲黑板重点：