HTTP 协议入门

参考文献:javascript

http://www.cnblogs.com/ranyonsue/p/5984001.htmlcss

 

HTTP协议详解

 http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.htmlhtml

HTTP协议详解(真的很经典)

http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.htmljava

HTTP 协议是互联网的基础协议,也是网页开发的必备知识,最新版本 HTTP/2 更是让它成为技术热点。git

本文介绍 HTTP 协议的历史演变和设计思路。github

1、HTTP/0.9

HTTP 是基于 TCP/IP 协议的应用层协议。它不涉及数据包(packet)传输,主要规定了客户端和服务器之间的通讯格式,默认使用80端口。浏览器

最先版本是1991年发布的0.9版。该版本极其简单,只有一个命令GET缓存

GET /index.html

上面命令表示,TCP 链接(connection)创建后,客户端向服务器请求(request)网页index.html服务器

协议规定,服务器只能回应HTML格式的字符串,不能回应别的格式。app

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

服务器发送完毕,就关闭TCP链接。

2、HTTP/1.0

2.1 简介

1996年5月,HTTP/1.0 版本发布,内容大大增长。

首先,任何格式的内容均可以发送。这使得互联网不只能够传输文字,还能传输图像、视频、二进制文件。这为互联网的大发展奠基了基础。

其次,除了GET命令,还引入了POST命令和HEAD命令,丰富了浏览器与服务器的互动手段。

再次,HTTP请求和回应的格式也变了。除了数据部分,每次通讯都必须包括头信息(HTTP header),用来描述一些元数据。

其余的新增功能还包括状态码(status code)、多字符集支持、多部分发送(multi-part type)、权限(authorization)、缓存(cache)、内容编码(content encoding)等。

2.2 请求格式

下面是一个1.0版的HTTP请求的例子。

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

能够看到,这个格式与0.9版有很大变化。

第一行是请求命令,必须在尾部添加协议版本(HTTP/1.0)。后面就是多行头信息,描述客户端的状况。

2.3 回应格式

服务器的回应以下。

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>

回应的格式是"头信息 + 一个空行(\r\n) + 数据"。其中,第一行是"协议版本 + 状态码(status code) + 状态描述"。

2.4 Content-Type 字段

关于字符的编码,1.0版规定,头信息必须是 ASCII 码,后面的数据能够是任何格式。所以,服务器回应的时候,必须告诉客户端,数据是什么格式,这就是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

这些数据类型总称为MIME type,每一个值包括一级类型和二级类型,之间用斜杠分隔。

除了预约义的类型,厂商也能够自定义类型。

application/vnd.debian.binary-package

上面的类型代表,发送的是Debian系统的二进制数据包。

MIME type还能够在尾部使用分号,添加参数。

Content-Type: text/html; charset=utf-8

上面的类型代表,发送的是网页,并且编码是UTF-8。

客户端请求的时候,可使用Accept字段声明本身能够接受哪些数据格式。

Accept: */*

上面代码中,客户端声明本身能够接受任何格式的数据。

MIME type不只用在HTTP协议,还能够用在其余地方,好比HTML网页。

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- 等同于 -->
<meta charset="utf-8" />

2.5 Content-Encoding 字段

因为发送的数据能够是任何格式,所以能够把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。

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

客户端在请求时,用Accept-Encoding字段说明本身能够接受哪些压缩方法。

Accept-Encoding: gzip, deflate

2.6 缺点

HTTP/1.0 版的主要缺点是,每一个TCP链接只能发送一个请求。发送数据完毕,链接就关闭,若是还要请求其余资源,就必须再新建一个链接。

TCP链接的新建成本很高,由于须要客户端和服务器三次握手,而且开始时发送速率较慢(slow start)。因此,HTTP 1.0版本的性能比较差。随着网页加载的外部资源愈来愈多,这个问题就愈发突出了。

为了解决这个问题,有些浏览器在请求时,用了一个非标准的Connection字段。

Connection: keep-alive

这个字段要求服务器不要关闭TCP链接,以便其余请求复用。服务器一样回应这个字段。

Connection: keep-alive

一个能够复用的TCP链接就创建了,直到客户端或服务器主动关闭链接。可是,这不是标准字段,不一样实现的行为可能不一致,所以不是根本的解决办法。

3、HTTP/1.1

1997年1月,HTTP/1.1 版本发布,只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议,一直用到了20年后的今天,直到如今仍是最流行的版本。

3.1 持久链接

1.1 版的最大变化,就是引入了持久链接(persistent connection),即TCP链接默认不关闭,能够被多个请求复用,不用声明Connection: keep-alive

客户端和服务器发现对方一段时间没有活动,就能够主动关闭链接。不过,规范的作法是,客户端在最后一个请求时,发送Connection: close,明确要求服务器关闭TCP链接。

Connection: close

目前,对于同一个域名,大多数浏览器容许同时创建6个持久链接。

3.2 管道机制

1.1 版还引入了管道机制(pipelining),即在同一个TCP链接里面,客户端能够同时发送多个请求。这样就进一步改进了HTTP协议的效率。

举例来讲,客户端须要请求两个资源。之前的作法是,在同一个TCP链接里面,先发送A请求,而后等待服务器作出回应,收到后再发出B请求。管道机制则是容许浏览器同时发出A请求和B请求,可是服务器仍是按照顺序,先回应A请求,完成后再回应B请求。

3.3 Content-Length 字段

一个TCP链接如今能够传送多个回应,势必就要有一种机制,区分数据包是属于哪个回应的。这就是Content-length字段的做用,声明本次回应的数据长度。

Content-Length: 3495

上面代码告诉浏览器,本次回应的长度是3495个字节,后面的字节就属于下一个回应了。

在1.0版中,Content-Length字段不是必需的,由于浏览器发现服务器关闭了TCP链接,就代表收到的数据包已经全了。

3.4 分块传输编码

使用Content-Length字段的前提条件是,服务器发送回应以前,必须知道回应的数据长度。

对于一些很耗时的动态操做来讲,这意味着,服务器要等到全部操做完成,才能发送数据,显然这样的效率不高。更好的处理方法是,产生一块数据,就发送一块,采用"流模式"(stream)取代"缓存模式"(buffer)。

所以,1.1版规定能够不使用Content-Length字段,而使用"分块传输编码"(chunked transfer encoding)。只要请求或回应的头信息有Transfer-Encoding字段,就代表回应将由数量未定的数据块组成。

Transfer-Encoding: chunked

每一个非空的数据块以前,会有一个16进制的数值,表示这个块的长度。最后是一个大小为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.5 其余功能

1.1版还新增了许多动词方法:PUTPATCHHEADOPTIONSDELETE

另外,客户端请求的头信息新增了Host字段,用来指定服务器的域名。

Host: www.example.com

有了Host字段,就能够将请求发往同一台服务器上的不一样网站,为虚拟主机的兴起打下了基础。

3.6 缺点

虽然1.1版容许复用TCP链接,可是同一个TCP链接里面,全部的数据通讯是按次序进行的。服务器只有处理完一个回应,才会进行下一个回应。要是前面的回应特别慢,后面就会有许多请求排队等着。这称为"队头堵塞"(Head-of-line blocking)。

为了不这个问题,只有两种方法:一是减小请求数,二是同时多开持久链接。这致使了不少的网页优化技巧,好比合并脚本和样式表、将图片嵌入CSS代码、域名分片(domain sharding)等等。若是HTTP协议设计得更好一些,这些额外的工做是能够避免的。

4、SPDY 协议

2009年,谷歌公开了自行研发的 SPDY 协议,主要解决 HTTP/1.1 效率不高的问题。

这个协议在Chrome浏览器上证实可行之后,就被看成 HTTP/2 的基础,主要特性都在 HTTP/2 之中获得继承。

5、HTTP/2

2015年,HTTP/2 发布。它不叫 HTTP/2.0,是由于标准委员会不打算再发布子版本了,下一个新版本将是 HTTP/3。

5.1 二进制协议

HTTP/1.1 版的头信息确定是文本(ASCII编码),数据体能够是文本,也能够是二进制。HTTP/2 则是一个完全的二进制协议,头信息和数据体都是二进制,而且统称为"帧"(frame):头信息帧和数据帧。

二进制协议的一个好处是,能够定义额外的帧。HTTP/2 定义了近十种帧,为未来的高级应用打好了基础。若是使用文本实现这种功能,解析数据将会变得很是麻烦,二进制解析则方便得多。

5.2 多工

HTTP/2 复用TCP链接,在一个链接里,客户端和浏览器均可以同时发送多个请求或回应,并且不用按照顺序一一对应,这样就避免了"队头堵塞"。

举例来讲,在一个TCP链接里面,服务器同时收到了A请求和B请求,因而先回应A请求,结果发现处理过程很是耗时,因而就发送A请求已经处理好的部分, 接着回应B请求,完成后,再发送A请求剩下的部分。

这样双向的、实时的通讯,就叫作多工(Multiplexing)。

5.3 数据流

由于 HTTP/2 的数据包是不按顺序发送的,同一个链接里面连续的数据包,可能属于不一样的回应。所以,必需要对数据包作标记,指出它属于哪一个回应。

HTTP/2 将每一个请求或回应的全部数据包,称为一个数据流(stream)。每一个数据流都有一个独一无二的编号。数据包发送的时候,都必须标记数据流ID,用来区分它属于哪一个数据流。另外还规定,客户端发出的数据流,ID一概为奇数,服务器发出的,ID为偶数。

数据流发送到一半的时候,客户端和服务器均可以发送信号(RST_STREAM帧),取消这个数据流。1.1版取消数据流的惟一方法,就是关闭TCP链接。这就是说,HTTP/2 能够取消某一次请求,同时保证TCP链接还打开着,能够被其余请求使用。

客户端还能够指定数据流的优先级。优先级越高,服务器就会越早回应。

5.4 头信息压缩

HTTP 协议不带有状态,每次请求都必须附上全部信息。因此,请求的不少字段都是重复的,好比CookieUser Agent,如出一辙的内容,每次请求都必须附带,这会浪费不少带宽,也影响速度。

HTTP/2 对这一点作了优化,引入了头信息压缩机制(header compression)。一方面,头信息使用gzipcompress压缩后再发送;另外一方面,客户端和服务器同时维护一张头信息表,全部字段都会存入这个表,生成一个索引号,之后就不发送一样字段了,只发送索引号,这样就提升速度了。

5.5 服务器推送

HTTP/2 容许服务器未经请求,主动向客户端发送资源,这叫作服务器推送(server push)。

常见场景是客户端请求一个网页,这个网页里面包含不少静态资源。正常状况下,客户端必须收到网页后,解析HTML源码,发现有静态资源,再发出静态资源请求。其实,服务器能够预期到客户端请求网页后,极可能会再请求静态资源,因此就主动把这些静态资源随着网页一块儿发给客户端了。

6、参考连接

(完)

相关文章
相关标签/搜索