目录

• HTTP，HTML，浏览器
  • 介绍一下 HTTP 和 HTTPS
    • HTTP 和 HTTPS 的基本概念2
    • HTTP 和 HTTPS的区别
    • HTTPS 协议的工作原理
    • HTTPS 协议的优缺点
  • TCP
    • 三次握手
    • 四次挥手
    • TCP 和 UDP 的区别
  • HTTP 发展史
  • BOM 对象
  • iframe
  • Doctype
  • Cookie、sessionStorage、localStorage 联系和区别
  • Cookie 如何防范 XSS 攻击
  • 浏览器事件
  • http 状态码
  • http 响应头
  • get 和 post 请求的区别
  • 浏览器缓存
  • 从用户输入 url 到页面展示发生了什么

---------

HTTP，HTML，浏览器

介绍一下 HTTP 和 HTTPS

HTTPS 的 SSL 加密实在传输层实现的

HTTP 和 HTTPS 的基本概念2

HTTP：超文本传输协议，是互联网上应用最广泛的一种网络协议，是客户端和服务端请求和相应的标准(TCP)，用于从 WWW 服务器传输超文本到本地浏览器的传输协议，HTTP 协议可以使浏览器更加高效，网络传输减少

HTTPS：以安全为目标的 HTTP 通道，简单讲就是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL

HTTPS 协议的主要作用：建立一个信息安全通道，来确保数据的传输，确保完善的的真实性

HTTP 和 HTTPS的区别

HTTP 传输的都是明文数据，也就是说没有加密的数据，网景公司设置了 SSL 协议来对 HTTP 协议传输的数据进行加密处理，简单来说 HTTPS 协议是由 HTTP 和 ssl 协议构建的可进行加密传输和身份认证的网络协议，比 HTTP 协议的安全性更高

HTTP 和 HTTPS 的主要区别：

• HTTPS 协议需要 ca 证书，费用较高
• HTTPS 协议更安全：HTTP 连接简单，没有状态，使用明文传输信息，HTTPS 协议则是由 ssl + HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 更安全
• 两者默认端口不同，使用的链接方式也不同：HTTP 协议的默认端口是 80，HTTPS 的默认端口是 443

HTTPS 协议的工作原理

对应的请求步骤：

1. Client 发起一个 HTTPS请求(例如HTTPS://blog.plumbiu.club)，根据 RFC2818 的规定，Client 知道需要连接 Server 的 443（默认）端口

2. Server 把事先配置好的公钥证书（public key certificate）返回给客户端

3. Client 验证公钥证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的 Root 证书或者Client 内置的 Root 证书）。如果验证通过则继续，不通过则显示警告信息

4. Client 使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给 Server

5. Server 使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client 和 Server 双方都持有了相同的对称密钥

6. Server 使用对称密钥加密“明文内容A”，发送给 Client

7. Client 使用对称密钥解密响应的密文，得到“明文内容A”

8. Client 再次发起 HTTPS 的请求，使用对称密钥加密请求的“明文内容B”，然后 Server 使用对称密钥解密密文，得到“明文内容 B”

HTTPS 协议的优缺点

优点：

1. HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户端和服务器
2. HTTPS 协议是由 SSL+HTTP 协议构建的可加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
3. 谷歌在 2014 年 8 月调整搜索引擎算法，采用 HTTPS 加密的网站在搜索结果中的排名将会更高

缺点：

1. HTTPS 握手阶段比较费时，页面加载时间延长 50%
2. HTTPS 缓存不如 HTTP 高效，会增加数据开销
3. HTTP 需要 SSL 证书，功能越多的证书费用要高
4. SSL 证书需要绑定 IP，不能在同一个 ip 绑定多个域名，ipv4 资源支持不了这种消耗

TCP

三次握手

一句话概括：

客户端和服务端都需要直到各自可收发，因此需要三次握手

简化逻辑图：

• 第一次握手：

客户端将 TCP 报文标志位 SYN 置为 1，随机产生一个序号值 seq = J，保存在 TCP 首部的序列号(Sequence Number) 字段里，指名客户端打算连接的服务器端口，并将该数据包发送给服务器端，发送完毕后，客户端进入 SYN_SENT 状态，等待服务端确认

• 第二次握手：

服务端收到的数据包后由标志位 SYN = 1 知道客户端请求建立连接，服务器端将 TCP 报文标志位 SYN 和 ACK 都置为 1， ack = J + 1，随机产生一个序列值 seq = K，并将该数据包发送给客户端已确认连接请求，服务端进入 SYN_RCVD 状态

• 第三次握手：

客户端收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果正确则将标志位 ACK 置为1，ack= K + 1，并将该数据包发送给服务器端，服务器端检查 ack 是否为 K + 1，ACK 是否为 1，如果正确则连接建立成功，客户端和服务器端进入 ESTABLISHED 状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

小写的 ack 和大写的 ACK 是不同的概念

• ack：Acknowledge number，表示头部确认号，是对上一个包的序号进行确认，即 ack = seq + 1
• ACK：TCP 首部的标志位，用于标志的 TCP 包是否对上一个包进行了确认操作，如果确认了，则把 ACK 标志位设置成 1

四次挥手

逻辑图：

在断开连接之前客户端和服务器都处于ESTABLISHED状态，双方都可以主动断开连接，以客户端主动断开连接为优。

• 第一次挥手：客户端打算断开连接，向服务器发送 FIN 报文(FIN 标记位被设置为 1，1 表示为 FIN，0 表示不是)，FIN 报文中会指定一个序列号，之后客户端进入FIN_WAIT_1 状态。也就是客户端发出连接释放报文段(FIN报文)，指定序列号 seq = u，主动关闭 TCP 连接，等待服务器的确认。

• **第二次挥手：服务器收到连接释放报文段(FIN 报文)后，就向客户端发送 ACK 应答报文，以客户端的 FIN 报文的序列号 seq+1 作为ACK应答报文段的确认序列号 ack = seq+1 = u + 1。接着服务器进入CLOSE_WAIT(等待关闭)**状态，此时的 TCP 处于半关闭状态，客户端到服务器的连接释放。客户端收到来自服务器的 ACK 应答报文段后，进入 FIN_WAIT_2 状态。

• 第三次握手：服务器也打算断开连接，向客户端发送连接释放(FIN)报文段，之后服务器进入 LASK_ACK(最后确认)状态，等待客户端的确认。服务器的连接释放(FIN)报文段的FIN=1，ACK=1，序列号seq=m，确认序列号ack=u+1。

• 第四次握手：客户端收到来自服务器的连接释放(FIN)报文段后，会向服务器发送一个ACK应答报文段，以连接释放(FIN)报文段的确认序号 ack 作为ACK应答报文段的序列号 seq，以连接释放(FIN)报文段的序列号 seq+1作为确认序号ack。之后客户端进入TIME_WAIT(时间等待)状态，服务器收到ACK应答报文段后，服务器就进入CLOSE(关闭)状态，到此服务器的连接已经完成关闭。客户端处于TIME_WAIT状态时，此时的TCP还未释放掉，需要等待2MSL后，客户端才进入CLOSE状态。

总结：

1. 客户端打算关闭连接，向服务器发送报文，等待服务器确认
2. 服务器接受到来自客户端的报文段，向客户端发送应答报文，等待服务器的数据发送完毕
3. 服务器数据发送完毕，也准备断开，向客户端发送关闭连接的字段
4. 客户端接受到来自服务器连接释放的报文，向服务器发送一个应答报文段，服务器收到后连接完成关闭，客户端等待 2MSL 后关闭

三次握手和四次挥手更加通俗的理解：

TCP 和 UDP 的区别

1. TCP 是面向连接的，传送的数据确保正确性；UDP 是无连接的，即发送数据前不需要先建立链接，会出现丢包现象
2. TCP 保证数据顺序；UDP 不保证
3. TCP 对资源的要求较多；UDP 较少
4. TCP 确保数据的正确性，因此适合大数据量的交换
5. TCP 连接只能是 1 对 1 的；UDP 支持 1 对 1，也支持 1 对多
6. TCP 首部为 20 字节；UDP 首部为 8 字节

HTTP 发展史

HTTP1.0

• 请求相应支持 HTTP 头，响应含状态行，增加了状态码
• 支持 HEAD，POST 方法
• 支持传输 HTML 文件意外的其他类型的内容

HTTP1.0 使用的是非持久连接，缺点是客户端必须为一个待请求的对象建立并维护一个新的连接，即每请求一个文档就要有两倍的 RTT 开销。并且由于同一个页面可能存在多个对象，所以非持久连接可能使一个页面的下载变得十分缓慢，这种短连接增加了网络传输的负担

RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；

HTTP1.1

• 支持长连接
• 引入了更多的缓存控制策略
• 引入了请求范围设置，优化了带宽
• 在错误通知管理中新增了错误状态响应吗
• 增加了 Host 头部处理，可以传递主机名(hostname)

HTTP1.1 传输的内容是明文，不够安全

HTTP2.0

• 二进制分帧，将数据分割为更小的帧，并且采用二进制编码
• 多路复用，能够在一个 TCP 上并行发送任意数量的 HTTP 请求，避免对头堵塞
• 头部压缩，HTTP1.X 协议是无状态的，导致每次请求都必须附上所有信息，这样重复的字段多次重新请求，会浪费很多带宽和性能，HTTP2.0 引入了头信息压缩机制
• 服务器推送，服务器可以主动把 JS 和 CSS 文件推送到客户端，而不需要客户端解析 HTML 时再发送请求

BOM 对象

BOM 是浏览器对象，有着很多关于浏览器的属性

iframe

iframe 元素会创建包含另一个文档的内联框架

缺点：

1. 会阻塞主页面的 onload 事件
2. 搜索引擎无法解读这种页面，不利于 SEO
3. iframe 和主页面共享连接池，而浏览器对相同区域有限制所以会影响性能

Doctype

Doctype 声明于文档最前面，告诉浏览器以哪种规范来渲染页面，例如 html 或者 xhtml 规范

DOCTYPE(document type) 必须放在 html 文件最前面，它不是 HTML 标签，也没有结束标签

<!DOCTYPE html>

Cookie、sessionStorage、localStorage 联系和区别

Cookie：由于 HTTP 是一个无状态协议，Cookie 出现的最大作用就是存储 sessionId 用来标识唯一用户

相同点：

• Cookie、sessionStorage、localStorage 都是保存在浏览器端，用于临时存储客户端会话信息或者数据的方法，且是同源的

不同点：

• 存储时间有效期不同
  1. cookie 的有效期是可以设置的，默认情况下关闭浏览器后失效
  2. sessionStorage 的有效期仅保持在当前页面，关闭当前会话或者浏览器就会失效
  3. localStorage 的有效期是在不进行手动删除的情况下是一直有效的
• 与服务端的通信
  1. cookie 的存储在 4kb 左右，存储量较小，一般页面最多存储 20 条左右信息
  2. localStorage 和 sessionStorage 的存储容量是 5Mb(部分浏览器有差异)

Cookie 如何防范 XSS 攻击

XSS(跨站脚本攻击)，是指攻击者在返回的 HTML 中嵌入 JavaScript 脚本

在 HTTP 头部上配置 set-cookie 响应头，其中两个属性可以防止 XSS 攻击：

• http-only：防止 XSS，因为它会禁止 JavaScript 脚本来访问 cookie
• secure：告诉浏览器仅在请求为 https 是才会发送 cookie

浏览器事件

1. click 点击事件在 ios 有 300ms 延迟，原因及如何解决

苹果的 safari 浏览器，为了把 PC 端大屏幕的页面更好的显示在小屏幕手机端，采用了双击缩放(doubel tap to zoom)方案，为了检测用户是单击操作还是双击操作而设置了 300ms 延迟

解决方案：

• 禁用缩放(粗暴型)

既然缩放是导致延迟的原因，那么我们可以禁止缩放

<meta name="viewport" content="width=device-width,user-scale=no"

• 利用 FastClick

FastClick 的原理是：检测到 touchend 时间后，like发出模拟 click 事件，并且把 浏览器 300ms 之后真正触发的事件阻断掉

npm i fastclick

document.addEventListener('DOMContentLoaded', () => {
  FastClick.attach(document.body)
}, false)

http 状态码

HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)：

HTTP状态码列表:

http 响应头

get 和 post 请求的区别

1. get 请求一般是获取数据；post 则是提交数据
   1. get 请求的请求参数放在 url 中，隐私性、安全性差，而且请求的长度有限制；post 请求是没有长度，数据放在 body(消息主题 entity-body 里) 中
2. get 请求可以被缓存；post 请求不可以缓存
3. get 请求会被保存在浏览器历史记录当中，post 不会
4. get 请求可以被收藏为标签，因为其请求参数就在 url 中；post 不能，因为它的参数不在 url 中
5. get 的请求是 url 编码(application-x-www-form-urlencoded)；post 请求支持多种编码方式(例如 multipart/form-data 等)
6. get请求刷新服务器或者回退没有影响，post请求回退时会重新提交数据请求

浏览器缓存

浏览器缓存分为强缓存和协商缓存，根据响应头内容(Cache-Control)来决定.

Cache-Control 取值：

协商缓存

协商缓存的触发条件：

• Cache-Control 的值为 no-cache
• 或者 Cache-Control: max-age=0

协商缓存的标识

Last-Modified：文件在服务器最后被修改的事件，从服务器的 Response Headers 上获取

更多请了解：一文彻底弄懂浏览器缓存，只需动手操作一次 - 掘金 (juejin.cn)

稍微总结一下：

1. 跟强缓存有关的字段有 expires、cache-control。如果 cache-control 和 expires 同时存在，cache-control 的优先级比 expires 高
2. 跟协商缓存的字段有 Last-Modified/If-Modified-Since、Etag/If-None-Match

从用户输入 url 到页面展示发生了什么

长话短说：

注：无缓存版本

1. DNS 解析
2. TCP 连接
3. 发送 HTTP 请求
4. 服务器处理请求并返回 HTTP 报文和加载资源
5. 浏览器解析渲染页面

更详细：

1. 首先，在浏览器地址栏输入 url,回车
2. 根据 url,浏览器先查看浏览器缓存 -> 系统缓存 -> 路由缓存，如果缓存中有，会从缓存中读取并显示，若没有，则跳到第三步
3. 在发送 http 请求前，先进行DNS域名解析，获取访问的IP地址
4. 浏览器向服务器发起 tcp 连接，与浏览器建立 tcp 三次握手
5. 握手成功后，浏览器和服务器已经建立了通信，浏览器向服务器发送 http 请求，请求数据包。
6. 服务器接收到请求，处理请求并返回 url 指定数据给浏览器
7. 浏览器接收到服务器 HTTP 响应内容
8. 浏览器进行渲染，解析HTML生成DOM树,解析 CSS 生成规则树，js 引擎解析 js,将解析后 DOM 树和 CSS 规则树关联起来构建 Renden 渲染树树，然后计算布局，绘制页面
9. 渲染完毕，四次挥手，关闭 tcp 连接

图片解释：