简单总结
1.DNS解析
2.TCP链接
3.发送HTTP请求
4.服务器处理请求并返回HTTP报文
5.浏览器解析渲染页面
6.连接结束
具体过程
DNS解析的过程就是寻找哪台机器上有我们需要资源的过程。当我们在浏览器中输入地址时，例如www.baidu.com，其实这不是百度网站的真正意义上的地址。互联网上每一台计算机的唯一标识是它的IP地址，但是IP不好记忆，用户倾向于用好想的方式来寻找互联网上的其他计算机，也就是上面说的百度网址。所以互联网设计者需要在用户的方便性与可用性上做权衡，这个权衡就是做网址到ip地址的转换，这个过程就是DNS解析。它实际上充当了一个翻译的角色，实现了网址到IP地址的转换。
转换过程
DNS解析是一个递归查询的过程
上图是查找www.google.com的IP地址过程。首先在本地域名服务器中查询IP地址，如果没有，本地域名服务器会向根域名服务器发送一个请求，如果根域名服务器也不存在该域名，本地域名会向com顶级域名服务器发送一个请求，依次类推下去。直到最后本地域名服务器得到google的IP地址并把它缓存到本地，供下次查询使用。因此网址的解析是一个从右向左的过程：. -> .com -> google.com. -> www.google.com.。根域名服务器是一个点.。事实上，真正的网址是www.google.com.，这个.对应的就是根域名服务器，默认情况下所有的网址的最后一位都是.，既然是默认情况下，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上
DNS优化
上述请求google的ip地址经历了8个步骤，如果每次请求都经历这么多步骤，太耗时，减少步骤的过程就是DNS缓存。
DNS缓存
DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。
- 在你的chrome浏览器中输入:chrome://dns/，你可以看到chrome浏览器的DNS缓存。
- 系统缓存主要存在/etc/hosts(Linux系统)中:
...
DNS负载均衡
真实的互联网世界背后存在成千上百台服务器，大型的网站甚至更多。但是在用户的眼中，它需要的只是处理他的请求，哪台机器处理请求并不重要。DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡，又叫做DNS重定向。大家耳熟能详的CDN(Content Delivery Network)就是利用DNS的重定向技术，DNS服务器会返回一个跟用户最接近的点的IP地址给用户，CDN节点的服务器负责响应用户的请求，提供所需的内容。
TCP链接
HTTPs协议
HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。
HTTPS过程
HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。
HTTP请求
它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。
请求行：格式：Method Request-URL HTTP-Version CRLF
例如：GET demo.html HTTP/1.1 (回车+换行)
常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。
请求头：请求头允许客户端向服务器传递请求的附加信息和客户端自身信息。常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。请求头和请求正文之间有回车和换行
请求正文：客户端向服务器传递的数据
服务器处理请求并返回HTTP报文
后端从固定的接口收到TCP报文，对TCP连接处理，对HTTP协议解析，并按照报文格式进一步封装成HTTP Response对象，供上层使用。
HTTP响应报文组成：响应行、响应报头和响应报文
服务器返回给浏览器的文本信息，通常THML,CSS,JS,图片等文件放在响应报文。
浏览器解析渲染页面
浏览器边解析边渲染。首先解析HTML文件，构建DOM数，然后解析CSS文件构建渲染树，渲染树完成后，开始布局渲染树并将其绘制到屏幕上。此过程中涉及到reflow（回流）和repaint（重绘）。DOM节点的各个元素都是以盒模型的形式存在，在写都需要浏览器去计算位置和大小等，这个过程就是reflow，等到位置大小颜色字体等确定下来之后，浏览器开始绘制内容，这就是repaint。r回流和重绘非常耗性能，有时会造成页面卡顿，破会用户体验，因此要尽可能减少回流和重绘。
JS的解析由浏览器中的JS解析引擎完成。JS是单线程运行，同一时间内只能做一件事，所有的任务需要排队，前一个任务结束才能执行后一个任务。但是又存在有些任务很耗时，例如IO操作，所以得要一种机制可以先执行排在后面的任务，这就是同步任务和异步任务。JS的执行机制可以看做是一个主线程加一个任务队列。同步任务放在主线程上执行，异步任务放在队列中。所有的同步任务在主线程上执行，形成一个执行栈，异步任务有了运行结果就会在任务队列中放置一个事件。脚本运行时先依次运行执行栈，然后从任务队列中提取事件，运行任务队列中的任务，这个过程不断重复，形成一个事件循环。
浏览器在解析过程中，异步请求外部资源，像图片，js等。异步请求不影响HTML文档加载，但是当文档加载时遇见JS文件，HTML文档会挂起渲染，要等到js文件加载完毕解析执行完毕，才继续渲染HTML。因为浏览器单线程，GUI渲染和js解析引擎互斥，不能同时处理。还有，JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。
ps：加载渲染慢，提高性能就要web优化。
网友评论