Ⅰ http协议无状态是什么意思让web应用有状态的机制
http协议无状态的意思如下：
1、协议对于事务处理没有记忆能力【事物处理】【记忆能力】
2、对同一个url请求没有上下文关系【上下文关系】
3、每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况【无直接联系】【受直接影响】
4、服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器【状态】
Web应用=http协议+session、cookies等状态机制+其他辅助的机制。
其实，应用程序(软件通信)的有状态与否是一个非常通用的概念。我们可知，在网络协议中，我们称TCP为一个有状态的传输层通信协议，而UDP则不是；IP是无状态的。
要明白这种有状态与否的判定，是指你这一协议栈层次所要实现的功能——是否由上下文决定——来判定的（是否受之前的通信过程直接影响、是否直接影响之后的通信过程）。
(1)web的无状态扩展阅读
关于网络应用层次中的各层次的有无状态情况。可以知道，支持协议（下层）的有无状态，消费协议（上层）的有无状态，没有直接的关系。每层协议的有无状态与它的本身功能执行的时候的有无状态的特点有关。
（1）IP是无状态的，它只负责将一个IP包发送到指定的IP地址上去。它不会考虑这个包与前面已经发送的包和后面的包的联系。（可能是重发包、可能是不连续包，它不管）。
（2）TCP是有状态的，它通过包头中的一些控制字段（序列编码等）来表明各个包之间的关系（前后关系，重包与否等等）。所以，通过这个协议你可以做到一个可靠的传输。其实这里的面向连接其实就是“三次握手”。
三次握手，首先可以保证对方的存在，其次握手的所交换的内容是为将来进行有状态的传输做准备。
（3）UDP是无状态的，它仅仅是在IP上加了Port，其他的事情什么也不干。这样它不可能做到可靠的传输，同样也不需要连接。
（4）HTTP是无状态的，它的底层协议是由状态的TCP，但是HTTP的一次完整协议动作，里面是使用有状态的TCP协议来完成的。
而每次协议动作之间没有任何关系。例如：第7次请求HTTP协议包，它或许是因为上次没有请求成功而重传，或许是上次的后续请求，或许是其他的，这些HTTP自身都不知道。
（5）www应用，很多时候，www应用是需要每个HTTP请求或应答动作之间是有关联的，那就是使应用有状态。这样才能提供给用户最好的用户体验。
Ⅱ http是一种无状态的协议，在web应用中，采用什么手段，知道两次请求是同一用户
因为HTTP是一种无状态协议，所以引进了cookie和session.
要判断两次请求是否为同一用户，可以在刚开始就将用户名或id存入cookie或session
然后将两次的请求用户进行比较
Ⅲ Web窗体的Web 窗体页帮助您完成哪些任务
Web 应用程序编程带来了一些特殊的难题，在对传统的基于客户端的应用程序进行编程时，通常不会遇到这些难题。这些难题包括： 实现多样式的 Web 用户界面。对于布局复杂且包含大量动态内容和功能齐全的用户交互对象的用户界面而言，使用基本的 HTML 功能来进行设计和实现将会既困难又费事。其中尤为困难的是为可能在多个不同的浏览器和客户端设备平台上运行的应用程序创建多样式的用户界面。 客户端与服务器的分离。在 Web 应用程序中，客户端（浏览器）和服务器是不同的程序，它们通常在不同的计算机上运行（甚至在不同的操作系统上运行）。因此，共同组成应用程序的这两个部分仅共享很少的信息；它们可以进行通信，但通常只交换很小块的简单信息。 无状态执行。当 Web 服务器接收到对某页的请求时，它会查找该页，对其进行处理，将其发送到浏览器，然后丢弃所有页信息。如果用户再次请求同一页，服务器则会重复整个过程：从头开始对该页进行重新处理。换言之，服务器不会记忆它已处理的页。因此，如果应用程序需要维护有关某页的信息，这就成为一个必须在应用程序代码中解决的问题。 未知的客户端功能。在许多情况下，Web 应用程序可由多个使用不同浏览器的用户进行访问。浏览器具有不同的功能，因此很难创建将在所有浏览器上都同样正常运行的应用程序。 数据访问方面的复杂性。对位于传统 Web 应用程序的数据源进行读取和写入可能比较复杂，并且会消耗大量资源。 可缩放性方面的复杂性。在许多情况下，由于应用程序的不同组件之间缺乏兼容性，用现有方法设计的 Web 应用程序未能实现可缩放性的目标。对于发展周期较短的应用程序，这往往是唯一会导致失败的地方。 若要解决这些 Web 应用程序的难题，可能需要大量的时间和精力。Web 窗体页和 ASP.NET 页框架通过以下几个方面来处理这些难题： 直观、一致的对象模型。ASP.NET 页框架提供了一种对象模型，它使您能够将窗体当作一个整体，而不是分离的客户端和服务器模块。在此模型中，您可以通过比在传统 Web 应用程序中更为直观的方式来对窗体进行编程，其中包括能够设置窗体元素的属性和响应事件。此外，ASP.NET 服务器控件是基于 HTML 页的物理内容以及浏览器与服务器之间的直接交互的一种抽象模型。通常，您可以按照在客户端应用程序中使用控件的方式使用服务器控件，而不必考虑如何创建 HTML 来显示和处理控件及其内容。 事件驱动的编程模型。Web 窗体页给 Web 应用程序带来了一种您熟悉的事件处理程序编写模型，用于为客户端或服务器上发生的事件编写事件处理程序。ASP.NET 页框架对此模型进行了抽象，使捕获客户端上的事件、将其传输到服务器并调用适当方法等操作的基础机制都是自动的，并对于实施者都是不可见的。这样就得到了一个清晰的、易于编写的、支持事件驱动开发的代码结构。 直观的状态管理。ASP.NET 页框架自动处理窗体及其控件的状态维护任务，它使您能够以显式方式维护应用程序特定信息的状态。这种状态管理无需使用大量服务器资源即可实现，而且可以通过向浏览器发送 Cookie 来实现，也可以不通过向浏览器发送 Cookie 来实现。 独立于浏览器的应用程序。ASP.NET 页框架支持在服务器上创建所有应用程序逻辑，使您无需为浏览器中的差异而进行显式编码。但是，它仍允许您自动利用浏览器特定的功能，方法是通过编写客户端代码来提供增强的性能和更丰富的客户端体验。 .NET Framework 公共语言运行库支持。ASP.NET 页框架是 ASP.NET 的一项技术。ASP.NET 是基于 .NET Framework 生成的，因此整个框架都可用于任何 ASP.NET 应用程序。您可以使用任何与运行库兼容的语言（包括 Microsoft Visual Basic、Visual C# 和 JScript .NET）来创作应用程序。此外，数据访问通过 .NET Framework 提供的数据访问基础结构（包括 ADO.NET）得到了简化。 .NET Framework 可缩放服务器性能。ASP.NET 页框架使您能够将 Web 应用程序从一台只装有一个处理器的计算机有效地缩放到多计算机“网络场”(Web farm)，而无需对应用程序的逻辑进行复杂的更改。
Ⅳ 什么是Http无状态Session、Cookie、Token三者之间的区别
HTTP无状态协议，是指协议对于交互性场景没有记忆能力。
在点击一个纯的html网页，请求获取服务器的html文件资源时，每次http请求都会返回同样的信息，因为这个是没有交互的，每一次的请求都是相互独立的。第一个请求和第二个请求也没有先后顺序，返回处理哪个，结果都是同样的资源页面，因为这种场景是无交互的，无论是什么人请求这个地址，服务器都是返回那个相同的响应。
在无交互场景中上面那样，当然也不会有太大的问题。但是对于涉及到动态交互的场景，就显得很尴尬了，何为交互？有来又有往，对于一模一样的两个接口，不同的人在请求第二个接口时可能会基于请求第一个接口的结果而有所不同。
现在我们来想一个复杂的场景，如在购物网站上买一个书包，流程如下：
所谓的登录只是验证你是否是一个合法用户，若是合法则跳转到信息的页面，不合法则告知用户名密码错误。
但是我们在第一步给服务器发完/login接口后，服务器就忘记了。。。忘记了你这个人，到底有没有经过认证。
所以在添加商品时/cart 你还是需要将你的账号密码和商品信息一起提交给 addCart接口，再让服务器做验证。
第三步同理。
所以当我们说涉及到交互时，情形就完全不一样了，因为这三步是有依赖关系的，第一步验证登录者是一个合法用户，验证通过给你返回200/OK，但是只要服务器给返回了响应，那么一个http的请求和响应就结束了。服务器怎么知道10秒钟之前你刚刚登录过呢？不好意思，服务器不知道你有没有登陆过，他只是对外提供一个登录接口，要想证明你是合法用户必须调/login接口。
第二步，将商品加入到购物车中时，你会调用/cart接口，但是注意，这个行为是和第一步是有关联关系的，是谁将什么物品加入到购物车中了？这个谁，有没有在网站上注册账号呢，是不是一个合法用户呢？所以说在添加购物车的时候，我们还需要将账号密码再次加入到请求参数中，每做一次操作购物车操作时，都需要再把之前已经传输过的账号密码，再反反复复的传输一遍又一遍，这是因为服务器不知道你是不是在20秒之前刚登陆过。
上面的无状态是指的，无登录状态，即服务器不知道某个用户是否已登录过了。因为愚蠢的服务器不知道客户端是否已登录过了,所以每次都要在交互场景(会话)中请求中带上上一次的请求信息，如账号、密码。明明只需要在/login接口中，才需要对比数据库中的账号密码和客户端传的是否一致来确定合法性。这下在添加购物车中也需要再一次地进行同样的重复且没有必要的操作，即降低了响应速度，又对用户不友好(因为每次都需要填账号，密码)。
缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另外人们常说的“会话”概念则是上面的交互行为的另一种表述方式。
通过上面我们知道了Http中无状态是一个什么概念，以及在无状态情况下，要进行添加购物车功能，所带来的困难。
客户端与服务器进行动态交互的Web应用程序出现之后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态，而这些不同的技术就是Cookie和Session了。
由于HTTP是一种无状态的协议，服务器 单纯从网络连接上 无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己的通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时， 浏览器把请求的网址连同该Cookie一同提交给服务器 。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Bai也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Bai颁发的Cookie呢？或者Google能不能修改Bai颁发的Cookie呢？
答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Bai的Cookie。Google也只能操作Google的Cookie，而不能操作Bai的Cookie。
Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作Bai的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Bai的域名不一样，因此Google不能操作Bai的Cookie。
1.在登录网站的时候选择记住密码
2.点击之后观察服务器上的相应内容
3.查看Chrome中的Cookie设置
4.观察服务器返回的Cookie内容
5.再次访问时，发现不需要输入密码即可直接登录，观察请求头信息
cookie并不是单纯为了实现 session机制而生的。而是1993 年，网景公司雇员 Lou Montulli 为了让用户在访问某网站时，进一步提高访问速度，同时也为了进一步实现个人化网络，发明了今天广泛使用的 Cookie。cookie还有一个很广泛的用途就是记住用户的登录账号和密码，这样当用户以后再次需要登录同一个网站或系统的时候就不需要再次填写这两个字段而是直接点击“登录”按钮就好。这就相当于给了一些“甜头”给用户，这就回应了“cookie”这个词语的字面意思了。
实现方法是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。
我是 “翎野君” ，感谢各位朋友的： 点赞 、 收藏 和 评论 ，我们下期见。
Ⅳ java web,由于Http协议是无状态，采用如下的哪个方法保存客户状态的数据，没有大小限制，而且性能表现最好
A.Session
session是通过操作浏览器cookie，生成随机的cookie值（JSESSIONID）,然后回传给服务端，服务端根据该cookie值找到对应保存在服务端的数据。
session的方式是结合cookie为一体的，如果客户端不支持Cookie(客户端禁用)，那就必须在访问的URL后面传递SessionID来获取保存在服务端的session值。
cookie不能说不安全，cookie如果保存在客户端时，用可逆算法加密后再保存在客户端的话，也挺安全。但是，数据过多的话，导致每次都要把cookie回传给服务器，会影响效率。
urlrewrite只适合传递简单的参数，而且有长度限制，更会引起安全问题（浏览器历史记录会完整的记录访问的URL）。
隐藏表单，同样的，每次访问需回传给服务器，造成速度缓慢（asp.net就喜欢这种方式）
4个选项当中安全性最高的是session，速度最快的也是session ,因为他要客户端回传的数据少