由于http是无状态协议，所以如果要维持client和server之间的会话（比如维护一个登录状态），就需要付出额外的努力，这就是cookie、session所做的努力。
cookie是在client存储用户信息，优势在于减轻了server的负担，劣势在于安全性低（如果用户B得到了用户A的cookie，B就可以以A的身份与server交互），每次与server通信都需要携带cookie，略微增加了网络开销;
session是在server存储用户信息，cookie的优、劣势正是session劣、优势，现在的大型网站通常都会优先使用cookie来维护client与server的对话，因为这样不但可以减轻server负担（大网站的用户量会很大，session占用的资源也会很可观），还可以方便使用集群式server（如果采用session，一个server挂掉，与该server会话的client就需要重新登录了，或者server还需要配置多点session）。
下图是baidu的一个cookie：
javax.servlet.http.Cookie的可配置属性如下，
唯一构造器Cookie(String name, String value)；
httpOnly为true时，cookie不会暴露给client的script，减少了xss攻击（xss攻击即跨站脚本攻击，通过在合法网站内嵌入非法脚本，已达到攻击用户的目的。比如在合法网站嵌入一条链接，该链接指向非法服务器，并携带用户在合法网站的Cookie数据，通过诱导用户点击该链接，最终获取用户Cookie）；
secure为true时，cookie只会在https环境下传输；
javax.servlet.http.HttpSession的可配置属性如下，可以看出session本身就应该是一个map（session容器同样是一个map）：
通常网站处于安全考虑，会修改session的默认名字（jsession），对于tomcat来说可以在server.xml的context标签中配置session名字：
<!--将JSESSION改名为ZY_SESSION，sessionCookiePath指明在该host下所有sessionCookie的path，不建议设置--> <Context path="" docBase="xxxxwebapp" reloadable="false" sessionCookiePath="/" sessionCookieName="ZY_SESSION"/>
http是无状态的，既然是无状态的，要维持会话在通信时必然需要携带身份信息，session也不可能只在server维护一些状态就可以保持与client的会话，session其实也是基于cookie的（也可以url重写）。server生成session后会在response中放入cookie（name为jsession，value为server生成的随机串，有效时间就是session的存活时间），client视jsession为普通cookie，当client携带此cookie与server通信时，server就可以根据jsession的value在session容器中找到对应的用户信息。所以说http维持会话状态的根本还是需要client携带身份信息进行请求，这一点不论是session、cookie还是url重写都不会改变。