HTTP2基础概念以及工具

HTTP2基础概念以及工具

HTTP/2连接

HTTP协议

HTTP1.0 RFC1945 HTTP1.1 RFC2616 HTTP/2 RFC7540

HTTP/1.X的缺点

HTTP/1.x 是一个应用非常广泛的应用层协议，但它的实现方式对现代的web应用的性能存在限制。主要体现在下面两点：

HTTP/1.0 只允许在一条TCP连接上处理一个HTTP请求， HTTP/1.1增加了请求pipelineing，但也是有限的缓解了请求并发性和head-of-line 阻塞问题 HTTP 头部域经常是重复的或冗长的，这会浪费不必要的网络带宽

HTTP/2的优点

可以在同一连接上交叉request和response message 采用更有效率的HTTP 头部编码 可以定义请求的优先级，让更重要的请求优先完成，极大的提升了性能 支持server push

消息模型

HTTP/2协议概览

HTTP/2支持HTTP/1.1全部核心特性，并且效率更高。

协议中的基本单元是基于二进制的frame 通过将每个HTTP请求/响应交换关联到它自己的stream上来实现请求多路复用 支持流控和优先级 支持服务器推送 支持头部压缩两个基本概念： Frame StreamRFC： 版本标识符：

h2 用在TLS ALPN扩展域中 h2c 用在Upgrade头部域中

HTTP2 三种方式协商过程

直接协商过程

HTTP2连接方式1– upgrade

在不知道对端是否支持HTTP/2的情况下，client使用带有h2c的Upgrade头部域来发 request，如下所示：

当request带有body时，可以使用OPTIONS request，如下所示

HTTP2连接方式2– 直接连接

如果预先知道对端支持HTTP/2，客户端可以直接发起连接，但RFC规定每个终端（endpoint）必须发送一个连接前言（preface）作为协议的最终确认并对HTTP/2连接做初始化设置。连接过程如下图所示：

握手过程：1、客户端必须首先发送一个连接序言，逻辑结构为“PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n”2、Preface之后必须紧跟一个settings frame，may be empty3、Server连接前言的第一个frame必须是settings frame，may be empty4、任一端接收到SETTINGS帧之后，都需要返回一个包含确认标志位SETTIGN作为确认5、其他帧都是正常的数据传输

HTTP2连接方式3– ALPN协商

HTTP/2安全版本在TLS上构建，协商采用的ALPN扩展协议，采用“h2”作为协议标识符（Layer Protocol Negotiation）

HTTP/2 协议本身并没有要求它必须基于 HTTPS（TLS）部署，但是出于以下三个原因，实际使用中，HTTP/2 和 HTTPS 几乎都是捆绑在一起：

HTTP 数据明文传输，数据很容易被中间节点窥视或篡改，HTTPS 可以保证数据传输的保密性、完整性和不被冒充； 正因为 HTTPS 传输的数据对中间节点保密，所以它具有更好的连通性。基于 HTTPS 部署的新协议具有更高的连接成功率； 当前主流浏览器，都只支持基于 HTTPS 部署的 HTTP/2；

流程如下：1.客户端和服务器端TLS层协商2.（后面协商过程和HTTP2直接连接过程完全一致）3.客户端发送连接序言（同上表示，PRI + SETTINGS）4.接收到客户端连接序言之后，服务器端发送连接序言5.双方各自确认SETTINGS帧6.其它帧的正常传输

支持HTTP/2的SSL应用必须满足下面的条件：

TLS1.2 or higher 支持SNI 禁用重协商TLS1.2要求 禁止压缩 禁用重协商 TLS 1.2 Cipher Suites（DHE>2048bit && ECC>224bit） TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 必须TLS1.3 or higher 要求 支持SNI扩展

HTTP2多路复用

HTTP2-frame

HTTP2-分析stream方式1

HTTP2-分析stream方式2

直接过滤: == idId 就是帧后面的数字

HTTP2 错误代码

H2 Error code 一般通过RST_STREAM and GOAWAY frames 来传输流或者连接的错误信息

HTTP2 Message

HTTP Message Exchanges

HTTP/2 协议被设计的尽量兼容HTTP/1。关于HTTP/1的RFC7231， RFC7232，RFC7233，RFC7234和RFC7235同样适用于HTTP/2。RFC7230的部分内容比如URI schemes，虽然表示方式被重新定义了，但仍然适用于HTTP/2。

注意：HTTP/2不再支持下面这些的特性：不支持

Chunked encoding 101 Switching Protocols 大写的header namec- onnection-specific 头部域，如Connection、Keep-Alive、Proxy-Connection、Transfer-Encoding和Upgrade

HTTP Header Fields

HTTP/2报头字段注意点：

和HTTP/1.x报头字段一样，都是ASCII字符表示 字段要求全部小写，"Accept" -> "accept" 若大写，会被作为不完整数据对待，有被丢弃的风险 新增伪报头字段，不允许终端自己产生，只允许规范中所定义的5个但不属于常规HTTP头部字段，1.:method 2.:scheme3.:authority4.:path5.:status （response头部） 伪报头字段必须出现在常规HTTP报头字段之前 连接属性专用字段（Connection-Specific Header Fields）不再被使用。比如Keep-Alive, Proxy-Connection, Transfer-Encoding和Upgrade等

Cookie头部域

RFC7230中对Cookie头部的规定不适用于HTTP/2。为了更好的压缩效率，Cookie 头部可以被分成多个具有相同field名的头部域，每个field包含一个或多个cookie-pair，像下面这样：cookie: a=bcookie: c=dcookie: e=f

HTTP1.1cookie: a=b; c=d; e=f

HTTP2 Frame

HTTP2协议

HTTP/2

分帧层，即h2多路复用的核心部分 数据或http层，包含传统上被认为是HTTP及其关联数据的部分

特点

分帧层，H2的分帧层是基于帧的二进制协议 首部压缩，h2的首部还会被深度压缩，显著减少传输中的冗余字节 多路复用，（请求和响应交织在一起） 加密传输，线上传输大部分是加密

所有的Frame都由长度为9-byte的头部和可变长度的payload组成

HTTP2 Stream

流-Stream

流（Stream），服务器和客户端在HTTP/2连接内用于交换帧数据的独立双向序列，逻辑上可看做一个较为完整的交互处理单元，即表达一次完整的资源请求-响应数据交换流程；一个业务处理单元，在一个流内进行处理完毕，这个流生命周期完结。

流是一个独立的，双向的帧序列；可以通过一个http2的连接在服务端与客户端之间不断的交换数据。

流特点

一个HTTP/2连接可同时保持多个打开的流 流可被客户端或服务器单独或共享创建和使用 流可被任一端关闭 在流内发送和接收数据都要按照顺序 流的标识符用无符号31-bit整数表示。标识由创建流的终端分配 流与流之间逻辑上是并行、独立存在

流的多路复用

流的概念提出是为了实现多路复用，在单个连接上实现同时进行多个业务单元数据的传输。逻辑图如下：

流的实际传输

流的理解

每一个帧可看做是一个学生，流可以认为是组（流标识符为帧的属性值），一个班级（一个连接）内学生被分为若干个小组，每一个小组分配不同的具体任务。 HTTP/1.0 一次请求-响应，建立一个连接，用完关闭；每一个小组任务都需要建立一个班级，多个小组任务多个班级，1:1比例 任务和连接1:1 HTTP/1.1 Pipeling解决方式为，若干个小组任务排队串行化单线程处理，后面小组任务等待前面小组任务完成才能获得执行机会，一旦有任务处理超时等，后续任务只能被阻塞，毫无办法，也就是人们常说的线头阻塞 HTTP/2多个小组任务可同时并行（严格意义上是并发）在班级内执行。一旦某个小组任务耗时严重，但不会影响到其它小组任务正常执行 针对一个班级资源维护要比多个班级资源维护经济多了，这也是多路复用出现的原因

流的组成

流的概念提出，就是为了实现多路复用。影响因素：

流的优先级（priority）属性建议终端（客户端+服务器端）需要按照优先级值进行资源合理分配，优先级高的需要首先处理，优先级低的可以稍微排排队，这样的机制可保证重要数据优先处理。 流的并发数（或者说同一时间存在的流的个数）初始环境下不少于100个 流量控制阀协调网络带宽资源利用，由接收端提出发送端遵守其规则 流具有完整的生命周期，从创建到最终关闭，经历不同阶段

流的标识符

31个字节表示无符号的整数，1~2^31-1 客户端创建的流以奇数表示，服务器端创建流以偶数表示 0x0用来表示连接控制信息流，不能够创建新流 通过101 协议切换升级切换到HTTP/2，0x1所指代流处于"half closed(local)"，不能用于创建新流 新建流的标识符要大于已有流和预留的流的标识符 新建流第一次被使用时，低于此标识符的并且处于空闲"idle"状态的流都会被关闭 已使用的流标识符不能被再次使用 终端的流标识符若被耗尽的情况下1.若是客户端，需要关闭连接，创建新的连接创建新流2.若是服务器端，需要发送一个GOAWAY帧通知客户端，强迫其打开一个新连接

流的并发数量

每一端都可以发送包含有SETTINGS_MAX_CONCURRENT_STREAMS参数的SETTINGS帧限制对等端流的最大并发量 对等端接收之后遵守终端最大并发量限制约定 状态为"open"或"half closed"的流需要计入限制总数 保留态"reserved"流不算入限制总数内 终端接收到HEADERS帧导致创建的流总数超过限制，需要响应PROTOCOL_ERROR或REFUSED_STREAM错误，具体哪一种错误，需要根据终端是否可以检测得到允许自动重复重试 终端想降低SETTINGS_MAX_CONCURRENT_STREAMS设置的活动流的上限，若低于当前已经打开流的数值，可以选择光比溢出的流或者允许流继续存在直到完成

流量控制

多路复用会引入资源竞争，流量控制可以保证流之间不会严重影响到彼此。流量控制通过使用WINDOW_UPDATE帧实现，可作用于单个流以及整个的连接。一些原则如下：

逐跳（流量控制是特定于一个连接的。是在单独的一跳的两个端点之间的，并不是在端到端的路径上的） 具有方向性（由接收者全面控制。接收方向可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制） 不能够被禁止 初始窗口值为65535字节，针对单个流，以及整个连接都有效 基于WINDOW_UPDATE帧传输实现，接收端通告对端准备在流/连接上接收的字节数 接收端完全控制权限，接收端可通告针对流/连接的窗口值，发送者需要遵守 目前只有DATA帧可被流量控制，仅针对其有效负载计算；超出窗口值，其负载可以为空

流的优先级

通过设置stream的优先级，可以让终端更好的分配资源，尤其是在发送容量有限的情况下选择stream来传输frame。 客户端可以在HEADERS frame中包含优先级信息来设置新stream的优先级，也可以在任何时候使用PRIORITY frame来改变stream的优先级。 设置stream的priority的时候可以定义它的优先级依赖于另一个stream的完结，该stream用上图中的Stream Dependency来定义。该值为0x0表示不依赖于其它stream。注意stream不能依赖其自身。 E用来定义该stream与其依赖的stream之间的依赖关系是否唯一。 如果没有明确指定，所有的stream的默认优先级为16

Server push

请求对比

Server Push

服务器推送（server push)指的是，还没收到浏览器请求，服务器就把各种资源推送给浏览器

HTTP/2工具

压力客户端：h2load, Avalanche，Loadrunner等 功能客户端：nghttp，curl，各种浏览器等 服务器：ngAvalanche等 HTTP/2 工具列表：https://github.com/http2/http2-spec/wiki/Implementations HTTP/2 Server: 1.ng-D -d /usr/local/apache2/htdocs/ 80 --no-tls 2.ng-d /usr/local/apache2/htdocs/ 80 -v --no-tls HTTP/2 Client：1.ng-v2.curl ----–v Loadrunner录制HTTP/2 脚本https://lrhelp.saas.hpe.com/en/12.53/help/WebHelp/Content/VuGen/t_HTTP2.htm

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。