Cuprins Li

Cuprins
 1. Introducere
 2. HTTP / 2 Protocol Prezentare generală
o 2.1 Organizarea de documente
o 2.2 Convenții și terminologie
 3. Începând HTTP / 2
o 3.1 HTTP / 2 Versiunea de identificare
o 3.2 Începâ nd HTTP / 2 pentru URI-uri "http"
 3.2.1 HTTP2-Settings Antet Câ mp
o 3.3 Începâ nd HTTP / 2 pentru "https" URI-uri
o 3.4 Începâ nd HTTP / 2 cu cunoștințelor anterioare
o 3.5 HTTP / 2 Prefață Conexiune
 4. Rame HTTP
o 4.1 Frame Format
o 4.2 Frame Size
o 4.3 antet de compresie și de decompresie
 5. Izvoare și multiplexare
o 5.1 Statele Stream
 5.1.1 Identificatorii Stream
 5.1.2 Stream Concurență
o 5.2 Flow Control
 5.2.1 Principii Flow Control
 5.2.2 Utilizarea corespunză toare de control al debitului
o 5.3 prioritate Stream
 5.3.1 Stream Dependențe
 5.3.2 Dependența de ponderare
 5.3.3 Reprioritization
 5.3.4 Prioritizarea Managementul de stat
 5.3.5 Priorită ți implicite
o 5.4 de eroare de manipulare
 5.4.1 Eroare de conexiune de manipulare
 5.4.2 Eroare Stream de manipulare
 5.4.3 Încetarea Conexiune
 6. Definiții Frame
o 6.1 DATE
o 6.2 antetele
o 6.3 PRIORITATE
o 6.4 RST_STREAM
o 6.5 SETĂ RI
 6.5.1 SETĂ RI Format
 6.5.2 setarile Parametri
 6.5.3 Setă ri de sincronizare
o 6.6 PUSH_PROMISE
o 6.7 PING
o 6.8 GOAWAY
o 6.9 WINDOW_UPDATE
 6.9.1 Fereastra Flow Control
 6.9.2 inițială dimensiunea ferestrei Flow Control
 6.9.3 Reducerea dimensiunea ferestrei Stream
o 6.10 CONTINUARE
o 6.11 ALTSVC
o 6.12 BLOCAT
 7. Coduri de eroare
 8. Schimburi de mesaje HTTP
o 8.1 HTTP Cerere / Schimb de raspuns
 8.1.1 Ră spunsuri informaționale
 8.1.2 Exemple
 8.1.3 HTTP Header Fields
 8.1.4 Cerere Mecanisme de fiabilitate în HTTP / 2
o 8.2 Server Push
 8.2.1 Cererile Push
 8.2.2 Ră spunsuri Push
o 8.3 Metoda CONNECT
 9. suplimentare Necesitati HTTP / Considerații
o 9.1 Managementul Conexiune
o 9.2 Utilizarea de caracteristici TLS
o 9.3 GZip Content-Encoding
 10. Considerații de Securitate
o 10.1 Autoritatea Server
o 10,2 Cross-Protocol Atacuri
o 10,3 intermediare Atacurile încapsulare
o 10.4 Cacheability de Responses împins
o 10.5 Denial of Considerații de servcii
o 10.6 Utilizarea compresie
o 10.7 Utilizarea Captuseala
o 10,8 Considerații de confidențialitate
 11. Considerații IANA
o 11.1 Înregistrarea HTTP / 2 Identificarea Strings
o 11.2 Cod de eroare Registrul
o 11.3 HTTP2-Settings Antet Câ mp de înregistrare
o 11.4 PRI metodă de înregistrare
 12. Mulțumiri
 13. Trimiterile
o 13,1 Referințe normative
o 13,2 informative Referințe
 A. Change Log (pentru a fi eliminate prin RFC Editor înainte de publicare)
o A.1 Din proiect-IETF-httpbis-http2-12
o A.14 Din proiect-mbelshe-httpbis-SPDY-00
 Adresele autorilor
 Cifre
o Figura 1: Cadru Antet
o Figura 2: Statele Stream
o Figura 3: Exemplu de Implicit Dependența Creation
o Figura 4: Exemplu de Exclusive Dependența Creation
o Figura 5: Exemplu de dependență Reordonarea
o Figura 6: DATELE Frame Payload
o Figura 7: header-cadru Payload
o Figura 8: PRIORITATE Frame Payload
o Figura 9: RST_STREAM Frame Payload
o Figura 10: Setarea Format
o Figura 11: PUSH_PROMISE Sarcina Format
o Figura 12: PING Sarcina Format
o Figura 13: GOAWAY Sarcina Format
o Figura 14: WINDOW_UPDATE Sarcina Format
o Figura 15: Continuarea Frame Payload
o Figura 16: ALTSVC Frame Payload
1. Introducere
Hypertext Transfer Protocol (HTTP) este un protocol de pline de succes. Cu toate acestea, formatul HTTP/1.1 mesaj
( [HTTP-p1] , secțiunea 3 ), a fost conceput pentru a fi puse în aplicare cu instrumentele la îndemâ nă , în anii 1990, nu de
performanță moderne de aplicații Web. Ca atare, acesta are mai multe caracteristici care au un efect general negativ
asupra performanței cerere azi.
În special, HTTP/1.0 doar permite o cerere pentru a fi restante la un moment dat pe o conexiune. HTTP/1.1 conducte
adresat doar parțial cererea concurență și suferă de la cap de linie de blocare. Prin urmare, clientii care au nevoie pentru a
face mai multe solicită ri de obicei folosesc mai multe conexiuni la un server, în scopul de a reduce latenta.
Mai mult decâ t atâ t, Câ mpuri titluri HTTP/1.1 sunt adesea repetitive și detaliată , care, în plus față de generatoare de mai
multe ori mai mari pachete de rețea, poate provoca mic fereastra inițială congestie TCP pentru a umple rapid. Acest lucru
poate duce la latență excesiv atunci câ nd mai multe cereri sunt fă cute pe o singură conexiune noua TCP.
Acest document abordează aceste probleme prin definirea o cartografiere optimizat de semantica HTTP de la o conexiune
de bază . În mod specific, aceasta permite intercalare de mesaje de cerere și de ră spuns pe aceeași conexiune și utilizează o
codificare eficient pentru câ mpurile de antet HTTP. Acesta permite, de asemenea, stabilirea priorită ților de cereri,
permițâ ndu cereri mai importante complet mai repede, îmbună tățirea în continuare a performanței.
Protocolul rezultat este conceput pentru a fi mai ușor de la rețea, deoarece mai puține conexiuni TCP poate fi folosit în
comparație cu HTTP/1.x. Acest lucru înseamnă mai puțin concurența cu alte fluxuri, și conexiuni trăit-mai lungi, care, la
râ ndul său, duce la o mai bună utilizare a capacită ților de rețea disponibile.
În cele din urmă , această încapsulare permite, de asemenea, de prelucrare a mai scalabilă a mesajelor prin utilizarea de
mesaje încadrare binar.
2. HTTP / 2 Protocol Prezentare generală
HTTP / 2 oferă un transport optimizat pentru semantica HTTP. HTTP / 2 suporta toate caracteristicile de bază ale
HTTP/1.1, dar își dorește să fie mai eficient în mai multe moduri.
Unitatea de protocol de bază în HTTP / 2 este un cadru ( secțiunea 4.1 ). Fiecare cadru are un alt tip și scop.De
exemplu, antete și DATE cadre formează baza de cereri HTTP și răspunsuri ( secțiunea 8.1 ); alte tipuri de cadru, cum ar
fi SETTINGS , WINDOW_UPDATE , și PUSH_PROMISE sunt folosite în sprijinul altor HTTP / 2 caracteristici.
Multiplexare a cererilor este realizată prin fiecare HTTP cerere-ră spuns schimbate însă rcinată unui singur flux ( secțiunea
5 ). Fluxuri sunt în mare măsură independente una de cealaltă , astfel încât o cerere blocat sau blocat nu împiedică
progresul pe alte cereri.
Controlul debitului și prioritizare a se asigura că este posibil să se utilizeze în mod corespunză tor fluxuri
multiplexate. Controlul debitului ( secțiunea 5.2 ) ajută la asigurarea că numai datele care pot fi utilizate de că tre un
receptor este transmis. Prioritizare ( secțiunea 5.3 ) se asigură că resursele limitate poate fi direcționat că tre cele mai
importante cereri primul.
HTTP / 2 se adaugă un nou mod de interacțiune, prin care un server poate împinge ră spunsurile la un client ( secțiunea
8.2 ). Server împinge permite un server pentru a trimite un speculativ de date client care serverul anticipează clientul va
avea nevoie, de tranzacționare de pe unele de utilizare a rețelei de un potențial câ știg de latență . Serverul face acest lucru
prin sintetizarea o cerere, pe care-l trimite ca unPUSH_PROMISE cadru. Serverul este apoi capabil de a trimite un răspuns
la cererea sintetice pe un flux separat.
Cadre care conțin câ mpuri antet HTTP sunt comprimate ( secțiunea 4.3 ). Cereri HTTP pot fi extrem de redundant, astfel
încâ t compresie poate reduce dimensiunea de cereri și ră spunsuri în mod semnificativ.
HTTP / 2 sprijină , de asemenea HTTP servicii alternative (a se vedea [ALT-SVC] ) folosind tipul de cadru ALTSVC
( secțiunea 6.11 ), pentru a permite servere mai mult control asupra traficului pentru a le.
2.1 Organizarea de documente
Specificația HTTP / 2 este împă rțit în patru pă rți:
 Pornind de HTTP / 2 ( secțiunea 3 ) se referă la modul în care este inițiată o conexiune HTTP / 2.
 Încadrarea ( secțiunea 4 ) și fluxuri ( secțiunea 5 ) straturi descrie modul HTTP / 2 cadre sunt structurate și a format în
fluxuri multiplexate.
 Cadru ( secțiunea 6 ) și de eroare ( secțiunea 7 ) definițiile includ detalii cu privire la cadru și de eroare de tipul celor
utilizate în HTTP / 2.
 Mapă rile HTTP ( Secțiunea 8 ) și cerințele suplimentare ( Secțiunea 9 ) descrie modul în care semantica HTTP sunt
exprimate folosind rame și fluxuri.
În timp ce unele dintre conceptele cadru și stratul de flux sunt izolate de la HTTP, intenția nu este de a defini un strat de
încadrare complet generic. Straturi de încadrare și fluxuri sunt adaptate la nevoile de protocolul HTTP si server de
apăsare.
2.2 Convenții și terminologie
Cuvintele-cheie "TREBUIE", "NU TREBUIE", "necesară ", "VOR", "nu", "ar trebui", "nu ar trebui", "recomandat", "poate", și
"OPȚ IONAL" în acest document sunt trebuie interpretată în sensul descris în RFC 2119 [RFC2119] .
Toate valorile numerice sunt în ordine octet rețea. Valorile sunt unsigned dacă nu se indică altfel. Valorile literale sunt
furnizate în zecimal sau hexazecimal, după caz. Literale hexazecimale sunt prefixate cu 0xpentru a le distinge de la literale
zecimale.
Se utilizează următorii termeni:
client:
Obiectivul inițierea conexiunea HTTP / 2.
Conexiune:
O conexiune la nivel de transport între două puncte finale.
eroare de conexiune:
O eroare care afectează întreaga conexiune HTTP / 2.
obiectiv:
Fie clientul sau serverul a conexiunii.
cadru:
Cea mai mică unitate de comunicare într-o conexiune HTTP / 2, constâ nd dintr-un antet și o secvență de lungime
variabilă de bytes structurate în funcție de tipul de cadru.
la egal la egal:
Un obiectiv. Câ nd se discută despre un anumit efect, "egal la egal" se referă la punctul final care este la distanță de
subiectul principal de discuție.
receptor:
Un obiectiv care primește cadre.
expeditor:
Un obiectiv care se transmite cadre.
server de:
Obiectivul care nu a inițiat conexiunea HTTP / 2.
flux:
Un curent bidirecțional de cadre pe un canal virtuală în conexiunea HTTP / 2.
Eroare curent:
O eroare pe individ fluxul HTTP / 2.
În cele din urmă , termenii "gateway", "intermediar", "proxy", și "tunel" sunt definite în secțiunea 2.3 a[HTTP-p1] .
3. Începând HTTP / 2
O conexiune HTTP / 2 este un protocol de nivel aplicație care rulează pe partea de sus a unei conexiuni TCP
( [TCP] ). Clientul este inițiatorul conexiune TCP.
HTTP / 2 utilizează aceeași "http" și "https" schemele URI folosite de HTTP/1.1. HTTP / 2 parts aceleași numere de port
implicite: 80 de "http" URI-uri și 443 pentru "https" URI-uri. Ca rezultat, prelucrare implementari cererile de URI-uri
resurse țintă , cum ar fihttp://example.org/foo sauhttps://example.com/bar sunt necesare
pentru a descoperi mai întâ i dacă serverul de amonte (la egal la egal imediat la care clientul dorește să stabilească o
conexiune) sprijină HTTP / 2.
Mijloacele prin care să sprijine pentru HTTP / 2 este determinată este diferit pentru "http" și "https" URI-uri. Discovery
pentru "http" URI-uri este descris în secțiunea 3.2 . Discovery pentru "https" URI-uri este descris în secțiunea 3.3 .
3.1 HTTP / 2 Versiunea de identificare
Protocolul definite în prezentul document are doi identificatori.
 String "H2" identifică protocolul HTTP unde / 2 utilizează TLS [TLS12] . Acest identificator este folosit in stratul de
cererea de prelungire negociere protocol TLS [TLSALPN] domeniu și în orice loc care HTTP / 2 peste TLS este
identificat.
Câ nd serializat într-un identificator protocol ALPN (care este o secvență de octeți), șirul de HTTP / 2 identificator
protocol este codificat folosind UTF-8 [UTF-8] .
 String "H2C" identifică protocolul HTTP unde / 2 este rula peste TCP text clar. Acest identificator este folosit în
HTTP/1.1 Upgrade domeniul antet și orice loc în care HTTP / 2 peste TCP este identificat.
Negocierea "H2" sau "H2C" implică utilizarea semanticii de transport, de securitate, de încadrare și de mesaje descrise în
acest document.
[ rfc.comment.1 : Nota RFC editorului:. vă rugă m să scoate restul de această secțiune înainte de publicarea de o versiune
finală a acestui document]
Numai implementari de finală RFC, publicat se pot identifica ca "H2" sau "H2C". Pâ nă câ nd există o astfel de RFC,
implementari NU TREBUIE să se identifice folosind aceste siruri de caractere.
Exemple și textul tot restul acestui document folosi "H2", ca o chestiune de doar comoditate editorial.Implementă ri de
proiecte de versiuni NU TREBUIE identifica folosind acest șir.
Implementă ri de proiecte de versiuni ale protocolului trebuie să adauge șirul "-" și proiectul de numă rul corespunză tor
pentru identificatorul. De exemplu, este identificat-proiect IETF-httpbis-http2-11 peste TLS folosind șirul "H2-11".
Experimentele non-compatibile, care se bazează pe aceste proiecte de versiuni trebuie să anexeze șirul "-" și un nume de
experiment pentru identificatorul. De exemplu, o implementare experimental de codare bazate pe starea de spirit pachete
bazate pe proiect-IETF-httpbis-http2-09 se pot identifica drept "h2-09-emo".Rețineți că orice etichetă trebuie să se
conformeze sintaxa "simbol", definit în secțiunea 3.2.6 de [HTTP-p1] .Experimentatori sunt încurajați să -și coordoneze
experimentele lor pe lista de discuții ietf-http-wg@w3.org.
3.2 Începând HTTP / 2 pentru URI-uri "http"
Un client care face o cerere pentru un "http" URI fă ră cunoștințe anterioare despre suport pentru HTTP / 2 folosește
mecanismul Upgrade HTTP ( secțiunea 6.7 din [HTTP-p1] ). Clientul face o cerere HTTP/1.1 care include un câ mp de antet
upgrade identificarea HTTP / 2, cu "H2C" token-ul. Cererea HTTP/1.1 TREBUIE să includă exact un HTTP2-Settings
( Secțiunea 3.2.1 ) câ mp de antet.
De exemplu:
GET / HTTP/1.1 default.htm

Gazdă: server.example.com
Conectare: upgrade, HTTP2-Setări
Upgrade: H2C
HTTP2-Setări: codare <base64url de HTTP/2 SETTINGS payload>
Cereri care conțin un organism de entitate trebuie să fie trimise în întregime înainte de clientul poate trimite HTTP / 2
rame. Aceasta înseamnă că o entitate mare cerere poate bloca utilizarea conexiunii pâ nă câ nd acesta este complet trimis.
În cazul în care concurenta a unei cereri inițiale de cereri ulterioare este importantă , o cerere de mic poate fi folosit pentru
a efectua upgrade-ul la HTTP / 2, la costul unui tur-retur suplimentar.
Un server care nu are suport pentru HTTP / 2 poate ră spunde la cererea ca și cum domeniul antet Upgrade au fost absenți:
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text / html
...
Un server care acceptă HTTP / 2 poate accepta upgrade-ul cu un 101 (Protocoale de comutare) ră spuns.După linia goală
care se termină răspunsul 101, serverul poate începe trimiterea HTTP / 2 rame. Aceste cadre trebuie să includă un
răspuns la cererea pe care a inițiat Upgrade.
HTTP/1.1 101 de Protocoale de comutare

Conexiune: Upgrade
Upgrade: H2C
[HTTP / 2 conexiune ...
Primul HTTP / 2 cadru trimis de server este o SETĂ RI cadru ( secțiunea 6.5 ). La primirea ră spunsului 101, clientul trimite
o prefață conexiune ( secțiunea 3.5 ), care include un SETTINGS cadru.
Cererea HTTP/1.1 care este trimis înainte de a face upgrade este atribuit flux de identificare 1 și i se atribuie valorile
prioritare implicite ( Secțiunea 5.3.5 ). Stream 1 este implicit jumă tate închis de la client că tre server, deoarece solicitare
este efectuată ca o cerere HTTP/1.1. După începerea conexiunea HTTP / 2, curentul 1 este folosit pentru răspunsul.
3.2.1 HTTP2-Settings Antet Câmp
O cerere care upgrade-uri de la HTTP/1.1 la http / 2 TREBUIE să includă exact o HTTP2-Setăricâ mp de

antet. HTTP2-Setăricâ mp de antet este un domeniu-hop-hop de antet care include parametrii care guvernează
conexiunea HTTP / 2, prevă zute în anticiparea a serverului acceptarea cererii pentru a face upgrade. Un server trebuie să
respingă o încercare de a actualiza în cazul în care acest domeniu antet nu este prezent.
HTTP2-Settings = token68
Conținutul HTTP2-Setăricâ mp de antet este utilă a unui SETĂ RI cadru ( secțiunea 6.5 ), codificată ca un șir
base64url (care este, codificarea-URL-ul și-filename în condiții de siguranță Base64 descris în secțiunea 5 de[RFC4648] ,
cu orice trailing '=' caractere omise) . ABNF [RFC5234] producerea detoken68este definit însecțiunea 2.1 a [HTTP-p7] .
Ca un domeniu-hop-hop cu antet, Conexiune câ mp de antet trebuie să includă o valoare de HTTP2-Setăriîn plus

față de Upgrade odată cu trecerea la HTTP / 2.
Un server decodează și interpretează aceste valori, deoarece orice alt SETTINGS cadru. Confirmarea parametrilor Setă ri
( Secțiunea 6.5.3 ) nu este necesar, deoarece un ră spuns 101 servește ca recunoaștere implicită . Furnizarea acestor valori
în cererea de upgrade asigură că protocolul nu are nevoie de valori implicite pentru parametrii de setă rile de mai sus, și
oferă un client o oportunitate de a oferi altor parametri înainte de a primi orice cadre de la server.
3.3 Începând HTTP / 2 pentru "https" URI-uri
Un client care face o cerere pentru o "https" URI fără cunoștințe anterioare despre suport pentru HTTP / 2
utilizează TLS [TLS12] cu extensia de negociere a protocolului stratului de aplicație [TLSALPN] .
Odată ce TLS negociere este completă , atât pentru client și server trimite o prefață conexiune ( secțiunea 3.5).
3.4 Începând HTTP / 2 cu cunoștințelor anterioare
Un client poate afla că un anumit server suporta HTTP / 2 prin alte mijloace. De exemplu, [ALT-SVC] descrie un mecanism
de publicitate această capacitate într-un câ mp de antet HTTP; rama ALTSVC ( secțiunea 6.11 ) descrie un mecanism
similar în HTTP / 2.
Un client poate trimite imediat HTTP / 2 cadre la un server care este cunoscut pentru a sprijini HTTP / 2, după prefață de
conectare ( secțiunea 3.5 ). Un server poate identifica o astfel de conexiune prin utilizarea metodei "PRI" în prefață
conexiune. Acest lucru afectează doar rezoluția de URI-uri "http"; servere de sprijin HTTP / 2 sunt necesare pentru a
sprijini negociere protocol în TLS [TLSALPN] pentru "https" URI-uri.
Înainte de suport pentru HTTP / 2 nu este un semnal puternic care un server de dat va sprijini HTTP / 2 pentru
conexiunile viitoare. Este posibil ca configurații de server să se schimbe; pentru configuratii sa difere între cazuri în sistem
cluster; sau condițiile de rețea să se schimbe.
3.5 HTTP / 2 Prefață Conexiune
La stabilirea unei conexiuni TCP și determinare că HTTP / 2 vor fi utilizate de că tre ambele colegii, fiecare obiectiv trebuie
să trimită o prefață conexiune ca o confirmare finală și de a stabili parametrii de setă rile inițiale pentru conexiunea HTTP /
2.
Conexiune prefață client începe cu o secvență de 24 de octeți, care în notație hexa sunt:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
(Ș irul PRI * HTTP/2.0 \ r \ n \ r \ Nm \ r \ n \ r \ n). Această secvență este urmată de

oSETTINGS cadru ( secțiunea 6.5 ). SETTINGS Cadrul poate fi gol. Clientul trimite prefața conexiune client imediat după
primirea unui răspuns protocoale de comutare 101 (indicâ nd un upgrade de succes), sau ca primii octeti de date de
aplicare a unei conexiuni TLS. În cazul în care începe o conexiune HTTP / 2, cu o cunoaștere prealabilă a suportul pentru
server pentru protocolul, conexiune prefața client este trimis la stabilirea conexiunii.
 Prefața conexiune client este aleasă astfel încâ t o mare parte din servere și intermediari HTTP/1.1 sau HTTP/1.0 nu
încercați pentru a procesa cadre suplimentare. Rețineți că acest lucru nu se răspunde preocupă rilor exprimate
în [TALKING] .
Prefața conectare la server constă dintr-un potențial goale SETĂ RI cadru ( secțiunea 6.5 ), care trebuie să fie primul cadru
serverul trimite în conexiunea HTTP / 2.
Pentru a evita latenta inutile, clienților li se permite să trimită cadre suplimentare la serverul imediat după trimiterea
conexiune prefața client, fă ră a mai aștepta să primească prefața conexiune la server. Este important de remarcat, totuși,
că conexiune la server Prefață SETTINGS cadru ar putea include parametrii care afectează neapă rat modul în care se
așteaptă un client pentru a comunica cu serverul. La primireaSETTINGS cadru, clientul este de așteptat pentru a onora
orice parametri stabiliți.
Clienți și servere TREBUIE termina conexiunea TCP, fie la egal la egal în cazul în care nu începe cu o prefață de conexiune
valid. Un GOAWAY cadru ( secțiunea 6.8 ) poate fi omisă în cazul în care este clar că la egal la egal nu este folosind HTTP /
2.
4. Rame HTTP
Odată ce conexiunea HTTP / 2 este stabilit, obiective pot începe schimbul de cadre.
4.1 Frame Format
Toate cadrele începe în afara de 8 octeți urmat de o sarcină utilă de între 0 și 16.383 octeți.
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 | Lungime (14) | Tip (8) | Steaguri (8) |
+ - + - + ----------- + --------------- + -----------------
-------------- +
| R | Stream Identifier (31) |
+ - + ----------------------------------------------- -------------- +
| Cadru Sarcina utilă (0 ...) ...
+ ------------------------------------------------- -------------- +
Cadru antet
Domeniile de antet cadru sunt definite ca:
R:
Un câmp 2-bit rezervate. Semantica acestor biți sunt nedefinite și biți trebuie să ră mâ nă unset (0), atunci câ nd trimit și
trebuie să fie ignorate atunci câ nd primesc.
Lungime:
Lungimea sarcinii utile cadru exprimat ca fă ră semn pe 14 biți numă r întreg. Cele 8 octeti de antet cadru nu sunt
incluse în această valoare.
Tip:
Tipul de 8 biți al cadrului. Tipul de cadru determină modul în care restul header-cadru și sarcina utilă sunt
interpretate. Implementari trebuie să trateze primirea de tip cadru necunoscut (orice tipuri de cadru nu sunt definite
în acest document), ca o eroare de conexiune ( secțiunea 5.4.1 ) de tipPROTOCOL_ERROR .
Steaguri:
Un câmp de 8 biți rezervat de tip cadru steaguri booleene specifice.
Steaguri sunt atribuite semantica specifice la tipul de cadru indicat. Steaguri care au semantica nu definite pentru un
anumit tip de cadru trebuie să fie ignorate, și trebuie să fie lă sat unset (0), atunci câ nd trimit.
R:
Un câmp de 1-bit rezervate. Semantica acestui bit sunt nedefinite și bitul trebuie să rămâ nă unset (0), atunci câ nd
trimit și trebuie să fie ignorate atunci câ nd primesc.
Identifier Stream:
Un flux identificator de 31-bit (a se vedea secțiunea 5.1.1 ). Valoarea 0 este rezervată pentru cadre care sunt asociate
cu conexiunea ca un întreg, spre deosebire de un flux de individ.
Structura și conținutul sarcina utilă cadru este în întregime dependentă de tipul de cadru.
4.2 Frame Size
Dimensiunea maximă a unui cadru sarcină utilă variază în funcție de tipul de cadru. Dimensiunea maximă absolută de o
sarcină utilă de cadru este de 2 -1 (16383) octeți, ceea ce înseamnă că dimensiunea maximă a cadrului este de 16391
14
octeti. Toate implementarile trebuie să fie capabil de a primi și de prelucrare minim rame pâ nă la această dimensiune
maximă .
Anumite tipuri de cadru, cum ar fi PING (a se vedea secțiunea 6.7 ), impune limite suplimentare cu privire la cantitatea de
date de sarcină utilă permise. De asemenea, o limită de dimensiune suplimentare pot fi stabilite de utilizari specifice de
aplicare (a se vedea secțiunea 9 ).
Dacă o dimensiune a cadrului depășește orice limită definită , sau este prea mic pentru a conține date obligatorii cadru,
obiectivul final trebuie să trimită o FRAME_SIZE_ERROR eroare. O eroare de dimensiune frame într-un cadru care ar putea
modifica starea întregului conexiunea trebuie să fie tratată ca o eroare de conexiune ( secțiunea 5.4.1 ); aceasta include
orice cadru care un bloc antet ( secțiunea 4.3 ) (care este,antete , PUSH_PROMISE , și CONTINUARE ), SETTINGS , și
orice WINDOW_UPDATE cadru cu un identificator de flux de 0.
4.3 antet de compresie și de decompresie
Un câmp de antet în HTTP / 2 este o pereche nume-valoare cu una sau mai multe valori asociate. Acestea sunt utilizate în
mesaje de cerere HTTP și de răspuns, precum și operațiunile de sistem de împingere (a se vedea secțiunea 8.2 ).
Seturi de antet sunt colecții de zero sau mai multe câ mpuri antet. Atunci câ nd sunt transmise printr-o conexiune, un set de
antet este serializat într-un bloc antet folosind HTTP antet de compresie[COMPRESSION] . Blocul antet serializat este apoi
divizată în una sau mai multe secvențe octet, numite fragmente bloc antet, și transmis în sarcina utilă de antete ( pct. 6.2 ),
PUSH_PROMISE ( secțiunea 6.6 ) sau continuarea ( secțiunea 6.10 ) cadre.
HTTP antet de compresie nu păstrează ordinea relativă de câmpuri antet. Câmpuri titluri cu mai multe valori sunt
codificate într-un câ mp de antet singur, folosind un delimitator special; a se vedea secțiunea 8.1.3.3 .
Câmp de antet Cookie [COOKIE] este tratată special de cartografiere HTTP; a se vedea secțiunea 8.1.3.4 .
Un obiectiv care primește reasamblează bloc antet prin concatenarea fragmentele sale, atunci decomprimă blocul a
reconstrui setul antet.
Un bloc complet antet constă fie:
 un singur antetele sau PUSH_PROMISE cadru, cu flag END_HEADERS, sau

 un antete sau PUSH_PROMISE cadru cu steagul END_HEADERS eliminate și una sau mai multeCONTINUARE cadre, în
cazul în care ultima CONTINUARE cadru are setul steag END_HEADERS.
Compresie Header este dinamică , folosind un singur context compresie pentru întreaga conexiune. Fiecare bloc antet este
procesat ca unitate discretă . Blocuri antet trebuie transmisă ca o secvență contiguă de cadre, fă ră cadre intercalate de
orice alt tip sau din orice alt flux. Ultimul cadru într-o secvență de antete sauCONTINUATION cadre TREBUIE să aibă un
set de pavilion END_HEADERS. Ultimul cadru într-o secvență de PUSH_PROMISE sau CONTINUATION cadre TREBUIE să
aibă un set de pavilion END_HEADERS.
Fragmente de bloc antet pot fi trimise doar ca sarcină utilă de antete , PUSH_PROMISE sau CONTINUATIONcadre, pentru
că aceste cadre transporta date care pot modifica cadrul de compresie menținut de că tre un receptor. Un obiectiv
primirea antete , PUSH_PROMISE sau CONTINUATION cadre TREBUIE reasambla blocuri de antet și de a efectua
decompresie chiar dacă cadrele vor fi eliminate. Un receptor TREBUIE termina conexiunea cu o eroare de conexiune
( secțiunea 5.4.1 ) de tip COMPRESSION_ERROR dacă nu decomprima un bloc antet.
5. Izvoare și multiplexare
Un "flux" este o secvență independent, bi-directional de cadre schimbate între client și server într-o conexiune HTTP /
2. Fluxuri au mai multe caracteristici importante:
 O singură conexiune HTTP / 2 poate conține mai multe fluxuri simultan deschise, fie cu obiectiv intercalare cadre din
mai multe fluxuri.
 Fluxuri pot fi stabilite și utilizate în mod unilateral sau în comun de către client sau server.
 Fluxuri pot fi închise de că tre oricare punct final.
 Ordinea în care cadrele sunt trimise într-un flux este semnificativ. Destinatarii procesa cadre în ordinea în care sunt
primite.
 Fluxuri sunt identificate printr-un numă r întreg. Identificatorii Stream sunt atribuite fluxuri de final inițierea fluxul.
5.1 Statele Stream
Ciclul de viață al unui flux este prezentată în figura 1 .

+ -------- +
PP | | PP
, -------- | Inactiv | --------.
/ | | \
v + -------- + v
+ ---------- + | + ---------- +
| | | H | |
, --- | Rezervat | | | rezervat | ---.
| | (Local) | v | (de la distanță) | |
| + ---------- + + -------- + + ---------- + |
| | ES | | ES | |
| | H, ------- | deschis | -------. | H |
| | / | | \ | |
| Vv + -------- + vv |
| + ---------- + | + ---------- + |
| | Jumatate | | | jumatate | |
| | Închis | | R | închis | |
| | (De la distanță) | | | (local) | |
| + ---------- + | + ---------- + |
| | V | |
| | ES / R + -------- + ES / R | |
| `-----------> | | <-----------" |
| R | închis | R |
`--------------------> | | <--------------------"
+ -------- +
H: cadru antete (cu continuări implicite)

PP: cadru PUSH_PROMISE (cu continuări implicite)
ES: flag END_STREAM
R: cadru RST_STREAM
Figura 1: Statele Stream
Ambele obiective au o vedere subiectiv al statului a unui flux care ar putea fi altfel, atunci câ nd cadrele sunt în
tranzit. Obiective nu-și coordonează crearea de fluxuri; ele sunt create în mod unilateral de oricare punct
final. Consecințele negative ale unei neconcordanțe în statele sunt limitate la starea de "inchis", după
trimiterea RST_STREAM , în cazul în care cadrele ar putea fi primit de ceva timp după închidere.
Fluxuri au urmă toarele state:
inactiv:
Toate fluxurile începe în starea "în așteptare". În această stare, nu de cadre au fost schimbate.
Urmă toarele tranziții sunt valide din această stare:

 Trimiterea sau primirea unui header- cadru face ca fluxul de a deveni "deschide".Identificatorul de flux
este selectat după cum este descris în secțiunea 5.1.1 . În același antetecadru poate provoca, de asemenea,
un flux de a deveni imediat "închise pe jumă tate".
 Trimiterea unui PUSH_PROMISE cadru marchează fluxul asociat pentru o utilizare ulterioară .Statul flux de
tranzițiile de flux rezervate la "rezervat (local)".
 Primirea unui PUSH_PROMISE cadru marchează fluxul asociat ca rezervat de la egal la egal la
distanță . Starea fluxului devine "rezervat (la distanță )".
rezervat (local):
Un flux în "rezervat (local)" Statul este una care a fost promis prin trimiterea
unui PUSH_PROMISEcadru. Un PUSH_PROMISE cadru rezerva un curent inactiv prin asocierea fluxului cu un flux
deschis, care a fost inițiat de la egal la egal la distanță (a se vedea secțiunea 8.2 ).
În această stare, numai urmă toarele tranziții sunt posibile:
 Obiectivul poate trimite un header- cadru. Acest lucru face ca fluxul să se deschidă într-o "(de la distanță )
pe jumătate închis" de stat.
 Fie final poate trimite o RST_STREAM cadru pentru a determina fluxul de a deveni "închis".Aceasta
eliberează rezervare flux.
Un obiectiv NU TREBUIE trimite altele decâ t cadre anteturi sau RST_STREAM în această stare.
O PRIORITATE cadru pot fi primite în acest stat. Primirea orice alte cadre decâ t RST_STREAM ,
sauPRIORITATEA trebuie tratată ca o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
rezervat (la distanță ):
Un flux în "rezervate (la distanță )," de stat a fost rezervat de către un coleg de la distanță .
În această stare, numai urmă toarele tranziții sunt posibile:
 Primirea unui header- cadru face ca fluxul de la trecerea la "jumă tate închis (local)".

 Fie final poate trimite o RST_STREAM cadru pentru a determina fluxul de a deveni "închis".Aceasta
eliberează rezervare flux.
Un obiectiv poate trimite o PRIORITATE cadru în acest stat pentru a reprioritize fluxul rezervate. Un obiectiv NU
TREBUIE trimite orice alt tip de cadru, altele decâ t RST_STREAM sau PRIORITATE .
Primirea orice alt tip de cadru, altele decâ t antete sau RST_STREAM trebuie să fie tratată ca o eroare de conexiune
( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
deschide:
Un flux în starea "deschis" poate fi utilizat de către ambele colegii pentru a trimite cadre de orice tip. În această stare,
colegii trimiterea respectă limitele de publicitate de control al fluxului de nivel curent (Secțiunea 5.2 ).
Din această stare, fie obiectiv poate trimite un cadru cu un set de steag END_STREAM, ceea ce face ca fluxul de tranziție
într-unul din "jumătate închis" state: un obiectiv trimite un steag END_STREAM determină starea de flux pentru a
deveni "pe jumătate închis (local)" ; un obiectiv ce a primit un steag END_STREAM determină statul flux de a deveni
"închis jumătate (de la distanță )". Un antetele cadru care poartă un steag END_STREAM poate fi urmată
de CONTINUATION cadre.
Fie final poate trimite o RST_STREAM cadru din acest stat, fă câ ndu-l să tranziția imediat la "închis".
jumă tate închis (local):
Un flux care este în "(local) jumă tate închis" statul nu poate fi utilizat pentru a trimite cadre.
A tranziții Stream de la acest stat a "închis" atunci câ nd un cadru care conține un steag END_STREAM este primit, sau
atunci câ nd, fie la egal la egal trimite un RST_STREAM cadru. Un antetele cadru care poartă un steag END_STREAM
poate fi urmată de CONTINUATION cadre.
Un receptor poate ignora WINDOW_UPDATE sau PRIORITARE cadre în această stare. Aceste tipuri de cadru ar putea
ajunge pentru o perioadă scurtă de timp, după un cadru care poartă steagul END_STREAM este trimis.
jumă tate închiși (la distanță ):
Un flux care este "închis jumă tate (de la distanță )," nu mai este folosit de la egal la egal pentru a trimite cadre. În
această stare, un obiectiv nu mai este obligată să mențină o fereastră de control al fluxului de receptor în cazul în care
efectuează controlul fluxului.
În cazul în care un obiectiv primește cadre suplimentare pentru un flux care este în această stare, altele
decâ t CONTINUATION de cadre, trebuie să răspundă cu o eroare de curent ( Secțiunea 5.4.2 ) de tipSTREAM_CLOSED .
Un flux poate tranziția de la această stare de "închisă " prin trimiterea unui cadru care conține un steag END_STREAM,
sau atunci câ nd, fie la egal la egal trimite un RST_STREAM cadru.
închis:
Starea de "închis" este starea terminalului.
Un obiectiv nu trebuie să trimită cadre pe un flux închis. Un obiectiv care primește orice cadru dupa ce a primit
o RST_STREAM trebuie să trateze ca ca o eroare de curent ( Secțiunea 5.4.2 ) de tipSTREAM_CLOSED . În mod similar,
un obiectiv care primește orice cadre dupa ce a primit un DATAcadru cu indicatorul END_STREAM, sau orice cadre cu
excepția unui CONTINUARE cadru dupa ce a primit un header- cadru cu un set de steag END_STREAM trebuie să
trateze ca ca o eroare de curent (Secțiunea 5.4.2 ) din tip STREAM_CLOSED .
WINDOW_UPDATE , PRIORITATEA , sau RST_STREAM cadre pot fi primite în acest stat pentru o perioadă scurtă de

timp, după un DATA sau header- cadru conține un steag END_STREAM este trimis.Pâ nă la egal la distanță primește și
procesează cadrul purtâ nd steagul END_STREAM, s-ar putea trimite cadru de oricare dintre aceste tipuri. Obiectivele
trebuie să ignore WINDOW_UPDATE , PRIORITATEA, sau RST_STREAM cadre primite în această stare, deși obiective
pot alege pentru a trata cadre care sosesc o perioadă semnificativă după trimiterea END_STREAM ca o eroare de
conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Dacă această stare se ajunge ca un rezultat de a trimite un RST_STREAM cadru, la egal la egal care
primește RST_STREAM ar fi trimis deja - sau enqueued pentru trimiterea - cadre pe fluxul care nu pot fi retrase. Un
obiectiv trebuie să ignore cadre pe care le primește pe fluxuri închise după ce acesta a trimis o RST_STREAM cadru. Un
obiectiv poate alege să se limiteze perioada în care se ignoră cadre și cadre tratamente care sosesc după această dată ca
fiind în eroare.
Cadre flux controlat (de exemplu, DATE ) primit după trimiterea RST_STREAM sunt numă rate spre fereastra de control
al fluxului de conexiune. Chiar dacă aceste cadre pot fi ignorate, deoarece ele sunt trimise înainte expeditorul
primește RST_STREAM , expeditorul va lua în considerare cadrele pentru a conta în fereastra de control al fluxului.
Un obiectiv ar putea primi o PUSH_PROMISE cadru după ce trimite RST_STREAM . PUSH_PROMISEprovoacă un flux de

a deveni "rezervat", chiar dacă fluxul de asociat a fost resetat. Prin urmare, oRST_STREAM este necesar pentru a
închide o fluxuri nedorite promise.
În absența unor orientă ri mai specifice în altă parte în acest document, implementari ar trebui să trateze primirea unui
mesaj care nu este permis în mod expres în descrierea unui stat ca o eroare de conexiune (secțiunea 5.4.1 ) de
tip PROTOCOL_ERROR .
5.1.1 Identificatorii Stream
Fluxuri sunt identificate cu un nesemnate 31-bit întreg. Streams inițiate de către un client trebuie să utilizați identificatori
de flux ciudat numerotate; cele inițiate de server TREBUIE folosesc identificatori de flux chiar-numerotate. Un
identificator flux de zero (0x0) este folosit pentru mesaje de control de conectare; NU TREBUIE utilizat la zero
identificator flux de a stabili un nou flux.
Cereri HTTP/1.1 care sunt modernizate la HTTP / 2 (a se vedea secțiunea 3.2 ) sunt răspuns cu un identificator flux de
unul (0x1). După actualizare completeaza, curent 0x1 este "închis jumătate (local)" la client. Prin urmare, fluxul 0x1 nu
poate fi selectat ca un nou identificator flux de un client care upgrade-uri de la HTTP/1.1.
Identificatorul de un flux nou înființat TREBUIE să fie numeric mai mare decâ t toate fluxurile că obiectivul de deschidere a
deschis sau rezervate. Aceasta reglementează fluxuri care sunt deschise, folosind un header-cadru și fluxuri care sunt
rezervate cu ajutorul PUSH_PROMISE . Un obiectiv care primește un identificator flux neașteptat trebuie să răspundă cu o
eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Prima utilizare a unui nou identificator de flux închide implicit toate fluxurile în starea "în așteptare", care ar fi fost inițiate
de care la egal la egal cu un identificator de flux de prim rang inferior. De exemplu, dacă un client trimite un header- cadru
pe flux de 7, fără a mai trimite un cadru pe flux 5, apoi flux 5 tranziții la starea de "închis", atunci câ nd primul cadru pentru
fluxul 7 este trimis sau primit.
Identificatorii Stream nu pot fi refolosite. Conexiuni tră it-lung poate duce în final epuizarea gama disponibilă de
identificatori de flux. Un client care este în imposibilitatea de a stabili un nou identificator de flux poate stabili o nouă
conexiune pentru noi fluxuri.
5.1.2 Stream Concurență
Un egal la egal poate limita numă rul de fluxuri concomitent activi

folosindSETTINGS_MAX_CONCURRENT_STREAMS parametrii într-o SETTINGS cadru. Maxim setarea fluxuri concurente
este specific pentru fiecare punct final și se aplică numai de la egal care primește setarea. Că este, clienții specifica numă rul
maxim de fluxuri concurente serverul poate iniția, și servere specifica numă rul maxim de fluxuri concurente clientul poate
iniția. Obiective nu trebuie să depă șească limita stabilită de la egal la egal lor.
Fluxuri care sunt în starea "deschis", sau oricare dintre "pe jumă tate închis" state conta față de numă rul maxim de fluxuri
care un obiectiv este permis pentru a deschide. Izvoare in oricare dintre aceste trei state conta față de limita de publicitate
în SETTINGS_MAX_CONCURRENT_STREAMS setarea (a se vedeasecțiunea 6.5.2 ).
Un obiectiv care primește o antete cadru care cauzeaza limita lor de publicitate curent concurent poate fi depă șit, trebuie
să trateze acest lucru ca pe o eroare de curent ( Secțiunea 5.4.2 ).
Izvoare in oricare dintre statele "rezervate" nu contează la fel de deschis.
5.2 Flow Control
Folosind fluxuri de multiplexare introduce dispută pe utilizarea conexiunii TCP, rezultâ nd în fluxurile blocate. O schemă de
control al fluxului asigură fluxuri pe aceeași conexiune nu interferează distructivă cu altele. Controlul debitului este
utilizat atât pentru fluxuri individuale și pentru legă tura în ansamblu.
HTTP / 2 prevede controlul fluxului prin utilizarea de WINDOW_UPDATE tipul de cadru.
5.2.1 Principii Flow Control
De control HTTP / 2 flux de curent are scopul de a permite îmbunătă țiri în viitor să curgă algoritmi de control, fă ră a
necesita modifică ri de protocol. De control al fluxului în HTTP / 2 are urmă toarele caracteristici:
1. De control al fluxului este de-hop-hop prin, nu end-to-end.

2. Control al fluxului se bazează pe rame de ferestre de actualizare. Receptoare publicitate câ te bytes acestea sunt
pregă tite pentru a primi pe un flux și pentru întreaga conexiune. Acesta este un sistem bazat pe credit.
3. De control al fluxului este direcțional cu un control general oferit de receptor. Un receptor poate alege pentru a seta
orice dimensiune fereastră care-l dorește pentru fiecare flux și pentru întreaga conexiune.Un expeditor trebuie să
respecte limitele de control al fluxului impuse de către un receptor. Clienti, servere si intermediari toate publicitate
independent fereastra lor de control al fluxului ca un receptor și să respecte limitele stabilite de control al fluxului
de la egal la egal lor, atunci câ nd trimit.
4. Valoarea inițială pentru fereastra de control al fluxului este de 65,535 bytes atât pentru noi fluxuri și conexiunea de
ansamblu.
5. Tipul de cadru determină dacă controlul fluxului se aplică la un cadru. Din cadrele menționate în acest document,
doar DATE cadre sunt supuse la controlul fluxului; toate celelalte tipuri de cadru nu consuma spațiu în fereastra de
publicitate de control al fluxului. Acest lucru asigură că cadrele importante de control nu sunt blocate de control al
debitului.
6. De control al fluxului nu poate fi dezactivat.
7. HTTP / 2 standardizează numai formatul WINDOW_UPDATE cadrului ( secțiunea 6.9 ). Aceasta nu prevede modul
în care un receptor decide câ nd să trimită acest cadru sau valoarea pe care o transmite.Nici nu precizează modul în
care un expeditor alege pentru a trimite pachete. Implementari sunt capabili de a selecta orice algoritm care se
potriveste nevoilor lor.
Implementă ri sunt, de asemenea, responsabil pentru gestionarea modul în care solicită rile și ră spunsurile sunt trimise pe
baza de prioritate; alege cum să evite cap de linie de blocare pentru a cererilor; și gestionarea crearea de noi
fluxuri. Alegeri algoritm pentru acestea ar putea interacționa cu orice algoritm de control al debitului.
5.2.2 Utilizarea corespunzătoare de control al debitului
De control al fluxului este definit pentru a proteja obiective care operează sub constrâ ngeri de resurse. De exemplu, un
proxy trebuie să împartă între memoria multe conexiuni, și, de asemenea, ar putea avea o conexiune amonte lentă și una
rapidă în aval. Flux de control abordează cazurile în care receptorul este un proces în imposibilitatea de date pe un singur
flux, dar vrea să -și continue pentru a procesa alte fluxuri, în aceeași conexiune.
Implementă ri care nu necesită această capacitate se poate face publicitate o fereastră de control al fluxului de
dimensiunea maximă , incrementarea spațiul disponibil câ nd sunt primite noi date. Trimiterea de date este întotdeauna
supusă la fereastra de control al fluxului de publicitate de că tre receptor.
Implementă ri cu resurse limitate (de exemplu, memorie) pot utiliza de control al fluxului de a limita cantitatea de
memorie de la egal la egal se poate consuma. Rețineți, totuși, că acest lucru poate duce la o utilizare ineficientă a resurselor
de rețea disponibile, în cazul în care de control al fluxului este activat fă ră cunoștințe de produs lă țime de bandă , întâ rziere
(a se vedea [RFC1323] ).
Chiar și cu deplină cunoștință de curent produs lă țime de bandă -întâ rziere, punerea în aplicare de control al debitului
poate fi dificil. Atunci câ nd se utilizează controlul fluxului, receptorul trebuie să citească de la TCP primi tampon într-un
timp util. Imposibilitatea de a face acest lucru ar putea duce la un impas, atunci câ nd cadre critice, cum ar
fi WINDOW_UPDATE , nu sunt disponibile la HTTP / 2. Cu toate acestea, controlul fluxului poate garanta că resursele
limitate sunt protejate, fă ră nici o reducere a gradului de utilizare a conexiune.
5.3 prioritate Stream
Un client poate atribui o prioritate pentru un nou flux de informații, inclusiv stabilirea priorităților în cadrul antetele
( secțiunea 6.2 ), care se deschide fluxul. Pentru un flux existent, cadrul PRIORITY ( secțiunea 6.3 ) poate fi utilizat pentru a
modifica prioritatea.
Scopul de prioritizare este de a permite un obiectiv de a exprima modul în care ar prefera la egal la egal sa aloce resurse
atunci câ nd gestionează fluxuri concurente. Cel mai important, prioritatea poate fi folosit pentru a selecta fluxuri de
transmitere cadre atunci câ nd există o capacitate limitată de a trimite.
Fluxuri pot fi prioritizate prin marcarea lor ca depinde de finalizarea altor fluxuri ( Secțiunea 5.3.1 ). Fiecare dependență
se atribuie o pondere relativ, un numă r care este folosit pentru a determina proporția relativă a resurselor disponibile,
care sunt atribuite fluxuri dependente ale aceluiași flux.
Stabilirea în mod explicit prioritatea pentru un flux de intrare este de la un proces de prioritizare. Aceasta nu garantează
nici o prelucrare sau de transport pentru special pentru curent în raport cu orice alt flux. Un obiectiv nu poate forța un
egal la egal pentru a procesa fluxuri concurente într-o anumită ordine, folosind cu prioritate. Exprimarea prioritate este,
prin urmare, doar vreodată o sugestie.
Informații prioritizare pot fi specificate în mod explicit pentru fluxuri în care acestea sunt create folosindantetele cadru,
sau modificate cu ajutorul PRIORITATE cadru. Furnizarea de informații prioritizarea este opțională , astfel încâ t valorile
implicite sunt utilizate în cazul în care nici un indicator nu este prevă zută explicit ( Secțiunea 5.3.5 ).
5.3.1 Stream Dependențe
Fiecare flux poate fi administrat o dependență explicită la un alt flux. Inclusiv o dependență exprimă o preferință pentru a
aloca resurse pentru fluxul de identificat, mai degrabă decâ t la fluxul de dependent.
Un flux care nu este dependent de orice alt flux este dată o dependență flux de 0x0.
Un flux de care depinde un alt flux este un flux de dependent. Fluxul pe care un flux este dependentă este un pă rinte de
dependențe, sau flux de pă rinte.
Atunci câ nd se atribuie o dependență pe un alt curent, în mod implicit, fluxul este adă ugat ca o nouă dependență a fluxului
de pă rinte. De exemplu, dacă fluxurile B și C sunt dependente de flux A, iar dacă fluxul D este creat cu o dependență de flux
A, aceasta are ca rezultat o ordine de dependență A urmat de B, C, și D.
AA
/ \ ==> / | \
BCBDC
Exemplu de Implicit Dependența Creation
Un steag exclusiv permite introducerea unui nou nivel de dependențe. Pavilion exclusiv determină fluxul de a deveni
unicul dependența de flux-mamă , cauzâ nd alte dependențe pentru a deveni dependent de fluxul de prioritate. În exemplul
anterior, în cazul în care fluxul D este creat cu o dependență exclusiv pe curent A, acest lucru duce la D a deveni pă rintele
dependență de B și C.
A
A |
/ \ ==> D
BC / \
BC
Exemplu de Exclusive Dependența Creation
În interiorul structura de dependențe, un flux de dependent vor fi alocate doar resurse în cazul în care toate fluxurile de
care depinde (lanțul de pă rinte fluxuri de pâ nă la 0x0) sunt fie închise, sau nu este posibil să se facă progrese pe ele.
Un flux nu poate depinde de el însuși. Un obiectiv poate fie trata acest lucru ca pe o eroare de curent (Secțiunea 5.4.2 ) de
tip PROTOCOL_ERROR , sau de a atribui valori prioritare implicite ( Secțiunea 5.3.5 ) la fluxul.
5.3.2 Dependența de ponderare
Toate fluxurile de dependente sunt alocate un numă r întreg de greutate între 1 - 256 (inclusiv).
Izvoare cu același pă rinte ar trebui alocate resurse proporțional în funcție de greutatea lor. Astfel, în cazul în care fluxul B
depinde de flux cu o greutate de 4, și C depinde de flux cu o greutate de 12, iar în cazul în care se poate face nici un progres
pe A, curent B primește în mod ideal, o treime din resursele alocate pentru flux C.
5.3.3 Reprioritization
Priorită ți Stream sunt schimbate cu ajutorul PRIORITATE cadru. Setarea o dependență provoacă un curent de a deveni

dependent de fluxul pă rinte identificat.
Fluxuri dependente muta cu fluxul lor de pă rinte în cazul în care pă rintele este prioritizat. Setarea o dependență cu steagul
exclusiv pentru un flux de prioritizat mută toate dependențele din nou flux de mamă pentru a deveni dependent de fluxul
de prioritizat.
Dacă un curent care se face dependentă de una dintre propriile dependențe, fluxul fostă dependentă este deplasat mai
întâi să fie dependente de fluxul prioritizat de pă rinte anterior. Dependența sa mutat păstrează greutatea sa.
De exemplu, pentru un arbore de dependență original, în cazul în care B și C depind de A, D și E depind de C, F și depinde
D. În cazul în care un se face în funcție de D, atunci D ia locul lui A. Toate alte relații de dependență , fie ră mâ ne aceeași, cu
excepția F, care devine dependent de o dacă reprioritization este exclusivă .
? ? ? ?
| / \ | |
ADADD
/ \ / / \ / \ |
BC ==> FBC ==> FA SAU A
/ \ | / \ / | \
DEEBCBCF
| | |
FEE
(Intermediar) (non-exclusiv) (exclusiv)
Exemplu de Dependența Reordonarea
5.3.4 Prioritizarea Managementul de stat
Atunci câ nd un flux este eliminat din structura de dependențe, dependențele sale pot fi mutate pentru a deveni dependent
de mamă a fluxului închis. Ponderile noi dependențe sunt recalculate prin distribuirea greută ții dependența fluxului închis
proporțional în funcție de ponderile dependențele sale.
Fluxuri care sunt eliminate din structura de dependențe provoca unele informații prioritizare să se piardă .Resursele sunt
împă rțite între fluxuri cu același fluxul de pă rinte, ceea ce înseamnă că în cazul în care un flux în care set se închide sau se
blochează , orice capacitate de rezervă alocat un flux este distribuit la vecinii imediate ale fluxului. Cu toate acestea, în cazul
în comun dependența este scos din copac, aceste fluxuri de resurse în comun cu fluxuri de la urmă torul cel mai înalt nivel.
De exemplu, să presupunem că fluxurile A și cota B, un pă rinte, și fluxuri C și D, atât depind de flux A. Înainte de eliminarea
de flux A, în cazul în care fluxurile de A și D sunt în imposibilitatea de a continua, atunci fluxul C primește toate resursele
dedicate flux A. Dacă fluxul A este îndepă rtată de pe lemn, greutatea flux A este împă rțit între fluxurile C și D. Dacă fluxul D
este încă în mă sură să procedeze, acest lucru duce la flux C primind un procent redus de resurse. Pentru ponderi egale de
plecare, C primește o treime, mai degrabă decâ t o jumă tate, din resursele disponibile.
Este posibil ca un flux de a deveni închisă în timp ce informațiile de prioritizare care creează o dependență pe care fluxul
este în tranzit. În cazul în care un flux de identificat într-o dependență a avut nici o informație de prioritate asociat distrus,
atunci fluxul de dependent este atribuit în schimb o prioritate implicit. Acest lucru creează potențial prioritizare
suboptimal, deoarece fluxul ar putea fi dat o prioritate care este mai mare decâ t destinate.
Pentru a evita aceste probleme, obiective ar trebui să mențină starea de prioritizare pentru fluxuri închise pentru o
perioadă după fluxuri apropiate.
Un obiectiv ar trebui să mențină fluxul de stat a priorită ților pentru o perioadă după fluxuri devin închis.Statul mai este
pă strat, mai mică șansa ca fluxuri sunt atribuite valori prioritare incorecte sau implicite.
Acest lucru ar putea crea o povară stat mare pentru un efect, așa că acest caz poate fi limitat. Un obiectiv poate aplica o
limită superioară fixă pe numă rul de fluxuri închise pentru care statul prioritizare este urmă rită pentru a limita expunerea
statului. Cantitatea de stat suplimentar un obiectiv menține ar putea fi dependentă de sarcină ; sub sarcină mare, de stat
prioritizare pot fi eliminate pentru a limita angajamentele de resurse. În cazuri extreme, un obiectiv ar putea debarasa
chiar de stat a priorităților pentru fluxurile de active sau rezervate. Dacă se aplică o limită fixă , obiective ar trebui să
mențină de stat pentru cel puțin la fel de multe fluxuri de permis de stabilirea lor
pentru SETTINGS_MAX_CONCURRENT_STREAMS .
Un obiectiv care primește o PRIORITATE cadru care modifică prioritatea unui flux închis ar trebui să modifice
dependențele de fluxuri care depind de ea, în cazul în care acesta și-a păstrat suficient de stat să facă acest lucru.
5.3.5 Priorități implicite
Furnizarea de informații de prioritate este opțională . Fluxuri sunt atribuite o dependență implicit pe flux 0x0. Fluxuri
împinse ( Secțiunea 8.2 ) depind inițial pe flux asociate lor. În ambele cazuri, fluxuri li se atribuie o greutate implicită de
16.
5.4 de eroare de manipulare
HTTP / 2 încadrare permite două clase de eroare:
 O condiție de eroare care face ca întreaga conexiune inutilizabil este o eroare de conexiune.
 O eroare într-un flux de individ este o eroare curent.
O listă a codurilor de eroare este inclusă în secțiunea 7 .
5.4.1 Eroare de conexiune de manipulare
O eroare de conexiune este nici o eroare care împiedică procesarea ulterioară a stratului de încadrare, sau care corupe
orice stat conexiune.
Un obiectiv care se confruntă cu o eroare de conexiune trebuie să trimită mai întâ i o GOAWAY cadru (secțiunea 6.8 ), cu
identificatorul flux de ultima fluxul pe care le-a primit cu succes de la egal la egal ei.GOAWAY Cadrul include un cod de
eroare care indică de ce conexiunea este de încheiere. După trimitereaGOAWAY cadru, obiectivul final trebuie să închidă
conexiunea TCP.
Este posibil ca GOAWAY nu va fi primit în mod fiabil de către punctul final de recepție. În cazul în care o eroare de
conexiune, GOAWAY oferă doar o încercare de best-effort pentru a comunica cu egal de ce conexiunea este încheiată .
Un obiectiv poate termina o conexiune în orice moment. În special, un obiectiv poate alege pentru a trata o eroare de
curent ca o eroare de conexiune. Obiectivele ar trebui să trimită o GOAWAY cadru atunci câ nd se încheie o conexiune, atâ ta
timp câ t circumstanțele o permit.
5.4.2 Eroare Stream de manipulare
O eroare de flux este o eroare legată de un anumit identificator de flux care nu afectează prelucrarea altor fluxuri.
Un obiectiv care detectează o eroare de flux trimite o RST_STREAM cadru ( secțiunea 6.4 ), care conține identificatorul flux
de fluxul de unde a apă rut eroarea. RST_STREAM Cadrul include un cod de eroare care indică tipul de eroare.
Un RST_STREAM este ultimul cadru care un obiectiv poate trimite pe un flux. Peer care trimiteRST_STREAM cadru trebuie
să fie pregă tit pentru a primi orice cadre care au fost trimise sau enqueued pentru trimiterea de la egal la egal la
distanță . Aceste cadre pot fi ignorate, cu excepția cazului în care se modifica starea conexiunii (cum ar fi starea menținut
pentru compresie antet ( secțiunea 4.3 )).
În mod normal, un obiectiv nu trebuie să trimită mai mult de o RST_STREAM cadru pentru orice flux. Cu toate acestea, un
obiectiv poate trimite suplimentare RST_STREAM cadre în cazul în care primește cadre pe un flux închis după mai mult de
un timp dus-întors. Acest comportament este permis să se ocupe de implementari incorect.
Un obiectiv nu trebuie să trimită o RST_STREAM ca ră spuns la o RST_STREAM cadru, pentru a evita looping.
5.4.3 Încetarea Conexiune
În cazul în care conexiunea TCP este rupt în jos în timp ce fluxurile rămâ n în state deschise sau închise pe jumă tate, apoi
obiectivul final trebuie să presupunem că aceste fluxuri au fost anormal întrerupt și ar putea fi incomplete.
6. Definiții Frame
Această specificație definește un numă r de tipuri de cadru, fiecare identificat printr-un cod unic de tip 8 biți.Fiecare tip
cadru servește un scop distinct, fie în crearea și gestionarea conexiunii ca un întreg, sau de fluxuri individuale.
Transmiterea tipuri specifice de cadru poate modifica starea unei conexiuni. Dacă obiective nu reușesc să mențină o
imagine sincronizată a statului de conectare, de comunicare de succes în conexiunea nu va mai fi posibil. Prin urmare, este
important ca obiective să aibă o înțelegere comună a modului în care statul este afectat de utilizarea orică rui cadru dat.
6.1 DATE
Cadrele de date (tip = 0x0) transmite arbitrare, secvențe de lungime variabilă de octeți asociate cu un flux.Unul sau mai
multe cadre de date sunt utilizate, de exemplu, pentru a transporta cereri HTTP sau sarcini utile de răspuns.
Rame de date poate conține, de asemenea, padding arbitrar. Padding poate fi adă ugat în cadrele de date pentru a ascunde
mă rimea mesajelor.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Pad mare? (8) | Pad Low? (8) |
+ --------------- + --------------- + ----------------- --------------
+
| Date (*) ...
+ ------------------------------------------------- -------------- +
| Padding (*) ...
+ ------------------------------------------------- -------------- +
DATE Frame Payload
Cadru de date conține urmă toarele câ mpuri:
Pad mare:
Un câmp de 8 biți care conține o cantitate de umplutură în unită ți de 256 de octeți. Acest câ mp este opțional și este
prezent doar în cazul în care pavilion PAD_HIGH este setat. Acest domeniu, în combinație cu Pad Low, determină cât de
mult padding este pe un cadru.
Pad Low:
Un câmp de 8 biți care conține o cantitate de umplutură în unită ți de octeți unice. Acest câ mp este opțional și este
prezent doar în cazul în care pavilion PAD_LOW este setat. Acest domeniu, în combinație cu Pad mare, determină câ t de
mult padding este pe un cadru.
Date:
De date de aplicare. Cantitatea de date este restul sarcinii utile cadru după scă derea lungimii celelalte domenii care
sunt prezente.
Padding:
Octeți de umplere care nu conțin aplicație valoare semantică . Octeti padding TREBUIE sa fie setat la zero atunci câ nd
trimit și ignorat atunci câ nd a primit.
Cadrului de date definește urmă toarele steagurile:
END_STREAM (0x1):
Bit 1 ființă set indică faptul că acest cadru este ultimul care obiectivul va trimite pentru fluxul de identificat. Setarea
acest flag face ca fluxul să introduceți unul dintre statele "jumă tate închise" sau de stat "închis" ( secțiunea 5.1 ).
END_SEGMENT (0x2):
Bit 2 ființă set indică faptul că acest cadru este ultimul pentru segmentul curent.Intermediarii NU TREBUIE fuziona
cadre traversează granița unui segment și trebuie să păstreze granițele segmentului, atunci câ nd transmiterea de
cadre.
PAD_LOW (0x8):
Bit 4 fiind stabilit indică faptul că Pad domeniul Low este prezent.
PAD_HIGH (0x10):
Bit 5 ființă set indică faptul că Pad domeniu de mare este prezent. Acest bit NU TREBUIE sa fie setat dacă steagul
PAD_LOW este, de asemenea, setat. Obiective care primesc un cadru cu set PAD_HIGH și PAD_LOW eliminate trebuie să
trateze acest lucru ca pe o eroare de conexiune (secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Comprimat (0x20):
Bit 6 ființă set indică faptul că datele din cadrul a fost comprimat cu compresie GZIP ([GZIP] ).
Rame de date trebuie să fie asociat cu un flux. În cazul în care un cadru de date este primit al că rui flux identificator de
câ mp este 0x0, beneficiarul trebuie să ră spundă cu o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Cadrele de date sunt opțional comprimate folosind compresie gzip [GZIP] . Fiecare cadru este comprimat în mod
individual; starea de compresor este resetat pentru fiecare cadru.
Un obiectiv nu trebuie să trimită un cadru de date cu indicatorul COMPRIMAT cu excepția cazului

înSETTINGS_COMPRESS_DATA setarea este activată , care este, setat la 1. Un obiectiv care nu a permis compresie cadru de
date trebuie să trateze primirea unui cadru de date cu steagul COMPRIMAT stabilit ca o eroare de conexiune ( secțiunea
5.4.1 ) de tip PROTOCOL_ERROR .
Cadrele de date sunt supuse de control al fluxului și pot fi trimise doar atunci câ nd un flux este în "deschise" sau "închise
jumă tate (de la distanță )" state. Întregul cadru de date utilă este inclusă în controlul fluxului, inclusiv Pad Low, Pad de
mare, și câ mpurile Huse dacă sunt prezente. În cazul în care un cadru de date este primit al că ror flux nu este în "deschis"
sau "închis jumă tate (local)" de stat, beneficiarul trebuie să răspundă cu o eroare de curent ( Secțiunea 5.4.2 ) de
tip STREAM_CLOSED .
Numă rul total de octeti de umplutură este determinată prin înmulțirea valorii Pad câmpului mare de 256 și adă ugarea
valorii Pad domeniu Min. Atât Pad mare și domenii Pad mici presupune o valoare de zero, dacă acesta este absent. Dacă
lungimea padding este mai mare decâ t lungimea de restul sarcinii utile cadru, destinatarul trebuie să trateze aceasta ca o
eroare de conexiune ( secțiunea 5.4.1 ) de tipPROTOCOL_ERROR .
Notă :
Un cadru poate fi crescut în dimensiune cu un octet de că tre inclusiv un Pad teren redus, cu o valoare de zero.
Utilizarea de padding este o caracteristică de securitate; ca atare, utilizarea sa necesită unele de îngrijire, a se
vedea secțiunea 10.7 .
6.2 antetele
Cadrul antete (tip = 0x1) poartă perechi nume-valoare. Este folosit pentru a deschide un flux ( secțiunea 5.1). Rame
antetele pot fi trimise pe un flux în "deschise" sau "închise jumă tate (de la distanță )" state.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
+ - + ------------- + --------------- + -----------------
-------------- +
| E | Stream de dependență? (31) |
+ - + ------------- + --------------------------------- --------------
+
| Greutate? (8) |
+ - + ------------- + --------------------------------- --------------
+
| Antet Block Fragment (*) ...
+ ------------------------------------------------- -------------- +
| Padding (*) ...
+ ------------------------------------------------- -------------- +
Header-cadru Payload
Cadru antetele utilă are urmă toarele câmpuri:
Pad mare:
Dimensiuni padding biți ridicate. Acest câ mp este prezent doar în cazul în care pavilion PAD_HIGH este setat.
Pad Low:
Dimensiuni padding biți mici. Acest câ mp este prezent doar în cazul în care pavilion PAD_LOW este setat.
E:
Un steag singur bit indică faptul că dependența flux este exclusivă , a se vedea secțiunea 5.3 . Acest câ mp este opțional și
este prezent doar în cazul în care pavilion prioritate este setat.
Stream de dependență :
Un flux identificator de 31-bit pentru fluxul care acest flux depinde, vezi secțiunea 5.3 . Acest câ mp este opțional și este
prezent doar în cazul în care pavilion prioritate este setat.
Greutate:
O greutate de 8-biți pentru fluxul, a se vedea secțiunea 5.3 . Adauga o la valoarea de a obține o greutate între 1 și 256.
Acest câ mp este opțional și este prezent doar în cazul în care pavilion prioritate este setat.
Antet Block Fragment:
Un fragment bloc antet ( secțiunea 4.3 ).
Padding:
Octeți de umplutură .
Cadrul antetele definește urmă toarele steagurile:
END_STREAM (0x1):
Bit 1 ființă set indică faptul că blocul de antet ( secțiunea 4.3 ), este ultimul care obiectivul va trimite pentru fluxul de
identificat. Setarea acest flag face ca fluxul să introduceți unul dintre state "jumă tate închise" ( Secțiunea 5.1 ).
Un cadru antete, care este urmat de CONTINUATION cadre poarta steagul END_STREAM care semnalează sfâ rșitul unui
flux. O CONTINUARE cadru nu poate fi folosit pentru a termina un flux.
END_SEGMENT (0x2):
Bit 2 ființă set indică faptul că acest cadru este ultimul pentru segmentul curent.Intermediarii NU TREBUIE fuziona
cadre traversează granița unui segment și trebuie să păstreze granițele segmentului, atunci câ nd transmiterea de
cadre.
END_HEADERS (0x4):
Bit 3 ființă set indică faptul că acest cadru conține un întreg bloc antet ( secțiunea 4.3 ) și nu este urmată de
orice CONTINUATION cadre.
Un cadru antete fă ră setul de pavilion END_HEADERS trebuie să fie urmată de o CONTINUARE cadru pentru același
flux. Un receptor trebuie să trateze primirea de orice alt tip de cadru sau un cadru pe un alt flux ca o eroare de
PAD_LOW (0x8):
PAD_HIGH (0x10):
PRIORITATE (0x20):
Bit 6 ființă set indică faptul că Exclusiv Flag (E), Stream dependență , și câ mpurile greutate sunt
prezente; vezi secțiunea 5.3 .
Sarcina utilă a unui cadru antete conține un fragment bloc antet ( secțiunea 4.3 ). Un bloc antet care nu se încadrează într-
un interval antete se continuă într-un cadru CONTINUARE ( secțiunea 6.10 ).
Rame antetele trebuie să fie asociat cu un flux. În cazul în care un cadru antete este primit al că rui flux identificator de
câ mp este 0x0, beneficiarul trebuie să ră spundă cu o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Cadrul antete schimba starea de conectare cum este descris în secțiunea 4.3 .
Cadrul antetele include padding opțional. Domenii de umplutură și steaguri sunt identice cu cele definite pentru cadrele de
date ( Secțiunea 6.1 ).
6.3 PRIORITATE
Cadrul PRIORITATE (tip = 0x2) specifică prioritatea sfătuit-expeditor a unui flux ( secțiunea 5.3 ). Acesta poate fi transmis
în orice moment, pentru un flux existent. Acest lucru permite reprioritization de fluxuri existente.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| E | Stream Dependency (31) |
+ - + ------------- + --------------------------------- --------------
+
| Greutate (8) |
+ - + ------------- +
PRIORITATEA Frame Payload
Sarcina utilă a unui cadru PRIORITATE conține următoarele câ mpuri:
E:
Un steag singur bit indică faptul că dependența flux este exclusivă , a se vedea secțiunea 5.3 .
Stream de dependență :
Un flux identificator de 31-bit pentru fluxul care acest flux depinde, vezi secțiunea 5.3 .
Greutate:
O greutate de 8-biți pentru dependența flux de identificat, a se vedea secțiunea 5.3 . Adă ugați unul la valoarea de a
obține o greutate între 1 și 256.
Cadrul PRIORITATE nu definește nici steaguri.
Cadrul PRIORITATE este asociat cu un flux existent. În cazul în care un cadru prioritate este primit cu un identificator de
flux de 0x0, destinatarul trebuie să ră spundă cu o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Cadrul prioritate poate fi transmis pe un flux în oricare dintre "rezervat (la distanță )", "deschide", "pe jumă tate închis
(local)", sau "închis jumă tate (de la distanță )" state, deși nu poate fi trimis între consecutiv cadre care cuprind un singur
bloc antet ( secțiunea 4.3 ). Rețineți că acest cadru ar putea ajunge după prelucrare sau cadru de trimitere a finalizat, ceea
ce ar face ca acesta să nu aibă nici un efect. Pentru un flux care este în "(la distanță ) pe jumătate închis" statul, acest cadru
poate afecta numai prelucrare a fluxului și nu cadru de transmisie.
6.4 RST_STREAM
Cadrul RST_STREAM (tip = 0x3) permite încetarea anormală a unui flux. Atunci câ nd sunt trimise de inițiatorul de un flux,
se indică faptul că doresc să anuleze fluxul sau că o condiție de eroare a avut loc.Atunci câ nd a trimis de receptor de un
flux, se indică faptul că , fie receptorul respinge fluxul, solicitâ nd ca fluxul să fie anulat sau că o condiție de eroare a avut
loc.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Cod de eroare (32) |
+ ------------------------------------------------- -------------- +
RST_STREAM Frame Payload
Cadrul RST_STREAM conține un singur nesemnate, pe 32 de biti cu semn de identificare a codului de eroare ( secțiunea
7 ). Codul de eroare indică de ce fluxul este reziliat.
Cadrul RST_STREAM nu definește nici steaguri.
Cadrul RST_STREAM termină complet fluxul de referință și provoacă -l pentru a intra în stare închisă . După ce a primit o
RST_STREAM pe un flux, receptorul nu trebuie să trimită cadre suplimentare, pentru care fluxul. Cu toate acestea, după
trimiterea RST_STREAM, obiectivul final trimiterea trebuie să fie pregă tit să primească și procesul de cadre suplimentare
trimis pe fluxul de care ar fi fost trimis de la egal la egal, înainte de sosirea RST_STREAM.
Rame RST_STREAM trebuie să fie asociat cu un flux. În cazul în care un cadru RST_STREAM este primit cu un identificator
de flux de 0x0, destinatarul trebuie să trateze acest lucru ca pe o eroare de conexiune (secțiunea 5.4.1 ) de
Rame RST_STREAM NU TREBUIE trimis pentru un flux în starea "în așteptare". În cazul în care este primit un cadru
RST_STREAM identificarea unui curent inactiv, destinatarul trebuie să trateze acest lucru ca pe o eroare de conexiune
6.5 SETĂRI
Setă rile cadru (tip = 0x4), transmite parametrii de configurare (cum ar fi preferințele și constrâ ngerile privind
comportamentul la egal la egal), care afectează modul în care obiective comunica, și este, de asemenea, utilizat pentru a
confirma primirea acestor parametri. În mod individual, un parametru setă rile pot fi, de asemenea, menționată ca un
"cadru".
Parametrii Setă rile nu sunt negociate; ele descriu caracteristicile la egal la egal trimitere, care sunt utilizate de că tre peer
primire. Valori diferite pentru același parametru poate fi promovat de că tre fiecare la egal la egal. De exemplu, un client
poate stabili ca fereastra inițială ridicată de reglare a debitului, în timp ce un server poate stabili o valoare mai mică a
conserva resursele.
Un cadru setă ri trebuie să fie trimise de că tre ambele obiective la începutul unei conexiuni, și pot fi trimise în orice alt
moment de oricare punct final pe durata de viață a conexiunii. Implementari trebuie să sprijine toate parametrii definiți de
această specificație.
Fiecare parametru într-un cadru SETĂ RI înlocuiește orice valoare existentă pentru acest parametru.Parametrii sunt
procesate în ordinea în care acestea apar, și un receptor de un cadru setă ri nu are nevoie pentru a menține orice alta decâ t
valoarea curentă a parametrilor săi de stat. Prin urmare, valoarea unui parametru SETTINGS este ultima valoare, care este
văzut de că tre un receptor.
Parametrii setă ri sunt recunoscute de la egal la egal primire. Pentru a activa aceasta, cadrul SETTINGS definește
următoarele pavilion:
ACK (0x1):
Bit 1 ființă set indică faptul că acest cadru confirmă primirea și aplicarea la egal la egal cu setă ri cadru. Câ nd acest bit
este setat, sarcina utilă a cadrului setă ri trebuie să fie gol. Primirea unui cadru SETTINGS cu indicatorul ACK și o
valoare de câ mp lungime altele decâ t 0 trebuie să fie tratată ca o eroare de conexiune ( secțiunea 5.4.1 ) de
tip FRAME_SIZE_ERROR . Pentru mai multe informații, consultați Setă ri de sincronizare ( Secțiunea 6.5.3 ).
SETĂ RI cadre se aplică întotdeauna la o conexiune, nu un singur flux. Identificatorul flux de un cadru setă ri trebuie să fie
zero. În cazul în care un obiectiv primește un cadru SETTINGS al că rui flux identificator de câmp este altceva decâ t 0x0,
obiectivul final trebuie să răspundă cu o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Setă rile Cadrul afectează starea conexiunii. A Setă ri cadru prost format sau incomplete trebuie să fie tratate ca o eroare de
6.5.1 SETĂRI Format
Sarcina utilă a unui cadru SETĂ RI este format din zero sau mai mulți parametri, fiecare constâ nd dintr-un identificator
fă ră semn pe 8 biți și o valoare fă ră semn pe 32 de biți.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Identifier (8) |
+ --------------- + --------------------------------- -------------- +
| Valoarea (32) |
+ ------------------------------------------------- -------------- +
Format Setarea
6.5.2 setarile Parametri
Sunt definiți următorii parametri:
SETTINGS_HEADER_TABLE_SIZE (1):
Permite expeditorul să informeze punctul final de la distanță a mă rimii tabelului de compresie antet folosit pentru a
decoda blocuri antet. Codificator poate reduce această dimensiune prin utilizarea de semnalizare specific pentru
formatul de compresie antet în interiorul unui bloc antet. Valoarea inițială este de 4.096 bytes.
SETTINGS_ENABLE_PUSH (2):
Această setare poate fi utilizat pentru a dezactiva server de împingere (secțiunea 8.2 ). Un obiectiv nu trebuie să trimită
o PUSH_PROMISE cadru în cazul în care primește acest parametru setat la o valoare de 0. Un obiectiv care are atât seta
acest parametru la 0 și a avut-o a recunoscut trebuie să trateze primirea unui PUSH_PROMISE cadru ca o eroare de
conexiune (secțiunea 5.4. 1 ) de tip PROTOCOL_ERROR .
Valoarea inițială este de 1, ceea ce indică faptul că împingere este permisă . Orice valoare, altele decâ t 0 sau 1 trebuie să
fie tratată ca o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
SETTINGS_MAX_CONCURRENT_STREAMS (3):
Indică numă rul maxim de fluxuri concurente care expeditorul va permite. Această limită este direcțională : se aplică la
numă rul de fluxuri care expeditorul permite receptorului să creeze. Inițial nu există nici o limită la această valoare. Se
recomandă ca această valoare să fie mai mic decâ t 100, pentru a nu limita inutil paralelism.
O valoare de 0 pentru SETTINGS_MAX_CONCURRENT_STREAMS nu trebuie să fie tratate ca deosebit de obiective. O

valoare zero, nu a preveni crearea de noi fluxuri, însă acest lucru se poate întâmpla, de asemenea, pentru orice limită ,
care este epuizat cu fluxuri active. Servere ar trebui să stabilească doar o valoare zero pentru durate scurte; dacă un
server nu vrea să accepte cereri, închizâ nd conexiunea ar putea fi de preferat.
SETTINGS_INITIAL_WINDOW_SIZE (4):
Indică inițială dimensiunea ferestrei expeditorului (în bytes) pentru controlul fluxului de nivelul curent. Valoarea
inițială este de 65.535.
Această setare afectează dimensiunea ferestrei tuturor fluxurilor, inclusiv fluxuri existente, a se vedeasecțiunea 6.9.2 .
Valorile de mai sus maxim fereastra de control al fluxului de dimensiunea de 2 - 1 trebuie să fie tratată ca o eroare de
31
conexiune ( secțiunea 5.4.1 ) de tip FLOW_CONTROL_ERROR .
SETTINGS_COMPRESS_DATA (5):
Această setare este utilizată pentru a permite compresia gzip a DATAcadre.
Valoarea 1 indică faptul că DATE cadre pot fi comprimate. O valoare de 0 indică faptul că de compresie nu este
permisă . Valoarea initiala este 0.
Altele decâ t 0 sau 1 Valorile nu sunt valabile. Un obiectiv trebuie să trateze primirea de orice altă valoare ca o eroare de
Un obiectiv care primește un cadru SETTINGS cu orice alt identificator trebuie să trateze acest lucru ca pe o eroare de
6.5.3 Setări de sincronizare
Cele mai multe valori în Setă ri beneficia de pe urma sau au nevoie de o înțelegere, atunci câ nd la egal la egal a primit și
aplicat schimbat valorile parametrilor comunicate. În scopul de a oferi astfel de momente de timp de sincronizare,
destinatarul unui cadru SETTINGS în care steagul ACK nu este setat trebuie să aplice parametrii actualizate câ t mai curâ nd
posibil după primirea.
Valorile din cadrul setă ri trebuie să fie aplicate în ordinea în care apar, cu nici o altă procesare cadru între valori. După ce
au fost aplicate toate valorile, destinatarul trebuie să emită imediat un cadru SETTINGS cu indicatorul ACK. La primirea
unui cadru SETTINGS cu indicatorul ACK, expeditorul a parametrilor modificate se pot baza pe aplicarea lor.
În cazul în care expeditorul a unui cadru SETTINGS nu primește o confirmare în termen de o sumă rezonabilă de timp,
aceasta poate emite o eroare de conexiune ( secțiunea 5.4.1 ) de tipSETTINGS_TIMEOUT .
6.6 PUSH_PROMISE
Cadrul PUSH_PROMISE (tip = 0x5) este utilizat pentru a notifica final la egal la egal în avans de fluxuri expeditorului
intenționează să inițieze. Cadrul PUSH_PROMISE include nesemnate 31-bit de identificare a fluxului de final intenționează
să creeze, împreună cu un set de antete care oferă context suplimentar pentru fluxul. Secțiunea 8.2 conține o descriere
amă nunțită a utiliză rii de cadre PUSH_PROMISE.
PUSH_PROMISE NU trebuie să fie trimise în cazul în care SETTINGS_ENABLE_PUSH stabilirea obiectivului la egal la egal

este setat la 0.
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 | ID Stream Făgăduinței (31) |
+ - + ----------------------------- + ----------------- --------------
+
+ ------------------------------------------------- -------------- +
| Padding (*) ...
+ ------------------------------------------------- -------------- +
Format PUSH_PROMISE Payload
PUSH_PROMISE cadru utilă are urmă toarele câ mpuri:
Pad mare:
Pad Low:
R:
Un singur bit rezervat.
Stream ID a promis:
Acest nesemnate 31-bit întreg identifică fluxul final intenționează să înceapă trimiterea de cadre pentru. Identificatorul
de flux promis trebuie să fie o alegere valabil pentru urmă torul fluxul transmis de expeditor (vezi nou identificator
curent ( Secțiunea 5.1.1 )).
Un fragment bloc antet ( secțiunea 4.3 ), care conține câ mpuri de antet cerere.
Padding:
Cadrul PUSH_PROMISE definește urmă toarele steagurile:
END_HEADERS (0x4):
Bit 3 ființă set indică faptul că acest cadru conține un întreg bloc antet ( secțiunea 4.3 ) și nu este urmată de
orice CONTINUATION cadre.
Un cadru PUSH_PROMISE fă ră setul de pavilion END_HEADERS trebuie să fie urmată de un cadru CONTINUARE pentru
același flux. Un receptor trebuie să trateze primirea de orice alt tip de cadru sau un cadru pe un alt flux ca o eroare de
PAD_LOW (0x8):
PAD_HIGH (0x10):
Rame PUSH_PROMISE trebuie să fie asociate cu un, flux de tip peer-inițiat existente. Identificatorul flux a unui cadru
PUSH_PROMISE indică fluxul este asociat. În cazul în care câ mpul identificator flux specifică 0x0 valoare, un beneficiar
trebuie să ră spundă cu o eroare de conexiune ( secțiunea 5.4.1 ) de tipPROTOCOL_ERROR .
Fluxuri promise nu sunt necesare pentru a fi utilizate în ordinea în care sunt promise. PUSH_PROMISE își rezervă numai
identificatori de flux pentru o utilizare ulterioară .
Beneficiarii de cadre PUSH_PROMISE pot alege pentru a respinge fluxuri promise prin returnarea
unuiRST_STREAM referire la identificatorul de flux promis înapoi expeditorului de PUSH_PROMISE.
Cadrul PUSH_PROMISE modifică starea de conectare astfel cum este definit în secțiunea 4.3 .
Un cadru PUSH_PROMISE modifică starea de conexiune în două moduri. Includerea unui bloc antet (secțiunea 4.3 )
modifică potențial statului menținut pentru compresie antet. PUSH_PROMISE își rezervă , de asemenea, un flux pentru o
utilizare ulterioară , provocâ nd fluxul promis pentru a intra în starea de "rezervat". Un expeditor NU TREBUIE trimite o
PUSH_PROMISE pe un flux cu excepția cazului în care fluxul este fie "deschis" sau "pe jumătate închis (de la
distanță )"; expeditorul trebuie să se asigure că fluxul promis este o alegere valabil pentru un nou identificator curent
( Secțiunea 5.1.1 ) (care este, fluxul promis trebuie să fie în starea "în așteptare").
Deoarece PUSH_PROMISE rezervă un flux, ignorâ nd un cadru PUSH_PROMISE determină starea de flux pentru a deveni
nedeterminată . Un receptor trebuie să trateze primirea unui PUSH_PROMISE pe un flux care nu este nici "deschis", nici
"semi-închis (local)" ca o eroare de conexiune ( secțiunea 5.4.1 ) de tipPROTOCOL_ERROR . În mod similar, un receptor
trebuie să trateze primirea unui PUSH_PROMISE care promite un identificator flux ilegal ( Secțiunea 5.1.1 ) (care este, un
identificator pentru un flux care nu este în prezent în starea "în așteptare"), ca o eroare de conexiune ( secțiunea 5.4 .1 ) de
Cadrul PUSH_PROMISE include padding opțional. Domenii de umplutură și steaguri sunt identice cu cele definite pentru
cadrele de date ( Secțiunea 6.1 ).
6.7 PING
Cadrul PING (tip = 0x6) este un mecanism pentru măsurarea un timp minim dus-întors de la expeditor, precum și a stabili
dacă o conexiune inactiv este încă funcțional. Rame PING pot fi trimise de la orice obiectiv.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| |
| Opac de date (64) |
| |
+ ------------------------------------------------- -------------- +
PING Payload Format
În plus față de antetul cadru, cadre PING TREBUIE să conțină 8 octeti de date din sarcina utilă . Un expeditor poate include
orice valoare se alege și de a folosi aceste bytes, în orice mod.
Receptoare de un cadru PING care nu include un steag ACK trebuie să trimită un cadru PING cu steagul ACK setat în
răspuns, cu o sarcină utilă identic. Răspunsurile PING ar trebui să aibă prioritate mai mare decâ t orice alt cadru.
Cadrul PING definește urmă toarele steagurile:
ACK (0x1):
Bit 1 ființă set indică faptul că acest cadru PING este un răspuns PING. Un obiectiv trebuie să stabilească acest steag în
răspunsurile PING. Un obiectiv nu trebuie să ră spundă la cadre PING conțin acest steag.
Rame PING nu sunt asociate cu orice flux individ. În cazul în care un cadru PING este primit cu o valoare de câmp
identificator flux altele decâ t 0x0, destinatarul trebuie să ră spundă cu o eroare de conexiune (secțiunea 5.4.1 ) de
Primirea unui cadru PING, cu o valoare de câmp lungime altele decâ t 8 trebuie să fie tratată ca o eroare de conexiune
( secțiunea 5.4.1 ) de tip FRAME_SIZE_ERROR .
6.8 GOAWAY
Cadrul GOAWAY (tip = 0x7) informează la egal la distanță pentru a opri crearea de fluxuri de pe această
conexiune. GOAWAY pot fi trimise fie prin client sau server. După ce a trimis, expeditorul va ignora cadre trimise la noi
fluxuri de restul conexiunii. Receptoare de un cadru GOAWAY NU TREBUIE deschide fluxuri suplimentare pe conexiunea,
deși o nouă conexiune poate fi stabilită pentru noi fluxuri. Scopul acestui cadru este de a permite un obiectiv de a opri
grațios accepta fluxuri noi (probabil pentru o repornire sau întreținere), în timp ce încă finisare de fluxuri stabilite
anterior.
Există o condiție inerentă cursă între un punct final de pornire noi fluxuri și trimiterea la distanță un cadru GOAWAY. Să se
ocupe de acest caz, GOAWAY conține identificatorul flux de ultima fluxul care a fost prelucrat pe final trimiterea în acest
sens. Dacă receptorul a GOAWAY utilizat fluxuri care sunt mai noi decâ t identificatorul de flux indicat, ei nu au fost
prelucrate de că tre expeditor și receptor poate trata fluxuri ca și cum acestea nu ar fi fost creată , la toate (prin urmare,
receptorul poate doriți să re-crea fluxurile mai tâ rziu pe o conexiune nouă ).
Obiectivele ar trebui să trimită întotdeauna un cadru GOAWAY înainte de a închide o conexiune, astfel încâ t telecomanda
poate ști dacă un curent a fost parțial prelucrate sau nu. De exemplu, dacă un client HTTP trimite un POST, în același timp,
că un server închide o conexiune, clientul poate nu știu dacă serverul a început pentru a procesa această cerere POST dacă
serverul nu trimite un cadru GOAWAY pentru a indica unde sa oprit de lucru. Un obiectiv ar putea alege pentru a închide o
conexiune fără a trimite GOAWAY pentru incorect colegii.
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 | Ultima-Stream-ID (31) |
+ - + ----------------------------------------------- -------------- +
| Cod de eroare (32) |
+ ------------------------------------------------- -------------- +
| Suplimentare Debug de date (*) |
+ ------------------------------------------------- -------------- +
GOAWAY Payload Format
Cadrul GOAWAY nu definește nici steaguri.
Cadrul GOAWAY se aplică conexiunii, nu un anumit curent. Un obiectiv trebuie să trateze un GOAWAY cadru cu un
identificator de flux, alta decâ t 0x0 ca o eroare de conexiune ( secțiunea 5.4.1 ) de tipPROTOCOL_ERROR .
Ultima identificatorul curent în cadrul GOAWAY conține identificatorul flux de numă rul cel mai mare pentru care
expeditorul a cadrului GOAWAY a primit de cadre și-ar fi luat o acțiune pe. Toate fluxurile de pâ nă la și inclusiv fluxul
identificate ar fi putut fi procesate într-un fel. Ultima identificatorul curent poate fi setat la 0 în cazul în care au fost
prelucrate nu fluxuri.
 Notă : În acest context, "prelucrate", înseamnă că unele date din fluxul a fost trecut la unele strat mai mare de software
care ar putea fi luat unele măsuri, ca rezultat.
Dacă o conexiune termină fă ră cadru GOAWAY, această valoare este efectiv mai înalt posibil identificatorul flux.
Pe fluxuri cu identificatori mai mici sau egale numerotate care nu au fost închise complet înainte de conexiunea fiind
închis, cererile re-încearcă , tranzactii, sau orice activitate de protocol nu este posibilă (cu excepția acțiunilor idempotenta
cum ar fi HTTP GET, PUT sau DELETE) . Orice activitate de protocol care utilizează fluxuri de mare numerotate pot fi
rejudecat în condiții de siguranță , folosind o nouă conexiune.
Activitatea pe fluxuri numerotate mai mici sau egale cu ultimul identificatorul curent s-ar putea finaliza în continuare cu
succes. Expeditorul unui cadru GOAWAY s-ar putea închide grațios pe o conexiune prin trimiterea unui cadru GOAWAY,
menținâ nd legătura într-o stare deschisă pâ nă câ nd toate în curs de fluxuri complet.
Un obiectiv poate trimite mai multe cadre GOAWAY dacă circumstanțele se schimbă . De exemplu, un obiectiv care trimite
GOAWAY cu NO_ERROR timpul opririi grațios ar putea întâ lni, ulterior, o stare care necesită încetarea imediată a
conexiunii. Ultima identificatorul flux de la ultima GOAWAY cadru primit indică care fluxuri ar fi putut fi
acționat. Serverele nu trebuie să crească valoarea pe care o trimite în ultima identificatorul de flux, deoarece acest lucru ar
provoca clienții să renunțe la a reîncerca automat de cereri în cazul în care un cadru GOAWAY este pierdut.
După trimiterea unui cadru GOAWAY, expeditorul poate debarasa de cadre pentru fluxuri cu identificatori mai mari decâ t
ultimul fluxul de identificat. Cu toate acestea, orice cadre care modifică starea conexiunii nu poate fi complet ignorate. De
exemplu, antete , PUSH_PROMISE și CONTINUATION cadre trebuie să fie prelucrate minim pentru a asigura starea de
menținut pentru compresie antet este consistent (a se vedeasecțiunea 4.3 ); similar, cadre de date trebuie să fie luate în
considerare pentru fereastra de control al fluxului de conexiune. Imposibilitatea de a procesa aceste cadre pot cauza de
control al fluxului sau antet de stat de compresie pentru a deveni nesincronizate.
Cadrul GOAWAY conține, de asemenea, un cod de eroare de 32 de biți ( secțiunea 7 ) care conține motivul pentru
închiderea conexiunii.
Obiective POATE adă ugați date opace la încă rcă tura de orice cadru GOAWAY. Date suplimentare de depanare este destinat
pentru scopuri de diagnosticare numai și nu are nici o valoare semantică . Informații de depanare ar putea conține date
sensibile de confidențialitate, de securitate sau. Date de depanare memorat sau altfel stocate persistent TREBUIE să aibă
garanții adecvate pentru a preveni accesul neautorizat.
6.9 WINDOW_UPDATE
Cadrul WINDOW_UPDATE (tip = 0x8) este utilizat pentru a implementa controlul debitului; a se vedeaSecțiunea 5.2 pentru
o privire de ansamblu.
Control al fluxului operează la două niveluri: pe fiecare flux în parte și pe întreaga conexiune.
Ambele tipuri de control al fluxului sunt-hop-by-hop; adică , numai între cele două obiective. Intermediarii nu transmite
WINDOW_UPDATE rame între conexiuni dependente. Cu toate acestea, de reglare a debitului de transfer de date prin orice
receptor poate provoca indirect propagarea informației de control al fluxului spre expeditorul original.
De control al debitului se aplică numai pentru cadre, care sunt identificate ca fiind supuse de control al fluxului. Dintre
tipurile de cadre, definite în acest document, aceasta include doar DATE cadru. Cadre care sunt exceptate de la controlul
fluxului trebuie să fie acceptate și procesate, cu excepția cazului în receptorul este în imposibilitatea de a aloca resurse
pentru manipularea cadru. Un receptor poate ră spunde cu o eroare de curent ( Secțiunea 5.4.2 ) sau eroare de conexiune
( secțiunea 5.4.1 ) de tip FLOW_CONTROL_ERROR în cazul în care acesta este în imposibilitatea de a accepta un cadru.
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 | Window Size Increment (31) |
+ - + ----------------------------------------------- -------------- +
Format Payload WINDOW_UPDATE
Sarcina utilă a unui cadru WINDOW_UPDATE este unul rezervat bit, plus o fă ră semn de 31 biți numă r întreg care indică
numă rul de octeți care expeditorul poate transmite, în plus față de fereastra de control al fluxului existent. Gama legal
pentru sporul la fereastra de control al fluxului este de 1 pâ nă la 2 - 1 (0x7fffffff) bytes.
31
Cadrul WINDOW_UPDATE nu definește nici steaguri.
Cadrul WINDOW_UPDATE pot fi specifice pentru un flux sau întreaga conexiune. În primul caz, fluxul de identificare cadrul
indică fluxul afectate; în al doilea caz, valoarea "0" indică faptul că întreaga conexiune este subiectul a cadrului.
WINDOW_UPDATE pot fi trimise de că tre un coleg care a trimis un cadru care poartă steagul END_STREAM. Aceasta
înseamnă că un receptor poate primi o ramă WINDOW_UPDATE pe o "jumătate închiși (la distanță )" sau flux "închis". Un
receptor NU TREBUIE trata acest lucru ca pe o eroare, a se vedeasecțiunea 5.1 .
Un receptor care primește un cadru controlat de debit trebuie să reprezinte întotdeauna pentru contribuția sa în fereastra
de control al fluxului de legă tură , excepția cazului în care tratează acest receptor ar fi o eroare de conexiune ( secțiunea
5.4.1 ). Acest lucru este necesar chiar dacă rama este în eroare. Deoarece expeditorul contează rama spre fereastra de
control al fluxului, dacă receptorul nu, fereastra de control al debitului de la transmițător și receptor pot deveni diferite.
6.9.1 Fereastra Flow Control
De control al fluxului în HTTP / 2 este implementat folosind o fereastră ținut de fiecare expeditor pe fiecare flux. Fereastra
de control al fluxului este o valoare întreg simplu, care indică cât de multe bytes de date este permisă expeditorul să
transmită ; ca atare, dimensiunea sa este o măsură a capacității de tamponare a receptorului.
Două ferestre de control al fluxului sunt aplicabile: fereastra de control al fluxului de curent și fereastra de control al
fluxului de conexiune. Expeditorul nu trebuie să trimită un cadru controlat de debit cu o lungime care depă șește spațiul
disponibil în oricare din ferestrele de control al fluxului promovate de către receptor.Rame cu lungime zero cu indicatorul
END_STREAM (de exemplu, un cadru de date gol) pot fi transmise în cazul în care nu există nici un spațiu disponibil în
fiecare fereastră de control al fluxului.
Pentru calcule de control al debitului, cadru antetul 8 byte nu este luată în calcul.
După trimiterea unui cadru controlat flux, expeditorul reduce spațiul disponibil în ambele ferestre de lungimea cadrului
transmis.
Receptorul de un cadru trimite un cadru WINDOW_UPDATE, deoarece consumă de date și eliberează spațiu în ferestrele
de control al debitului. Cadre WINDOW_UPDATE separate sunt trimise pentru fluxul și nivelul de legă tură ferestre de
control al debitului.
Un expeditor care primește un cadru WINDOW_UPDATE actualizează fereastra corespunză toare cu suma specificată în
cadru.
Un expeditor nu trebuie să permită o fereastră de control al fluxului de a depă și 2 - 1 bytes. Dacă un expeditor primește
31
un WINDOW_UPDATE care cauzeaza o fereastră de control al debitului pentru a depăși această maximă se termina
TREBUIE să fie curentul sau conexiunea, după caz. Pentru fluxuri, expeditorul trimite un RST_STREAM cu codul de eroare
de FLOW_CONTROL_ERROR cod; pentru conexiunea, oGOAWAY cadru cu un FLOW_CONTROL_ERROR cod.
Cadre Flow controlate ale expeditorului și cadrele WINDOW_UPDATE de receptor sunt complet asincron în raport unul cu
altul. Această proprietate permite un receptor pentru a actualiza agresiv dimensiunea ferestrei păstrat de că tre expeditor,
pentru a preveni fluxuri de la trage de timp.
Un expeditor care este în imposibilitatea de a trimite date pe un flux de cauza, fie fereastra de control al fluxului fiind zero
sau mai mică poate trimite un cadru blocate ( secțiunea 6.12 ), în scopul de a informa receptorul de o problemă potențială
de control al fluxului.
6.9.2 inițială dimensiunea ferestrei Flow Control
Atunci câ nd o conexiune HTTP / 2 este stabilit mai întâ i, noi fluxuri sunt create cu o inițială fereastră de control al fluxului
de mă rime de 65,535 bytes. Fereastra de control al fluxului de conexiune este 65535 bytes. Ambele obiective pot ajusta
fereastra inițială dimensiunea de noi surse de incluzâ nd o valoare
pentruSETTINGS_INITIAL_WINDOW_SIZE în SETTINGS cadru care face parte din prefață de conectare.Dimensiunea
inițială fereastră de control al fluxului de conectare nu poate fi modificată .
Înainte de a primi un SETTINGS cadru care stabilește o valoare de SETTINGS_INITIAL_WINDOW_SIZE , un obiectiv poate

folosi numai implicit inițial fereastra dimensiunea la trimiterea de cadre controlat de debit. În mod similar, fereastra de
control al fluxului de conexiune este setat la implicit inițială fereastră dimensiune pâ nă câ nd un cadru WINDOW_UPDATE
este primit.
Un SETTINGS cadru poate modifica inițial fereastra de control al fluxului de dimensiunea pentru toate fluxurile de
curent. În cazul în care valoarea de SETTINGS_INITIAL_WINDOW_SIZE schimbă ri, un receptor trebuie să se adapteze
dimensiunea tuturor ferestrelor de control al fluxului de curent, care se menține de diferența dintre valoarea nouă și
vechea valoare. Un SETTINGS cadru nu poate modifica fereastra de control al fluxului de conexiune.
Un obiectiv trebuie să trateze o schimbare a SETTINGS_INITIAL_WINDOW_SIZE care cauzează orice fereastră de control al

fluxului să depă șească dimensiunea maximă ca o eroare de conexiune ( secțiunea 5.4.1 ) de tip FLOW_CONTROL_ERROR .
O schimbare a SETTINGS_INITIAL_WINDOW_SIZE poate cauza spațiului disponibil într-o fereastră de reglare a debitului

pentru a deveni negativ. Un expeditorul trebuie să urmă rească fereastra negativ de control al fluxului, și nu trebuie să
trimită noi cadre controlat de debit pâ nă câ nd primește cadre WINDOW_UPDATE care produc fereastra de control al
fluxului de a deveni pozitiv.
De exemplu, în cazul în care clientul trimite 60KB imediat la stabilirea conexiunii, iar serverul setează fereastra inițială
dimensiunea pentru a fi 16KB, clientul va recalcula fereastra de control al fluxului disponibile pentru a fi-44KB la
primirea SETTINGS cadrului. Clientul pă strează o fereastră de control al fluxului negativ pâ nă cadre WINDOW_UPDATE
restabili fereastra de a fi pozitiv, după care clientul poate relua trimiterea.
6.9.3 Reducerea dimensiunea ferestrei Stream
Un receptor care dorește să utilizeze o fereastră de control al fluxului mai mică decâ t dimensiunea actuală poate trimite un
nou SETTINGS cadru. Cu toate acestea, receptorul trebuie să fie pregă tit să primească date care depă șește această
dimensiune fereastră , deoarece expeditorul poate trimite date care depă șește limita inferioară , înainte de
procesarea SETTINGS cadru.
După trimiterea unui cadru setă ri care reduce inițial fereastra de control al fluxului de mă rimea, un receptor are două
opțiuni pentru administrarea fluxurilor care depă șesc limitele de control al fluxului:
1. Receptorul poate trimite imediat RST_STREAM cu FLOW_CONTROL_ERROR cod de eroare pentru fluxurile afectate.

2. Receptorul poate accepta fluxuri și tolera capul rezultat din linia de blocare, trimiterea de cadre WINDOW_UPDATE
ca consumă date.
6.10 CONTINUARE
Cadrul CONTINUARE (tip = 0x9) este utilizat pentru a continua o secvență de fragmente bloc antet (secțiunea 4.3 ). Orice
numă r de cadre CONTINUATION pot fi trimise pe un flux existent, atâta timp cât cadrul precedent este pe aceeași fluxul și
este un antete , PUSH_PROMISE sau cadru CONTINUARE fără setul END_HEADERS pavilion.
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
+ --------------- + --------------- + ----------------- --------------
+
+ ------------------------------------------------- -------------- +
| Padding (*) ...
+ ------------------------------------------------- -------------- +
CONTINUARE Frame Payload
Cadru CONTINUARE utilă are urmă toarele câ mpuri:
Pad mare:
Pad Low:
Un fragment bloc antet ( secțiunea 4.3 ).
Padding:
Cadrul CONTINUARE definește urmă toarele steagurile:
END_HEADERS (0x4):
Bit 3 ființă set indică faptul că acest cadru se încheie un bloc antet ( secțiunea 4.3 ).
În cazul în care bitul END_HEADERS nu este stabilit, acest cadru trebuie să fie urmată de un alt cadru CONTINUARE. Un
receptor trebuie să trateze primirea de orice alt tip de cadru sau un cadru pe un alt flux ca o eroare de conexiune
PAD_LOW (0x8):
PAD_HIGH (0x10):
Sarcina utilă a unui cadru CONTINUARE conține un fragment bloc antet ( secțiunea 4.3 ).
Cadrul CONTINUARE schimba starea de conectare astfel cum este definit în secțiunea 4.3 .
Rame CONTINUATION trebuie să fie asociat cu un flux. În cazul în care un cadru continuare este primit al că rui flux
identificator de câ mp este 0x0, beneficiarul trebuie să răspundă cu o eroare de conexiune (secțiunea 5.4.1 ) de tip
PROTOCOL_ERROR.
Un cadru CONTINUARE trebuie să fie precedată de o antete , PUSH_PROMISE sau continuarea cadru fără setul de pavilion
END_HEADERS. Un beneficiar care observă încă lcarea acestei reguli trebuie să răspundă cu o eroare de conexiune
Cadrul CONTINUARE include padding opțional. Domenii de umplutură și steaguri sunt identice cu cele definite pentru
cadrele de date ( Secțiunea 6.1 ).
6.11 ALTSVC
Cadrul ALTSVC (tip = 0xA) reclama disponibilitatea de un serviciu alternativ de client. Acesta poate fi transmis în orice
moment, pentru un flux-client inițiat existente sau curent 0, și este destinat să permită servere pentru a încă rca echilibru
sau altfel trafic segment; a se vedea [ALT-SVC] pentru detalii (în special,secțiunea 2.4 , care prezintă manipularea client de
servicii alternative).
Un cadru ALTSVC pe un flux-client inițiat indică faptul că serviciul de alternativă transmis este asociat cu originea care
flux.
Un cadru ALTSVC pe flux 0 indică faptul că serviciul de alternativă transmis este asociat cu originea cuprinse în domeniul
Originea cadrului. O asociere cu o origine care clientul nu ia în considerare autoritate pentru conexiunea curentă trebuie
să fie ignorată .
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Max-Age (32) |
+ ------------------------------- + --------------- + - --------------
+
| Port (16) | Proto-Len (8) |
+ ------------------------------- + --------------- + - --------------
+
| Protocol-ID (*) |
+ --------------- + --------------------------------- -------------- +
| Host-Len (8) | Host (*) ...
+ --------------- + --------------------------------- -------------- +
| Origine? (*) ...
+ ------------------------------------------------- -------------- +
ALTSVC Frame Payload
Cadrul ALTSVC conține urmă toarele câ mpuri:
Max-vâ rstă :
O, pe 32 de biți întreg fă ră semn care indică durata de viață prospețime a asociației de servicii de alternativă ,
conform [ALT-SVC] , secțiunea 2.2 .
Port:
O, 16-bit întreg fă ră semn care indică faptul că portul serviciului de alternativă este disponibil la.
Proto-Len:
O, de 8-biți întreg fără semn care indică lungimea, în octeți, a câ mpului Protocol-ID.
Protocol-ID:
O succesiune de bytes (lungime determinate de Proto-Len) Conținâ nd identificatorul de protocol ALPN serviciului
de alternativă .
Host-Len:
O, 8 biți întreg fă ră semn care indică lungimea în octeți, a câ mpului gazdă .
Gazdă :
O secvență de caractere (lungime determinate de Host-Len) Care conține un șir ASCII indică gazda că serviciul de
alternativă este disponibil la. Un nume de domeniu internaționalizate [IDNA] trebuie să fie exprimată folosind un
etichetelor.
Origine:
O secvență opțională de caractere (lungime determinată prin scă derea lungimii toate câ mpurile precedente din
lungimea cadrului) care conține serializarea ASCII unei origini ( [RFC6454] , secțiunea 6.2) că serviciul alternativ este
aplicabilă .
Cadrul ALTSVC nu definește nici steaguri.
Cadrul ALTSVC este destinat pentru primirea de că tre clienți; un server care primește un cadru ALTSVC TREBUIE să -l
trateze ca pe o eroare de conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR .
Cadrul ALTSVC este prelucrat-hop-hop de. Un intermediar NU TREBUIE transmite cadre ALTSVC, deși se poate utiliza
informațiile conținute în ALTSVC rame în formarea de noi cadre ALTSVC pentru a trimite la clientii proprii.
6.12 BLOCAT
Cadrul BLOCAT (tip = 0XB) indică faptul că expeditorul este în imposibilitatea de a trimite date din cauza într-o fereastră
de control al fluxului închis.
[ rfc.comment.2 : Cadrul BLOCAT este inclus în acest proiect de versiune pentru a facilita experimentare.Dacă rezultatele
experimentului nu oferă un feedback pozitiv, acesta ar putea fi eliminate.]
Cadrul BLOCATĂ este folosit pentru a oferi feedback cu privire la performanța de control al fluxului în scopul de
optimizare a performanțelor și depanare. Cadrul BLOCAT pot fi trimise de către un inter pares atunci câ nd datele
controlate de debit nu pot fi trimise ca urmare a controlului fluxului de conexiune sau la nivel de flux. Acest cadru nu
trebuie adresată în cazul în care există alte motive care împiedică datelor de a fi trimise, fie o lipsă de date disponibile, sau
transportul stau la baza fiind blocat.
Cadrul BLOCATE este trimis pe fluxul care este blocat, adică , fluxul cu un numă r non-pozitiv de octeți disponibili în
fereastra de control al fluxului. Un cadru BLOCAT poate fi trimis pe flux 0x0 pentru a indica faptul că de control al fluxului
nivel de conexiune este blocat.
Un obiectiv NU TREBUIE trimite orice cadre ulterioare blocat pâ nă fereastra afectate de control al fluxului devine
pozitiv. Acest lucru înseamnă că WINDOW_UPDATE cadre sunt primite sauSETTINGS_INITIAL_WINDOW_SIZE este
crescută înainte de cadre mai BLOCAT pot fi trimise.
Cadrul BLOCAT definește nici steaguri și nu conține nici o sarcină utilă . Un receptor trebuie să trateze primirea unui cadru
blocate cu o sarcină utilă ca o eroare de conexiune ( secțiunea 5.4.1 ) de tipFRAME_SIZE_ERROR .
7. Coduri de eroare
Codurile de eroare sunt domenii pe 32 de biți, care sunt utilizate în RST_STREAM și GOAWAY cadre pentru a transmite
motivele pentru fluxul sau eroare de conexiune.
Coduri de eroare împă rtă șesc un spațiu comun de cod. Unele coduri de eroare se aplică numai în anumite condiții și nu au
semantică definite în anumite tipuri de cadru.
Sunt definite următoarele coduri de eroare:
NO_ERROR (0):
Condiția asociat nu este ca urmare a unei erori. De exemplu, o GOAWAY ar putea include acest cod pentru a indica
oprirea grațioasă a unei conexiuni.
PROTOCOL_ERROR (1):
Obiectivul a detectat o eroare de protocol nespecific. Această eroare este pentru a fi un cod de eroare mai specific nu
este disponibil.
INTERNAL_ERROR (2):
Obiectivul întâ lnit o eroare internă neașteptată .
FLOW_CONTROL_ERROR (3):
Efectului detectat că la egal la egal sa încă lcat protocolul de control al fluxului.
SETTINGS_TIMEOUT (4):
Obiectivul a trimis un cadru setă ri, dar nu a primit un răspuns în timp util.Consultați Setă ri de sincronizare ( Secțiunea
6.5.3 ).
STREAM_CLOSED (5):
Obiectivul a primit un cadru după un flux a fost pe jumătate închis.
FRAME_SIZE_ERROR (6):
Obiectivul a primit un cadru care a fost mai mare decâ t dimensiunea maximă pe care o susține.
REFUSED_STREAM (7):
Obiectivul refuză fluxul înainte de a efectua orice prelucrare de aplicare, a se vedea secțiunea 8.1.4 pentru detalii.
CANCEL (8):
Folosit de final pentru a indica faptul că nu mai este nevoie de fluxul.
COMPRESSION_ERROR (9):
Punctul final este incapabil să mențină contextul compresie pentru conexiune.
Connect_error (10):
Conexiunea stabilit ca ră spuns la o cerere CONNECT ( secțiunea 8.3 ) a fost de resetare sau anormal de închisă .
ENHANCE_YOUR_CALM (11):
Efectului detectat că la egal la egal sa se prezintă un comportament pe o anumită perioadă de timp, care a determinat-o
să refuze să proceseze cadre suplimentare.
INADEQUATE_SECURITY (12):
Transportul care stau la baza are proprietă ți care nu îndeplinesc cerințele minime impuse de acest document (a se
vedea secțiunea 9.2 ) sau final.
8. Schimburi de mesaje HTTP
HTTP / 2 este destinat pentru a fi cât mai compatibil cu utiliză rile actuale ale HTTP. Acest lucru înseamnă că , din punctul
de vedere al aplicatiilor client si server, caracteristici ale protocolului sunt neschimbate.Pentru a realiza acest lucru, toate
semantică cerere și de ră spuns sunt pă strate, deși sintaxa de a transmite aceste semantica sa schimbat.
Astfel, caietul de sarcini și cerințele de Semantica HTTP/1.1 și conținut [HTTP-P2] , Cereri condiționale[HTTP-p4] , Cereri
Gama [HTTP-P5] , Cache [HTTP-P6] și Authentication [HTTP-P7] se aplică la HTTP / 2.Porțiuni selectate ale HTTP/1.1
Mesaj de sintaxă și de rutare [HTTP-p1] , cum ar fi HTTP și HTTPS schemele URI, sunt de asemenea aplicabile în HTTP / 2,
dar exprimarea acestor semantică pentru acest protocol sunt definite în secțiunile de mai jos.
8.1 HTTP Cerere / Schimb de raspuns
Un client trimite o cerere HTTP pe un nou flux, folosind un identificator de flux nefolosită anterior (secțiunea 5.1.1 ). Un
server trimite un ră spuns HTTP pe aceeași fluxul ca cererea.
Un mesaj HTTP (cerere sau ră spuns) este format din:
1. o antete cadru, urmat de zero sau mai multe CONTINUATION cadre (care conțin anteturile mesajelor, a se
vedea [HTTP-p1] , secțiunea 3.2 ), și
2. zero sau mai multe DATA cadre (care conțin sarcina utilă mesaj; vezi [HTTP-p1] , secțiunea 3.3 ), și
3. opțional, un header- cadru, urmat de zero sau mai multe CONTINUATION cadre (care conțin trailer-o parte, dacă
este prezent, a se vedea [HTTP-p1] , secțiunea 4.1.2 ).
Ultimul cadru din secvența poartă un steag END_STREAM, deși un header- cadru care poartă drapelul END_STREAM poate
fi urmată de CONTINUATION cadre care transporta orice porțiuni ră mase ale blocului antet.
Alte cadre (din orice flux) nu trebuie să apară între oricare header- cadru și urmă toarele CONTINUATIONcadrele (dacă
există ), nici între CONTINUATION cadre.
În caz contrar, cadre pot alterna pe fluxul dintre aceste cadre, dar aceste cadre nu transporta semantica HTTP. În
special, antete cadre (și orice CONTINUATION cadre care urmează ), altele decâ t prima și opționale ultimele cadrele din
această secvență nu poartă semantica HTTP.
Trailing câ mpuri antet sunt transportate într-un bloc antet care se termină , de asemenea, fluxul. Că este, o secvență de
pornire cu un header- cadru, urmat de zero sau mai multe CONTINUATION cadre, în cazul în care header- cadru poartă un
steag END_STREAM. Blocuri antet după prima care nu termina fluxul nu sunt parte a unei cereri HTTP sau ră spuns.
Un schimb de cerere HTTP / răspuns consumă complet un singur flux. O cerere începe cu antete cadru care pune fluxul
într-o stare "deschis" și se termină cu o END_STREAM rulment cadru, ceea ce face ca fluxul de a deveni "pe jumă tate
închis" pentru client. Un răspuns începe cu un header- cadru și se termină cu o END_STREAM rulment cadru, urmat
opțional de CONTINUATION cadre, care pune fluxul în starea "închis".
8.1.1 Răspunsuri informaționale
Seria 1xx de coduri de stare de ră spuns HTTP ( [HTTP-P2] , secțiunea 6.2 ), nu sunt acceptate în HTTP / 2.
Cazul de utilizare cele mai comune pentru 1xx se folosește un câ mp de antet Asteptati-va cu un 100-
continua simbolică (colocvial, "Asteptati / continua") pentru a indica faptul că clientul se așteaptă la o 100
(Continuare) non-finala cod de stare de răspuns, dintre care primire indică faptul că clientul ar trebui să continue
trimiterea corpului cerere, în cazul în care acesta nu a fă cut-o deja.
De obicei, se așteaptă / continuare este utilizat de că tre clienții care doresc să evite trimiterea unei cantită ți mari de date
într-un corp cerere, doar pentru a avea cererea respinsă de către serverul de origine (lăsâ nd astfel conexiunea potențial
inutilizabil).
HTTP / 2 nu permite mecanismul Asteptati / continua; în cazul în care serverul trimite un cod de stare finală de
respingere a cererii, se poate face acest lucru fă ră a face conexiunea de bază inutilizabil.
Rețineți că acest lucru înseamnă HTTP / 2 clienti care trimit cereri cu organisme pot pierde cel puțin o că lă torie dus-întors
de date trimise atunci câ nd cererea este respinsă . Acest lucru poate fi atenuat prin limitarea cantită ții de date trimise
pentru prima că lătorie dus-întors de clienti-lă țime de bandă limitată , în așteptarea unui cod de stare finală .
Alte coduri de stare 1xx definite nu sunt aplicabile HTTP / 2. De exemplu, semantica 101 (Protocoale de comutare) nu sunt
potrivite pentru un protocol multiplexate. De asemenea, 102 (procesare) nu mai este necesară , deoarece HTTP / 2 are un
mijloc separate păstrează legă tura de viață .
Această diferență între versiunile de protocol necesită o manipulare specială de că tre intermediari, care traduce între ele:
 Un intermediar care gateway-uri HTTP/1.1 la HTTP / 2 trebuie să genereze un 100 (Continuare), răspuns în cazul în
care o cerere primită include și Asteptati câ mp de antet cu un 100-continuasimbolică ( [HTTP-p2] , secțiunea
5.1.1 ), dacă nu se poate genera imediat un cod de stare finală . Ea nu trebuie să transmită 100-
continua așteptare în câ mpurile de antet cerere.
 Un intermediar care gateway-uri HTTP / 2 pentru a HTTP/1.1 poate adă uga un câ mp de antet Asteptati-va cu
un 100-continuaașteptare atunci câ nd transmit o cerere care are un corp; a se vedea[HTTP-p2] , Secțiunea
5.1.1 pentru cerințe specifice.
 Un intermediar care gateway-uri HTTP / 2 pentru a HTTP/1.1 să aruncați toate celelalte ră spunsuri informaționale
1xx.
8.1.2 Exemple
Această secțiune prezintă cereri HTTP/1.1 și ră spunsuri, cu ilustrații de echivalente HTTP / 2 cereri și ră spunsuri.
O cerere HTTP GET include câmpuri de antet de solicitare și nici un organism și, prin urmare, se transmite ca un
singur antete cadru, urmat de zero sau mai multe CONTINUATION cadre conțin blocul serializat de câ mpuri antet
cerere. Header- cadru în cele ce urmează are atâ t END_HEADERS și steaguri END_STREAM
stabilite; nu CONTINUATION cadre sunt transmise:
GET / HTTP/1.1 resursă antete

Gazdă: example.org ==> + END_STREAM
Accept: image / jpeg + END_HEADERS
: Metoda = GET
: Schema = https
: Path = / resurse
gazdă = example.org
accepta = image / jpeg
În mod similar, un răspuns care include doar linii de antet de ră spuns este transmisă ca anteturi cadru (din nou, urmat de
zero sau mai multe CONTINUARE rame) care conține blocul serializate de linii de antet de răspuns.
HTTP/1.1 304 nemodificate antete

ETag: "xyzzy" ==> + END_STREAM
Expira: Joi, douăzeci și trei ianuarie ... + END_HEADERS
: Stare = 304
ETAG: "xyzzy"
expiră: Joi, douăzeci și trei
ianuarie ...
O cerere POST HTTP care include câ mpuri antet cerere și date sarcină utilă este transmisă ca un header-cadru, urmat de
zero sau mai multe CONTINUATION cadre ce conțin câ mpurile de antet cerere, urmat de una sau mai multe DATA cadre,
cu ultima CONTINUAREA (sau antetele ) cadru cu END_HEADERS setul de pavilion și finală DATA cadrul avâ nd un set flag
END_STREAM:
POST / resursă HTTP/1.1 antete

Gazdă: example.org ==> - END_STREAM
Content-Type: image / jpeg - END_HEADERS
Content-Length: 123: metoda = POST
: Path = / resurse
{Date binare}-tip de conținut = image / jpeg
CONTINUARE
+ END_HEADERS
: Autoritatea = example.org
: Schema = https
Conținutul de lungime = 123
DATE
+ END_STREAM
{Date binare}
Rețineți că datele care contribuie la orice câ mp de antet dat ar putea fi răspâ ndit între fragmente de bloc antet. Alocarea de
linii de antet de cadre în acest exemplu este doar ilustrativ.
Un ră spuns care include câ mpuri de antet și date sarcină utilă este transmisă ca anteturi cadru, urmat de zero sau mai
multe CONTINUATION cadre, urmat de una sau mai multe DATA cadre, cu ultimul DATA cadru din secvență avâ nd flag
END_STREAM:
HTTP/1.1 200 OK antetele

Content-Type: image / jpeg ==> - END_STREAM
Content-Lungime: 123 + END_HEADERS
: Stare = 200
{Date binare}-tip de conținut = image / jpeg
DATE
+ END_STREAM
{Date binare}
Trailing câ mpuri antet sunt trimise ca un bloc antet după atât cererea sau blocul de antet de ră spuns și toateDATA cadrele
au fost trimise. Header- cadru începâ nd cu blocul de antet remorcilor are setul steag END_STREAM.
HTTP/1.1 200 OK antetele

Content-Type: image / jpeg ==> - END_STREAM
Transfer-Encoding: + END_HEADERS chunked
Trailer: Foo: status = 200
-Tip de conținut 123 = image / jpeg
{Date binare} remorcă = Foo
0
Foo: bar DATE
- END_STREAM
{Date binare}
Antete
+ END_STREAM
+ END_HEADERS
foo: bar
8.1.3 HTTP Header Fields
Câmpuri antet HTTP transporta informații ca o serie de perechi cheie-valoare. Pentru o listă de antete HTTP înregistrate,
vezi mesaj Antet Câmp Registrul menținută la < http://www.iana.org/assignments/message-headers >.
În timp ce HTTP/1.x folosit mesajul de începe-line (a se vedea [HTTP-p1] , secțiunea 3.1 ) pentru a transmite obiectivul
URI și metoda a cererii, precum și codul de stare de ră spuns, HTTP / 2 foloseste pseudo-antete speciale începâ nd cu ":"
pentru aceste sarcini.
La fel ca în HTTP/1.x, nume de câ mpuri antet sunt șiruri de caractere ASCII, care sunt comparate într-un mod case-
insensitive. Cu toate acestea, numele de câ mpuri antet trebuie să fie convertite în litere mici, înainte de codare în HTTP /
2. O cerere sau ră spuns care conține nume de mari câmp de antet trebuie să fie tratate ca malformat ( secțiunea 8.1.3.5 ).
HTTP / 2 nu utilizează domeniul antet Connection pentru a indica domenii "-hop-by-hop" antet; în acest protocol,
metadate-conexiune specific este transmis prin alte mijloace. Ca atare, un mesaj care conține conexiune HTTP / 2 trebuie
să fie tratate ca malformat ( secțiunea 8.1.3.5 ).
Acest lucru înseamnă că un intermediar transforma un mesaj HTTP/1.x la http / 2 va trebui pentru a elimina orice
Câmpuri titluri nominalizate de domeniul antet Connection, împreună cu domeniul antet conexiune în sine. Astfel de
intermediari ar trebui să elimine, de asemenea, alte domenii de antet-conexiune specifice, cum ar fi-ține în viață , Proxy-
Connection, Transfer-Encoding și upgrade, chiar dacă acestea nu sunt numiți de că tre conexiune.
O excepție de la acest lucru este domeniul antet TE, care pot fi prezente într-o cerere HTTP / 2, dar atunci câ nd este nu
trebuie să conțină valoare, altele decâ t "remorci".
Notă :
HTTP / 2 intenționat nu are suport pentru upgrade la un alt protocol. Metodele de strâ ngere de mâ nă descrise
în Secțiunea 3 sunt considerate suficiente pentru a negocia folosirea de protocoale alternative.
8.1.3.1 Cerere Header Fields
HTTP / 2 definește un numă r de câ mpuri antet, începâ nd cu un colon ":" personaj care transporta informații despre ținta
cerere:
 The : Metodacâ mp de antet include metoda HTTP ( [HTTP-p2] , secțiunea 4 ).

 The : Schemacâ mp de antet include partea schema de țintă URI ( [RFC3986] , secțiunea 3.1 ).
: Schema nu se limitează la http și httpsschemed URI-uri. Un proxy sau gateway-ul poate traduce cererile
pentru schemele de non-HTTP, care să permită utilizarea de HTTP pentru a interacționa cu non-HTTP servicii.
 The : Autoritateacâ mp de antet include partea autorită ții de țintă URI ( [RFC3986] , secțiunea 3.2 ).Autoritatea
nu trebuie să includă depasiteuserinfo subcomponentă pentru http sau https schemed URI-uri.
Pentru a se asigura că linia de cerere HTTP/1.1 poate fi reprodus cu exactitate, acest domeniu antet TREBUIE să fie
omise, dacă traducerea dintr-o cerere de HTTP/1.1 care are o țintă cerere origine sau sub formă asterisc (a se
vedea [HTTP-p1] , secțiunea 5.3 ). Clientii care generează HTTP / 2 cereri direct TREBUIE omite în
schimbGazdăcâ mp de antet. Un intermediar care convertește o cerere HTTP / 2 pentru a HTTP/1.1 trebuie să
creeze unGazdă câ mp de antet în cazul în care nu este prezent într-o cerere de copiere a valorii a :
Autoritatea câ mp de antet.
 The : Cale câ mp de antet include calea și interogare pă rți ale țintă URI ( -cale absolutăproducție de
la [RFC3986] și, opțional, un '?' caractere, urmat deîntrebareproducție, a se vedea [RFC3986] ,secțiunea
3.3 și [RFC3986] , secțiunea 3.4 ). Acest câ mp nu trebuie să fie goale; URI-uri care nu conțin o componentă de traseu
trebuie să includă o valoare de "/", cu excepția cazului în care cererea este o cerere OPȚ IUNI în formă asterisc, caz
în care: Cale câ mp de antet TREBUIE să includă "*".
Toate HTTP / 2 cereri TREBUIE să includă exact o valoare validă pentru : Metoda, : Schema, Ș i : Caleheader
domenii, dacă acest lucru este o cerere CONNECT ( secțiunea 8.3 ). O cerere HTTP care omite câ mpuri antet obligatorii
este malformat ( secțiunea 8.1.3.5 ).
Nume de câ mpuri antet care încep cu un colon sunt valabile numai în contextul HTTP / 2. Acestea nu sunt câmpuri antet
HTTP. Implementari NU TREBUIE genera câ mpuri antet care încep cu un colon, dar ele trebuie să ignore orice câ mp de
antet care începe cu un colon. În special, câmpurile de antet cu nume începâ nd cu un colon NU TREBUIE expus ca câ mpuri
antet HTTP.
HTTP / 2 nu definește o modalitate de a transporta identificatorul versiune care este inclus în linia de cerere HTTP/1.1.
8.1.3.2 răspuns Header Fields
O singură : Starecâ mp de antet este definit ca poarta câ mpul pentru cod de stare HTTP (a se vedea[HTTP-
p2] , secțiunea 6 ). Acest câ mp antet TREBUIE să fie incluse în toate ră spunsurile, altfel ră spunsul este incorect ( secțiunea
8.1.3.5 ).
HTTP / 2 nu definește o modalitate de a transporta versiunea motiv sau fraza care este inclus într-o linie de stare
HTTP/1.1.
8.1.3.3 Antet Câmp de comandă
HTTP antet compresie [COMPRESSION] nu pă strează ordinea de câ mpuri antet, deoarece ordinea relativă a câ mpurilor de
antet cu nume diferite, nu este important. Cu toate acestea, în același câmp antet poate fi repetată pentru a forma o listă
(vezi [HTTP-p1] , secțiunea 3.2.2 ), în cazul în care ordinea relativă a valorilor de câ mp de antet este semnificativă . Această
repetiție poate apă rea fie ca un domeniu unic antet cu o lista separata prin virgula de valori, sau ca mai multe câ mpuri
antet, cu o singură valoare, sau orice combinație a acestora. Prin urmare, în acest ultim caz, comanda trebuie protejat
înainte de efectuarea comprimare.
Pentru a pă stra ordinea de mai multe apariții ale unui câmp de antet cu același nume, valorile sale comandate sunt
concatenate într-o singură valoare, folosind un octet cu valori zero (0x0) pentru a le delimita.
După domenii de decompresie, antet care au valori conținâ nd zero octeti (0x0) trebuie să fie împă rțit în mai multe
domenii de antet înainte de a fi prelucrate.
De exemplu, urmă toarea HTTP/1.x bloc antet:
Content-Type: text / html

Cache-Control: max-vârstă = 60, privat
Cache-Control: trebuie să-revalidare
conține trei directive Cache-Control; două în primul câ mp de antet Cache-Control, iar ultima în al doilea câ mp Cache-
Control. Înainte de compresie, ei ar trebui să fie convertit într-o formă similară cu aceasta (cu 0x0 reprezentate ca "\ 0"):
cache-Control: max-vârstă = 60, privat \ 0must-revalidare

-tip de conținut: text / html
Rețineți aici că ordonarea între Content-Type și Cache-Control nu este pă strat, dar ordonarea relativă a directivelor Cache-
Control -, precum și de faptul că primele două au fost, în timp ce ultimul a fost la un alt separate prin virgulă linie - este.
Câmpuri titluri care conțin mai multe valori TREBUIE fi concatenate într-o singură valoare cu excepția cazului în care
ordinea de câ mp de antet este cunoscut a fi nesemnificativ.
Cazul special al set-cookie- Care nu formează o listă separată prin virgulă , dar poate avea mai multe valori - nu
depinde de comanda. set-cookie câ mp de antet pot fi codate ca mai multe valori de câ mp de antet, sau ca o singură
valoare concatenate.
8.1.3.4 Comprimarea Antet domeniul Cookie
Câmp antet Cookie [COOKIE] poate transporta o cantitate semnificativă de date redundante.
Domeniul antet Cookie foloseste o virgulă (";") pentru a delimita cookie-perechi (sau "firimituri"). Acest câ mp de antet nu
respectă lista regulilor de construcție în HTTP (a se vedea [HTTP-p1] , secțiunea 3.2.2 ), care împiedică cookie-perechi de a
fi separate în diferite perechi nume-valoare. Acest lucru poate reduce în mod semnificativ eficiența de compresie ca
cookie-perechi individuale sunt actualizate.
Pentru a permite o mai bună eficiență de compresie, domeniul antet Cookie poate fi împă rțită în câ mpuri antet separate,
fiecare cu unul sau mai multe cookie-perechi. Dacă există mai multe domenii de antet Cookie după decompresie, acestea
trebuie să fie concatenate într-un singur șir de octet folosind două delimitatorul octet de 0x3B, 0x20 (șirul ASCII ";").
Domeniul antet Cookie poate fi împă rțită folosind un octet zero (0x0), astfel cum este definit în secțiunea 8.1.3.3 . Câ nd
decodare, la zero octeți TREBUIE să fie înlocuită cu delimitatorul cookie (";").
8.1.3.5 mesaje malformate
O cerere malformat sau de raspuns este unul care utilizează o secvență valabil de HTTP / 2 rame, dar altfel este invalid din
cauza prezenței de câmpuri antet interzise, lipsa de câ mpuri antet obligatorii, sau includerea de nume de câ mpuri antet
majuscule.
O cerere sau răspuns care include un organism entitate poate include o Conținutul de lungimecâ mp de
antet. O cerere sau de răspuns este de asemenea incorect în cazul în care valoarea a unuiConținutul de
lungimecâ mp de antet nu este egală cu suma necomprimate DATA cadru lungimi de sarcină utilă care formează corpul.
Notă :
The Content-Lengthcâ mp de antet este setat la lungimea de un organism entită ți. Comprimare aDATE cadre

este o funcție de HTTP / 2 care să nu modifice entități.
Intermediarii care prelucrează cereri HTTP sau răspunsuri (de exemplu, toate, altele decâ t cele care acționează în calitate
de intermediari tuneluri) TREBUIE să nu transmită o cerere malformat sau răspuns.
Implementă ri care detectează cererile malformate sau ră spunsuri trebuie să se asigure că fluxul se termină .Pentru cereri
de malformații, un server poate să trimită un ră spuns HTTP înainte de închiderea sau resetarea fluxul. Clientii nu trebuie
să accepte un ră spuns incorect. Rețineți că aceste cerințe sunt destinate să protejeze împotriva mai multor tipuri de
atacuri comune împotriva HTTP; ele sunt în mod deliberat stricte, pentru că fiind permisive pot expune implementari la
aceste vulnerabilități.
8.1.4 Cerere Mecanisme de fiabilitate în HTTP / 2
În HTTP/1.1, un client HTTP este în imposibilitatea de a încerca din nou o cerere de non-idempotenta atunci câ nd apare o
eroare, deoarece nu există nici un mijloc de a determina natura erorii. Este posibil ca unele servere de prelucrare a avut
loc înainte de eroare, ceea ce ar putea duce la efecte nedorite în cazul în care cererea a fost reattempted.
HTTP / 2 prevede două mecanisme pentru asigurarea unei garanții pentru un client care o cerere nu a fost procesată :
 GOAWAY Cadrul reprezintă cel mai mare numă r de flux care ar fi putut fi prelucrate. Prin urmare, cererile de pe fluxuri,
cu numere mai mari sunt garantate pentru a fi sigur de a încerca din nou.
 REFUSED_STREAM cod de eroare poate fi inclus într-un RST_STREAM cadru pentru a indica faptul că fluxul este închis
înainte de orice prelucrare a avut loc. Orice cerere care a fost trimis pe fluxul de resetare poate fi rejudecat în
condiții de siguranță .
Cereri care nu au fost procesate, nu au eșuat; clienții le reîncerca în mod automat, chiar si cei cu metode non-idempotenta.
Un server nu trebuie să indice faptul că un flux de nu a fost procesat excepția cazului în care se poate garanta acest fapt. În
cazul în cadre, care sunt pe un flux sunt transmise la stratul de cerere pentru orice flux, apoi REFUSED_STREAM nu trebuie
să fie utilizate pentru acel flux, și o GOAWAY cadru trebuie să includă un identificator de flux, care este mai mare decâ t sau
egală cu identificatorul dat flux.
În plus față de aceste mecanisme, PING cadrul oferă o modalitate pentru un client pentru a testa cu ușurință o
conexiune. Conexiunile care rămâ n în așteptare poate deveni rupt ca unele middleboxes (de exemplu, NAT, sau echilibrat
de încă rcare) aruncați în tă cere legă turi de conectare. PING cadru permite unui client pentru a testa în condiții de
siguranță dacă o conexiune este încă activ, fă ră a trimite o cerere.
8.2 Server Push
HTTP / 2 permite un server pentru a trimite preventiv (sau "push"), una sau mai multe ră spunsuri asociate la un client ca
răspuns la o singură cerere. Această caracteristică devine deosebit de util atunci câ nd serverul știe clientul va avea nevoie
de aceste raspunsuri disponibile, în scopul de a procesa pe deplin ră spunsul la cererea inițială .
Împingerea răspunsuri suplimentare este opțională , și este negociat între obiective

individuale.SETTINGS_ENABLE_PUSH Setarea poate fi setat la 0 pentru a indica faptul că împinge server este dezactivat.
Deoarece împingâ nd ră spunsuri este hop-by-hop în mod eficient, un intermediar ar putea primi ră spunsuri împinse de la
server și alegeți să nu transmită cele de pe la client. Cu alte cuvinte, cum să facă uz de răspunsurilor împins este de pâ nă la
acel intermediar. În egală măsură , intermediarul ar putea alege pentru a împinge răspunsuri suplimentare pentru client,
fă ră nici o acțiune întreprinsă de către server.
Un client nu poate împinge. Astfel, serverele trebuie să trateze primirea unui PUSH_PROMISE cadru ca o eroare de

conexiune ( secțiunea 5.4.1 ) de tip PROTOCOL_ERROR . Clientii trebuie să respingă orice încercare de a
schimba SETTINGS_ENABLE_PUSH setarea la o altă valoare decâ t "0" valoare prin tratarea mesajul ca o eroare de
Un server poate împinge numai ră spunsuri care sunt cacheable (a se vedea [HTTP-p6] , secțiunea 3 ); cereri promise
trebuie să fie sigure (a se vedea [HTTP-p2] , secțiunea 4.2.1 ) și nu trebuie să includă un corp cerere.
8.2.1 Cererile Push
Server împinge este semantic echivalent cu un server de răspuns la o cerere; Cu toate acestea, în acest caz, că cererea este,
de asemenea, trimis de server, ca un PUSH_PROMISE cadru.
PUSH_PROMISE Cadrul include un bloc antet care conține un set complet de câ mpuri antet cerere pe care serverul le
atribuie cererii. Nu este posibil să împingă un răspuns la o cerere care include un corp cerere.
Răspunsurile împins sunt întotdeauna asociate cu o cerere explicită din partea clientului. CelePUSH_PROMISE Cadrele
trimise de serverul sunt trimise la curent că cererea explicită a lui. PUSH_PROMISEcadru include, de asemenea, un
identificator de flux promis, ales din identificatorii flux disponibile la server (a se vedea secțiunea 5.1.1 ).
Câmpurile antet în PUSH_PROMISE și orice ulterioare CONTINUATION cadre trebuie să fie un set de câ mpuri antet cerere
(valabil și complet Secțiunea 8.1.3.1 ). Serverul trebuie să includă o metodă în: Metodacâ mp de antet care este în
condiții de siguranță și cacheable. În cazul în care un client primește unPUSH_PROMISE care nu include un set complet și
valid de câmpuri antet, sau: Metodacâ mp de antet identifică o metodă care nu este sigur, acesta trebuie să ră spundă
cu o eroare de curent ( Secțiunea 5.4.2 ) de tip PROTOCOL_ERROR .
Serverul ar trebui să trimită PUSH_PROMISE ( secțiunea 6.6 ) cadre înainte de a trimite orice cadre care fac referire la
răspunsurile promise. Astfel se evită o cursă în care clienții solicită problemă înainte de a primi
orice PUSH_PROMISE cadre.
De exemplu, în cazul în care serverul primește o cerere pentru un document care conține link-uri integrate la mai multe
fișiere imagine, și serverul alege pentru a împinge aceste imagini suplimentare pentru client, trimiterea de promisiuni
împinge înainte de DATE cadrele care conțin link-uri de imagine asigură faptul că clientul este posibilitatea de a vedea
promisiunile înainte de a descoperi link-uri integrate. În mod similar, în cazul în care serverul împinge răspunsuri referite
de către blocul de antet (de exemplu, în domenii de antet Link), trimiterea promisiunile împinge înainte de a trimite blocul
de antet se asigură că clienții nu le solicită .
PUSH_PROMISE cadre nu trebuie să fie trimise de că tre client. PUSH_PROMISE cadre pot fi trimise de că tre server cu
privire la orice flux, care a fost deschis de că tre client. Acestea trebuie să fie trimise pe un flux care este fie "deschis" sau
"pe jumă tate închiși (la distanță )" stat la server. PUSH_PROMISE cadre sunt intercalate cu cadre care cuprind un răspuns,
deși ele nu pot fi intercalate cu anteturi și CONTINUATION cadre care cuprind un singur bloc antet.
8.2.2 Răspunsuri Push
După trimiterea PUSH_PROMISE cadru, serverul poate începe livrarea ră spunsul împins ca răspuns (secțiunea 8.1.3.2 ) pe
un curent inițiat-server care utilizează identificatorul flux promis. Serverul folosește acest flux pentru a transmite un
răspuns HTTP, folosind aceeași secvență de cadre astfel cum este definit însecțiunea 8.1 . Acest flux devine "jumă tate
închis" la client ( secțiunea 5.1 ), după ce inițial antetele cadru este trimis.
Odată ce un client primeste un PUSH_PROMISE cadru și alege să accepte răspunsul împins, clientul nu ar trebui să emită
orice cereri de ră spunsul promis pâ nă după fluxul promis sa închis.
În cazul în care clientul stabilește, pentru orice motiv, că nu dorește să primească răspunsul împins de la server, sau în
cazul în care serverul durează prea mult timp pentru a începe trimiterea de răspunsul promis, clientul poate trimite
un RST_STREAM cadru, utilizâ nd fie CANCEL sau REFUSED_STREAM coduri, și referințele de identificare fluxul împins lui.
Un client poate folosi SETTINGS_MAX_CONCURRENT_STREAMS setare pentru a limita numă rul de ră spunsuri care pot fi
împinse în același timp de că tre un server. Publicitate unSETTINGS_MAX_CONCURRENT_STREAMS valoare de zero,
dezactivează serverului împinge prin prevenirea serverul de la crearea fluxurile necesare. Acest lucru nu interzice un
server de la trimiterea de cadre PUSH_PROMISE; clientii au nevoie pentru a reseta orice fluxuri promis că nu sunt dorit.
Clientii primesc un ră spuns împins trebuie să valideze că serverul este autorizată să furnizeze răspunsul, a se
vedea secțiunea 10.1 . De exemplu, un server care oferă un certificat pentru numaiexample.com ID-DNS sau Nume
comun nu este permis pentru a împinge un răspuns pentru https://www.example.org/doc .
8.3 Metoda CONNECT
În HTTP/1.x, pseudo-metoda CONNECT ( [HTTP-p2] , secțiunea 4.3.6 ) este utilizat pentru a converti o conexiune HTTP
într-un tunel la o gazdă de la distanță . CONNECT este utilizat în principal cu proxy HTTP pentru a stabili o sesiune TLS cu
un server de origine în scopul de a interacționa cuhttps resurse.
În HTTP / 2, metoda CONNECT este utilizat pentru a stabili un tunel pe un singur HTTP / 2 flux de la o gazdă de la distanță ,
în scopuri similare. Maparea câ mp de antet HTTP funcționează ca cea mai mare parte așa cum este definit în Cerere Antet
Fields ( secțiunea 8.1.3.1 ), cu câ teva diferențe. În mod special:
 The : Metoda câ mp de antet este setat la CONNECT.

 The : Schema și : Cale Câmpuri titluri TREBUIE să fie omise.
 The : Autoritateacâ mp de antet conține gazdă și portul pentru conectarea la (echivalent cu autoritate forma
cererea-țintă de cereri CONNECT, a se vedea [HTTP-p1] , secțiunea 5.3 ).
Un proxy care acceptă Connect stabilește o conexiune TCP [TCP] la serverul identificat în: Autoritateacâ mp de
antet. Odată ce această conexiune este stabilit cu succes, proxy-ul trimite un header-cadru care conține un cod de stare 2xx
serie a clientului, astfel cum sunt definite în [HTTP-p2] , secțiunea 4.3.6 .
După ce inițial antetele cadrul trimis de fiecare la egal la egal, toate ulterioare DATA cadre corespund cu datele trimise de
pe conexiunea TCP. Sarcina utilă a orică ror DATA cadre trimise de client sunt transmise prin proxy pentru serverul
TCP; Datele primite de la serverul TCP este asamblat în DATA cadre de proxy.Altele decâ t tipuri de cadru DATA cadre sau
flux de management ( RST_STREAM , WINDOW_UPDATE , șiPRIORITARE ) nu trebuie să fie transmis pe un flux conectat, și
trebuie să fie tratată ca o eroare de curent (Secțiunea 5.4.2 ), în cazul în care a primit.
Conexiunea TCP poate fi închisă de că tre nici la egal la egal. Steagul END_STREAM pe un DATA cadru este tratat ca fiind
echivalente cu bitul TCP FIN. Un client este de așteptat pentru a trimite un DATA cadru cu steagul END_STREAM stabilit
dupa ce a primit un cadru care poartă steagul END_STREAM. Un proxy care primeste un DATA cadru cu indicatorul
END_STREAM trimite datele anexate cu bitul FIN setat pe ultimul segment TCP. Un proxy care primeste un segment TCP cu
un set de biți FIN trimite un DATA cadru cu indicatorul END_STREAM. Rețineți că segmentul TCP final sau DATA cadru ar
putea fi gol.
O eroare de conexiune TCP este semnalizată cu RST_STREAM . Un proxy tratează orice eroare de conexiune TCP, care
include recepționarea unui segment TCP cu setul RST biți, ca o eroare de flux ( secțiunea 5.4.2 ) de tip connect_error . În
mod corespunză tor, un proxy trebuie să trimită un segment TCP cu bitul RST setat dacă se detectează o eroare cu fluxul
sau conexiunea HTTP / 2.
9. suplimentare Necesitati HTTP / Considerații
Această secțiune prezintă atribute de protocolul HTTP care îmbună tă ți interoperabilitatea, reduce expunerea la
vulnerabilitati de securitate cunoscute, sau de a reduce potențialul de variație de punere în aplicare.
9.1 Managementul Conexiune
HTTP / 2 conexiuni sunt persistente. Pentru performanțe optime, este de așteptat clienții nu va închide conexiuni pâ nă la
constatarea că nici o altă comunicare cu un server este necesar (de exemplu, atunci câ nd un utilizator navighează de la o
anumită pagină web), sau pâ nă câ nd serverul inchide conexiunea.
Clientii nu ar trebui să deschidă mai mult de un HTTP / 2 conexiune la un anumit destinație, în cazul în care o destinație
este adresa IP și portul, care este derivat dintr-un URI, un selectat serviciu alternativ [ALT-SVC], sau de un proxy
configurat. Un client poate crea conexiuni suplimentare ca înlocuitori, fie pentru a înlocui conexiunile care sunt aproape de
epuizarea spațiului de identificare curent disponibil ( Secțiunea 5.1.1 ), sau pentru a înlocui conexiunile care s-au
confruntat de erori ( Secțiunea 5.4.1 ).
Un client poate deschide mai multe conexiuni la aceeași adresă IP și portul TCP folosind diferite Server Name
Indicarea [TLS-EXT] valori sau pentru a oferi diferite certificate client TLS, dar ar trebui să evite crearea unor conexiuni
multiple cu aceeași configurație. [ rfc.comment.3 : Aveti nevoie de mai mult text pe cât de certificate de client se referă aici,
vezi problema # 363].
Clienții pot utiliza o singură conexiune de server pentru a trimite cereri pentru URI-uri cu mai multe componente de
autoritate diferite, atâta timp cât serverul este autoritar ( secțiunea 10.1 ).
Serverele sunt încurajați să mențină conexiuni deschise pentru câ t mai mult posibil, dar li se permite să pună capă t
conexiuni inactiv dacă este necesar. Câ nd fie final alege pentru a închide conexiunea TCP la nivel de transport, obiectivul
de încheiere ar trebui să trimită mai întâ i o GOAWAY ( secțiunea 6.8 ), cadru, astfel încâ t ambele obiective pot determina
în mod credibil dacă trimise în prealabil de cadre au fost procesate și grațios complet sau rezilia orice sarcini ră mase
necesare.
9.2 Utilizarea de caracteristici TLS
Implementari de HTTP / 2 trebuie să sprijine TLS 1.2 [TLS12] . General de orientare utilizare TLS în[TLSBCP] trebuie să fie
urmată , cu unele restricții suplimentare care sunt specifice pentru HTTP / 2.
Implementarea TLS TREBUIE să sprijine Server Name indicația (SNI) [TLS-EXT] extensie pentru TLS. HTTP / 2 clienții
trebuie să indice numele de domeniu țintă atunci câ nd negociază TLS.
Implementarea TLS TREBUIE să dezactivați comprimare. Compresie TLS poate duce la expunerea de informații care altfel
nu ar fi descoperit [RFC3749] . Compresie generic este inutilă , deoarece HTTP / 2 oferă caracteristici de compresie, care
sunt mai conștienți de context și, prin urmare, ar putea fi mai adecvat pentru utilizare pentru performanță , securitate sau
din alte motive.
Implementă ri trebuie să negocieze - și, prin urmare, utilizat - apartamente cifru efemere, cum ar fi efemeră Diffie-Hellman
(DHE) sau varianta curbe eliptice (ECDHE), cu o dimensiune minimă de 2048 biți (DHE) sau nivelul de securitate de 128
biți (ECDHE). Clientii trebuie să accepte dimensiuni DHE de pâ nă la 4096 de biți.
Implementarile sunt încurajate să nu negocieze apartamente cifru TLS cu vulnerabilitati cunoscute, cum ar fi [RC4] .
O implementare, care negociază o conexiune TLS care nu îndeplinește cerințele în această secțiune, sau orice constrâ ngeri
bazate pe politici, nu ar trebui să negocieze HTTP / 2. Scoaterea HTTP / 2 protocoale de examinare ar putea duce la
eliminarea tuturor protocoalelor de la un set de protocoale oferite de client.Acest lucru duce la eșec negociere protocol,
așa cum este descris în secțiunea 3.2 a [TLSALPN] .
Datorită limită rilor de implementare, s-ar putea să nu fie posibil să eșueze TLS negociere pe baza de toate aceste
cerințe. Un obiectiv TREBUIE termina o conexiune HTTP / 2, care este deschis pe o sesiune de TLS care nu îndeplinesc
aceste cerințe minime, cu o eroare de conexiune ( secțiunea 5.4.1 ) de tipINADEQUATE_SECURITY .
9.3 GZip Content-Encoding
Clientii trebuie să sprijine de compresie gzip pentru organismele de ră spuns HTTP. Indiferent de valoarea câ mpului antet
accepta codifică , un server poate trimite ră spunsuri cu codificare gzip. Un ră spuns comprimat trebuie să poarte încă o
codifică conținut câ mp de antet adecvat.
Acest lucru se schimba în mod eficient valoarea implicită a Accept-Encoding câ mp de antet ( [HTTP-p2] ,secțiunea 5.3.4 )
de la "identitate" a "identită ții, gzip", însă codificare gzip nu poate fi suprimată prin includerea "; q = 0" . Intermediari care
efectuează traducerea de la HTTP / 2 pentru a HTTP/1.1 TREBUIE decomprima încă rcă turi excepția cazului în care
cererea cuprinde o valoare Accept-Encoding, care include "gzip".
10. Considerații de Securitate
10.1 Autoritatea Server
Un client este capabil să accepte HTTP / 2 raspunsuri de la serverele care sunt autoritate pentru aceste resurse
numai. Acest lucru este deosebit de important pentru server de împingere ( secțiunea 8.2 ), în cazul în care clientul
validează PUSH_PROMISE înainte de a accepta răspunsul.
HTTP / 2 se bazează pe definiția HTTP/1.1 de autoritate pentru a stabili dacă un server este autoritate în furnizarea de un
anumit răspuns, a se vedea [HTTP-p1] , secțiunea 9.1 . Acest lucru se bazează pe rezoluția de nume locale pentru "http"
Schema URI, și identitatea de server oferit de sistemul de "https" (a se vedea[RFC2818] , secțiunea 3 ).
Un client nu trebuie să folosească , în orice mod, resursele oferite de un server care nu este autoritate pentru aceste
resurse.
10,2 Cross-Protocol Atacuri
Într-un atac cross-protocol, un atacator provoacă un client pentru a iniția o tranzacție într-un protocol pentru un server
care înțelege un protocol diferit. Un atacator ar putea fi capabil de a provoca tranzacția să apară tranzacție ca fiind valabile
în al doilea protocol. În combinație cu capacită țile de contextul web, acest lucru poate fi folosit pentru a interacționa cu
servere slab protejate în rețele private.
Completarea o strâ ngere de mâ nă TLS cu un identificator ALPN pentru HTTP / 2 poate fi considerată suficientă . ALPN
oferă un indiciu pozitiv că un server este dispus să continue cu HTTP / 2, care previne atacurile de pe alte protocoale
bazate pe TLS.
Criptarea în TLS, este dificil pentru atacatori pentru a controla datele care ar putea fi utilizate într-un atac cross-protocol
pe un protocol text clar.
Versiunea text clar de HTTP / 2 are o protecție minimă împotriva atacurilor cross-protocol. Prefața de conectare
( secțiunea 3.5 ) conține un șir de caractere, care este proiectat pentru a confunda servere HTTP/1.1, dar nici o protecție
specială este oferit pentru alte protocoale. Un server care este dispus să ignore pă rți ale unei cereri HTTP/1.1 care conține
un câ mp de antet upgrade ar putea fi expus la un atac cross-protocol.
10,3 intermediare Atacurile încapsulare
HTTP / 2 nume de câ mpuri antet și valori sunt codificate ca secvențe de octeți cu un prefix de lungime.Acest lucru permite
HTTP / 2 pentru a efectua orice șir de octeți ca numele sau valoarea unui câmp de antet.Un intermediar, care se traduce
HTTP / 2 cereri sau de răspunsuri în HTTP/1.1 direct ar putea permite crearea de mesaje HTTP/1.1 corupte. Un atacator
ar putea exploata acest comportament de a provoca intermediarului pentru a crea mesaje HTTP/1.1 cu câ mpuri ilegale
antet, Câmpuri titluri suplimentare, sau chiar mesaje noi, care sunt falsificate în întregime.
Nume de câ mpuri antet sau valori care conțin caractere care nu sunt permise de HTTP/1.1, inclusiv retur de car (U 000 D)
sau o linie de alimentare (U 000 A) nu trebuie să fie traduse cuvâ nt cu cuvâ nt de că tre un intermediar, astfel cum este
prevă zut în [HTTP-p1] , secțiunea 3.2.4 .
Traducere de la HTTP/1.x la HTTP / 2 nu produce același posibilitatea de a un atacator. Intermediari care efectuează
traduceri la HTTP / 2 trebuie să elimine orice cazuri deobs ori de producție de la valori de câmp de antet.
10.4 Cacheability de Responses împins
Răspunsuri împinse nu au o solicitare explicită din partea clientului; cererea este furnizată de serverul
înPUSH_PROMISE cadru.
Răspunsuri cache care sunt împinse este posibil, pe baza orientă rilor furnizate de că tre serverul de origine în domeniul
antet Cache-Control. Cu toate acestea, acest lucru poate cauza probleme în cazul unui singur server gă zduiește mai mult de
un chiriaș. De exemplu, un server poate oferi mai multor utilizatori, fiecare o mică parte din spațiul să u URI.
În cazul în care mai mulți chiriași imparta spatiul pe același server, serverul trebuie să se asigure că chiriașii nu sunt în
măsură să împingă reprezentă ri de resurse pe care ei nu au autoritate peste. Imposibilitatea de a pune în aplicare acest
lucru ar permite un chiriaș pentru a oferi o reprezentare care ar fi servit din cache, imperative reprezentarea reală ca
locatarul autoritar oferă .
Răspunsuri împins pentru care un server de origine nu este autoritate (a se vedea secțiunea 10.1 ) nu sunt în cache sau
folosite.
10.5 Denial of Considerații de servcii
O conexiune HTTP / 2 pot cere un angajament mai mare de resurse pentru a opera decâ t o conexiune HTTP/1.1. Utilizarea
de compresie antet și controlul fluxului depind de un angajament de resurse pentru stocarea o cantitate mai mare de
stat. Setă rile pentru aceste caracteristici se asigure că angajamentele de memorie pentru aceste caracteristici sunt strict
delimitate. Capacitatea de prelucrare nu pot fi protejate în același mod.
SETTINGS Cadrul poate fi abuzat de a provoca un egal pentru a cheltui timp de procesare suplimentar. Acest lucru ar putea
fi realizat prin schimbarea inutil parametri setă ri, setarea parametrilor de mai multe nedefinite, sau schimbarea aceeași
setare de mai multe ori în același cadru. WINDOW_UPDATE ,PRIORITATEA , sau BLOCAT cadre pot fi abuzat de a provoca
o risipă inutilă de resurse. Un server ar putea emite în mod eronat ALTSVC cadre pentru originile pe care ea nu poate fi
autoritate pentru a genera exces de lucru pentru clienti.
Un numă r mare de cadre mici sau goale pot fi abuzat de a provoca un egal pentru a cheltui timp anteturile cadru de
procesare. Rețineți, totuși, că unele utiliză ri sunt pe deplin legitime, cum ar fi trimiterea unui golDATA cadru pentru a
termina un flux.
Compresie antet oferă , de asemenea, unele oportunită ți de a irosi resurse de procesare; vezi[COMPRESSION] pentru mai
multe detalii cu privire la eventualele abuzuri.
Limite în SETĂ RI parametri nu pot fi reduse instantaneu, care lasă un obiectiv expus la comportament de la un coleg care
ar putea depă și noile limite. În special, imediat după stabilirea unei conexiuni, limitele stabilite de că tre un server nu sunt
cunoscute clienților și ar putea fi depă șită fă ră a fi o încă lcare de protocol evident.
Toate aceste caracteristici - de exemplu, SETĂ RI schimbă ri, rame mici, de compresie antet - au utiliză ri legitime. Aceste
caracteristici deveni o povară numai atunci câ nd sunt utilizate în mod inutil sau în exces.
Un obiectiv care nu monitorizează acest comportament se expune la un risc de atac denial of service.Implementari ar
trebui să monitorizeze utilizarea acestor caracteristici și a stabilit limite privind utilizarea lor. Un obiectiv poate trata
activitate care este suspect ca o eroare de conexiune ( secțiunea 5.4.1 ) de tipENHANCE_YOUR_CALM .
10.6 Utilizarea compresie
HTTP / 2 permite utilizarea mai mare de compresie pentru ambele domenii de antet ( secțiunea 4.3 ) și organismele de
răspuns ( punctul 9.3 ). Compresie pot permite unui atacator de a recupera datele secrete atunci câ nd este comprimat în
același context ca date sub control atacator.
Există atacuri demonstrabile pe compresie care exploatează caracteristicile de web (de exemplu,
[INCALCAREA] ). Atacatorul a induce cereri multiple care conțin diferite text clar, cu respectarea lungimea cifrat rezultat
în fiecare, care dezvă luie o lungime mai mică , atunci câ nd o presupunere cu privire la secretul este corectă .
Implementă ri care comunică pe un canal sigur NU TREBUIE comprima conținut care include atât date confidențiale și
controlate atacator dacă dicționare separate de compresie sunt utilizate pentru fiecare sursă de date. Compresie nu
trebuie utilizat în cazul în care sursa de date nu poate fi determinată în mod credibil.
Intermediarii nu trebuie să modifice comprimarea DATA cadre excepția cazului în care informațiile suplimentare sunt
disponibile care permite intermediarul pentru a identifica sursa de date. În special, cadre care nu sunt comprimate, nu
poate fi comprimat, și cadre, care sunt comprimate separat, nu pot fi unite într-un singur cadru. Cadre comprimate pot fi
decomprimat sau împă rțite în mai multe cadre.
Considerații suplimentare cu privire la comprimarea câ mpuri antet sunt descrise în [COMPRESSION] .
10.7 Utilizarea Captuseala
Captuseala cadrul HTTP / 2 nu este conceput ca un înlocuitor pentru uz general umplutură , așa cum ar putea fi furnizate
de TLS [TLS12] . Padding redundant ar putea fi chiar contraproductivă . Aplicarea corectă poate depinde de a avea
cunoștințe specifice de date care este că ptușit.
Pentru a atenua atacurile care se bazeaza pe compresie, compresia dezactivarea putea fi preferată padding ca o
contramăsură .
Padding poate fi folosit pentru a ascunde dimensiunea exactă a conținutului cadru, și este prevă zut pentru a atenua atacuri
specifice în cadrul HTTP. De exemplu, în cazul în care conținutul de atacuri comprimat include atât plaintext și secrete
date controlate atacator (vezi, de exemplu, [BREACH] ).
Utilizarea padding poate duce la mai puțină protecție decâ t ar putea pă rea imediat evident. În cel mai bun, padding face
doar mai dificil pentru un atacator pentru a deduce informații lungime prin creșterea numă rului de cadre un atacator
trebuie să respecte. Schemele de padding implementate incorect poate fi ușor învins. În special, randomizat padding cu o
distribuție previzibilă ofera foarte putin protecție; sau sarcini utile de umplutură la o dimensiune fixă expune informații ca
dimensiuni sarcină utilă trece granița dimensiune fixa, care ar putea fi posibilă în cazul în care un atacator poate controla
plaintext.
Intermediarii NU ar trebui să elimine umplutură , dacă un intermediar poate scoate padding și se adaugă cantită ți diferite
în cazul în care intenția este de a îmbună tă ți mă surile de protecție oferă de umplutură .
10,8 Considerații de confidențialitate
Mai multe caracteristici de HTTP / 2 oferă un observator o oportunitate de a corela acțiunile de un singur client sau server
de-a lungul timpului. Aceasta include valoarea de setă ri, modul în care ferestrele de control al fluxului sunt gestionate,
modul în care priorită țile sunt alocate pentru fluxuri, calendarul de reacții la stimuli, precum și manipularea de orice
caracteristici opționale.
În ceea ce privește acest creează diferențe observabile de comportament, acestea ar putea fi utilizate ca bază pentru
amprentarea unui anumit client, astfel cum sunt definite în <http://www.w3.org/TR/html5/introduction.html #
amprentă >.
11. Considerații IANA
Un șir de identificare a HTTP / 2 este introdus în "Protocolul de la Negocierea Application Layer (ALPN) Protocolul ID-uri"
registru stabilit în [TLSALPN] .
Acest document stabilește un registru de coduri de eroare. Acest nou registru este înscris într-o nouă "Transfer Hypertext
Protocol (HTTP) 2 Parametrii" secțiune.
Acest document înregistrează HTTP2-Setări header teren pentru utilizarea în HTTP.
Acest document înregistrează PRIMetoda de utilizare în HTTP, pentru a evita coliziunile cu prefata de conectare
( secțiunea 3.5 ).
11.1 Înregistrarea HTTP / 2 Identificarea Strings
Acest document creează două înregistră ri pentru identificarea de HTTP / 2 în "Protocolul Negocierea Application Layer
(ALPN) Protocolul ID-uri" registru stabilit în [TLSALPN] .
"H2" șirul identifică HTTP / 2 atunci câ nd sunt utilizate peste TLS:
Protocol:
HTTP / 2 peste TLS
Secvența de identificare:
0x68 0x32 ("h2")
Caietul de sarcini:
Acest document (RFCXXXX)
Ș irul "H2C" identifică HTTP / 2 atunci câ nd sunt utilizate peste TCP text clar:
Protocol:
HTTP / 2 peste TCP
Secvența de identificare:
0x68 0x32 0x63 ("H2C")
Caietul de sarcini:
Acest document (RFCXXXX)
11.2 Cod de eroare Registrul
Acest document stabilește un registru pentru HTTP / 2 coduri de eroare. "HTTP / 2 Cod de eroare" registru gestionează un
spațiu pe 32 de biți. "HTTP / 2 Cod de eroare" registry funcționează în conformitate cupolitica de "revizuire
Expert" [RFC5226] .
Inscrierile pentru coduri de eroare trebuie să includă o descriere a codului de eroare. Referent de specialitate, se
recomandă de a examina noi înregistră ri pentru eventualele suprapuneri cu coduri de eroare existente. Utilizarea
înregistră rilor existente trebuie să fie încurajată , dar nu obligatorie.
Înregistră rile noi sunt sfătuiți să furnizeze urmă toarele informații:

Cod de eroare:
Valoarea cod de eroare de 32 de biți.
Nume:
Un nume pentru codul de eroare. Specificarea unui nume de cod de eroare este opțională .
Descriere:
O descriere a condițiilor în care codul de eroare este aplicabilă .
Caietul de sarcini:
O referință opțional pentru o specificație care definește codul de eroare.
Un prim set de înregistră ri de cod de eroare pot fi gă site în secțiunea 7 .
11.3 HTTP2-Settings Antet Câmp de înregistrare
Această secțiune înregistrează HTTP2-Setăriheader domeniu în permanentă mesaj Antet Câ mp Registrul[BCP90] .
Antet nume de câ mp:
HTTP2-Setă ri
Protocol se aplică :
http
Status:
standard
Autor / Schimbare controler:
IETF
Document de specificație (s):
Secțiunea 3.2.1 a acestui document
Informații legate de:
Acest câ mp antet este utilizat numai de către un client HTTP / 2 de negociere pe baza de upgrade.
11.4 PRI metodă de înregistrare
Această secțiune înregistrează PRIMetoda în metoda HTTP Registrul [HTTP-p2] .
Numele metodei:
PRI
Sigur
Nu
Idempotenta
Nu
Document de specificație (e)
Secțiunea 3.5 a acestui document
Informații legate de:

Această metodă nu este folosit de un client real. Această metodă va apă rea pentru a fi utilizat atunci câ nd un server
HTTP/1.1 sau încercă ri intermediare pentru a analiza o prefață conexiune HTTP / 2.
12. Mulțumiri
Acest document include contribuții substanțiale din urmă toarele persoane:
 Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy
Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang,
Jonathan Leighton (contribuabili SPDY).
 Gabriel Muntenegru și Willy Tarreau (mecanism Upgrade).
 William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Muntenegru, Jitu Padhye, Roberto Peon, Rob Trace (debit de
control).
 Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike Bishop, Herve Ruellan (contribuții editoriale
substanțiale).
 Alexey Melnikov a fost un editor al acestui document în timpul 2013.
 O parte substanțială a contribuției Martin a fost susținută de Microsoft în timpul angajă rii sale acolo.
13. Trimiterile
13,1 Referințe normative
[ALT-SVC] Nottingham, M., McManus, P., și J. Reschke, " HTTP Servicii alternative ", Internet-Proiect-proiect IETF-
httpbis-alt-SVC-01 (work in progress), aprilie 2014.
[COMPRESSION] Ruellan, H. și R. Peon, " HPACK - compresie antet pentru HTTP / 2 ", Internet-Proiect-proiect IETF-httpbis-
header-compresie-07 (work in progress), aprilie 2014.
[COOKIE] Barth, A., " Mecanismul HTTP de management de stat ", RFC 6265, aprilie 2011.
[GZIP] Deutsch, P. , Gailly, JL. , Adler, M. , Deutsch, L. , și G. Randers-Pehrson , " format de fișier GZIP specificații
versiunea 4.3 ", RFC 1952, mai 1996.
[HTTP-p1] Fielding, R., Ed.. și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1): Mesaj Sintaxa și Routing ",
Internet-Proiect proiect-IETF-httpbis-p1-mesaje-26 (work in progress), Februarie 2014.
[HTTP-p2] Fielding, R., Ed.. și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1): Semantica și conținut ",
Internet-Proiect-proiect IETF-httpbis-P2-semantica-26 (work in progress), Februarie 2014.
[HTTP-p4] Fielding, R., Ed.. și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1): Cereri condiționale ", Internet-
Proiect proiect-IETF-httpbis-p4-condiționată -26 (work in progress), Februarie 2014.
[HTTP-P5] Fielding, R., Ed.. , Lafon, Y., Ed. , și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1): Cereri Range ",
Internet-Proiect-proiect IETF-httpbis-p5-26-range (work in progress), Februarie 2014.
[HTTP-p6] Fielding, R., Ed.. , Nottingham, M., Ed.. , și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1):
Caching ", Internet-Proiect-proiect IETF-httpbis-p6-26-cache (work in progress), Februarie 2014.
[HTTP-p7] Fielding, R., Ed.. și J. . Reschke, Ed , " Hypertext Transfer Protocol (HTTP/1.1): autentificare ", Internet-
Proiect-proiect IETF-httpbis-p7-auth-26 (work in progress), Februarie 2014.
[RFC2119] Bradner, S. , " Cuvinte cheie pentru utilizarea in RFC-uri pentru a indica niveluri ale cerințelor ", BCP 14, RFC
2119, martie 1997.
[RFC2818] Rescorla, E., " HTTP Over TLS ", RFC 2818, mai 2000.
[RFC3986] Berners-Lee, T., Fielding, R., și L. Masinter, " Uniform Resource Identifier (URI): Sintaxa Generic ", STD 66,
RFC 3986, ianuarie 2005.
[RFC4648] Josefsson, S., " Base16, Base32, și Base64 date de codifică ri ", RFC 4648, octombrie 2006.
[RFC5226] NARTEN, T. și H. Alvestrand, " Linii directoare pentru scriere un Considerații secțiunea IANA în RFC ", BCP
26, RFC 5226, mai 2008.
[RFC5234] Crocker, D. și P. Overell, " Augmented BNF pentru sintaxa Specificatii: ABNF ", STD 68, RFC 5234, ianuarie
2008.
[RFC6454] Barth, A., " Web origine Concept ", RFC 6454, decembrie 2011.
[TCP] Postel, J., " Protocolul de control al transmisiei ", STD 7, RFC 793, septembrie 1981.
[TLS-EXT] Eastlake, D., " Transport Layer Security (TLS) Extensions: Definiții extensie ", RFC 6066, ianuarie 2011.
[TLS12] Dierks, T. și E. Rescorla, " Layer Security transport (TLS) Protocol Version 1.2 ", RFC 5246, august 2008.
[TLSALPN] Friedl, S., Popov, A., Langley, A., și E. Stephan, " Transport Layer Security (TLS) Application Layer Protocol
Extension Negociere ", Internet-Proiect-proiectul de IETF-TLS-applayerprotoneg-05 (lucră ri în curs ),
martie 2014.
[UTF-8] Yergeau, F., " UTF-8, un format de transformare a ISO 10646 ", STD 63, RFC 3629, noiembrie 2003.
13,2 informative Referințe
[BCP90] Klyne, G. , Nottingham, M. , și J. Mogul , " Proceduri de înregistrare pentru Antet mesaj Fields", BCP 90, RFC
3864, septembrie 2004.
[ÎNCĂLCAREA] Gluck, Y., Harris, N., și A. Prado, " încă lcarea: Relansarea Attack CRIME ", iulie 2013,
<http://breachattack.com/resources/BREACH% 20 -% 20SSL,% 20gone% 20in% 2,030% 20seconds.pdf >.
[IDNA] Klensin, J., " nume de domenii internationalizate pentru Aplicații (IDNA): Definiții și cadru de documente ",
RFC 5890, august 2010.
[RC4] Rivest, R., "algoritmul de criptare RC4", RSA Data Security, Inc, martie 1992.
[RFC1323] Jacobson, V., Braden, B. și D. Borman, " Extensii TCP pentru înaltă performanță ", RFC 1323, mai 1992.
[RFC3749] Hollenbeck, S., " Transport Layer Security Protocol de compresie Metode ", RFC 3749, mai 2004.
[TALKING] Huang, LS., Chen, E., Barth, A., Rescorla, E., și C. Jackson, " vorbesc cu tine pentru distracție și profit ", 2011,
< http://w2spconf.com/2011/papers/ websocket.pdf >.
[TLSBCP] Sheffer, Y., Holz, R., și P. Saint-Andre, " Recomandă ri pentru utilizarea sigură a TLS și DTLS ", Internet-Proiect
proiect-Sheffer-TLS-BCP-02 (work in progress), Februarie 2014.
A. Change Log (pentru a fi eliminate prin RFC Editor înainte de publicare)
A.1 Din proiect-IETF-httpbis-http2-12
Eliminat rezervate octet de la ALTSVC .
A adă ugat BLOCAT cadru (la risc).
Simplificat schema de prioritate.
A adă ugat DATA compresie pe-cadru gzip.
Schimbat "antet conexiune" la "prefață legă tură " pentru a evita confuzia.
Adă ugat pe baza de dependență flux de prioritizare.
A adaugat "H2C" identificator pentru a distinge între text clar și asigurat HTTP / 2.
Adă ugarea padding lipsă de PUSH_PROMISE .
Integra ALTSVC cadru și textul de sprijin.
Scaderea cerință pe "dezumfle" Content-Encoding.
Îmbună tă țirea considerente de securitate în jurul utilizarea de compresie.
Adă ugarea padding pentru cadrele de date.
Renumerotarea tipuri de cadru, coduri de eroare, și setă rile.
Adă ugarea INADEQUATE_SECURITY cod de eroare.
Actualizarea cerințelor de utilizare TLS la 1.2; interzicerea de compresie TLS.
Scoaterea extensibilitate pentru rame și setă ri.
Modificarea setarea dimensiune identificator.
Scoaterea capacitatea de a dezactiva controlul fluxului.
Schimbarea token identificare protocol la "H2".

Schimbarea utilizarea de: autoritate pentru a face opțional și pentru a permite userinfo în cazuri non-HTTP.
Permițâ nd împă rțită pe 0x0 pentru Cookie.
Rezervat metodă PRI în HTTP/1.1 a evita posibile coliziuni în viitor.
Cookie adă ugat prăbușește pentru compresie antet mai eficient.
A adă ugat header câmp comanda cu mecanismul de valoare concatenare.
Marcat proiect pentru punerea în aplicare.
Adă ugarea definiție pentru metoda CONNECT.
Constrâ ngere utilizarea a împinge la metode sigure, cacheable cu nici un organism cerere.
Schimbarea de la: gazdă la: autoritatea de a elimina orice confuzie potențial.
Adă ugarea de stabilire pentru antet de compresie dimensiunea de masă .
Adă ugarea de setă ri confirmare.
Scoaterea steaguri inutile și potențial problematice din CONTINUARE.
Negare a adă ugat de considerente de servicii.
Marcarea proiectul gata de implementare.
Renumerotarea flag END_PUSH_PROMISE.
Clarifică ri editoriale și modifică ri.
Adă ugat cadru CONTINUARE pentru anteturi și PUSH_PROMISE.
PUSH_PROMISE nu mai este implicit interzisă dacă SETTINGS_MAX_CONCURRENT_STREAMS este zero.
Împinge extins pentru a permite toate metodele sigure, fă ră un corp cerere.
Clarificat utilizarea de câmpuri antet HTTP în cereri și ră spunsuri. -Hop-by-hop Câmpuri titluri HTTP/1.1 interzise.
Impune ca intermediarii nu cere înainte de rutare lipsă sau ilegal:-antete.
Cerințe clarificate în jurul valorii de manipulare diferite cadre după aproape curent, resetare curent șiGOAWAY .
A adă ugat interdicții mai specifice pentru trimiterea de diferite tipuri de cadre din diferite state flux.
Efectuarea ultima valoare de setare a primit valoarea efectivă .
Cerințe clarificate pe versiune TLS, extinderea și cifruri.
Comis atrocități majore de restructurare.
Trimitere adă ugat la primul proiect de compresie antet.
A adă ugat mai multe descriere formală a cadrului ciclului de viață .
END_STREAM mutat (redenumit de la final) înapoi la antetele / DATA .
Antete eliminate + PRIORITARE, a adăugat prioritate opțională pentru header- cadru.
A adă ugat PRIORITATE cadru.
Continuă ri a adă ugat cadre transporta blocuri de antet.
Utilizarea înlocuit de "sesiune" cu "conexiune", pentru a evita confuzia cu alte concepte statefull HTTP, cum ar fi cookie-
uri.
Eliminat "mesaj".
A trecut la TLS ALPN din NPN.
Modifică rile editoriale.
A adă ugat IANA secțiunea considerente de tipuri de cadru, codurile de eroare și setă rile.
Eliminat de compresie cadru de date.
A adă ugat PUSH_PROMISE .
A adă ugat steaguri aplicabile la nivel global pentru încadrare.
Eliminat antet mecanism de compresie bazate pe zlib.
Actualizat referințe.
Clarificat reutilizarea identificator flux.
Eliminat ACREDITARE cadru și mecanisme asociate.
Sfat adă ugat împotriva implementarea naiv de control al debitului.
Secțiune antet sesiune adă ugat.
Antet cadru restructurate. Distincție între îndepă rtat de date și cadre de control.
Altered proprietă ți de control al debitului pentru a include limite la nivel de sesiune.
Adă ugat notă pe cacheability de resurse împins și mai multe servere chiriaș.
Formularul eticheta protocol modificată pe baza discuțiilor.
Sa schimbat de-a lungul titlu.
Secțiune eliminat pe Incompatibilită ți cu SPDY proiect # 2.
Schimbat INTERNAL_ERROR pe GOAWAY de a avea o valoare de 2 < https://groups.google.com/forum/?fromgroups #!

topic/spdy-dev/cfUef2gL3iU >.
Înlocuit abstract și introducere.
Adă ugat secțiune pe incepand HTTP/2.0, inclusiv mecanism de upgrade.
Eliminat trimiteri neutilizate.
Principii de control al fluxului de adă ugate ( secțiunea 5.2.1 ), pe baza < http://tools.ietf.org/html/draft-montenegro-

httpbis-http2-fc-principles-01 >.
A.14 Din proiect-mbelshe-httpbis-SPDY-00
Adoptat ca bază pentru proiectul-IETF-httpbis-http2.
Actualizat autori / Lista editori.
A adă ugat notă de stare.

Cuprins Li

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cuprins Li

Încărcat de

Drepturi de autor:

Formate disponibile

Cuprins

2. HTTP / 2 Protocol Prezentare generală

Specificația HTTP / 2 este împă rțit în patru pă rți:

Se utilizează următorii termeni:

Obiectivul inițierea conexiunea HTTP / 2.

O conexiune la nivel de transport între două puncte finale.

O eroare care afectează întreaga conexiune HTTP / 2.

Fie clientul sau serverul a conexiunii.

Un obiectiv care se transmite cadre.

Obiectivul care nu a inițiat conexiunea HTTP / 2.

Un curent bidirecțional de cadre pe un canal virtuală în conexiunea HTTP / 2.

O eroare pe individ fluxul HTTP / 2.

3.1 HTTP / 2 Versiunea de identificare

Protocolul definite în prezentul document are doi identificatori.

3.2 Începând HTTP / 2 pentru URI-uri "http"

GET / HTTP/1.1 default.htm

HTTP/1.1 101 de Protocoale de comutare

3.2.1 HTTP2-Settings Antet Câmp

O cerere care upgrade-uri de la HTTP/1.1 la http / 2 TREBUIE să includă exact o HTTP2-Setăricâ mp de

Ca un domeniu-hop-hop cu antet, Conexiune câ mp de antet trebuie să includă o valoare de HTTP2-Setăriîn plus

3.3 Începând HTTP / 2 pentru "https" URI-uri

3.4 Începând HTTP / 2 cu cunoștințelor anterioare

(Ș irul PRI * HTTP/2.0 \ r \ n \ r \ Nm \ r \ n \ r \ n). Această secvență este urmată de

Domeniile de antet cadru sunt definite ca:

4.3 antet de compresie și de decompresie

Câmp de antet Cookie [COOKIE] este tratată special de cartografiere HTTP; a se vedea secțiunea 8.1.3.4 .

Un bloc complet antet constă fie:

 un singur antetele sau PUSH_PROMISE cadru, cu flag END_HEADERS, sau

Ciclul de viață al unui flux este prezentată în figura 1 .

H: cadru antete (cu continuări implicite)

Figura 1: Statele Stream

Fluxuri au urmă toarele state:

Urmă toarele tranziții sunt valide din această stare:

În această stare, numai urmă toarele tranziții sunt posibile:

Un obiectiv NU TREBUIE trimite altele decâ t cadre anteturi sau RST_STREAM în această stare.

rezervat (la distanță ):

În această stare, numai urmă toarele tranziții sunt posibile:

 Primirea unui header- cadru face ca fluxul de la trecerea la "jumă tate închis (local)".

jumă tate închis (local):

jumă tate închiși (la distanță ):

Starea de "închis" este starea terminalului.

WINDOW_UPDATE , PRIORITATEA , sau RST_STREAM cadre pot fi primite în acest stat pentru o perioadă scurtă de

Un obiectiv ar putea primi o PUSH_PROMISE cadru după ce trimite RST_STREAM . PUSH_PROMISEprovoacă un flux de

Un egal la egal poate limita numă rul de fluxuri concomitent activi

Izvoare in oricare dintre statele "rezervate" nu contează la fel de deschis.

HTTP / 2 prevede controlul fluxului prin utilizarea de WINDOW_UPDATE tipul de cadru.

5.2.1 Principii Flow Control

1. De control al fluxului este de-hop-hop prin, nu end-to-end.

5.2.2 Utilizarea corespunzătoare de control al debitului

Exemplu de Implicit Dependența Creation

Exemplu de Exclusive Dependența Creation

Priorită ți Stream sunt schimbate cu ajutorul PRIORITATE cadru. Setarea o dependență provoacă un curent de a deveni

Exemplu de Dependența Reordonarea

5.3.4 Prioritizarea Managementul de stat

5.4 de eroare de manipulare

HTTP / 2 încadrare permite două clase de eroare:

O listă a codurilor de eroare este inclusă în secțiunea 7 .

5.4.1 Eroare de conexiune de manipulare

5.4.2 Eroare Stream de manipulare

Un obiectiv nu trebuie să trimită o RST_STREAM ca ră spuns la o RST_STREAM cadru, pentru a evita looping.

DATE Frame Payload

Cadru de date conține urmă toarele câ mpuri:

Cadrului de date definește urmă toarele steagurile: