为什么是 cookie，还有哪些替代品？

HTTP 是无状态的。记住您的网页（因此您不必每次访问新页面时都重新输入密码）是有状态的。为了弥合无状态协议和有状态应用程序之间的差距，您需要某种会话标识符，该标识符包含在每个请求中。

执行此操作的标准方法是使用 cookie。但是您可以将它放在 HTTP 请求中的任何位置。一些例子：

• 过去的一种常见做法是将会话标识符放在 URL 中，但这意味着它最终会出现在各种日志中并通过引用标头泄漏。不太好。

• 单页应用程序可以只将标识符（例如身份验证令牌）存储在客户端的 JavaScript 变量中，然后在每个请求的自定义标头中发送它。它就像一个只为一个页面加载而存在的cookie。（正如Marko Vodopija指出的那样，这里的安全性会稍弱一些，因为标识符无法http-only像 cookie 一样受到保护。）

您可以将这些视为“模拟”有限版本 cookie 的不同方式。

顺便说一下，PHP 在其会话中使用 cookie。

为什么有些人不喜欢饼干？

cookie 本身并没有什么不安全的地方，使用它们的安全性不亚于任何更人为的替代方法。相反，正如我们所看到的，一些替代品更糟糕。

一些讨厌 cookie 的原因与它们如此有用的原因相同——它们使网络成为有状态的。这意味着它们可用于跟踪您，以及随之而来的所有隐私问题。所以有些人可能想完全禁用 cookie。

这可能就是为什么以隐私为重点的网站会提供无 cookie 替代方案的原因。它不会使网站本身更安全，但它可以为出于隐私原因关闭 cookie 的用户提供服务。

只是对@Anders 答案的补充。

Cookie 是在 HTTP 中进行有状态会话的一种方式，它本身就是一个非连接的无状态协议。Web 应用程序和任何在线业务都需要会话。

Cookies 过去和早期的 javascript 一样不受欢迎，因为第一个是收集使用情况统计的方式，存在隐私问题，而另一个允许服务器控制浏览器，存在安全问题。如今，许多网站在禁用 cookie 或 javascript 的情况下根本无法使用，并且在浏览器中禁用它们并不总是一项微不足道的任务。所以我的意见是提供需要cookies的服务很好。如果您无法建立会话，只需显示一个警告页面，说明您的服务需要 cookie。

URL 重写是（曾经是？）在 HTTP 中提供会话的 cookie 的替代方案。在该模式下，您始终添加一个由密钥和会话标识符组成的参数。所有会话数据都应在该模式下传送到服务器端。这样就没有额外的数据泄露风险，因为在 URL 中只交换了标识符。缺点是它对书签不友好：URL 确实包含会话 id，因此如果您将包含它的页面的 URL 加入书签，以后尝试使用它时会收到无效会话错误。在同域站点之间传递信息比使用 cookie 更难。出于这个原因，cookie 现在是拥有有状态 HTTP 站点或应用程序的标准方式。

不喜欢 cookie 的人也会争辩说，由于在 URL 重写中没有持久性等价物，并且持久性 cookie 被高度用于收集客户行为数据，主要的网络公司（谷歌、Facebook、亚马逊等）只允许cookie 来浏览他们的网站，并且由于那个 URL 重写已经或多或少地被放弃了。无论是真是假，现在都毫无意义，因为事实是大多数站点都需要cookie，并且大多数用户都允许使用cookie。