web-applications - cookies 是如何工作的？

Question

我想知道 cookie 的所有可能用途。他们是好是坏？它们是如何工作的？

到目前为止我收集的一些最佳实践 -

为组件使用无 Cookie 的域

标签: cookies

当浏览器请求静态图像并将 cookie 与请求一起发送时，服务器对这些 cookie 没有任何用处。所以他们只会无缘无故地创建网络流量。您应该确保使用无 cookie 请求来请求静态组件。创建一个子域并在那里托管所有静态组件。

如果您的域是 www.example.org，您可以在 static.example.org 上托管您的静态组件。但是，如果您已经在顶级域 example.org 上设置了 cookie，而不是 www.example.org，那么所有对 static.example.org 的请求都将包含这些 cookie。在这种情况下，您可以购买一个全新的域，在那里托管您的静态组件，并保持该域没有 cookie。雅虎!使用 yimg.com，YouTube 使用 ytimg.com，亚马逊使用 images-amazon.com 等等。

在无 cookie 域上托管静态组件的另一个好处是，某些代理可能会拒绝缓存使用 cookie 请求的组件。在相关说明中，如果您想知道是否应该在主页上使用 example.org 或 www.example.org，请考虑 cookie 的影响。省略 www 使您别无选择，只能将 cookie 写入 *.example.org，因此出于性能原因，最好使用 www 子域并将 cookie 写入该子域。

实现限制

实际的用户代理实现对它们可以存储的 cookie 的数量和大小有限制。一般来说，用户代理的 cookie 支持应该没有固定的限制。他们应该努力存储尽可能多的常用 cookie。此外，通用用户代理应该单独提供以下每个最低功能，尽管不一定同时提供:

* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the characters that comprise the cookie non-terminal in the syntax description of the Set-Cookie2 header, and as received in the Set-Cookie2 header)
* at least 20 cookies per unique host or domain name

为特定目的或有限容量设备创建的用户代理应该提供至少 20 个 4096 字节的 cookie，以确保用户可以与基于 session 的源服务器交互。

Set-Cookie2 响应头中的信息必须完整保留。如果由于某种原因没有足够的空间来存储 cookie，它必须被丢弃，而不是被截断。应用程序应该尽可能少地使用 cookie，并且它们应该优雅地处理 cookie 的丢失。

Answer 1

刀是好是坏:)
简化解释:网络服务器向客户端发送一些文本。
这有一个额外的来源(谁发送它)和一个“生命周期”(它会在客户端持续多久)。

根据您的设置(浏览器安全性)，您的浏览器会存储此“文本文件”。
当您稍后再次联系服务器(站点)时，您的浏览器会将 cookie 发送到服务器。

简单的例子:我让你在我的网站上选择字体大小(小中大)。
当您选择尺寸时，我(服务器)会向您发送一个 cookie。
下次您访问时，我会询问此 cookie 是否存在 - 如果存在，我会根据 cookie 内容设置字体大小。

cookie 背后也有安全性 - 作为示例，cookie 仅发送给发行者。

曼弗雷德