forked from httpwg/http2-spec
-
Notifications
You must be signed in to change notification settings - Fork 273
/
draft-ietf-httpbis-http2-zh.xml
5271 lines (4538 loc) · 300 KB
/
draft-ietf-httpbis-http2-zh.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-httpbis-http2-latest"
x:maturity-level="proposed"
xmlns:x="http://purl.org/net/xml2rfc/ext">
<x:feedback template="mailto:[email protected]?subject={docname},%20%22{section}%22&body=<{ref}>:"/>
<front>
<title abbrev="HTTP/2">Hypertext Transfer Protocol version 2</title>
<author initials="M." surname="Belshe" fullname="Mike Belshe">
<organization>Twist</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="R." surname="Peon" fullname="Roberto Peon">
<organization>Google, Inc</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
<organization>Mozilla</organization>
<address>
<postal>
<street>Suite 300</street>
<street>650 Castro Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2014" />
<area>Applications</area>
<workgroup>HTTPbis</workgroup>
<keyword>HTTP</keyword>
<keyword>SPDY</keyword>
<keyword>Web</keyword>
<abstract>
<t>
This specification describes an optimized expression of the syntax of the Hypertext Transfer
Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced
perception of latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces unsolicited push of
representations from servers to clients.
本规范描述了一种优化的超文本传输协议(HTTP).HTTP/2通过引进首部字段压缩以及多路复用来更有效利用网络资源、减少感知延迟。另外同样介绍了服务器主动推送规范。
</t>
<t>
This document is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.
HTTP's existing semantics remain unchanged.
本文档保持对HTTP/1.1的后向兼容，HTTP的现有的语义保持不变。
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>
Discussion of this draft takes place on the HTTPBIS working group mailing list
([email protected]), which is archived at <eref
target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
该草案的HTTPBIS工作组的邮件组列表可以在此处找到<eref
target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
Working Group information can be found at <eref
target="http://tools.ietf.org/wg/httpbis/"/>; that specific to HTTP/2 are at <eref
target="http://http2.github.io/"/>.
</t>
<t>
The changes in this draft are summarized in <xref
target="change.log"/>.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the
HTTP/1.1 message format (<xref target="HTTP-p1" x:fmt="," x:rel="#http.message"/>) was
designed to be implemented with the tools at hand in the 1990s, not modern Web application
performance. As such it has several characteristics that have a negative overall effect on
application performance today.
超文本传输协议（HTTP）是一个非常成功的协议。 然而，HTTP/1.1 是针对90年代的情况而不是现代web应用的性能而设计。因此它对现代应用程序的性能产生负面影响。
</t>
<t>
In particular, HTTP/1.0 only allows one request to be outstanding at a time on a given
connection. HTTP/1.1 pipelining only partially addressed request concurrency and
suffers from head-of-line blocking. Therefore, clients that need to make many requests
typically use multiple connections to a server in order to reduce latency.
特别是，HTTP/1.0只允许一个请求建立在给定的连接上, HTTP/1.1管道只部分解决了请求并发和对头阻塞的问题.因此客户端需要通过多个请求多次请求服务器以减少延迟。
</t>
<t>
Furthermore, HTTP/1.1 header fields are often repetitive and verbose, which, in addition to
generating more or larger network packets, can cause the small initial TCP congestion window
to quickly fill. This can result in excessive latency when multiple requests are made on a
single new TCP connection.
此外，HTTP/1.1的报头字段经常重复和冗长，其中，为了产生更多或更大的网络数据包，可能会导致小的初始TCP拥塞窗口来快速填充。 当多个请求在一个新的TCP连接进行可能会导致过度的延迟。
</t>
<t>
This document addresses these issues by defining an optimized mapping of HTTP's semantics to
an underlying connection. Specifically, it allows interleaving of request and response
messages on the same connection and uses an efficient coding for HTTP header fields. It
also allows prioritization of requests, letting more important requests complete more
quickly, further improving performance.
该文通过定义一个基础连接的HTTP的语义优化的映射来解决这些问题。 具体地，它允许对请求和响应消息建立在同一连接，并使用高效率编码的HTTP报头字段。 它还允许请求的优先级，让更多的重要的要求更快速的完成，进一步提高了性能。
</t>
<t>
The resulting protocol is designed to be more friendly to the network, because fewer TCP
connections can be used in comparison to HTTP/1.x. This means less competition with other
flows, and longer-lived connections, which in turn leads to better utilization of available
network capacity.
最终协议被设计为对网络更友好，因为相对HTTP/1.x使用了更少的连接。 这意味着与其他流更少的竞争和更长时间的连接,从而更有效地利用可用的网络容量。
</t>
<t>
Finally, this encapsulation also enables more scalable processing of messages through use of
binary message framing.
最后，这种封装也通过使用二进制消息帧使信息处理更具扩展性。
</t>
</section>
<section anchor="Overview" title="HTTP/2 Protocol Overview">
<t>
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 efficient in several ways.
HTTP/2 提供了对HTTP语义的优化运输。HTTP/2支持所有HTTP／1.1的核心特征，并且在某些方面更高效。
</t>
<t>
The basic protocol unit in HTTP/2 is a <xref target="FrameHeader">frame</xref>. Each frame
has a different type and purpose. For example, <x:ref>HEADERS</x:ref> and
<x:ref>DATA</x:ref> frames form the basis of <xref target="HttpSequence">HTTP requests and
responses</xref>; other frame types like <x:ref>SETTINGS</x:ref>,
<x:ref>WINDOW_UPDATE</x:ref>, and <x:ref>PUSH_PROMISE</x:ref> are used in support of other
HTTP/2 features.
HTTP/2中基本的协议单位是<xref target="FrameHeader">帧</xref>。每个帧都有不同的类型和用途。例如，<x:ref>报头(HEADERS)</x:ref>和<x:ref>数据(DATA)</x:ref>帧组成了基本的<xref target="HttpSequence">HTTP 请求和响应</xref>；其他帧例如 <x:ref>设置(SETTINGS)</x:ref>,<x:ref>窗口更新(WINDOW_UPDATE)</x:ref>, 和<x:ref>推送承诺(PUSH_PROMISE)</x:ref> 是用来支持HTTP/2的其他功能。
</t>
<t>
Multiplexing of requests is achieved by having each HTTP request-response exchanged assigned
to a single <xref target="StreamsLayer">stream</xref>. Streams are largely independent of
each other, so a blocked or stalled request does not prevent progress on other requests.
请求多路复用是通过给每个HTTP请求响应分配在一个<xref target="StreamsLayer">流</xref>上实现的。流在很大程度上是相互独立的，因此一个请求上的阻塞或终止并不会影响其他请求的处理。
</t>
<t>
Flow control and prioritization ensure that it is possible to properly use multiplexed
streams. <xref target="FlowControl">Flow control</xref> helps to ensure that only data that
can be used by a receiver is transmitted. <xref
target="StreamPriority">Prioritization</xref> ensures that limited resources can be directed
to the most important requests first.
流量控制和优先级能确保正确使用复用流。<xref target="FlowControl">流量控制</xref>确保数据只可以被传播的接收者使用。<xref target="StreamPriority">优先级</xref> 能确保有限的资源能被首先传送。
</t>
<t>
HTTP/2 adds a new interaction mode, whereby a server can <xref target="PushResources">push
responses to a client</xref>. Server push allows a server to speculatively send a client
data 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 <x:ref>PUSH_PROMISE</x:ref> frame. The server is then able to send a response to
the synthetic request on an separate stream.
HTTP/2添加了一种新的交互模式，即服务器能<xref target="PushResources">推送消息给客户端</xref>。服务器推送允许服务端预测客户端需要来发送数据给客户端，交换网络使用来阻止潜在的延迟增长。服务器通过复用一个以<x:ref>PUSH_PROMISE</x:ref> 帧发送的请求来实现。然后服务端可以在一个单独的流里面发送响应给这个合成的请求。
</t>
<t>
Frames that contain HTTP header fields are <xref target="HeaderBlock">compressed</xref>.
HTTP requests can be highly redundant, so compression can reduce the size of requests and
responses significantly.
帧包含的HTTP报头字段是被<xref target="HeaderBlock">压缩的</xref>。HTTP请求可能是高度冗余的，因此压缩能显著见效请求和响应的大小。
</t>
<section title="Document Organization">
<t>
The HTTP/2 specification is split into four parts:
HTTP/2协议被分为以下两个部分：
<list style="symbols">
<t>
<xref target="starting">Starting HTTP/2</xref> covers how an HTTP/2 connection is
initiated.
<xref target="starting">启动HTTP/2</xref>包含了一个HTTP/2连接是如何初始化的。
</t>
<t>
The <xref target="FramingLayer">framing</xref> and <xref
target="StreamsLayer">streams</xref> layers describe the way HTTP/2 frames are
structured and formed into multiplexed streams.
<xref target="FramingLayer">帧</xref> 和 <xref
target="StreamsLayer">流</xref>层描述了 HTTP/2流是如何建立并形成复用流的。
</t>
<t>
<xref target="frame-types">Frame</xref> and <xref target="ErrorCodes">error</xref>
definitions include details of the frame and error types used in HTTP/2.
<xref target="frame-types">帧</xref> 和 <xref target="ErrorCodes">错误码</xref>
定义了HTTP/2中使用的流和错误类型的详细内容。
</t>
<t>
<xref target="HTTPLayer">HTTP mappings</xref> and <xref target="HttpExtra">additional
requirements</xref> describe how HTTP semantics are biao using frames and
streams.
<xref target="HTTPLayer">HTTP寻址</xref> 和 <xref target="HttpExtra">拓展需求</xref> 描述了HTTP语义化是如何由帧和流表达的。
</t>
</list>
</t>
<t>
While some of the frame and stream layer concepts are isolated from HTTP, the intent is
not to define a completely generic framing layer. The framing and streams layers are
tailored to the needs of the HTTP protocol and server push.
虽然一些帧和流层的概念是与HTTP隔离的，它的意图并不是定义一个完全通用的帧层。这些帧和流层是为了HTTP协议和服务端推送的需求定制的。
</t>
</section>
<section title="Conventions and Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
文档中出现的关键字“必须”，“必须不”，“要求”，“应”，“不应”，“应该”，“不应该”，“建议”，“或许”及“可选”的可在此找到解释<xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
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 prefixed with <spanx style="verb">0x</spanx> to distinguish them
from decimal literals.
所有的数值都是按网络字节顺序。值是无符号的除非有另外说明。按情况提供十进制或十六进制的文本值。十六进制以前缀<spanx style="verb">0x</spanx>来区分。
</t>
<t>
The following terms are used:
文中术语包括：
<list style="hanging">
<t hangText="client:">
The endpoint initiating the HTTP/2 connection.
客户端：发起HTTP/2请求的端点
</t>
<t hangText="connection:">
A transport-level connection between two endpoints.
连接：在两个端点之间的传输层级别的连接。
</t>
<t hangText="connection error:">
An error that affects the entire HTTP/2 connection.
连接错误：HTTP/2连接整个过程中发生的错误
</t>
<t hangText="endpoint:">
Either the client or server of the connection.
端点：连接的客户端或服务器。
</t>
<t hangText="frame:">
The smallest unit of communication within an HTTP/2 connection, consisting of a header
and a variable-length sequence of bytes structured according to the frame type.
帧：HTTP/2.0通信连接中的最小单元，包括根据帧类型结构的字节的报头和可变长度的序列。
</t>
<t hangText="peer:">
An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint
that is remote to the primary subject of discussion.
对等端：一个端点。当讨论特定的端点时，“对等端”指的是讨论的主题的远程端点
</t>
<t hangText="receiver:">
An endpoint that is receiving frames.
接收端：正在接收帧的端点。
</t>
<t hangText="sender:">
An endpoint that is transmitting frames.
发送端：正在传输帧的端点
</t>
<t hangText="server:">
The endpoint which did not initiate the HTTP/2 connection.
服务端：不是启动HTTP/2连接的端点。
</t>
<t hangText="stream:">
A bi-directional flow of frames across a virtual channel within the HTTP/2 connection.
流：一个双向字节帧流穿过HTTP/2连接中的虚拟通道。
</t>
<t hangText="stream error:">
An error on the individual HTTP/2 stream.
流错误：一个HTTP/2流中错误
</t>
</list>
</t>
</section>
</section>
<section anchor="starting" title="Starting HTTP/2">
<t>
An HTTP/2 connection is an application level protocol running on top of a TCP connection
(<xref target="TCP"/>). The client is the TCP connection initiator.
一个HTTP/2连接是运行在TCP连接(<xref target="TCP"/>)上的应用层协议。客户端是TCP连接发起者。
</t>
<t>
HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. HTTP/2 shares the same
default port numbers: 80 for "http" URIs and 443 for "https" URIs. As a result,
implementations processing requests for target resource URIs like <spanx
style="verb">http://example.org/foo</spanx> or <spanx
style="verb">https://example.com/bar</spanx> are required to first discover whether the
upstream server (the immediate peer to which the client wishes to establish a connection)
supports HTTP/2.
HTTP/2使用与HTTP/1.1相同的"http" and "https" 资源标识符(URI)。使用相同的默认端口："http"80端口及“https”443端口。因此，实现对例如<spanx
style="verb">http://example.org/foo</spanx>或<spanx
style="verb">https://example.com/bar</spanx>目标资源的URI请求处理需要首先确定上游服务端(当前客户端希望建立连接的对等端)是否支持HTTP/2。
</t>
<t>
The means by which support for HTTP/2 is determined is different for "http" and "https"
URIs. Discovery for "http" URIs is described in <xref target="discover-http"/>. Discovery
for "https" URIs is described in <xref target="discover-https"/>.
检测“http”及“https”的URIs是否支持HTTP/2的方法是不一样的。检测"http" URIs在<xref target="discover-http"/>中描述。检测"https" URIs在<xref target="discover-https"/>中描述。
</t>
<section anchor="versioning" title="HTTP/2 Version Identification">
<t>
The protocol defined in this document is identified using the string "h2". This
identification is used in the HTTP/1.1 Upgrade header field, in the <xref
target="TLSALPN">TLS application layer protocol negotiation extension</xref> field, and
other places where protocol identification is required. When serialised into an ALPN
protocol identifier (which is a sequence of octets), the "h2" string is encoded using
<xref target="UTF-8">UTF-8</xref>.
文档中定义的协议用字符"h2"标记。这种方式用在HTTP/1.1的升级字段、<xref
target="TLSALPN">TLS 应用层协议协商扩展</xref>字段以及其他需要定义协议的地方。当在定义ALPN协议(序列化的字节)中序列化时，"h2"字符使用<xref target="UTF-8">UTF-8</xref>编码。
</t>
<t>
Negotiating "h2" implies the use of the transport, security, framing and message
semantics described in this document.
协定"h2"用于文档中的传输、安全、帧及语义化消息部分。
</t>
<t>
<cref>Editor's Note: please remove the remainder of this section prior to the publication
of a final version of this document.</cref>
</t>
<t>
Only implementations of the final, published RFC can identify themselves as "h2".
Until such an RFC exists, implementations MUST NOT identify themselves using "h2".
</t>
<t>
Examples and text throughout the rest of this document use "h2" as a matter of
editorial convenience only. Implementations of draft versions MUST NOT identify using
this string.
</t>
<t>
Implementations of draft versions of the protocol MUST add the string "-" and the
corresponding draft number to the identifier. For example, draft-ietf-httpbis-http2-09
is identified using the string "h2-09".
</t>
<t>
Non-compatible experiments that are based on these draft versions MUST append the string
"-" and an experiment name to the identifier. For example, an experimental implementation
of packet mood-based encoding based on draft-ietf-httpbis-http2-09 might identify itself
as "h2-09-emo". Note that any label MUST conform to the "token" syntax defined in
<xref target="HTTP-p1" x:fmt="of" x:rel="#field.components"/>. Experimenters are
encouraged to coordinate their experiments on the [email protected] mailing list.
</t>
</section>
<section anchor="discover-http" title="Starting HTTP/2 for "http" URIs">
<t>
A client that makes a request to an "http" URI without prior knowledge about support for
HTTP/2 uses the HTTP Upgrade mechanism (<xref target="HTTP-p1" x:fmt="of"
x:rel="#header.upgrade"/>). The client makes an HTTP/1.1 request that includes an Upgrade
header field identifying HTTP/2 with the h2 token. The HTTP/1.1 request MUST include
exactly one <xref target="Http2SettingsHeader">HTTP2-Settings</xref> header field.
客户端发起“http” URI请求不支持HTTP/2的使用HTTP升级机制(<xref target="HTTP-p1" x:fmt="of"
x:rel="#header.upgrade"/>)。客户端发起一个http1.1请求，其中包含识别HTTP/2的升级头部字段与h2令牌。HTTP/1.1必须包含一个确切的<xref target="Http2SettingsHeader">HTTP2-Settings</xref>中的头部字段。
</t>
<figure>
<preamble>For example: 例如：</preamble>
<artwork type="message/http; msgtype="request"" x:indent-with=" "><![CDATA[
GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
]]></artwork>
</figure>
<t>
Requests that contain an entity body MUST be sent in their entirety before the client can
send HTTP/2 frames. This means that a large request entity can block the use of the
connection until it is completely sent.
包含主体内容的请求必须在客户端能发送HTTP/2帧前全部发送。这意味着一个大的请求实例能阻塞连接的使用直到其全部被发送。
</t>
<t>
If concurrency of an initial request with subsequent requests is important, a small
request can be used to perform the upgrade to HTTP/2, at the cost of an additional
round-trip.
如果一个请求的并发后续请求是重要的，那么一个小的请求可以用来执行升级到HTTP/2,消耗一个额外的往返成本。
</t>
<t>
A server that does not support HTTP/2 can respond to the request as though the Upgrade
header field were absent:
不支持HTTP/2的服务端对请求返回一个不包含升级的头部字段的响应：
</t>
<figure>
<artwork type="message/http; msgtype="response"" x:indent-with=" ">
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
...
</artwork>
</figure>
<t>
A server that supports HTTP/2 can accept the upgrade with a 101 (Switching Protocols)
response. After the empty line that terminates the 101 response, the server can begin
sending HTTP/2 frames. These frames MUST include a response to the request that initiated
the Upgrade.
支持HTTP/2的服务端可以返回一个101(转换协议)响应来接受升级请求。在101空内容响应终止后，服务端可以开始发送HTTP/2帧。这些帧必须包含一个标示升级的响应。
</t>
<figure>
<artwork type="message/http; msgtype="response"" x:indent-with=" ">
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2
[ HTTP/2 connection ...
</artwork>
</figure>
<t>
The first HTTP/2 frame sent by the server is a <x:ref>SETTINGS</x:ref> frame (<xref
target="SETTINGS"/>). Upon receiving the 101 response, the client sends a <xref
target="ConnectionHeader">connection preface</xref>, which includes a
<x:ref>SETTINGS</x:ref> frame.
第一个被服务端发送的HTTP/2帧是一个<x:ref>设置(SETTINGS)</x:ref>帧(<xref target="SETTINGS"/>)。在收到101响应后，客户端发送一个包含<x:ref>设置(SETTINGS)</x:ref>帧的连接序言。
</t>
<t>
The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is
assigned the highest possible priority. Stream 1 is implicitly half closed from the
client toward the server, since the request is completed as an HTTP/1.1 request. After
commencing the HTTP/2 connection, stream 1 is used for the response.
HTTP/1.1最初用来升级的请求用1来标示流并将赋予最高优先级。流1对发送到服务端的客户端是隐式半封闭的，因为这个请求已经以一个HTTP/1.1请求完成了。HTTP/2连接开始后,流1在响应中使用。
</t>
<section anchor="Http2SettingsHeader" title="HTTP2-Settings Header Field">
<t>
A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one <spanx
style="verb">HTTP2-Settings</spanx> header field. The <spanx
style="verb">HTTP2-Settings</spanx> header field is a hop-by-hop header field that
includes parameters that govern the HTTP/2 connection, provided in anticipation of the
server accepting the request to upgrade. A server MUST reject an attempt to upgrade if
this header field is not present.
从HTTP/1.1升级到HTTP/2的请求必须包含一个确切的<spanx style="verb">HTTP2-Settings</spanx>头部字段。这个<spanx
style="verb">HTTP2-Settings</spanx>头部字段是一个包含管理HTTP/2连接参数的逐跳头部字段。如果没有此头部字段，服务端必须拒绝升级。
</t>
<figure>
<artwork type="abnf" x:indent-with=" "><![CDATA[
HTTP2-Settings = token68
]]></artwork>
</figure>
<t>
The content of the <spanx style="verb">HTTP2-Settings</spanx> header field is the
payload of a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>), encoded as a
base64url string (that is, the URL- and filename-safe Base64 encoding described in <xref
target="RFC4648" x:fmt="of" x:sec="5"/>, with any trailing '=' characters omitted). The
<xref target="RFC5234">ABNF</xref> production for <spanx style="verb">token68</spanx> is
defined in <xref target="HTTP-p7" x:fmt="of" x:rel="#challenge.and.response"/>.
这个<spanx style="verb">HTTP2-Settings</spanx>头部字段的内容是<x:ref>设置(SETTINGS)</x:ref>帧的有效载体，使用base64url字符编码(URL及文件名安全的Base64编码，编码描述在<xref target="RFC4648" x:fmt="of" x:sec="5"/>中)。
</t>
<t>
The client MUST include values for the following
<xref target="SettingFormat">SETTINGS parameters</xref>:
客户端必须包含以下<xref target="SettingFormat">设置(SETTINGS) 参数</xref>：
<list style="symbols">
<t><x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref></t>
<t><x:ref>最大连接数设置</x:ref></t>
<t><x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref></t>
<t><x:ref>初始化窗口大小设置</x:ref></t>
</list>
</t>
<t>
As a hop-by-hop header field, the <spanx style="verb">Connection</spanx> header field
MUST include a value of <spanx style="verb">HTTP2-Settings</spanx> in addition to <spanx
style="verb">Upgrade</spanx> when upgrading to HTTP/2.
作为一个逐跳的报文头部字段，当升级到HTTP/2时，此<spanx style="verb">连接</spanx> 头部字段必须包含一个<spanx style="verb">HTTP2设置(HTTP2-Settings)</spanx>的值。
</t>
<t>
A server decodes and interprets these values as it would any other
<x:ref>SETTINGS</x:ref> frame. <xref target="SettingsSync">Acknowledgement of the
SETTINGS parameters</xref> is not necessary, since a 101 response serves as implicit
acknowledgment. Providing these values in the Upgrade request ensures that the protocol
does not require default values for the above SETTINGS parameters, and gives a client an
opportunity to provide other parameters prior to receiving any frames from the server.
服务端就像对任何其他 <x:ref>设置(SETTINGS</x:ref>帧一样对这些值进行解码。因为101响应的隐式声明，对这些<xref target="SettingsSync">设置参数的确认</xref>不是必须的。这些升级请求中的值使得协议不需要上述设置参数的默认值，同时使客户端有机会提供其他优先参数来从服务端获取任何帧。
</t>
</section>
</section>
<section anchor="discover-https" title="Starting HTTP/2 for "https" URIs">
<t>
A client that makes a request to an "https" URI without prior knowledge about support for
HTTP/2 uses <xref target="TLS12">TLS</xref> with the <xref target="TLSALPN">application
layer protocol negotiation extension</xref>.
客户端发起“https”的URI请求无法预知服务端是否支持HTTP/2的使用 <xref target="TLS12">TLS</xref>与<xref target="TLSALPN">应用层协议协商扩展</xref>。
</t>
<t>
Once TLS negotiation is complete, both the client and the server send a <xref
target="ConnectionHeader">connection preface</xref>.
TSL协议一旦完成，客户端和服务端都可以发送<xref target="ConnectionHeader">连接序言</xref>。
</t>
</section>
<section anchor="known-http" title="Starting HTTP/2 with Prior Knowledge">
<t>
A client can learn that a particular server supports HTTP/2 by other means. For example,
<xref target="AltSvc"/> describes a mechanism for advertising this capability in an HTTP
header field. A client MAY immediately send HTTP/2 frames to a server that is known to
support HTTP/2, after the <xref target="ConnectionHeader">connection preface</xref>. A
server can identify such a connection by the use of the "PRI" method in the connection
preface. This only affects the resolution of "http" URIs; servers supporting HTTP/2 are
required to support <xref target="TLSALPN">protocol negotiation in TLS</xref> for "https"
URIs.
客户端可以通过其他方式判断服务端是否支持HTTP/2。例如， <xref target="AltSvc"/>定义一种机制让HTTP头字段进行广播。客户端可以对支持HTTP/2的服务端在<xref target="ConnectionHeader">连接序言</xref>之后立即发送HTTP/2帧。服务端可以通过连接序言中的“PRI”方法来区分这种连接。这种对"http"URI改变的唯一影响是，支持HTTP/2的服务端对“https”URI需要支持<xref target="TLSALPN">TLS中的协商扩展</xref>。
</t>
<t>
Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2
for future connections. It is possible for server configurations to change or for
configurations to differ between instances in clustered server. Interception proxies
(a.k.a. "transparent" proxies) are another source of variability.
对HTTP/2之前的支持并不是强烈信号表明一个给定的服务器会在以后的连接中支持HTTP/2。服务器配置有可能改变或者集群中不同服务器配置有差异。拦截代理(又叫“透明”代理)是另一个可能得原因。
</t>
</section>
<section anchor="ConnectionHeader" title="HTTP/2 Connection Preface">
<t>
Upon establishment of a TCP connection and determination that HTTP/2 will be used by both
peers, each endpoint MUST send a connection preface as a final confirmation and to
establish the initial SETTINGS parameters for the HTTP/2 connection.
在建立TCP连接并且检测到HTTP/2会被各个对等端使用后，每个端点必须发送一个连接序言最终确认和作为建立HTTP/2连接的初始设置参数。
</t>
<t>
The client connection preface starts with a sequence of 24 octets, which in hex notation
are:
客户端连接序言以24个字节的序列开始，以十六进制表示是：
</t>
<figure>
<artwork type="inline" x:indent-with=" "><![CDATA[
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
]]></artwork>
</figure>
<t>
(the string <spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>). This sequence
is followed by a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>). The client
sends the client connection preface immediately upon receipt of a 101 Switching Protocols
response (indicating a successful upgrade), or as the first application data octets of a
TLS connection. If starting an HTTP/2 connection with prior knowledge of server support
for the protocol, the client connection preface is sent upon connection establishment.
(字符串<spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>)。这个序列后跟着一个<x:ref>设置</x:ref>帧(<xref target="SETTINGS"/>)。客户端在收到101转换协议响应(升级成功指示)后马上发送客户端连接序言，或者作为TLS连接的第一个应用数据字节。如果在对服务器支持HTTP/2具有先验知识的情况下启动HTTP/2连接，客户端连接序言在连接建立后就发送。
</t>
<t>
<list>
<t>
The client connection preface is selected so that a large proportion of HTTP/1.1 or
HTTP/1.0 servers and intermediaries do not attempt to process further frames. Note
that this does not address the concerns raised in <xref target="TALKING"/>.
客户端连接序言是这样选择的：大部分的HTTP/1.1或者HTTP/1.0服务端以及中介者不试图进一步处理帧。注意这并不能解决<xref target="TALKING"/>中提到的问题。
</t>
</list>
</t>
<t>
The server connection preface consists of just a <x:ref>SETTINGS</x:ref> frame (<xref
target="SETTINGS"/>) that MUST be the first frame the server sends in the HTTP/2
connection.
服务端连接序言仅包含一个必须在HTTP/2连接中首个发送的<x:ref>设置(SETTINGS)</x:ref> 帧 (<xref target="SETTINGS"/>)。
</t>
<t>
To avoid unnecessary latency, clients are permitted to send additional frames to the
server immediately after sending the client connection preface, without waiting to receive
the server connection preface. It is important to note, however, that the server
connection preface <x:ref>SETTINGS</x:ref> frame might include parameters that necessarily
alter how a client is expected to communicate with the server. Upon receiving the
<x:ref>SETTINGS</x:ref> frame, the client is expected to honor any parameters established.
为了避免不必要的延迟，允许客户端在发送客户端连接序言之后立即发送其他额外的帧，不需要等待收到服务端连接序言。不过需要注意的是，服务端连接序言<x:ref>设置(SETTINGS)</x:ref>帧可能包含一些关于期望客户端如何与服务端通信的所必须修改的参数。在收到这些<x:ref>设置(SETTINGS)</x:ref>帧之后，客户端应当遵守任何建立的参数。
</t>
<t>
Clients and servers MUST terminate the TCP connection if either peer does not begin with a
valid connection preface. A <x:ref>GOAWAY</x:ref> frame (<xref target="GOAWAY"/>) MAY be
omitted if it is clear that the peer is not using HTTP/2.
任意一个端点没有以一个有效的连接序言开始，客户端以及服务端必须终止TCP连接。如果端点并没有使用HTTP/2此时<x:ref>超时GOAWAY</x:ref> 帧可能可以省略。
</t>
</section>
</section>
<section anchor="FramingLayer" title="HTTP Frames">
<t>
Once the HTTP/2 connection is established, endpoints can begin exchanging frames.
HTTP/2连接一旦建立，端点之间可以马上交换数据帧。
</t>
<section anchor="FrameHeader" title="Frame Format">
<t>
All frames begin with an 8-octet header followed by a payload of between 0 and 16,383
octets.
所有的帧以8字节的头部开始并且跟着0-16,383长度的主体。
</t>
<figure title="Frame Header">
<artwork type="inline"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | Length (14) | Type (8) | Flags (8) |
+-+-+-----------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+-+-------------------------------------------------------------+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
The fields of the frame header are defined as:
帧头部字段定义是：
<list style="hanging">
<x:lt hangText="R:">
<t>
A reserved 2-bit field. The semantics of these bits are undefined and the bits MUST
remain unset (0) when sending and MUST be ignored when receiving.
保留的2字节字段。这些字节的语义是未定义的，并且在发送的时候必须保留未设置(0)，在接受的时候必须被忽略。
</t>
</x:lt>
<x:lt hangText="Length:">
<t>
The length of the frame payload expressed as an unsigned 14-bit integer. The 8 octets
of the frame header are not included in this value.
以14字节无符号整数的帧主体的长度。8字节长度的帧头部信息不计算在此内。
</t>
</x:lt>
<x:lt hangText="Type:">
<t>
The 8-bit type of the frame. The frame type determines how the remainder of the
frame header and payload are interpreted. Implementations MUST treat the receipt of
an unknown frame type (any frame types not defined in this document) as a <xref
target="ConnectionErrorHandler">connection error</xref> of type
<x:ref>PROTOCOL_ERROR</x:ref>.
帧的8字节类型。帧类型定义了剩余的帧报头和帧主体将如何被解释。具体实现必须处理收到未知帧类型(任何未在文档中定义的帧)时作为 <xref target="ConnectionErrorHandler">连接错误</xref>中的
<x:ref>类型协议错误PROTOCOL_ERROR</x:ref>。
</t>
</x:lt>
<x:lt hangText="Flags:">
<t>
An 8-bit field reserved for frame-type specific boolean flags.
为帧类型保留的8字节字段有具体的布尔标识。
</t>
<t>
Flags are assigned semantics specific to the indicated frame type.
Flags that have no defined semantics for a particular frame type
MUST be ignored, and MUST be left unset (0) when sending.
标识针对确定的帧类型赋予特定的语义。确定帧类型定义语义以外的标示必须被忽略，并且必须在发送的时候保留未设置(0)。
</t>
</x:lt>
<x:lt hangText="R:">
<t>
A reserved 1-bit field. The semantics of this bit are undefined and the bit MUST
remain unset (0) when sending and MUST be ignored when receiving.
1字节的保留字段。这个字段的语义未设置并且必须在发送的时候保持未设置(0),在接受的时候必须被忽略。
</t>
</x:lt>
<x:lt hangText="Stream Identifier:">
<t>
A 31-bit stream identifier (see <xref target="StreamIdentifiers"/>). The value 0 is
reserved for frames that are associated with the connection as a whole as opposed to
an individual stream.
31字节的流标识符(见<xref target="StreamIdentifiers"/>)。0是保留的，标明帧是与连接相关作为一个整体而不是一个单独的流。
</t>
</x:lt>
</list>
</t>
<t>
The structure and content of the frame payload is dependent entirely on the frame type.
帧主体的结构和内容完全取决于帧类型。
</t>
</section>
<section anchor="FrameSize" title="Frame Size">
<t>
The maximum size of a frame payload varies by frame type. The absolute maximum size of a
frame payload is 2<x:sup>14</x:sup>-1 (16,383) octets, meaning that the maximum frame
size is 16,391 octets. All implementations SHOULD be capable of receiving and minimally
processing frames up to this maximum size.
帧主体的最大长度限制因不同的帧类型而不同。最大帧主体的绝对长度是2<x:sup>14</x:sup>-1 (16,383)字节，表示最大的帧长度是16,391字节。所有的实现应当具备接收和处理此最大长度帧的能力。
</t>
<t>
Certain frame types, such as <x:ref>PING</x:ref> (see <xref target="PING"/>), impose
additional limits on the amount of payload data allowed. Likewise, additional size limits
can be set by specific application uses (see <xref target="HttpExtra" />).
某些帧类型，例如<x:ref>PING</x:ref>(见 <xref target="PING"/>)，对主体数据大小有额外的限制。同样的，一些特定的应用也可能使用额外的大小限制(见 <xref target="HttpExtra" />)。
</t>
<t>
If a frame size exceeds any defined limit, or is too small to contain mandatory frame
data, the endpoint MUST send a <x:ref>FRAME_SIZE_ERROR</x:ref> error. A frame size error
in a frame that could alter the state of the entire connection MUST be treated as a <xref
target="ConnectionErrorHandler">connection error</xref>; this includes any frame carrying
a <xref target="HeaderBlock">header block</xref> (that is, <x:ref>HEADERS</x:ref>,
<x:ref>PUSH_PROMISE</x:ref>, and <x:ref>CONTINUATION</x:ref>), <x:ref>SETTINGS</x:ref>,
and any <x:ref>WINDOW_UPDATE</x:ref> frame with a stream identifier of 0.
如果一个帧大小超过任何设定的限制，或者太小无法包含强制的帧数据，这个端点必须发送一个<x:ref>帧大小错误FRAME_SIZE_ERROR</x:ref>。如果帧大小错误可能修改整个连接状态，必须作为一个<xref
target="ConnectionErrorHandler">连接错误</xref>处理；这包括与0流一起的携带<xref target="HeaderBlock">头部块</xref>(即<x:ref>报文头HEADERS</x:ref>，<x:ref>推送许可PUSH_PROMISE</x:ref>和<x:ref>延续CONTINUATION</x:ref>)、<x:ref>设置SETTINGS</x:ref>以及任何<x:ref>窗口更新WINDOW_UPDATE</x:ref>的帧。
</t>
</section>
<section anchor="HeaderBlock" title="Header Compression and Decompression">
<t>
A header field in HTTP/2 is a name-value pair with one or more associated values. They are
used within HTTP request and response messages as well as server push operations (see
<xref target="PushResources" />).
HTTP/2报文头部字段是包含一个或多个相关意义的键值对。他们在HTTP请求响应消息及服务器推送操作(见<xref target="PushResources" />)中使用。
</t>
<t>
Header sets are collections of zero or more header fields. When transmitted over a
connection, a header set is serialized into a header block using <xref
target="COMPRESSION">HTTP Header Compression</xref>. The serialized header block is then
divided into one or more octet sequences, called header block fragments, and transmitted
within the payload of <xref target="HEADERS">HEADERS</xref>, <xref
target="PUSH_PROMISE">PUSH_PROMISE</xref> or <xref
target="CONTINUATION">CONTINUATION</xref> frames.
报头集合是0个或多个报头字段的集合。当传输一个连接的时候，报头集合将使用<xref target="COMPRESSION">HTTP头部压缩</xref>序列化到报文头部块中。序列化的报头块被分割成一个或多个的字节序列，称为报头分区，并在<xref target="HEADERS">报头HEADERS</xref>、<xref target="PUSH_PROMISE">推送约定PUSH_PROMISE</xref>及<xref
target="CONTINUATION">延续CONTINUATION</xref>的载体中传送，
</t>
<t>
HTTP Header Compression does not preserve the relative ordering of header fields. Header
fields with multiple values are encoded into a single header field using a special
delimiter; see <xref target="HeaderOrdering"/>.
HTTP报文头压缩并不保留报头字段的相关顺序。通用多个值的报头字段使用特定的分割器被编码分割到一个单独的报头区域；见<xref target="HeaderOrdering"/>。
</t>
<t>
The <xref target="COOKIE">Cookie header field</xref> is treated specially by the HTTP
mapping; see <xref target="CompressCookie"/>.
报文头<xref target="COOKIE">Cookie字段</xref>被通过HTTP映射特殊处理；见<xref target="CompressCookie"/>。
</t>
<t>
A receiving endpoint reassembles the header block by concatenating its fragments, then
decompresses the block to reconstruct the header set.
接收端点连接报头区块重新组装，并且解压缩区块后重建报头集合。
</t>
<t>
A complete header block consists of either:
一个完整的报头区块可以包含：
<list style="symbols">
<t>
a single <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame,
with the END_HEADERS flag set, or
一个包含头部终止标记集合的单独的<x:ref>报头HEADERS</x:ref> 或 <x:ref>推送约定PUSH_PROMISE</x:ref>帧，或者
</t>
<t>
a <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame with the END_HEADERS
flag cleared and one or more <x:ref>CONTINUATION</x:ref> frames,
where the last <x:ref>CONTINUATION</x:ref> frame has the END_HEADERS flag set.
一个头部终止标记被清除的<x:ref>报头HEADERS</x:ref> 或 <x:ref>推送约定PUSH_PROMISE</x:ref>帧以及一个或多个<x:ref>延续CONTINUATION</x:ref>帧，最后一个<x:ref>延续CONTINUATION</x:ref>帧拥有头部终止标记设置。
</t>
</list>
</t>
<t>
Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved
frames of any other type or from any other stream. The last frame in a sequence of
<x:ref>HEADERS</x:ref> or <x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS
flag set. The last frame in a sequence of <x:ref>PUSH_PROMISE</x:ref> or
<x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS flag set.
报头区块必须作为一个连续的帧序列传输，没有任何类型或任何其他流的交错帧。一个<x:ref>报头HEADERS</x:ref>或者<x:ref>延续CONTINUATION</x:ref>帧序列的最后一帧必须有头部终止标记设置。<x:ref>推送约定PUSH_PROMISE</x:ref>或者<x:ref>延续CONTINUATION</x:ref>帧序列的最后一帧必须具有头部终止标记设置。
</t>
<t>
Header block fragments can only be sent as the payload of <x:ref>HEADERS</x:ref>,
<x:ref>PUSH_PROMISE</x:ref> or <x:ref>CONTINUATION</x:ref> frames, because these frames
carry data that can modify the compression context maintained by a receiver. An endpoint
receiving <x:ref>HEADERS</x:ref>, <x:ref>PUSH_PROMISE</x:ref> or
<x:ref>CONTINUATION</x:ref> frames MUST reassemble header blocks and perform decompression
even if the frames are to be discarded. A receiver MUST terminate the connection with a
<xref target="ConnectionErrorHandler">connection error</xref> of type
<x:ref>COMPRESSION_ERROR</x:ref> if it does not decompress a header block.
报头区块必须被<x:ref>报头HEADERS</x:ref>、<x:ref>推送约定PUSH_PROMISE</x:ref>或<x:ref>延续CONTINUATION</x:ref>的有效载体发送，因为这些帧中携带了能被接收端修改的压缩上下文数据。端点在接收<x:ref>报头HEADERS</x:ref>、<x:ref>推送约定PUSH_PROMISE</x:ref>或<x:ref>延续CONTINUATION</x:ref>帧时必须重新组装报头区块并且执行解压缩，即便这些帧将被废弃。如何不能重建头部区间，接收端必须终止连接并报<x:ref>解压缩错误COMPRESSION_ERROR</x:ref>的<xref target="ConnectionErrorHandler">连接错误connection error</xref>。
</t>
</section>
</section>
<section anchor="StreamsLayer" title="Streams and Multiplexing">
<t>
A "stream" is an independent, bi-directional sequence of <x:ref>HEADERS</x:ref> and
<x:ref>DATA</x:ref> frames exchanged between the client and server within an HTTP/2
connection. Streams have several important characteristics:
流是一个独立的，客户端和服务端在HTTP/2连接下交换<x:ref>报头HEADERS</x:ref>和 <x:ref>数据DATA</x:ref>帧的双向序列。
<list style="symbols">
<t>
A single HTTP/2 connection can contain multiple concurrently open streams, with either
endpoint interleaving frames from multiple streams.
一个单独的HTTP/2连接能够保护多个同时打开的流，各个端点间从多个流中交错帧。
</t>
<t>
Streams can be established and used unilaterally or shared by either the client or
server.
流可以被被客户端或者服务端单方面建立使用或分享。
</t>
<t>
Streams can be closed by either endpoint.
流可以被任何一个终端关闭。
</t>
<t>
The order in which frames are sent within a stream is significant. Recipients process
frames in the order they are received.
在流内发送帧的顺序很重要。它们将按被接收的顺序处理。
</t>
<t>
Streams are identified by an integer. Stream identifiers are assigned to streams by
the endpoint initiating the stream.
流以一个整数标识。标识符有启动流的终端分配。
</t>
</list>
</t>
<section anchor="StreamStates" title="Stream States">
<t>
The lifecycle of a stream is shown in <xref target="StreamStatesFigure"/>.
流的生存周期如<xref target="StreamStatesFigure"/>所以：
</t>
<figure anchor="StreamStatesFigure" title="Stream States">
<artwork type="drawing">
<![CDATA[
+--------+
PP | | PP
,--------| idle |--------.
/ | | \
v +--------+ v
+----------+ | +----------+
| | | H | |
,---| reserved | | | reserved |---.
| | (local) | v | (remote) | |
| +----------+ +--------+ +----------+ |
| | ES | | ES | |
| | H ,-------| open |-------. | H |
| | / | | \ | |
| v v +--------+ v v |
| +----------+ | +----------+ |
| | half | | | half | |
| | closed | | R | closed | |
| | (remote) | | | (local) | |
| +----------+ | +----------+ |
| | v | |
| | ES / R +--------+ ES / R | |
| `----------->| |<-----------' |
| R | closed | R |
`-------------------->| |<--------------------'
+--------+
H: HEADERS frame (with implied CONTINUATIONs)
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
ES: END_STREAM flag
R: RST_STREAM frame
]]>
</artwork>
</figure>
<t>
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 <x:ref>RST_STREAM</x:ref>, where
frames might be received for some time after closing.
当流在传输的时候，各个端点对流状态的主观认识可能不同。终端并不协调流的创建；它们是被任意终端单方面创建的。不匹配的状态导致的消极结果是在发送<x:ref>RST_STREAM</x:ref>流之后它们的“关闭”是受限制的，因为可能在关闭之后帧才被接收。
</t>
<t>
Streams have the following states:
流有以下状态：
<list style="hanging">
<x:lt hangText="idle:">
<t>
<vspace blankLines="0"/>
All streams start in the "idle" state. In this state, no frames have been
exchanged.
所有流以“空闲”状态开始。在这种状态下，没有任何帧的交换。
</t>
<t>
The following transitions are valid from this state:
下列传输在这种状态下是有效的：
<list style="symbols">
<t>
Sending or receiving a <x:ref>HEADERS</x:ref> frame causes the stream to become
"open". The stream identifier is selected as described in <xref
target="StreamIdentifiers"/>. The same <x:ref>HEADERS</x:ref> frame can also
cause a stream to immediately become "half closed".
发送或者接收一个<x:ref>报头HEADERS</x:ref>帧导致流变成“打开”。流标识符如<xref target="StreamIdentifiers"/>说明。这个<x:ref>报头HEADERS</x:ref>帧同样可能导致流立即变成“半关闭”状态。
</t>