Linux网络HTTP(下)(9)
文章目录
- 前言
- 一、B站“记住”了我
- 二、Cookie
- 三、Session
- 四、实际例子
- Cookie
- Session
- 总结
前言
本篇打算讲解 Cookie 和 Session！就通过一个生活当中的形象的例子来讲解吧！
一、B站“记住”了我
如图，假设我现在第一次登录B站，显示未登录，要求我登录
于是我老老实实的登录了，有了如下界面
然后现在我退出了界面，但是再次登录，却显示的是登录状态，这是为什么呢
答案就在这里，我们点击 URL 左边的那个锁，点击 Cookie 和 站点数据 ，可以看到以下页面，靠的就是这个，也是我们本篇想要学习了解的内容
二、Cookie
HTTP Cookie（也称为 Web Cookie、 浏览器 Cookie 或简称 Cookie） 是服务器发送到用户浏览器并保存在浏览器上的一小块数据， 它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。 通常， 它用于告知服务端两个请求是否来自同一浏览器， 如保持用户的登录状态、 记录用户偏好等
其实我觉得这个名字特别好听，是个很有趣的名字，曲奇，跟其他的计算机术语对比来说
同时因为 HTTP 是一种无状态协议，如果没有 cookie 的存在，那么每当我们要进行页面请求时都需要重新输入账号和密码进行认证，这样太麻烦了，现在 cookie 已经被内置到 HTTP 协议当中去了
当我们第一次登录一个网站时，需要输入账号密码来证明"我是我"。网站确认身份后，为了让你下次访问时不用重复登录，就会给你的浏览器发一个"通行证"。
这个"通行证"就是 Cookie 。浏览器收到后会把它存起来，以后每次访问这个网站都会自动带上它，这样网站就知道你是谁了，不用再反复验证身份。
从第一次登录认证之后，浏览器再向该网站发起的 HTTP 请求当中就会自动包含一个 cookie 字段，其中携带的就是我第一次的认证信息，此后对端服务器需要对你进行认证时就会直接提取出 HTTP 请求当中的 cookie 字段，而不会重新让你输入账号和密码了
也就是在第一次认证登录后，后续所有的认证都变成了自动认证，这就叫做 cookie 技术
内存级别 & 文件级别
cookie 就是在浏览器当中的一个小文件，文件里记录的就是用户的私有信息。 cookie 文件可以分为两种，一种是 内存级别 的 cookie 文件，另一种是 文件级别 的 cookie 文件
将浏览器关掉后再打开，访问之前登录过的网站，如果需要你重新输入账号和密码，说明你之前登录时浏览器当中保存的 cookie 信息是内存级别的
将浏览器关掉甚至将电脑重启再打开，访问之前登录过的网站，如果不需要你重新输入账户和密码，说明你之前登录时浏览器当中保存的 cookie 信息是文件级别的
“关闭浏览器” 相当于 “结束进程” 这个动作
但是我这么一想你可能就觉得不太靠谱，这样的话，Cookie 存放在本地，我甚至都能直接打开，如果在不加密的前提下甚至可以直接看到账号密码
如果你浏览器当中保存的 cookie 信息被非法用户盗取了，那么此时这个非法用户就可以用你的cookie信息，以你的身份去访问你曾经访问过的网站，我们将这种现象称为 cookie 被盗取了
又或者比如你不小心点了某个链接，这个链接可能就是一个下载程序，当你点击之后它就会通过某种方式把程序下载到你本地，并且自动执行该程序，该程序会扫描你的浏览器当中的 cookie 目录，把所有的 cookie 信息通过网络的方式传送给恶意方，当恶意方拿到你的 cookie 信息后就可以拷贝到它的浏览器对应的 cookie 目录当中，然后以你的身份访问你曾经访问过的网站
那不就完蛋了，虽然说是实现了自动登录，但是要是会以账号密码的丢失来换取这点方便的话肯定还是不太愿意的
三、Session
所以我们就有了 Session 这门技术
当前主流的服务器还引入了 SessionID 这样的概念，当我们第一次登录某个网站输入账号和密码后，服务器认证成功后还会服务端生成一个对应的 SessionID ，这个 SessionID 与用户信息是不相关的。系统会将所有登录用户的 SessionID 值统一维护起来
此时当认证通过后服务端在对浏览器进行 HTTP 响应时，就会将这个生成的 SessionID 值响应给浏览器。浏览器收到响应后会自动提取出 SessionID 的值，将其保存在浏览器的 cookie 文件当中。后续访问该服务器时，对应的 HTTP 请求当中就会自动携带上这个 SessionID
比如下面这个DS生成的最简单的实现
而服务器识别到 HTTP 请求当中包含了 SessionID ，就会提取出这个 SessionID ，然后再到对应的集合当中进行对比，对比成功就说明这个用户是曾经登录过的，此时也就自动就认证成功了，然后就会正常处理你发来的请求，这就是我们当前主流的工作方式
你可能觉得听起来还是不太靠谱，因为 SessionID 也是可以被盗取的，到时候不法人员拿着我的SessionID，还是可以以我的身份进行一些网页的访问
但是如果破解某个信息的成本已经远远大于破解之后获得的收益（说明做这个事是赔本的），那么就可以说这个信息是安全的
有攻击才会有进步，我们把信息放在服务器上，相应的也进步出了很多种防范手段，比如说：
- 通过 IP 地址来判断登录用户所在的地址范围。如果一个账号在短时间内登录地址发送了巨大变化，此时服务器就会立马识别到这个账号发生异常了，进而在服务器当中清除对应的 SessionID 的值
- 当操作者想要进行某些高权限的操作时，会要求操作者再次输入账号和密码信息，再次确认身份，因为盗窃者拿到的是你的 SessionID ，这数字本身是没有什么实际意义的，所以盗窃者也无法修改你的密码
- SessionID 也有过期策略，比如 SessionID 是一个小时内是有效的，过一个小时后系统自动清除这个 SessionID 的值
总的来说，肯定是会更好一点的
四、实际例子
Cookie
我从网上扒拉了可以验证 Cookie 的代码，现在我运行，然后给你看看，当然在写入前我已经确认清除了原有Cookie
验证写入Cookie
其实这张图片就已经能够显示 Cookie 的自动写入和自动提交了，这个 favicon.ico 其实是一个网站图标，这很明显就是浏览器再次向服务器发出 http 请求拿到图标，我们可以看到这一次请求报头就多了一行Cookie
验证到期时间
如图，我设置了一分钟的到期时间，除此之外还可以验证路径之类的，就是只有在本地写入Cookie后，只有你后续访问服务器的某条路径才会自动提交Cookie
Session
一个浏览器对应一个进程，现在我打开 Edge 和 Google 这两个浏览器，最后发现现在浏览器已经可以能够识别是哪个浏览器了
总结
最后补充一个完整的 Cookie 的相应报头吧！
Set-Cookie: username=peter; expires=Thu, 18 Dec 2025 12:00:00
UTC; path=/; domain=.example.com; secure; HttpOnly
以及一些名词解释：
- expires=< date >： 设置 Cookie 的过期日期/时间。 如果未指定此属性， 则 Cookie 默认为会话 Cookie， 即当浏览器关闭时过期。
- path=< some_path >： 限制 Cookie 发送到服务器的哪些路径。 默认为设置它的路径。
- domain=< domain_name >： 指定哪些主机可以接受该 Cookie。 默认为设置它的主机。
- secure： 仅当使用 HTTPS 协议时才发送 Cookie。 这有助于防止Cookie 在不安全的 HTTP 连接中被截获。
- HttpOnly： 标记 Cookie 为 HttpOnly， 意味着该 Cookie 不能被客户端脚本（如 JavaScript） 访问。 这有助于防止跨站脚本攻击（XSS）