一、应用层DNS解析域名
首先，浏览器会查找本地域名DNS缓存，不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）；若找到则返回响应的IP地址。若没找到则请求上级DNS服务器，直至找到或到根节点。（本机计算机找到其中一台解析域名的服务器(可能是.com)，如果没有找到对应的IP地址，那么就会去找根域名服务器，根域名服务器知道所有的子服务器，所以他肯定知道该域名所对应的IP地址在那个子服务器中，所以告诉第一次查询的服务器要他去另一台服务器上找，找到了，就将其返回给计算机，以后在有另一台计算机也通过这个域名访问，那么第一台服务器会有原来的域名IP地址的缓存，就不用去找根服务器了。）
DNS查找示意图
二、浏览器给web服务器发送一个HTTP请求
HTTP请求头信息图解
1、Request URL：浏览器给web服务器发送一个HTTP请求的完整地址
2、Request Method：http请求方法
3、Host：主机名 www.baidu.com
4、User-Agent：浏览器标识信息
5、Accept：能接收的数据类型有哪些
6、Accept-Language：表示用户希望优先想得到的版本，一次排列下去，先是中文，再是英文
7、Accept-Encoding：通知服务端可以发送的数据压缩格式
8、Cookie：浏览器端的一个技术，在服务器上记录用户信息，但是也会在浏览器中保存一份。
9、Connection：连接的方式，有两种，非持续连接和持续连接，非持续连接，一次请求/响应就对应一个TCP连接，接到了响应该连接就关闭，然后在发送请求就在建立TCP连接，持续连接就相反，这里使用的是持续连接
10、Referer：告诉服务器该请求是从哪个页面链接过来的，服务器基此可以获得一些信息用于处理。
11、Referrer Policy：无论是同源请求还是非同源请求，都发送完整的 URL（移除参数信息之后）作为引用地址。
三、传输层TCP传输报文
1、三次握手机制
一开始客户端和服务端都市关闭状态，但是在某个时刻，客户端需要和服务端进行通信，此时双方都会各自准备好端口，服务器段的端口会处于监听状态，等待客户端的连接。客户端可会知道自己的端口号，和目的进程的端口号，这样才能发起请求。
三次握手图解
第一次握手：客户端想与服务器进行连接了，所以状态变为主动打开，同时发送一个连接请求报文给服务器段SYN=1，并且会携带x个字节过去。发送完请求连接报文后，客户端的状态就变为了SYN_SENT，可以说这个状态是等待发送确认(为了发送第三次握手时的确认包)
第二次握手：服务端接收到连接请求报文后，从LSTTEN状态变为被动打开状态，然后给客户端返回一个报文。这个报文有两层意思，一是确认报文，二可以达到告诉客户端，我也打开连接了。发完后，变为SYN_RCVD状态(也可以说是等待接受确认状态，接受客户端发过来的确认包)
第三次握手：客户端得到服务器端的确认和知道服务器端也已经准备好了连接后，还会发一个确认报文到服务器端，告诉服务器端，我接到了你发送的报文，接下来就让我们两个进行连接了。客户端发送完确认报文后，进入ESTABLISHED，而服务器接到了，也变为ESTABLISHED
进入到ESTABLISHED状态后，连接就已经完成了，可以进行通信了。
问题：为什么需要第三次握手，有前面两次不就已经可以了吗？
假设没有第三次握手，客户端发送一个连接请求报文过去，但是因为网络延迟，在等待了一个超时时间后，客户端就会在重新发一个请求连接报文过去，然后正常的进行，服务器端发回一个确认连接报文，然后就开始通讯，通讯结束后，那个第一次因为网络延迟的请求连接报文到了服务器端，服务器端不知道这个报文已经失效，也发回了一个确认连接报文，客户端接收后，发现自己并没有发送连接请求(因为超时了，所以就认为自己没有发)，所以对这个确认连接请求就什么也不做，但是此时服务端不这么认为，他认为i连接已经建立了，就一直打开着等待客户端传数据过来，这就造成了极大的浪费。如果有了第三次握手，那么客户端就可以通知服务器了。所以第三次握手也很重要。（ 第三次握手是确保双方能通信顺畅，没有网络拥堵的情况 ）
四、服务器响应请求
经过前面的6个步骤，服务器收到了我们的请求，也处理我们的请求，到这一步，它会把它的处理结果返回，也就是返回一个HTPP响应。
经过前面几个步骤，服务器已经接受客户端发出的请求，也处理我们的请求，到这一步，服务端会将运算结果返回至客户端，即返回一个http请求。浏览器的返回状态可以根据状态代码判别，第一个数字定义了响应的类别，且有五种可能取值。如下：
1xx：信息性状态码，表示服务器已接收了客户端请求，客户端可继续发送请求。
100 Continue
101 Switching Protocols
2xx：成功状态码，表示服务器已成功接收到请求并进行处理。
200 OK 表示客户端请求成功
204 No Content 成功，但不返回任何实体的主体部分
206 Partial Content 成功执行了一个范围（Range）请求
3xx：重定向状态码，表示服务器要求客户端重定向。
301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL
302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源
303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源
304 Not Modified 服务器内容没有更新，可以直接读取浏览器缓存
307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET，但实际使用时并不一定，307则更多浏览器可能会遵循这一标准，但也依赖于浏览器具体实现
4xx：客户端错误状态码，表示客户端的请求有非法内容。
400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解
401 Unauthonzed 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
403 Forbidden 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
404 Not Found 请求的资源不存在，例如，输入了错误的URL
5xx：服务器错误状态码，表示服务器未能正常处理客户端的请求而出现意外错误。
500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求
503 Service Unavailable 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常
五、浏览器显示HTML
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了，浏览器是如何把页面呈现在屏幕上的呢？不同浏览器可能解析的过程不太一样，这里我们只介绍webkit的渲染过程，下图对应的就是WebKit渲染的过程，这个过程包括：
解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树
浏览器在解析html文件时，会”自上而下“加载，并在加载过程中进行解析渲染。在解析过程中，如果遇到请求外部资源时，如图片、外链的CSS、iconfont等，请求过程是异步的，并不会影响html文档进行加载。
DOM渲染流程
解析过程中，浏览器首先会解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。
DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。
页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
当文档加载过程中遇到js文件，html文档会挂起渲染（加载解析渲染同步）的线程，不仅要等待文档中js文件加载完毕，还要等待解析执行完毕，才可以恢复html文档的渲染线程。因为JS有可能会修改DOM，最为经典的document.write，这意味着，在JS执行完成前，后续所有资源的下载可能是没有必要的，这是js阻塞后续资源下载的根本原因。所以我明平时的代码中，js是放在html文档末尾的。
--------------------------------------------------------------------分割线------------------------------------------------------------------------------------------
大致的过程应该就这么多，更多的细节没有去扩展了；写这边文章主要还是出去面试的时候被别人问的太丢面儿，故而详细的去网上了解查询了下，方便自己以后的温故知新。文中许有部分不正确的地方，还望不吝指出。
网友评论