Get与Post_Cookie与Session.docx

Http协议详解
1.HTTP的请求响应模型
HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。（所以才有了Cookie和Session）

HTTP协议永远都是客户端发起请求，服务器回送响应。见下图：
这样就限制了使用HTTP协议，无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端。
那么如何实现消息从服务器端主动推送给客户端呢？
1.采用第三方推送，如百度云（或腾讯的信鸽推送）。服务器端把消息给第三方，第三方帮你把消息发给连接到他的并且订阅过你这个主题的客户端
2.打开应用时向服务器发申请，其实还是客户端发起请求，只是这个请求是自动的，用户感觉不到
3.如果应用一直打开，或者有后台服务，可以定时向服务器发申请
1.1请求：Request
服务器端request的从客户端传来的信息
1.2响应：Response
服务器端response给客户端处理之后的信息，都是以服务器端为主体的
2.GET与POST的差别（是以客户端为主体）：
GET是客户端获取服务器端的资源（比如要从服务器上获取id=1234的数据的信息，就在url后http://.../id?1234）（一般将需要获取的资源加载URL后面，所以不安全，而且数据量有限，只有1024B。但是执行效率比POST好）
POST是客户端发送给服务器端的资源（比如表单中的数值需要传送给服务器端进行处理）（这些数据一般html的header里面，所以原则上没有大小的限制，当然，不能超过header的容量）
GET有两个特性：安全性和幂等性
安全性意味着该操作用于获取信息而非修改信息。
幂等性意味着对同一URL的多个请求应该返回同样的结果。
换句话说，GET请求一般不应产生副作用。从根本上讲，其目标是当用户打开一个链接时，她可以确信从自身的角度来看没有改变资源。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。
POST请求就不那么轻松了。POST表示可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对文章的注解应该通过POST请求实现，因为在注解提交之后站点已经不同了（比方说文章下面出现一条注解）。
建议：
1、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
2、在做数据查询时，建议用Get方式（因为这是从服务器获取数据）；而在做数据添加、修改或删除时，建议用Post方式（因为这是向服务器传送数据）；
3.Cookie和Session
Cookie和Session都为了用来保存状态信息，都是保存客户端状态的机制，它们都是为了解决HTTP无状态的问题而所做的努力。
Session可以用Cookie来实现，也可以用URL回写的机制来实现。用Cookie来实现的Session可以认为是对Cookie更高级的应用。
3.1两者比较
Cookie和Session有以下明显的不同点：
Cookie将状态保存在客户端，Session将状态保存在服务器端；
Cookie因为保存在客户端，安全性较低；Session安全性较高；
Cookie不影响服务器性能，但是Session会影响
Session是针对每一个用户的，变量的值保存在服务器上，用一个JsessionID来区分是哪个用户。Session类似与Cache的Map，在有效期内不会被GC。
3.2Session机制
session对象的信息保存在服务器中，但是ID保存在客户机的cookies中如果客户机不支持Cookies则转为URL重写，一般使用session对象时不必考虑其实现的细节问题。
Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个sessionid，如果已包含一个sessionid则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，sessionid的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个sessionid将被在本次响应中返回给客户端保存。
当用户关闭某个Web服务器上所有的网页时，此服务器与客户机的session对象及其变量会自动消失
Session的实现方式
下面的两种方式其实大同小异，一个是在cookie中加上这个sessionId，另一个实在每次的Url中加上