http2.0RFC文档 - CSDN文库

http2.0

需积分: 9 111 浏览量更新于2023-05-26 评论收藏 4.97MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

HTTPbis Working Group M. Belshe

Internet-Draft BitGo

Intended status: Standards Track R. Peon

Expires: December 1, 2015 Google, Inc

M. Thomson, Editor

Mozilla

May 30, 2015

Hypertext Transfer Protocol Version 2 (HTTP/2)

draft-ietf-httpbis-http2-latest

Abstract

This speciﬁcation describes an optimized expression of the semantics of the Hypertext Transfer

Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efﬁcient use of

network resources and a reduced perception of latency by introducing header ﬁeld compression and

allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of

representations from servers to clients.

This speciﬁcation is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's

existing semantics remain unchanged.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other

groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced,

or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as “work in progress”.

This Internet-Draft will expire on December 1, 2015.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review

these documents carefully, as they describe your rights and restrictions with respect to this document.

Code Components extracted from this document must include Simpliﬁed BSD License text as

described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described

in the Simpliﬁed BSD License.

1.Introduction

The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the way HTTP/1.1

uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative

overall effect on application performance today.

In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP

connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency

and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to

make many requests use multiple connections to a server in order to achieve concurrency and thereby

reduce latency.

Furthermore, HTTP header ﬁelds are often repetitive and verbose, causing unnecessary network trafﬁc

as well as causing the initial TCP [TCP] congestion window to quickly ﬁll. This can result in excessive

latency when multiple requests are made on a new TCP connection.

HTTP/2 addresses these issues by deﬁning an optimized mapping of HTTP's semantics to an

underlying connection. Speciﬁcally, it allows interleaving of request and response messages on the

same connection and uses an efﬁcient coding for HTTP header ﬁelds. It also allows prioritization of

requests, letting more important requests complete more quickly, further improving performance.

The resulting protocol is more friendly to the network because fewer TCP connections can be used in

comparison to HTTP/1.x. This means less competition with other ﬂows and longer-lived connections,

which in turn lead to better utilization of available network capacity.

Finally, HTTP/2 also enables more efﬁcient processing of messages through use of binary message

framing.

2.HTTP/2 Protocol Overview

HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core features

of HTTP/1.1 but aims to be more efﬁcient in several ways.

The basic protocol unit in HTTP/2 is a frame (Section4.1). Each frame type serves a different purpose.

For example, HEADERS and DATA frames form the basis of HTTP requests and responses

(Section8.1); other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are used

in support of other HTTP/2 features.

Multiplexing of requests is achieved by having each HTTP request/response exchange associated with

its own stream (Section5). Streams are largely independent of each other, so a blocked or stalled

request or response does not prevent progress on other streams.

Flow control and prioritization ensure that it is possible to efﬁciently use multiplexed streams. Flow

control (Section5.2) helps to ensure that only data that can be used by a receiver is transmitted.

Prioritization (Section5.3) ensures that limited resources can be directed to the most important streams

ﬁrst.

HTTP/2 adds a new interaction mode whereby a server can push responses to a client (Section8.2).

Server push allows a server to speculatively send data to a client that the server anticipates the client

will need, trading off some network usage against a potential latency gain. The server does this by

synthesizing a request, which it sends as a PUSH_PROMISE frame. The server is then able to send a

response to the synthetic request on a separate stream.

Because HTTP header ﬁelds used in a connection can contain large amounts of redundant data,

frames that contain them are compressed (Section4.3). This has especially advantageous impact upon

request sizes in the common case, allowing many requests to be compressed into one packet.

client:

connection:

connection error:

endpoint:

frame:

peer:

receiver:

sender:

server:

stream:

stream error:

2.1Document Organization

The HTTP/2 speciﬁcation is split into four parts:

Starting HTTP/2 (Section3) covers how an HTTP/2 connection is initiated.

The frame (Section4) and stream (Section5) layers describe the way HTTP/2 frames are

structured and formed into multiplexed streams.

Frame (Section6) and error (Section7) deﬁnitions include details of the frame and error types

used in HTTP/2.

HTTP mappings (Section8) and additional requirements (Section9) describe how HTTP

semantics are expressed using frames and streams.

While some of the frame and stream layer concepts are isolated from HTTP, this speciﬁcation does not

deﬁne a completely generic frame layer. The frame and stream layers are tailored to the needs of the

HTTP protocol and server push.

2.2Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD

NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as

described in RFC 2119 [RFC2119].

All numeric values are in network byte order. Values are unsigned unless otherwise indicated. Literal

values are provided in decimal or hexadecimal as appropriate. Hexadecimal literals are preﬁxed with

0x to distinguish them from decimal literals.

The following terms are used:

The endpoint that initiates an HTTP/2 connection. Clients send HTTP requests and receive

HTTP responses.

A transport-layer connection between two endpoints.

An error that affects the entire HTTP/2 connection.

Either the client or server of the connection.

The smallest unit of communication within an HTTP/2 connection, consisting of a header and a

variable-length sequence of octets structured according to the frame type.

An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote

to the primary subject of discussion.

An endpoint that is receiving frames.

An endpoint that is transmitting frames.

The endpoint that accepts an HTTP/2 connection. Servers receive HTTP requests and send

HTTP responses.

A bidirectional ﬂow of frames within the HTTP/2 connection.

An error on the individual HTTP/2 stream.

Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are deﬁned in Section 2.3 of

[RFC7230]. Intermediaries act as both client and server at different times.

The term "payload body" is deﬁned in Section 3.3 of [RFC7230].

3.Starting HTTP/2

An HTTP/2 connection is an application-layer protocol running on top of a TCP connection ([TCP]). The

client is the TCP connection initiator.

剩余59页未读，继续阅读

lixinyuan224

粉丝: 0
资源: 5

会员权益专享

http2.0 RFC文档

评论0

会员权益专享

最新资源

http2.0 RFC文档

评论0

HTTP2.0协议

HTTP_2基础教程.pdf

HTTP2基础教程.pdf

rfc 文档大全 下载

rfc文档1一3093

rdp8.0协议 rfc文档

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

lacp的rfc文档

关于udp协议的rfc文档

smb rfc 文档

XML标准和RFC官方文档

有详细介绍RFC6749规则的中文文档吗

ipv6 rfc相关文档

rfc9000文档下载

只有正式成为互联网标准，才能获得一个 RFC 编号，成为 RFC 文档 对吗

rfc viewer

tcp发展 rfc pdf

sap rfc 有开发文档吗或者博客链接

The valid characters are defined in RFC 7230 and RFC 3986 怎么解决

rfc 7230 and rfc 3986

会员权益专享

最新资源

rfc 文档大全下载

只有正式成为互联网标准，才能获得一个 RFC 编号，成为 RFC 文档对吗