目录
B.通过session ticket:包含对话秘钥和加密方法的加密
持久化):长连接(Keep-Alive(单个连接不同时间多个请求/响应)
1xx Informational (信息):接受请求正在处理
206 Partial Content:处理了部分请求,返回了相应的数据范围【分段下载】
3xx - Redirection(重定向):附加操作已完成请求
301 Moved Permanently:永久重定向,搜索引擎会更新
B.代理服务器的目标地址请求的不对,config/index.js 配置的 proxy 的 target
304 Not Modified:304资源缓存,可以使用本地缓存
4xx Client Error(客户端错误): 服务器无法处理请求
5xx Server Error(服务器错误):服务器处理请求出错
后端查看配置 Nginx 反向代理参数有没有问题或者重启 Nginx 服务
Http
默认端口号 80
基于TCP
无状态的协议(Cookie/Session识别->状态)
无状态是指服务端无状态是指服务端不会存储每次的会话信息,对于客户端每次发送的请求,都认为它是一个新的请求,上一次会话和下一次会话没有联系。
明文传输
即协议里的报文(主要指的是头部)不使用二进制数据,而是文本形式。
弊端:WIFI获取信息
应用:对数据的安全性要求较低时,例如在一些博客、新闻网站上
Https
默认端口号443
HTTPS = HTTP + SSl/TLS协议(传输层)
用SSL/TLS对数据进行加密和解密
SSL的全称是Secure Sockets Layer,即安全 套接 层协议
TLS的全称是Transport Layer Security,即安全 传输 层协议
HTTPS中TLS1.2版本7次,TLS1.3版本6次
有状态协议:session cookie
密文传输:TLS/SSL
TLS实际上是SSL的后继版本
TLS1.2握手
非对称加密:身份认证、密钥协商
为什么不用对称加密:
- 每个客户端都用同一个密钥不合理
- 一个客户端对应一个密钥,在传输过程被拦截
- 有一对秘钥,「公钥」和「私钥」
- 公钥可以发送给所有的客户端,私钥只保存在服务器端。
对称加密:协商的密钥对数据加密
散列函数:验证信息的完整性
服务端的公钥和私钥,非对称加密
客户端生成的随机秘钥,对称加密
第三方认证
引入:中间人篡改公钥
数字签名:由服务端私钥加密
数据完整性: 数字签名可以确保数据的完整性,即一旦数据被签名,任何对数据的篡改都会导致数字签名验证失败。
安全证书(公钥、域名、有效期、签名):存在于服务器端
-
公钥: 用于加密通信的公钥。
-
域名: 证书颁发机构确认的域名,确保证书只对特定域名有效。
-
证书的有效期: 证书颁发和过期的时间范围。
-
数字签名: 由证书颁发机构使用其私钥生成的数字签名,用于验证证书的真实性。
客户端对比签名
- 浏览器会去安装一些比较权威的第三方认证机构的公钥,比如VeriSign、Symantec以及GlobalSign等等。
- 验证数字签名的时候,会直接从本地拿到相应的第三方的公钥,对私钥加密后的数字签名进行解密得到真正的签名。
- 然后客户端利用签名生成规则进行签名生成,看两个签名是否匹配,如果匹配认证通过,不匹配则获取证书失败。
SSL重连
A.通过session ID:只能是同一个服务器
目前所有的浏览器都支持这一种方法。
但是这种方法有一个缺点是,session ID 只能够存在一台服务器上,如果我们的请求通过负载平衡被转移到了其他的服务器上,那么就无法恢复对话。
B.通过session ticket:包含对话秘钥和加密方法的加密
session ticket 是服务器在上一次对话中发送给客户的,这个 ticket 是加密的,只有服务器能够解密,里面包含了本次会话的信息,比如对话秘钥和加密方法等。这样不管我们的请求是否转移到其他的服务器上,当服务器将 ticket 解密以后,就能够获取上次对话的信息,就不用重新生成对话秘钥了。
http版本
1.0->1.1(一次传输多个文件,默认Connection: keep-alive)
http1.x解析基于文本,
http2.0采用二进制格式,新增特性 多路复用、header压缩、服务端推送(静态html资源)
HTTP/2和HTTP/3,主要支持 并发处理 和 减少延迟 方面。
队头阻塞:其他请求阻塞
当 http 开启长连接时,共用一个 TCP 连接,同一时刻只能处理一个请求,那么当前请求耗时过长的情况下,其它的请求只能处于阻塞状态
队头阻塞问题是指当一个请求或响应在传输过程中被阻塞时,后续的请求或响应也会被阻塞,从而影响整体性能。
HTTP/1.x 中,由于使用了串行的连接,一个请求必须等待前面的请求完成才能开始传输。
HTTP/2 的多路复用机制使得多个请求和响应可以并行在同一个连接上进行传输,提高了并发性。
然而,HTTP/2 并没有完全解决队头阻塞问题的主要原因有几点:
-
依赖树的构建: HTTP/2 中,请求和响应的传输是通过帧(frames)的方式进行的,每个帧都有一个标识符(Stream ID)来标识属于哪个请求或响应。虽然可以并行传输多个帧,但这些帧在接收端需要按照顺序重新组装。如果某个关键资源的请求被阻塞,它所依赖的所有资源也将被阻塞,构成了一个依赖树。这种依赖树结构仍然可能导致队头阻塞问题。
-
优先级机制: HTTP/2 引入了优先级机制,允许客户端指定请求的优先级。服务器在处理请求时也会考虑这些优先级。然而,优先级并不是强制性的,服务器和客户端可以根据各自的实现来解释和处理。因此,在一些情况下,优先级并不能完全解决队头阻塞。
-
头部压缩问题: HTTP/2 使用了头部压缩,将请求和响应的头部信息压缩为一个首部块。虽然这有效地减小了传输的数据量,但在某些情况下,头部信息的压缩和解压缩过程也可能导致一些延迟。
无头阻塞: HTTP/3 在 QUIC 协议中引入了一种称为"无头阻塞"(Head-of-Line Blocking Avoidance)的机制。它通过使用独立的流(stream)来传输关键资源(如页面的主 HTML 文档),这样即使某个资源的传输被阻塞,其他资源的传输也可以继续进行
队头阻塞是一个复杂的网络问题,受到网络拓扑、延迟、丢包等多种因素的影响。
HTTP/1.0
短连接:每个请求对应一个TCP连接,完成后关闭连接
每个 HTTP 请求都会建立一个新的 TCP 连接,完成请求后立即关闭连接,这被称为短连接
无持久化(单个连接单个请求/响应)
无管道化(无法并发发送请求)
HTTP/1.1
持久化):长连接(Keep-Alive(单个连接不同时间多个请求/响应)
一次 TCP 连接中可以传输多个 HTTP 请求和响应
管道化
分块/流式传输(边收边处理)
HTTP/2
二进制传输(更小的帧)
多路复用(单个连接同时多个请求/响应)
头部压缩
可服务器推送
HTTP/3
(QUIC协议)UDP代替TCP(时延,拥塞)
传输层也能多路复用
0-RRT握手
改进头部压缩
websocket:HTML5新特性,TCP,实时通信
兼容性不好,只适用于主流浏览器和IE10+
应用:webpack热更新
HTML5 的一个持久化的协议,它实现了浏览器与服务器的全双工通信
WebSocket 和 HTTP 都是应用层协议,都基于 TCP 协议。
WebSocket 在建立连接时需要借助 HTTP 协议,连接建立好了之后 client 与 server 之间的双向通信就与 HTTP 无关了
-
如果服务器支持 WebSocket,它会以 HTTP 101 Switching Protocols 的状态码作为响应,表明协议切换成功。服务器的响应同样包含
Upgrade: websocket
和Connection: Upgrade
标头,还包含一个用于标识 WebSocket 连接的密钥。 -
WebSocket 连接建立: 一旦握手完成,连接就从 HTTP 进化为 WebSocket。此后,客户端和服务器可以在同一 TCP 连接上双向发送消息,而不需要重新建立连接。
-
全双工通信: WebSocket 提供了全双工通信的能力,允许客户端和服务器之间异步地发送消息。这与传统的 HTTP 请求-响应模式不同,其中每个请求都需要等待服务器的响应。
-
帧格式: WebSocket 通信使用帧(frames)的概念。每个帧包含一个或多个消息片段,可以是文本、二进制数据或控制帧。这种灵活性允许在 WebSocket 上传输各种类型的数据。
重连:心跳机制 检测、指数退避 重连间断、限制重连次数
-
检测连接丢失: 在 WebSocket 连接中,如果网络中断或服务器关闭连接,客户端将无法继续发送或接收消息。客户端可以通过定时的心跳机制或监测与服务器的连接状态来检测连接的丢失。
-
尝试重连: 当客户端检测到连接丢失时,它会尝试重新建立连接。这通常包括以下步骤:
- 关闭先前的连接:客户端会关闭之前的失效连接。
- 创建新的 WebSocket 连接:客户端会尝试与服务器建立新的 WebSocket 连接。
- 设置事件监听器:新连接建立后,客户端需要重新设置消息接收、错误处理和连接关闭等事件的监听器。
-
指数退避策略: 为了避免在服务器繁忙或网络状况不佳的情况下过于频繁地进行重连,通常会采用指数退避(exponential backoff)策略。这意味着每次连接尝试失败后,等待的时间会逐渐增加,以减轻服务器负担和网络负载。
-
限制重连次数: 为了避免无限制的重连尝试,通常会设置最大重连次数或限制尝试的时间段。
const MAX_RECONNECT_ATTEMPTS = 5;
let reconnectAttempts = 0;
function connectWebSocket() {
const socket = new WebSocket('wss://example.com/socket');
socket.addEventListener('open', () => {
console.log('WebSocket connected');
reconnectAttempts = 0; // 重置重连尝试次数
});
socket.addEventListener('close', event => {
if (reconnectAttempts < MAX_RECONNECT_ATTEMPTS) {
// 指数退避策略
const delay = Math.pow(2, reconnectAttempts) * 1000;
setTimeout(connectWebSocket, delay);
reconnectAttempts++;
} else {
console.log('Exceeded max reconnect attempts');
}
});
socket.addEventListener('error', event => {
// 处理连接错误
});
socket.addEventListener('message', event => {
// 处理收到的消息
});
}
// 初始化连接
connectWebSocket();
http状态码
0:请求未发送/未收到响应
已发送+响应前刷新
- ajax发送后还没有得到响应前立即刷新浏览器,这时ajax就会被浏览器给丢弃了,会返回status code为0;这主要发生在form表单的提交用ajax来提交,而没有阻止表单提交的默认行为,导致页面刷新,这时ajax发出了,但页面刷新; 其实ajax能得到xhr的status只不过值为0;
跨域
- xhr跨域,包括异步请求跨域和302重定向跨域的情况,这时会出现xhr status为0的情况
1xx Informational (信息):接受请求正在处理
100 Cotinue
101 Switching Protocols 切换协议
2xx Successful(成功):请求正常处理完毕
200 OK:有返回内容
201 Created:服务器创建新资源
204 No Content:无返回内容
206 Partial Content:处理了部分请求,返回了相应的数据范围【分段下载】
3xx - Redirection(重定向):附加操作已完成请求
301 Moved Permanently:永久重定向,搜索引擎会更新
服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
302 Found:临时重定向,搜索引擎通常不会更新索引
A.cookie 失效 有 CORS 问题
B.代理服务器的目标地址请求的不对,config/index.js 配置的 proxy 的 target
//响应拦截器
if (error.response && error.response.status === 302) {
if (window.location.host === 'expenseexternal.xx.cn') {
window.location.href = 'https:///passport-cloud.xxx.cn/login?service=' + encodeURIComponent(window.location.href)
}
}
304 Not Modified:304资源缓存,可以使用本地缓存
表示客户端发送了一个带有条件的请求(通常If-Modified-Since或
If-None-Match
)