Http,自动登录（涉及cookie）

最新推荐文章于 2024-07-17 10:44:11 发布

qd573717339

最新推荐文章于 2024-07-17 10:44:11 发布

阅读量1.3k

点赞数

文章标签： Http Cookie

本文链接：https://blog.csdn.net/qd573717339/article/details/50924608

版权

1.Http协议

消息的分类

http消息分为请求消息和相应消息。

特点

基于TCP/IP协议之上，默认端口号是80
无连接：限制每次连接值处理一个请求，服务器处理完客户端的请求，接受到客户端的应答后，即断开。采用这种方式可以节省传输时间。
无状态：对事物处理没有记忆能力。

消息的基本格式

请求消息和响应消息的格式基本相似，基本分为3部分

首行
请求头
正文

其中，头部用来指出HTTP消息的一些属性，它们有固定的格式；正文部分是传输的实际内容，它们的格式是任意的，通常用Content-Type头来指定。首行在请求消息和响应消息中具体格式略有区别，它们表示的按理说应该是HTTP消息最基本的部分。不论是HTTP请求还是HTTP响应，首行都是有的，否则会出现不可饶恕的解析错误；然而头部和正文是可选的，不过实际过程中，多多少少都要包含一些基本的头。

HTTP消息主要是基于ASCII编码的消息实体。主要的意思是指首行和头部都是以ASCII编码，而正文部分的编码就显得任意了。在实际的开发中，发送的文本消息时常会碰到乱码的问题。一种解决办法是，对于文本消息，约定以UTF-8格式进行编码和解码。

知道的人也许知道，HTTP消息是基于TCP协议的上层应用协议。TCP协议是网络流协议的一种。抽象地讲，就是从一台主机一个字节一个字节有序地传输到另一台主机。对于HTTP协议来说，自然保持了这种有序性，即按照首行、头部、正文的顺序进行传输。首行和头部都是ASCII文本流，正文部分是字节流。一个特殊的控制结构CRLF用来控制每个部分的结束。

GET请求报文示例：

<span style="font-size:18px;"> GET /books/?sex=man&name=Professional HTTP/1.1      //首行
 Host: www.example.com                                          //以下几行都是请求头
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Connection: Keep-Alive</span>

POST请求报文示例
```
 POST / HTTP/1.1                     
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 40
 Connection: Keep-Alive

 sex=man&name=Professional 
```
- GET可提交的数据量受到URL长度的限制，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制
- 理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，出于安全考虑，服务器软件在实现时会做一定限制
- 参考上面的报文示例，可以发现GET和POST数据内容是一模一样的，只是位置不同，一个在URL里，一个在HTTP包的包体里
HTTP请求的方法
- GET POST HEAD DELETE HEAD PATCH OPTIONS
- 之前说过，服务器对于方法的处理，是没有强制的规范的。这句话说得并不全对。其实每个HTTP方法，都是有一些HTTP协议要求的。比如说GET方法请求的资源，浏览器端一般都会有缓存，下次请求的时候可能从缓存中去取就够了，服务器不用再重复发送相同的资源了；但是服务器如果将获取资源的接口的方法定义为POST，那么浏览器端就不会再对资源进行缓存了，即使每次取到的都是同样地内容，都会请求服务器重新发送一遍。所以说，将请求资源的接口的方法定义为POST而不是GET，就是一种不合理的设计。
  
  再比如，GET方法的请求消息是不能定义消息体的，HEAD方法的请求其响应消息是不包含消息体的，这些都是HTTP协议对于HTTP方法的约束。

HTTP响应
- 响应行
- 响应头
- 响应正文

http响应的示例：

HTTP/1.1 200 OK                     //响应行  （版本号，状态码，状态文本）

Server:Apache Tomcat/5.0.12         //响应头
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>...                          //响应正文

常见的状态码有如下几种

200: 客户端请求成功
301: 请求永久定向
302: 请求临时定向
404: 请求的资源部存在，例如：输入了错误的url
500: 服务器发生了不可一起的错误

2.自动登录

最直接的方式
- 登录成功后，本地保存用户名和密码。但是需要进行加密，对称加密是不可靠的，因为很难确保App的源码不泄露，别有用心的人还是可以根据源码中的对称加密算法，反向把密码推算出来。只有不对称加密才是最安全。
Cookie机制（也叫Token）
- App在登录成功后，会从服务器获取到一个Cookie,这个Cookie存放在HttpRequst的header中，我们不需要关心，他是什么，只需要将其保存咋本地即可。
- 每次发起网络请求的时候，就把保存在本地的cookie取出来，添加到请求头中。
- 每次接收到响应时，都需要把HttpResponse中的header中的Cookie取出来，覆盖掉本地保存的cookie,不管Cookie有值与否。
- 用户注销，需要将本地保存的Cookie清空。
开启gzip压缩
- Http协议上的gzip编码是一种用来改进Web应用程序性能的技术。
- 大Web站点常使用此技术来减少传输量的大小，这样可以减少存储空间，减少网路传输时间
- 在App发起网络请求的时候，在HttpRequst头中,添加支持gzip的key-value,key是Accept-Encoding，value是gzip.
- 当服务器返回数据时，检查HttpResponse头中的content-encoding字段是否包含gzip,这个值的有无，导致了解析的方式不同。