HTTP/2协议详解与优化

需积分: 22 53 浏览量更新于2024-07-09 收藏 301KB PDF 举报

"HTTP2-rfc7540.pdf 是HTTP2的官方协议文档，由Internet Engineering Task Force (IETF)发布，主要作者包括M. Belshe、R. Peon和M. Thomson等。该文档详细阐述了HTTP版本2（HTTP/2）的优化表达，旨在提高网络资源的效率，减少延迟感知，并引入了头字段压缩和多路复用技术，同时服务器可以未经请求地向客户端推送内容。此规范是HTTP/1.1消息语法的替代方案，但不废弃HTTP/1.1的现有语义。" HTTP/2是互联网通信协议的重要升级，主要改进点包括： 1. **二进制分帧**：与HTTP/1.x的文本分帧不同，HTTP/2使用二进制格式进行数据传输，提高了解析效率，减少了错误的可能性。 2. **多路复用**：在单个TCP连接上可以并发处理多个HTTP请求和响应，解决了HTTP/1.1中的阻塞问题，显著提高了页面加载速度，减少了延迟。 3. **头部压缩**：使用HPACK算法对HTTP头部进行压缩，减少了头部数据的传输量，降低了网络带宽的消耗。 4. **服务器推送**（Server Push）：服务器可以预测客户端可能需要的资源并主动推送，减少了客户端的等待时间，提升了用户体验。 5. **优先级和依赖**：HTTP/2允许客户端和服务器指定请求和响应的优先级，确保关键资源优先处理，进一步优化了页面加载顺序。 6. **流控制**：通过流控制机制，服务器和客户端可以管理它们之间交换的数据流，避免了拥塞和过载问题。 7. **流量控制**：HTTP/2引入了更精细的流量控制策略，以适应不同的网络环境和条件，提高了网络资源的利用率。 8. **幂等性**：某些HTTP方法如PUT和DELETE在HTTP/2中被设计为幂等的，意味着多次执行同一操作会产生相同的结果，增强了系统的稳定性和可靠性。 9. **安全优先**：HTTP/2鼓励使用HTTPS，以提供更强的数据加密和身份验证能力，保障网络通信的安全性。 HTTP/2通过一系列创新设计，极大地提升了HTTP协议的性能和效率，降低了网络延迟，优化了用户在网页浏览和其他在线交互中的体验。作为Internet Standards Track文档，HTTP/2的实施和应用已成为现代互联网服务的标准配置。

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

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页未读，继续阅读

lvdy

粉丝: 1
资源: 16

HTTP/2协议详解与优化

http2基础文档

HTTP RFC文档

rfc2327_sdp.pdf

rfc3261中文版 pdf 下载

rfc全部文档离线下载rfc1-rfc8505

关于MIME和S-MIME的信息资源

rfc8446 中文 pdf

rfc2822 中文 pdf

confd rfc中文pdf

opus数据帧格式的参考资料有哪些

最新资源