写在前面
　 　今天是正式开始学习Web前端的第一天，之前也多多少少看过一些 关于前端的东西，但是很多地方没有一点头绪，在不相关的工作中来回切 换，难以专注做一件事的感觉很是头疼。不过，既然生活的本质就是杂 乱，还是习惯才好。急于求成是年轻而又躁动不安的内心诉求，在我这种新手身上表现的极为明显，安安静静的坐下来，在这个燥热的环境下尤为可贵。点滴记录，只为重新开始。
PS:文中所写均为学习记录，不对的地方欢迎指正。

首先名词解析

url:全球统一定位符；我理解为，互联网上任何一个资源都有他唯一的身份证。

DNS:域名解析系统。我理解为，可以将域名翻译成IP号。

1.域名解析

当我们用浏览器输入 类似于：www.baidu.com 按下回车时，域名解析就开始了。这一步仅仅是查找相应的IP地址。

步骤：浏览器缓存--系统缓存--路由缓存--运营商缓存--根域名....

类似于这样一个过程。我理解为这一步仅仅是为了得到对应的IP。

2.建立TCP连接

这个过程涉及到三次握手：

1. 客户端向服务器发出连接报文
2. 服务器收到请求连接的报文，并进行回复。
3. 客户端收到服务端的回复确认报文，再次进行确认。

Q: 为什么要进行三次握手而不是两次？
A:现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

ps:此部分内容也不是特别容易理解清楚，就暂时先有个印象，不知道这种学习方法是不是正确？

3.发起HTTP请求

请求方法：

• GET:获取资源
• POST:传输实体主体
• HEAD:获取报文首部
• PUT：传输文件
• DELETE:删除文件
• OPTIONS:询问支持的方法
• TRACE:追踪路径

请求报文

4.网站处理

浏览器处理这点也仍旧不好理解，还是先贴图吧。以后慢慢理解。感觉就是前、后端工作中的内容。结果就是根据请求客户端请求发出响应，客户端得到响应结果。

MVC模型

5.浏览器处理

浏览器接受发来的html文件,根据这些来构建DOM树，在解析到外部的css和js文件时，向服务器发起请求下载资源，若是下载css文件，则解析器会在下载的同时继续解析后面的html来构建DOM树，则在下载js文件和执行它时，解析器会停止对html的解析。这便出现了js阻塞问题。

浏览器解析的CSS文件，构成CSSOM树，它和DOM树一同构成渲染树。

解析过程：

• HTML字符串被浏览器接受后被一句句读取解析
• 解析到link 标签后重新发送请求获取css；解析到 script标签后发送请求获取 js，并执行代码
• 解析到img 标签后发送请求获取图片资源

绘制过程：

• 浏览器根据 HTML 和 CSS 计算得到渲染树，绘制到屏幕上，js 会被执行
  解析顺序：

• 浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。

• JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。

• 浏览器在解析过程中，如果遇到请求外部资源时请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

浏览器布局和绘制

• 布局：计算出每一个渲染对象的大小和位置。
• 绘制：每个像素信息绘制在屏幕上。
  ** 布局肯定比绘制成本高 **

最后再抄一张图

减少rpaint和reflow的方法

写在后面
这篇文章大多部分我自己仍旧不是很理解，但是基本了解到url到页面展现的一个过程，这些东西只能在以后的学习中慢慢的去熟悉。

参考文章：
浏览器中输入url后发生了什么

url输入到页面展现的过程简述