PeerShare-HTTP/2 #30

ohnowho · 2019-08-08T12:25:21Z

PeerShare-HTTP2

—— 2019.08.08
[TOC]

万维网的组成结构

1989年，当时在 CERN 工作的 Tim Berners-Lee 博士写了一份关于建立一个通过网络传输超文本系统的报告。这个系统起初被命名为 Mesh，在随后的1990年项目实施期间被更名为万维网（World Wide Web）。它在现有的TCP和IP协议基础之上建立，由四个部分组成：

一个用来表示超文本文档的文本格式，超文本标记语言（HTML）。
一个用来交换超文本文档的简单协议，超文本传输协议（HTTP）。
一个显示（以及编辑）超文本文档的客户端，即网络浏览器。第一个网络浏览器被称为 WorldWideWeb。
一个服务器用于提供可访问的文档，即 httpd 的前身。

这四个部分完成于1990年底，且第一批服务器已经在1991年初在CERN以外的地方运行了。 1991年8月16日，Tim Berners-Lee 在公开的超文本新闻组上发表的文章被视为是万维网公共项目的开始。

HTTP协议的组成结构

信封 envelope Header
发件人收件人目的地大小类型
信纸 letter Payload
想要传达的信息
邮戳 stamp Footer
确保信息正确无误地传达
HTTP相关的一些基础知识浅谈
HTTP相关的一些基础知识浅谈 #14

HTTP协议的各个版本

HTTP 0.9 1991年

只有GET 命令
只回应HTML格式
服务器发送完毕，就关闭TCP连接。

HTTP 1.0 1996年5月

GET POST HEAD
MIME type
客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。
由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。
Content-Encoding字段说明数据的压缩方法。
每个TCP连接只能发送一个请求,发送数据完毕，连接就关闭
有些浏览器(比如Firefox)在请求时，用了一个非标准的Connection字段。
Connection: keep-alive
建立可以复用的TCP连接，直到客户端或服务器主动关闭连接
新增 HTTP header
新增状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）
缓存头 If-Modified-Since ,Expires

HTTP 1.1 1997年1月

GET POST HEAD PUT PATCH OPTIONS DELETE
新增 Host字段
将请求发往同一台服务器上的不同网站，虚拟主机
头信息文本（ASCII编码），数据体可以是文本，也可以是二进制
持久连接 persistent connection
TCP连接默认不关闭，可以被多个请求复用
Connection: close 主动关闭
管道机制 pipelining
同一个TCP连接里面，客户端可以同时发送多个请求
按照顺序，先回应A请求，完成后再回应B请求
队头阻塞 HOL Head-of-line blocking
应用技巧合并脚本和样式表将图片嵌入CSS代码域名分片（domain sharding
引入了range头域，它允许只请求资源的某个部分返回206（Partial Content）
新增了24个错误状态响应码
400 Bad Request(没有HOST) 409（Conflict） 410（Gone）
缓存头 Entity tag，If-Unmodified-Since, If-Match, If-None-Match

SPDY 1.0 （读作speedy）2009年

SPDY 2.0 2012年

基于TLS（1.1以上）只支持https
NPN (Next Protocol Negotiation:13172）也就是加了一个域Query Supported Protocol List
在TLS的握手阶段增加一些字段来表明服务器端和客户端希望在TLS基础上使用HTTP之外的（SPDY）协议。由Google提出的，为SPDY铺路。
Client端程序的实现是：握手前对OpenSSL（或封装它的库）设置可接受哪些协议，握手后获取服务器选择了哪个协议，然后按选择的协议进行通信。
严重依赖SSL,不管收到的是HTTP请求，还是HTTPS请求，SPDY都会走一趟SSL握手的流程，以确定服务器是否支持SPDY。
多路复用请求
对请求划分优先级
压缩HTTP头压缩算法采用 DELEFT
Server Push
SPDY改进了HTTP，实际生活中的网站上很大的速度提升，HTTP不是瓶颈.
SPDY存在于应用层面，在http发送请求之前，修改请求。SPDY一度是一个事实上的标准，大部分浏览器都实施了SPDY.

HTTP 2.0 2015年

在2015年，谷歌决定将SPDY合并到HTTP协议中，弃用SPDY
演示 https://http2.akamai.com/demo

二进制协议

头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧
不是文本协议，不再可读，也不可无障碍的手动创建，改善的优化技术现在可被实施。
二进制协议的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为将来的高级应用打好了基础。如果使用文本实现这种功能，解析数据将会变得非常麻烦，二进制解析则方便得多。

a new binary framing layer 不向后兼容之前的版本
应用层基本保持不变，对网站开发者透明
(除非使用原始的TCP套接字构建网站或者自定义客户端)
Q: node中间层算自定义客户端？如通过中间层请求多个分公开的图片
HTTP2不需要站点和应用做出改变：使用HTTP/1.1和HTTP/2对他们来说是透明的。拥有一个最新的服务器和新点的浏览器进行交互就足够了。只有一小部分群体需要做出改变，而且随着陈旧的浏览器和服务器的更新，而不需Web开发者做什么，用的人自然就增加了。

Multipexing 多路复用

每个 Frame Header 都有一个 Stream ID 就是被用于实现该特性。每次请求/响应使用不同的 Stream ID。就像同一个 TCP 链接上的数据包通过 IP:PORT来区分出数据包去往哪里一样。通过 Stream ID 标识，所有的请求和响应都可以欢快的同时跑在一条 TCP 链接上了。下图是 http 和 spdy(http2 的模型和 spdy 是类似的) 的并发模型对比：

当流并发时，就会涉及到流的优先级和依赖。优先级高的流会被优先发送。图片请求的优先级要低于 CSS 和 SCRIPT，这个设计可以确保重要的东西可以被优先加载完。

Stream

Stream Identifier将http2连接上传输的每个帧都关联到一个“流”。
流是一个独立的，双向的帧序列可以通过一个http2的连接在服务端与客户端之间不断的交换数据。
每个单独的http2连接都可以包含多个并发的流，这些流中交错的包含着来自两端的帧。流既可以被客户端/服务器端单方面的建立和使用，也可以被双方共享，或者被任意一边关闭。在流里面，每一帧发送的顺序非常关键。接收方会按照收到帧的顺序来进行处理。
流的多路复用意味着在同一连接中来自各个流的数据包会被混合在一起。就好像两个（或者更多）独立的“数据列车”被拼凑到了一辆列车上，但它们最终会在终点站被分开。

A "stream" is an independent, bi-directional sequence of frames
exchanged between the client and server within an HTTP/2 connection.
Streams have several important characteristics:

o A single HTTP/2 connection can contain multiple concurrently open
streams, with either endpoint interleaving frames from multiple
streams.

o Streams can be established and used unilaterally or shared by
either the client or server.

o Streams can be closed by either endpoint.

o The order in which frames are sent on a stream is significant.
Recipients process frames in the order they are received. In
particular, the order of HEADERS, and DATA frames is semantically
significant.

o Streams are identified by an integer. Stream identifiers are
assigned to streams by the endpoint initiating the stream.


                                +--------+
                        send PP |        | recv PP
                       ,--------|  idle  |--------.
                      /         |        |         \
                     v          +--------+          v
              +----------+          |           +----------+
              |          |          | send H /  |          |
       ,------| reserved |          | recv H    | reserved |------.
       |      | (local)  |          |           | (remote) |      |
       |      +----------+          v           +----------+      |
       |          |             +--------+             |          |
       |          |     recv ES |        | send ES     |          |
       |   send H |     ,-------|  open  |-------.     | recv H   |
       |          |    /        |        |        \    |          |
       |          v   v         +--------+         v   v          |
       |      +----------+          |           +----------+      |
       |      |   half   |          |           |   half   |      |
       |      |  closed  |          | send R /  |  closed  |      |
       |      | (remote) |          | recv R    | (local)  |      |
       |      +----------+          |           +----------+      |
       |           |                |                 |           |
       |           | send ES /      |       recv ES / |           |
       |           | send R /       v        send R / |           |
       |           | recv R     +--------+   recv R   |           |
       | send R /  `----------->|        |<-----------'  send R / |
       | recv R                 | closed |               recv R   |
       `----------------------->|        |<----------------------'
                                +--------+

          send:   endpoint sends this frame
          recv:   endpoint receives this frame

          H:  HEADERS frame (with implied CONTINUATIONs)
          PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
          ES: END_STREAM flag
          R:  RST_STREAM frame


                          Figure 2: Stream States

Frame

Frame 是 HTTP/2 二进制格式的基础，基本可以把它理解为它 TCP 里面的数据包一样。HTTP/2 之所以能够有如此多的新特性，正是因为底层数据格式的改变

+-----------------------------------------------+
|                 Length (24)                   |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------+
|R|                 Stream Identifier (31)          |
+=+=================================================+
|                   Frame Payload (0...)        ...
+---------------------------------------------------+

Length: 表示 Frame Payload 部分的长度，另外 Frame Header 的长度是固定的 9 字节（Length + Type + Flags + R + Stream Identifier = 72 bit）。

- Type: 区分这个 Frame Payload 存储的数据是属于 HTTP Header 还是 HTTP Body；另外 HTTP/2 新定义了一些其他的 Frame Type，例如，这个字段为 0 时，表示 DATA 类型（即 HTTP/1.x 里的 Body 部分数据）

Flags: 共 8 位，每位都起标记作用。每种不同的 Frame Type 都有不同的 Frame Flags。例如发送最后一个 DATA 类型的 Frame 时，就会将 Flags 最后一位设置 1（flags &= 0x01），表示 END_STREAM，说明这个 Frame 是流的最后一个数据包。
R: 保留位。
Stream Identifier: 流 ID，当客户端和服务端建立 TCP 链接时，就会先发送一个 Stream ID = 0 的流，用来做些初始化工作。之后客户端和服务端从 1 开始发送请求/响应。

- Frame 由 Frame Header 和 Frame Payload 两部分组成。不论是原来的 HTTP Header 还是 HTTP Body，在 HTTP/2 中，都将这些数据存储到 Frame Payload，组成一个个 Frame，再发送响应/请求。通过 Frame Header 中的 Type 区分这个 Frame 的类型。

10种 frames

DATA
for the payload
DATA frames 必须和一个 stream 相关联
DATA frames 受 flow control 控制
只有当一个stream 的状态是 open ~~或 half-closed(remote)~~ 时 DATA frames 才能被发送.

DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated with a stream
1byte = 1 octet = 8bit
传输与stream关联的任意可变长度的octet序列
One or more DATA frames are used,for instance, to carry HTTP request or response payloads.
一个或多个DATA frames 被使用，比如，运输http 请求或相应的 payloads
DATA frames MAY also contain padding. Padding can be added to DATA frames to obscure the size of messages. Padding is a security feature;
DATA frames可能也包含padding. 添加padding可以模糊信息大小，padding 是一个安全特性。


    +---------------+
    |Pad Length? (8)|
    +---------------+-----------------------------------------------+
    |                            Data (*)                         ...
    +---------------------------------------------------------------+
    |                           Padding (*)                       ...
    +---------------------------------------------------------------+

The DATA frame contains the following fields:
DATA frame 包含以下字段：
- Pad Length: An 8-bit field containing the length of the frame
  padding in units of octets. This field is conditional and is only present if the PADDED flag is set.
  一个 8-bit 字段包含 frame padding 的长度，单位为octet
  只有设置了PADDED flag 才会存在
- Data: Application data. The amount of data is the remainder of the frame payload after subtracting the length of the other fields that are present.
  应用数据 = frame payload - 其他现有字段的长度
- Padding: Padding octets that contain no application semantic value.Padding octets MUST be set to zero when sending. A receiver is not obligated to verify padding, but MAY treat non-zero padding as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
  不包含应用语义。发送时必须将padding octects 设置为零。接收方没有义务验证 padding，但可能将非零的padding 视为PROTOCOL_ERROR类型的连接错误
The DATA frame defines the following flags:
- END_STREAM (0x1): Bit 0 being set indicates that this frame is the
  last that the endpoint will send for the identified stream.
  Setting this flag causes the stream to enter one of the "half
  closed" states or the "closed" state (Section 5.1).
- PADDED (0x8): Bit 3 being set indicates that the Pad Length field
  and any padding that it describes is present.
Note: A frame can be increased in size by one octet by including a
Pad Length field with a value of zero.
值为0 的 Pad Length 字段可以增加 frame 1个 octet长度

HEADERS
for the meta data

The HEADERS frame (type=0x1) is used to open a stream (Section 5.1),
and additionally carries a header block fragment. HEADERS frames can
be sent on a stream in the "open" or "half closed (remote)" states.

    +---------------+
    |Pad Length? (8)|
    +-+-------------+-----------------------------------------------+
    |E|                 Stream Dependency? (31)                     |
    +-+-------------+-----------------------------------------------+
    |  Weight? (8)  |
    +-+-------------+-----------------------------------------------+
    |                   Header Block Fragment (*)                 ...
    +---------------------------------------------------------------+
    |                           Padding (*)                       ...
    +---------------------------------------------------------------+

                      Figure 7: HEADERS Frame Payload

The HEADERS frame payload has the following fields:
- Pad Length: An 8-bit field containing the length of the frame
  padding in units of octets. This field is only present if the
  PADDED flag is set.
- E: A single bit flag indicates that the stream dependency is
  exclusive, see Section 5.3. This field is only present if the
  PRIORITY flag is set.
- Stream Dependency: A 31-bit stream identifier for the stream that
  this stream depends on, see Section 5.3. This field is only
  present if the PRIORITY flag is set.
- Weight: An unsigned 8-bit integer representing a priority weight for
  the stream, see Section 5.3. Add one to the value to obtain a weight between 1 and 256. This field is only present if the
  PRIORITY flag is set.
- Header Block Fragment: A header block fragment (Section 4.3).
- Padding: Padding octets.
The HEADERS frame defines the following flags:
- END_STREAM (0x1): Bit 0 being set indicates that the header block
  (Section 4.3) is the last that the endpoint will send for the
  identified stream.
A HEADERS frame carries the END_STREAM flag that signals the end
of a stream. However, a HEADERS frame with the END_STREAM flag
set can be followed by CONTINUATION frames on the same stream.
Logically, the CONTINUATION frames are part of the HEADERS frame.
- END_HEADERS (0x4): Bit 2 being set indicates that this frame
  contains an entire header block (Section 4.3) and is not followed
  by any CONTINUATION frames.
A HEADERS frame without the END_HEADERS flag set MUST be followed
by a CONTINUATION frame for the same stream. A receiver MUST
treat the receipt of any other type of frame or a frame on a
different stream as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR.
- PADDED (0x8): Bit 3 being set indicates that the Pad Length field
  and any padding that it describes is present.
- PRIORITY (0x20): Bit 5 being set indicates that the Exclusive Flag
  (E), Stream Dependency, and Weight fields are present;

PRIORITY
RST_STREAM
SETTINGS
PUSH_PROMISE
PING
GOAWAY
WINDOW_UPDATE
CONTINUATION

支持明文 HTTP 传输直到今天，没有任何主流浏览器支持非TLS的http2.

HTTP2.0 支持明文 HTTP 传输因为不是基于TLS,而是HTTP协议本身
尽管如此，大部分vendors表示，只支持基于TLS的http2,因此默认必须TLS.( Firefox和Chrome都明确地表示，他们只会实现基于TLS的http2.)
需要TLS1.2以上版本，因为需要一个ALPN扩展(application Layer Protocol Negotiation)。
对HTTP1.1有很好兼容(应用层面)，HTTP请求就不用走SSL握手了。

On HTTP Request:

  TCP连接on Port 80

  根据是否有proir knowledge，相应配置HTTP Headers

On HTTPS Request:

  ALPN协商具体用哪个协议，HTTP2.0, SPDY or HTTP1.1

prioritization 和 flow control

因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

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

数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。

客户端可以在opened stream中 HEADERS frame 指定数据流的优先级。优先级越高，服务器就会越早回应。在任何其他时候，客户端可以发送一个 PRIORITY frame 来改变一个stream的优先级。
当没有指定优先级时，server会异步地处理这些请求，无序。

Server Push

允许服务器通过推送它知道客户端将要求的数据来减少往返，当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH_PROMISE 的 Frame，里面带了 PUSH 需要新建的 Stream ID。

HTTP Header（在payload frame中） HPACK压缩算法

Header基本上和HTTP/1.1中的相同，除了一些伪Header 比如
:method, :scheme, :host and :path
如果我们约定将常用的请求比如 GET /index.html 用一个 1 来表示，POST /index.html 用 2 来表示。那么是不是可以节省很多字节？

为 HTTP/2 的专门量身打造的 HPACK 便是类似这样的思路延伸。它使用一份索引表来定义常用的 HTTP Header。把常用的 HTTP Header 存放在表里。请求的时候便只需要发送在表里的索引位置即可。例如 :method=GET 使用索引值 2 表示，:path=/index.html 使用索引值 5 表示（完整的列表参考：HPACK Static Table）。只要给服务端发送一个 Frame，该 Frame 的 Payload 部分存储 0x8285，Frame 的 Type 设置为 Header 类型，便可表示这个 Frame 属于 HTTP Header，请求的内容是：

GET /index.html

为什么是 0x8285，而不是 0x0205？这是因为高位设置为 1 表示这个字节是一个完全索引值（key 和 value 都在索引中）。类似的，通过高位的标志位可以区分出这个字节是属于一个完全索引值，还是仅索引了 key，还是 key 和 value 都没有索引。因为索引表的大小的是有限的，它仅保存了一些常用的 HTTP Header，同时每次请求还可以在表的末尾动态追加新的 HTTP Header 缓存。动态部分称之为 Dynamic Table。Static Table 和 Dynamic Table 在一起组合成了索引表：

<----------  Index Address Space ---------->
<-- Static  Table -->  <-- Dynamic Table -->
+---+-----------+---+  +---+-----------+---+
| 1 |    ...    | s |  |s+1|    ...    |s+k|
+---+-----------+---+  +---+-----------+---+
                       ^                   |
                       |                   V
                 Insertion Point      Dropping Point

HPACK 不仅仅通过索引键值对来降低数据量，同时还会将字符串进行霍夫曼编码来压缩字符串大小。
In 2015, at Google, they didn’t want to have two competing standards and so they decided to merge it into HTTP while giving birth to HTTP/2 and deprecating SPDY.

以常用的 User-Agent 为例，它在静态表中的索引值是 58，它的值是不存在表中的，因为它的值是多变的。第一次请求的时候它的 key 用 58 表示，表示这是一个 User-Agent ，它的值部分会进行霍夫曼编码（如果编码后的字符串变更长了，则不采用霍夫曼编码）。

服务端收到请求后，会将这个 User-Agent 添加到 Dynamic Table 缓存起来，分配一个新的索引值。客户端下一次请求时，假设上次请求User-Agent的在表中的索引位置是 62，此时只需要发送 0xBE（同样的，高位置 1），便可以代表：

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36。

HTTP协议的拓展

HTTPS

1994年 HTTP在基本的TCP/IP协议栈上发送信息，网景公司（Netscape Communication）在此基础上创建了一个额外的加密传输层：SSL Secure Sockets Layer 安全套接层。SSL 1.0没有在公司以外发布过，但SSL 2.0及其后继者SSL 3.0和SSL 3.1允许通过加密来保证服务器和客户端之间交换消息的真实性，来创建电子商务网站。SSL在标准化道路上最终成为TLS传输层安全(Transport Layer Security，TLS) ,随着版本1.0, 1.1, 1.2的出现成功地关闭漏洞。TLS 1.3 目前正在形成。

REST representational state transfer

在 2000 年，一种新的使用 HTTP 的模式被设计出来：representational state transfer (或者说 REST)。由 API 发起的操作不再通过新的 HTTP 方法传达，而只能通过使用基本的 HTTP / 1.1 方法访问特定的 URI。这允许任何 Web 应用程序通过提供 API 以允许查看和修改其数据，而无需更新浏览器或服务器：all what is needed was embedded in the files served by the Web sites through standard HTTP/1.1。 REST 模型的缺点在于每个网站都定义了自己的非标准 RESTful API，并对其进行了全面的控制；不同于 *DAV 扩展，客户端和服务器是可互操作的。 RESTful API 在 2010 年变得非常流行。
自 2005 年以来，可用于 Web 页面的 API 大大增加，其中几个 API 为特定目的扩展了 HTTP 协议，大部分是新的特定 HTTP 头：

Server-sent events，HTML5 服务器发送事件服务器可以偶尔推送消息到浏览器。
WebSocket，HTML5的一种在单个 TCP 连接上进行全双工通讯的协议持久连接多路复用，全双工通信，可以通过升级现有 HTTP 协议来建立。

只需建立一次Request/Response消息对，之后都是TCP连接，避免了需要多次建立Request/Response消息对而产生的冗余头部信息
HTTP和WebSocket
HTTP和WebSocket #5

webpack 与 HTTP2

AggressiveSplittingPlugin
插件 AggressiveSplittingPlugin 将原始的块分的更小。你可以指定你想要的块大小。它提高了缓存，但不利于压缩（对 HTTP/1 来说也影响传输时间）。
AggressiveSplittingPlugin 都能够找到一个合适的块大小（在限制内），并将块的模块（modules）和哈希（hash）保存到 records 中
当再次调用 AggressiveSplittingPlugin，在尝试分离剩余模块之前，它会先尝试从 records 中恢复块。这就确保已缓存的块能够被复用
输出多个需要被加载的块（chunk），应用就能使用多个 script 标签（并行）加载每个块
webpack按时间先后顺序输出这些块。最旧的文件先执行，最新的在最后。浏览器可以先执行已被缓存的块，同时加载最新的文件

后http2时代

http2做了许多艰难的折衷和妥协。随着http2逐渐部署，将会带来一个健全的协议升级方式，而这为将来更多的协议升级奠定了基础。同时，它也引入了一套概念和基础架构来并行处理多个不同版本协议。也许我们并不需要在引入新协议时就完全将旧的淘汰掉。

http2仍然背负了许多HTTP1的历史包袱，主要是为了保证数据流量能够在HTTP 1和http2之间无碍转发。这些包袱会阻碍进一步的的开发和创造，期待http3能丢掉其中一部分。

你认为http还缺少什么？

QUIC

Google的QUIC （快速UDP互联网连接）协议是一个非常有趣的试验，它在很大程度上继承了SPDY的衣钵。QUIC是一个UDP版的TCP + TLS + HTTP/2替代实现。

QUIC可以创建更低延迟的连接，并且也像HTTP/2一样，通过仅仅阻塞部分流解决了包裹丢失这个问题，让连接在不同网络上建立变得更简单－这其实正是MPTCP想去解决的问题。

QUIC现在还只有Google的Chrome和它后台服务器上的实现，虽然有第三方库libquic，但这些代码仍然很难在其他地方被复用。该协议也被IETF通信工作组引入了草案。

参考资料

SPDY以及HTTP2.0
https://www.cnblogs.com/zzSoftware/p/3753903.html
HTTP 协议入门
http://www.ruanyifeng.com/blog/2016/08/http.html
HTTP的发展
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
HTTP/2 新特性浅析
https://segmentfault.com/a/1190000002765886
What is HTTP/2
https://kinsta.com/learn/what-is-http2/#
Introduction to HTTP/2
https://developers.google.com/web/fundamentals/performance/http2/
Journey to HTTP/2
https://kamranahmed.info/blog/2016/08/13/http-in-depth/
Hypertext Transfer Protocol Version 2
https://http2.github.io/http2-spec/
webpack & HTTP/2
https://juejin.im/post/59e87b89f265da433226b0f3
HTTP2 文档
https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PeerShare-HTTP/2 #30

PeerShare-HTTP/2 #30

ohnowho commented Aug 8, 2019 •

edited

Loading

PeerShare-HTTP/2 #30

PeerShare-HTTP/2 #30

Comments

ohnowho commented Aug 8, 2019 • edited Loading

PeerShare-HTTP2

万维网的组成结构

HTTP协议的组成结构

HTTP协议的各个版本

HTTP 0.9 1991年

HTTP 1.0 1996年5月

HTTP 1.1 1997年1月

SPDY 1.0 （读作speedy）2009年

SPDY 2.0 2012年

HTTP 2.0 2015年

二进制协议

Multipexing 多路复用

Stream

Frame

10种 frames

支持明文 HTTP 传输 直到今天，没有任何主流浏览器支持非TLS的http2.

prioritization 和 flow control

Server Push

HTTP Header（在payload frame中） HPACK压缩算法

HTTP协议的拓展

HTTPS

REST representational state transfer

webpack 与 HTTP2

后http2时代

QUIC

参考资料

相关书籍

ohnowho commented Aug 8, 2019 •

edited

Loading

支持明文 HTTP 传输直到今天，没有任何主流浏览器支持非TLS的http2.