一、常见的Http Method有哪些，使用场景分别是什么

二、单机情况下 http无状态解决方案，cookie和session 

三、分布式业务场景的常见登录解决方案JWT

四、说下常用浏览器输入一个url到用户看到结果，中间经过哪些流程

五、什么是浏览器的同源策略和跨域 

六、为什么会出现跨域，有什么常见的解决方案 

一、常见的Http Method有哪些，使用场景分别是什么

http1.0定义了三种：
​
    GET: 向服务器获取资源，比如常见的查询请求
    POST: 向服务器提交数据而发送的请求
    Head: 和get类似，返回的响应中没有具体的内容，用于获取报头
    
http1.1定义了六种
​
    PUT：一般是用于更新请求，比如更新个人信息、商品信息全量更新
    PATCH：PUT 方法的补充,更新指定资源的部分数据
    DELETE：用于删除指定的资源
    OPTIONS: 获取服务器支持的HTTP请求方法,服务器性能、跨域检查等
    CONNECT: 方法的作用就是把服务器作为跳板，让服务器代替用户去访问其它网页，之后把数据原原本本的返回给用户，网页开发基本不用这个方法，如果是http代理就会使用这个，让服务器代理用户去访问其他网页，类似中介
    TRACE：回显服务器收到的请求，主要用于测试或诊断 

常见http状态码解析 

浏览器向服务器请求时，服务端响应的消息头里面有状态码，表示请求结果的状态
​
分类
1XX: 收到请求，需要请求者继续执行操作，比较少用
​
2XX: 请求成功，常用的 200
​
3XX: 重定向，浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取；
​
好处：网站改版、域名迁移等，多个域名指向同个主站导流
必须记住： 301：永久性跳转，比如域名过期，换个域名 302：临时性跳转
​
4XX: 客服端出错，请求包含语法错误或者无法完成请求
必须记住： 
  400: 请求出错，比如语法协议 
  403: 没权限访问 
  404: 找不到这个路径对应的接口或者文件 
  405: 不允许此方法进行提交，Method not allowed，比如接口一定要POST方式，而你是用了GET
​
5XX: 服务端出错，服务器在处理请求的过程中发生了错误
必须记住： 
    500: 服务器内部报错了，完成不了这次请求 
    503: 服务器宕机 

二、单机情况下 http无状态解决方案，cookie和session 

说下Cookie和Session的区别和联系:
        Cookie数据保存在客户端，session数据保存在服务端
        Cookie不是很安全，容易泄露，不能直接明文存储信息
        Cookie大小和数量存储有限制 

你们公司C端业务登录的是怎样做的（业务量大，集群部署）?

        部分业务是采用redis替代本身的tomcat单机session (业务需要高度可控)

        还有其他业务是使用JSON Web token (C端普通业务)

三、分布式业务场景的常见登录解决方案JWT

JWT 是一个开放标准，它定义了一种用于简洁，自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。 可以使用 HMAC 算法或者是 RSA 的公钥密钥对进行签名

JWT格式组成 头部、负载、签名
header+payload+signature
头部：主要是描述签名算法
负载：主要描述是加密对象的信息，如用户的id等，也可以加些规范里面的东西，如iss签发者，exp 过期时间，sub 面向的用户
签名：主要是把前面两部分进行加密，防止别人拿到token进行base解密后篡改token
简单来说: 就是通过一定规范来生成token，然后可以通过解密算法逆向解密token，这样就可以获取用户信息 

为啥使用这个呢，有什么优缺点？ 

优点:
生产的token可以包含基本信息，比如id、用户昵称、头像等信息，避免再次查库
存储在客户端，不占用服务端的内存资源，使用加解密的方式进行校验，在分布式业务中能较好的提高性能和节省空间

缺点:
token是经过base64编码，所以可以解码，因此token加密前的对象不应该包含敏感信息，如用户权限，密码等
如果没有服务端存储，则不能做登录失效处理，除非服务端改秘钥

生成的token，在客户端或者浏览器是怎么存储的
    可以存储在cookie，localstorage和sessionStorage里面

JWT的使用见下面这篇博文:

分布式应用下登录检验解决方案 JWT+登录拦截器开发+用户信息传递_这是王姑娘的微博的博客-CSDN博客

四、说下常用浏览器输入一个url到用户看到结果，中间经过哪些流程

     1、浏览器输入url, 解析url地址是否合法
​
　　2、浏览器检查是否有缓存, 如果有直接显示。如果没有跳到第三步。
​
　　3、在发送http请求前，需要域名解析（DNS解析），解析获取对应过的ip地址。
​
　　4、浏览器向服务器发起tcp链接，完成tcp三次握手
​
　　5、握手成功后，浏览器向服务器发送http请求
​
　　6、服务器收到处理的请求，将数据返回至浏览器
​
　　7、浏览器收到http响应。
​
　　8、浏览器解析响应。如果响应可以缓存，则存入缓存
​
　　9、浏览器进行页面渲染

五、什么是浏览器的同源策略和跨域 

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。

由Netscape提出的一个著名的安全策略。

当一个浏览器的两个tab页中分别打开来 百度和谷歌的页面

当浏览器的百度tab页执行一个脚本的时候会检查这个脚本是属于哪个页面的，

即检查是否同源，只有和百度同源的脚本才会被执行。

如果非同源，那么在请求数据时，浏览器会在控制台中报一个异常，提示拒绝访问。

同源策略是浏览器的行为，是为了保护本地数据不被JavaScript代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收 

六、为什么会出现跨域，有什么常见的解决方案 

跨域：浏览器同源策略 1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。 最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。所谓"同源"指的是"三个相同"

协议相同  http https
域名相同  www.wnn2011.net
端口相同  80  81

一句话：浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域

浏览器控制台跨域提示：
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. 

解决方法:
    .JSONP
    .页面这层再包装一层服务，目前最多就是nodejs
    .Http响应头配置允许跨域
        .nginx代理服务器
        .后端程序代码配置 

程序代码中处理 SpringBoot 通过拦截器配置     //表示接受任意域名的请求,也可以指定域名response.setHeader("Access-Control-Allow-Origin", request.getHeader("origin"));     //该字段可选，是个布尔值，表示是否可以携带cookieresponse.setHeader("Access-Control-Allow-Credentials", "true");     response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");     response.setHeader("Access-Control-Allow-Headers", "*");

nginx配置跨域操作，可以看看下面这篇博文:

Nginx从初级到高级的玩法_这是王姑娘的微博的博客-CSDN博客本博文主要介绍了Nginx从入门到熟悉的玩法，从Nginx快速安装-配置解读-文件服务器的配置-accesslog日志统计挖掘-站点访问量和高频url统计，到Nginx负载均衡玩法-兜底数据返回-浏览器跨域配置-服务端缓存配置-静态资源压缩，再到高级玩法之https认证-OpenResty下载限速-keepAlived高可用，全程实操配置+截图，通俗易懂~https://blog.csdn.net/wnn654321/article/details/122548679