Http发展历史

1、背景

如今我们享受着丰富的互联网,网购、点外卖、叫网约车方便了我们的生活,看短视频、看电子书更扩宽了我们的视野。关于互联网,最初的设想来源于CERN(欧洲核子研究组织)的Tim BernersLee博士,
他提出了一种能让相隔甚远的研究者们共享知识的设想。他认为借助多文档之间相互关联形成的超文本 (HyperText),可以连成可相互参阅的 WWW(World Wide Web,万维网)。 WWW 构建技术主要包括:

  1. HTML(HyperText Markup Language,超文本标记语言);
  2. HTTP 协议 ;
  3. URL(UniformResource Locator,统一资源定位符)。

HTML让我们看到丰富的网页,包含文字,图片,视频等等,而URL指明了文档所在地址,告诉客户端资源在哪个位置,而http是应用层的协议,提供一种发布和接收HTML页面的方法。


2、简单介绍http协议

  • HTTP 协议用于客户端和服务器端之间的通信

通过请求报文和响应报文的交换达成通信

  • HTTP是不保存状态的协议

使用 HTTP 协议,每当客户端有新的请求发送时,服务器端就会有对应的新响应产生。协议本身并不保留或缓存之前一切的请求或响应报文的信息。这种设计模式是为了更快地处理大量请求和响应,确保协议的可伸缩性。

  • 状态保存必要性的事例

假设不记录已登录的状态,那么每次跳转新页面都需要再次登录。这对用户来说,无疑是一种不友好的体验。

  • cookie 技术的引入

Cookie 技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。首先,Cookie会根据响应报文内的Set-Cookie 首部字段信息,通知客户端保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。

  • HTTP 协议使用 URI 定位互联网上的资源

正是因为 URI 的特定功能,在互联网上任意位置的资源都能被访问到。


3、http协议版本介绍

http协议的主要版本如下,其中,SPDY 协议由谷歌自行研发,主要解决 HTTP/1.1 效率不高的问题。这个协议在Chrome浏览器上证明可行以后,被当作 HTTP/2 的基础,主要特性都在 HTTP/2 之中得到继承。

Http发展历史

3.1 HTTP/0.9

3.1.1 一个实例

最早版本是1991年发布的0.9版本,下面展示了请求和响应报文的格式:

  GET /index.html
  <html>
    <body>Hello World</body>
  </html>

3.1.2 说明

该版本极其简单,仅支持GET命令。该命令表示,当TCP连接建立后,客户端向服务器请求网页 index.html。0.9版本协议规定,服务器只能回应 HTML 格式的字符串,不能回应别的格式。且服务器发送完成后,就会关闭 TCP 连接。

3.2 HTTP/1.0

3.2.1 一个实例

1996年5月,HTTP/1.0 版本发布,内容大大增加。下面展示了请求和响应报文的格式:

  GET / HTTP/1.0
  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
  Accept: */*
  HTTP/1.0 200 OK 
  Content-Type: text/plain
  Content-Length: 137582
  Expires: Thu, 05 Dec 1997 16:00:00 GMT
  Last-Modified: Wed, 5 August 1996 15:55:28 GMT
  Server: Apache 0.84

  <html>
    <body>Hello World</body>
  </html>

3.2.2 说明

对于请求方式,在GET命令的基础上,还引入了POST命令和HEAD命令,这丰富了浏览器与服务器的互动手段。而服务器响应的内容也得到了扩展,任何格式的内容都可以被发送。这使得互联网不仅可以传输文字,还能传输图像、视频、二进制文件。另外观察请求和响应报文,除了数据部分,每次通信都包括头信息(HTTP header),用来描述一些元数据。

其他的新增功能还包括状态码、多字符集支持、多部分发送、权限、缓存、内容编码等。

3.2.3 关于Content-Type字段

Content-Type是响应报文中的常用字段,通过该字段,可以告诉客户端数据的格式。下面是常见的Content-Type字段的值:

  • text/plain
  • text/html
  • text/css
  • image/jpeg
  • image/png
  • image/svg+xml
  • audio/mp4
  • video/mp4
  • application/javascript
  • application/pdf
  • application/zip
  • application/atom+xml

除了以上常见的内容类型,在实际的工程中,我们经常有上传文件,上传图片等行为。此地,就用到了多部分对象集合(Multipart)。即:

  • Content-Type: multipart/form-data;

HTTP 协议中使用了多部分对象集合,发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。

3.2.4 关于Content-Encoding字段

HTTP/1.0增加了内容编码的功能,内容编码指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

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

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

在响应报文中,Content-Encoding字段说明数据的压缩方法。

  Content-Encoding: gzip
  Content-Encoding: compress
  Content-Encoding: deflate

在请求报文中,用Accept-Encoding字段说明客户端可以接受哪些压缩方法。

  Accept-Encoding: gzip, deflate

3.3 HTTP/1.1

3.3.1 新增方法

新增了许多请求方法:PUT、PATCH、HEAD、 OPTIONS、DELETE。

3.3.2 关于持久连接

  • 持久连接

TCP连接默认不关闭,可以被多个请求复用。

  • 非持久连接

HTTP 协议的初始版本中,每进行一次 HTTP 通信就要断开一次 TCP 连接。每次的请求都会造成无谓的 TCP 连接建立和断开,增加通信量的开销。

  • 持久连接的优势

建立 1 次 TCP 连接后进行多次请求和响应的交互,减少 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。在 HTTP/1.1 中,所有的连接默认都是持久连接持久连接使得多数请求以管道机制(pipelining)发送成为可能。

3.3.3 关于管道机制

持久连接使得多数请求以管线化(pipelining)方式发送成为可能。从前发送请求后需等待并收到响应,才能发送下一个请求。管线化技术 出现后,不用等待响应亦可直接发送下一个请求。
比如,当请求一个包含 1多张图片的Web页面,与挨个连接相比,用持久连接可以让请求更快结束。而管线化技术则比持久连接还要快。请求数越多,时间差就越明显。

3.3.4 分块传输编码

  • 分块传输编码出现的背景

在 HTTP 通信过程中,请求的编码实体资源尚未全部传输完成之前,浏览器无法显示请求页面。于是,HTTP/1.1在HTTP/1.0内容编码的基础上,提出了分块传输编码。这样在传输大容量数据时,通过便可以把数据分割成多块,让浏览器逐步显示页面。

  • 如何使用分块传输编码
  Transfer-Encoding: chunked
  • 如何确定传输已结束

分块传输编码会将实体主体分成多个部分(块)。每一块都会用十六进制来标记块的大小,而实体主体的最后一块会使用“0(CR+LF)”来标记。最后是一个大小为0的块,就表示本次回应的数据发送完了。

  HTTP/1.1 200 OK
  Content-Type: text/plain
  Transfer-Encoding: chunked

  25
  This is the data in the first chunk

  1C
  and this is the second one

  3
  con

  8
  sequence

  0

3.4 HTTP/2

2015年,HTTP/2 发布。

3.4.1 HTTP/2新特性-多路复用

  • 多路复用可以解决什么问题?

做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。

3.4.2 HTTP/2新特性-头信息压缩

  • HTTP1.1的处理方式

在HTTP1.1中,HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言,消息主体都会经过gzip压缩,或者本身传输的就是压缩过后的二进制文件,但状态行和头部却没有经过任何压缩,直接以纯文本传输。

  • 缺点

随着Web功能越来越复杂,每个页面产生的请求数也越来越多,导致消耗在头部的流量越来越多,尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容,完全是一种浪费。

  • HTTP2的处理方式
  1. 头信息使用gzip或compress压缩后再发送;
  2. 客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。

3.4.3 HTTP/2新特性-服务器推送

  • HTTP1.1的处理方式

当一个html文件使用了许多资源:样式表、脚本、图片,视频等等。在HTTP1.1中这些资源每一个都必须明确地请求。

  • 缺点

浏览器解析html文件的时候增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求,网络经常是空闲的和未充分使用的。

  • HTTP2的处理方式

服务器可以预期到客户端请求网页后,很可能会再请求静态资源,所以就主动把这些静态资源随着网页一起发给客户端了。


Reference

[1]: 上野宣, 于均良。图解HTTP:HTTP[J]. 人民邮电出版社, 2014
[2]: HTTP 协议入门
[3]: Http系列(-) Http发展历史
[4]: HTTP百度百科

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 193,812评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,626评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,144评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,052评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,925评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,035评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,461评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,150评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,413评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,501评论 2 307
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,277评论 1 325
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,159评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,528评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,868评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,143评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,407评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,615评论 2 335

推荐阅读更多精彩内容