在浏览器中输入一个url,都经历了什么?

简单来说:
客户端获取URL - > DNS解析(如果有nginx,解析到的ip地址是 负载均衡器的ip地址) - > TCP连接 - >发送HTTP请求 - >服务器处理请求(tomcat/apache/Node.Js) - >返回报文 - >浏览器解析渲染页面 - > TCP断开连接

如果有CDN的时候:

1. 当用户点击网站页面上的内容URL，先经过本地DNS系统解析，如果本地DNS服务器没有相应域名的缓存，则本地DNS系统会将域名的解析权交给CNAME指向的CDN专用DNS服务器。
2. CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回给用户。
3. 用户向CDN的全局负载均衡设备发起URL访问请求。
4. CDN全局负载均衡设备根据用户IP地址，以及用户请求的URL，选择一台用户所属区域的区域负载均衡设备，并将请求转发到此设备上。
5. 基于以下这些条件的综合分析之后，区域负载均衡设备会选择一个最优的缓存服务器节点，并从缓存服务器节点处得到缓存服务器的IP地址，最终将得到的IP地址返回给全局负载均衡设备：
6. 根据用户IP地址，判断哪一个边缘节点距用户最近；
7. 根据用户所请求的URL中携带的内容名称，判断哪一个边缘节点上有用户所需内容；
8. 查询各个边缘节点当前的负载情况，判断哪一个边缘节点尚有服务能力。
9. 全局负载均衡设备把服务器的IP地址返回给用户。
10. 用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器将内容拉到本地。

众所周知，打开一个网页的过程中，浏览器会因页面上的css/js/image等静态资源会多次发起连接请求，所以我们暂且把这个网页加载过程分成两部分：

1. html(jsp/php/aspx) 页面加载(假设存在简单的Nginx负载均衡)
2. css/js/image等 网页静态资源加载(假设使用CDN)

1.DNS解析

浏览器首先搜索浏览器自身缓存的DNS记录。
或许很多人不知道，浏览器自身也带有一层DNS缓存。Chrome 缓存1000条DNS解析结果，缓存时间大概在一分钟左右。
（Chrome浏览器通过输入：chrome://net-internals/#dns 打开DNS缓存页面）
如果浏览器缓存中没有找到需要的记录或记录已经过期，则搜索hosts文件和操作系统缓存。
在Windows操作系统中，可以通过 ipconfig /displaydns 命令查看本机当前的缓存。
通过hosts文件，你可以手动指定一个域名和其对应的IP解析结果，并且该结果一旦被使用，同样会被缓存到操作系统缓存中。
Windows系统的hosts文件在%systemroot%\system32\drivers\etc下，linux系统的hosts文件在/etc/hosts下。

3. 如果在hosts文件和操作系统缓存中没有找到需要的记录或记录已经过期，则向域名解析服务器发送解析请求。
   其实第一台被访问的域名解析服务器就是我们平时在设置中填写的DNS服务器一项，当操作系统缓存中也没有命中的时候，系统会向DNS服务器正式发出解析请求。这里是真正意义上开始解析一个未知的域名。
   一般一台域名解析服务器会被地理位置临近的大量用户使用（特别是ISP的DNS），一般常见的网站域名解析都能在这里命中。
4. 如果域名解析服务器也没有该域名的记录，则开始递归+迭代解析。
   这里我们举个例子，如果我们要解析的是mail.google.com。

首先我们的域名解析服务器会向根域服务器（全球只有13台）发出请求。显然，仅凭13台服务器不可能把全球所有IP都记录下来。所以根域服务器记录的是com域服务器的IP、cn域服务器的IP、org域服务器的IP……。如果我们要查找.com结尾的域名，那么我们可以到com域服务器去进一步解析。所以其实这部分的域名解析过程是一个树形的搜索过程。
根域服务器告诉我们com域服务器的IP。
接着我们的域名解析服务器会向com域服务器发出请求。根域服务器并没有mail.google.com的IP，但是却有google.com域服务器的IP。
接着我们的域名解析服务器会向google.com域服务器发出请求。…
如此重复，直到获得mail.google.com的IP地址。
为什么是递归：问题由一开始的本机要解析mail.google.com变成域名解析服务器要解析mail.google.com，这是递归。
为什么是迭代：问题由向根域服务器发出请求变成向com域服务器发出请求再变成向google.com域发出请求，这是迭代。

5. 获取域名对应的IP后，一步步向上返回，直到返回给浏览器。

2.发送TCP请求

浏览器会选择一个大于1024的本机端口向目标IP地址的80端口发起TCP连接请求。经过标准的TCP握手流程，建立TCP连接。
客户端：
（应用层开始）获取URL，通过负责域名解析的DNS服务获取网址的IP地址，根据HTTP协议生成HTTP请求报文（应用层结束）
（传输层开始）根据TCP协议连接从客户端到服务端（通过三次握手）客户端给服务端发送一个带SYN（同步）标志的数据包给客户端，然后客户端接收到信息再给客户端回传一个带有SYN / ACK（确认）标志的数据包以示传达确认信息，客户求最后端的再传送一个带ACK标志的数据包，代表“握手”结束，连接成功.TCP协议在把请求报文按序号分割成多个报文段（传输层结束）
（网络层开始）根据IP协议（传输数据），ARP协议（获取MAC地址），OSPF协议（选择最优路径），搜索服务器地址，一边中转一边传输数据（网络层结束）
（数据链路层开始）到达后通过数据链路层，物理层负责0,1比特流与物理设备电压高低，光的闪灭之间的互换。数据链路层负责将0,1序列划分为数据帧从一个节点传输到临近的另一个节点，这些节点是通过MAC来唯一标识的（MAC，物理地址，一个中主机会有一个MAC地址）。 （数据链路层结束）
服务端
通过数据链路层 - >通过网络层 - >再通过传输层（根据TCP协议接收请求报文并重组报文段） - >再通过应用层（通过HTTP协议对请求的内容进行处理） - >再通过应用层 - >传输层 - >网络层 - >数据链路层 - >到达客户端
客户端
通过数据链路层 - >网络层 - >传输层（根据TCP协议接收响应报文并重组） - >应用层（HTTP协议对响应进行处理） - >浏览器渲染页面 - >断开连接协议四次挥手）
四次挥手
主动方发送标志位：（ACK + FIN）+（发送序号= 200 +确认序号= 500）第一次挥手
被动方接收后发送标志位：ACK +（发送序号=主动方确认序号500 +确认序号=主动方发送序号+1201）第二次挥手
标志位：（ACK + FIN）+（发送序号=主动方确认序号+1 501）第三次挥手
主动方接收后发送标志位：（ACK）+（发送序号=被动方的确认序号201 +确认序号=被动方的发生序号+1502）

3.发送HTTP请求

其实这部分又可以称为前端工程师眼中的HTTP，它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。

请求行
格式如下:
Method Request-URL HTTP-Version CRLF
eg: GET index.html HTTP/1.1

请求报头
请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。
PS: 客户端不一定特指浏览器，有时候也可使用Linux下的CURL命令以及HTTP客户端测试工具等。
常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。
上图是使用Chrome开发者工具截取的对百度的HTTP请求以及响应报文，从图中可以看出，请求报头中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息，Accept-Encoding与Accept类似，它用于指定接受的编码方式。Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP连接建立的时间。
请求正文
当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息，例如: 现在的Web应用通常采用Rest架构，请求的数据格式一般为json。这时就需要设置Content-Type: application/json。
服务器处理请求并返回HTTP报文
自然而然这部分对应的就是后端工程师眼中的HTTP。后端从在固定的端口接收到TCP报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，我使用过的Web服务器有Tomcat, Jetty和Netty等等。
HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。
状态码
状态码是由3位数组成，第一个数字定义了响应的类别，且有五种可能取值:
HTTP缓存
响应报头
常见的响应报头字段有: Server, Connection…。
响应报文
服务器返回给浏览器的文本信息，通常HTML, CSS, JS, 图片等文件就放在这一部分。

4.负载均衡

什么是负载均衡？当一台服务器无法支持大量的用户访问时，将用户分摊到两个或多个服务器上的方法叫负载均衡。
什么是Nginx？Nginx是一款面向性能设计的HTTP服务器，相较于Apache、lighttpd具有占有内存少，稳定性高等优势。
负载均衡的方法很多，Nginx负载均衡、LVS-NAT、LVS-DR等。这里，我们以简单的Nginx负载均衡为例。关于负载均衡的多种方法详情大家可以Google一下。
Nginx有4种类型的模块：core、handlers、filters、load-balancers。
我们这里讨论其中的2种，分别是负责负载均衡的模块load-balancers和负责执行一系列过滤操作的filters模块。

1. 一般，如果我们的平台配备了负载均衡的话，前一步DNS解析获得的IP地址应该是我们Nginx负载均衡服务器的IP地址。所以，我们的浏览器将我们的网页请求发送到了Nginx负载均衡服务器上。
2. Nginx根据我们设定的分配算法和规则，选择一台后端的真实Web服务器，与之建立TCP连接、并转发我们浏览器发出去的网页请求。
   Nginx默认支持 RR轮转法 和 ip_hash法 这2种分配算法。
   前者会从头到尾一个个轮询所有Web服务器，而后者则对源IP使用hash函数确定应该转发到哪个Web服务器上，也能保证同一个IP的请求能发送到同一个Web服务器上实现会话粘连。
   也有其他扩展分配算法，如：
   fair：这种算法会选择相应时间最短的Web服务器
   url_hash：这种算法会使得相同的url发送到同一个Web服务器
3. Web服务器收到请求，产生响应，并将网页发送给Nginx负载均衡服务器。
4. Nginx负载均衡服务器将网页传递给filters链处理，之后发回给我们的浏览器。
   而Filter的功能可以理解成先把前一步生成的结果处理一遍，再返回给浏览器。比如可以将前面没有压缩的网页用gzip压缩后再返回给浏览器。

5.渲染页面

1. 浏览器根据页面内容，生成DOM Tree。根据CSS内容，生成CSS Rule Tree(规则树)。调用JS执行引擎执行JS代码。
2. 根据DOM Tree和CSS Rule Tree生成Render Tree(呈现树)
3. 根据Render Tree渲染网页
   浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
   JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。但是又存在某些任务比较耗时，如IO读写等，所以需要一种机制可以先执行排在后面的任务，这就是：同步任务(synchronous)和异步任务(asynchronous)。JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务，异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行，形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件；脚本运行时先依次运行执行栈，然后会从任务队列里提取事件，运行任务队列中的任务，这个过程是不断重复的，所以又叫做事件循环(Event loop)。
   浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等。浏览器将重复1-6过程下载该资源。请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

6.网页静态加载

什么是CDN？如果我在广州访问杭州的淘宝网，跨省的通信必然造成延迟。如果淘宝网能在广东建立一个服务器，静态资源我可以直接从就近的广东服务器获取，必然能提高整个网站的打开速度，这就是CDN。CDN叫内容分发网络，是依靠部署在各地的边缘服务器，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度。
接下来的流程就是浏览器根据url加载该url下的图片内容。本质上是浏览器重新开始第一部分的流程，所以这里不再重复阐述。区别只是负责均衡服务器后端的服务器不再是应用服务器，而是提供静态资源的服务器。