-先进行了一个简单的自我介绍,主要介绍了一下本身的工做经历和一些技术栈css
上来就放大招,这个题可深可浅,我整理了一下答案html
当咱们在web浏览器的地址栏中输入: www.baidu.com,而后回车,到底发生了什么html5
1.对www.baidu.com这个网址进行DNS域名解析,获得对应的IP地址java
2.根据这个IP,找到对应的服务器,发起TCP的三次握手webpack
3.创建TCP链接后发起HTTP请求nginx
4.服务器响应HTTP请求,浏览器获得html代码web
5.浏览器解析html代码,并请求html代码中的资源(如js、css图片等)(先获得html代码,才能去找这些资源)浏览器
6.浏览器对页面进行渲染呈现给用户缓存
注:服务器
DNS域名解析采用的是递归查询的方式,过程是,先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级,这样递归查找以后,找到了,给咱们的web浏览器
为何HTTP协议要基于TCP来实现? TCP是一个端到端的可靠的面相链接的协议,HTTP基于传输层TCP协议不用担忧数据传输的各类问题(当发生错误时,会重传)
最后一步浏览器是如何对页面进行渲染的?
a: 解析html文件构成 DOM树,
b: 解析CSS文件构成渲染树,
c: 边解析,边渲染 ,
d: JS 单线程运行,JS有可能修改DOM结构,意味着JS执行完成前,后续全部资源的下载是没有必要的,因此JS是单线程,会阻塞后续资源下载
a)首先会搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存)
b)若是浏览器自身的缓存里面没有找到,那么浏览器会搜索系统自身的DNS缓存
c)若是尚未找到,那么尝试从 hosts文件里面去找
d)在前面三个过程都没获取到的状况下,就递归地去域名服务器去查找,具体过程以下
拿到域名对应的IP地址以后,User-Agent(通常指浏览器)会以一个随机端口(1024<端口<65535)向服务器的WEB程序(经常使用的有httpd,nginx)等的80端口。这个链接请求(原始的http请求通过TCP/IP4层模型的层层封包)到达服务器端后(这中间有各类路由设备,局域网内除外),进入到网卡,而后是进入到内核的TCP/IP协议栈(用于识别链接请求,解封包,一层一层的剥开),还有可能要通过Netfilter防火墙(属于内核的模块)的过滤,最终达到WEB程序,最终创建了TCP/IP的链接
HTTP请求报文由三部分组成:请求行,请求头和请求正文
请求行:用于描述客户端的请求方式,请求的资源名称以及使用的HTTP协议的版本号(例:GET/books/java.html HTTP/1.1)
请求头:用于描述客户端请求哪台主机,以及客户端的一些环境信息等
注:这里提一个请求头 Connection,Connection设置为 keep-alive用于说明 客户端这边设置的是,本次HTTP请求以后并不须要关闭TCP链接,这样可使下次HTTP请求使用相同的TCP通道,节省TCP创建链接的时间
请求正文:当使用POST, PUT等方法时,一般须要客户端向服务器传递数据。这些数据就储存在请求正文中(GET方式是保存在url地址后面,不会放到这里)
HTTP响应也由三部分组成:状态码,响应头和实体内容
状态码:状态码用于表示服务器对请求的处理结果
列举几种常见的:200(没有问题) 302(要你去找别人) 304(要你去拿缓存) 307(要你去拿缓存) 403(有这个资源,可是没有访问权限) 404(服务器没有这个资源) 500(服务器这边有问题)
若干响应头:响应头用于描述服务器的基本信息,以及客户端如何处理数据
实体内容:服务器返回给客户端的数据
注:html资源文件应该不是经过 HTTP响应直接返回去的,应该是经过nginx经过io操做去拿到的吧
浏览器拿到html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每一个浏览器的线程数不同),这是时候就用上 keep-alive特性了,创建一次HTTP链接,能够请求多个资源,下载资源的顺序就是按照代码里面的顺序,可是因为每一个资源大小不同,而浏览器又是多线程请求请求资源,因此这里显示的顺序并不必定是代码里面的顺序。
最后,浏览器利用本身内部的工做机制,把请求的静态资源和html代码进行渲染,渲染以后呈现给用户
浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树,而后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在,这些都须要浏览器去计算其位置和大小等,这个过程称为relow;当盒模型的位置,大小以及其余属性,如颜色,字体,等肯定下来以后,浏览器便开始绘制内容,这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是很是消耗性能的,尤为是在移动设备上,它会破坏用户体验,有时会形成页面卡顿。因此咱们应该尽量少的减小reflow和repain。
JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行,JS有可能修改DOM结构,意味着JS执行完成前,后续全部资源的下载是没有必要的,因此JS是单线程,会阻塞后续资源下载
域名解析 --> 发起TCP的3次握手 --> 创建TCP链接后发起http请求 --> 服务器响应http请求,浏览器获得html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等) --> 浏览器对页面进行渲染呈现给用户
ps: 反正我是凉了 一会儿没想起来底层的东西,答非所问
当一个浏览器接收到从服务器发来的html页面,在渲染并呈现到屏幕上以前,有不少步骤要作。浏览器渲染页面须要作的一系列行为被称做“关键渲染路径(Critical Rendering Path 简称CRP)”。
CRP
的知识对于如何提高网站性能是至关有用的。CRP
有6个步骤:
具体步骤 请 移驾 www.jianshu.com/p/e53141edc…
一、把<script>
标签放在<head>
中意味着必须等到所有的js代码都下载解析和执行完成之后,才开始展示页面内容,为避免这个问题通常把js代码所有放在<body>
元素内容后面
二、script标签不带defer和async属性:同步模式,脚本获取和执行都是同步,页面会被阻塞,浏览器都会按照<script>
元素在页面中出现的前后顺序对他们依次进行解析
同步模式:又称阻塞模式,会阻止浏览器的后续执行,中止后续解析,只有当前加载完成才能进行下一步操做。
三、async属性:html5的新属性,只适合用于外部脚本文件,异步模式
经过createElement建立的script标签其属性async默认为true
四、defer属性:异步模式,只适合外部脚本文件,会被延迟到整个页面都解析完毕后再运行,脚本加载不阻塞页面的解析,同时带有defer的脚本彼此之间,能保证其执行顺序
补充:
<script>
标签打开defer或async属性,脚本就会异步加载。渲染引擎遇到这一行命令,就会开始下载外部脚本,但不会等它下载和执行,而是直接执行后面的命令。
defer
与async
的区别是:defer
要等到整个页面在内存中正常渲染结束(DOM 结构彻底生成,以及其余脚本执行完成),才会执行;async
一旦下载完,渲染引擎就会中断渲染,执行这个脚本之后,再继续渲染。一句话,defer
是“渲染完再执行”,async
是“下载完就执行”。另外,若是有多个defer
脚本,会按照它们在页面出现的顺序加载,而多个async
脚本是不能保证加载顺序的。
无需多言了吧,仍是贴的 细则地址吧 www.runoob.com/css/css-box…
Entry: 入口, webpack执行构建的第一步将从Entry开始,可抽象成输入
Module: 模块,在webpcak中一切皆模块,一个模块对应一个文件。webpack会从配置的Entry开始递归找出全部依赖的模块。
Chunk: 代码块,一个Chunk由多个模块组合而成,用于代码合并于分割
Loader: 模块转换器,用于将模块的原内容按照需求转换成新内容。cookies
Plugin: 扩展插件,在webpcak构建流程中的特定时机注入扩展逻辑,来改变构建结果或作咱们想要的事情
Outout: 输出结果,再webpack通过一些列处理并得出最终想要的代码后输出结果
webpcak在启动后会从Entry里配置的Module开始,递归解析Entry依赖的全部Module.每找到一个Module,就会根据配置的Loader去找出对应的转换规则,对Module进行转换后,再解析出当前Module依赖的Module。这些模块会以Entry为单位进行分组,一个Entry及其全部依赖的Module被分到一个组也就是一个Chunk.最后,webpack会将全部Chunk转换成文件输出。在整个流程中,webpack会在恰当的时机执行Plugin里定义的逻辑。
细则 : 移驾 webpack 官网: webpack.docschina.org/
讲一讲我的的一些见解,没什么特色就是聊聊,应该是摸摸你的底,经验什么的
讲了一下,我为什么学Typescript,和他的趋势,我的见解,这是一个知识帖就不作详细介绍了