1. HTTP报文结构
问:什么是HTTP报文?
答:使用HTTP协议进行交互的信息被称为HTTP报文
客户端发送的叫 请求报文(request);服务器发送的叫 响应报文(response)
问:HTTP报文长什么样?
答:HTTP报文其实就是多行字符串文本(由CR+LF作为换行符)
HTTP报文大致可以分为 报文首部 和 报文主体 两块,报文主体 非必要
报文首部
空行(CR+LF)
报文主体
问:请求报文与响应报文的首部结构一样吗?
答:你看:
请求报文首部:
请求行:GET /dir/index.html HTTP/1.1 (method + request-URI + HTTP version)
+首部字段:请求首部字段 + 通用首部字段 + 实体首部字段
+其他:HTTP RFC中未定义的首部(如Cookie等)
响应报文首部:
状态行:HTTP/1.1 200 OK (HTTP version + status code + reason-phrase)
+首部字段:响应首部字段 + 通用首部字段 + 实体首部字段
+其他:HTTP RFC中未定义的首部(如Cookie等)
2. HTTP内容编码
问:为什么需要编码啊?
答:HTTP是可以将数据原样传输的,但编码/压缩可以提升传输速率,这样能处理的请求不就更多了吗?但是,编码是需要计算机来完成的,因此会消耗更过的CPU资源。
问:那编码/压缩的是HTTP报文的那一部分呢?
答:编码的是实体主体部分(什么是实体主体部分?)
报文主体与实体主体的差异:
just as what I said above: HTTP报文 = 报文首部 + 报文主体
what is 实体? 实体作为请求/响应的有效载荷数据(Payload)被传输
实体 = 实体首部 + 实体主体
问:那什么是HTTP内容编码?
答:HTTP内容编码是HTTP协议中一种编码功能
它指明应用在实体主体上的编码格式,并保持实体信息的原样压缩
内容编码后的实体由客户端接受并负责解码
追问:那HTTP内容编码支持哪些编码格式啊?
追答:常用的内容编码有以下几种:
- gzip(GNU zip)
- compress(UNIX系统的标准压缩)
- deflate(zlib)
- identity(不进行编码)
3. 分块传输编码
问:为什么需要分块传输?
答:在HTTP通信过程中,请求的编码实体资源在未全部传输完成之前,浏览器无法显示请求页面
在传输大容量数据时,通过把数据分隔成多块,浏览器能够逐步显示页面
这种把实体主体分块的功能,就被称作:分块传输编码(Chunked Transfer Coding)
问:HTTP是怎样实现分块传输的呢?
答:分块传输编码会将实体主体分割成多个部分(块),每块都会使用十六进制来标记其大小
实体的最后一块会使用"0(CR+LF)"来标记
addon:HTTP/1.1中存在一种叫做传输编码(Transfer Coding)的机制,他可以在通信时按照某种编码方式传输,但只定义作用于分块传输编码中。
4. 多部分对象集合
发送的一份报文主体内可含有多类型实体,通常是在图片或者文本文件等上传时使用
多部分对象集合(Multipart)包含的对象如下:
mutipart/form-data:在web表单文件上传时使用
multipart/byteranges:响应报文(206部分内容)包含多个范围内容时使用
5. 范围请求
问:什么是范围请求?
答:指定请求数据范围的请求叫做范围请求
问:为什么需要范围请求?/范围请求的应用场景
答:断点续传 恢复下载
问:怎样做到范围请求?
答:你看
使用首部字段Range来指定资源的byte范围
请求5001-10000字节
Range: bytes=5001-10000
请求5001之后全部字节
Range: bytes=5001-
请求多重范围
Range: bytes=0-1000, 5000-8000
针对范围请求,服务器会返回状态码为206 Partial Content的响应报文
对于多重范围的范围请求,响应会在首部字段Content-Type字段标明multipart/byteranges
6. 内容协商
问:什么是内容协商?What is Content Negotiation?
答: 内容协商机制是指:客户端和服务端就响应的资源内容进行交涉,服务端提供给客户端最合适的资源
内容协商会以语言、字符集、编码方式等为基准判断响应的资源
举个栗子:服务器中同一个网页有多种语言版本,浏览器可以根据自己的默认语言与服务器协商返回对应网页版本
问:判断基准是首部的哪些字段呢?
答:Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language
问:内容协商有几种实现方式?
答:3种
- 服务器驱动协商(Server-driven Negotiation)
服务器以请求的首部字段为参考自动处理,取决于浏览器返送的信息,用户无操作权
- 客户端驱动协商(Client-driven Negotiation)
给用户提供可选列表,或者使用Javascritp脚本在页面自动选择
- 透明协商(Transparent Negotiation)
上述两者的结合体,是由服务器端和客户端各自进行内容协商的一种办法(我也没理解)