对HTML语义化的了解

语义化是指依据内容的结构化（内容语义化），抉择适合的标签（代码语义化）。艰深来讲就是用正确的标签做正确的事件。

语义化的长处如下：

  • 对机器敌对，带有语义的文字表现力丰盛，更适宜搜索引擎的爬虫爬取无效信息，有利于SEO。除此之外，语义类还反对读屏软件，依据文章能够主动生成目录；
  • 对开发者敌对，应用语义类标签加强了可读性，构造更加清晰，开发者能清晰的看出网页的构造，便于团队的开发与保护。

常见的语义化标签：

<header></header>  头部<nav></nav>  导航栏<section></section>  区块（有语义化的div）<main></main>  次要区域<article></article>  次要内容<aside></aside>  侧边栏<footer></footer>  底部

画一条0.5px的线

  • 采纳transform: scale()的形式，该办法用来定义元素的2D 缩放转换：
transform: scale(0.5,0.5);
  • 采纳meta viewport的形式
<meta name="viewport" content="width=device-width, initial-scale=0.5, minimum-scale=0.5, maximum-scale=0.5"/>

这样就能缩放到原来的0.5倍，如果是1px那么就会变成0.5px。viewport只针对于挪动端，只在挪动端上能力看到成果

行内元素有哪些？块级元素有哪些？ 空(void)元素有那些？

  • 行内元素有：a b span img input select strong；
  • 块级元素有：div ul ol li dl dt dd h1 h2 h3 h4 h5 h6 p；

空元素，即没有内容的HTML元素。空元素是在开始标签中敞开的，也就是空元素没有闭合标签：

  • 常见的有：<br>、<hr>、<img>、<input>、<link>、<meta>；
  • 鲜见的有：<area>、<base>、<col>、<colgroup>、<command>、<embed>、<keygen>、<param>、<source>、<track>、<wbr>。

Canvas和SVG的区别

（1）SVG： SVG可缩放矢量图形（Scalable Vector Graphics）是基于可扩大标记语言XML形容的2D图形的语言，SVG基于XML就意味着SVG DOM中的每个元素都是可用的，能够为某个元素附加Javascript事件处理器。在 SVG 中，每个被绘制的图形均被视为对象。如果 SVG 对象的属性发生变化，那么浏览器可能主动重现图形。

其特点如下：

  • 不依赖分辨率
  • 反对事件处理器
  • 最适宜带有大型渲染区域的应用程序（比方谷歌地图）
  • 复杂度高会减慢渲染速度（任何适度应用 DOM 的利用都不快）
  • 不适宜游戏利用

（2）Canvas： Canvas是画布，通过Javascript来绘制2D图形，是逐像素进行渲染的。其地位产生扭转，就会从新进行绘制。

其特点如下：

  • 依赖分辨率
  • 不反对事件处理器
  • 弱的文本渲染能力
  • 可能以 .png 或 .jpg 格局保留后果图像
  • 最适宜图像密集型的游戏，其中的许多对象会被频繁重绘

注：矢量图，也称为面向对象的图像或绘图图像，在数学上定义为一系列由线连贯的点。矢量文件中的图形元素称为对象。每个对象都是一个自成一体的实体，它具备色彩、形态、轮廓、大小和屏幕地位等属性。

常见的图片格式及应用场景

（1）BMP，是无损的、既反对索引色也反对间接色的点阵图。这种图片格式简直没有对数据进行压缩，所以BMP格局的图片通常是较大的文件。

（2）GIF是无损的、采纳索引色的点阵图。采纳LZW压缩算法进行编码。文件小，是GIF格局的长处，同时，GIF格局还具备反对动画以及通明的长处。然而GIF格局仅反对8bit的索引色，所以GIF格局实用于对色调要求不高同时须要文件体积较小的场景。

（3）JPEG是有损的、采纳间接色的点阵图。JPEG的图片的长处是采纳了间接色，得益于更丰盛的色调，JPEG非常适合用来存储照片，与GIF相比，JPEG不适宜用来存储企业Logo、线框类的图。因为有损压缩会导致图片含糊，而间接色的选用，又会导致图片文件较GIF更大。

（4）PNG-8是无损的、应用索引色的点阵图。PNG是一种比拟新的图片格式，PNG-8是十分好的GIF格局替代者，在可能的状况下，应该尽可能的应用PNG-8而不是GIF，因为在雷同的图片成果下，PNG-8具备更小的文件体积。除此之外，PNG-8还反对透明度的调节，而GIF并不反对。除非须要动画的反对，否则没有理由应用GIF而不是PNG-8。

（5）PNG-24是无损的、应用间接色的点阵图。PNG-24的长处在于它压缩了图片的数据，使得同样成果的图片，PNG-24格局的文件大小要比BMP小得多。当然，PNG24的图片还是要比JPEG、GIF、PNG-8大得多。

（6）SVG是无损的矢量图。SVG是矢量图意味着SVG图片由直线和曲线以及绘制它们的办法组成。当放大SVG图片时，看到的还是线和曲线，而不会呈现像素点。SVG图片在放大时，不会失真，所以它适宜用来绘制Logo、Icon等。

（7）WebP是谷歌开发的一种新图片格式，WebP是同时反对有损和无损压缩的、应用间接色的点阵图。从名字就可以看进去它是为Web而生的，什么叫为Web而生呢？就是说雷同品质的图片，WebP具备更小的文件体积。当初网站上充斥了大量的图片，如果可能升高每一个图片的文件大小，那么将大大减少浏览器和服务器之间的数据传输量，进而升高拜访提早，晋升拜访体验。目前只有Chrome浏览器和Opera浏览器反对WebP格局，兼容性不太好。

  • 在无损压缩的状况下，雷同品质的WebP图片，文件大小要比PNG小26%；
  • 在有损压缩的状况下，具备雷同图片精度的WebP图片，文件大小要比JPEG小25%~34%；
  • WebP图片格式反对图片透明度，一个无损压缩的WebP图片，如果要反对透明度只须要22%的分外文件大小。

什么是原型什么是原型链?

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <meta http-equiv="X-UA-Compatible" content="IE=edge">    <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>Document</title></head><body></body><script>    function Person () {    }    var person  = new Person();    person.name = 'Kevin';    console.log(person.name) // Kevin    // prototype    function Person () {    }    Person.prototype.name = 'Kevin';    var person1 = new Person();    var person2 = new Person();    console.log(person1.name)// Kevin    console.log(person2.name)// Kevin    // __proto__    function Person () {    }    var person = new Person();    console.log(person.__proto__ === Person.prototype) // true    //constructor    function Person() {    }    console.log(Person === Person.prototype.constructor) // true    //综上所述    function Person () {    }    var person = new Person()    console.log(person.__proto__ == Person.prototype) // true    console.log(Person.prototype.constructor == Person) // true    //顺便学习一下ES5得办法,能够取得对象得原型    console.log(Object.getPrototypeOf(person) === Person.prototype) // true    //实例与原型    function Person () {    }    Person.prototype.name = 'Kevin';    var person = new Person();    person.name = 'Daisy';    console.log(person.name) // Daisy    delete person.name;    console.log(person.name) // Kevin    //原型得原型    var obj = new Object();    obj.name = 'Kevin',    console.log(obj.name) //Kevin     //原型链     console.log(Object.prototype.__proto__ === null) //true     // null 示意"没用对象" 即该处不应该有值     // 补充     function Person() {     }     var person = new Person()     console.log(person.constructor === Person) // true     //当获取person.constructor时，其实person中并没有constructor属性,当不能读取到constructor属性时,会从person的原型     //也就是Person.prototype中读取时,正好原型中有该属性,所以     person.constructor === Person.prototype.constructor     //__proto__     //其次是__proto__，绝大部分浏览器都反对这个非标准的办法拜访原型，然而它并不存在于Person.prototype中，实际上，它     // 是来自与Object.prototype,与其说是一个属性，不如说是一个getter/setter,当应用obj.__proto__时，能够了解成返回了     // Object.getPrototypeOf(obj)     总结：          1、当一个对象查找属性和办法时会从本身查找,如果查找不到则会通过__proto__指向被实例化的构造函数的prototype     2、隐式原型也是一个对象,是指向咱们构造函数的原型     3、除了最顶层的Object对象没有__proto_，其余所有的对象都有__proto__,这是隐式原型     4、隐式原型__proto__的作用是让对象通过它来始终往上查找属性或办法，直到找到最顶层的Object的__proto__属性，它的值是null,这个查找的过程就是原型链</script></html>

ES6新个性

1.ES6引入来严格模式    变量必须申明后在应用    函数的参数不能有同名属性, 否则报错    不能应用with语句 (说实话我根本没用过)    不能对只读属性赋值, 否则报错    不能应用前缀0示意八进制数,否则报错 (说实话我根本没用过)    不能删除不可删除的数据, 否则报错    不能删除变量delete prop, 会报错, 只能删除属性delete global[prop]    eval不会在它的外层作用域引入变量    eval和arguments不能被从新赋值    arguments不会主动反映函数参数的变动    不能应用arguments.caller (说实话我根本没用过)    不能应用arguments.callee (说实话我根本没用过)    禁止this指向全局对象    不能应用fn.caller和fn.arguments获取函数调用的堆栈 (说实话我根本没用过)    减少了保留字（比方protected、static和interface）2.对于let和const新增的变量申明3.变量的解构赋值4.字符串的扩大    includes()：返回布尔值，示意是否找到了参数字符串。    startsWith()：返回布尔值，示意参数字符串是否在原字符串的头部。    endsWith()：返回布尔值，示意参数字符串是否在原字符串的尾部。5.数值的扩大    Number.isFinite()用来查看一个数值是否为无限的（finite）。    Number.isNaN()用来查看一个值是否为NaN。6.函数的扩大    函数参数指定默认值7.数组的扩大    扩大运算符8.对象的扩大    对象的解构9.新增symbol数据类型10.Set 和 Map 数据结构     ES6 提供了新的数据结构 Set。它相似于数组，然而成员的值都是惟一的，没有反复的值。 Set 自身是一个构造函数，用来生成 Set 数据结构。    Map它相似于对象，也是键值对的汇合，然而“键”的范畴不限于字符串，各种类型的值（包含对象）都能够当作键。11.Proxy    Proxy 能够了解成，在指标对象之前架设一层“拦挡”，外界对该对象的拜访    都必须先通过这层拦挡，因而提供了一种机制，能够对外界的拜访进行过滤和改写。    Proxy 这个词的原意是代理，用在这里示意由它来“代理”某些操作，能够译为“代理器”。    Vue3.0应用了proxy12.Promise    Promise 是异步编程的一种解决方案，比传统的解决方案——回调函数和事件——更正当和更弱小。    特点是：        对象的状态不受外界影响。        一旦状态扭转，就不会再变，任何时候都能够失去这个后果。13.async 函数     async函数对 Generator 函数的区别：    （1）内置执行器。    Generator 函数的执行必须靠执行器，而async函数自带执行器。也就是说，async函数的执行，与一般函数截然不同，只有一行。    （2）更好的语义。    async和await，比起星号和yield，语义更分明了。async示意函数里有异步操作，await示意紧跟在前面的表达式须要期待后果。    （3）失常状况下，await命令前面是一个 Promise 对象。如果不是，会被转成一个立刻resolve的 Promise 对象。    （4）返回值是 Promise。    async函数的返回值是 Promise 对象，这比 Generator 函数的返回值是 Iterator 对象不便多了。你能够用then办法指定下一步的操作。14.Class     class跟let、const一样：不存在变量晋升、不能反复申明...    ES6 的class能够看作只是一个语法糖，它的绝大部分性能    ES5 都能够做到，新的class写法只是让对象原型的写法更加清晰、更像面向对象编程的语法而已。15.Module    ES6 的模块主动采纳严格模式，不论你有没有在模块头部加上"use strict";。    import和export命令以及export和export default的区别

当在浏览器中输出 Google.com 并且按下回车之后产生了什么？

（1）解析URL： 首先会对 URL 进行解析，剖析所须要应用的传输协定和申请的资源的门路。如果输出的 URL 中的协定或者主机名不非法，将会把地址栏中输出的内容传递给搜索引擎。如果没有问题，浏览器会查看 URL 中是否呈现了非法字符，如果存在非法字符，则对非法字符进行本义后再进行下一过程。

（2）缓存判断： 浏览器会判断所申请的资源是否在缓存里，如果申请的资源在缓存里并且没有生效，那么就间接应用，否则向服务器发动新的申请。

（3）DNS解析： 下一步首先须要获取的是输出的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则应用，如果没有则向本地 DNS 服务器发动申请。本地 DNS 服务器也会先查看是否存在缓存，如果没有就会先向根域名服务器发动申请，取得负责的顶级域名服务器的地址后，再向顶级域名服务器申请，而后取得负责的权威域名服务器的地址后，再向权威域名服务器发动申请，最终取得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给申请的用户。用户向本地 DNS 服务器发动申请属于递归申请，本地 DNS 服务器向各级域名服务器发动申请属于迭代申请。

（4）获取MAC地址： 当浏览器失去 IP 地址后，数据传输还须要晓得目标主机 MAC 地址，因为应用层下发数据给传输层，TCP 协定会指定源端口号和目标端口号，而后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目标地址。而后将下发给数据链路层，数据链路层的发送须要退出通信单方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目标 MAC 地址须要分状况解决。通过将 IP 地址与本机的子网掩码相与，能够判断是否与申请主机在同一个子网里，如果在同一个子网里，能够应用 APR 协定获取到目标主机的 MAC 地址，如果不在一个子网里，那么申请应该转发给网关，由它代为转发，此时同样能够通过 ARP 协定来获取网关的 MAC 地址，此时目标主机的 MAC 地址应该为网关的地址。

（5）TCP三次握手： 上面是 TCP 建设连贯的三次握手的过程，首先客户端向服务器发送一个 SYN 连贯申请报文段和一个随机序号，服务端接管到申请后向服务器端发送一个 SYN ACK报文段，确认连贯申请，并且也向客户端发送一个随机序号。客户端接管服务器的确认应答后，进入连贯建设的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接管到确认后，也进入连贯建设状态，此时单方的连贯就建设起来了。

（6）HTTPS握手： 如果应用的是 HTTPS 协定，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送应用的协定的版本号、一个随机数和能够应用的加密办法。服务器端收到后，确认加密的办法，也向客户端发送一个随机数和本人的数字证书。客户端收到后，首先查看数字证书是否无效，如果无效，则再生成一个随机数，并应用证书中的公钥对随机数加密，而后发送给服务器端，并且还会提供一个后面所有内容的 hash 值供服务器端测验。服务器端接管后，应用本人的私钥对数据解密，同时向客户端发送一个后面所有内容的 hash 值供客户端测验。这个时候单方都有了三个随机数，依照之前所约定的加密办法，应用这三个随机数生成一把秘钥，当前单方通信前，就应用这个秘钥对数据进行加密后再传输。

（7）返回数据： 当页面申请发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接管到响应后，开始对 html 文件进行解析，开始页面的渲染过程。

（8）页面渲染： 浏览器首先会依据 html 文件构建 DOM 树，依据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建设好后，依据它们来构建渲染树。渲染树构建好后，会依据渲染树来进行布局。布局实现后，最初应用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示进去了。

（9）TCP四次挥手： 最初一步是 TCP 断开连接的四次挥手过程。若客户端认为数据发送实现，则它须要向服务端发送连贯开释申请。服务端收到连贯开释申请后，会通知应用层要开释 TCP 链接。而后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连贯曾经开释，不再接管客户端发的数据了。然而因为 TCP 连贯是双向的，所以服务端仍旧能够发送数据给客户端。服务端如果此时还有没发完的数据会持续发送，结束后会向客户端发送连贯开释申请，而后服务端便进入 LAST-ACK 状态。客户端收到开释申请后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会继续 2MSL（最大段生存期，指报文段在网络中生存的工夫，超时会被摈弃） 工夫，若该时间段内没有服务端的重发申请的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

Vue路由守卫有哪些，怎么设置，应用场景等

罕用的两个路由守卫：router.beforeEach 和 router.afterEach每个守卫办法接管三个参数：to: Route: 行将要进入的指标 路由对象from: Route: 以后导航正要来到的路由next: Function: 肯定要调用该办法来 resolve 这个钩子。在我的项目中，个别在beforeEach这个钩子函数中进行路由跳转的一些信息判断。判断是否登录，是否拿到对应的路由权限等等。

说一下HTTP 3.0

HTTP/3基于UDP协定实现了相似于TCP的多路复用数据流、传输可靠性等性能，这套性能被称为QUIC协定。

  1. 流量管制、传输可靠性性能：QUIC在UDP的根底上减少了一层来保障数据传输可靠性，它提供了数据包重传、拥塞管制、以及其余一些TCP中的个性。
  2. 集成TLS加密性能：目前QUIC应用TLS1.3，缩小了握手所破费的RTT数。
  3. 多路复用：同一物理连贯上能够有多个独立的逻辑数据流，实现了数据流的独自传输，解决了TCP的队头阻塞问题。
  4. 疾速握手：因为基于UDP，能够实现应用0 ~ 1个RTT来建设连贯。

对 CSSSprites 的了解

CSSSprites（精灵图），将一个页面波及到的所有图片都蕴含到一张大图中去，而后利用CSS的 background-image，background-repeat，background-position属性的组合进行背景定位。

长处：

  • 利用CSS Sprites能很好地缩小网页的http申请，从而大大提高了页面的性能，这是CSS Sprites最大的长处；
  • CSS Sprites能缩小图片的字节，把3张图片合并成1张图片的字节总是小于这3张图片的字节总和。

毛病：

  • 在图片合并时，要把多张图片有序的、正当的合并成一张图片，还要留好足够的空间，避免板块内呈现不必要的背景。在宽屏及高分辨率下的自适应页面，如果背景不够宽，很容易呈现背景断裂；
  • CSSSprites在开发的时候相对来说有点麻烦，须要借助photoshop或其余工具来对每个背景单元测量其精确的地位。
  • 保护方面：CSS Sprites在保护的时候比拟麻烦，页面背景有少许改变时，就要改这张合并的图片，无需改的中央尽量不要动，这样防止改变更多的CSS，如果在原来的中央放不下，又只能（最好）往下加图片，这样图片的字节就减少了，还要改变CSS。

对盒模型的了解

CSS3中的盒模型有以下两种：规范盒子模型、IE盒子模型 盒模型都是由四个局部组成的，别离是margin、border、padding和content。

规范盒模型和IE盒模型的区别在于设置width和height时，所对应的范畴不同：

  • 规范盒模型的width和height属性的范畴只蕴含了content，
  • IE盒模型的width和height属性的范畴蕴含了border、padding和content。

能够通过批改元素的box-sizing属性来扭转元素的盒模型：

  • box-sizeing: content-box示意规范盒模型（默认值）
  • box-sizeing: border-box示意IE盒模型（怪异盒模型）

HTTP协定的性能怎么样

HTTP 协定是基于 TCP/IP，并且应用了申请-应答的通信模式，所以性能的要害就在这两点里。

  • 长连贯

HTTP协定有两种连贯模式，一种是继续连贯，一种非继续连贯。
（1）非继续连贯指的是服务器必须为每一个申请的对象建设和保护一个全新的连贯。
（2）继续连贯下，TCP 连贯默认不敞开，能够被多个申请复用。采纳继续连贯的益处是能够防止每次建设 TCP 连贯三次握手时所破费的工夫。

对于不同版本的采纳不同的连贯形式：

  • 在HTTP/1.0 每发动一个申请，都要新建一次 TCP 连贯（三次握手），而且是串行申请，做了无畏的 TCP 连贯建设和断开，减少了通信开销。该版本应用的非继续的连贯，然而能够在申请时，加上 Connection: keep-a live 来要求服务器不要敞开 TCP 连贯。
  • 在HTTP/1.1 提出了长连贯的通信形式，也叫长久连贯。这种形式的益处在于缩小了 TCP 连贯的反复建设和断开所造成的额定开销，加重了服务器端的负载。该版本及当前版本默认采纳的是继续的连贯。目前对于同一个域，大多数浏览器反对同时建设 6 个长久连贯。
  • 管道网络传输

HTTP/1.1 采纳了长连贯的形式，这使得管道（pipeline）网络传输成为了可能。

管道（pipeline）网络传输是指：能够在同一个 TCP 连贯外面，客户端能够发动多个申请，只有第一个申请收回去了，不用等其回来，就能够发第二个申请进来，能够缩小整体的响应工夫。然而服务器还是依照程序回应申请。如果后面的回应特地慢，前面就会有许多申请排队等着。这称为队头梗塞。

  • 队头梗塞

HTTP 传输的报文必须是一发一收，然而，外面的工作被放在一个工作队列中串行执行，一旦队首的申请解决太慢，就会阻塞前面申请的解决。这就是HTTP队头阻塞问题。

队头阻塞的解决方案： （1）并发连贯：对于一个域名容许调配多个长连贯，那么相当于减少了工作队列，不至于一个队伍的工作阻塞其它所有工作。
（2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，可能并发的长连接数变多，解决了队头阻塞的问题。

UDP协定为什么不牢靠？

UDP在传输数据之前不须要先建设连贯，远地主机的运输层在接管到UDP报文后，不须要确认，提供不牢靠交付。总结就以下四点：

  • 不保障音讯交付：不确认，不重传，无超时
  • 不保障交付程序：不设置包序号，不重排，不会产生队首阻塞
  • 不跟踪连贯状态：不用建设连贯或重启状态机
  • 不进行拥塞管制：不内置客户端或网络反馈机制

文档申明（Doctype）和<!Doctype html>有何作用? 严格模式与混淆模式如何辨别？它们有何意义?

文档申明的作用： 文档申明是为了通知浏览器，以后HTML文档应用什么版本的HTML来写的，这样浏览器能力依照申明的版本来正确的解析。

的作用：<!doctype html> 的作用就是让浏览器进入规范模式，应用最新的 HTML5 规范来解析渲染页面；如果不写，浏览器就会进入混淆模式，咱们须要防止此类情况产生。

严格模式与混淆模式的辨别：

  • 严格模式： 又称为规范模式，指浏览器依照W3C规范解析代码；
  • 混淆模式： 又称怪异模式、兼容模式，是指浏览器用本人的形式解析代码。混淆模式通常模仿老式浏览器的行为，以避免老站点无奈工作；

辨别：网页中的DTD，间接影响到应用的是严格模式还是浏览模式，能够说DTD的应用与这两种形式的区别非亲非故。

  • 如果文档蕴含严格的DOCTYPE ，那么它个别以严格模式出现（严格 DTD ——严格模式）；
  • 蕴含过渡 DTD 和 URI 的 DOCTYPE ，也以严格模式出现，但有过渡 DTD 而没有 URI （对立资源标识符，就是申明最初的地址）会导致页面以混淆模式出现（有 URI 的过渡 DTD ——严格模式；没有 URI 的过渡 DTD ——混淆模式）；
  • DOCTYPE 不存在或模式不正确会导致文档以混淆模式出现（DTD不存在或者格局不正确——混淆模式）；
  • HTML5 没有 DTD ，因而也就没有严格模式与混淆模式的区别，HTML5 有绝对宽松的 法，实现时，曾经尽可能大的实现了向后兼容(HTML5 没有严格和混淆之分)。

总之，严格模式让各个浏览器对立执行一套标准兼容模式保障了旧网站的失常运行。

GET和POST的申请的区别

Post 和 Get 是 HTTP 申请的两种办法，其区别如下：

  • 利用场景： GET 申请是一个幂等的申请，个别 Get 申请用于对服务器资源不会产生影响的场景，比如说申请一个网页的资源。而 Post 不是一个幂等的申请，个别用于对服务器资源会产生影响的情景，比方注册用户这一类的操作。
  • 是否缓存： 因为两者利用场景不同，浏览器个别会对 Get 申请缓存，但很少对 Post 申请缓存。
  • 发送的报文格式： Get 申请的报文中实体局部为空，Post 申请的报文中实体局部个别为向服务器发送的数据。
  • 安全性： Get 申请能够将申请的参数放入 url 中向服务器发送，这样的做法绝对于 Post 申请来说是不太平安的，因为申请的 url 会被保留在历史记录中。
  • 申请长度： 浏览器因为对 url 长度的限度，所以会影响 get 申请发送数据时的长度。这个限度是浏览器规定的，并不是 RFC 规定的。
  • 参数类型： post 的参数传递反对更多的数据类型。

TCP的三次握手和四次挥手

（1）三次握手

三次握手（Three-way Handshake）其实就是指建设一个TCP连贯时，须要客户端和服务器总共发送3个包。进行三次握手的次要作用就是为了确认单方的接管能力和发送能力是否失常、指定本人的初始化序列号为前面的可靠性传送做筹备。本质上其实就是连贯服务器指定端口，建设TCP连贯，并同步连贯单方的序列号和确认号，替换TCP窗口大小信息。

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

  • 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，此时客户端处于 SYN_SEND 状态。
首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
  • 第二次握手：服务器收到客户端的 SYN 报文之后，会以本人的 SYN 报文作为应答，并且也是指定了本人的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，示意本人曾经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y
  • 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，示意曾经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，单方已建设起了连贯。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段能够携带数据，不携带数据则不耗费序号。

那为什么要三次握手呢？两次不行吗？

  • 为了确认单方的接管能力和发送能力都失常
  • 如果是用两次握手，则会呈现上面这种状况：
如客户端收回连贯申请，但因连贯申请报文失落而未收到确认，于是客户端再重传一次连贯申请。起初收到了确认，建设了连贯。数据传输结束后，就开释了连贯，客户端共收回了两个连贯申请报文段，其中第一个失落，第二个达到了服务端，然而第一个失落的报文段只是在某些网络结点长时间滞留了，延误到连贯开释当前的某个工夫才达到服务端，此时服务端误认为客户端又收回一次新的连贯申请，于是就向客户端收回确认报文段，批准建设连贯，不采纳三次握手，只有服务端收回确认，就建设新的连贯了，此时客户端疏忽服务端发来的确认，也不发送数据，则服务端统一期待客户端发送数据，浪费资源。

简略来说就是以下三步：

  • 第一次握手： 客户端向服务端发送连贯申请报文段。该报文段中蕴含本身的数据通讯初始序号。申请发送后，客户端便进入 SYN-SENT 状态。
  • 第二次握手： 服务端收到连贯申请报文段后，如果批准连贯，则会发送一个应答，该应答中也会蕴含本身的数据通讯初始序号，发送实现后便进入 SYN-RECEIVED 状态。
  • 第三次握手： 当客户端收到连贯批准的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连贯建设胜利。

TCP 三次握手的建设连贯的过程就是互相确认初始序号的过程，通知对方，什么样序号的报文段可能被正确接管。 第三次握手的作用是客户端对服务器端的初始序号的确认。如果只应用两次握手，那么服务器就没有方法晓得本人的序号是否 已被确认。同时这样也是为了避免生效的申请报文段被服务器接管，而呈现谬误的状况。

（2）四次挥手

刚开始单方都处于 ESTABLISHED 状态，如果是客户端先发动敞开申请。四次挥手的过程如下：

  • 第一次挥手： 客户端会发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即收回连贯开释报文段（FIN=1，序号seq=u），并进行再发送数据，被动敞开TCP连贯，进入FIN_WAIT1（终止期待1）状态，期待服务端的确认。
  • 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明曾经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
即服务端收到连贯开释报文段后即收回确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（敞开期待）状态，此时的TCP处于半敞开状态，客户端到服务端的连贯开释。客户端收到服务端的确认后，进入FIN_WAIT2（终止期待2）状态，期待服务端收回的连贯开释报文段。
  • 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
即服务端没有要向客户端收回的数据，服务端收回连贯开释报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最初确认）状态，期待客户端的确认。
  • 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为本人 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。须要过一阵子以确保服务端收到本人的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于敞开连贯了，处于 CLOSED 状态。
即客户端收到服务端的连贯开释报文段后，对此收回确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（工夫期待）状态。此时TCP未开释掉，须要通过工夫期待计时器设置的工夫2MSL后，客户端才进入CLOSED状态。

那为什么须要四次挥手呢？

因为当服务端收到客户端的SYN连贯申请报文后，能够间接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。然而敞开连贯时，当服务端收到FIN报文时，很可能并不会立刻敞开SOCKET，所以只能先回复一个ACK报文，通知客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我能力发送FIN报文，因而不能一起发送，故须要四次挥手。

简略来说就是以下四步：

  • 第一次挥手： 若客户端认为数据发送实现，则它须要向服务端发送连贯开释申请。
  • 第二次挥手：服务端收到连贯开释申请后，会通知应用层要开释 TCP 链接。而后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连贯曾经开释，不再接管客户端发的数据了。然而因为 TCP 连贯是双向的，所以服务端仍旧能够发送数据给客户端。
  • 第三次挥手：服务端如果此时还有没发完的数据会持续发送，结束后会向客户端发送连贯开释申请，而后服务端便进入 LAST-ACK 状态。
  • 第四次挥手： 客户端收到开释申请后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会继续 2MSL（最大段生存期，指报文段在网络中生存的工夫，超时会被摈弃） 工夫，若该时间段内没有服务端的重发申请的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

TCP 应用四次挥手的起因是因为 TCP 的连贯是全双工的，所以须要单方别离开释到对方的连贯，独自一方的连贯开释，只代 表不能再向对方发送数据，连贯处于的是半开释的状态。

最初一次挥手中，客户端会期待一段时间再敞开的起因，是为了避免发送给服务器的确认报文段失落或者出错，从而导致服务器 端不能失常敞开。

数组去重

第一种： 通过ES6新个性Set()例如： var arr = [1, 2, 3, 1, 2]; var newArr= [...new Set(arr)]
第二种：封装函数利用 {} 和【】function uniqueEasy(arr) {    if(!arr instanceof Array) {        throw Error('以后传入的不是数组')    }    let list = []    let obj = {}    arr.forEach(item => {        if(!obj[item]) {            list.push(item)            obj[item] = true        }    })    return list}

当然还有其余的办法，但自己我的项目中个别应用以上两种根本满足

src和href的区别

src和href都是用来援用内部的资源，它们的区别如下：

  • src： 示意对资源的援用，它指向的内容会嵌入到以后标签所在的地位。src会将其指向的资源下载并应⽤到⽂档内，如申请js脚本。当浏览器解析到该元素时，会暂停其余资源的下载和解决，直到将该资源加载、编译、执⾏结束，所以⼀般js脚本会放在页面底部。
  • href： 示意超文本援用，它指向一些网络资源，建设和以后元素或本文档的链接关系。当浏览器辨认到它他指向的⽂件时，就会并⾏下载资源，不会停⽌对以后⽂档的解决。 罕用在a、link等标签上。