Http,自动登录(涉及cookie)

1.Http协议

  • 消息的分类
  1. http消息分为请求消息  和 相应消息。
  • 特点
  1. 基于TCP/IP协议之上,默认端口号是80
  2. 无连接:限制每次连接值处理一个请求,服务器处理完客户端的请求,接受到客户端的应答后,即断开。采用这种方式可以节省传输时间。
  3. 无状态:对事物处理没有记忆能力。
  • 消息的基本格式

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

  1. 首行
  2. 请求头
  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,这个值的有无,导致了解析的方式不同。


参考:

http://codecloud.net/http-network-7073.html

http://www.imooc.com/article/1851



            



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值