3.HTTP报文内的HTTP信息

Http通信过程包括从客户端发往服务端的请求及从服务端返回客户端的响应.本章就来让我们了解一下请求和响应是怎么运作的.

一 .HTTP报文 :

1. 用于HTTP协议交互的信息被称为HTTP报文,请求端(客户端)的HTTP报文叫做请求报文,响应端(服务端)的叫做响应报文. HTTP报文本身是由多行(CR_LF)数据构成的字符串文本.HTTP报文大致可分为报文首部和报文主体.

二请求报文及相应报文结构

2. 请求报文和响应报文的首部内容由以下数据组成.
   1. 请求行 : 包含用于请求的方法,请求URI和HTTP版本.
   2. 状态行 : 包含表名响应结果的状态码,原因短语和HTTP版本.
   3. 首部字段 : 包含表示请求和响应的各种条件和属性的各类首部. 一般有四种首部,分别是:通用首部,请求首部,响应首部和实体首部.
   4. 其他 : 可能包含HTTP的RFC里未定义的首部(cookie等).

三.编码提升传输速率 :

1. HTTP在传输时可以按照原貌直接传输,但也可以在传输过程中通过编码提升传输速率.通过在传输时编码,能有效的处理大量的访问请求.但是,编码的操作需要计算机来完成,因此会消耗更多的CPU等资源.

2. 报文主体和实体主体的差异 :

   1. 报文(message) : 是HTTP通信中的基本单位,由8位组字节流(octet sequence , 其中octet为8个比特)组成,通过HTTP通信传输.
   2. 实体(entity) : 作为请求或响应的有效载荷数据(补充项)被传输 ,其内容由实体首部和实体主体组成.
   3. HTTP报文的主体用于传输请求或相应的实体主体 .通常,报文主体等于实体主体.只有当传输中进行编码操作时,实体主体的内容发生变化,才导致它和报文主体产生差异.报文和实体这两个术语在之后会经常出现,请事先理解两者的差别.

3. 压缩传输的内容编码 : 向待发送邮件内增加附件时,为了使邮件容量变小,我们会先用Zip压缩文件之后再添加附件发送.HTTP协议中有一种被称为内容编码的功能也能进行类似的操作.内容编码指明应用在实体内容上的编码格式,并保持实体信息鸳鸯压缩.内容编码后的实体由客户端接收并负责解码. 常用的内容编码有以下几种 :

   1. gzip (gnu zip)
   2. compress(unix系统的标准压缩)
   3. deflate(zlib)
   4. identity(不进行编码)

4. 分割发送的分块传输编码 : 在HTTP通信过程中,请求的编码实体资源尚未全部传输完成之前,浏览器无法显示请求页面. 在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面.这种把实体主体分块的功能称为分块传输编码(chunked transfer coding).

5. 分块传输编码会将实体主体分成多个部分(块).每一块都会用十六进制来标记块的大小,而实体的最后一块会使用"0(CR+LF)"来标记.使用分块传输编码的实体会由接收的客户端负责解码,回复到编码前的实体主体.HTTP1.1 中存在一种称为传输编码(transfer coding)的机制,它可以在通信时按某种编码方式传输,但只定义作用域分块传输编码中.

四. 发送多种数据的多部分对象集合

1 : 发送邮件时,我们可以在邮件里写入文字并添加多份附件.这里是因为采用了MIME(Multipurpose Internet Mail Extensions ,多用途因特网邮件扩展) 机制,它允许邮件处理文本,图片,视频等多个不同类型的数据. 相应的,HTTP协议中也采纳了多部分对象集合,发送的一份报文主体内可含有多类型实体.通常是在图片或文本等上传时使用. 多部分对象集合包含的对象如下 :

1. multipart / fORM-data : 在WEB表单文件上传时使用.
2. multipart / byte ranges : 状态码206(partial content , 部分内容) 响应报文包含了多个范围的内容时使用.
3. 在HTTP报文中使用多部分对象集合时,需要在首部字段里加上content-type .

2.使用boundary字符串来划分多部分对象集合指明的各类实体. 在boundary 字符串指定的各个实体的起始行之前植入"--" 标记(例如 : --AaB03X , --THIS_STRING_SEPARATES) ,而在多部分对象集合对应的字符串的最后插入"标记"(例如: --AaB03X , --THIS_STRING_SEPARATES) 作为结束.多部分对象集合的每个部分类型中,都可以含有首部字段.另外,可以在某个部分中嵌套使用多部分对象集合. 有关多部分对象更详细的解释,请参考RFC2046.

五.获取部分内容的范围请求

1. 以前,用户不能使用现在这种高速的带宽访问互联网,当时,下载一个尺寸稍大的图片或文件就已经很吃力了. 如果下载过程中遇到网络中断的情况,那就必须重头开始.为了解决上述问题,需要一种可恢复的机制.所谓恢复是指能从之前下载中断处恢复下载.要实现该功能需要指定下载的实体范围.像这样,指定范围发送的请求叫做范围请求(range request) . 对一份10000字节带下的资源,如果使用范围请求,可以只请求5001 -- 10000字节内的资源.

2. 执行范围请求时,会用到首部字段range来制定资源的byte范围 .
   1. 5001 -10000字节 : Range :bytes= 5001 -10000
   2. 从5001字节之后全部的 : Rnage : bytes=5001-
   3. 从一开始到3000字节和5000-7000字节的多重范围 : Range:bytes=-3000,5000-700
   4. 针对范围请求,响应会范围状态码为206 Partial content 的响应报文.另外,对于多重范围的范围请求,响应会在首部字段content-type标明multipart/byteranges后返回响应报文.如果服务端无法响应范围请求,则会返回状态码200 OK和完整的实体内容.

六 . 内容协商返回最合适的内容

1. 同一个web网站有可能存在着多份相同的内容页面.比如英语班和中文版的web页面,它们内容上虽相同,但是用的语言却不同.当浏览器的默认语言为英语或中文,访问相同的URI的web页面时,则会显示对应的英语版或中文版的web页面,这样的机制称为内容协商(content neGotiation)

2. 内容协商机制是指客户端和服务端就响应的资源内容进行交涉,然后提供给客户端最为合适的资源.内容协商会以响应资源的语言,字符集,编码方式等作为判断的基准.包含在请求报文中的某些首部字段如下,就是判断的基准,这些首部字段的详细说明请参考下一章.

   1. accept
   2. accept-charset
   3. accept-encoding
   4. accept-language
   5. content-language

3. 服务器驱动协商(server-driven negotiation) : 由服务器端进行内容协商 . 以请求的首部字段为参考.在服务端自动处理.但对用户来说,以浏览器发送的信息作为判定的依据,并不一定能筛选出最优内容.

4. 客户端驱动协商(agent-driven negotiation) : 由客户端进行内容协商的方式.用户从浏览器显示的可选项列表中手动选择.还可以利用javascript脚本在web页面上自动进行上述选择.如果按OS的类型或浏览器类型,自行切换成PC版页面或手机版页面

5. 透明协商(transparent negotiation) : 是服务器驱动和客户端驱动的结合体,是由服务器端和客户端各自进行协商的一种方法 .