接口测试经典面试题：Session、cookie、token有什么区别？

HTTP是一个没有状态的协议，这种特点带来的好处就是效率较高，但是缺点也非常明显，这个协议本身是不支持网站的关联的，比如ceshiren.com/和https://ce… 、cookie 、token。

• session 即会话，是一种持久网络协议，起到了在用户端和服务器端创建关联，从而交换数据包的作用。

• cookie 是“小型文本文件”，是某些网站为了辨别用户身份，进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。

• token 在计算机身份认证中是令牌（临时）的意思，在词法分析中是标记的意思。一般作为邀请、登录系统使用。

演示环境搭建

与 get、post 区别实战详解 章节相同，为了避免其他因素的干扰，使用 Flask 编写一个简单的 demo server(Flask 的安装与启动参考 get、post 区别实战详解 章节)，来演示 cookie 与 session。

demo server 演示代码

1. from flask import Flask,session,Request, request,make_responseapp = Flask(__name__)request: Requestapp.secret_key = "key"@app.route('/')def hello_world():

2. return 'Hello, World!'@app.route("/session")def session_handle():

3. #读取请求

4. for k, v in request.args.items():

5. #收到请求后写入session

6. session[k] = v

7. #创建服务器响应，将session的内容打印出来

8. resp = make_response({k: v for k, v in session.items()})

9. for k, v in request.args.items():

10. #给服务器设置cookie，并添加cookie字符串进行标识

11. resp.set_cookie(f"cookie_{k}", v)

12. return resp

分析 session、cookie、token

session、cookie 区别演示

首先使用浏览器的无痕模式对演示网站发起访问，并传入 a、b 两个参数 以一次请求为例，查看 cookie 的传递过程

第一次请求的请求头信息如下，可以看到没有任何的 cookie 信息：

1. GET /session?a=1&b=2 HTTP/1.1

2. Host: 127.0.0.1:5000

3. Connection: keep-alive

4. Pragma: no-cache

5. Cache-Control: no-cache

6. sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"sec-ch-ua-mobile: ?0

7. Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

8. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

9. Sec-Fetch-Site: none

10. Sec-Fetch-Mode: navigate

11. Sec-Fetch-User: ?1

12. Sec-Fetch-Dest: document

13. Accept-Encoding: gzip, deflate, br

14. Accept-Language: en

第一次请求的响应头信息，对客户端返回了 set-cookie 字段：

1. HTTP/1.0 200 OK

2. Content-Type: application/json

3. Content-Length: 18Set-Cookie: cookie_a=1; Path=/

4. Set-Cookie: cookie_b=2; Path=/

5. Vary: Cookie

6. Set-Cookie: session=eyJhIjoiMSIsImIiOiIyIn0.YKSvNA.2sSLXbraXxQ-MfKOLhoLJPZmV9U; HttpOnly; Path=/

7. Server: Werkzeug/1.0.1 Python/3.8.7

8. Date: Wed, 19 May 2021 06:24:52 GMT

第二次请求的请求头信息，客户端向服务端请求时请求头多出了一个 cookie 信息，并提交了和第二次 set-cookie 相同的信息：

1. GET /session?a=1&b=2 HTTP/1.1

2. Host: 127.0.0.1:5000

3. ...省略...

4. Cookie: cookie_a=1; cookie_b=2; session=eyJhIjoiMSIsImIiOiIyIn0.YKSvNA.2sSLXbraXxQ-MfKOLhoLJPZmV9U

当用户访问带 cookie 浏览器时，这个服务器就为这个用户产生了唯一的 cookie，并以此作为索引在服务器的后端数据库产生一个项目，接着就给客户端的响应报文中添加一个叫做 Set-cookie 的首部行，格式为 k:v。

这样当该用户下次再访问此网站时，就会在对服务器发起请求的时候添加一个名 Cookie 的首部行。浏览器由此就可以得知用户的身份，从而用户就不需要再次重新输入一些个人信息。

使用 curl 命令对网站发起了一个 get 请求，并传入 a、b 两个参数

curl 'http://127.0.0.1:5000/session?a=1&b=2' -v -s &>session

查看 session 文件内的请求以及响应内容

1. * Trying 127.0.0.1...

2. * TCP_NODELAY set* Connected to 127.0.0.1 (127.0.0.1) port 5000 (#0)> GET /session?a=1&b=2 HTTP/1.1

3. > Host: 127.0.0.1:5000

4. > User-Agent: curl/7.64.1

5. > Accept: */*

6. >

7. * HTTP 1.0, assume close after body

8. < HTTP/1.0 200 OK

9. < Content-Type: application/json

10. < Content-Length: 18< Set-Cookie: cookie_a=1; Path=/

11. < Set-Cookie: cookie_b=2; Path=/

12. < Vary: Cookie

13. < Set-Cookie: session=eyJhIjoiMSIsImIiOiIyIn0.EWX6Qg.M8tEGPyRhlf0iUiLktEqup-4e-U; HttpOnly; Path=/

14. < Server: Werkzeug/1.0.1 Python/3.7.5

15. <{ [18 bytes data]* Closing connection 0{"a":"1","b":"2"}

从上面可以发现，与上一章节内容不同的是响应值多出了 3 个Set-Cookie字段。下面有一个Set-Cookie显示为session=eyJhIjoiMSIsImIiOiIyIn0.EWX6Qg.M8tEGPyRhlf0iUiLktEqup-4e-U; HttpOnly; Path=/，由此可见 session 一般是加密串格式，可以通过 cookie 传递。

token 演示

token 的使用有一个非常经典的场景，就是在 github 中的使用。在 github->settings->Developer settings->Personal access tokens 中，可以生成一个 token 用于访问 github 的 api，这个 token 是没有时效性的，“任何人”可以使用它们代替通过 HTTPS 的 Git 密码，也可以用来通过基本身份验证向 API 进行身份验证。

使用 OAuth 令牌对 GitHub API 进行身份验证（因返回结果个人信息太多所以省略展示）

$ curl -u username:$token https://api.github.com/user

token是无状态的，客户端传递用户数据给服务端后，服务端将数据加密就生成了token并传回给客户端。这样客户端每次访问时都传递token，而服务端解密token之后，即可了解客户的信息。

在 github 中，token 只会生成一次，且不会过期，不过在很多其他的 web 应用网站，token 会存在过期机制。

session、cookie、token 的区别

1. @startuml

2. autonumber

3. title session、cookie过程

4. participant 客户端 as c

5. participant 服务器 as s

7. c -> s: 第一次请求

8. s -> s: 创建SessionID并保存

9. s -> c: 返回SessionID，并Set-Cookie

10. c -> c: Cookie保存\n在浏览器

11. c -> s: 第二次请求，请求中携带Cookie和SessionId

12. s -> s: 判断SessionId\n属于哪个用户

13. s -> c: 响应

15. @enduml

1. @startuml

2. autonumber

3. title token身份验证流程

5. participant 客户端 as c

6. participant 服务器 as s

8. c -> s: 第一次请求，携带用户信息（账户、密码）

9. s -> s: 用户信息加密\n之后得到token

10. s -> c: 返回token

11. c -> s: 请求时携带token

12. s -> s: 对token解密之后做认证

13. s -> c: 响应

15. @enduml

• session 存储在服务器端，cookie 存储在客户端。

• cookie 可设置为长时间保持，session 一般失效时间较短，客户端关闭（默认情况下）或者 session 超时都会失效。

• session记录会话信息，token不会记录会话信息。token是无状态的。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。