HTTP/2：优化协议，提升效率与并发——IETF新标准

需积分: 9 76 浏览量更新于2024-07-22 收藏 134KB PDF 举报

Hypertext Transfer Protocol Version 2 (HTTP/2) 是一个重要的互联网协议升级，由 Internet Engineering Task Force (IETF) 发布，RFC 7540 为其标准文档。HTTP/2 主要目标是优化网络资源的使用，减少延迟感知，并引入了关键技术改进。首先，HTTP/2 引入了头部字段压缩（Header Field Compression），这是一种数据压缩技术，可以显著减小数据传输量，提高服务器与客户端之间的通信效率。这使得同一连接上能够同时处理多个请求和响应，从而提升了并发性能。相比于 HTTP/1.1，HTTP/2 的多路复用能力使得网络带宽得到了更有效地利用。其次，HTTP/2 还支持服务器主动推送（Server Push），即在客户端请求某个资源之前，服务器可以根据预判自动推送可能相关的其他资源，进一步减少了网络往返次数，加快了页面加载速度。这种特性对于动态内容丰富的网站尤为有利，如新闻、视频流等。值得注意的是，尽管HTTP/2 在语法上是一个全新的设计，但它并未完全替代 HTTP/1.1，而是作为其后继者存在。原有的 HTTP/1.1 的语义保持不变，意味着现有的客户端和服务器库不需要重写，只需要支持新的协议栈即可逐步迁移至HTTP/2。 HTTP/2 的发布过程遵循 IETF 的标准化流程，经过公开审查并得到 Internet Engineering Steering Group (IESG) 的批准，表明其在业界具有广泛的认可度和稳定性。这份规范文档由 Mozilla 和 Google 等公司共同维护，反映了当前 Web 浏览器和服务器技术的发展趋势。总结来说，HTTP/2 是一项旨在提升 Web 应用性能的关键技术，通过优化数据传输、增强并发处理和引入服务器推送等功能，对现代互联网应用体验产生了深远影响。随着越来越多的网站和服务采用 HTTP/2，它已成为构建高性能 Web 服务不可或缺的一部分。

RFC 7540 HTTP/2 May 2015

5.1. Stream States

The lifecycle of a stream is shown in Figure 2.

+--------+

send PP | | recv PP

,--------| idle |--------.

/ | | \

v +--------+ v

+----------+ | +----------+

,------| reserved | | recv H | reserved |------.

| +----------+ v +----------+ |

| | +--------+ | |

| send H | ,-------| open |-------. | recv H |

| | / | | \ | |

| v v +--------+ v v |

| +----------+ | +----------+ |

| +----------+ | +----------+ |

| | | | |

| | 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

Note that this diagram shows stream state transitions and the frames

and flags that affect those transitions only. In this regard,

CONTINUATION frames do not result in state transitions; they are

effectively part of the HEADERS or PUSH_PROMISE that they follow.

Belshe, et al. Standards Track [Page 16]

RFC 7540 HTTP/2 May 2015

For the purpose of state transitions, the END_STREAM flag is

processed as a separate event to the frame that bears it; a HEADERS

frame with the END_STREAM flag set can cause two state transitions.

Both endpoints have a subjective view of the state of a stream that

could be different when frames are in transit. Endpoints do not

coordinate the creation of streams; they are created unilaterally by

either endpoint. The negative consequences of a mismatch in states

are limited to the "closed" state after sending RST_STREAM, where

frames might be received for some time after closing.

Streams have the following states:

idle:

All streams start in the "idle" state.

The following transitions are valid from this state:

* Sending or receiving a HEADERS frame causes the stream to

become "open". The stream identifier is selected as described

in Section 5.1.1. The same HEADERS frame can also cause a

stream to immediately become "half-closed".

* Sending a PUSH_PROMISE frame on another stream reserves the

idle stream that is identified for later use. The stream state

for the reserved stream transitions to "reserved (local)".

* Receiving a PUSH_PROMISE frame on another stream reserves an

idle stream that is identified for later use. The stream state

for the reserved stream transitions to "reserved (remote)".

* Note that the PUSH_PROMISE frame is not sent on the idle stream

but references the newly reserved stream in the Promised Stream

ID field.

Receiving any frame other than HEADERS or PRIORITY on a stream in

this state MUST be treated as a connection error (Section 5.4.1)

of type PROTOCOL_ERROR.

reserved (local):

A stream in the "reserved (local)" state is one that has been

promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame

reserves an idle stream by associating the stream with an open

stream that was initiated by the remote peer (see Section 8.2).

Belshe, et al. Standards Track [Page 17]

RFC 7540 HTTP/2 May 2015

In this state, only the following transitions are possible:

* The endpoint can send a HEADERS frame. This causes the stream

to open in a "half-closed (remote)" state.

* Either endpoint can send a RST_STREAM frame to cause the stream

to become "closed". This releases the stream reservation.

An endpoint MUST NOT send any type of frame other than HEADERS,

RST_STREAM, or PRIORITY in this state.

A PRIORITY or WINDOW_UPDATE frame MAY be received in this state.

Receiving any type of frame other than RST_STREAM, PRIORITY, or

WINDOW_UPDATE on a stream in this state MUST be treated as a

connection error (Section 5.4.1) of type PROTOCOL_ERROR.

reserved (remote):

A stream in the "reserved (remote)" state has been reserved by a

remote peer.

In this state, only the following transitions are possible:

* Receiving a HEADERS frame causes the stream to transition to

"half-closed (local)".

* Either endpoint can send a RST_STREAM frame to cause the stream

to become "closed". This releases the stream reservation.

An endpoint MAY send a PRIORITY frame in this state to

reprioritize the reserved stream. An endpoint MUST NOT send any

type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in

this state.

Receiving any type of frame other than HEADERS, RST_STREAM, or

PRIORITY on a stream in this state MUST be treated as a connection

error (Section 5.4.1) of type PROTOCOL_ERROR.

open:

A stream in the "open" state may be used by both peers to send

frames of any type. In this state, sending peers observe

advertised stream-level flow-control limits (Section 5.2).

From this state, either endpoint can send a frame with an

END_STREAM flag set, which causes the stream to transition into

one of the "half-closed" states. An endpoint sending an

Belshe, et al. Standards Track [Page 18]

RFC 7540 HTTP/2 May 2015

END_STREAM flag causes the stream state to become "half-closed

(local)"; an endpoint receiving an END_STREAM flag causes the

stream state to become "half-closed (remote)".

Either endpoint can send a RST_STREAM frame from this state,

causing it to transition immediately to "closed".

half-closed (local):

A stream that is in the "half-closed (local)" state cannot be used

for sending frames other than WINDOW_UPDATE, PRIORITY, and

RST_STREAM.

A stream transitions from this state to "closed" when a frame that

contains an END_STREAM flag is received or when either peer sends

a RST_STREAM frame.

An endpoint can receive any type of frame in this state.

Providing flow-control credit using WINDOW_UPDATE frames is

necessary to continue receiving flow-controlled frames. In this

state, a receiver can ignore WINDOW_UPDATE frames, which might

arrive for a short period after a frame bearing the END_STREAM

flag is sent.

PRIORITY frames received in this state are used to reprioritize

streams that depend on the identified stream.

half-closed (remote):

A stream that is "half-closed (remote)" is no longer being used by

the peer to send frames. In this state, an endpoint is no longer

obligated to maintain a receiver flow-control window.

If an endpoint receives additional frames, other than

WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in

this state, it MUST respond with a stream error (Section 5.4.2) of

type STREAM_CLOSED.

A stream that is "half-closed (remote)" can be used by the

endpoint to send frames of any type. In this state, the endpoint

continues to observe advertised stream-level flow-control limits

(Section 5.2).

A stream can transition from this state to "closed" by sending a

frame that contains an END_STREAM flag or when either peer sends a

RST_STREAM frame.

Belshe, et al. Standards Track [Page 19]

RFC 7540 HTTP/2 May 2015

closed:

The "closed" state is the terminal state.

An endpoint MUST NOT send frames other than PRIORITY on a closed

stream. An endpoint that receives any frame other than PRIORITY

after receiving a RST_STREAM MUST treat that as a stream error

(Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint

that receives any frames after receiving a frame with the

END_STREAM flag set MUST treat that as a connection error

(Section 5.4.1) of type STREAM_CLOSED, unless the frame is

permitted as described below.

WINDOW_UPDATE or RST_STREAM frames can be received in this state

for a short period after a DATA or HEADERS frame containing an

END_STREAM flag is sent. Until the remote peer receives and

processes RST_STREAM or the frame bearing the END_STREAM flag, it

might send frames of these types. Endpoints MUST ignore

WINDOW_UPDATE or RST_STREAM frames received in this state, though

endpoints MAY choose to treat frames that arrive a significant

time after sending END_STREAM as a connection error

(Section 5.4.1) of type PROTOCOL_ERROR.

PRIORITY frames can be sent on closed streams to prioritize

streams that are dependent on the closed stream. Endpoints SHOULD

process PRIORITY frames, though they can be ignored if the stream

has been removed from the dependency tree (see Section 5.3.4).

If this state is reached as a result of sending a RST_STREAM

frame, the peer that receives the RST_STREAM might have already

sent -- or enqueued for sending -- frames on the stream that

cannot be withdrawn. An endpoint MUST ignore frames that it

receives on closed streams after it has sent a RST_STREAM frame.

An endpoint MAY choose to limit the period over which it ignores

frames and treat frames that arrive after this time as being in

error.

Flow-controlled frames (i.e., DATA) received after sending

RST_STREAM are counted toward the connection flow-control window.

Even though these frames might be ignored, because they are sent

before the sender receives the RST_STREAM, the sender will

consider the frames to count against the flow-control window.

An endpoint might receive a PUSH_PROMISE frame after it sends

RST_STREAM. PUSH_PROMISE causes a stream to become "reserved"

even if the associated stream has been reset. Therefore, a

RST_STREAM is needed to close an unwanted promised stream.

Belshe, et al. Standards Track [Page 20]

剩余95页未读，继续阅读

sinat_27376813

粉丝: 0
资源: 3

HTTP/2：优化协议，提升效率与并发——IETF新标准

RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1

解决http500错误解决http500错误解决http500错误解决http500错误

HTTP协议（HyperText Transfer Protocol，超文本传输协议）

计算机网络中英文对照

常用端口号和对应的协议

告诉我完整的常用服务端口

知道协议以及他们的端口

应用层常用的协议，以及对应的传输层端口号

IPV4 HTTP是指什么

最新资源