Skip to content

Latest commit

 

History

History
47 lines (31 loc) · 3.9 KB

Cookie与Session.md

File metadata and controls

47 lines (31 loc) · 3.9 KB

Cookie与Session

会话跟踪是Web程序中常用的技术,HTTP协议是无状态的,确定用户身份就需要跟踪用户的整个会话。最常用的会话跟踪是使用CookieSession,简单来说Cookie通过在客户端记录信息确定用户身份,Session通过在服务器端记录信息确定用户身份。

Cookie

由于HTTP协议是无状态的,一旦数据交换完毕,此次链接就会关闭,再次交换数据就需要重新连接,意味着服务器无法从链接上跟踪会话。假如AB同时购买了一件商品,不进行会话跟踪的话服务器就无法判断究竟是谁购买了此商品。
服务端为进行会话跟踪,给每个客户端颁发一个通行证,每个人访问必须携带通行证,这样服务端就能区别用户身份了。
Cookie实际上是一小段的文本信息,服务端将需要通行证信息Cookie发送到浏览器,浏览器将通行证存储起来,并且对于同源的每个请求都会自动携带通行证信息(CSRF跨站请求伪造基于此策略),于是服务端就可以判断用户身份。

Session

Session是服务器端使用的一种记录客户端状态的机制,相应的也增加了服务器的存储压力。
对于客户端的每个会话,都有一个唯一的SESSION ID与其对应,服务端将用户数据存储进SESSION ID对应的文件或者是内存中,只要客户端每次请求将SESSION ID交予服务端,服务端就能区别用户进行会话跟踪。

实例

仅使用Cookie

仅使用cookie而不使用session进行用户身份跟踪,服务端将所有的用户数据信息告知浏览器,浏览器进行存储,每次请求将数据发送到服务端。此种方式理论上可行,但是相对并不安全,尤其是在用户数据信息未加密的情况下,若是被中间人攻击则用户的数据信息将全部被泄露,或者用户自身将浏览器数据进行修改进行请求伪造,伪造他人身份访问服务器等,此外不同浏览器对于同一域Cookie的大小(一般为4KB左右)与数量都有限制,将用户数据都存储于Cookie可能会有空间或数量不够的情况。

仅使用Session

仅使用session而不使用Cookie进行用户身份跟踪,由于使用Session在客户端仅需要一个SESSION ID传输到服务端就能进行会话跟踪,所以实现比较简单,可以通过对所有的URL后拼接一个SESSION ID或者对于每个表单设置一个隐藏的input用以存储SESSION ID进行提交,服务器就可以进行会话跟踪,由于数据是存储在服务端,相对比较安全,且存储量大小完全取决于服务端,可以较好控制。

结合使用

现在普遍使用的方式就是将COOKIESESSION结合使用,直接将SESSION ID存储于COOKIE中,浏览器自动将同源的COOKIE携带在请求头中,进行会话跟踪,这样既不需要在COOKIE中存储大量信息,也不需要对每次请求都需要操作附带SESSION ID。浏览请求头中Cookie字段的JSESSION ID=XXXXXXXXXXXXXXXXXXX就是Java默认的SESSION IDPHPSESSID=XXXXXXXXXXXXXXXXXXXXXXXXXX就是PHP默认的SESSION ID

差异

存储位置

Cookie将数据存储在浏览器,Session则将数据存储在服务端。

类型

Cookie是存储的String类型,Session在服务端则是Object类型。

安全

Cookie在客户端用户可以进行修改伪造,Session在服务端用户无法进行直接的修改伪造。

作用域

Cookie由于浏览器的同源策略,只有同源的情况下才会发送,Session在服务端理论上可以进行多域共享。

存储大小

Cookie大小由浏览器限制,一般不超过4KBSession在服务端大小可以灵活控制。

每日一题

https://github.com/WindrunnerMax/EveryDay