HTTP的协议有什么特点？
HTTP协议基于文本传输的，支持不同的****数据格式，例如HTML、JSON、XML等数据格式，并且http是无状态的，每个http请求之间相互独立，采用了请求-应答模式，有很好的扩展性，可以通过扩展头部、方法等支持行方式
HTTP报文格式？怎么分割
http的报文格式分为请求头、请求行、请求体，请求头包含了请求方式、url、http版本，请求行包含了key-value对的信息，有connection，content-lenth等字段，请求体包含了实际的请求数据；请求头和请求行通过/r/n进行分割，请求行和请求体通过一行空白行进行分割
HTTP有什么方法？
GET、PUT、DELETE、post、head、options、trace、connect
哪些http方法是安全的？哪些是幂等的
get、head是安全的 post、put、delete是不安全的
get、head、put、delete是幂等的 post是不幂等的
GET和POST请求的区别？追问：GET请求一定是安全且幂等的吗？
get请求是从服务器获取资源，post请求向服务器提交数据，
get请求是读操作，是安全且幂等的；post请求因为会修改服务器的资源，且多次post请求会创建多个资源，所以是不安全且不幂等的 get请求一般是将请求参数放在url的查询字符串中，浏览器对url的长度有限制，所以get请求的请求参数有长度限制。post请求的数据放在请求体，post请求的请求参数没有长度限制
HTTP有哪些状态码？
100类：属于提示信息，为协议处理中的中间状态 200类：表示服务器成功处理客户端的请求
- 200：表示成功处理，返回期望的结果
- 204：与200状态码相似，但是响应头没有body数据
- 206：http分块下载或断点续传的几次， 300类：表示请求的资源发生了变动，需要客户端用新的URL重新发送请求，就是重定向
- 301：永久性的重定向，后续请求可以直接重定向访问
- 302：临时访问，
- 304： 400类：表示客户端发送的报文有误，服务器无法处理
- 403：请求的权限不够
- 404：请求的资源不存在 500类：表示服务器处理 时内部发生了错误，属于服务器端的错误码
什么情况下会出现502错误码？
502（Bad GateWay）表示码表示服务器在充当网关或代理时，在尝试满足请求时从它访问的入站服务器接收到无效响应 如果客户端访问服务是通过nginx来反向代理到应用服务器，那么如果应用服务器出现故障，导致nginx无法从应用服务获得响应，这时候nginx就会返回502错误码给客户端
有个服务出现504错误码，这个服务出现了什么问题
504是网关超时错误，通过nginx将请求代理到后端应用，后端程序没有在规定时间内返回数据，需要开发检查接口超时问题，比如是否出现死循环、sql慢查询等
重定向是哪一类状态码？临时重定向和永久重定向有什么区别？
重定向是300类状态码，301表示永久重定向，302表示临时重定向 永久重定向，客户端会记忆重定向后的url，下次访问的时候不需要访问旧url，直接跳转新url访问 临时重定向，客户端会收到302状态码，不会记忆重定向后的url，下次访问依旧访问旧url，再跳转到新的url
HTTP1.1和2.0的区别
2.0引入stream概念，可以在同一个tcp连接中，实现并发传输，而1.1不能并发传输，必须在一个请求结束之后才能进行下一个请求应答，浏览器是通过建立多个tcp连接，实现http1.1的并发，比较消耗内存
报文改进，1.1发生的是文本数据，2.0发生二进制数据，通过HPACK算法压缩HTTP头部，提高了传输效率
http2.0支持服务器主动推送数据
HTTP2.0和HTTP3.0的区别？
HTTP2.0和HTTP3.0的最大区别是传输层使用的协议不同了，HTTP2.0使用的是TCP协议连接，HTTP3.0使用UDP协议；
HTTP2.0会出现TCP队头阻塞问题，（http2.0的tcp阻塞问题，是因为http2.0的并发传输是在一条TCP连接上实现的，在传输过程中，如果某个stream发生了丢包，服务端不仅不能处理这个stream，也不会处理其他的stream，必须等丢失的包重传，才能继续处理其他stream，这个就发生了tcp队头阻塞），但是HTTP3.0通过一个在UDP协议上实现了一个可靠的QUIC协议，当stream发生丢包时，只会阻塞这个stream，其他stream不会受影响
http3.0建立连接比http2.0高效，http3.0：3次握手就能建立连接+TLS握手成功；http2.0需要3次TCP握手+TLS四次握手
http3.0在网络切换的环境下无需重新建立连接，通过在应用层的唯一id来确定连接
简述JWT的原理和校验机制
jwt的数据个数是header.payload.signature，头部、负载、签名三部分组成，
header包含：令牌的类型以及令牌签名的算法
payload：向服务器传递的数据，比如包含认证信息
签名：对前面两部分的签名，防止数据篡改（使用在Header中公开的特点签名算法，通过特定的密钥（由服务器进行保密），对前面两部分进行加密计算
验证JWT令牌的流程：
- 服务端接收到客户端发来的JWT，取出header+payload，然后服务端根据自己的加密密钥进行加密计算
- 把加密的结果和客户端发来JWT的signature进行对比，如果完全相同，则表示前面两部分没有动，如果不相同表示被篡改了
- 当令牌没有被篡改后，服务端可以进行其它验证：令牌过期，用户是否有权限访问等
jwt令牌是由3个部分组成，分别是头部、负载、签名，头部包括类型和签名算法，负载包含了用户信息等数据，签名是对头部和负载两部分的签名，使用头部的签名算法，通过服务器的密钥对前面两部分内容进行加密计算
校验jwt的过程是服务端接收到客户端发过来的jwt令牌后，服务端会取出头部和负载数据，然后用自己的密钥对头部和负载进行加密计算，将得到的加密结果和客户端发送过来的jwt的签名机械能对比，如果相同，表示前面两部分没有内中间人篡改，这个时候服务器可以进行其他检查，比如检查jwt是否过期，如果没有问题，正常执行业务逻辑
什么是跨域？什么情况下会发生跨域？
当网页尝试访问不同源的资源的使用，就会发生跨域，只要域名、协议、端口这三个信息任意一个不同，都认为是不同源的URL 可以用跨域资源共享技术，在服务器需要的响应头上添加Access-Control-Allow-Origin的字段，
什么是Restful？RestFul请求的url有什么特点？
restful是一种api接口设计规范，用url定位资源，用http方法表示接口的动作，用http状态码表示接口处理的情况
HTTP和HTTPS有什么区别？
安全性：HTTP使用明文传输，HTTPS通过SSL/TLS协议对数据进行加密处理，提供更高的安全性和数据保护
建立连接：HTTP建立只需要TCP三次握手；HTTPS在TCP三次握手后还需要进行SSL/TLS的握手过程
端口：HTTP的端口是80；HTTPS的端口是443
证书：HTTPS需要使用数字证书来验证服务器的身份，并确保数据传输的安全性。证书由第三方机构颁发，用于证明服务器的身份和所有权。而HTTP没有使用证书进行身份验证和加密。
加密算法？
对称加密算法，非对称加密算法，哈希算法
HTTPS建立连接过程
- 第一次TLS握手：客户端发送一个client hello消息，消息里面有客户端使用的TLS版本号、支持的密码套件、客户端生成的随机数，
- 第二次TLS握手：当服务端接收到客户端的消息后，会返回Server Hello消息，有确认的TLS版本号，密码套件，服务端生成的随机数。接着发送Server Certificate给客户端，包含数字证书，发送Server Hello Done消息
- 校验证书：客户端收到服务端的数字证书的时候，会对校验服务端的证书，如果证书合法，客户端会从CA机构的公钥解密数字证书拿到服务端的公钥
- 第三次TLS握手：客户端再次生成一个随机数，用服务端的公钥加密后，通过client key exchange消息传给服务端。服务端通过私钥解密得到客户端的第二个随机数。这里有三个随机数了，双方根据这三个随机数生成对称密钥。生成密钥后，客户端发一个消息给服务端开始使用对称加密方式发送消息，并且对之前发送的数据做个摘要，再用对称加密算法加密，让服务端做个验证，确保对称密钥是否可用，以及之前的握手信息是否被篡改
- 第四次握手：服务端也是同样操作，发送消息告诉客户端开始用对称加密方式发送消息，并且对数据做个摘要，并用对称密钥进行加密，让客户端做个校验，如果双方都验证加密和解密都没问题，那么TLS四次握手正式完成了。
HTTPS过程中进行了多少次非对称加密？多少次对称加密？
- https握手之前：
- 服务端向CA机构注册证书时，CA机构会用CA私钥对服务端的公钥进行签名，形成数字证书，这里涉及到1次非对称加密
- https握手期间：
- 客户端向服务端的公钥加密随机数，服务端再用私钥进行解密，这里涉及1次非对称加密
- 客户端和服务端生成对称密钥后，都需要对之前握手的数据做个摘要，并用对称密钥加密一下，这个过程客户端和服务端都涉及到，所以HTTPS握手期间用了两次对称加密，客户端和服务端都做了一次
- https握手完成之后：
- https数据传输期间都是用对称密钥进行加密和解密
SSL握手流程为什么要使用非对称加密？
为了保护对称密钥的安全
为什么HTTPS不用非对称加密算法加密HTTP报文？
非对称加密使用到了公钥和私钥，加密和解密的过程相对较慢， 不适合大数据的加密传输，相比之下对称加密算法比较快，适合大数据的加密，而HTTP报文包含大量的数据，如果使用非对称算法会导致性能下降和延迟增加
Https会对url进行加密，url属于http报文的头部信息，https会对整个http报文都加密，所以https是会对url加密的