当前位置：首页 > wzjs >正文

深圳网址网站建设公司营销型网站模板

wzjs 2025/8/2 20:34:16

深圳网址网站建设公司,营销型网站模板,盐城手机网站建设公司,wordpress 编写页面代码CookieCookie的本质就是保存在客户端的一小块数据工作原理1.当用户第一次访问服务器时，服务器会在响应的 HTTP 头中设置 Set-Cookie 选项，用于设置 Cookie 到用户的浏览器上，cookie的本质就是数据，其保存方式有两种，一…

Cookie

Cookie的本质就是保存在客户端的一小块数据

工作原理

1.当用户第一次访问服务器时，服务器会在响应的 HTTP 头中设置 Set-Cookie 选项，用于设置 Cookie 到用户的浏览器上，cookie的本质就是数据，其保存方式有两种，一种是保存在内存中，那这就是会话cookie，客户端进程退出那么cookie就没了，还有一种是保存在文件中，那就是持久cookie，这样的话浏览器进程退出，该cookie也不会消失，当然这也不是永久的，而是定时就失效了。

2.在之后浏览器的请求中，浏览器会自动在 HTTP 请求头中携带 Cookie 选项，将之前保存的 Cookie 信息发送给服务器。

分类

1.会话 Cookie（Session Cookie）：在浏览器关闭时失效，保存在内存中。

2.持久 Cookie（Persistent Cookie）：带有明确的过期日期或持续时间，可以跨多个浏览器会话存在，保存在文件里。

cookie的设置

服务器在 HTTP 响应报文的报头中添加 Set-Cookie选项，客户端浏览器获取后设置Cookie，可能是内存里也可能是文件里，看 Set-Cookie 中有没有 expires 字段

完整的 Set-Cookie 示例

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

RFC 1123 互联网时间格式标准

示例：

Tue, 16 Jul 2024 08:30:45 GMT

格式详解

星期几：3字母英文缩写（Mon, Tue, Wed等）
日期：2位数字（前导零可选）
月份：3字母英文缩写（Jan, Feb, Mar等）
年份：4位数字
时间：24小时制，HH:MM:SS
时间标准：GMT (格林尼治标准时间)或UTC (协调世界时)

set-cookie可选属性介绍

1.username指明用户，expires是cookie的失效时间，path和domain是做一个限制，只有http请求是发送给这个路径、发送给这个域名，那才会在http请求报头的选项中加上cookie，set-cookie设置了secure字段，那么只有https请求，才能加上cookie，http就不行了，set-cookie设置httponly，那客户端脚本就不能访问cookie

2.每个 Cookie 属性都以分号（;）和空格（）分隔。名称和值之间使用等号（=）分隔。如果 Cookie 的一个属性的名称或值包含特殊字符（如空格、分号、逗号等），则需要进行 URL 编码，将属性中的特殊字符转成%XX的十六进制形式。

Session

session 的本质是保存在服务器端的数据

工作原理

在cookie的技术体系中，数据保存客户端内存或文件中，这并不安全，因此又引入了session的技术体系，将会话数据存储在服务器端内存、数据库或缓存中，只给客户端一个session id来找到对应数据

当用户首次访问网站时，服务器会为用户创建一个唯一的 Session ID，并通过 Set-Cookie 将session id发送到客户端。

客户端在之后的请求中会携带这个 Session ID，服务器通过 Session ID 来识别用户，从而获取用户的会话信息。

安全性

与信息直接存储在Cookie 中相似，由于 Session ID 是在cookie中的的，因此session id也存在被窃取的风险。但是此时用户只泄漏了一个 Session ID，私密信息暂时没有被泄露的风险，还可以通过设置合适的 Cookie 属性（如 HttpOnly 和 Secure）来增强cookie中session id的安全性。

超时和失效

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

Cookie和Session的合作用途

会话信息保存在服务器端的内存或文件中，然后将session id加进http响应头的set-cookie中，接着客户端收到http响应，将cookie保存在客户端内存或文件中，然后之后每次请求如果符合限制条件（路径、域名）都会带上cookie，也就是那个session id，然后就可以实现用户认证和会话管理和安全性于一体

Cookie 和 Session 的协作流程

会话初始化（用户首次访问）：
- 服务器检测到请求中没有 Session ID（如 Cookie: sessionid=xxx不存在）。
- 服务器生成唯一 Session ID（如 abc123xyz），通常是一个高强度随机字符串（避免可预测性）。
- 服务器存储会话数据：
  - 在内存（如 Redis）、数据库或文件中保存会话数据（如 { "sessionid": "abc123xyz", "user_id": 123, "last_activity": 1620000000 }）。
  - 会话数据中可能包含用户身份、权限、临时状态等信息。
响应阶段（Set-Cookie）：
```
HTTP/1.1 200 OK
Set-Cookie: sessionid=abc123xyz; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
```
- 关键属性说明：
  - HttpOnly：防止 JavaScript 通过 document.cookie访问（防 XSS）。
  - Secure：仅通过 HTTPS 传输（防明文泄露）。
  - SameSite=Lax/Strict：控制跨站请求时是否发送 Cookie（防 CSRF）。
  - Max-Age/Expires：设置有效期（会话过期时间）。
客户端存储 Cookie：
- 浏览器收到 Set-Cookie后，按规则存储 Cookie（包括域名、路径、有效期等）。
- 存储位置可能为内存（会话 Cookie）或磁盘（持久化 Cookie）。
后续请求：
- 浏览器自动在符合条件的请求头中添加 Cookie：
```
GET /profile HTTP/1.1
Cookie: sessionid=abc123xyz
```
- 条件限制：仅当请求的域名、路径匹配 Cookie 属性时才会发送。
服务器验证会话：
- 服务器读取 Cookie: sessionid=abc123xyz，查询内存/数据库中的会话数据。
- 验证 Session ID 是否有效、是否过期、是否被篡改（如签名机制）。
- 通过后，认为请求已认证，返回用户专属数据。