1、http1.1和http2的区别
http1.1：
（1）高延迟：会导致队头阻塞
（2）明文传输：不安全
（3）无状态：头部巨大且重复
（4）不支持服务器推送
http2:
（1）二进制分帧
（2）header头部压缩，gzip等
（3）多路复用
（4）可以给请求设置优先级
（5）支持服务端推送
（6）可以基于https提高安全性
2、简单讲解一下 http2 的多路复用
在 HTTP2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，服务端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以 避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。
3、简单介绍TCP的三次握手和四次挥手
三次握手：
（1）A对B说：我的序号是x，我要向你请求连接；（第一次握手，发送SYN包，和序列号seq=1，然后进入SYN-SEND状态） ；
（2）B收到之后对A说：我的序号是y，同意建立连接。（第二次握手，发送SYN包，ack=x+1，然后进入SYN-RCVD状态）
（3）A收到之后对B说：好的，知道了，发送确认包ack=y+1（第三次握手，A已进入ESTABLISHED状态） B听到A的确认之后，也进入ESTABLISHED状态。
四次挥手就是：
（1）A与B交谈结束之后，A要结束此次会话，对B说：我要关闭连接了（seq=u,FIN=1）。（第一次挥手，A进入FIN-WAIT-1） ；
（2）B收到A的消息后说：确认，你要关闭连接了。（seq=v,ack=u+1,ACK=1）（第二次挥手，B进入CLOSE-WAIT）
（3）A收到B的确认后,等了一段时间，因为B可能还有话要对他说。（此时A进入FIN-WAIT-2）； B说完了他要说的话（只是可能还有话说）之后，对A说，我要关闭连接了。（seq=w, ack=u+1,FIN=1，ACK=1）(第三次挥手)
（4）A收到B要结束连接的消息后说：已收到你要关闭连接的消息。（seq=u+1,ack=w+1,ACK=1）(第四次挥手，然后A进入CLOSED) ；B收到A的确认后，也进入CLOSED。
4、TCP为什么是三次握手而不是两次
为了防止网络信号差或其他原因时，client第一次发的链接请求可能因为时间太久已经失效，而此时server端才接受到，以为是正常的链接请求，便给client发确认，客户端如果没有第三次确认，这时服务端就无法断定这个链接已经失效，一直等待client发数据，严重消耗网络资源。
5、TCP和UDP的区别和使用场景
（1）TCP是面向连接的，UDP是无连接的；
（2）TCP是可靠的传输，UDP是尽最大努力交付，即不保证可靠交付；
（4）UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性较高的通信或广播通信；
（5）每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信；
（6）TCP对系统资源要求较多，UDP对系统资源要求较少。
（7）TCP适用效率要求相对低，但对准确性要求相对高的场景，如文件传输；UDP适用效率要求相对高，对准确性要求相对低的场景，如直播、语音通话、广播通信等；
6、HTTP 常见状态码
1xx: 信息提示
2xx：成功
3xx：重定向
4xx：客户端错误
5xx：服务端错误
200成功
204无内容
301永久移动（回应 GET 响应时会自动将请求者转到新位置）
302临时重定向
304未修改（协商缓存）
400 Bad Request
401未授权（身份不识别）
403服务器拒绝请求（资格不够）
404未找到
409请求发生冲突
500服务器内部错误
502错误网关
503服务不可用
7、介绍HTTPS 握手过程
（先是非对称加密建立连接，然后是对称加密）
1.客户端使用 https 的 url 访问服务器，要求与服务器建立 ssl (Secure Sockets Layer 安全套接字协议)连接；
2.服务器收到客户端请求后，会将网站的证书（包含公钥）传送一份给客户端；
3.客户端收到网站证书后会检查证书的颁发机构以及过期时间，如果没有问
题就随机生成一个密钥；
4.客户端利用公钥将会话密钥加密，并传送给服务端，服务端利用自己的私
钥解密出会话密钥；
5.之后服务器与客户端使用密钥加密传输；
8、HTTPS 握手过程中，客户端如何验证证书的合法性
1.首先浏览器读取证书中的证书所有者、有效期等信息进行校验，校验证书的网站域名是否与证书颁发的域名一致，校验证书是否在有效期内；
2.浏览器开始查找操作系统中已内置的证书发布机构 CA，与服务器发来的证书中的颁发者 CA比对，用于校验证书是否为合法机构颁发；
3.如果找不到，浏览器就会报错，说明浏览器发来的证书是不可信任的；
4.如果找到，那么浏览器就会从操作系统中取出颁发者 CA 的公钥（多数浏览器开发商发布版本时，会实现在内部植入常用认证机关的公开密钥），然后对服务器发来的证书里面的签名进行解密；
5.浏览器使用相同的 hash 算法计算出服务器发来的证书的 hash 值，将这个计算的 hash 值与证书中签名做对比；
6.对比结果一致，则证明服务器发来的证书合法，没有被冒充。
9、http和https的区别
（1）HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。
（2）HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
（3）HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
（4）HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
10、HTTPS的优缺点
HTTPS的优点：
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS的缺点：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
11、常用的跨域解决方案有哪些？
同源：指的是在url中协议、域名、端口号均相同。
浏览器的同源策略：不同源的脚本在没有明确授权的情况下，不能读写对方资源。
1、JSONP
（1）浏览器脚本——定义：定义 callback，callback内是读取数据的逻辑
（2）服务端——调用：输出对 callback 的调用，把目标数据作为入参传给 callback
（3）只能用于get请求
2、CORS跨域资源共享（Cross-origin resource sharing）
分为简单请求和复杂请求
简单请求对应的 CORS 行为
浏览器会把请求分为简单请求和非简单请求，对于这两种请求，CORS 的处理过程是不同的，我们先来看简单请求：
- 请求方式为HEAD、POST 或者 GET
- http头信息不超出以下字段：Accept、Accept-Language 、 Content-Language、 Last-Event-ID、 Content-Type(限于三个值：application/x-www-form-urlencoded、multipart/form-data、text/plain)
满足这两个条件的，就是简单请求。对于简单请求，对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段：
Origin: http://imooc.com
Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。服务器处理的结果，分为两种情况：
-
不同意： 如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应；浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段，就知道出错了，从而抛出一个错误，被 XMLHttpRequest 的 onerror 回调函数捕获。
-
同意：如果Origin指定的域名在许可范围内，服务器返回的响应，会多出这个关键的头信息字段：
Access-Control-Allow-Origin: imooc.com
这个字段用于说明服务器接纳哪些域名。它的值要么是请求时Origin字段的值，要么是一个*——表示接受任意域名的请求。
复杂请求对应的 CORS 行为
有一些请求对服务器有着特殊的要求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。
非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。
这个 preflight 的作用在于，确认当前网页所在的域名是否在服务器的许可名单之中、明确可以使用的 HTTP 请求方法和头信息字段。只有在这个请求返回成功的情况下，浏览器才会发出正式的请求。
"预检"请求用的请求方法是OPTIONS
3、postMessage跨域（结合iframe）
// a页面http://www.imooc.com/a.html
<iframe id="iframe" src="http://www.imooc.com/b.html" style="display:none;"></iframe>
<script>
var iframe = document.getElementById('iframe');
iframe.onload = function() {
var data = {
name: 'xiuyan'
};
// a 页面向 b 页面派发消息
iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.neal.cn');
};
// a 页面接受 b 页面的消息
window.addEventListener("message", function( event ) {
console.log('data from b is', event.data)
});
</script>
b页面（http://www.imooc.com/b.html）对消息接受和派发的处理：
<script>
// 接收 a 页面的数据
window.addEventListener('message', function(e) {
console.log('data from a is', event.data)
var data = JSON.parse(e.data);
if (data) {
data.age = 100;
// 派发数据到 a 页面
window.parent.postMessage(JSON.stringify(data), 'http://www.imooc.com');
}
}, false);
</script>
4、反向代理
跨域是针对浏览器的限制，服务器不存在这个限制；
需要一个代理服务器，浏览器向代理服务器发请求（这个时候不跨越），然后由代理服务器向真实的数据服务器请求资源，把资源返回给浏览器。
最常用前端vue或react后端Nginx配置实现反向代理
12、接口如何防刷？
1：网关控制流量洪峰，对在一个时间段内出现流量异常，可以拒绝请求（参考博客文章 mp.csdn.net/postedit/81…
2：源ip请求个数限制。对请求来源的ip请求个数做限制
3：http请求头信息校验；（例如host，User-Agent，Referer）
4：对用户唯一身份uid进行限制和校验。例如基本的长度，组合方式，甚至有效性进行判断。或者uid具有一定的时效性
5：前后端协议采用二进制方式进行交互或者协议采用签名机制
6：人机验证，验证码，短信验证码，滑动图片形式，12306形式
13、axios所具有的特性
1、在浏览器中发送 XMLHttpRequests 请求；
2、在 node.js 中发送 http请求；
3、基于 promise 的 HTTP 库，支持promise所有的API
4、拦截请求和响应；（修改请求数据，只能用在'PUT','POST'和'PATCH'这几个请求方法）
5、转换请求和响应数据,响应回来的内容自动转换；
6、自动转换 JSON 数据；
7、客户端支持保护安全免受 XSRF 攻击；
14、介绍下 HTTP 中间人攻击
1.服务器向客户端发送公钥；
2.攻击者截获公钥，保留在自己手上；
3.然后攻击者自己生成一个【伪造的】公钥，发给客户端；
4.客户端收到伪造的公钥后，生成加密 hash（秘钥） 值发给服务器；
5.攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥；
6.同时生成假的加密 hash 值，发给服务器；
7.服务器用私钥解密获得假秘钥；
8.服务器用假秘钥加密传输信息；
防范方法：
1. 用HTTPS，服务器在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书
的有效性；（现有 HTTPS 很难被劫持，除非信任了劫持者的 CA 证书）。
15、浏览器常见的攻击和如何防御
1、XSS（跨站脚本攻击）
原理：XSS(cross-site scripting)攻击指的是攻击者往Web页面里插入恶意 html标签或者javascript代码。
①攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；
②或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。
XSS分为存储型、反射型、DOM型
存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
防御：
（1）httpOnly: 在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。
（2） 输入过滤: 一般是用于对于输入格式的检查，例如：邮箱，电话号码，用户名，密码……等，按照规定的格式输入。不仅仅是前端负责，后端也要做相同的过滤检查。因为攻击者完全可以绕过正常的输入流程，直接利用相关接口向服务器发送设置。
（3） 转义 HTML: 如果拼接 HTML 是必要的，就需要对于引号，尖括号，斜杠进行转义,但这还不是很完善.想对 HTML 模板各处插入点进行充分的转义,就需要采用合适的转义库。
（4）白名单: 对于显示富文本来说，不能通过上面的办法来转义所有字符，因为这样会把需要的格式也过滤掉。这种情况通常采用白名单过滤的办法，当然也可以通过黑名单过滤，但是考虑到需要过滤的标签和标签属性实在太多，更加推荐使用白名单的方式。
详见美团技术团队：juejin.cn/post/684490…
2、CSRF跨站请求伪造（Cross Site Request Forgery）
原理：
受害者用户登录网站A，输入个人信息，在本地保存服务器生成的cookie。然后在A网站点击由攻击者构建一条恶意链接跳转到B网站，然后B网站携带着的用户cookie信息去访问A网站。让A网站造成是用户自己访问的假相，从而来进行一些列的操作，常见的就是转账。
防御：
（1）验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差。
（2） http请求中验证Referer字段；请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
（3） token；token 验证的 CSRF 防御机制是公认最合适的方案。若网站同时存在 XSS 漏洞的时候，这个方法也是空谈。
详见美团技术团队：juejin.cn/post/684490…
16、cookie 和 token 都存放在 header 中，为什么不会劫持 token？
（1）如果被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。
（2）CRFS攻击中，利用浏览器会自动带上cookie进行攻击，而token不会被浏览器自动带上； token是放在jwt里面下发给客户端的，而且不一定存储在哪里，不能通document.cookie直接拿到，通过jwt+ip的方式可以防止被劫持， 即使被劫持，也无法通过验证，是无效的token。
17、介绍下如何实现 token 加密？
JWT 组成：Header（头部）、Payload（负载）、Signature（签名）
（1）需要一个secret（随机数）；
（2）后端利用secret 和加密算法（如：HMAC-SHA256）对 payload（如账号密码）生成一个字符串（token），返回前端；
（3）前端每次 request 在 header 中带上 token;
（4）后端用同样的算法解密进行验证；
18、为什么通常在发送数据埋点请求的时候使用的是 1x1 像素的透明 gif 图片？
- 能够完成整个 HTTP 请求+响应（尽管不需要响应内容）
- 触发 GET 请求之后不需要获取和处理数据、服务器也不需要发送数据
- 跨域友好
- 执行过程无阻塞
- 相比 XMLHttpRequest 对象发送 GET 请求，性能上更好
- GIF的最低合法体积最小（最小的BMP文件需要74个字节，PNG需要67个字节，而合法的GIF，只需要43个字节）
前端在点击事件或onload等事件中加入下面代码，实现埋点
<script type="text/javascript">
var thisPage = location.href;
var referringPage = (document.referrer) ? document.referrer : "none";
var beacon = new Image();
beacon.src = "http://www.example.com/logger/beacon.gif?page=" + encodeURI(thisPage)
+ "&ref=" + encodeURI(referringPage);
</script>
