HTTP无状态 与 服务器断开连接 的关系

楼主把问题看得太复杂了

本是约定俗成的问题

HTTP：超文本传输协议（Hypertext Transfer Protocol）

http://baikebaiducom/view/9472htm

这只是个规则而已就像车水马龙都要遵守交通规则

至于链接的断开与否就类似于打电话了我打过去那边接了就是响应我了链接就开了其实这个过程是个双通道他那边接了也就是在询问我我要不要和他建立连接我这边默认是同意了于是我也和他建立了一个链接

日绕昏了书上还有更绕的"权威"解释看书吧

众所周知，http的连接是无状态的。

HTTP无状态协议是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。

通俗一点讲就是你每次请求服务器的时候，它并不知道你是谁，但实际上现在的网站并不是这样的，因为它们使用了cookie和session来辅助服务器记住你是谁，简单来讲这两者就是你进入这个网站的钥匙。关于cookie和session的具体内容和差别，可以去找度娘聊聊。

可能有的同学会有疑问，我在做网站开发的时候并没有设置cookie啊，那是怎么识别用户的呢？

其实在你首次登陆某个网站的，没有任何cookie的时候（首次登陆或者清除），服务器会给你返回一个自生成的id（tomcat默认的叫JSESSIONID，百度的叫BAIDUID，简书的叫_session_id，当然每个都可能不一样，这个是可以自定义的）cookie值写入你的浏览器。那这个sessionid（以下都会这么叫）就是你进入网站的钥匙。当你登陆的时候，请求会携带这个cookie值传入后台。

（向后台传递的数据）

一般登陆后台的处理就是如果用户登陆成功，那么就将用户id或者。。。保存至session中，那这样就生成了一条识别链。

（简易的识别链）

大概的解释一下：当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识称为sessionid，如果已包含则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，sessionid的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个sessionid将被在本次响应中返回给客户端保存。之后的每次访问都会携带上这个sessionid，然后查找对应的session和session中的值，服务器进行登陆判断和权限判断。

关闭浏览器、长时间没有请求服务器、注销登陆，这个时候服务器会把该sessionid从内存中清除掉，这个时候如果我们再去请求服务器，sessionid已经不存在了，所以服务器并没有在内存中找到对应的 sessionid，所以会再产生一个新的sessionid，这个时候一般我们又要再登录一次。

细心的同学会发现，那么是不是意味着，如果我拿到了你这个sessionid我就可以冒充你来访问这个网站了？没有错，如果网站没有很好的防护，确实可以这么做。具体怎么实现我这就不太方便说了，感兴趣也可以度娘cookie窃取欺骗和攻击。

所以请各位同学保护好自己的cookie，不要轻易被偷窃走哦。

无状态是针对于“状态”来说的。

一个WEB应用协议中的“状态”指的是，为两个相互关联的用户交互操作保留某种公共信息，例如用户登录信息，工作流等。

这些信息具有不同作用域，如page，request，session，application等。通常由服务器负责保存这些信息。

“无状态”

的概念逐渐流行，得益于分布式系统的发展。首先，无状态请求易于实现负载均衡。在分布式web系统下，有多个可用服务器，每个服务器都可以处理客户端请求。

传统的有状态请求，因为状态信息只保存在第一次发起请求的那台服务器上，之后的请求都只能由这台服务器来处理，服务器无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用服务器来处理，而有状态的请求则会因为存储请求状态信息的服务器宕机而承担状态丢失的风险。

需要注意的是，“状态"指请求的状态，而不是资源的状态。Restful风格的无状态约束要求服务器不保存请求状态，如果确实需要维持用户状态，也应由客户端负责。传递user

credentials 是Restful的，而传递sessionID是unRestful的,因为session信息保存在服务器端。

在无状态自动配置（Stateless Autoconfiguration）过程中，主机首先通过将它的网卡MAC地址附加在链接本地地址前缀1111111010之后，产生一个链路本地单点传送地址。接着主机向该地址发出一个被称为邻居发现（neighbor discovery）的请求，以验证地址的唯一性。如果请求没有得到响应，则表明主机自我设置的链路本地单点传送地址是唯一的。否则，主机将使用一个随机产生的接口ID组成一个新的链路本地单点传送地址。然后，以该地址为源地址，主机向本地链路中所有路由器多点传送一个被称为路由器请求（ router solicitation）的配置信息。路由器以一个包含一个可聚集全球单点传送地址前缀和其它相关配置信息的路由器公告响应该请求。主机用它从路由器得到的全球地址前缀加上自己的接口ID，自动配置全球地址，然后就可以与Internet中的其它主机通信了。使用无状态自动配置，无需手动干预就能够改变网络中所有主机的IP地址。

更简单的理解是无状态就是自动分配，有状态是要用网管分给你的地址，不完全正解。但基本可以简单这样理解。

HTTP协议是无状态协议

客户端与服务器进行动态交互的Web应用程序出现之后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态，而这些不同的技术就是Cookie和Session了。

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

尽管AJAX技术的出现才不到两年时间，但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人员，就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构，凡是采用AJAX技术的页面简洁而又丰富，一个页面表现了丰富多彩的形态。

AJAX技术还使用了一种不同于XML格式的JSON文件格式，这个意义在哪里呢？在REST软件架构下我们不能对于XML文件进行序列化处理，这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可，它被认为能以远比XML更好的方式来序列化和传输简单数据结构，而且它更简洁。这对REST是一个极大贡献和补充。

当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态，客户端的状态自己来管理，这是AJAX技术的应用之地。通过AJAX技术，可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。

原文摘自： http://blogcsdnnet/tennysonsky/article/details/44562435

HTTP 是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点：1、支持客户/服务器模式；2、简单快速；3、灵活； 4、无连接；5、无状态 。

无连接

无连接的含义 是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

早期这么做的原因是 HTTP 协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，大部分通道实际上会很空闲、无端占用资源。因此 HTTP 的设计者有意利用这种特点将协议设计为 请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端 。

随着时间的推移，网页变得越来越复杂，里面可能嵌入了很多，这时候每次访问都需要建立一次 TCP 连接就显得很低效。后来，Keep-Alive 被提出用来解决这效率低的问题。

Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接 。市场上的大部分 Web 服务器，包括 iPlanet、IIS 和 Apache，都支持 HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive 功能对资源利用的影响尤其突出。

这样一来，客户端和服务器之间的 HTTP 连接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

无状态

无状态 是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。HTTP 协议这种特性有优点也有缺点，优点在于解放了服务器，每一次请求“点到为止”不会造成不必要连接占用，缺点在于每次请求会传输大量重复的内容信息。客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。

Cookie可以保持登录信息到用户下次与服务器的会话，换句话说，下次访问同一网站时，用户会发现不必输入用户名和密码就已经登录了 （当然，不排除用户手工删除Cookie）。而还有一些Cookie在用户退出会话的时候就被删除了，这样可以有效保护个人隐私。Cookies 最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入 Cookies，以便在最后付款时提取信息。

与 Cookie 相对的一个解决方案是 Session，它是通过服务器来保持状态的。 当客户端访问服务器时，服务器根据需求设置 Session，将会话信息保存在服务器上，同时将标示 Session 的 SessionId 传递给客户端浏览器，浏览器将这个 SessionId 保存在内存中，我们称之为无过期时间的 Cookie。浏览器关闭后，这个 Cookie 就会被清掉，它不会存在于用户的 Cookie 临时文件。以后浏览器每次请求都会额外加上这个参数值，服务器会根据这个 SessionId，就能取得客户端的数据信息。如果客户端浏览器意外关闭，服务器保存的 Session 数据不是立即释放，此时数据还会存在，只要我们知道那个 SessionId，就可以继续通过请求获得此 Session 的信息，因为此时后台的 Session 还存在，当然我们可以设置一个 Session 超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应 SessionId 的 Session 信息。