HTTP/2 - HTTP/2

HTTP/2
Kansainvälinen standardi RFC  7540
Kehittäjä IETF
Otettu käyttöön 14. toukokuuta 2015 ; 6 vuotta sitten ( 14.5.2015 )
Verkkosivusto https://http2.github.io/

HTTP / 2 (alunperin nimeltään HTTP / 2.0 ) on merkittävä tarkistaminen HTTP- protokolla, jota World Wide Web . Se on johdettu aiemmasta kokeellisesta SPDY -protokollasta, jonka Google on alun perin kehittänyt . HTTP / 2 kehitti HTTP työryhmä (kutsutaan myös httpbis, jossa " bis " tarkoittaa "kahdesti") on Internet Engineering Task Force (IETF). HTTP/2 on HTTP: n ensimmäinen uusi versio HTTP/1.1: n jälkeen, joka standardoitiin RFC  2068: ssä vuonna 1997. Työryhmä esitteli HTTP/2: n Internet Engineering Steering Groupille (IESG) harkittavaksi ehdotettuna standardina joulukuussa 2014, ja IESG hyväksyi sen julkaistavaksi ehdotettuna standardina 17. helmikuuta 2015 (ja päivitettiin helmikuussa 2020 TLS 1.3: n osalta ). HTTP/2 -määritys julkaistiin nimellä RFC  7540 14. toukokuuta 2015.

Standardointia tukivat Chrome- , Opera- , Firefox- , Internet Explorer 11- , Safari- , Amazon Silk- ja Edge -selaimet. Useimmat suuret selaimet olivat lisänneet HTTP/2 -tuen vuoden 2015 loppuun mennessä. Noin 97 prosentilla käytetyistä verkkoselaimista on mahdollisuus. Lokakuusta 2021 lähtien 47% (hieman yli 50%: n jälkeen) kymmenestä miljoonasta verkkosivustosta tuki HTTP/2 -protokollaa.

Sen ehdotettu seuraaja on HTTP/3 , merkittävä versio, joka perustuu HTTP/2: n määrittelemiin käsitteisiin.

Tavoitteet

Työryhmän työjärjestyksessä mainitaan useita tavoitteita ja huolenaiheita:

Erot HTTP: stä 1.1

Ehdotetut muutokset eivät edellytä muutoksia olemassa olevien verkkosovellusten toimintaan, mutta uudet sovellukset voivat hyödyntää uusia ominaisuuksia nopeammin. HTTP/2 jättää kaiken HTTP/1.1: n korkean tason semantiikan, kuten menetelmät , tilakoodit , otsikkokentät ja URI: t , samaksi. Uutta on se, miten tiedot kehystetään ja siirretään asiakkaan ja palvelimen välillä.

Sivustot, jotka ovat tehokkaita minimoimaan pyyntöjen määrä tarvitaan muodostamaan kokonaisen sivun koodin pienentämisellä (vähentämällä ja pakkauskoodi pienempi koodiksi nippuihin, vähentämättä toimintakyky) resursseja, kuten kuvia ja skriptejä. Minimointi ei kuitenkaan ole välttämättä kätevää eikä tehokasta, ja se saattaa silti vaatia erilliset HTTP -yhteydet sivun ja pienennettyjen resurssien saamiseksi. HTTP/2 sallii palvelimen "työntää" sisältöä eli vastata tiedoilla useampiin kyselyihin kuin asiakas pyysi. Tämän avulla palvelin voi toimittaa tietoja, jotka se tietää, että selaimen on muodostettava verkkosivu odottamatta, että selain tutkii ensimmäisen vastauksen ja ilman ylimääräistä pyyntöjaksoa.

Lisäsuorituskykyä parannettiin ensimmäisessä HTTP/2-luonnoksessa (joka oli SPDY-kopio) pyyntöjen ja vastausten multipleksoinnista , jotta vältettäisiin osa HTTP-1: n pään esto- ongelmista (vaikka käytettäisiin HTTP-putkilinjoja ), otsikoiden pakkaus ja pyyntöjen priorisointi. Kuitenkin, koska HTTP/2 toimii yksittäisen TCP-yhteyden päällä, on silti mahdollista, että pään esto estetään, jos TCP-paketit katoavat tai niiden lähettäminen viivästyy. HTTP/2 ei enää tue HTTP/1.1: n paloitettua siirtokoodausmekanismia , koska se tarjoaa omat, tehokkaammat mekanismit tietojen suoratoistoon.

Historia

Genesis ja myöhemmin erot SPDY: stä

SPDY (lausutaan kuten "nopea") oli edellinen HTTP-korvausprotokolla, jonka on kehittänyt Googlen johtama tutkimusprojekti . Pääasiassa latenssin vähentämiseen keskittynyt SPDY käyttää samaa TCP -putkea, mutta eri protokollia tämän vähennyksen saavuttamiseksi. Perusmuutokset, jotka tehtiin HTTP/1.1: een SPDY: n luomiseksi, olivat: "todellinen pyyntöjen liittäminen ilman FIFO-rajoituksia, viestien kehystysmekanismi asiakkaan ja palvelimen kehittämisen yksinkertaistamiseksi, pakollinen pakkaus (mukaan lukien otsikot), prioriteettien ajoitus ja jopa kaksisuuntainen viestintä".

HTTP Työryhmä käsitteli Googlen SPDY protokolla, Microsoft : n HTTP-Speed + Liikkuvuus ehdotuksen (SPDY pohjainen), ja verkko-HTTP päivitys. Heinäkuussa 2012 Facebook antoi palautetta jokaisesta ehdotuksesta ja suositteli, että HTTP/2 perustuu SPDY: hen. HTTP/2: n alkuperäinen luonnos julkaistiin marraskuussa 2012 ja se perustui suoraan SPDY -kopioon.

Suurin ero HTTP/1.1: n ja SPDY: n välillä oli, että jokaiselle SPDY -toiminnolle annetaan "virran tunnus", mikä tarkoittaa, että käyttäjä ja palvelin yhdistävät yhden TCP -kanavan. SPDY jakoi pyynnöt joko ohjaukseksi tai dataksi käyttämällä "yksinkertaista jäsentää binaariprotokollaa, jossa on kahdenlaisia ​​kehyksiä". SPDY paransi selvästi HTTP: tä, ja uuden sivun latausnopeus vaihteli 11%: sta 47%: iin.

HTTP/2: n kehittämisessä käytettiin SPDY: tä hyppypisteenä. Protokollien monien yksityiskohtaisten erojen joukossa merkittävin on, että HTTP/2 käyttää kiinteää Huffman -koodipohjaista otsikkopakkausalgoritmia SPDY: n dynaamisen streamipohjaisen pakkauksen sijaan. Tämä auttaa vähentämään mahdollisuutta pakata oraakkelihyökkäyksiä protokollaan, kuten CRIME -hyökkäykseen.

Google ilmoitti 9. helmikuuta 2015 aikovansa poistaa SPDY -tuen Chromesta HTTP/2 -tuen hyväksi. Tämä tuli voimaan alkaen Chrome 51: stä.

Kehityksen virstanpylväät

Päivämäärä Virstanpylväs
20. joulukuuta 2007 Ensimmäinen HTTP/1.1 -versio Internet -luonnos
23. tammikuuta 2008 Ensimmäinen HTTP -suojausominaisuudet Internet -luonnos
Vuoden 2012 alussa Ehdotuspyynnöt HTTP 2.0: lle
14. lokakuuta - 25. marraskuuta 2012 Työryhmän viimeinen puhelu HTTP/1.1 -versiota varten
28. marraskuuta 2012 Ensimmäinen HTTP 2.0: n luonnos, joka perustuu luonnokseen mbelshe-httpbis-spdy-00
Pidetty/eliminoitu Työryhmän viimeinen puhelu HTTP -suojausominaisuuksia varten
Syyskuu 2013 Lähetä HTTP/1.1 -versio IESG : lle ehdotetuksi standardiksi
12. helmikuuta 2014 IESG hyväksyi HTTP/1.1 -version julkaistavaksi ehdotettuna standardina
6. kesäkuuta 2014 Julkaise HTTP/1.1 -versio nimellä RFC  7230 , 7231 , 7232 , 7233 , 7234 , 7235
1. elokuuta 2014 - 1. syyskuuta 2014 Työryhmä HTTP/2: n viimeinen puhelu
16. joulukuuta 2014 Lähetä HTTP/2 IESG: lle ehdotetuksi standardiksi
31. joulukuuta 2014 - 14. tammikuuta 2015 IETF: n viimeinen puhelu HTTP/2: lle
22. tammikuuta 2015 IESG telechat tarkistaa HTTP/2 ehdotetuksi standardiksi
17. helmikuuta 2015 IESG hyväksyi HTTP/2: n julkaisemiseksi ehdotettuna standardina
14. toukokuuta 2015 Julkaise HTTP/2 nimellä RFC  7540
Helmikuuta 2020 RFC  8740 : HTTP/2 ja TLS 1.3

Salaus

HTTP/2 on määritetty sekä HTTP URI -tunnuksille (eli ilman TLS -salausta , kokoonpano, joka on lyhennetty h2c: ssä ) että HTTPS -URI -tunnuksille (TLS: n kautta käyttäen ALPN -laajennusta, jossa vaaditaan TLS 1.2 tai uudempi, kokoonpano, joka on lyhennetty h2: ssa ).

Vaikka standardi itsessään ei vaadi salauksen käyttöä, kaikki tärkeimmät asiakkaan toteutukset (Firefox, Chrome, Safari, Opera, IE, Edge) ovat ilmoittaneet tukevansa vain HTTP/2 -protokollaa TLS: n kautta, mikä tekee salauksesta de facto pakollisen.

Kritiikkiä

HTTP/2: n kehitysprosessia ja protokollaa on arvosteltu.

FreeBSD ja Lakat kehittäjä Poul-Henning Kamp väittää, että standardi on laadittu epärealistisen nopealla aikataululla, sulkematta pois mitään perustetta uusi HTTP / 2 muu kuin SPDY protokollaa ja jolloin muut menetettyjä mahdollisuuksia parantaa. Kamp arvostelee itse protokollaa epäjohdonmukaisuudesta ja tarpeettomasta, ylivoimaisesta monimutkaisuudesta. Hän toteaa myös, että protokolla rikkoo protokollakerrosperiaatetta , esimerkiksi kopioimalla siirtokerrokseen (TCP) kuuluvan virtauksen ohjauksen. Suurin osa huolenaiheista on kuitenkin liittynyt salausongelmiin.

Salaus

Pakolliset salauksen laskennalliset kustannukset ja varmenteiden saatavuus

Aluksi jotkut työryhmän jäsenet yrittivät ottaa protokollaan käyttöön salausvaatimuksen. Tämä kohtasi kritiikkiä.

Kriitikot totesivat, että salauksella on vähäiset laskutuskustannukset ja että monet HTTP-sovellukset eivät itse asiassa tarvitse salausta eivätkä niiden tarjoajat halua käyttää lisäresursseja siihen. Salauskannattajat ovat todenneet, että tämä salauskustannus on käytännössä vähäinen. Poul-Henning Kamp on arvostellut IETF: ää siitä, että se standardisoi kiireesti Googlen SPDY-prototyypin HTTP/2-muotoon poliittisten syiden vuoksi. Kritiikki pakollisen salauksen asialistalle nykyisessä varmennekehyksessä ei ole uutta eikä se ole ainutlaatuista avoimen lähdekoodin yhteisön jäsenille- Ciscon työntekijä totesi vuonna 2013, että nykyinen varmenne ei ole yhteensopiva pienten laitteiden, kuten reitittimien, kanssa. koska nykyinen malli ei edellytä vuosittain ilmoittautumista ja ei-vähäpätöisten maksujen peruuttamista jokaisesta todistuksesta, vaan se on toistettava jatkuvasti vuosittain. Työryhmä ei lopulta päässyt yksimielisyyteen pakollisesta salauksesta, vaikka useimmat asiakkaan toteutukset edellyttävät sitä, mikä tekee salauksesta tosiasiallisen vaatimuksen.

Opportunistisen salauksen puute

HTTP/2 -protokollaa kritisoitiin myös siitä, että se ei tukenut opportunistista salausta , joka on passiivisen valvonnan vastainen toimenpide , joka on samanlainen kuin STARTTLS -mekanismi, joka on pitkään ollut saatavilla muissa Internet -protokollissa, kuten SMTP . Kriitikot ovat todenneet, että HTTP/2 -ehdotus rikkoo IETF: n omaa RFC  7258 "Pervasive Monitoring Is a Attack" -järjestelmää , jolla on myös paras nykyinen käytäntö 188. RFC7258/BCP188 velvoittaa passiivisen valvonnan pitämään hyökkäyksenä, ja IETF: n suunnittelemien protokollien tulisi suojautua passiiviselta valvonnalta (esimerkiksi käyttämällä opportunistista salausta). HTTP/2: n opportunistiselle salaukselle on toimitettu useita eritelmiä, joista luonnos-nottingham-http2-salaus hyväksyttiin työryhmän viralliseksi työkohteeksi, minkä seurauksena RFC  8164 julkaistiin toukokuussa 2017.

TCP-rivin esto

Vaikka HTTP/2: n suunnittelu ratkaisee tehokkaasti HTTP-tapahtumatason päätelaitteen esto- ongelman sallimalla useita samanaikaisia ​​HTTP-tapahtumia, kaikki nämä tapahtumat multipleksoidaan yhdellä TCP-yhteydellä, mikä tarkoittaa, että kaikki pakettitason päätelaitteet TCP -virran rivin esto estää samanaikaisesti kaikki tapahtumat, joita käytetään tämän yhteyden kautta. Tätä HTTP/2: n huippuluokan estoa pidetään nykyään laajalti suunnitteluvirheenä, ja suuri osa QUIC- ja HTTP/3-toiminnoista on omistettu vähentämään huippuluokan esto-ongelmia.

Palvelinpuolen tuki

Palvelinohjelmisto

  • Apache 2.4.12 tukee HTTP/2: ta moduulin mod_h2 kautta, vaikka palvelimen lähdekoodiin on kiinnitettävä asianmukaiset korjaustiedostot, jotta se tukee kyseistä moduulia. Apache 2.4.17: stä lähtien kaikki korjaustiedostot sisältyvät Apache -päälähdepuuhun, vaikka itse moduuli nimettiin uudelleen mod_http2. SPDY: n vanhoja versioita tuettiin moduulin mod_spdy kautta, mutta mod_spdy -moduulin kehitys on pysähtynyt.
  • Apache Tomcat tukee HTTP/2 -versiota 8.5 ja uudempia, joiden kokoonpano on muutettu.
  • Apache Traffic Server tukee HTTP/2 -protokollaa.
  • Caddy tukee HTTP/2 -protokollaa.
  • Charles -välityspalvelin tukee HTTP/2 -versiota Charles 4 -versiosta lähtien.
  • Citrix NetScaler 11.x tukee HTTP/2 -protokollaa.
  • Sucuri tukee HTTP/2.
  • F5 BIG-IP Local Traffic Manager 11.6 tukee HTTP/2-protokollaa.
  • Barracuda Networks WAF (Web Application Firewall) tukee HTTP/2 -protokollaa.
  • h2o rakennettiin alusta asti HTTP/2 -tuelle.
  • HAProxy 1.8 tukee HTTP/2 -protokollaa.
  • Jetty 9.3 tukee HTTP/2 -protokollaa.
  • lighttpd 1.4.56 tukee HTTP/2 -protokollaa.
  • LiteSpeed ​​Web Server 5.0 tukee HTTP/2 -protokollaa.
  • Microsoft IIS tukee HTTP/2: ta Windows 10: ssä, Windows Server 2016 : ssa ja Windows Server 2019: ssä .
  • Netty 4.1 tukee HTTP/2 -protokollaa.
  • Nginx 1.9.5 tukee HTTP / 2, julkaistiin 22. syyskuuta 2015 käyttäen moduulia ngx_http_v2_module ja HTTP / 2 Server Push sitten version 1.13.9 20. helmikuuta 2018 saakka.
  • Node.js Vakaa tuki 8.13.0. (5.0 tukee HTTP/2-moduulia ja solmu 8.4 esitteli kokeellisen sisäänrakennetun HTTP/2-tuen.)
  • Kestrel-verkkopalvelin ASP.NET Corelle tukee HTTP/2: ta .NET Core 2.2.0 -esikatselun 1 jälkeen.
  • OpenLiteSpeed ​​1.3.11 ja 1.4.8 tukevat HTTP/2 -protokollaa.
  • Proxygen tukee HTTP/2 -protokollaa.
  • Pulse Secure Virtual Traffic Manager 10.2 tukee HTTP/2 -protokollaa.
  • Radware Alteon NG tukee HTTP/2 -protokollaa.
  • ShimmerCat tukee HTTP/2 -protokollaa.
  • Vert.x 3.3 tukee HTTP/2 -protokollaa.
  • Warp ( Haskell -verkkopalvelin, jota käytetään oletuksena Yesodissa ) tukee HTTP/2 -protokollaa.
  • Wildfly 9 tukee HTTP/2 -protokollaa.
  • Lähettilään välityspalvelin tukee HTTP/2 -protokollaa.

Sisällönjakeluverkot

  • Akamai oli ensimmäinen merkittävä CDN, joka tuki HTTP/2- ja HTTP/2 -palvelinpalvelusta .
  • Microsoft Azure tukee HTTP/2 -protokollaa.
  • PageCDN tukee HTTP/2-pakettia valmiina ja tarjoaa käyttöliittymän HTTP/2-palvelimen asennuksen asettamiseen CDN-hallintapaneelissa.
  • CDN77 tukee HTTP/2 -protokollaa nginxin avulla (20. elokuuta 2015) .
  • Cloudflare tukee HTTP/2 -protokollaa, jossa käytetään nginx -protokollaa SPDY: n kanssa varaosana selaimille, jotka eivät tue, säilyttäen samalla kaikki tietoturva- ja suorituskykypalvelut. Cloudflare oli ensimmäinen suuri CDN, joka tuki HTTP/2 Server Pushia .
  • AWS CloudFront tukee HTTP/2 -protokollaa 7.9.2016 lähtien.
  • Tukee nopeasti HTTP/2 -protokollaa, mukaan lukien Server Push.
  • Imperva Incapsula CDN tukee HTTP/2 -protokollaa. Toteutus sisältää tukea myös WAF- ja DDoS -lieventämisominaisuuksille.
  • KeyCDN tukee HTTP/2 -protokollaa nginxin avulla (6. lokakuuta 2015). HTTP/2 -testi on testisivu, jolla voit tarkistaa, tukeeko palvelimesi HTTP/2 -protokollaa.
  • Voxility tukee HTTP/2: ta nginxin avulla heinäkuusta 2016 lähtien. Toteutus tukee Cloud DDoS -lievennyspalveluja.
  • StackPath tukee HTTP/2 -protokollaa.

Toteutukset

Katso myös

Viitteet

Ulkoiset linkit