浏览器兼容性问题解决方案

老生常谈的面试题了

这个过程发生了什么？

• DNS 解析
  • DNS 缓存
  • DNS 负载均衡
• TCP 连接
  • 三次握手的步骤
  • 四次挥手
• HTTP 请求
• HTTPS 协议
• HTTPS 过程
• 浏览器接收服务器响应结果并处理
• 总结

DNS 解析

DNS 概念

DNS，英文全称 Domain Name System,中文全程：域名系统，作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS 基于 C/S 架构（多数基于套接字架构的都是 C/S 架构），同时使用 TCP 和 UDP 的 53 号端口，当前，对于每一级域名长度限制是 63 个字符，域名总长度则不能超过 253 个字符

DNS 解析的过程就是寻找哪台机器上有你需要资源的过程。当你在浏览器中输入一个地址时，例如 www.baidu.com，其实不是百度网站真正意义上的地址。互联网上每一台计算机的唯一标识是它的 IP 地址，但是 IP 地址并不方便记忆。用户更喜欢用方便记忆的网址去寻找互联网上的其它计算机，也就是上面提到的百度的网址。所以互联网设计者需要在用户的方便性与可用性方面做一个权衡，这个权衡就是一个网址到 IP 地址的转换，这个过程就是 DNS 解析。它实际上充当了一个翻译的角色，实现了网址到 IP 地址的转换。网址到 IP 地址转换的过程是如何进行的?

DNS 缓存

可以看到上图中，如果没有 DNS 缓存，得到非常多的服务器去找对应的 IP 地址（实际情况可能还不止上图的几台服务器）。所以 DNS 优化可以让我们在根源就解决加载的第一步问题

DNS 缓存

DNS 存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS 服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。

• 在你的 chrome 浏览器中输入:chrome://dns/，你可以看到 chrome 浏览器的 DNS 缓存。

• 系统缓存主要存在 hosts 文件中

  • linux etc/hosts 文件
  • window C:\Windows\System32\drivers\etc
  • max emmmm 没有 mac 电脑

DNS 负载均衡

我们平时用的一些优秀的 JS 库或者其他的库，包括图片，都可能会用到一项叫CDN的东西。请求 CDN 的内容，一个是速度较快，其次减少自己服务器的负担。
那CDN原理是什么？就是 DNS 负载均衡

互联网世界背后存在成千上百台服务器，大型的网站甚至更多。那么负载均衡则是分配来自各地的请求，分别分配给不同的服务器去处理这些请求。
例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是 DNS 负载均衡，又叫做 DNS 重定向。

TCP 连接

何为 tcp

TCP 是一种面向有连接的传输层协议。
它可以保证两端（发送端和接收端）通信主机之间的通信可达。
它能够处理在传输过程中丢包、传输顺序乱掉等异常情况；此外它还能有效利用宽带，缓解网络拥堵。

常说的 三次握手，四次挥手

三次握手的步骤

“3 次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

抽象派

客户端：hello，你是server么？
服务端：hello，我是server，你是client么
客户端：yes，我是client

实际情况

太枯燥了。。。我也不知道从何写起，可以看下百科

百度百科 - 三次握手 (opens new window)

四次挥手

在挥手之前其实还有一个HTTP 请求。在请求结束后才会进行4次挥手。

还是直接写抽象派的把

主动方：我已经关闭了向你那边的主动通道了，只能被动接收了
被动方：收到通道关闭的信息
被动方：那我也告诉你，我这边向你的主动通道也关闭了
主动方：最后收到数据，之后双方无法通信

HTTP 请求

HTTP 请求报文是由三部分组成: 请求行, 请求报头和请求正文

请求行

格式如下:
Method Request-URL HTTP-Version CRLF

换成我们常见的请求，一一对应的便是如下：
GET index.html HTTP/1.1

请求报头

常见的请求报头有

Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent 等。

看一个百度请求的时候的请求报头

其中

• Accept 用于指定客户端用于接受哪些类型的信息，Accept-Encoding 与 Accept 类似，它用于指定接受的编码方式。
• Connection 设置为 Keep-alive 用于告诉客户端本次 HTTP 请求结束之后并不需要关闭 TCP 连接，这样可以使下次 HTTP 请求使用相同的 TCP 通道，节省 TCP 连接建立的时间。

HTTPS 协议

HTTP 报文是包裹在 TCP 报文中发送的，服务器端收到 TCP 报文时会解包提取出 HTTP 报文。但是这个过程中存在一定的风险，HTTP 报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入 TCP 报文之前对 HTTP 做一次加密就可以解决这个问题了。HTTPS 协议的本质就是 HTTP + SSL(or TLS)。在 HTTP 报文进入 TCP 报文之前，先使用 SSL 对 HTTP 报文进行加密。从网络的层级结构看它位于 HTTP 协议与 TCP 协议之间。

HTTPS 过程

HTTPS 相比于 HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用 HTTPS 需要根据具体情况在安全和性能方面做出权衡。

浏览器接收服务器响应结果并处理

HTTP 响应报文也是由三部分组成: 状态码, 响应报头和响应报文。

状态码 可以看这里 Http 状态码

响应报文 服务器返回给浏览器的文本信息，通常 HTML, CSS, JS, 图片等文件就放在这一部分。
然后就是浏览器渲染的过程了。浏览器渲染又是非常大的一个板块，TODO 完善该文章

总结

看了那么多流程，目的都是一样的，提高加载速度和效率

如何尽快的加载资源？

答案就是能不从网络中加载的资源就不从网络中加载，当我们合理使用缓存，将资源放在浏览器端，这是最快的方式。

如果资源必须从网络中加载，则要考虑缩短连接时间，即 DNS 优化部分;减少响应内容大小，即对内容进行压缩。

另一方面，如果加载的资源数比较少的话，也可以快速的响应用户。当资源到达浏览器之后，浏览器开始进行解析渲染，浏览器中最耗时的部分就是 reflow，所以围绕这一部分就是考虑如何减少 reflow 的次数。