HTTP | HTTP报文内的HTTP信息

最新推荐文章于 2023-01-31 10:19:40 发布

烫青菜

最新推荐文章于 2023-01-31 10:19:40 发布

阅读量1.7k

点赞数

分类专栏：网络通信文章标签： http

本文链接：https://blog.csdn.net/weixin_39766005/article/details/120919979

版权

网络通信专栏收录该内容

9 篇文章 2 订阅

订阅专栏

1.通用首部字段 ( General Header Fields )

a. Cache-Control指令

b.Connection字段

c.Pragma字段

d. max-age与s-maxage指令

2.请求首部字段 ( Request Header Fields )

a.Accept字段

b.Host字段

3.响应首部字段( Response Header Fields )

a.ETag字段

4.实体首部字段（ Entity Header Fields )

一、HTTP报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端(服务器端）的叫做响应报文。 HTTP 报文本身是由多行（用 CR + LF 作换行符，windows端即\r\n）数据构成的字符串文本。

HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（ CR + LF ）来划分。通常，并不一定要有报文主体。

1.请求报文

请求报文的报文首部由请求行、首部字段及其他组成。

请求行：包含请求方法、请求URI、HTTP版本。
首部字段：包含请求首部字段、通用首部字段、实体首部字段三部分。
其他：可能包含HTTP的RFC里未定义的首部（如Cookie等）。

eg：请求报文的报文首部信息如下：

    GET / HTTP/1.1
    Host: hackr.jp
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/=>20100101 Firefox/13.0
    Accept: text/html, application/xhtml+xml, application/xml; q=0.9, =>*/*; q=0.8
    Accept-Language: ja,en-us;q=0.7,en;q=0.3
    Accept-Encoding: gzip, deflate
    DNT: 1
    Connection: keep-alive
    If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT
    If-None-Match: "45bae1-16a-46d776ac"
    Cache-Control: max-age=0

2.响应报文

响应报文的报文首部由状态行、首部字段及其他组成。

状态行：包含表明响应结果的状态码、原因短语、HTTP版本。
首部字段：包含响应首部字段、通用首部字段、实体首部字段三部分。
其他：可能包含HTTP的RFC里未定义的首部（如Cookie等）。

eg：响应报文的报文首部信息如下：

    HTTP/1.1304 Not Modified
    Date: Thu, 07 Jun 2012 07:21:36 GMT
    Server: Apache
    Connection: close
    Etag: "45bae1-16a-46d776ac"

二、4种HTTP首部字段类型

HTTP首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。HTTP首部字段是由首部字段名和字段值构成的，中间用冒号":"分隔。HTTP首部字段根据实际用途被分为以下 4 种类型：

1.通用首部字段 ( General Header Fields )

请求报文和响应报文两方都会使用的首部。

a. Cache-Control指令

Cache-Control指令可用于请求和响应时，按请求和响应分类如下：

很容易把 no- cache 误解成为不缓存 , 但事实上 no- cache 代表不缓存过期的资源 , 缓存会向源服务器进行有效期确认后处理资源 , 也许称为 do-not-serve-from-cache-without-revalidation 更合适。no-store才是真正地不进行缓存 , 请读者注意区别理解。

b.Connection字段

Connection首部字段具备如下两个作用：1.控制不再转发给代理的首部字段；2.管理持久连接。

在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不再转发给代理的首部字段（即 Hop-by-hop Header 逐跳首部）。

扩展：

        HTTP首部字段将定义成缓存代理和非缓存代理的行为 , 分成 2 种类型：

1.端到端首部 ( End - to - end Header )

        分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。

2.逐跳首部 ( Hop - by - hop Header )

        分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。HTTP /1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段。

        HTTP /1.1中，除Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization 、Trailer、TE、Transfer - Encoding、Upgrade 这 8 个首部字段之外，其他所有字段都属于端到端首部。

HTTP /1.1 版本的默认连接都是持久连接。为此 , 客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时 , 则指定 Connection 首部字段的值为 Close：Connection:Close

HTTP /1.1 之前的 HTTP 版本的默认连接都是非持久连接。如果想在旧版本的 HTTP 协议上维持持续连接 , 则需要指定 Connection 首部字段的值为Keep-Alive：Connection:Keep-Alive

c.Pragma字段

Pragma是 HTTP /1.1 之前版本的历史遗留字段，仅作为与 HTTP /1.0 的向后兼容而定义。规范定义的形式唯一：Pragma:no-cache

该首部字段属于通用首部字段 , 但只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。

所有的中间服务器如果都能以 HTTP /1.1 为基准 , 那直接采用Cache-Control:no-cache 指定缓存的处理方式是最为理想的。但要整体掌握全部中间服务器使用的 HTTP 协议版本却是不现实的。因此 , 发送的请求会同时含有下面两个首部字段：

Cache-Control:no-cache
Pragma:no-cache

d. max-age与s-maxage指令

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。另外，当指定max-age 值为 0，那么缓存服务器通常需要将请求转发给源服务器。当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而 max-age数值代表资源保存为缓存的最长时间。

s-maxage 指令的功能和 max-age 指令的相同，它们的不同点是 s-maxage 指令只适用于供多位用户使用的公共缓存服务器性。也就是说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。

当使用 s-maxage 指令后，则直接忽略对Expires实体首部字段及 max-age 指令的处理。

2.请求首部字段 ( Request Header Fields )

从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

a.Accept字段

Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype 这种形式，一次指定多种媒体类型。

常见媒体类型
文本文件	text/html、text/plain、text/css application/json、application/xml
图片文件	image/gif、image/png...
视频文件	video/mpeg、video/quicktime...
应用程序使用的二进制文件	application/octet-stream、application/zip...

若想要给显示的媒体类型增加优先级，则使用 q = 来额外表示权重值，用分号 ( ; ) 进行分隔。权重值 q 的范围是 0 ～ 1 ( 可精确到小数点后 3 位 )，默认为1且1为最大值。当服务器提供多种内容时 , 将会首先返回权重值最高的媒体类型。

Accept:text/plain;q=0.3,text/html 相当于Accept:text/plain;q=0.3,text/html;q=1，即text/html的权重大，当服务器端存在text/plain、text/html类型的文本文件时，会优先返回html的。

b.Host字段

首部字段 Host 会告知服务器 , 请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP /1.1 规范内是唯——个必须被包含在请求内的首部字段。若服务器未设定主机名，直接发送一个空值即可，即Host:

首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联 , 这是首部字段Host必须存在的意义。

3.响应首部字段( Response Header Fields )

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

a.ETag字段

首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag 值。资源被缓存时，就会被分配唯一性标识。另外，当资源更新时， ETag 值也需要更新。生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配。

ETag中有强 ETag 值和弱 ETag 值之分：

强 ETag 值：不论实体发生多么细微的变化都会改变其值。ETag:"******"
弱 ETag 值：只用于提示资源是否相同。只有资源发生了根本改变 , 产生差异时才会改变 ETag值。这时 , 会在字段值最开始处附加 W/。ETag:W/"******"

请求首部字段 If-Match就需要用到ETag，它会告知服务器匹配资源所用的实体标记 ( ETag ) 值。这时的服务器无法使用弱 ETag 值，服务器会比对 If - Match 的字段值和资源的 ETag 值，仅当两者一致时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。

4.实体首部字段（ Entity Header Fields )

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的
信息。

5.非HTTP/1.1首部字段

Cookie:Status=enable

Cookie字段会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。

三、报文主体和实体主体

1.报文 ( message )

报文是 HTTP 通信中的基本单位 , 由 8 位组字节流 ( Octet sequence , 其中 octet 为 8 个比特 ) 组成 , 通过 HTTP 通信传输。

2.实体 ( entity )

实体作为请求或响应的有效载荷数据 ( 补充项 ) 被传输 , 其内容由实体首部和实体主体组成。

HTTP报文的主体用于传输请求或响应的实体主体。通常，报文主体等于实体主体。只有当传输中进行编码操作（为了提升传输速率）时，实体主体的内容发生变化，才导致它和报文主体产生差异。

四、内容编码（压缩）

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。常用的内容编码有以下几种：

gzip （ GNU zip )
compress ( UNIX 系统的标准压缩 )
deflate ( zlib )
identity ( 不进行编码）

五、分块传输编码（分割发送）

把实体主体分块的功能称为分块传输编码（Chuncked Transfer Coding）。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。

分块传输编码会将实体主体分成多个部分 ( 块 )。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用 " 0 ( CR + LF ) " 来标记。使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

HTTP /1.1中存在一种称为传输编码 ( TransferCoding ) 的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。

六、多部分对象集合（含有多类型实体）

多部分对象集合指发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。多部分对象集合包含的对象如下：

1.multipart/form-data：在web表单文件上传时使用。

2.multipart/byteranges：在状态码206（范围请求）响应报文包含了多个范围的内容时使用。

Content-type：在 HTTP 报文中使用多部分对象集合时，需要在首部字段里加上 Content-type。

Content-Type：multipart/form-data;boundary=WebKitFormBoundary7MA4YWxkTrZu0gW

Content-Type：multipart/byteranges;boundary=WebKitFormBoundary7MA4YWxkTrZu0gW

boundary ：使用 boundary 字符串来划分多部分对象集合指明的各类实体。在 boundary 字符串指定的各个实体的起始行之前插入 " -- " 标记, 而在多部分对象集合对应的字符串的最后插入 " -- " 标记作为结束。

七、范围请求（中断后继续下载）

指定范围发送的请求叫做范围请求（ Range Request ) 。范围请求可以实现在下载中断处恢复下载。

执行范围请求时，会用到首部字段 Range来指定资源的 byte 范围。byte 范围的指定形式如下：

5001 ~ 10000 字节：Range : bytes = 5001-10000

从 5001 字节之后全部的字节：Range : bytes = 5001-

从一开始到 3000 字节和 5000 ～ 7000 字节的多重范围：Range : bytes = -3000,5000-7000

针对范围请求，响应会返回状态码为 206 PartialContent的响应报文。对于多重范围的范围请求，响应会在首部字段 Content - Type 标明multipart / byteranges 后返回响应报文。如果服务器端无法响应范围请求，则会返回状态码200 OK 和完整的实体内容。

八、内容协商

当浏览器的默认语言为英语或中文，访问相同 URI的 Web 页面时，则会显示对应的英语版或中文版的Web页面。这样的机制称为内容协商（ Content Negotiation ) 。

内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。包含在请求报文中的某些首部字段（Accept、Accept - Charset、Accept - Encoding、Accept - Language、Content - Language）就是判断的基准。

内容协商技术有以下 3 种类型：

服务器驱动协商 ( Server-driven Negotiation )：由服务器端进行内容协商 . 以请求的首部字段为参考 , 在服务器端自动处理 . 但对用户来说 , 以浏览器发送的信息作为判定的依据 , 并不一定能筛选出最优内容 .
客户端驱动协商 ( Agent-driven Negotiation )：由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用JavaScript脚本在 Web 页面上自动进行上述选择。比如按 OS 的类型或浏览器类型，自行切换成 PC 版页面或手机版页面。
透明协商（Transparent Negotiation )：是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。

——《图解HTTP》笔记

烫青菜

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
打赏
0
评论
HTTP | HTTP报文内的HTTP信息

目录一、HTTP报文1.请求报文2.响应报文二、报文主体和实体主体三、内容编码（压缩）四、分块传输编码（分割发送）五、多部分对象集合（含有多类型实体）六、范围请求（中断后继续下载）七、内容协商一、HTTP报文用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端(服务器端）的叫做响应报文。 HTTP 报文本身是由多行（用 CR + LF 作换行符，windows端即\r\n）数据构成的字符串文本...
复制链接

扫一扫