一、URI格式
二、Http协议请求和响应
1、请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成2、响应报文的组成
HTTP是一种不保存状态,即无状态协议。自身不对请求和响应之间的通信状态进行保存
三、HTTP协议支持的方法
持久连接
使用cookie来管理状态。
Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie。当下次客户端在往该服务器发送请求时,客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端发现客户端发送过来的Cookie后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。
-
没有Cookie信息状态下的请求
-
第二次以后,存有Cookie信息状态的请求
-
HTTP请求报文和响应报文的内容如下
压缩编码
内容编码指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体用客户端接收并负责解码。
常见的内容编码有以下几种
- gzip (GNU zip)
- compress(UNIX 系统的标准压缩)
- deflate (zlib)
- identity(不进行编码)
返回结果的HTTP状态码
保存资源的缓存
缓存是指代理服务器或客户端本地磁盘内保存的资源副本,利用缓存可以减少对源服务器的访问,因此能节省通信流量和通信时间。
缓存服务器是代理服务器的一种,并归类在缓存代理类型中
缓存的有效期
即使存在缓存,也会因为客户端的要求、缓存的有效期等因素,向源服务器确认资源的有效性。若判断缓存失效,缓存服务器将会再次从源服务器上获取“新”资源。
HTTP报文首部
Content-Type字段表示报文主体的对象类型
Content-Type: text/html
Keep-Alive: timeout=15,max=100
HTTP首部字段根据实际用途被分为以下4类
通用首部字段
请求报文和响应报文两方都会使用的首部请求报文字段
客户端向服务端发送请求报文时使用的首部响应首部字段
服务端向客户端返回响应报文时使用的首部实体首部字段
针对请求报文和响应报文的实体部分使用的首部
HTTP/1.1首部字段一览
-
通用首部字段
-
请求首部字段
-
响应首部字段
-
实体首部字段
Accept
Accept首部字段可通知服务器,用户代理能够处理的媒体类型以及媒体类型的相对优先级。可使用type/subtype这种形式,一次指定多种媒体类型。
比如:
- 文本文件
text/html, text/plain, text/css... - 图片文件
image/jpeg, image/gif, image/png.. - 视频文件
video/mpeg, video/quicktime... - 应用程序使用的二进制文件
application/octet-stream, application/zip...
给显示的媒体类型增加优先级,使用q=0.3来表示权重值,用分号分隔。权重值q的范围是0~1,不指定时,默认权重为q=1.0
Accept-Charset
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
告诉服务器用户支持的字符集及字符集的相对优先顺序
Accept-Encoding
Accept-Encoding:gzip,defate
Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。
Accept-Language
Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3
告知服务器客户端能够处理的自然语言集(指中文或英文)
Authorization
Authorization:Basic dwvub3N1bjpwXYZVBBB==
告知服务器用户代理的认证信息
其他首部字段
Expect,期望出现的某种特定行为
From,告诉服务器用户代理的用户的电子邮件地址
Host
虚拟主机运行在同一个IP上,因此使用首部字段Host加以区分
Host:www.hackr.jp
条件请求
- If-Match: 告知服务器匹配资源所用的实体标记(ETag)值
- If-Modified-Since: 如果在If-Modified-Since字段指定的日期时间之后,资源发生了更新,服务器会接受请求
- If-None-Match:和If-Match作用相反
-
If-Range:告知服务器若指定的If-Range字段值和请求资源的Etag值一致时,则作为范围请求处理,如下图
- If-Unmodified-Since
形如if-xxx这种样式的请求首部字段,都可称为条件请求。服务器收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。 -
Max-Forwards
指定最大转发请求次数,当服务器接收到Max-Forwards值为0的请求时,则不再进行转发,而是直接返回响应。
- Proxy-Authorization
接收到从代理服务器发来的认证质询时,客户端会发送包含首部字段Proxy-Authorization的请求,以告知服务器认证所需要的信息 - Referer
告知服务器请求的原始资源的URI - TE
TE:gzip,deflate;q=0.5
告知服务器客户端能处理响应的传输编码方式及相对优先级 - User-Agent
用于传达浏览器的种类
User-Agent:Mozilla/5.0
响应首部字段
1.Accept-Ranges
2.Age
3.ETag
4.Location 提供重定向的URI
5.Proxy-Authenticate
6.Retry-After
7.Server 告知客户端当前服务器上安装的HTTP服务器应用程序的信息
8.Vary
9.WWW-Authenticate 告知客户端适用于访问请求URI所指定资源的认证方案
实体首部字段
1.Allow 所有支持的HTTP方法
2.Content-Encoding 告知客户端,服务器对实体的主体部分选用的内容编码方式
3.Content-Language 告知客户端,实体主体使用的自然语言
4.Content-Length 表明实体主体部分的大小(单位是字节)
5.Conten-Location 表示报文主体返回资源对应的URI
6.Content-MD5 首部字段Content-MD5是一串由MD5算法生成的值,其目的在于检查报文主体在传输过程中是否保持完整,以及确认传输到达。
客户端会对接收的报文主体执行相同的MD5算法,然后与首部字段Content-MD5的字段值比较。
7.Content-Range:bytes 5001-10000/10000 告知客户端返回实体的哪个部分符合范围请求。
8.Content-Type: text/html; charset=UTF-8 实体主体对象媒体类型
9.Expires:Wed, 04jul 2012 08:26:05 GMT 资源失效日期
10.Last-Modified 资源最终修改的时间
HTTPS
-
HTTP的缺点
- 通信使用明文(不加密),内容可能会被窃听
- 不验证通信方的身份,可能遭遇伪装
- 无法证明报文的完整性,可能被篡改
HTTP + 加密 + 认证 + 完整性保护 = HTTPS
-
建立HTTPS通信的过程图
为什么不一直使用HTTPS
一个原因,是因为与纯文本通信相比,加密通信会消耗更多的CPU及内存资源。如果每次通信都加密,会消耗相当多的资源,平摊到一台计算机上时,能够处理的请求数量必定会随之减少。
因此,如果是非敏感信息则使用HTTP通信,只有在包含个人信息等敏感数据时,才利用HTTPS加密通信。
节约购买证书的开销
确认访问用户
1、HTTP 使用的认证方式
- BASIC 认证(基本认证)
- DIGEST认证(摘要认证)
- SSL客户端认证
- FormBase认证(基于表单认证)
2、BASIC认证
BASIC认证不够安全,不常用
3、DIGEST认证
质询响应方式是指,一开始一方会先发送认证要求给另一方,接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
4、SSL客户端认证
步骤1:接收到需要认证资源的请求,服务器会发送Certificate Request报文,要求客户端提供客户端证书。
步骤2:用户选择将发送的客户端证书后,客户端会把客户端证书信息以
5、基于表单认证
输入已事先登录的用户ID(通常是任意字符串或邮件地址)和密码等登录信息后,发送给web应用程序,基于认证结果来决定认证是否成功。
- 认证多半为基于表单认证
因为HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。另外,SSL客户端认证虽然具有高度的安全等级,但因为导入及维持费用等问题,还尚未普及。 - Session管理及Cookie应用
一般使用Cookie来管理Session(会话)
基于表单认证本身是通过服务器端的web应用,将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于HTTP是无状态协议,所以使用Cookie管理Session