1：说一下 http 和 https
http：是超文本传输协议，是目前互联网运用最为广泛的协议，他主要是服务器和客户端传输获取数据的一个桥梁，http是明文传输，如果攻击者窃取了服务器和客户端传输的报文，很容易被读懂，因此http不适合传输比较铭感的信息。
https:安全套接字层超文本传输协议HTTPS，就是在http基础上加入了ssl层,就是通过ssl对数据进行了加密，因此https要比http安全。
2：http的缺点
1：通信使用明文，内容可能被窃取
2：不验证通信方的身份容易遭遇伪装
3：无法证明报文的完整性，又可能内容篡改内容
3：https的优点
1：可以认证用户和服务端，确保数据发送到正确的客户机和服务器
2：HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证，比较安全
3：虽然不能完全安全，但它大幅增加了中 间人攻击的成本。
4：https 协议的缺点
1：https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
2：https 缓存不如 http 高效，会增加数据开销。
3： SSL 证书也需要钱，功能越强大的证书费用越高。
4： SSL 证书需要绑定 IP，不能再同一个 ip 上绑定多个域名，ipv4 资源支持不了这 种消耗。
5：http和https的区别
1：Https 协议需要 ca 证书，费用较高。
2：http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl 加 密传输协议。
3：使用不同的链接方式，端口也不同，一般而言，http 协议的端口为 80，https 的端口为 443
4：http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进 行加密传输、身份认证的网络协议，比 http 协议安全。
6：https 协议的工作原理
客户端在使用 HTTPS 方式与 Web 服务器通信时有几个步骤。
a. 客户使用 https url 访问服务器，则要求 web 服务器建立 ssl 链接。
b. web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥）， 返回或者说传输给客户端。
c. 客户端和 web 服务器端开始协商 SSL 链接的安全等级，也就是加密等级。
d. 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站 的公钥来加密会话密钥，并传送给网站。
e. web 服务器通过自己的私钥解密出会话密钥。
f. web 服务器通过会话密钥加密与客户端之间的通信。
总结：http是超文本传输协议，目前互联网运用比较广泛的一个协议，负责客户端和服务器之间的数据传输，但是数据传输我明文，被攻击者获取容易读懂，不是很安全，他没有进行身份认证，因此不能确认，容易造成伪装，也不能确定数据的完整性，https在http基础上加上了ssl层，建立安全通道，对数据进行加密身份认证因此要比http安全，但是https性能没有http好，开销比较大，需要花钱，费用比较高，加载速度没有http协议快，端口号不一样http80，https443
加密技术：
对称加密：
对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。
这种加密方式固然很好，但是问题就在于如何让双方知道秘钥。因为传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。
非对称加密
有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。
这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。
简单流程如下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个秘钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。
混合加密
在对称加密的时候，可能会有攻击者截取公钥，然后自己通过私钥进行加密，然后发送给服务器的风险。
tcp： 三次握手，一句话概括
TCP 和 UDP 的区别
（1）TCP 是面向连接的，udp 是无连接的即发送数据前不需要先建立链接。 （2）TCP 提供可靠的服务。也就是说，通过 TCP 连接传送的数据，无差错，不 丢失，不重复，且按序到达;UDP 尽最大努力交付，即不保证可靠交付。 并且因 为 tcp 可靠，面向连接，不会丢失数据因此适合大数据量的交换。
（3）TCP 是面向字节流，UDP 面向报文，并且网络出现拥塞不会使得发送速率降 低（因此会出现丢包，对实时的应用比如 IP 电话和视频会议等）。
（4）TCP 只能是 1 对 1 的，UDP 支持 1 对 1,1 对多。
（5）TCP 的首部较大为 20 字节，而 UDP 只有 8 字节。 TCP 是面向连接的可靠性传输，而 UDP 是不可靠的。
什么是 WebSocket?
WebSocket 是 HTML5 中的协议，支持持久连续，http 协议不支持持久性连接。 Http1.0 和 HTTP1.1 都不支持持久性的链接，HTTP1.1 中的 keep-alive，将多个 http 请求合并为 1 个；
WebSocket 是什么样的协议，具体有什么优点？
HTTP 的生命周期通过 Request 来界定，也就是 Request 一个 Response，那么在 Http1.0 协议中，这次 Http 请求就结束了。 在 Http1.1 中进行了改进，是的有一个 connection：Keep-alive，也就是说， 在一个 Http 连接中，可以发送多个 Request，接收多个 Response。但是必须记 住，在 Http 中一个 Request 只能对应有一个 Response，而且这个 Response 是 被动的，不能主动发起。 WebSocket 是基于 Http 协议的，或者说借用了 Http 协议来完成一部分握手，在 握手阶段与 Http 是相同的。我们来看一个 websocket 握手协议的实现，基本是 2 个属性，upgrade，connection。
请求方法：
put:用来传输文件,要求在请求报文主体中包含文件的内容,但是他自身不带验证机制.
head:获取报文的首部
delete:删除文件,他自身不带验证机制.
options:用来获取服务器支持那些请求方法
tract:追踪路径
发送请求的时候:在Max-Forwards首部字段中填写输入的数值,每经过服务器就减一,当数值减到0时,就服务器发起响应
connect：要求和代理服务器建立隧道，通过ｓｓｌ进行加密，经过隧道
get和post请求的区别
- Get 请求能缓存，Post 不能
- Post 相对 Get 安全一点点，因为Get 请求都包含在 URL 里（当然你想写到
body里也是可以的），且会被浏览器保存历史纪录。Post 不会，但是在抓包的情况下都是一样的。 - URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的，不是 RFC 规定的
- Post 支持更多的编码类型且不对数据类型限制
- get 请求只能进行 url 编码，而 post 支持多种编码方式 get 请求会浏览器主动 cache，而 post 支持多种编码方式。 get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。 GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/ 服务器的限制，导致他们在应用过程中体现出一些不同。 GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
http：特点
持久连接：通过三次握手和四次挥手，能够减少tcp的连接和断开的开销怕，减轻服务器的负载
管线化：可以并行发送多个请求，而不需要一个接一个的等待响应
使用cookie的状态管理：一般进行登录功能
一般：交互的时候出现跨域的话我们就用token，否则就可以用session和cookie
状态码：
200：请求正常的处理
204：服务器接受了请求已经成功的处理了，但是响应报文中，不含实体的主体部分
206：客户端进行了范围的请求，而服务器成功的执行了这一部分的get请求
301：永久重定向 禁止post方法改变get方法
302：临时重定向
303：临时重定向，区别就是采用get方法获取资源
304：客服端附带条件访问服务器，服务器允许请求访问资源，但是请求没有满足条件
307：临时重定向
400：参数不匹配
401：需要认证
403：权限不够
404：访问不到资源
500：服务器内部错误
503：服务器已经关闭
**说一下 http2.0 参考答案：
** 首先补充一下，http 和 https 的区别，相比于 http,https 是基于 ssl 加密的 http 协议简要概括：
http2.0 是基于 1999 年发布的 http1.0 之后的首次更新。 提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比 http1.0）
允许多路复用：多路复用允许同时通过单一的 HTTP/2 连接发送多重请求-响应信 息。
改善了：在 http1.1 中，浏览器客户端在同一时间，针对同一域名下的请求有一 定数量限制（连接数量），超过限制会被阻塞。
二进制分帧：HTTP2.0 会将所有的传输信息分割为更小的信息或者帧，并对他们 进行二进制编码。 首部压缩 服务器端推送
fetch 发送 2 次请求的原因
参考答案：
fetch 发送 post 请求的时候，总是发送 2 次，第一次状态码是 204，第二次才成 功？
原因很简单，因为你用 fetch 的 post 请求的时候，导致 fetch 第一次发送了一 个 Options 请求，询问服务器是否支持修改的请求头，如果服务器支持，则在第 二次中发送真正的请求。