浅谈HTTP的无状态性

HTTP是Hyper Text Transfer Protocol的缩写，顾名思义，这个协议支持着超文本的传输。那么什么是超文本呢？说白了就是使用HTML编写的页面。通常，我们使用客户端浏览器访问服务器的资源，最常见的URL也是以html为后缀的文件。因此，我们可以说超文本是网络上最主要的资源。

        既然HTTP协议的目的在于支持超文本的传输，更加广义一些就是支持资源的传输，那么在客户端浏览器向HTTP服务器发送请求，继而HTTP服务器将相应的资源发回给客户端这样一个过程中，无论对于客户端还是服务器，都没有必要记录这个过程，因为每一次请求和响应都是相对独立的，就好像你在自动售货机前投下硬币购买商品一样，谁都不会也不需要记住这样一个交易过程。一般而言，一个URL对应着唯一的超文本，而HTTP服务器也绝对公平公正，不管你是Michael，还是Jordon，它都会根据接收到的URL请求返回相同的超文本。正是因为这样的唯一性，使得记录用户的行为状态变得毫无意义，所以，HTTP协议被设计为无状态的连接协议符合它本身的需求。

        然而，随着时间的推移，人们发现静态的HTML着实无聊而乏味，增加动态生成的内容才会令Web应用程序变得更加有用。于是乎，HTML的语法在不断膨胀，其中最重要的是增加了表单（Form）；客户端也增加了诸如脚本处理、DOM处理等功能；对于服务器，则相应的出现了CGI（Common Gateway Interface）以处理包含表单提交在内的动态请求。在这种客户端与服务器进行动态交互的Web应用程序出现之后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。

        Cookie是通过客户端保持状态的解决方案。从定义上来说，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。让我们说得更具体一些：当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中的，而是存放于HTTP响应头（Response
Header）；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置，对于Windows操作系统而言，我们可以从：[系统盘]:\Documents and Settings\[用户名]\Cookies目录中找到存储的Cookie；自此，客户端再向服务器发送请求的时候，都会把相应的Cookie再次发回至服务器。而这次，Cookie信息则存放在HTTP请求头（Request Header）了。

        有了Cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。通常，我们可以从很多网站的登录界面中看到“请记住我”这样的选项，如果你勾选了它之后再登录，那么在下一次访问该网站的时候就不需要进行重复而繁琐的登录动作了，而这个功能就是通过Cookie实现的。

   

        与Cookie相对的一个解决方案是Session，它是通过服务器来保持状态的。由于Session这个词汇包含的语义很多，因此需要在这里明确一下Session的含义。首先，我们通常都会把Session翻译成会话，因此我们可以把客户端浏览器与服务器之间一系列交互的动作称为一个Session。从这个语义出发，我们会提到Session持续的时间，会提到在Session过程中进行了什么操作等等；其次，Session指的是服务器端为客户端所开辟的存储空间，在其中保存的信息就是用于保持状态。从这个语义出发，我们则会提到往Session中存放什么内容，如何根据键值从Session中获取匹配的内容等。

        要使用Session，第一步当然是创建Session了。那么Session在何时创建呢？当然还是在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同创建Session的方法，而在Java中是通过调用HttpServletRequest的getSession方法（使用true作为参数）创建的。在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有Session
id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。正式这样一个过程，用户的状态也就得以保持了。有关Session的内容还比较多，在以后的Post中，我还将继续讲述。

        综上所述，HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态，而这些不同的技术就是Cookie和Session了。

PS：

   1.每个Session都有一个Session   ID,这个ID是存放在哪里的呢？有两种情况，一种是通过Cookie存取（Tomcat里面默认就是如此），还有一种是通过重写Url存取，后面的方法会在Url上多出一个字符串如sessionid=llkjkl3k22390等等，这样每次重新来过的时候都把Url中的SessionID传一次。而 Cookie的方式就较简单，程序一开始执行，服务器就生成一个SessionID并通过Cookie写在客户端浏览器的缓冲中，当下一次访问的时候，服务器先检测一下是否有这个Cookie，如果有，取他的ID，如果没有，新生成一个。这就是为什么大家关闭浏览器后，再进去Session已经找不到了，其实在服务器端Session并没有清空，而是SessionID变了。   

  session里面的数据都放在服务器端，通过sessionID保证不会访问错误，服务器端自动对Session进行管理，如果在规定时间内没有访问，则释放这个Session。因此，当客户关闭浏览器，他用过的Session没有人去访问，就会在一段时间内被释放。   

  由上可见，Session是通过一个ID建立客户端和服务器端的联系的，因此，象那些想在浏览器关闭的同时释放Session不可行（除非触发一个页面去手工释放）就不奇怪了。因为Cookie是可窗口绑在一起的，当浏览器全部关闭，这个cookie也就没有用了，下一次再来，有新生成一个Cookie，又是一个新的Session了，大家可以试试，把浏览器的Cookie不接收，那样Session就没有用了。 

    2.http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，我们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session
cookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID，我们通常情是看不到JSESSIONID的，但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到sessionid=KWJHUG6JJM65HS2K6之类的字符串。

明白了原理，我们就可以很容易的分辨出persistent cookies和session cookie的区别了，网上那些关于两者安全性的讨论也就一目了然了，session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，自然不如 session cookie安全了。

通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到了，此时我们可以先把sessionid保存在persistent cookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。

在一些web开发的书中，往往只是简单的把Session和cookie作为两种并列的http传送信息的方式，session cookies位于服务器端，persistent cookie位于客户端，可是session又是以cookie为基础的，明白的两者之间的联系和区别，我们就不难选择合适的技术来开发web service了。