思考
Session依赖于Cookie吗？
上篇笔记《初始Session》中，有讲到Session记录客户端状态的方法步骤，是通过一个名为JSESSIONID的Cookie，然后找到这个客户端相对应的具体的Session。
这是不是就是说，Session依赖于Cookie呢？如果客户端禁止了Cookie，那么客户端就不会记录名为JSESSIONID的Cookie，下次客户端请求服务器也不会携带该Cookie的值，那么如何获取到具体客户端对应的Session呢？
搞清JSESSIONID
初看上面的思考会觉得，Session还真的是依赖于Cookie的呀。
可是如果往细的探究，这个将Session和Cookie牵连起来的JSESSIONID到底起了个什么作用？它的作用可不可以通过其它方式来代替。通过这种方式使得Session不依赖于Cookie。
JSESSIONID这个Cookie到底干了啥？充当了什么角色？
JSESSIONID这个Cookie存储的value就是服务端记录该客户端状态的Session ID（服务器自己产生，不会重复）。
它所充当的角色就是桥梁，让具体客户端能够找到在服务端相对应的Session。
产生这个名为JSESSIONID的Cookie，是服务端在创建Session的时候产生的。（如果web容器用的是非Tomcat，那么这个Cookie的名字就不叫JSESSIONID了，但是作为使用者，我们不需要关心这个Cookie的名是什么，因为客户端第二次访问服务器的时候，服务器通过该Cookie名找到相应的SessionId（Cookie所对应的值）并不需要我们手动实现。）
不美好的现实
如果浏览器都允许使用Cookie的话，那么很多人都会直接使用服务器产生Session的同时相应给客户端一个名为JSESSIONID的Cookie。下次客户端请求服务器给携带过来。
的确，这种方式简单，省事。但是，我们一直强调——Cookie是不安全的 （这也是好多浏览器器禁止使用Cookie的原因）
Cookie的安全性
为什么Cookie是不安全的呢？因为Cookie是存在客户端的，可以通过篡改Cookie的值来达到欺骗服务器的目的，然后 “非法” 的进行一些 “合法” 的操作。
这里我说一下我知道的比较浅显的篡改（伪造）Cookie方式：
第一步：用合法的身份登录一个网站（登录之后的页面）
第二步：实现伪造Cookie来达到欺骗服务器的目的
打开另外一个浏览器，输入相应网址
伪造Cookie
通过上述例子，我们可以清楚的了解到Cookie的不安全性，这也是为什么越来越多的企业不会使用Cookie机制来获取客户端状态的原因。
同样的，和Session相关的名为JSESSIONID的Cookie，安全吗？虽然说SessionID不可能重复，可是万一呢？篡改者运气好到爆呢？刚好把JSESSIONID的值改为另外一个客户端在服务器上的SessionID。
有关Session的攻击可以看这篇博客：Session攻击（会话劫持+固定）与防御
技术就是这样，因为需求，所以有了这项技术。
同样的，为了避免Cookie的不安全性，Session最好是不要和Cookie有关（侧面的讲出了Session可以不依赖于Cookie），因此就有了URL重写技术。