详解Cookie、Session和缓存
1 Cookie和Session
Cookie和Session都为了⽤来保存状态信息，都是保存客户端状态的机制，它们都是为了解决HTTP⽆状态的问题⽽所做的努⼒。
Session可以⽤Cookie来实现，也可以⽤URL回写的机制来实现。⽤Cookie来实现的Session可以认为是对Cookie更⾼级的应⽤。
1.1两者⽐较
Cookie和Session有以下明显的不同点：
1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的⼩段⽂本并随每⼀个请求发送⾄同⼀个服务器。Cookie最早在RFC2109中实现，后续
RFC2965做了增强。⽹络服务器⽤HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies
并将它们保存为⼀个本地⽂件，它会⾃动将同⼀服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每⼀个⽤户的，变量的值保存在服务器上，⽤⼀个sessionID来区分是哪个⽤户session变量，这个值是通过⽤户的浏览器在访问的时候返回给服务器，当客户禁⽤cookie时，这个值也可能设置为由get来返回给服务器；
4）就安全性来说：当你访问⼀个使⽤session 的站点，同时在⾃⼰机⼦上建⽴⼀个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。
jsessionid1.2 Session机制
Session机制是⼀种服务器端的机制，服务器使⽤⼀种类似于散列表的结构（也可能就是使⽤散列表）来保存信息。
当程序需要为某个客户端的请求创建⼀个session的时候，服务器⾸先检查这个客户端的请求⾥是否已包含了⼀个session标识 - 称为session id，如果已包含⼀个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使⽤（如果检索不到，可能会新建⼀个），如果客户端请求不包含session id，则为此客户端创建⼀个session并且⽣成⼀个与此session相关联的se
ssion id，session id的值应该是⼀个既不会重复，⼜不容易被到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。
1.2.1 Session的实现⽅式
1  使⽤Cookie来实现
服务器给每个Session分配⼀个唯⼀的JSESSIONID，并通过Cookie发送给客户端。
当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够到这个客户端对应的Session。
流程如下图所⽰：
2  使⽤URL回显来实现
URL回写是指服务器在发送给浏览器页⾯的所有链接中都携带JSESSIONID的参数，这样客户端点击任何⼀个链接都会把JSESSIONID 带会服务器。
如果直接在浏览器输⼊服务端资源的url来请求该资源，那么Session是匹配不到的。
Tomcat对Session的实现，是⼀开始同时使⽤Cookie和URL回写机制，如果发现客户端⽀持Cookie，就继续使⽤Cookie，停⽌使⽤URL 回写。如果发现Cookie被禁⽤，就⼀直使⽤URL回写。jsp开发处理到Session的时候，对页⾯中的链接记得使⽤deURL() 。
1.2.2 与Cookie相关的HTTP扩展头
1）Cookie：客户端将服务器设置的Cookie返回到服务器；
2）Set-Cookie：服务器向客户端设置Cookie；
3）Cookie2 (RFC2965)）：客户端指⽰服务器⽀持Cookie的版本；
4）Set-Cookie2 (RFC2965)：服务器向客户端设置Cookie。
1.2.3 Cookie的流程
服务器在响应消息中⽤Set-Cookie头将Cookie的内容回送给客户端，客户端在新的请求中将相同的内容携带在Cookie头中发送给服务器。从⽽实现会话的保持。
流程如下图所⽰：
2 缓存的实现原理
2.1 什么是Web缓存
WEB缓存(cache)位于Web服务器和客户端之间。
缓存会根据请求保存输出内容的副本，例如html页⾯，图⽚，⽂件，当下⼀个请求来到的时候：如果是相同的URL，缓存直接使⽤副本响应访问请求，⽽不是向源服务器再次发送请求。
HTTP协议定义了相关的消息头来使WEB缓存尽可能好的⼯作。
2.2缓存的优点
减少相应延迟：因为请求从缓存服务器（离客户端更近）⽽不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快。
减少⽹络带宽消耗：当副本被重⽤时会减低客户端的带宽消耗；客户可以节省带宽费⽤，控制带宽的需求的增长并更易于管理。
2.3与缓存相关的HTTP扩展消息头
Expires：指⽰响应内容过期的时间，格林威治时间GMT
Cache-Control：更细致的控制缓存的内容
Last-Modified：响应中资源最后⼀次修改的时间
ETag：响应中资源的校验值，在服务器上某个时段是唯⼀标识的。
Date：服务器的时间
If-Modified-Since：客户端存取的该资源最后⼀次修改的时间，同Last-Modified。
If-None-Match：客户端存取的该资源的检验值，同ETag。
2.4客户端缓存⽣效的常见流程
服务器收到请求时，会在200OK中回送该资源的Last-Modified和ETag头，客户端将该资源保存在cache中，并记录这两个属性。当客户端需要发送相同的请求时，会在请求中携带If-Modified-Since和If-None-Match两个头。两个头的值分别是响应中Last-Modified和ETag头的值。服务器通过这两个头判断本地资源未发⽣变化，客户端不需要重新下载，返回304响应。常见流程如下图所⽰：
2.5 Web缓存机制
HTTP/1.1中缓存的⽬的是为了在很多情况下减少发送请求，同时在许多情况下可以不需要发送完整响应。前者减少了⽹络回路的数量；HTTP利⽤⼀个“过期（expiration）”机制来为此⽬的。后者减少了⽹络应⽤的带宽；HTTP⽤“验证（validation）”机制来为此⽬的。
HTTP定义了3种缓存机制：
1）Freshness：允许⼀个回应消息可以在源服务器不被重新检查，并且可以由服务器和客户端来控制。例如，Expires回应头给了⼀个⽂档不可⽤的时间。Cache-Control中的max-age标识指明了缓存的最长时间；
2）Validation：⽤来检查以⼀个缓存的回应是否仍然可⽤。例如，如果⼀个回应有⼀个Last-Modified回应头，缓存能够使⽤If-Modified-Since来判断是否已改变，以便判断根据情况发送请求；
3）Invalidation：在另⼀个请求通过缓存的时候，常常有⼀个副作⽤。例如，如果⼀个URL关联到⼀个缓存回应，但是其后跟着POST、PUT和DELETE的请求的话，缓存就会过期。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。