TCP/IP 网络模型

应用层(HTTP、DNS等)->传输层(UDP/TCP)->网络层(IP协议会将传输层的报文作为数据部分，再加上 IP头组装成 IP 报文，如果 IP 报文大小超过 MTU（以太网中一般为1500字节）就会再次进行分片)->网络接口层(在IP头部的前面加上MAC头部，并封装成数据帧发送到网络上)

OSI七层网络模型

1.http和https

1.1基本概念

http: 是用于从WWW服务器传输超文本到本地浏览器的超文本传输协议。 https:是以安全为目标的HTTP通道，即HTTP下加入SSL层进行加密。

1.2http和https的区别

http是超文本传输协议，信息是明文传输，https协议要比http协议安全，https是具有安全性的ssl加密传输协议。
http协议的默认端口为80，https的默认端口为443。
http的连接很简单，是无状态的。https 握手阶段比较费时。
https缓存不如http高效，会增加数据开销。
https协议需要CA证书，费用较高，功能越强大的证书费用越高。

Https采用混合加密，客户端利用对称加密生成会话密钥，经过公钥加密后传递。服务端用非对称加密的私钥进行解密，拿到会话秘钥。

Https为了保证传输的内容不被修改，使用摘要算法+数字签名。

1.3状态码

1.3.1 状态码分类

1xx - 服务器收到请求。
2xx - 请求成功，如200。
3xx - 重定向，如302。
4xx - 客户端错误，如404。
5xx - 服务端错误，如500。

1.3.2 常见状态码

200 - 成功。
204 -（无内容）服务器成功处理了请求，但没有返回任何内容
301 - 永久重定向。请求的网页已永久移动到新位置。服务器返回此响应（对GET或HEAD请求的响应）时，会自动将请求者转到新位置。
302 - 临时重定向。
304 - 资源未被修改。当协商缓存命中时会返回这个状态码。自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
403 - 没权限。服务器拒绝请求。
404 - 资源未找到。
500 - 服务器错误。
504 - 网关超时。

1.4http请求方法

GET: 通常用来获取资源
HEAD: 获取报文首部
POST: 提交数据，即上传数据
PUT: 修改数据
DELETE: 删除资源(几乎用不到)
CONNECT: 建立连接隧道，用于代理服务器
OPTIONS: 列出可对资源实行的请求方法，用来跨域请求
TRACE: 追踪请求-响应的传输路径

1.4.1GET和POST的区别

从语义的角度，GET 是从服务器获取指定资源，POST 是根于请求报文body对指定的资源做出处理。
从缓存的角度，GET 请求会被浏览器缓存下来(可以放在浏览器本身上，也可以放在nginx)，留下历史记录，而 POST 默认不会。
从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
从安全的角度，GET 一般放在 URL 中不会对服务器上资源进行改变，是安全的。POST会对服务器的数据进行修改，不安全。
从幂等性的角度，GET是幂等的，而POST不是。(幂等表示执行相同的操作，结果也是相同的)
从TCP的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)，然后发 data,返回200。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)

1.5浏览器缓存机制

浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中

1.5.1 强制缓存和协商缓存

强制缓存：只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，即是否使用缓存的决定权在浏览器这边。当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是 Expires(绝对时间) 和 Cache-Control(相对时间)，其中Cache-Control优先级比Expires高。

强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下：

不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致）。
存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存。
存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果。

协商缓存：就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程。

控制协商缓存的字段分别有：

基于时间。 请求头If-Modified-Since(当资源过期，发现响应头中有last-modified声明，则再次发起请求时带上l-m的时间，服务器收到后与被请求资源的l-m对比，如果l-m大，则说明资源被修改过，返回最新资源200OK；如果小，则自由无修改返回304)响应头Last-Modified(标识这个响应资源的最后修改事件)

基于唯一标识。 请求头If-None-Match和Etag响应头，优先级更高。if-none-match的值就是Etage唯一标识。返回服务器判断i-n-m的值与请求资源生成的唯一标识是否相等->相等返回304不会返回资源，不相等返回200和资源，并在响应头加上新的ETag标识。

优点：1.没有修改文件内容的情况下最后修改时间也可能改变，从而重新请求浪费资源2.秒级内修改检测不到3.有些服务器不能精确获取文件最后修改时间。

协商缓存主要有以下两种情况：

协商缓存生效，返回304
协商缓存失效，返回200和资源

1.5.2三种刷新操作对http缓存的影响

正常操作：地址栏输入URL，跳转链接，前进后退等。
手动刷新：f5，点击刷新按钮，右键菜单刷新。
强制刷新：ctrl+f5,shift+command+r

正常操作：强制缓存有效，协商缓存有效。手动刷新：强制缓存失效，协商缓存有效。强制刷新：强制缓存和协商缓存都失效。

1.6http各版本的区别

HTTP 1.0:

任意数据类型都可以发送
有GET、POST、HEAD三种方法
无法复用TCP连接(长连接)
有丰富的请求响应头信息。以header中的Last-Modified/If-Modified-Since和Expires作为缓存标识

HTTP 1.1: 是一种半双工的协议：在同一时间里，客户端和服务器只能有一方主动发数据。(对于登录页面扫码等这样的简单场景可以定时轮询或者长轮询的方式实现服务器推送的效果)

引入更多的请求方法类型PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT
引入长连接，就是TCP连接默认不关闭，可以被多个请求复用，通过请求头connection:keep-alive设置
引入管道连接机制，可以在同一TCP连接里，同时发送多个请求。解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
强化了缓存管理和控制Cache-Control、ETag/If-None-Match
支持分块响应，断点续传，利于大文件传输，能过请求头中的Range实现
使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机，并且共享一个IP地址

HTTP 2: 基于https协议

二进制分帧：不再是纯文本，避免文本歧义，把报文全部换成二进制格式，方便了机器的解析。
服务器推送：新建 stream 来给客户端发送消息，服务器可以额外的向客户端推送资源，而无需客户端明确的请求
多路复用：在共享TCP链接的基础上同时发送请求和响应
增加了安全性，使用HTTP 2.0，要求必须至少TLS 1.2
使用HPACK算法将头部压缩，如果同时发出多个请求，他们的头是一样的或者相似的，协议会帮你消除重复部分。

HTTP 3:

网络迁移不需要重新连接：一个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手，这不利于移动设备切换网络的场景，比如 4G 网络环境切换成 WIFI。把TCP换成UDP。UDP 包之间是无序的，也没有依赖关系。UDP 是不需要连接的，也就不需要握手和挥手的过程，所以天然的就比 TCP 快。
QUIC 协议的特点：
1. 无队头阻塞 当某个流发生丢包时，只会阻塞这个流，其他流不受影响。
2. 建立连接速度快
3. 连接迁移通过连接ID来标记通信的两个断电，IP地址变化仍保有ID，消除重连成本。

1.6.1页面有多张图片，HTTP是怎样的加载表现？

在HTTP 1下，浏览器对一个域名下最大TCP连接数为6，所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目，加快页面图片的获取速度。
在HTTP 2下，可以一瞬间加载出来很多资源，因为，HTTP2支持多路复用，可以在一个TCP连接中发送多个HTTP请求。

1.7HTTP的Keep-Alive和TCP的Keep-Alive

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。

1.8从输入URL到页面呈现经历了什么

juejin.cn/post/684490…

DNS域名解析先在本地域名服务器中查找，如果本地DNS域名服务器无法查询到，则根据本地DNS服务器设置的转发器进行查询。若未用转发模式，则迭代查找，从根域名服务器开始查找，一层一层找下去。建立TCP连接，http协议的通过TCP三次握手建立连接，https协议的还需要通过SSL的加密。完成了之后，客户端和服务器端就可以开始传送数据。发送http/https请求发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议发送到服务器指定端口。服务器处理并返回响应报文服务器接受到请求，就解析请求头，如果头部有缓存相关信息（如if-none-match与if-modified-since），则验证缓存是否有效，若有效则返回状态码为304，若无效则重新返回资源，状态码为200.关闭TCP连接四次挥手。浏览器解析并渲染页面解析HTML，⽣成DOM树，解析CSS，⽣成CSSOM树。遍历可⻅节点，将DOM树和CSSOM树结合，⽣成渲染树。布局完成过程中，如果有js操作或者其他操作，对元素的颜色，背景等作出改变就会引起重绘，如果有对元素的大小、定位等有改变则会引起回流。将像素发送给GPU，展示在⻚⾯上。

1.9http常见字段

Host:客户端发送请求时，用来指定服务器的域名。可以将请求发往「同一台」服务器上的不同网站。
Content-Length：服务器在返回数据时，表明本次回应的数据长度。
Connection字段最常用于客户端要求服务器使用「 HTTP 长连接」机制，以便其他请求复用。只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
Content-Type字段用于服务器回应时，告诉客户端，本次数据是什么格式。Accept用于客户端请求时，声明自己可以接收写数据格式。
Content-Encoding表示服务器返回的数据使用了什么压缩格式。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

2.TCP三次握手和四次挥手

2.1三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，等待服务器确认。
第二次握手：服务器返回ACK（ACK=客户端序列号+1），同时也发送一个自己的SYN包（服务器端唯一的序号syn=k），即SYN+ACK包。
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），TCP连接成功，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

为什么是是三次握手不是两次或四次？

因为，tcp连接是全双工的，数据在两个方向上能同时传递。所以要确保双方，同时能发数据和收数据。

第一次握手：证明了发送方能发数据

第二次握手：ack确保了接收方能收数据，syn确保了接收方能发数据

第三次握手：确保了发送方能收数据

四次握手浪费，两次握手不能保证“双方同时具备收发功能”

2、为什么客户端最后还要发送一次确认？主要是为了防止已失效的连接请求报文段突然又传到了服务器，因而产生错误。

2.2四次挥手

1，客户端进程发出连接释放报⽂，并且停⽌发送数据。发送释放数据报⽂⾸部，FIN=1，其序列号为seq=u（等于前⾯已经传送过来的数据的最后⼀个字节的序号加1）。TCP规定， FIN报⽂段即使不携带数据，也要消耗⼀个序号。
2，服务器收到FIN后，发出确认报⽂，ACK等于收到的序号+1，并且带上⾃⼰的序列号seq=v。TCP服务器通知⾼层的应⽤进程，客户端向服务器的⽅向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。
3，服务器将最后的数据发送完毕后，就向客户端发送FIN，FIN=1，ack=u+1，表示关闭这个方向的数据传输。
4，客户端收到服务器的连接释放报⽂后，发出确认ACK=收到的序列号+1，此时，客户端就进⼊了TIME-WAIT（时间等待）状态。此时TCP连接还没有释放，必须经过2MSL（最⻓报⽂段寿命）的时间后，当客户端撤销相应的TCB后，才进⼊CLOSED状态。但服务器只要收到了客户端发出的确认，⽴即进⼊CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要⽐客户端早⼀些。

1、为什么挥手是四次而握手是三次？
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。

2、为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。

释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

3、为什么要等2MSL

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

2.3TCP和UDP区别

连接状态：TCP 是面向连接的协议，UDP 是无连接的协议。TCP 在建立数据传输之前先要建立连接，而 UDP 则直接发送数据。
可靠性：TCP 提供可靠的数据传输，保证了数据的完整性和正确性，确保数据不会丢失、重复或乱序。UDP 不提供可靠的数据传输，可能会存在数据丢失、重复或乱序的情况。
传输速度：UDP 的传输速度相对于 TCP 更快，因为它没有连接状态和数据确认等额外的开销。但是在保证数据可靠性时，TCP 的传输速度反而更快，因为 TCP 可以采用流量控制和拥塞控制等机制来优化传输效率。
粘包问题：在 TCP 中，应用层发送的数据会先被拆分成多个 TCP 报文段发送，这些报文段可能会被合并，导致接收端出现粘包的情况。UDP 则不会出现粘包问题，每个数据报都是独立的。
应用场景：TCP 通常用于要求可靠性、稳定性高的应用场景，例如网页浏览器、电子邮件、文件传输等。UDP 则用于速度和实时性要求较高的应用场景，例如音视频会议、直播、游戏等。

3.跨域问题

同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

3.1 跨域的解决方案

3.1.1 JSOP

利用script标签(有三种标签不受同源策略影响：img,link,script)，不过只支持GET请求且不安全，可能遇到XSS攻击。

3.1.2 CORS

简单请求时，请求头会自动添加“Origin”字段。服务器响应头中包含 Access-Control-Allow-Origin 来选择我们允许跨域的域名。对于复杂请求呢，我们需要发送一个预检请求，需要携带 Access-Control-Request-Method & Access-Control-Request-Headers，预检请求没有请求体。如果返回的响应头中有 Access-Control-Allow-xxx 那就应该是可以。

如果想传递cookie需要的设置：1.在请求中设置 withCredentials 为 true2.在响应头设置：Access-Control-Allow-Credentials 设置为 true

3.1.3 代理

proxy启用一个代理服务器(域名和客户端一样)接受客户端请求，将请求转发给服务器，拿到服务器响应数据。代理服务器与目标服务器之间的交互是在服务器端完成的，因此不受浏览器同源策略的限制。

Nginx 可以通过添加响应头的方式来修改 HTTP 响应报文中的内容。

正向代理和反向代理的区别

正向代理是客户端的代理，服务器不知道真正的客户端是谁；反向代理是服务器的代理，客户端不知道真正的服务器是谁
正向代理一般是客户端架设的；反向代理一般是服务器架设的
正向代理主要是用来解决访问限制问题；反向代理则是提供负载均衡、安全防护等作用。

3.2跨域拦截是浏览器拦截还是服务器拦截

跨域是浏览器的同源策略造成的，同源是指"协议+域名+端口"三者相同，为了保证浏览器安全对响应的数据进行拦截，若发现是非同源的资源浏览器进程会把响应体丢弃。所以跨域拦截是浏览器进行拦截。跨域是为了阻止用户读取到另一个域名下的内容，跨域并不是请求发不出去，请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了。Ajax 可以获取响应，浏览器认为这不安全，所以拦截了响应。通过表单的方式可以发起跨域请求,因为表单并不会获取新的内容，所以可以发起跨域请求。

3.3去不同网站会携带原来的cookie吗

不会。在cookie中，domain 属性指定了 cookie 的所属域名，path 属性用来指定路径；这两个属性决定了服务器发送的请求是否带上这个cookie。两个网站的域名、路径不一致，所以不会带上原来的cookie。

3.4怎么在解决登录a网站，浏览b网站也自动登录

1.token 服务端生成的加密字符串，当用户第一次使用账号密码成功进行登录后，服务器便生成一个Token及Token失效时间并将此返回给客户端。客户端再次访问服务器，将token放入headers中。Token完全由应用管理，所以它可以避开同源策略。可以避免CSRF攻击。

基于token的单点登录：SSO

sso需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统(app1,app2...)不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌（authCode）实现，sso认证中心验证用户的用户名密码没问题，创建授权令牌（authCode），在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌authCode，然后各个子系统通过单独的单点登录接口，传入 authCode，得到系统登录的 Token，完成登录过程。

3.5token

定义:token可以成为令牌，一般由uid用户唯一身份标识+time当前时间的时间戳+sign签名+固定参数(可选)组成。

token在客户端一般存放于localStorage，cookie或者sessionStorage中，在服务器中一般存于数据库中。

token的认证流程：用户登录后，服务器返回token给客户端。客户端收到保存在xx中，客户端再次访问服务器，将token放入header中，服务器采用filter过滤器进行校验，校验成功返回响应的请求数据。

token可以抵抗csrf，cookie+session不行

4.cookie、localStorage和sessionStorage、session

4.1cookie和session

cookie 和 session 都是普遍用来跟踪浏览用户身份的会话方式。

cookie 数据存放在客户端，session 数据放在服务器端。
http 请求时需要发送到服务端，增加请求数量。
session 会在一定时间内保存在服务器上(当浏览器第一次访问服务器时，服务器会创建一个Session对象。服务器会将SessionID以cookie的方式返回浏览器。)。如果访问量比较大，会比较消耗服务器的性能。考虑到减轻服务器性能方面的开销，应当使用 cookie 。
单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个域名最多保存 50 个 cookie。将登陆信息等重要信息存放为 session（更安全）、其他信息如果需要保留，可以放在 cookie 中。
A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。
session是有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。负载均衡多服务器的情况，不好确认当前用户是否登录，因为服务器不共享session。 juejin.cn/post/701250…

4.2localStorage和sessionStorage

相同点

localStorage和SessionStorage一样都是用来存储客户端临时信息的对象。
只能存储字符串对象
不同浏览器无法共享localStorage与SessionStroage中的信息。相同浏览器的不同页面间（同源页面）可以共享相同的localStorage，但不能共享sessionStorage。
不会随着 http 请求被发送到服务端。
HTML5 专⻔为存储来设计的，最⼤可存 5M。

不同点

localStorage的生命周期是永久，除非用户清除localStorage信息。
sessionStorage的生命周期为当前窗口或标签页。一旦窗口永久关闭就结束。

4.3cookie字段

Expires属性指定一个具体的到期时间，到了指定时间以后，浏览器就不再保留这个 Cookie。
Max-Age属性指定从现在开始 Cookie 存在的秒数。过了这个时间以后，浏览器就不再保留这个 Cookie。
Domain属性指定浏览器发出 HTTP 请求时，哪些域名要附带这个 Cookie。如果服务器在Set-Cookie字段指定的域名，不属于当前域名，浏览器会拒绝这个 Cookie。
Path属性指定浏览器发出 HTTP 请求时，哪些路径要附带这个 Cookie。
Secure属性指定浏览器只有在HTTPS下，才能将这个 Cookie 发送到服务器。
HttpOnly属性指定该 Cookie 无法通过 JavaScript 脚本拿到(主要是Document.cookie属性、XMLHttpRequest对象和 Request API 都拿不到该属性),这样就防止了该 Cookie 被脚本读到，只有浏览器发出 HTTP 请求时，才会带上该 Cookie。
sameSite准确的说 SameSite 这个属性有两个可选值，分别是 Strict 和 Lax 。其中 Strict 为严格模式，另一个域发起的任何请求都不会携带该类型的 cookie，能够完美的阻止 CSRF 攻击，但是也可能带来了少许不便之处，例如通过一个导航网站的超链接打开另一个域的网页会因为没有携带 cookie 而导致没有登录等问题。因此 Lax 相对于 Strict 模式来说，放宽了一些。简单来说就是，用「安全」的 HTTP 方法（GET、HEAD、OPTIONS 和 TRACE）改变了当前页面或者打开了新页面时，可以携带该类型的 cookie。

4.4cookie和token都放在header中，为什么会劫持cookie，不会劫持token

cookie: 登陆后后端生成一个sessionid放在cookie中返回给客户端, 并且服务端一直记录着这个 sessionid, 客户端以后每次请求都会带上这个sessionid, 服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie就相当于拿到了sessionid ,就可以完全替代你。同时浏览器会自动携带cookie
token: 同样是登录后服务端返回一个token，客户端保存起来，在以后http请求里手动的加入到请求头里，服务端根据token 进行身份的校验。浏览器不会自动携带token，所以不会劫持 token。

4.5token怎么实现无感刷新

什么是无感刷新

后台返回的token是有时效性的，时间到了，你在交互后台的时候，后台会判断你的token是否过期（安全需要），如果过期了就会逼迫你重新登陆！

token无感刷新其本质是为了优化用户体验,当token过期时不需要用户跳回登录页重新登录,而是当token失效时,进行拦截,发送刷新token的ajax,获取最新的token进行覆盖,让用户感受不到token已经过期

实现无感刷新

1、后端返回过期时间，前端判断token过期时间,去调用刷新token接口。

缺点：需要后端额外提供一个Token过期时间的字段；使用了本地时间判断，若本地时间篡改，特别是本地时间比服务器时间慢时，拦截会失败。

2、写个定时器，定时刷新Token接口。缺点：浪费资源,消耗性能,不建议采用。

3、在响应拦截器中拦截，判断Token 返回过期后，调用刷新token接口。

5.怎么理解浏览器多进程和JS单线程

进程是CPU分配的最小单位。线程是不能单独存在的，它是由进程来启动和管理的；线程是依附于进程的，而进程中使用多线程并行处理能提升运算效率。在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程），空白页面会被合并。

浏览器进程有Browser进程，第三方插件进程，GPU进程和浏览器渲染进程等。多进程可以避免单页面崩溃影响整个浏览器。当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，GUI渲染线程就会被触发。但是设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起，GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

6.攻击和防御

常见的网络漏洞：跨站脚本攻击(XSS)、跨站请求伪造(CSRF)、点击劫持、SQL注入、DDOS攻击、DNS劫持

XSS

攻击者通过注入恶意的脚本，在用户浏览网页的时候进行攻击，比如获取cookie或者其他用户身份信息。可以分为存储型和反射型。

存储型是攻击者输入一些数据并且存储到了数据库中，其他浏览者看到的时候进行攻击。
反射型的话.不存储在数据库中，往往表现为将攻击代码放在URL地址的请求参数中。

防御：

转义字符 对于用户的输入应该是永远不信任的。最普遍的做法就是转义输入输出的内容，对于引号、尖括号、斜杠进行转义。

CSP CSP 本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击。通常可以通过两种方式来开启 CSP：1.设置 HTTP Header 中的 Content-Security-Policy；2.设置 meta 标签的方式。

输入内容长度控制

HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。

验证码：防止脚本冒充用户提交危险操作。

CSRF

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

防御：

同源检测：验证 HTTP Referer 或者 Origin 字段；它记录了该 HTTP 请求的来源地址。

在请求地址中添加 token 并验证：服务器下发一个随机 Token，每次发起请求时将 Token 携带上，服务器验证 Token 是否有效。

在 HTTP 头中自定义属性并验证。把token放到HTTP头的自定义属性里面

不让第三方网站访问到用户 Cookie。 可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送，可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。

SQL

所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令.

防范方法：

永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等。

永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。

永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。

应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装

sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky,网站平台就有亿思网站安全平台检测工具。

websocket是什么

适用于客户端和服务器端需要相互主动发大量数据的场景(网页游戏、网页聊天室)。浏览器在TCP三次握手建立连接之后，会统一使用HTTP协议先进行一次通信。如果是普通的HTTP请求，那后续双方就还是HTTP；如果是想建立websocket连接，就会带一些特殊的header头：

Connection:upgrade//升级协议
Upgrade:WebSocket//升级成websocket
Sec-WebSocket-Key:xxx//随机生成的base64码

走websocket握手流程，把base64码用一种公开的算法变成另一段字符串放在HTTP响应头中(Sec-WebSocket-Accpet),同时返回101(协议切换)。浏览器接收后再把码转回来，和发出是比较一致则验证通过。

websocket连接允许客户端和服务器之间进行全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端。websocket只需要建立一次连接，就可以一直保持连接状态

字段

opcode:什么类型的数据帧。1是string，2是2进制，8是关闭连接的信号。
payload:存放的是我们真正想要传输的数据的长度，单位是字节。
payload data:存放真正要传输的数据。

前端计网http总结