图解HTTP-第3章-HTTP报文内的HTTP信息

HTTP报文

用于HTTP协议交互的信息被称为HTTP报文。HTTP报文本身是由多行(用CR+LF作换行符)数据构成的字符串文本。

HTTP报文的结构.png

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

请求报文(上)和响应报文(下)的结构.png

请求报文及响应报文的结构

请求报文的实例.png
响应报文的实例.png

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

编码提升传输速率

报文主体实体主体差异

  • 报文(message)
    是HTTP通信中的基本单位,由8位组字节流(octet sequence,其中octet为8个比特)组成,通过HTTP传输。
  • 实体(entity)
    作为请求或响应的有效载荷数据(补充项)被传输,其内容由实体首部和实体主体组成。
    HTTP报文的主体用于传输请求或响应的实体主体。
    通常,报文主体等于实体主体。只有当传输中进行编码操作时,实体主体的内容发生变化,才导致它和报文主体产生差异

压缩传输的内容编码

内容编码指明应用实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

内容编码.png

常用的内容编码有以下几种:

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

分割发送的分块传输编码

把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)。

分块传输编码.png

分块传输编码会将实体主体分成多个部分(块)。每一块都会用十六进制来标记块的大小,而实体主体的最后一块会使用“0(CR+LF)”来标记。

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

邮件能发送多份附件,因为采用MIME(Multipurpose Internet Mail Extensions,多用途因特网邮件扩展)机制。
相应地,HTTP协议中也采纳了多部分对象集合,发送的一份报文主体可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象如下:

  • multipart/form-data
    在Web表单文件上传时使用。
  • multipart/byteranges
    状态码206(Partial Content,部分内容)响应报文包含了多个范围的内容时使用。
multipat form-data.png
multipat byteranges.png

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

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

获取部分内容的范围请求

指定范围发送的请求叫做范围请求(Range Request)。

Range Reques.png

执行范围请求时,会用到首部字段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和完整的实体内容。

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

内容协商机制是指客户端和服务器端就响应的资源内容进行交涉,然后提供给客户端最为合适的资源。内容协商会以资源的语言,字符集,编码方式等作为判断的基准。

包含在请求报文中的某些首部字段就是判断的基准。

  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Content-Language

内容协商技术有3种类型

  • 服务器驱动协商(Server-driven Negotiation)
    以请求的首部字段为参考,在服务器端自动处理。但对用户来说,以浏览器发送的信息作为判定的依据,并不一定能筛选出最优内容。
  • 客户端驱动协商(Agent-driven Negotiation)
    用户从浏览器显示的可选列表种手动选择。可以利用JavaScript脚本在Web页面上自动进行上述选择。比如按OS的类型或浏览器类型,自动切换成PC版页面或手机版页面。
  • 透明协商(Transparent Negotiation)
    是服务器驱动和客户端驱动的结合体,是由服务器端和客户端各自进行内容协商的一种方法。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,736评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,167评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,442评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,902评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,302评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,573评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,847评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,562评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,260评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,531评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,021评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,367评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,016评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,068评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,827评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,610评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,514评论 2 269

推荐阅读更多精彩内容