3、HTTP 报文内的 HTTP 信息
HTTP 通信过程包括从客户端发往服务器端的请求及从服务器端返回 客户端的响应。
3.1、HTTP报文
HTTP报文:用于 HTTP 协议交互的信息。
请求端(客户端)的 HTTP 报文叫做请求报文,响应端(服务器端)的叫做响应报文。 HTTP 报文本身是由多行(用 CR+LF 作换行符)数据构成的字符串文本。
其结构如图:
3.2、 请求报文及响应报文的结构
请求报文和响应报文的结构如图所示:
请求报文和响应报文实例如图所示:
请求报文和响应报文的首部内容由以下数据组成:
-
请求行:包含用于请求的方法,请求 URI 和 HTTP 版本。
-
状态行:包含表明响应结果的状态码,原因短语和 HTTP 版本。
-
首部字段:包含表示请求和响应的各种条件和属性的各类首部。一般有 4 种首部,分别是:通用首部、请求首部、响应首部和实体首 部。
-
其他:可能包含 HTTP 的 RFC 里未定义的首部(Cookie 等)。
3.3、编码提升传输速率
HTTP 在传输数据时可以按照数据原貌直接传输,但也可以在传输过 程中通过编码提升传输速率。通过编码的方式,能够有效的处理大量的访问请求。
3.3.1、 报文主体和实体主体的差异
-
报文(message):是HTTP通信中的基本单位,由把八位组字节流组成,通过HTTP通信传输。
-
实体(entity):作为请求或响应请求的有效载荷数据(补充项)被传输,内容由实体首部和实体主体组成。
HTTP 报文的主体用于传输请求或响应的实体主体。 通常,报文主体等于实体主体。只有当传输中进行编码操作时,实体主体的内容发生变化,才导致它和报文主体产生差异。
3.3.2、 压缩传输的内容编码
内容编码指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。如图所示:
常用的内容编码有以下几种。
-
gzip(GNU zip)
-
compress(UNIX 系统的标准压缩)
-
deflate(zlib)
-
identity(不进行编码)
3.3.3 分割发送的分块传输编码
分块传输编码(Chunked Transfer Coding):把实体主体分块的功能。如图所示:
分块传输编码会将实体主体分成多个部分(块)。每一块都会用十六进制来标记块的大小,而实体主体的最后一块会使用“0(CR+LF)”来标记。 使用分块传输编码的实体主体会由接收的客户端负责解码,恢复到编码前的实体主体。
3.4 发送多种数据的多部分对象集合
MIME(Multipurpose Internet Mail Extensions,多用途因特网邮 件扩展)机制:它允许邮件处理文本、图片、视频等多个不同类型的数据。
MIME 扩展中会使用一种称为多部分对象集合(Multipart)的方法,来容纳多份不同类型的数据。
多部分对象集合包含的对象如下:
-
multipart/form-data:在Web表单文件上传时使用。
-
multipart/byteranges:状态码206(Partial Content,部分内容)响应报文包含了多个范围的内容时使用。
3.5 获取部分内容的范围请求
范围请求(Range Request):指定范围发送的请求。
执行范围请求时,会用到首部字段 Range 来指定资源的 byte 范围。byte 范围的指定形式如下:
-
5001~10000 字节:Range: bytes=5001-10000
-
从 5001 字节之后全部的:Range: bytes=5001-
-
从一开始到 3000 字节和 5000~7000 字节的多重范围:Range: bytes=-3000, 5000-7000
针对范围请求,响应会返回状态码为 206 Partial Content 的响应报 文。另外,对于多重范围的范围请求,响应会在首部字段 Content-Type 标明 multipart/byteranges 后返回响应报文。如果服务器端无法响应范围请求,则会返回状态码 200 OK 和完整的 实体内容。
3.6、 内容协商返回最合适的内容
内容协商(Content Negotiation):当浏览器的默认语言为英语或中文,访问相同 URI 的 Web 页面时, 则会显示对应的英语版或中文版的 Web 页面的机制。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉,然 后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字 符集、编码方式等作为判断的基准。
内容协商技术:
-
服务器驱动协商(Server-driven Negotiation):由服务器端进行内容协商。以请求的首部字段为参考,在服务器端自 动处理。但对用户来说,以浏览器发送的信息作为判定的依据,并不 一定能筛选出最优内容。
-
客户端驱动协商(Agent-driven Negotiation):由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手 动选择。还可以利用 JavaScript 脚本在 Web 页面上自动进行上述选 择。比如按 OS 的类型或浏览器类型,自行切换成 PC 版页面或手机 版页面。
-
透明协商(Transparent Negotiation):是服务器驱动和客户端驱动的结合体,是由服务器端和客户端各自进 行内容协商的一种方法。
4、 返回结果的 HTTP 状态码
HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端 的处理是否正常、通知出现的错误等工作。
4.1 状态码告知从服务器端返回的请求结果
响应状态中的第一位指定了响应类别,后两位无分类。响应类别可
分为一下五种:
下面具体分析各类别常用状态码。
2XX 表示请求被正常处理了
-
200 OK:表示从客户端发来的请求在服务器端被正常处理了。在响应报文内,随状态码一起返回的信息会因方法的不同而发生改 变。比如,使用GET方法时,对应请求资源的实体会作为响应返回;而使用HEAD方法时,对应请求资源的实体首部不随报文主体作为响应返回(即在响应中只返回首部,不会返回实体的主体部分)。
-
204 No Content:该状态码代表服务器接收的请求已成功处理,但在返回的响应报文中 不含实体的主体部分。另外,也不允许返回任何实体的主体。一般用于只需要从客户端往服务器发送消息,而对客户端不需要发送新消息内容的情况下使用。
-
206 Partial Content:表示客户端进行了范围请求,而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。
3XX 重定向
3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请 求。
-
301 Moved Permanently:永久性重定向。表示请求的资源已被分配了新的 URI,以后 应使用资源现在所指的 URI。
-
302 Found:临时性重定向。表示请求的资源已被分配了新的 URI,希望 用户(本次)能使用新的 URI 访问。
-
303 See Other:表示由于请求对应的资源存在着另一个 URI,应使用 GET 方法定向获取请求的资源。
-
304 Not Modified:表示客户端发送附带条件的请求时,服务器端允许请求访问资源,但未满足条件的情况。304 状态码返回时,不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中,但是和重定向没有关系。
-
307 Temporary Redirect:临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET,但实际使用时大家并不遵守。 307 会遵照浏览器标准,不会从 POST 变成 GET。但是,对于处理响应时的行为,每种浏览器有可能出现不同的情况。
4XX 客户端错误
4XX 的响应结果表明客户端是发生错误的原因所在。
-
400 Bad Request:表示请求报文中存在语法错误。
-
401 Unauthorized:该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、 DIGEST 认证)的认证信息。另外若之前已进行过 1 次请求,则表示 用 户认证失败。
-
403 Forbidden:表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由,但如果想作说明的话,可以在实体的主体部分对原因进行描述,这样就能让用户看到了。
-
404 Not Found:表明服务器上无法找到请求的资源。除此之外,也可以在服 务器端拒绝请求且不想说明理由时使用。
5XX 服务器错误
5XX 的响应结果表明服务器本身发生错误。
-
500 Internal Server Error:表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。
-
503 Service Unavailable:表明服务器暂时处于超负载或正在进行停机维护,现在无法 处理请求。