golang 内存和调度

百度欠缺问题

golang数据结构

# 理解session、token、cookie、JWT

Tags: 鉴权, 项目内容

Published: 2024年6月22日

# Cookie

- cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
- cookie 由服务器生成，发送给浏览器，浏览器把 cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。由于 cookie 是存在客户端上的，所以浏览器加入了一些限制确保 cookie 不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的 cookie 数量是有限的。

# Session

## **概念**

Session（会话）是在客户端和服务器之间保持状态的机制，通常用来存储用户会话信息，如登录状态。

## **工作机制**

- 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
- 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
- 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
- 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

**优点：**

- 简单易用，适合单机应用。
- 服务器端存储会话信息，便于管理和控制。

**缺点：**

- 依赖服务器存储，无法跨服务器或跨数据中心共享会话状态（除非使用共享存储）。
- 对于大型分布式系统，扩展性较差。

# Token

## 工作机制

- 客户端使用用户名和密码请求登录。
- 服务端收到请求，验证用户名和密码。
- 验证成功后，服务端会签发一个token，再把这个token返回给客户端。
- 客户端收到token后可以把它存储起来，比如放到cookie中。
- 客户端每次向服务端请求资源时需要携带服务端签发的token，可以在cookie或者header中携带。
- 服务端收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据。

**优点：**

- 无状态，客户端持有 Token，不依赖服务器存储会话信息，适合分布式系统。
- 易于扩展，Token 可以在不同服务之间共享认证信息。

**缺点：**

- Token 一旦泄露，可能被滥用。
- Token 的管理和刷新需要额外的机制。

# JWT

## **概念**

JWT 是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间传递声明信息。通常用于身份认证和信息交换。

## 工作机制

JWT由三部分组成:头部(Header)、载荷(Payload)和签名(Signature)。它们通过点号"."分隔。

1. 头部(Header):头部通常由两部分组成，声明使用的加密算法和类型。例如:{"alg":"HS256","typ":"JWT"}

> 这个头部使用Base64编码后会成为JWT的第一部分
> 
1. 载荷(Payload):载荷是]WT的第二部分，包含了需要传输的用户信息和其他声明。例如:{"sub":"1234567890""name": "John Doe","admin": true}。

> 载荷也会经过Base64编码，
> 
1. 签名(Sianature):签名是JWT的第三部分，用于验证JWT的真实性和完整性。签名使用头部和载荷，以及预先约定的密钥(只有服务器知道)进行加密。

> 加密后的签名会与头部和载荷一起组成JWT的第三部分。
> 

当客户端发送请求时，将JWT放在请求的头部(通常是"Authorization"字段)，服务器收到请求后，会对]WT进行解析和验证。通过对比签名和验证密钥，服务器可以确定JWT是否被篡改过，从而判断请求的合法性。这就是JWT的简单原理，它通过在客户端和服务器之间传递可信的JSON令牌来进行身份验证和授权。

## JWT与其他认证技术的比较比如cookie和session相比有什么优势?

JWT 天然具有完美的水平扩缩能力，JWT令牌是多方系统中一种优秀的凭证载体，它不需要任何一个服务节点保留任何一点状态信息，就能够保障认证服务与用户之间的承诺是双方当时真实意图的体现，是准确、完整、不可改、且不可抵赖的。同时，由于 JWT本身可以携带少量信息，这十分有利于 RESTfUI API 的设计，能够较容易地做成无状态服务，在做水平扩展时就不需要像前面 Cookie-Session 方案那样考虑如何部署的问题。

## JWT有哪些缺点

- **令牌难以主动失效:**JWT 令牌一旦签发，理论上就和认证服务器再没有什么瓜葛了，在到期之前就会始终有效，除非服务器部署额外的逻辑去处理失效问题，这对某些管理功能的实现是很不利的。譬如一种颇为常见的需求是:要求一个用户只能在一台设备上登录，在 B设备登录后，之前已经登录过的 A 设备就应该自动退出。如果采用 JWT，就必须设计一个"黑名单”的额外的逻辑，用来把要主动失效的令牌集中存储起来，而无论这个黑名单是实现在 Session、Redis 或者数据库中，都会让服务退化成有状态服务，降低了JT 本身的价值，但黑名单在使用 JT 时依然是很常见的做法，需要维护的黑名单一般是很小的状态量，许多场景中还是有存在价值的。
- **只能携带相当有限的数据:**HTTP 协议并没有强制约束 Header 的最大长度，但是，各种服务器、浏览器都会有自己的约束，譬如 Tomcat 就要求 Header 最大不超过 8KB，而在 Nginx 中则默认为 4KB，因此在令牌中存储过多的数据不仅耗费传输带竞，还有额外的出错风险。

理解session、token、cookie、JWT

# 值类型和引用类型的区别

Tags: Golang

# 简介

在 Go 语言中，类型可以分为引用类型和值类型。这两类类型在内存分配、效率和使用方式上有不同的特点和性能表现。



## 值类型

值类型通常直接存储其值，并在赋值或传递时创建其副本。

**常见的值类型**

- **基本类型：`int`, `float64`, `bool`, `string`**
- **结构体类型（`struct`）**
- **数组类型（`array`）**

**行为特点**

- **赋值：**赋值或传递时，会复制整个值，生成独立的副本。
- **存储位置：**通常存储在栈上，但是大型值类型（如大数组）可能会存储在堆上（由编译器决定*escape analysis*）。
- **变化彼此不影响：**副本的变化不会影响原值，反之亦然。

## 引用类型

引用类型存储的是指向值的指针，因此赋值或传递时复制的是指针，而不是值本身。

**常见的引用类型**

- **指针类型（`pointer`）**
- **切片类型（`slice`）**
- **映射类型（`map`）**
- **通道类型（`chan`）**
- **函数类型（`func`）**

**行为特点**

- **赋值：赋值或传递时，只复制指针，因此多个引用可以指向同一个底层数据。**
- **存储位置：通常存储在堆上。**
- **变化会相互影响：一个引用的变化会影响到所有指向同一对象的引用。**

# 性能方面的区别

## 内存和速度

- **值类型**由于直接存储值，不需要间接寻址，所以在读取和写入时性能更高，尤其对于小型数据结构。但由于赋值和传递时会复制整个值，如果值类型的大小很大，可能会导致较高的内存开销和性能开销。
- **引用类型**由于只存储指针，赋值和传递时开销较低，适用于大型复合数据结构。但是，访问引用类型需要间接寻址，可能会略微增加访问时间。

## 内存分配

- **值类型**在赋值时会在栈上创建副本，常用于较小的数据结构。当值类型很大时，可能会因为栈空间不足被分配到堆上。
- **引用类型**储存在堆上，使用垃圾回收机制管理内存，因而在内存分配和回收时有一定的开销。但由于只传递指针，减少了数据复制的开销。


![Untitled.png](https://cdn.jsdelivr.net/gh/Gypsophila1006/img/img/ef3ff88248e280834c2f10149aec8c01.Untitled.webp)

## 使用场景

- **值类型**适用于数据较小且需要频繁复制的场景，例如基本类型和简单的结构体。
- **引用类型**适用于大型数据结构或需要共享状态的场景，例如切片、映射和通道。

## 选择的考量因素

在实际开发中，选择值类型还是引用类型应根据具体的性能需求和用例场景：

- **性能：**如果传递的单位数据非常大，应考虑使用引用类型以节省内存和提升性能。
- **数据共享：**如果需要多个实例共享同一个数据，应使用引用类型以确保数据一致性。
- **安全性：**如果不希望数据被意外修改，可以使用值类型，以确保每个副本都是独立的。

了解值类型和引用类型的特性及其在性能上的差异，有助于选择适合的方案，从而优化代码的内存和执行效率。

值类型和引用类型的区别

在这里，我记录学习后端技术、实习经验和个人思考，也会随性分享一些生活琐事和吐槽。如果你和我有相似的兴趣或经历，欢迎随时交流！