HTTP是一个专门用于在两点之间传输文字、图片、视频等超文本数据的约定和规范

HTTP

超文本运输协议，是实现网络通信的一种规范
HTTP是一个传输协议，即将数据由A传到B或将B传输到A，并且 A 与 B 之间能够存放很多第三方，如：A<=>X<=>Y<=>Z<=>B
传输的数据并不是计算机底层中的二进制包，而是完整的、有意义的数据，如HTML 文件, 图片文件, 查询结果等超文本，能够被上层应用识别
在实际应用中，HTTP常被用于在Web浏览器和网站服务器之间传递信息，以明文方式发送内容，不提供任何方式的数据加密

特点如下：

• 支持客户/服务器模式
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间
• 无状态：HTTP协议无法根据之前的状态进行本次的请求处理

HTTP 的无状态特性

HTTP报文内的HTTP信息

用于HTTP协议交互的信息被称为HTTP报文，客户端的叫请求报文，服务端的叫做响应报文。
组成：报文首部（客户端或服务端需要处理的请求或相应的内容及其属性）和报文主体（应被发送的数据）

首部的信息：

• 请求行：用于请求的方法
• 状态行：表明相应的结果的状态码，原因短语和HTTP的版本
• 首部字段：表示请求和相应的各种条件和属性的各类首部
• 其他：包含HTTP的RFC里未定义的首部，cookie等

缺点 ：

• 通信使用明文（不加密），内容可能被窃听
• 不验证通信方的身份，因此有可能遭遇伪装

编码提升传输速率

在传输时编码，能有效地处理大量的访问请求，但编码的操作需要用计算机来完成，会消耗更多CPU资源

报文主体和实体主体
报文：HTTP通信中的基本单位，由8位字节流组成，通过HTTP通信传输
实体：作为请求或相应的有效载荷数据（补充项）被传输，其内容由实体首部和实体组成

HTTP报文的主体，用于传输请求或响应的主体的实体
报文主体=实体主体，只有当传输中进行编码操作时，实体主体的内容才会发生变化，导致他和报文主体产生差异。

压缩传输的内容编码
内容编码：指明应用在实体内容上的编码格式，并保持实体信息原样压缩，内容编码后的实体由客户端接收并负责解码

分割发送的分块传输编码
在HTTP通信过程中，请求的编码实体资源尚未完全传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块（分割物叫做块），能够让浏览器逐步显示页面
每一块会用一个十六进制标记块的大小，而实体的最后一块会用“0(CR + LF)”来标记。
使用分块传输编码的实体主体会由接受的客户端负责解码，恢复到编码前的实体主体。
HTTP/1.1中存在一种称为传输编码的机制，它可以在通信时按照某种编码方式传输，但只定义作用于分块传输的编码中。

发送多种数据的多部份对象集合

HTTP的幂等性

幂等性是指一次和多次请求某一个资源应该具有同样的副作用
在HTTP协议里，所谓的安全就是请求方法不会破坏服务器上的资源，所谓的幂等，就是执行多次相同的操作，操作结果都是相同的。
很明显，GET方法就是安全且幂等的，post因为是新增或提交数据，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以是不幂等的。

HTTP首部

HTTP首部的内容为客户端和服务器分别处理请求和响应，提供所需要的信息。

HTTP请求报文

HTTP协议的优缺点

优点

简单
灵活易拓展
应用广泛跨平台

缺点

无状态、明文传输、不安全

• 无状态可以将记忆http状态的资源节省下来，减轻服务器的负担，将更多的CPU资源用于对外提供服务；
• 但是在完成具有关联性的操作时很麻烦

不安全：

• 使用明文通信—不加密
• 不验证双方通信身份

• 无法证明明文的完整性

  HTTP1.0 && HTTP1.1

  HTTP 1.0和 HTTP 1.1 有以下区别：

• 连接方面

  • http1.0 默认使用非持久连接，而 http1.1 默认使用持久连接。
  • http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
• 资源请求方面
  • 在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能
  • http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
• 缓存方面
  • 在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准
  • http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
• http1.1 中新增了 host 字段，用来指定服务器的域名。
  • http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。
  • 随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。
• http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT、HEAD、OPTIONS 等。

  keep-alive模式

一系列用逗号隔开的参数，每一个参数由一个标识符和一个值构成，并使用等号 (‘=’) 隔开。下述标识符是可用的：

• timeout：指定了一个空闲连接需要保持打开状态的最小时长（以秒为单位）。需要注意的是，如果没有在传输层设置 keep-alive TCP message 的话，大于 TCP 层面的超时设置会被忽略。
• max：在连接关闭之前，在此连接可以发送的请求的最大值。在非管道连接中，除了 0 以外，这个值是被忽略的，因为需要在紧跟着的响应中发送新一次的请求。HTTP 管道连接则可以用它来限制管道的使用
• 
  

HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。
当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。其使用方法如下：

• HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive），所以要想连接得到保持，必须手动配置发送Connection: keep-alive字段。若想断开keep-alive连接，需发送Connection:close字段；
• HTTP1.1规定了默认保持长连接，数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送Connection：close首部字段。

Keep-Alive的建立过程：

• 客户端向服务器在发送请求报文同时在首部添加发送Connection字段
• 服务器收到请求并处理 Connection字段
• 服务器回送Connection:Keep-Alive字段给客户端
• 客户端接收到Connection字段
• Keep-Alive连接建立成功

服务端自动断开过程（也就是没有keep-alive）：

• 客户端向服务器只是发送内容报文（不包含Connection字段）
• 服务器收到请求并处理
• 服务器返回客户端请求的资源并关闭连接
• 客户端接收资源，发现没有Connection字段，断开连接

客户端请求断开连接过程：

• 客户端向服务器发送Connection:close字段
• 服务器收到请求并处理connection字段
• 服务器回送响应资源并断开连接
• 客户端接收资源并断开连接

开启Keep-Alive的优点：

• 较少的CPU和内存的使⽤（由于同时打开的连接的减少了）；
• 允许请求和应答的HTTP管线化；
• 降低拥塞控制 （TCP连接减少了）；
• 减少了后续请求的延迟（⽆需再进⾏握⼿）；
• 报告错误⽆需关闭TCP连；

开启Keep-Alive的缺点：

• 长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

管道网络传输 & 队头阻塞

由于采用了长连接的模式，使得管道网络传输成为了可能；即可在同一个TCP链接里面，客户端发起多个请求，只要第一个请求发出去了，不必等他回来就可以发送第二个请求，减少整体响应时间
但是服务器还是按照顺序，依次回应请求，如果前面回应的特别慢，后面就会有许多请求等待，这称为队头阻塞

HTTP1.1 & HTTP2.0

• 二进制协议：HTTP/2 是一个二进制协议。在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”，可以分为头信息帧和数据帧。 帧的概念是它实现多路复用的基础。
• 多路复用：HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了”队头堵塞”【1】的问题。
• 数据流：HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。
• 头信息压缩：HTTP/2 实现了头信息压缩.
  • 由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。
  • HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。
• 服务器推送：HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是 http2 下服务器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。

【1】队头堵塞：

队头阻塞是由 HTTP 基本的“请求 - 应答”模型所导致的。HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

HTTP2

头部压缩算法

HTTP2的头部压缩是HPACK算法。在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。
具体来说:

• 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；
• 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新；
• 每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值。

例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销

HTTP3.0

HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。

1. 流量控制、传输可靠性功能：QUIC在UDP的基础上增加了一层来保证数据传输可靠性，它提供了数据包重传、拥塞控制、以及其他一些TCP中的特性。
2. 集成TLS加密功能：目前QUIC使用TLS1.3，减少了握手所花费的RTT数。
3. 多路复用：同一物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了TCP的队头阻塞问题。

1. 快速握手：由于基于UDP，可以实现使用0 ~ 1个RTT来建立连接。

HTTP协议性能

HTTP 协议是基于 TCP/IP，并且使用了请求-应答的通信模式，所以性能的关键就在这两点里。

• 长连接

HTTP协议有两种连接模式，一种是持续连接，一种非持续连接。
（1）非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。
（2）持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间。

对于不同版本的采用不同的连接方式：

• 在HTTP/1.0 每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。该版本使用的非持续的连接，但是可以在请求时，加上 Connection: keep-a live 来要求服务器不要关闭 TCP 连接。
• 在HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。该版本及以后版本默认采用的是持续的连接。目前对于同一个域，大多数浏览器支持同时建立 6 个持久连接。

• 管道网络传输

HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。

管道（pipeline）网络传输是指：可以在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器还是按照顺序回应请求。如果前面的回应特别慢，后面就会有许多请求排队等着。这称为队头堵塞。

• 队头堵塞

HTTP 传输的报文必须是一发一收，但是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是HTTP队头阻塞问题。

队头阻塞的解决方案：
（1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。
（2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

HTTP 缺点

1. 通信使用明文，内容可能会被窃听
   • 如果通信经过加密，就有可能让人无法破解报文信息的含义，但是加密处理后的报文信息的还是会被看到
   • 窃听相同段上的通信并非难事，只要收集在互联网上流动的数据包（帧），对于收集来的数据包解析的工作，可交给抓包or嗅探器工具
   • 解决：最为普及的防止窃听方法是加密技术，加密的对象可以有：通信、内容
     • 通信的加密：通过和SSL和TLS的组合使用，加密HTTP的通信内容，用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了，与SSL组合使用的HTTP称为HTTPS，或HTTP over SSL
     • 内容的加密：即把HTTP报文的内容进行加密处理后再发送加密请求
2. 不验证双方的身份，可能会遭遇伪装
   • 不存在确认通信方的处理步骤，任何人都可以发起请求；只要服务器收到请求，不管对方是谁都会回一个响应。（仅限于发送端IP地址和端口没有被Web服务器设定限制的访问的前提下）
   • 隐患：
     • 无法确定请求发送至目标的web服务器是否按照真实意图返回相应的那台服务器
     • 无法确定响应返回到的客户端是否是按真实意图接收那个客户端
     • 无法确定相应返回到的客户端是否具备访问权限
     • 无法确定请求来自何方、出自谁收
     • 即使是无意义的请求也会接收，无法阻止海量请求下的DoS攻击（拒绝服务攻击）
   • 解决：
     • 证书
3. 无法验证报文的完整性，可能已经遭到篡改
   • 完整性：信息的准确度，若无法证明其完整性，通常意味着无法判断信息是否正确
   • 接收到的信息可能有误：从请求或响应发送出去到接受的这段时间内，无法据悉是否内容被篡改（像这种在请求或响应的传输途中，遭到攻击者拦截或篡改内容的攻击称为中间人攻击）
   • 解决：MD5、SHA-1等散列值校验的方法，以及用来确认文件的数字签名的方法
     • 提供文件下载服务的web网站会提供相应的PCG（完美隐私）创建的数字签名以及MD5算法生成的散列函数值
     • PCG是用来证明创建文件的数字签名，MD5是由单向函数生成的散列值
     • 浏览器无法自动帮用户检查；无法百分百确认结果正确（因为MD5和PCG被篡改用户无法意识到）

       HTTPS

       HTTPS并不是一种新协议，只是HTTP通信接口部分用SSL和TLS协议代替而已。
       HTTP直接与TCP通信，当使用SSL时，先和SSL通信，然后SSL在和TCP通信。

让HTTP运行安全的SSL/TLS协议上，即 HTTPS = HTTP + SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密
SSL 协议位于TCP/IP 协议与各种应用层协议之间，浏览器和服务器在使用 SSL 建立连接时需要选择一组恰当的加密算法来实现安全通信，为数据通讯提供安全支持

过程

• 首先客户端通过URL访问服务器建立SSL连接
• 服务端收到客户端请求后，会将网站支持的证书信息（证书中包含公钥）传送一份给客户端
• 客户端的服务器开始协商SSL连接的安全等级，也就是信息加密的等级
• 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站
• 服务器利用自己的私钥解密出会话密钥
• 服务器利用会话密钥加密与客户端之间的通信

SSL

概念

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。是独立于HTTP的协议，其他运行在应用层的SMTP、Telnet等协议可以配合SSL协议使用

SSL速度

1. 通信慢
2. 大量消耗CPU及内存资源，导致处理速度慢

原因：

1. 与HTTP相比，网络负载会变慢到2-100倍，除去和TCP连接、发送HTTP请求、响应以外，还必须进行SSL通信，因此整体上处理通信量不可避免会增加
2. SSL必须进行加密处理，在服务器和客户端东需要进行加密和解密的处理；因此也会更多的消耗硬件资源，导致负载增强

解决：使用SSL加速器（专用服务器）硬件来改善问题。

实现

SSL的实现这些功能主要依赖于三种手段：

• 对称加密：采用协商的密钥对数据加密
  • 加密和解密使用的秘钥都是同一个，是对称的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性
  • 
• 非对称加密：实现身份认证和密钥协商
  • 非对称加密，存在两个秘钥，一个叫公钥，一个叫私钥。两个秘钥是不同的，公钥可以公开给任何人使用，私钥则需要保密
  • 公钥和私钥都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密
  • 
• 混合加密：在HTTPS通信过程中，采用的是对称加密+非对称加密，也就是混合加密
  • 在对称加密中讲到，如果能够保证了密钥的安全，那整个通信过程就可以说具有了机密性；而HTTPS采用非对称加密解决秘钥交换的问题，具体做法是发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信
  • 

上述的方法解决了数据加密，在网络传输过程中，数据有可能被篡改，并且黑客可以伪造身份发布公钥，如果你获取到假的公钥，那么混合加密也并无多大用处，你的数据仍被黑客解决
因此，在上述加密的基础上仍需加上完整性、身份验证的特性，来实现真正的安全，实现这一功能则是摘要算法

• 摘要算法：验证信息的完整性
  • 可以理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”
  • 摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性
  • 比如，你发了条消息：“转账 1000 元”，然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改
  • 
• 数字签名：身份验证
  • 数字签名能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名
  • 原理其实很简单，就是用私钥加密，公钥解密
  • 签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的
  • 

和消息本身一样，因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么判断这个公钥就是你的公钥。这时候就需要一个第三方，就是证书验证机构

CA验证机构

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场
CA 对公钥的签名认证要求包括序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”

流程

• 服务器的运营人员向数字证书认证机构提出公开密钥的申请
• 数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名
• 然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起
• 服务器会将这份由数字证书认证机构颁发的数字证书发送给客户端，以进行非对称加密方式通信

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，则证明：

• 认证服务器的公开密钥的是真实有效的数字证书认证机构
• 服务器的公开密钥是值得信赖的

HTTPS通信（握手）过程

HTTPS的通信过程如下：

1. 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
2. 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。
4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。
5. 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

为什么不一直使用HTTPS

1. 与纯文本通信相比，加密通信会消耗更多的CPU及内存资源，如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够请求的数量也会随之减少。
2. 节约购买证书的开销

   HTTP & HTTPS 区别

• HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理，相对更安全
• HTTP 和 HTTPS 使用连接方式不同，默认端口也不一样，HTTP是80，HTTPS是443
• HTTPS 由于需要设计加密以及多次握手，性能方面不如 HTTP
• HTTPS需要SSL，SSL 证书需要钱，功能越强大的证书费用越高

HTTPS与HTTP虽然只差一个SSL，但是通信安全得到了大大的保障，通信的四大特性都以解决，解决方式如下：

• 机密性：混合算法
• 完整性：摘要算法
• 身份认证：数字签名
• 不可否定：数字签名

同时引入第三方证书机构，确保公开秘钥的安全性

浏览器+HTTP

当在浏览器中输入 Google.com 并且按下回车之后发生了什么？

1. 解析URL
   • 首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。
   • 如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。
2. 缓存判断
   • 浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。
3. DNS解析
   • 下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。
   • 本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。
   • 用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。
4. 获取MAC地址
   • 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。
   • 网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。
   • 通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
5. TCP三次握手
6. HTTPS握手
   • 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。
   • 首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。
   • 服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。
   • 客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。
   • 服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。
   • 这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。
7. 返回数据
   • 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程
8. 页面渲染
   • 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。
   • 当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。
   • 渲染树构建好后，会根据渲染树来进行布局。
   • 布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。
9. TCP四次挥手

DOM和CSSDOM树渲染过程

浏览器渲染页面前需要先构建 DOM 和 CSSOM 树。因此，我们需要确保尽快将 HTML 和 CSS都提供给浏览器。这也是我们为什么要在页面底部引入JavaScript代码的原因。或者说可以在头部引用，但是前提是加上async、defer，或window.onload。

1、首先呢是构建DOM树，刚开始获取到的是原始的字节，这时候呢，首先会进行一个转换的过程，就是说通过指定的字符编码（utf-8或者gbk2312之类的）准换成字符，这个时候呢，是字符串一样的东西，会进行一个令牌化的处理，把这些字符串转换成W3C标准下的各种令牌大概是这样的（“”、“

”），这个时候还不是标签对象呢，需要发出的令牌转换成定义其属性和规则的“对象”，最后才是DOM树的构建，由于标签之间的嵌套关系，创建的对象链接在一个树数据结构内，这个结构也会捕获原始标记中定义的父项-子项关系（比如说body是HTML对象的子项，是DIV对象的父类一样）。 整个流程的最终输出是我们这个简单页面的文档对象模型 (DOM)，浏览器对页面进行的所有进一步处理都会用到它。

2、CSSOM树的构建，整体的过程呢其实和上边的流程特别的相似。CSS 字节转换成字符，接着转换成令牌和节点，最后链接到一个称为“CSS 对象模型”(CSSOM) 的树结构，有人可能就要懵逼了，css怎么会有树形结构呢，也是依赖于类名的嵌套关系吧，为页面上的任何对象计算最后一组样式时，浏览器都会先从适用于该节点的最通用规则开始（例如，如果该节点是 body 元素的子项，则应用所有 body 样式），然后通过应用更具体的规则（即规则“向下级联”）以递归方式优化计算的样式。就是说没有明显关系的，会直接连接在body上。但是这个时候还不是完整的CSSOM树，它只显示了我们决定在样式表中替换的样式。

3、通过DOM树和CSS规则树，浏览器就可以通过它两构建渲染树了。浏览器会先从DOM树的根节点开始遍历每个可见节点，然后对每个可见节点找到适配的CSS样式规则并应用。渲染树生成后，还是没有办法渲染到屏幕上，渲染到屏幕需要得到各个节点的位置信息，这就需要布局的处理了。

4、布局阶段会从渲染树的根节点开始遍历，由于渲染树的每个节点都是一个Render Object对象，包含宽高，位置，背景色等样式信息。所以浏览器就可以通过这些样式信息来确定每个节点对象在页面上的确切大小和位置，布局阶段的输出就是我们常说的盒子模型，它会精确地捕获每个元素在屏幕内的确切位置与大小。

5、在绘制阶段，浏览器会遍历渲染树，调用渲染器的paint()方法在屏幕上显示其内容。渲染树的绘制工作是由浏览器的UI后端组件完成的

页面有多张图片，HTTP是怎样的加载表现？

• 在HTTP 1下，浏览器对一个域名下最大TCP连接数为6，所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目，加快页面图片的获取速度。
• 在HTTP 2下，可以一瞬间加载出来很多资源，因为，HTTP2支持多路复用，可以在一个TCP连接中发送多个HTTP请求。