<h1类"pgc-h-right-arrow"数据轨道">的前言。</h1>
我们知道HTTP是一种无状态协议，服务端不知道哪个请求是由哪个用户发起的。在某些情况下，我们需要知道哪个用户发起了请求以及哪个用户操作了请求。例如，在市场服务中，用户发起下订单请求，服务端需要确定它是哪个特定用户。因此，服务端需要使用某种机制来识别和记录用户的信息，状态等。
会话机制是通过使无状态协议的 HTTP 成为有状态来实现的。服务端为每个请求服务端用户创建自己的会话，以识别和跟踪用户。会话存储在服务端，可以存储在文件、内存、数据等中，并具有唯一的标识会话 ID。服务端创建会话后，服务端通过 HTTP 协议告诉客户端在本地 Cookie 中记录会话 ID。这允许来自同一客户端的每个后续请求将 Cookie 发送到服务端，服务端通过检测存储在服务端的会话 ID 来找出哪个用户是请求的用户。
<h1 class="pgc-h-arrow-right" data-track="13">Session</h1>
会话中文是指会话，诉讼时效。实际上，客户端和服务端一对一交互是一种抽象的概念。许多人认为 Session 是由以下代码获取的 Session 对象，但这只是 Cookie 的更通用的实现之一。会话有许多实现。
由于大多数应用程序使用 Cookie 来实现会话跟踪，因此这是上面的代码行。饼干是真实的。当客户端请求客户端并首先创建会话时，客户端通过 HTTP 协议（用于 HTTP 响应标头的 Set-Cookie）告诉客户端会话 ID 需要记录在本地 Cookie 中。该键的值为 JSESSIONID。
然后，来自同一客户端的每个后续请求都将 Cookie 发送到服务端，服务端通过检测存储在服务端的会话 ID 来找出哪个用户是请求的用户。
但是，客户端浏览器可以禁用 Cookie，这可能会导致问题。但是我们可以使用URL覆盖技术来实现会话跟踪，即向请求服务端的所有请求参数添加代表性用户ID或会话ID。
正如我们之前所说，会话可以存储在文件，内存，数据库等中。会话信息存储在哪里其实要根据自己的业务来决定，所有出厂业务场景来讲技术架构都是流氓，技术本身不是好是坏，但什么业务场景适合什么技术，这也是架构师考虑技术选择能力的一个方面。
但是，会话机制需要考虑群集服务中的会话一致性问题。会话同步可以在集群服务中完成，但这种方法存在一些缺点，如同步麻烦、同步延迟，以及同一会话的多机存储浪费存储空间。另一种常见的方法是使用专用的会话服务集群来保存用户会话信息，例如 Redis 缓存服务，它不仅支持集群的高可用性，而且还基于快速内存性能。
<h1 class="pgc-h-arrow-right" data-track="24">Cookie</h1>
Cookie 是客户端技术，是许多人实现会话会话的选择，服务端允许客户端将一些信息写入本地 Cookie 以进行会话跟踪。但是，请注意，浏览器会在本地禁用 Cookie。
当涉及到cookie时，很难说许多广告商，网站等使用我们的个人隐私来跟踪，分析我们的行为并提出个性化推荐。许多网站使用第三方cookie来获取用户信息并将其发送到服务以记录用户的行为。你肯定还会在其他应用中遇到关于抗脱发的讨论，然后你打开淘宝惊喜发现，向你推荐各种抗脱发洗发水。但是，某些浏览器已禁用第三方cookie或优化处理，例如Safari，Mozilla等。
我们可以手动将一些信息设置为cookie，以便客户不仅可以使用它，还可以在随后的请求中相应地处理它。
我们可以通过浏览器查看本地存储的 Cookie 信息，其他网站可以扫描使用我们存储的 Cookie，因此某些安全或机密信息不应存储在 Cookie 中，因为数据的安全性较低。一般情况下，更重要的信息，如用户登录信息，存储在服务端会话中，其他信息，如会话ID，可以存储在cookie中。
而且单个cookie的大小是有限的，不同的浏览器限制是不同的，典型的大小是几kb.不同的浏览器对于一个域名下的cookie的数量也是有限的，一般是几十个，而且淘汰策略的时候有一些饱和，所以要注意这些情况， 尽量不要超过浏览器限制。
作者：杰克·陈
友情链接： https://blog.csdn.net/chenlixiao007/article/details/118873800