Open cheny88 opened 2 years ago
axios向服务器端发送请求时,有两种情况会出现401状态码(unauthorized未授权):服务器端有些api接口要求传递token,1. token失效或 2. 没有传递,就会报401错误。
出现401错误的处理方式:设置axios请求拦截器和响应拦截器
HTTP/3:
http://
打头的都是标准 HTTP 服务。HTTP 协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息。字节一面:如何用 UDP 实现可靠传输? UDP变可靠的方法可以参考现有的QUIC协议,不在传输层做可靠性保证,在应用层做(流量控制、拥塞控制),然后说QUIC协议的优点,不出现队头阻塞、建链时间很短0RTT、可以保证前向安全和前向纠错、通过ID辨别连接······
HTTPS是利用先 TCP 握手(1RTT),再 TLS 握手(2RTT)完成安全传输。 但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层,而是QUIC 内部包含了 TLS,它在自己的帧会携带 TLS 里的“记录”,再加上 QUIC 使用的是 TLS1.3,因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商,甚至在第二次连接的时候,应用数据包可以和 QUIC 握手信息(连接信息 + TLS 信息)一起发送,达到 0-RTT 的效果。
http2 server push ? websocket ? websocket 的产生原因:HTTP 协议有一个缺陷:通信只能由客户端发起。这种单向请求的特点,注定了如果服务器有连续的状态变化,客户端要获知就非常麻烦。我们只能使用"轮询":每隔一段时候,就发出一个询问,了解服务器有没有新的信息。最典型的场景就是聊天室。
轮询的效率低,非常浪费资源(因为必须不停连接,或者 HTTP 连接始终打开)。因此,工程师们一直在思考,有没有更好的方法。WebSocket 就是这样发明的。 它的最大特点就是,服务器可以主动向客户端推送信息,客户端也可以主动向服务器发送信息,是真正的双向平等对话。 其他特点包括:
(1)建立在 TCP 协议之上,服务器端的实现比较容易。
(2)与 HTTP 协议有着良好的兼容性。默认端口也是80和443,并且握手阶段采用 HTTP 协议,因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器。
(3)数据格式比较轻量,性能开销小,通信高效。
(4)可以发送文本,也可以发送二进制数据。
(5)没有同源限制,客户端可以与任意服务器通信。
(6)协议标识符是ws(如果加密,则为wss),服务器网址就是 URL。
主要区别:
HTTP1.0和HTTP1.1的区别:
长连接: HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接。
HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。
节约带宽 HTTP 1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,才开始把请求body发送到服务器。如果客户端无权限请求服务器,则会返回401状态码(unauthorized未授权),当服务器返回401的时候,客户端就可以不用发送请求body了,节约了带宽。
另外HTTP1.0中,存在一些浪费的现象,例如客户端只是需要某个资源一部分,而服务器却将整个资源送过来了。HTTP1.1在请求头中引入了range头域,允许只请求资源的某一个部分。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础.
HTTP2 和HTTP1.X的区别:
多路复用: HTTP2使用了多路复用的技术,做到同一个连接并发处理多个请求,让所有数据流共用同一个连接,可以更有效地使用 TCP 连接。一个连接上可以有多个request,且可以随机的混在一起,每个不同的request都有对应的id,服务端可以通过request_id来辨别,大大加快了传输速率。
新的二进制格式: HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2的协议解析决定采用二进制格式,实现方便且健壮。
header压缩 引入头信息压缩机制(header compression),头信息压缩后再发送;客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,不发送同样字段,只发送索引号,提高速度。
服务端推送 HTTP2允许服务器未经请求,主动向客户端发送资源。客户端向服务器请求资源时,服务器可以把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接发送请求到服务器端获取,避免往返的延迟。
HTTP3
为什么HTTP3.0使用UDP协议
基于UDP, 由于HTTP/2 通过多路复用、二进制流与 Header 压缩等技术,极大地提高了性能,但是还存在问题,比如队头堵塞(HTTP2协议的多路复用机制解决了HTTP层的队头阻塞问题,但是在TCP层仍然存在队头阻塞问题) TCP协议在收到数据包之后,这部分数据可能是乱序到达的,但是TCP必须将所有数据收集排序整合后给上层使用,如果其中某个包丢失了,就必须等待重传,从而出现某个丢包数据阻塞整个连接的数据使用。
QUIC协议是基于UDP协议实现的,在一条链接上可以有多个流,流与流之间是互不影响的,当一个流出现丢包影响范围非常小,(因为一个流丢包了,只有这个流重传数据包了,别的流不受影响)从而解决队头阻塞问题。
0RTT 建链(RTT:往返时间) 一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手,总计需要至少2-3个RTT,普通的HTTP协议也需要至少1个RTT才可以完成握手。
然而,QUIC协议可以实现在第一个包就可以包含有效的应用数据,从而实现0RTT,但这也是有条件的。(对于第一次交互的客户端和服务端0RTT也是做不到的,使用QUIC协议的客户端和服务端要使用1RTT进行密钥交换)
保证了前向安全和前向纠错 前向安全指的是密钥泄漏也不会让之前加密的数据被泄漏,影响的只有当前,对之前的数据无影响。
前面提到QUIC协议首次连接时先后生成了两个加密密钥,由于config被客户端存储了,如果期间服务端私钥泄漏,那么可以根据K = mod p计算出密钥K。
前向纠错利用数据进行传输冗余信息的方法进行数据校验。
QUIC每发送一组数据就对这组数据进行异或运算,并将结果作为一个FEC包发送出去,接收方收到这一组数据后根据数据包和FEC包即可进行校验和纠错。
在移动端的表现比TCP好 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的,这种方式在多变的移动端网络环境下是很脆弱的,比如,当我们从4G环境切换到wifi环境时,手机的IP地址就会发生变化,这时必须创建新的TCP连接才能继续传输数据。
QUIC协议是通过 ID 的方式去识别一个连接,不管你网络环境如何变化,只要 ID 不变,就能迅速重连上。