HTTP 本质是一种无状态协议，HTTP 的每次请求或者响应之间都是没有任何关系的，也就是说，客户端发一次请求后，再发一次请求的时候，服务器已经不认识刚才的客户端是谁了，这就导致了很严重的问题：用户体验及其不佳！
但是因为引入了 Cookie 技术之后，就不一样了！比如用户在第一次输入账号和密码时，浏览器会进行保存（Cookie），近期再次访问同一个网站，浏览器会自动将用户信息推送给服务器。像哔哩哔哩中某些需要大会员才能观看的视频，服务器都会先获取用户信息进行身份判断，用的就是浏览器缓存的信息。这样只要用户首次输入密码，一段时间内将不用再做登录操作了。
一些浏览器的网址旁边有一个锁的标志，点击进去就可以看到对应网站的各种 Cookie 数据（当然有些浏览器是看不到的，比如 Chrome 浏览器）。
这些 Cookie 数据实际都是对应的服务器方写的，如果你将对应的某些 Cookie 删除，那么此时可能就需要你重新进行登录认证了，因为你删除的可能正好就是你登录时所设置的 Cookie 信息。
💥注意，这里说的
Cookie和我们在浏览器中类似记录下密码这些是不太一样的，那只是免去了我们填密码的工作，而Cookie技术指的是可以让客户端和服务器保持会话。
所以我们可以总结一句话：会话保持不是 HTTP 天然具备的，而是在后来使用的时候才引入的话题！
2、Cookie 原理
其实要实现会话保持还是挺复杂的，但是 Cookie 技术就不一样了，它只是做到让人看起来就像是会话一直保持着一样，但实际还是原来的无状态通信，只是稍微做了一下修改：多携带一些状态信息！
如图所示，这个多携带的信息，其实就是一个 cookie 文件，而 cookie 文件中其实保存就是一些账号的密码等内容，服务器收到了该文件之后就会做对应的鉴权工作！
而 cookie 信息是在服务端创建的，但最后保存在浏览器端。在 cookie 有效期内，后续的浏览器的请求就会带上对应的 cookie 信息，服务端收到请求后，识别 cookie 就可以知道当前发起请求的用户是哪一个，而且，浏览器下次再次需要相同信息时，比如用户名什么的，可以直接从 cookie 里获取，而不用再次让用户发起请求获取。
我们可以通过在服务器的响应中设置 cookie 字段，这个字段名我们之前介绍过，叫做 Set-Cookie，其后面跟的就是给用户提供的鉴权信息，并且可以设置该 cookie 的最大生存时间，当过了该时间之后，在客户端会进行时间的对比，超时了 cookie 就失效了，就要重新在请求中带上账号密码等信息，对应到用户就是要重新输入密码进行登录了！
// 往后20秒，每次http请求时候都会自动携带曾经设置的所有cookie，帮助服务器进行鉴权行为 -- http会话保持
resphead += "Set-Cookie: name=lirendada; Max-Age=20\r\n"; cookie 有如下特点：
- 每一个
cookie文件大小超过4KB后浏览器不识别 - 浏览器保存
cookie的数量有限，至多300个 cookie不安全，可能会泄露用户信息- 浏览器可以禁用
cookie - 默认情况下，浏览器关闭时就会销毁
cookie（临时 cookie） cookie遵守同源策略
cookie 一定程度上解决了 http 请求无状态的问题。但由于 cookie 不安全和服务端不可控，一般很少用 cookie 来作为用户的登录标识信息。
内存级别 & 文件级别之分
cookie 就是在浏览器当中的一个小文件，文件里记录的就是用户的私有信息。cookie 文件一般分为两种，一种是内存级别的 cookie 文件，另一种是文件级别的 cookie 文件。
- 内存级别：比如说将浏览器关掉后再打开，访问之前登录过的网站，如果需要你重新输入账号和密码，说明此时的
cookie文件是内存级别的。 - 文件级别：比如说将浏览器关掉甚至将电脑重启再打开，访问之前登录过的网站，如果不需要你重新输入账户和密码，说明此时的
cookie文件是文件级别的。
🎏 Cookie 存在的安全问题
在互联网早期，因为大多数人使用的都是 http 协议，并且网上的大部分软件其实都是不太正规的，这导致了早期很多人电脑会被一些坏叔叔偷偷的放了一些木马，这些木马危害程度不一，但是最常见的就是窃取用户信息了，比如说一台电脑中了木马，该木马窃取了用户的 cookie 信息，此时该用户的信息基本就被坏人掌握了，这些坏人利用用户的 cookie 信息，来对对应的服务器进行访问，此时服务器会误以为这个用户就是之前那位用户，就允许登录和获取用户信息了，那么就麻烦了，轻则损失一些用户的个人财产，重则导致不停的敲诈事件发生……
简单地说，如果你能够截获某个用户的 cookie 变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用 cookie 被攻击的可能性比较大。
3、Session 原理
为了提高安全性，于是引入了 session 机制，其实就是将原来保存在客户端的 cookie，现在变成了由服务端来保存管理，如下图所示：
当用户发起第一次请求的时候，需要携带上用户信息如账号密码，然后服务器首先会从用户的请求中解析，看看是否存在 cookie 文件，不存在的话则会为该用户生成一个 session id，这是一个不会重复、难以伪造、很长的字符串，是通过一些加密算法来得到的！
然后服务器会将该 session id 以文件的形式保存在服务器本地进行管理，因为一般服务器的安全级别是比较高的，甚至可能还有法律的支持，所以黑客从之前的对用户攻击，变成了只能对服务器攻击之后，这个攻击威胁就大大降低了！
接着用户会收到服务器发过来的响应报文，其中就有 Cookie 字段，该字段的值就是服务器生成的 session id，用户也会将其保存到本地的 cookie 文件中，就算黑客布置了木马，拿到了该 session id，那么也不知道该 session id 到底是什么鬼（因为没办法看出用户信息）。
此后用户在请求的时候，都会在请求报文中携带上该 session id，而服务器收到该 session id 之后就会进行鉴权！
session 和 cookie 的区别如下所示：
session数据是保存在服务端的，而cookie数据是保存在客户端的session中保存的是对象，cookie中保存的是字符串session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到，而cookie中如果设置了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的
🎏 session 存在的安全问题
细心的小伙伴就能看出来，其实 session 面临的安全问题和 cookie 基本是差不多的，即使现在用户信息由服务器保存，并且还生成了一个很难破解的 session id，但是黑客可能就不想知道用户的密码了，但是他就是想登录用户的账号！
所以在服务器和用户通信的过程中，黑客对请求或者响应进行窃取，拿到报文中的 session id（再或者是通过木马拿到用户本地的 session id），这样子一来，虽然黑客不知道用户的信息是什么，但是依然是可以用该 session id 去伪造请求包发送给服务器，而服务器是很难识别出来的，如下图所示：
那可能就会有人问，session机制存在的意义何在，如何更好的避免这种伪造的情况❓❓❓
其实现实就是这样子，没有完美的机制，对于一个程序也是如此，一定会有漏洞，并且这些漏洞都是在时间的不断推移中发现的，那我们需要做的其实就是在发现漏洞的时候及时修补漏洞，其实 session 机制已经是尽可能的保护用户的信息了，但是因为 http 传输其实还是明文传输的问题，这问题没从根源解决，就导致了 session 机制这种尴尬的场景。
就算我们写出再好的程序，也会有厉害的人找到漏洞并且攻击，所以要客观的去看待这些机制的引入，就是为了不断完善这些漏洞。不过在安全领域有一个准则：如果破解某个信息的成本已经远远大于破解之后获得的收益（说明做这个事是赔本的），那么就可以认为这个信息就是安全的。
回到问题上来，其实我们单单使用 session 机制是行不通的，还得配合其它的一些机制，比如说，异地登录警报、会话超时重新登录等等策略，就能在一定程度上缓解这种问题！
但是还存在一个大问题，就是因为信息是明文传输的，此时黑客岂不是就能对第一次用户请求的报文进行窃取拿到用户信息，那后面的 session id 其实都没有意义了，所以我们就要学习后面的 https 协议，看看其是如何解决明文传输的问题！
4、http 相关抓包工具
1、postman：能够模拟客户端浏览器的行为。
2、fiddler：一个本地抓包工具，作为 http 调试使用。（能够明文抓到本地的 POST 方法请求正文！）
