Linux网络--HTTP cookie 与 session

大家好，好久不见，上一次我们学习了HTTP，今天我们再学习一些HTTP的补充知识，那么话不多说，我们开始今天的学习：

目录

[HTTP cookie 与 session](#HTTP cookie 与 session)

[1. 引入 HTTP Cookie](#1. 引入 HTTP Cookie)

[1.1 定义](#1.1 定义)

[1.2 工作原理](#1.2 工作原理)

[1.3 分类](#1.3 分类)

[1.4 安全性](#1.4 安全性)

[1.5 用途](#1.5 用途)

[2. 认识 cookie](#2. 认识 cookie)

[2.1 基本格式](#2.1 基本格式)

[2.2 完整的 Set-Cookie 示例](#2.2 完整的 Set-Cookie 示例)

[2.3 注意事项](#2.3 注意事项)

[2.4 Cookie 的生命周期](#2.4 Cookie 的生命周期)

[2.5 安全性考虑](#2.5 安全性考虑)

[2.6 单独使用 Cookie，有什么问题？](#2.6 单独使用 Cookie，有什么问题？)

[3. 引入 HTTP Session](#3. 引入 HTTP Session)

[3.1 定义](#3.1 定义)

[3.2 工作原理](#3.2 工作原理)

[3.3 安全性](#3.3 安全性)

[3.4 超时和失效](#3.4 超时和失效)

[3.5 用途](#3.5 用途)

[4. 总结](#4. 总结)

HTTP cookie与session

一种关于登录的场景演示

当我们在网页中进行登陆账号之后，会在一段时间内都保持这个登录状态，那么网页是如何认识我这个登录用户的？并且 HTTP 是一个无连接、无状态的协议，每次请求都需要建立新的连接，且不适合保存用户的浏览信息，那么到底该如何才能实现这个功能呢？

1. 引入****HTTP Cookie

关于这两个问题，我们可以在接下来的学习中找到答案

1.1 定义

HTTP Cookie （也称为 Web Cookie 、浏览器 Cookie 或简称 Cookie ）是服务器发送到用户浏览器并保存在浏览器上的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态、记录用户偏好等。

原来浏览器是通过cookie来保存登录信息的，那么它是怎样工作的呢？我们继续往下看：

1.2 工作原理

1. 当用户第一次访问网站时，服务器会在响应的 HTTP 头中设置 Set-Cookie 字段，用于发送 Cookie 到用户的浏览器。
2. 浏览器在接收到 Cookie 后，会将其保存在本地（通常是按照域名进行存储）。
3. 在之后的请求中，浏览器会自动在 HTTP 请求头中携带 Cookie 字段，将之前保存的 Cookie 信息发送给服务器。

1.3 分类

1. 会话 Cookie （ Session Cookie ） ：在浏览器关闭时失效。
2. 持久 Cookie （ Persistent Cookie ） ：带有明确的过期日期或持续时间，可以跨多个浏览器会话存在。
   如果 cookie 是一个持久性的 cookie ，那么它其实就是浏览器相关的，特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容，因为 cookie 文件通常以二进制或 sqlite 格式存储。一般我们查看，直接在浏览器对应的选项中直接查看即可。
   类似于下面这种方式：

1.4 安全性

由于 Cookie 是存储在客户端的，因此存在被篡改或窃取的风险

1.5 用途

用户认证和会话管理 ( 最重要 )
跟踪用户行为
缓存用户偏好等
比如在 chrome 浏览器下，可以直接访问： chrome://settings/cookies

2. 认识****cookie

HTTP 存在一个报头选项： Set-Cookie , 可以用来进行给浏览器设置 Cookie 值。
在 HTTP 响应头中添加，客户端（如浏览器）获取并自行设置并保存 Cookie 。

2.1 基本格式

C++
Set-Cookie: <name>=<value>
其中 <name> 是 Cookie 的名称，<value> 是 Cookie 的值。

2.2 完整的Set-Cookie示例

C++
Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00
UTC; path=/; domain=.example.com; secure; HttpOnly

时间格式必须遵守 RFC 1123 标准，具体格式样例： Tue, 01 Jan 2030 12:34:56 GMT 或者 UTC( 推荐 ) 。
关于时间解释

Tue : 星期二（星期几的缩写）
, : 逗号分隔符
01 : 日期（两位数表示）
Jan : 一月（月份的缩写）
2030 : 年份（四位数）
12:34:56 : 时间（小时、分钟、秒）
GMT : 格林威治标准时间（时区缩写）
GMT （格林威治标准时间）和 UTC （协调世界时）是两个不同的时间标准，但它们
在大多数情况下非常接近，常常被混淆。以下是两者的简单解释和区别：
1. GMT（格林威治标准时间）：
GMT 是格林威治标准时间的缩写，它是以英国伦敦的格林威治区为基准的世界时间标准。
GMT 不受夏令时或其他因素的影响，通常用于航海、航空、科学、天文等领域。
GMT 的计算方式是基于地球的自转和公转。
2. UTC（协调世界时）：
UTC 全称为 " 协调世界时 " ，是国际电信联盟 (ITU) 制定和维护的标准时间。
UTC 的计算方式是基于原子钟，而不是地球的自转，因此它比 GMT 更准确。据称，世界上最精确的原子钟 50 亿年才会误差 1 秒。
UTC 是现在用的时间标准，多数全球性的网络和软件系统将其作为标准时间。
GMT 和 UTC 的英文全称以及相关信息如下：
1. GMT（格林尼治标准时间）
英文全称： Greenwich Mean Time
GMT 是指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义为通过那里的经线。理论上来说，格林尼治标准时间的正午是指当太阳横穿格林尼治子午线时的时间。
但值得注意的是，地球的自转是有些不规则的，且正在缓慢减速。因此，格林尼治时间已经不再被作为标准时间使用。
2. UTC（协调世界时）
英文全称： Coordinated Universal Time
UTC 是最主要的世界时间标准，其以原子时秒长为基础，在时刻上尽量接近于格林尼治标准时间。
UTC 被广泛使用在计算机网络、航空航天等领域，因为它提供了非常准确和可靠的时间参考。
总结来说， GMT 和 UTC 都曾是或现在是国际上重要的时间标准，但由于地球自转的不规则性和原子钟的精确性，UTC 已经成为了全球性的标准时间 ，而 GMT 则更多被用作历史和地理上的参考
计算方式： GMT 基于地球的自转和公转，而 UTC 基于原子钟。
准确度：由于 UTC 基于原子钟，它比基于地球自转的 GMT 更加精确。
在实际使用中， GMT 和 UTC 之间的差别通常很小，大多数情况下可以互换使用。但在需要高精度时间计量的场合，如科学研究、网络通信等，UTC 是更为准确的选择。
关于其他可选属性的解释
expires=<date> 要验证 ：设置 Cookie 的过期日期 / 时间。如果未指定此属性，则 Cookie 默认为会话 Cookie ，即当浏览器关闭时过期。
path=<some_path> 要验证 ：限制 Cookie 发送到服务器的哪些路径。默认为设置它的路径。
domain=<domain_name> 了解即可 ：指定哪些主机可以接受该 Cookie 。默认为设置它的主机。
secure 了解即可 ：仅当使用 HTTPS 协议时才发送 Cookie 。这有助于防止Cookie 在不安全的 HTTP 连接中被截获。
HttpOnly 了解即可 ：标记 Cookie 为 HttpOnly ，意味着该 Cookie 不能被客户端脚本（如 JavaScript ）访问。这有助于防止跨站脚本攻击（ XSS ）。
以下是对 Set-Cookie 头部字段的简洁介绍：

属性	值	描述
username	peter	这是 Cookie 的名称和值，标识用户名为 "peter"。
expires	Thu, 18 Dec 2024 12:00:00 UTC	指定 Cookie 的过期时间。在这个例子中，Cookie 将在 2024 年 12 月 18 日 12:00:00 UTC 后过期。
path	/	定义 Cookie 的作用范围。这里设置为根路径/，意味着 Cookie 对.example.com域名下的所有路径都可用。
domain	.example.com	指定哪些域名可以接收这个 Cookie。点前缀（.）表示包括所有子域名。
secure	-	指示 Cookie 只能通过 HTTPS 协议发送，不能通过 HTTP 协议发送，增加安全性。
HttpOnly	-	阻止客户端脚本（如 JavaScript）访问此 Cookie，有助于防止跨站脚本攻击（XSS）。

2.3 注意事项

每个 Cookie 属性都以分号（ ; ）和空格（ ）分隔。
名称和值之间使用等号（ = ）分隔。
如果 Cookie 的名称或值包含特殊字符（如空格、分号、逗号等），则需要进行 URL 编码。

2.4 Cookie****的生命周期

如果设置了 expires 属性，则 Cookie 将在指定的日期 / 时间后过期。
如果没有设置 expires 属性，则 Cookie 默认为会话 Cookie ，即当浏览器关闭时过期。

2.5 安全性考虑

使用 secure 标志可以确保 Cookie 仅在 HTTPS 连接上发送，从而提高安全性。
使用 HttpOnly 标志可以防止客户端脚本（如 JavaScript ）访问 Cookie ，从而防止 XSS 攻击。
通过合理设置 Set-Cookie 的格式和属性，可以确保 Cookie 的安全性、有效性和可访问性，从而满足 Web 应用程序的需求。

2.6 单独使用Cookie，有什么问题？

通过上文对cookie报文的介绍，我们可以知道cookie报文里是可能会有用户的私密数据呢？比如，用户名密码，浏览痕迹等。本质问题在于这些用户私密数据在浏览器(用户端)保存，非常容易被人盗取，更重要的是，除了被盗取，还有就是用户私密数据也就泄漏了。

3. 引入****HTTP Session

这时就协议session了，下面我们学习一下session：

3.1 定义

HTTP Session 是服务器用来跟踪用户与服务器交互期间用户状态的机制。由于 HTTP 协议是无状态的（每个请求都是独立的），因此服务器需要通过 Session 来记住用户的信息。

3.2 工作原理

当用户首次访问网站时，服务器会为用户创建一个唯一的 Session ID ，并通过 Cookie 将其发送到客户端。
客户端在之后的请求中会携带这个 Session ID ，服务器通过 Session ID 来识别用户，从而获取用户的会话信息。
服务器通常会将 Session 信息存储在内存、数据库或缓存中。

3.3 安全性

与 Cookie 相似，由于 Session ID 是在客户端和服务器之间传递的，因此也存在被窃取的风险。
但是一般虽然 Cookie 被盗取了，但是用户只泄漏了一个 Session ID ，私密信息暂时没有被泄露的风险
Session ID 便于服务端进行客户端有效性的管理，比如异地登录。可以通过 HTTPS 和设置合适的 Cookie 属性（如 HttpOnly 和 Secure ）来增强安全性。

3.4 超时和失效

Session 可以设置超时时间，当超过这个时间后， Session 会自动失效。服务器也可以主动使 Session 失效，例如当用户登出时。

3.5 用途

用户认证和会话管理
存储用户的临时数据（如购物车内容）
实现分布式系统的会话共享（通过将会话数据存储在共享数据库或缓存中）

4. 总结

HTTP Cookie 和 Session 都是用于在 Web 应用中跟踪用户状态的机制。 Cookie 是存储在客户端的，而 Session 是存储在服务器端的。它们各有优缺点，通常在实际应用中会结合使用，以达到最佳的用户体验和安全性。
好了，以上就是今天我们学习的所有内容，感觉对 HTTP 协议的认识又加深了，如果感到有收获的话还请点赞收藏，那我们下次再见！