服务器端Cookie和客户端Cookie之间有什么区别?


120

在服务器和客户端上创建cookie有什么区别?这些称为服务器端Cookie和客户端Cookie吗?有没有一种方法可以创建只能在服务器或客户端上读取的cookie?


15
没有“服务器端Cookie”与“客户端Cookie”之类的东西。只有HTTP报头中发送的带有请求和响应的cookie,名称/值对。
丹·格罗斯曼

1
可能引用会话变量,该变量将数据保存在服务器上。通常,仍然有一个会话标识符被保留为客户端cookie。
AndrewR 2011年

这个问题极有可能涉及到在服务器端(即“ Cookie”和“ Set-Cookie”响应标头中)对Cookie进行编码的不同方式以及在客户端(即它们对Cookie进行编码的方式)的不同方式。编码在“ Cookie”请求标头中-$ Path变量和所有爵士乐)。参见RFC 2109
Ophir Radnitz,2012年

Answers:


146

HTTP Cookie

Cookies是网站用于在浏览器中存储状态信息的键/值对。假设您有一个网站(example.com),当浏览器请求一个网页时,该网站可以发送cookie来在浏览器上存储信息。

浏览器请求示例:

GET /index.html HTTP/1.1
Host: www.example.com

来自服务器的示例答案:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

这里,两个cookie foo = 10和bar = 20存储在浏览器中。第二个将在9月30日到期。在随后的每个请求中,浏览器都会将cookie发送回服务器。

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*

会话:服务器端Cookie

服务器端Cookie被称为“会话”。在这种情况下,网站在浏览器上存储了一个包含唯一会话标识符的cookie。状态信息(上面的foo = 10和bar = 20)存储在服务器上,并且会话标识符用于将请求与存储在服务器上的数据进行匹配。

使用范例

您可以同时使用会话和cookie来存储:身份验证数据,用户首选项,电子商务网站中图表的内容等。

利弊

以下是解决方案的优缺点。这些是我首先想到的,肯定还有其他人。

Cookie优点:

  • 可扩展性:所有数据都存储在浏览器中,因此每个请求可以通过负载平衡器到达不同的Web服务器,并且您拥有满足请求所需的所有信息;
  • 可以通过浏览器上的javascript访问它们;
  • 不在服务器上,它们将在服务器重新启动后幸存下来;
  • RESTful:请求不依赖于服务器状态

Cookie缺点:

专业会议:

  • 通常更易于使用,在PHP中可能没有太大区别。
  • 无限存储

会话缺点:

  • 更难扩展
  • 在Web服务器上重启时,您可能会丢失所有会话,也可能不会丢失
  • 不是RESTful的

会议优点:secure
user2167582 2015年

1
为什么会议更安全?如果您通过http发送会话cookie,则它可能会被劫持。如果站点使用https,则安全性应该与使用安全cookie(加密,签名等)的时间
相同-filippo

1
Cookies缺点:使每个请求更大,可能会影响性能。我不知道这些数字,但是由于人们确实将无cookie域名用于某些事情,所以我认为这是不平凡的。
maniexx '17

5
误导性很大的答案-会话不是cookie。zh_cn.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session您可以具有会话变量,具体取决于服务器上实现会话管理的方式。通常,通过持有会话标识符,可以拥有一个或多个与会话管理相关的cookie。REST和RESTful也与cookie或会话管理无关-REST和RESTful实现可以具有会话和cookie。
Zlatin Zlatev

2
请参阅stackoverflow.com/questions/35054840/…我并不是说会话通常不使用cookie实现,但是会话管理还有其他选择,因此将会话变量称为服务器端cookie是错误的。我在2017年在上面的评论中说“ REST和RESTful实现可以具有会话和cookie”时,也指的是JWT。尽管一些纯粹主义者可能会认为这不是实现REST API的正确方法。
Zlatin Zlatev

57

您可能是说Http Only cookie和其对应部分之间的区别?

Http仅cookie无法在客户端JavaScript(仅服务器)中访问(读取或写入)。如果未设置Http Only标志,或者在(客户端)JavaScript中创建了cookie,则可以在(客户端)JavaScript和服务器端中读取和写入cookie。


38

所有cookie都是客户端服务器

没有区别。可以在服务器端或客户端设置常规Cookie。“经典” cookie将随每个请求一起发送回去。服务器设置的cookie将作为响应发送给客户端。服务器仅在显式设置或更改cookie时发送cookie,而客户端在每个请求时发送cookie。

但本质上是相同的cookie。

但是,行为可以改变

Cookie基本上是name=value一对,但是在值之后可以是一串用分号分隔的属性,这些属性会影响Cookie的行为(如果由客户端(或服务器)实现的话)。这些属性可以与生存期,上下文和各种安全设置有关。

仅HTTP(不是仅服务器)

服务器可以设置这些属性之一,以指示它是仅HTTP的cookie。这意味着cookie仍会来回发送,但在JavaScript中将不可用。但是请注意,cookie仍然存在!它只是浏览器中的内置保护,但是如果有人使用像IE5这样可笑的旧浏览器或某些自定义客户端,他们实际上可以读取cookie!

因此,似乎有“服务器cookie”,但实际上没有。这些cookie仍将发送给客户端。在客户端上,无法阻止将cookie发送到服务器。

实现“唯一性”的替代方法

如果要只在服务器上或仅在客户端上存储值,则需要某种其他类型的存储,例如服务器上的文件或数据库,或客户端上的本地存储。


嗨,我对这些概念很陌生,并且有一些疑问。抱歉,我的问题听起来很傻,但我仍然会问。非常感谢您的帮助-可以将在客户端设置的Cookie发送到任何域吗?我的意思是,这不是安全威胁吗?另外,它如何与非浏览器客户端(如API等)一起使用?
卡兰·查达

1
@KaranChadha,您好,如果您有任何问题,请使用页面顶部的“问问题”按钮将其作为正式问题进行提问。有关7年历史的问题的评论主题可能不会引起足够的重视。当然,可以将链接添加到此Q&A,甚至明确地添加到此答案。您可以使用每个帖子底部的“分享”按钮。
GolezTrol '18年

这是真的?客户端生成的cookie似乎没有被转移。如果这样做document.cookie="foo=bar",然后fetch("/foobar", {credentials: 'include'} )没有包含发送的cookie foo=bar。刚刚使用DevTools和控制台在此站点上直接尝试了该代码。
oligofren

是的,确实如此,docs也说,但是有些细节可能会导致这种情况,例如缺少expires属性。
GolezTrol

1
@MarinosAn是的。但是,对于修改Cookie行为的属性,我的回答有点简短,因此我现在对其进行了扩展。
GolezTrol

4
  1. 是的,您可以创建只能在服务器端读取的cookie。这些称为“仅HTTP” -cookie,如其他答案中所述

  2. 不,(我知道)没有办法创建只能在客户端读取的“ cookie”。Cookies旨在促进客户端与服务器之间的通信。

  3. 但是,如果您想要类似“ client-only-cookies”的选项,则有一个简单的答案:使用“本地存储”。

实际上,本地存储在语法上比cookie更易于使用。有关Cookie与本地存储的简要概述,请参见:

https://courses.cs.washington.edu/courses/cse154/12au/lectures/slides/lecture21-client-storage.shtml#slide8

重点:您可以使用在JavaScript中创建的cookie来存储只在客户端需要的与GUI相关的内容。但是对于每次发出的请求,cookie都会发送到服务器,它成为http-request标头的一部分,因此使请求包含更多数据,因此发送速度较慢。

如果您的页面有50个资源(例如图像,css文件和脚本),则cookie(通常)随每个请求一起发送。有关每个Web请求是否发送浏览器cookie的更多信息。

本地存储没有那些与数据传输相关的缺点,它不发送任何数据。这太棒了。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.