HTTP协议——Cookie的相关概念和使用

Cookie的相关概念和使用

这里，我们需要来讲解一个不是完全属于HTTP协议中的内容，但是又和HTTP息息相关的。
即cookie，这是什么呢？我们其实经常可以在浏览器中看到相关cookie：

HTTP的无状态、无连接

我们需要回顾一下我们在HTTP中的一个很特别的概念：
HTTP协议是一个无状态、无连接的协议！要想搞清楚cookie存在的意义，我们需要把这个概念搞清楚，这样子才能明白为什么浏览器中要出现cookie。

1.HTTP的无连接
我们肯定是会很好奇，我们模拟HTTP协议通信的时候，不是都要连接的吗？不连接双方怎么进行通信呢？为什么要说HTTP是无连接的？

这里我们需要搞清楚：
HTTP协议是在应用层的！是我们用户或者服务器端直接进行使用的。
通信必然需要进行连接，但是我们得先搞清楚，负责连接的是谁？很清楚的是，我们在HTTP类底下放了一个TCP服务器！所以，负责连接的是TCP协议！不是HTTP。

基于HTTP通信的双方，都是根据协议内定好的标准，然后基于标准对数据做一系列的操作。这个协议本身是不负责进行连接的！

2.HTTP无状态
这个其实很好理解，就是HTTP这个协议本身，不会对用户所做的行为进行记录！
比如我们今天申请看当前站点下的一个网页a.html(无论是长连接还是短连接)，然后我们再马上的申请查看该网页，HTTP客户端还是要再发送一次完整的申请！！！
长短连接的区别只是连接通道的关闭时机不一样罢了。

HTTP的服务器不会因为，客户端连续申请同一份资源的时候而进行判断处理。而是要根据请求的次数来依次处理。这就叫做HTTP的无状态！

HTTP无状态的弊端及解决方案cookie

HTTP是无状态的，但是非常不利于用户进行使用！
比如，我们今天登录某个网站查看资源。但是，该服务器内的服务方式规定了：
对于一些资源，必须要用户进行登录才能使用。

那客户端就需要向服务器申请登陆服务。如果我们多次访问该资源呢？那岂不是每次都要进行登录。因为HTTP协议本身是没有记录用户使用状态的！这是极不方便用户使用的！

---

但是，这个常见其实我们是很少见过的：
因为我们经常能够发现，登录一些网站，一旦我们进行登录了，我们后序有一段时间内(具体多少取决于网站设定)都是不需要再次登陆的。除非是一些验证。

这是为什么呢？不是说HTTP是无状态的吗？这是如何做到的呢？
答案：这个是因为，浏览器中使用了cookie的方式，来记录了一些相关状态！

---

cookie的使用

我们只需要拿下面一张图来解释cookie的使用逻辑即可：

现在我们需要理解的是：
这个cookie会存储在哪里呢？其实，cookie是分为文件级和内存级的。这个具体要取决于网站设置的cookie数据的有效时间！没错，cookie数据是有一个有效期的，也就是会过期。

然后，具体就看浏览器对于不同的cookie数据是如何处理的，有一些放在内存上，所以，只有这一次访问这个网站有效。关掉浏览器再访问就失效了。
但是，一些是存储在文件上的，它只要还没有过期就是还有效！所以，我们就算把这个浏览器关了，再打开原来那个网站，也不用登录。因为cookie数据实在内存中的！

cookie的设置

首先，我们需要来认识一下cookie的设置。即服务端怎么把cookie数据设置到报头中。只要设置到报头内，发送给浏览器，后续浏览器就都会带上这个cookie！

cookie的设置格式：

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

比如，今天我们需要把客户端的账户密码设置到cookie中：

Set-Cookie: username=xxxx
Set-Cookie: password=xxxx

当然cookie的设置是可以全部连在一起的：

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

如上所示：
多个cookie数据放在一起的时候，需要使用;作为分隔符！

过期时间设置

这里需要特别说一个cookie：即expires！！！
这个其实是cookie数据的过期时间，后面跟的就是一个对应的时间。即在这个时间之前，cookie都是有效的。这个时间是有具体的格式的：

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

1. Tue：这个其实是星期几的缩写！

   星期一 ~ 星期日 对应的英文缩写
   Mon Tue Wed Thu Fri Sat Sun
   

2. 星期几后面需要跟着一个,[空格]

3. 01：这个是日期：从01(1号) ~ 31(如果有)

4. Jan：月份的英文缩写：

   一月 ~ 十二月 对印的英文缩写
   Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 
   

5. 12:34:56 ：时分秒，注意，如果数字是个位数，需要写为01一样的形式。

6. GMT: 格林威治标准时间（时区缩写）UTC：协调世界时(推荐使用，这个更精准)。

GMT和UTC的区别：

​​GMT（格林尼治标准时间）​​ 和 ​​UTC（协调世界时）​​ 基本上是一样的时间标准，但有点小区别：
1.​​GMT​​ 是以前用的，基于地球自转（天文观测）。
2.​​UTC​​ 是现在通用的，基于原子钟（更精确），但会偶尔加“闰秒”来对齐地球自转。

---

简单说：​​
日常用的时候，GMT ≈ UTC（时间一样）。
但科学上，UTC 更准，GMT 已经过时了。
✅ ​​结论：​​ 现在都用 ​​UTC​​，不用纠结 GMT。

了解其它的相关cookie设置

• expires=< date >[要验证]：设置 Cookie 的过期日期/时间。如果未指定此属性，则 Cookie 默认为会话 Cookie，即当浏览器关闭时过期。
• path=< some_path >[要验证]：限制Cookie发送到服务器的路径。默认为设置它的路径。
• domain=< domain_name >[了解即可]：指定主机可接受该Cookie。默认为设置本主机。
• secure[了解即可]：仅当使用 HTTPS 协议时才发送 Cookie。这有助于防止Cookie 在不安全的 HTTP 连接中被截获。
• HttpOnly[了解即可]：标记 Cookie 为 HttpOnly，意味着该 Cookie 不能被客户端脚本（如 JavaScript）访问。这有助于防止跨站脚本攻击（XSS）。

属性	值	描述
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）。

上述了解一下即可。实际上很多时候我们用不到那么多。

单独使用cookie的问题

但是，单独使用cookie是有很大的问题的！即cookie是明文数据。
如果我们直接把cookie的数据写到报头内发送，特别是我们的账户密码等。这直接写到报头里面再发送，直接就等同于隐私数据在裸奔！

万一，一些不法分子、或者是黑客，使用抓包工具，把数据给抓包了。我们的密码在cookie内。那么，这个中间人也是可以在对应的文件内，修改cookie对印的内容。那它不就是可以直接拿着这个cookie登录我们在某网站上的账户，从而绕开登录页面？

所以，单独使用cookie是非常危险的！存在着很大的安全隐患！！！

cookie & session

在上面，我们说到了单纯使用cookie的不足之处，那我们就需要知道，这个不足应如何解决？

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

---

我们也是通过一张图进行解释Session的原理：

安全性

通过上面的原理解释：
我们就可以很轻松的把数据隐藏起来，中间人就没办法把隐私数据抓包了，抓也只能抓到对应的session_id。但是，这样看着还是不安全啊？
中间人不是可以一样拿着session_id去访问？

这个不用怕，总是能有办法解决的。
通过使用HTTP Session的管理方案，在服务器看来，客户端是可以被记录状态的！

这里就通过一个很简单的例子来讲：
就比如聊天软件QQ，它的服务器是可以一直进行监测的。如果说，我们的号被盗了，那个人的地址肯定是和我们不一样的！(ip地址标识世界地址唯一性)。
那么，可以在Seesion中加入一个记录地址的变量。如果发现突然跳转地址差异很大，或者时间间隔很短，服务器就需要进行异常处理！(要求输入验证码、或是直接需要重新登陆)。

服务器可以直接把这个session_id对应的session给从管理数据结构中删除就好了！这样子就需要进行重新登陆了。当然，也可以记录一系列其它的相关状态，如活跃度等。

总之，使用了HTTP Session的会话管理，就能够记录客户端的状态！这个不是HTTP协议做的，是服务器开发人员设定的。通过记录状态，就可以在很大程度上保证数据安全！

Session的其他细节说明

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

Session的用途

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

这个部分，是需要结合具体的业务的，根据不同的需求设计即可！！！

测试代码

今天这个部分我们就不再讲解代码的了，直接给出链接查看。
其实就是在原来的HTTP协议通信上做出了对应的修改，代码中有注释查看：
https://gitee.com/yangnp/linux-network-learning/tree/master/2025_9_5/Cookie_Session

代码中会包含一些上述讲到的相关原理。但是有一些没有。这个部分理解原理为主！