HTTP2先驱：SPDY协议详解

spdy

HTTP2

需积分: 10 149 浏览量更新于2024-07-15 收藏 135KB PDF 举报

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

领优惠券(最高得80元）

"SPDY英文文档（HTTP2基础）" SPDY（Speedy）是由Google开发的一种网络协议，它被设计用于降低网页加载时间并增强网络通信的安全性。SPDY协议在HTTP2之前作为一项重要的过渡技术，其目标是通过压缩、多路复用和优先级设置来优化网络数据传输，从而提升网页的加载速度。尽管SPDY本身并未成为正式的互联网标准，但它对HTTP/2协议的发展起到了关键作用，HTTP/2最终采纳了许多SPDY的核心概念。 SPDY协议分为两个主要层次：底层的帧协议层和上层的应用协议层。底层帧协议层建立在可靠的传输协议之上，如TCP，用于实现多个并发流的高效、优先级和压缩数据通信。这一层的设计使得数据的传输更加灵活，可以有效地避免TCP连接的阻塞问题，减少延迟。上层的应用协议层则保留了与HTTP/1.1相似的语义，以确保与现有的HTTP应用服务器的兼容性。它引入了请求和响应的压缩，减少了HTTP头信息的大小，这对于那些包含大量HTTP头信息的交互特别有益。此外，SPDY协议还支持多路复用，允许在一个TCP连接上同时处理多个HTTP请求和响应，解决了HTTP/1.x中的“阻塞”问题，即一个慢速请求会阻塞整个连接上的其他请求。 SPDY协议中的优先级机制使得关键资源（如页面框架或脚本）可以优先传输，从而加快页面的初始渲染。这有助于提升用户体验，因为用户可以更快地看到页面内容的初步布局。虽然SPDY协议没有成为正式的互联网标准，但它的创新思路为HTTP/2的发展奠定了基础。HTTP/2最终被IETF采纳，并在2015年发布，其中包含了SPDY的许多特性，如二进制分帧、头部压缩（HPACK）、流控制和优先级。这些改进显著提升了Web性能，降低了页面加载时间，同时也降低了服务器和客户端之间的网络负载。 SPDY协议是网络优化领域的一次重要尝试，它展示了如何通过改进现有协议来解决Web性能问题。尽管SPDY已被HTTP/2所取代，但其设计理念和实现方式对现代互联网架构产生了深远影响。

资源详情

资源推荐

Internet-Draft SPDY Feb 2012

2.3.1. Stream frames

SPDY defines 3 control frames to manage the lifecycle of a stream:

SYN_STREAM - Open a new stream

SYN_REPLY - Remote acknowledgement of a new, open stream

RST_STREAM - Close a stream

2.3.2. Stream creation

A stream is created by sending a control frame with the type set to

SYN_STREAM (

Section 2.6.1). If the server is initiating the stream,

the Stream-ID must be even. If the client is initiating the stream,

the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs

from each side of the connection must increase monotonically as new

streams are created. E.g. Stream 2 may be created after stream 3,

but stream 7 must not be created after stream 9. Stream IDs do not

wrap: when a client or server cannot create a new stream id without

exceeding a 31 bit value, it MUST NOT create a new stream.

The stream-id MUST increase with each new stream. If an endpoint

receives a SYN_STREAM with a stream id which is less than any

previously received SYN_STREAM, it MUST issue a session error

(

Section 2.4.1) with the status PROTOCOL_ERROR.

It is a protocol error to send two SYN_STREAMs with the same

stream-id. If a recipient receives a second SYN_STREAM for the same

stream, it MUST issue a stream error (

Section 2.4.2) with the status

code PROTOCOL_ERROR.

Upon receipt of a SYN_STREAM, the recipient can reject the stream by

sending a stream error (

Section 2.4.2) with the error code

REFUSED_STREAM. Note, however, that the creating endpoint may have

already sent additional frames for that stream which cannot be

immediately stopped.

Once the stream is created, the creator may immediately send HEADERS

or DATA frames for that stream, without needing to wait for the

recipient to acknowledge.

2.3.2.1. Unidirectional streams

When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag

set, it creates a unidirectional stream which the creating endpoint

can use to send frames, but the receiving endpoint cannot. The

receiving endpoint is implicitly already in the half-closed

Belshe & Peon Expires August 4, 2012 [Page 9]

Internet-Draft SPDY Feb 2012

(

Section 2.3.6) state.

2.3.2.2. Bidirectional streams

SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are

bidirectional streams. Both endpoints can send data on a bi-

directional stream.

2.3.3. Stream priority

The creator of a stream assigns a priority for that stream. Priority

is represented as an integer from 0 to 7. 0 represents the highest

priority and 7 represents the lowest priority.

The sender and recipient SHOULD use best-effort to process streams in

the order of highest priority to lowest priority.

2.3.4. Stream headers

Streams carry optional sets of name/value pair headers which carry

metadata about the stream. After the stream has been created, and as

long as the sender is not closed (

Section 2.3.7) or half-closed

(

Section 2.3.6), each side may send HEADERS frame(s) containing the

header data. Header data can be sent in multiple HEADERS frames, and

HEADERS frames may be interleaved with data frames.

2.3.5. Stream data exchange

Once a stream is created, it can be used to send arbitrary amounts of

data. Generally this means that a series of data frames will be sent

on the stream until a frame containing the FLAG_FIN flag is set. The

FLAG_FIN can be set on a SYN_STREAM (

Section 2.6.1), SYN_REPLY

(

Section 2.6.2), HEADERS (Section 2.6.7) or a DATA (Section 2.2.2)

frame. Once the FLAG_FIN has been sent, the stream is considered to

be half-closed.

2.3.6. Stream half-close

When one side of the stream sends a frame with the FLAG_FIN flag set,

the stream is half-closed from that endpoint. The sender of the

FLAG_FIN MUST NOT send further frames on that stream. When both

sides have half-closed, the stream is closed.

If an endpoint receives a data frame after the stream is half-closed

from the sender (e.g. the endpoint has already received a prior frame

for the stream with the FIN flag set), it MUST send a RST_STREAM to

the sender with the status STREAM_ALREADY_CLOSED.

Belshe & Peon Expires August 4, 2012 [Page 10]

Internet-Draft SPDY Feb 2012

2.3.7. Stream close

There are 3 ways that streams can be terminated:

Normal termination: Normal stream termination occurs when both

sender and recipient have half-closed the stream by sending a

FLAG_FIN.

Abrupt termination: Either the client or server can send a

RST_STREAM control frame at any time. A RST_STREAM contains an

error code to indicate the reason for failure. When a RST_STREAM

is sent from the stream originator, it indicates a failure to

complete the stream and that no further data will be sent on the

stream. When a RST_STREAM is sent from the stream recipient, the

sender, upon receipt, should stop sending any data on the stream.

The stream recipient should be aware that there is a race between

data already in transit from the sender and the time the

RST_STREAM is received. See Stream Error Handling (

Section 2.4.2)

TCP connection teardown: If the TCP connection is torn down while

un-closed streams exist, then the endpoint must assume that the

stream was abnormally interrupted and may be incomplete.

If an endpoint receives a data frame after the stream is closed, it

must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.

2.4. Error Handling

The SPDY framing layer has only two types of errors, and they are

always handled consistently. Any reference in this specification to

"issue a session error" refers to

Section 2.4.1. Any reference to

"issue a stream error" refers to

Section 2.4.2.

2.4.1. Session Error Handling

A session error is any error which prevents further processing of the

framing layer or which corrupts the session compression state. When

a session error occurs, the endpoint encountering the error MUST

first send a GOAWAY (

Section 2.6.6) frame with the stream id of most

recently received stream from the remote endpoint, and the error code

for why the session is terminating. After sending the GOAWAY frame,

the endpoint MUST close the TCP connection.

Note that the session compression state is dependent upon both

endpoints always processing all compressed data. If an endpoint

partially processes a frame containing compressed data without

updating compression state properly, future control frames which use

compression will be always be errored. Implementations SHOULD always

Belshe & Peon Expires August 4, 2012 [Page 11]

剩余50页未读，继续阅读

loaderfj1

粉丝: 0
资源: 5

HTTP2先驱：SPDY协议详解

HTTP2中英对照版

SPDY协议文档 (英文)

nghttp-tools 有什么作用

wireshark http2

okhttp 发挥结果

谈一谈http各个版本

OkHttpClient 是什么

先进的数据传输协议有什么，优缺点

java Http 请求类

okhttp3.8.0-jdk1.6.jar

CVE-2021-28165

okhttp3.8.1的用法

okhttp-jvm与okhttp

android socket框架哪个好用

5、Android客户端访问网络发送HTTP请求可以使用OkHttp开源框架。

okhttp3 jar包

什么是HTTP2.0?

tomcat服务器优点

okhttp https

最新资源