【重学计网】你真的了解Cookie、Session、Token、JWT吗？一起来聊聊网络安全知识

Cookie 和 Session 有什么区别？

• 存储位置：Cookie的数据存储在客户端（通常是浏览器）。当浏览器向服务器发送请求时，会自动附带Cookie中的数据。Session的数据存储在服务器端。服务器为每个用户分配一个唯一的Session ID，这个ID通常通过Cookie或URL重写的方式发送给客户端，客户端后续的请求会带上这个Session ID，服务器根据ID查找对应的Session数据。
• 安全性：Cookie相对不安全，因为数据存储在客户端，容易受到XSS（跨站脚本攻击）的威胁。Session通常认为比Cookie更安全，因为敏感数据存储在服务器端。

那token是什么？

用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户

如果客户端禁用了cookie，session还能用吗？

不能 客户端浏览器禁用 Cookie 时，服务器将无法把会话 ID 发送给客户端，客户端也无法在后续请求中携带会话 ID 返回给服务器，从而导致服务器无法识别用户会话。

但是，有方法可以绕过这个问题

• URL重写：每当服务器响应需要保持状态的请求时，将Session ID附加到URL中作为参数。例如，原本的链接http://example.com/page变为http://example.com/page;jsessionid=XXXXXX，服务器端需要相应地解析 URL 来获取 Session ID，并维护用户的会话状态。这种方式的缺点是URL变得不那么整洁，且如果用户通过电子邮件或其他方式分享了这样的链接，可能导致Session ID的意外泄露。

什么数据应该存在到cookie，什么数据存放到 Localstorage

Cookie 适合用于在客户端和服务器之间传递数据、跨域访问和设置过期时间，而 LocalStorage 适合用于在同一域名下的不同页面之间共享数据、存储大量数据和永久存储数据。

JWT 令牌和传统方式有什么区别？

• 无状态性：JWT是无状态的令牌，不需要在服务器端存储会话信息。相反，JWT令牌中包含了所有必要的信息，如用户身份、权限等。
• 安全性：JWT使用密钥对令牌进行签名，只有持有正确密钥的服务器才能对令牌进行验证和解析。比传统的基于会话和Cookie的验证更加安全
• 跨域支持：JWT令牌通过在请求的头部或参数中携带JWT令牌，可以实现无需Cookie的跨域身份验证

JWT 令牌都有哪些字段？

JWT令牌由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature）。其中，头部和载荷均为JSON格式，使用Base64编码进行序列化，而签名部分是对头部、载荷和密钥进行签名后的结果。

JWT 令牌为什么能解决集群部署，什么是集群部署？

在传统的基于会话和Cookie的身份验证方式中，会话信息通常存储在服务器的内存或数据库中。但在集群部署中，不同服务器之间没有共享的会话信息，这会导致用户在不同服务器之间切换时需要重新登录，或者需要引入额外的共享机制（如Redis）

当用户进行登录认证后，服务器将生成一个JWT令牌并返回给客户端。客户端在后续的请求中携带该令牌，服务器可以通过对令牌进行验证和解析来获取用户身份和权限信息，而无需访问共享的会话存储。

jwt的缺点是什么？

JWT 一旦派发出去，在失效之前都是有效的，没办法即使撤销JWT。

要解决这个问题的话，得在业务层增加判断逻辑，比如增加黑名单机制。使用内存数据库比如 Redis 维护一个黑名单，如果想让某个 JWT 失效的话就直接将这个 JWT 加入到 黑名单 即可。然后，每次使用 JWT 进行请求的话都会先判断这个 JWT 是否存在于黑名单中

前端是如何存储JWT的？（单点登录？）

在传统的基于会话和Cookie的身份验证方式中，会话信息通常存储在服务器的内存或数据库中。但在集群部署中，不同服务器之间没有共享的会话信息，这会导致用户在不同服务器之间切换时需要重新登录，或者需要引入额外的共享机制（如Redis） 举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

所以解决方案服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

客户端收到服务器返回的 JWT，可以储存在 Local Storage 里面，也可以储存在Cookie里面，还可以存储在Session Storage里面。

什么是跨域访问问题，如何解决？

跨域访问问题（Cross-Origin Resource Sharing，CORS）是由浏览器的同源策略引起的安全限制。同源策略是一种浏览器安全策略，它要求网页中的所有资源必须来自同一个域名、协议和端口，否则浏览器会阻止跨域的资源请求。 所以，如果在浏览器访问过程中发现域名、端口或者协议不同的时候，就会出现跨域问题。

1. 域名不同：如从a.com的页面请求b.com的资源。
2. 协议不同：如从http的页面请求https的资源。
3. 端口不同：当页面的端口与请求的资源的端口不一致时，同样会触发跨域问题。

解决跨域访问问题的方法有以下几种：

1. CORS（推荐）：CORS是一种机制，通过在服务器端设置相应的响应头来解决跨域问题。服务器在响应中添加Access-Control-Allow-Origin头，指定允许跨域访问的域名或通配符*，使得浏览器可以放行跨域请求。CORS是目前最常用的解决跨域问题的方式，支持现代浏览器。

@CrossOrigin(origins = "*")
public class HollisTestController {
    
}

1. JSONP：JSONP是一种跨域通信的技术，它利用<script>标签可以跨域访问的特性，通过动态创建<script>标签来加载跨域资源，服务器返回一个包含回调函数的JavaScript脚本，客户端通过回调函数处理响应数据。不过JSONP只支持GET请求，且只能用于跨域请求JSON数据。
2. 代理服务器：可以通过在同源域名下设置一个代理服务器，实现跨域访问。前端将请求发送给代理服务器，代理服务器再转发请求给目标服务器，并将响应返回给前端，从而绕过跨域限制。这种方式需要部署额外的代理服务器，适用于一些特殊情况。

什么是CDN，为什么他可以做缓存？

CDN是Content Delivery Network的缩写，翻译成内容分发网络（这个中文名我一直记不住），它主要是通过将内容存储在全球各地的边缘节点上，以就近原则向用户提供内容。 CDN可以做缓存是因为它在全球范围内部署了多个边缘节点，这些节点分布在不同的地理位置，靠近用户所在的区域。当用户请求某个资源（例如网页、图片、视频等），CDN会根据用户的位置，将资源从最近的边缘节点提供给用户。 比如说我在内蒙古呼和浩特，我想要访问部署在上海的淘宝服务器，这时候发起一次请求的话，就需要从呼和浩特把请求发送到上海。那如果能够更近一点的区域快速拿到一些资源的话，就可以不用这么慢了。 那么CDN刚好是可以部署在很多地方的边缘节点，你比如说阿里云的CDN（非广告，哈哈哈），在全球拥有3200+节点。中国内地（大陆）拥有2300+节点，覆盖31个省级区域；中国香港、中国澳门、中国台湾、其他国家和地区拥有900+节点，覆盖70多个国家和地区。

如果很多静态资源可以放到CDN上面，那么就可以就近的访问到CDN，然后快速的获取到这些静态的资源。 CDN具有广泛的应用场景，可实现图片小文件、大文件下载和视音频点播业务类型的存储，以实现加速的目的。 用户首次访问这些资源的时候，CDN会将资源从服务器获取到，并将其缓存到边缘节点上。当其他用户在同一地区请求相同的资源时，CDN会直接从边缘节点返回缓存的副本，而不必再次访问源服务器。这样可以减少网络延迟和带宽消耗，提高内容的传输速度和响应性能。

CDN它怎么才能请求到最近的服务器

CDN本身是提供了CDN节点存放静态资源，然后让访问速度更快。 但是，究竟如果基于当前位置选择位置最合适的CDN节点呢？

此时DNS就要登场了。做域名解析来找到当前位置最合适的CDN节点，北京的找北京地区的CDN节点，上海的定位到上海。

如果我的内容对你有帮助，请辛苦动动您的手指为我点赞，评论，收藏。感谢大家!!