http协议无状态是什么意思？让web应用有状态的机制？

http协议无状态的意思如下：

1、协议对于事务处理没有记忆能力事物处理记忆能力

2、对同一个url请求没有上下文关系上下文关系

3、每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况无直接联系受直接影响

4、服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器状态

Web应用=http协议+session、cookies等状态机制+其他辅助的机制。 

其实，应用程序(软件通信)的有状态与否是一个非常通用的概念。我们可知，在网络协议中，我们称TCP为一个有状态的传输层通信协议，而UDP则不是；IP是无状态的。

要明白这种有状态与否的判定，是指你这一协议栈层次所要实现的功能——是否由上下文决定——来判定的（是否受之前的通信过程直接影响、是否直接影响之后的通信过程）。

扩展资料

关于网络应用层次中的各层次的有无状态情况。可以知道，支持协议（下层）的有无状态，消费协议（上层）的有无状态，没有直接的关系。每层协议的有无状态与它的本身功能执行的时候的有无状态的特点有关。

（1）IP是无状态的，它只负责将一个IP包发送到指定的IP地址上去。它不会考虑这个包与前面已经发送的包和后面的包的联系。（可能是重发包、可能是不连续包，它不管）。

（2）TCP是有状态的，它通过包头中的一些控制字段（序列编码等）来表明各个包之间的关系（前后关系，重包与否等等）。所以，通过这个协议你可以做到一个可靠的传输。其实这里的面向连接其实就是“三次握手”。

三次握手，首先可以保证对方的存在，其次握手的所交换的内容是为将来进行有状态的传输做准备。

（3） UDP是无状态的，它仅仅是在IP上加了Port，其他的事情什么也不干。这样它不可能做到可靠的传输，同样也不需要连接。

（4） HTTP是无状态的，它的底层协议是由状态的TCP，但是HTTP的一次完整协议动作，里面是使用有状态的TCP协议来完成的。

而每次协议动作之间没有任何关系。例如：第7次请求HTTP协议包，它或许是因为上次没有请求成功而重传，或许是上次的后续请求，或许是其他的，这些HTTP自身都不知道。

（5） www应用，很多时候，www应用是需要每个HTTP请求或应答动作之间是有关联的，那就是使应用有状态。这样才能提供给用户最好的用户体验。

作为服务器的主机需要一直保持供电状态。

目前服务器系统电源主要采用双电源供电方式，电源工作状态有三种Activate、Standby和Normal，默认条件下两个电源状态均为Normal状态；当业务和服务增加时，可以将两个电源置成Activate状态；当业务和服务减少时，为了节省能源，在保证服务器系统能够正常运行的情况下，可以将其中一个电源置于Activate状态，另一个置成Standby状态。但是当服务器意外断电后，重新再次上电后，电源的工作状态将会恢复至默认状态，不能保持设置的工作状态，需要重新设置电源状态，浪费大量人力物力。

进入路由器的配置界面~一般是开网页打19216801或11

输入帐号密码~（看说明书）丢了就试ADMIN ADMIN

找到里面的NAT 有的是NAPT 写你要转换的IP 转换前的和转换后的 端口写80（做网页） 协议是TCP

时间功能用无状态会话bean，购物车用有状态会话bean。（不过现在很多网站类程序都不在 EJB 端用有状态会话bean而是在Web端用HTTP session保存状态）。

状态这个词汇在 EJB 中是指，我们是否期望服务器允许这个 bean 保存有状态值，因为 EJB 是启用了池化特性的，因此一大堆闲置的 bean 放在池中时它的状态有没有必要保存，因为当它下次为另一个用户的请求服务时这些东西会产生影响结果的可能性。

因此在有状态会话bean是允许这个 EJB 实现类有些非静态的字段成员，并且在 ejbCreate/ejbRemove 时会初始化或清理状态值，另外在我们从客户端 lookup 并 homecreate 之后的所有对于这个 homecreate 产生的对象 stub1 的请求都将在服务器端也被同一个 bean 实例处理（因为它可能缓存有上一次请求时留下的状态值），当然，当我们调用 homecreate 得到另一个客户端stub2 对象时它在服务器端对应的 bean 实例可能跟前一次不同但也可以跟你第一次 homecreate 那个 stub1 是相同的 （主要是看你是否已经对第一个stub1 调用了 remove 方法，调用了 remove 那表示它的生命周期结束，后面的 stub2 可能依然在服务器端得到与 stub1 时相同的实例，因为 stub1 请求已经完成后服务器端对应的 bean 实例回到池中等待重用）。像购物车需要记住车内有什么物品，这就是”状态“，在你连续的多次发起添加物品，修改数量和结算请求时需要保持状态的一致性（我们不能看到别人的购物车的信息）。

Shop stub1 = homecreate();

stub1addProduct(product1);

stub1addProduct(product2);

stub1removeProduct(product1);

Shop stub2 = homecreate();

stub2addProduct(product1);

stub1pay();

stub1remove();

Shop stub3 = homecreate(); 

stub3addProduct(product4);

// 在 stub1remove(); 之后 stub3 可能在服务端是用 stub1 当时相同的 bean 实例来服务的，因为 stub1 请求已经完成了。但 stub2 还没有完成因此 stub3 和 stub2 在服务端对应的 bean 肯定不相同，在 stub1remove() 之前 stub1 和 stub2 在服务端对应的 bean 实例也肯定不相同，因此上面这段代码要求服务器上的 EJB 缓冲池中至少有2个 Shop EJB 的实例，这点服务器是绝对保证遵守规范的。

对于无状态会话bean 来说，它就是完全不需要照顾这些，它的 ejbCreate 和 ejbRemove 这些方法也是完全没有意义的，不产生任何实际作用，也不需要被服务器调用的。

技术性的方面，当我们故意在服务端代码中无条件地抛也一个 runtime exception 不处理它，我们在服务器的 exception stack trace 中也能看出无状态和有状态的区别，因为服务器对于有状态会话bean需要记住是哪个连接请求的标记，比如客户端TCP地址和端口及一个内部唯一性的编号，而对于无状态会话bean来说，不用区分这些，因此，有些服务器（比如像 WebSphere）为无状态会话bean提供一个Share Context 的选项，意思就是说既然无状态那么应该是线程绝对安全的所以我们不需要多个池化的实例而只需要在服务器上生成唯一一个实例放入池中就可以了。