HTTP杂谈

HTTP 协议

HTTP请求和响应步骤

以上完整表示了HTTP请求和响应的7个步骤，下面从TCP/IP协议模型的角度来理解HTTP请求和响应如何传递的。

TCP/IP协议

TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议，通过20多年的发展已日渐成熟，并被广泛应用于局域网和广域网中，目前已成为事实上的国际标准。TCP/IP协议簇是一组不同层次上的多个协议的组合，通常被认为是一个四层协议系统，与OSI的七层模型相对应。

HTTP协议就是基于TCP/IP协议模型来传输信息的。

(1). 链路层

也称作数据链路层或网络接口层（在第一个图中为网络接口层和硬件层），通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。

(2). 网络层

也称作互联网层（在第一个图中为网际层），处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。

IP是一种网络层协议，提供的是一种不可靠的服务，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都通过端系统和每个中间路由器中的IP层在互联网中进行传输。

ICMP是IP协议的附属协议。IP层用它来与其他主机或路由器交换错误报文和其他重要信息。

IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。

(3). 传输层

主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。

TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。

UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。

(4). 应用层

应用层决定了向用户提供应用服务时通信的活动。TCP/IP 协议族内预存了各类通用的应用服务。包括 HTTP，FTP（File Transfer Protocol，文件传输协议），DNS（Domain Name System，域名系统）服务。

当应用程序用TCP传送数据时，数据被送入协议栈中，然后逐个通过每一层直到被当作一串比特流送入网络。其中每一层对收到的数据都要增加一些首部信息（有时还要增加尾部信息），该过程如图所示。

当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识，以确定接收数据的上层协议。这个过程称作分用（Demultiplexing）。协议是通过目的端口号、源I P地址和源端口号进行解包的。

通过以上步骤我们从TCP/IP模型的角度来理解了一次HTTP请求与响应的过程。

下面这张图更清楚明白：

下面具体来看如何进行一步步操作的。

Http是什么？

通俗来讲，他就是计算机通过网络进行通信的规则，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据。目前任何终端（手机，笔记本电脑。。）之间进行任何一种通信都必须按照Http协议进行，否则无法连接。

1、四个基于

请求与响应： 客户端发送请求，服务器端响应数据

无状态的： 协议对于事务处理没有记忆能力，客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配等，因此增加页面等待时间，当客户端向服务器端发送请求，服务器端响应完毕后，两者断开连接，也不保存连接状态，一刀两断！恩断义绝！从此路人！下一次客户端向同样的服务器发送请求时，由于他们之前已经遗忘了彼此，所以需要重新建立连接。HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于 是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管 理状态了。有关 Cookie 的详细内容稍后讲解。

应用层： Http是属于应用层的协议，配合TCP/IP使用。

TCP/IP： Http使用TCP作为它的支撑运输协议。HTTP客户机发起一个与服务器的TCP连接，一旦连接建立，浏览器（客户机）和服务器进程就可以通过套接字接口访问TCP。

针对无状态的一些解决策略：

有时需要对用户之前的HTTP通信状态进行保存，比如执行一次登陆操作，在30分钟内所有的请求都不需要再次登陆。于是引入了Cookie技术。

HTTP/1.1想出了持久连接（HTTP keep-alive）方法。其特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive即为表明使用了持久连接。等等还有很多……

2、持久连接

持久连接的特点是，只要任意一端 没有明确提出断开连接，则保持 TCP 连接状态。在 HTTP/1.1 中，所有的连接认都是持久连接，但在 HTTP/1.0 并未标准化。
持久连接使得多数请求以管线化（pipelinin）方式发送成为可能。从发送请求后需待并到响应，才能发送下一请求。管线化技出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要用途一个接一个地等待响应。

3、 Cookie技术

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

HTTP/1.0 和 HTTP/1.1 支持的主要方法

PUT：传输文件
PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。 但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。

使用PUT 方法的请求、响应例子

说明	说明
请求	PUT/example.html HTTP/1.1 Host:www.hackr.jp Content_Type:text/html Content-Length: 1560
响应 1	响应返回状态码 204 No Content（比如 ：该 html 已存在于服务器上）

响应1的意思其实是请求行成功了，但无返回

**HEAD：获得报文首部 **
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。

使用 HEAD 方法的请求·响应的例子

说明	说明
请求	HEAD /index.html HTTP/1.1 Host: www.hackr.jp
响应	返回index.html有关的响应首部

**DELETE：删除文件 **
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。

使用 DELETE 方法的请求·响应的例子

说明	说明
请求	DELETE /example.html HTTP/1.1 Host: www.hackr.jp
响应	响应返回状态码 204 No Content（比如 ：该 html 已从该服务器上删除）

TRACE：追踪路径

TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方 法。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服 务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最 后接收到请求的服务器端则返回状态码 200 OK 的响应。 客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。 但是，TRACE 方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。

使用 TRACE 方法的请求·响应的例子

说明	说明
请求	TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2 HTTP/1.1 200 OK Content-Type: message/http 39
响应	Content-Length: 1024 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2（返回响应包含请求内容）

**CONNECT：要求用隧道协议连接代理 **
CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协 议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容 加 密后经网络隧道传输。
CONNECT 方法的格式如下所示：
CONNECT 代理服务器名:端口号 HTTP版本

使用 CONNECT 方法的请求·响应的例子

说明	说明
请求	CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp
响应	HTTP/1.1 200 OK（之后进入网络隧道）

HTTP请求报文

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。

在请求首部和响应首部后或许还有 其他非标准首部字段（X-Frame-Options、DNT、P3P）更多内容见《图解HTTP》

1.请求行

请求行分为三个部分：请求方法、请求地址和协议版本

请求方法

HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

最常的两种GET和POST，如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。

请求地址

URL：统一资源定位符，是一种自愿位置的抽象唯一识别方法。

组成：<协议>：//<主机>：<端口>/<路径>

端口和路径有时可以省略（HTTP默认端口号是80）

如下例：

有时会带参数，GET请求

协议版本

协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1

2.请求首部

HTTP/1.1 首部分为四大类
1、通用首部

2、请求首部

实体首部

响应首部

HTTP 首部字段重复了会如何：当 HTTP 报文首部中出现了两或两以上具有相同首部段名怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻的不同，结果可能并不一致。有些浏览器优先处理第一次出现的首部段，而有些则优先处理最后出现的首部段。

3.请求数据

可选部分，比如GET请求就没有请求数据。

下面是一个POST方法的请求报文：

POST 　/index.php　HTTP/1.1 　　 请求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2　　请求头
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer:http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
　　空行
username=aa&password=1234　　请求数据

HTTP响应报文

HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。

1.状态行

由3部分组成，分别为：协议版本，状态码，状态码描述。

其中协议版本与请求报文一致，状态码描述是对状态码的简单描述，所以这里就只介绍状态码。

状态码

状态代码为3位数字。

• 1xx：指示信息——表示请求已接收，继续处理。
• 2xx：成功——表示请求已被成功接收、理解、接受。
• 3xx：重定向——需要进行附加操作以完成请求。
• 4xx：客户端错误——服务器无法处理请求。
• 5xx：服务器端错误——服务器处理请求出错。

下面列举几个常见的：

更多内容见《图解HTTP》

2.响应首部

3.响应数据

用于存放需要返回给客户端的数据信息。

下面是一个响应报文的实例：

HTTP/1.1 200 OK　　状态行
Date: Sun, 17 Mar 2013 08:12:54 GMT　　响应头部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
　　空行

　　响应数据 Hello HTTP!

关于请求头部和响应头部的知识点很多，这里只是简单介绍。

通过以上步骤，数据已经传递完毕，HTTP/1.1会维持持久连接，但持续一段时间总会有关闭连接的时候，这时候据需要断开TCP连接。

HTTPS 原理

HTTP 缺点

• 通信使用明文（不加密），内容可能被窃听。
• 不验证通信方的份，因此有可能遭遇伪装（DOS攻击）。
• 无法证明报文的完整性，所以有可能已遭篡改（中间人攻击）。

HTTP+加密+认证+完整性保护=HTTPS

0

1、加密

1、共享密钥加密

加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可能会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。
2、公开密钥加密

• 公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。用公开密钥密方式，发送密文的一方用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用解密的私有密钥，不必担心密钥被攻击者窃听而盗走。另外，要想根据密文和公开密钥，恢复到息原文是常困难，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能做到。退一步讲，如果能对一非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术看不太现实的。
  HTTPS采用混合加密机制：在交换密钥环节用公开密钥加密方式，之后的建立通信文阶段则用共享密钥加密方式
• 公开密钥加密缺点及改正
  缺点：遗憾的是，公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
  改正：使用数字证书认证机构和七相关机关颁发的公开密钥证书；步骤如下：
  

2、 认证

SSL客户端认证步骤：
为达到 SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
步骤 1： 接收到需要认证资源的请求，服务器会发送 CertificateRequest 报文，要求客户端提供客户端证书。
步骤 2： 用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。
步骤3：服务器验证客户端证书通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

3、HTTPS的安全通信机制

消除HTTP瓶颈的SPDY

1、HTTP的瓶颈

有些网站有实时更新内容的需求，HTTP却无法妥善地处理好这项任务。因为以下的HTTP标准会成为瓶颈。
1、一条连接上只可发送一个请求
2、 请求只能从客户端开始。客户端不可以接收除响应以外的指令
3、请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
4、 发送冗长的首部。每次互相发送相同的首部造成的浪费较多
5、可任意选择数据压缩格式。非强制压缩发送。

2、SPDY的目标

陆续出现的 Ajax 和 Comet 等提高易用性的技术（详情见图解HTTP），一定程度上使 HTTP得到了改善，但 HTTP 协议本身的限制也令人有些束手无策。为了进行根本性的改善，需要有一些协议层面上的改动。处于持续开发状态中的 SPDY 协议，正是为了在协议级别消除 HTTP所遭遇的瓶颈。

3、SPDY 的设计与功能

1、设计：

SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。SPDY 以会话层的形式加入，控制对数据的流动，但还是采用 HTTP建立通信连接。因此，可照常使用 HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 报文等。

2、使用 SPDY 后，HTTP 协议额外获得以下功能。

多路复用流：通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
赋予请求优先级:SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
压缩 HTTP 首部:压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
推送功能:支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
服务器提示功能:服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

使浏览器进行全双工通信的WebSocket

1、WebSocket协议的主要特点

1、推送功能
支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。

**2、减少通信量 **
只要建立起 WebSocket 连接，就希望一直保持连接状态。和 HTTP 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应减少了。

3、WebSocket通信步骤

1、握手、请求
为了实现 WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服务器通信协议发生改变，以达到握手的目的。

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Sec-WebSocket-Key 字段内记录着握手过程中必不可少的键值。Sec-WebSocket-Protocol 字段内记录使用的子协议子协议按 WebSocket 协议标准在连接分开使用时，定义那些连接的名称。

2. 握手、响应

对于之前的请求，返回状态码 101 Switching Protocols 的响应。
HTTP/1.1 101 Switching Protocols
Upgrade: websocke
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Sec-WebSocket-Accept 的字段值是由握手请求中的 Sec- WebSocket-Key 的字段值生成的。 成功握手确立 WebSocket 连接之后，通信时不再使用 HTTP 的数 据帧，而采用 WebSocket 独立的数据帧

3、WebSocket与Socket 的关系

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议
WebSocket是应用层协议。

HTTP0.9、HTTP1.0、HTTP1.1与HTTP2.0区别

1、HTTP0.9

HTTP/0.9是第一个版本的HTTP协议，已过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。由于没有协议头，造成了HTTP/0.9协议只支持一种内容，即纯文本。不过网页仍然支持用HTML语言格式化，同时无法插入图片。

HTTP/0.9具有典型的无状态性，每个事务独立进行处理，事务结束时就释放这个连接。由此可见，HTTP协议的无状态特点在其第一个版本0.9中已经成型。一次HTTP/0.9的传输首先要建立一个由客户端到Web服务器的TCP连接，由客户端发起一个请求，然后由Web服务器返回页面内容，然后连接会关闭。如果请求的页面不存在，也不会返回任何错误码

2、HTTP1.0

HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用。相对于HTTP/0.9增加了如下主要特性：

• 请求与响应支持头域
• 响应对象以一个响应状态行开始
• 响应对象不只限于超文本
• 开始支持客户端通过POST方法向Web服务器提交数据，支持GET、HEAD、POST方法
• 支持长连接（但默认还是使用短连接），缓存机制，以及身份认证

3、HTTP1.1

HTTP协议的第三个版本是HTTP/1.1，是目前使用最广泛的协议版本。HTTP/1.1是目前主流的HTTP协议版本，相对于HTTP/1.0新增了以下内容：

1. 默认为长连接

HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection：keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

2. 提供了范围请求功能(宽带优化)

HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。这是支持文件断点续传的基础。

3. 提供了虚拟主机的功能(HOST域)

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

4. 多了一些缓存处理字段

HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，一般被称为e-tags，新增更为强大的Cache-Control头。

5. 错误通知的管理

在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

4、HTTP2.0:SPDY的升级版

HTTP/2 是如何提高效率呢？

二进制分帧：HTTP 2.0 的所有帧都采用二进制编码

• 帧：客户端与服务器通过交换帧来通信，帧是基于这个新协议通信的最小单位。

• 消息：是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。

• 流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2…N）；

多路复用 (Multiplexing)

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。有了新的分帧机制后，HTTP/2 不再依赖多个TCP 连接去实现多流并行了。每个数据流都拆分成很多互不依赖的帧，而这些帧可以交错（乱序发送），还可以分优先级。最后再在另一端把它们重新组合起来。HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接（每个域名一个连接）即可。

请求优先级

• 把HTTP 消息分解为很多独立的帧之后，就可以通过优化这些帧的交错和传输顺序，每个流都可以带有一个31 比特的优先值：0 表示最高优先级；2的31次方-1 表示最低优先级。

• 服务器可以根据流的优先级，控制资源分配（CPU、内存、带宽），而在响应数据准备好之后，优先将最高优先级的帧发送给客户端。

• HTTP 2.0 一举解决了所有这些低效的问题：浏览器可以在发现资源时立即分派请求，指定每个流的优先级，让服务器决定最优的响应次序。这样请求就不必排队了，既节省了时间，也最大限度地利用了每个连接。

header压缩

HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP/2使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

服务端推送

• 服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确地请求。

• HTTP 2.0 连接后，客户端与服务器交换SETTINGS 帧，借此可以限定双向并发的流的最大数量。

• 所有推送的资源都遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

• 服务器必须遵循请求 - 响应的循环，只能借着对请求的响应推送资源

参考：《图解HTTP》
参考链接：HTTP