1.DNS解析
2.TCP连接
3.发送http请求
4.服务器处理请求并返回http报文
5.返回http报文
6.关闭TCP连接
7.浏览器解析渲染页面
8.解析结束
1.DNS解析
寻找哪台机器上有你需要资源。网址-->IP
www.baidu.com，其实不是百度网站真正意义上的地址。互联网上每一台计算机的唯一标识是它的IP地址。网址到IP地址的转化过程就是DNS解析的过程。
image.png
网址的解析是一个从右向左的过程: com -> google.com -> www.google.com。但是你是否发现少了点什么，根域名服务器的解析过程呢？事实上，真正的网址是www.google.com.，并不是我多打了一个.，这个.对应的就是根域名服务器，默认情况下所有的网址的最后一位都是.，既然是默认情况下，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上，所有网址真正的解析过程为:** . -> .com -> google.com. -> www.google.com.**。
DNS优化-->DNS缓存
从距离浏览器的距离进行排序如下
浏览器缓存-->系统缓存-->路由器缓存-->IPS服务器缓存-->根域名服务器缓存-->顶级域名服务器缓存-->主域名服务器缓存
DNS负载均衡
根据每台服务器的负载量，服务器距离用户地理位置的远近距离等等，DNS可以返回一个合适的机器的IP给用户。这个过程叫做DNS负载均衡。又叫DNS重定向
2.TCP连接
终于拿到了服务器IP，下一步任务，连接到该服务器。客户端和服务器的TCP连接-->三次握手
三次握手
客户端：“你好，在家不，有你快递。”
服务端：“在的，送来就行。”
客户端：“好嘞。”
3.发送http请求
与服务器建立连接后，就可以向服务器发送请求了
请求报文的结构
请求行包括请求方法、URL、HTTP版本。
首部字段传递重要信息，包括请求首部字段、通用首部字段和实体首部字段。我们可以从报文中看到发出的请求的具体信息。
4.服务器处理请求
服务器接收请求后由web服务器（准确说是http服务器）处理请求。web服务器解析用户请求，知道了需要调度哪些资源文件，再通过相应的这些资源文件处理用户请求和参数，并调用数据库信息，最后将结果通过web服务器返回给浏览器客户端。
5.返回http报文
在HTTP里，有请求就会有响应，哪怕是错误信息。
响应报文
在响应结果中都会有个一个HTTP状态码，比如我们熟知的200、301、404、500等。通过这个状态码我们可以知道服务器端的处理是否正常，并能了解具体的错误。
状态码由3位数字和原因短语组成。根据首位数字，状态码可以分为五类：
状态码
6.关闭TCP连接
四次握手
为了避免服务器与客户端双方的资源占用和损耗，当双方没有请求或响应传递时，任意一方都可以发起关闭请求
4次握手
客户端：“兄弟，我这边没数据要传了，咱关闭连接吧。”
服务端：“收到，我看看我这边有木有数据了。”
服务端：“兄弟，我这边也没数据要传你了，咱可以关闭连接了。”
客户端：“好嘞。”
7.浏览器解析渲染页面
浏览器加载解析HTML,CSS,JS,图片，视频等，最后渲染页面展示给用户。
解析
浏览器通过解析HTML，生成DOM树，解析CSS，生成CSS规则树，然后通过DOM树和CSS规则树生成渲染树。渲染树与DOM树不同，渲染树中并没有head、display为none等不必显示的节点。
要注意的是，浏览器的解析过程并非是串连进行的，比如在解析CSS的同时，可以继续加载解析HTML，但在解析执行JS脚本时，会停止解析后续HTML，这就会出现阻塞问题
渲染
根据渲染树布局，计算CSS样式，即每个节点在页面中的大小和位置等几何信息。HTML默认是流式布局的，CSS和js会打破这种布局，改变DOM的外观样式以及大小和位置。这时就要提到两个重要概念：replaint和reflow。
replaint：屏幕的一部分重画，不影响整体布局，比如某个CSS的背景色变了，但元素的几何尺寸和位置不变。
reflow： 意味着元件的几何尺寸变了，我们需要重新验证并计算渲染树。是渲染树的一部分或全部发生了变化。这就是Reflow，或是Layout。
所以我们应该尽量减少reflow和replaint，我想这也是为什么现在很少有用table布局的原因之一。
主要参考转载：
网友评论