• Käännös

HTTP-standardin uusi versio on äskettäin julkaistu. HTTP/2 hyväksyttiin toukokuussa 2015, ja se on yleistynyt selaimissa ja verkkopalvelimissa (mukaan lukien NGINX ja NGINX Plus). Tällä hetkellä yli 60 % käytössä olevista selaimista tukee HTTP/2:ta, ja tämä luku kasvaa edelleen joka kuukausi.

HTTP/2-standardi perustuu SPDY-protokollaan, jonka on kehittänyt Googlelta. Google Chrome tukee SPDY:tä vuoden 2016 alkuun asti. NGINX oli yksi ensimmäisistä, jotka ottivat käyttöön SPDY-protokollan, ja nyt sillä on johtava rooli HTTP/2:n edistämisessä. Julkaistu, jossa se annettiin yksityiskohtainen kuvaus HTTP/2, vertaa sitä SPDY:hen ja kuvaa yksityiskohtaisesti uuden protokollan käyttöönottoprosessia.

HTTP/2:n pääominaisuudet ovat samanlaisia ​​kuin SPDY:n:

• HTTP/2 on binaarinen, ei tekstiprotokolla, mikä tekee siitä kompaktimman ja tehokkaamman.
• HTTP/2 käyttää vain yhtä multipleksointiyhteyttä isäntään sen sijaan, että useat yhteydet siirtäisivät yhden tiedoston kerrallaan.
• HTTP/2 käyttää erikoistunutta HPACK-protokollaa otsikoiden pakkaamiseen (SPDY:ssä käytetyn gzipin sijaan).
• HTTP/2:ssa sitä käytetään monimutkainen mekanismi priorisointi antaa selaimille eniten tarvittavat tiedostot Ensinnäkin (SPDY käytti yksinkertaisempaa algoritmia).

Nyt meidän on mentävä syvemmälle ja tarkasteltava lähemmin uuden protokollan ominaisuuksia. Tämä artikkeli on kirjoitettu auttamaan päätöksenteossa siirtyä HTTP/2:een, ja se käsittelee myös mahdollisia optimointeja protokollaa toteutettaessa.

1. Lopeta HTTP/2
2. Aloita SPDY:n käyttö
3. Vältä HTTP/1.x-optimointia
4. Ota käyttöön HTTP/2 tai SPDY
5. Tutustu HTTP/1.x-optimointeihin
6. Harkitse HTTP/2-ystävällistä jakamista

Huomautus: SPDY ja HTTP/2 eivät varsinaisesti vaadi TLS:ää, mutta suurin hyöty tulee, kun SSL/TLS on käytössä, joten selaimet tukevat vain SPDY:tä ja HTTP/2:ta, jos SSL/TLS on olemassa.

Arvioi HTTP/2:n käyttöönoton tarve

HTTP/2:n käyttöönotto ei ole vaikeaa ja prosessi kuvataan yksityiskohtaisesti. On kuitenkin syytä ymmärtää, että HTTP/2 ei ole universaali ratkaisu ja saattaa olla hyödyllistä joissakin sovelluksissa, mutta ei toisissa.

On esimerkiksi erittäin todennäköistä, että HTTP/2 nopeuttaa sivustoa, joka jo käyttää SSL/TLS:ää (tästä eteenpäin lyhennettynä TLS), muuten TLS on otettava käyttöön ennen HTTP/2:n käyttöönottoa. On syytä huomata, että TLS:n käyttö saattaa aiheuttaa suorituskykyä, mikä voi kumota HTTP/2:n nopeuden. Siksi tämä tapaus kannattaa tarkistaa ensin.

1. Vain yhtä yhteyttä palvelimeen käytetään useiden yhteyksien sijaan, jotka siirtävät yhden tiedoston kerrallaan. Toisin sanoen yhteyksien määrä vähenee, mikä on erityisen hyödyllistä TLS:ää käytettäessä.
2. TLS:n tehokas käyttö. HTTP/2 tekee vain yhden TLS-kättelyn, ja multipleksointi mahdollistaa tämän yhteyden tehokkaan käytön. HTTP/2 pakkaa myös otsikkotiedot, ja HTTP/1.x-optimoinnin (kuten tiedostojen yhdistämisen) poistaminen mahdollistaa välimuistialgoritmin toiminnan tehokkaammin.
3. Web-sovellusten yksinkertaistaminen. Käyttämällä HTTP/2:ta voit päästä eroon HTTP/1.x-optimoinneista, jotka myös aiheuttavat hankaluuksia kehittäjille.
4. Erinomainen monimutkaisille verkkosivuille. HTTP/2 sopii erinomaisesti verkkosivuille, jotka käyttävät HTML:ää, CSS:ää, JavaScriptiä, kuvia ja videoita samanaikaisesti. Selaimet voivat priorisoida tiedostopyynnöt niin, että sivun tarpeellisimmat osat lähetetään ensin.
5. Yhteyden suojaus. Vaikka HTTP/2:ta käytettäessä voi esiintyä suorituskyvyn heikkenemistä TLS:n käytön vuoksi, TLS tekee samalla verkkosovelluksia käyttäjille turvallisempia.

Ja viisi vastaavaa haittaa, joita saatat kohdata:

1. Korkeat kustannukset yhdestä liittymästä. HPACK-tiedonpakkausalgoritmi vaatii LUT-tuen molemmista päistä. Lisäksi tarvitaan enemmän muistia yhtä yhteyttä kohti.
2. On mahdollista, että TLS:ää käytetään redundantti. Jos lähetettävää tietoa ei tarvitse suojata tai se on jo suojattu DRM:llä (tai muulla salauksella), TLS:stä ei todennäköisesti ole hyötyä.
3. Nykyisten HTTP/1.x-optimointien löytäminen ja poistaminen on välttämätöntä HTTP/2-suorituskyvyn parantamiseksi, mikä on lisätyötä.
4. Ei tarjoa etuja ladattaessa suuria tiedostoja. Jos verkkosovellus on ensisijaisesti suunniteltu suurten tiedostojen lataamiseen tai videoiden suoratoistoon, on todennäköistä, että TLS:n käyttö on harhaanjohtavaa eikä multipleksoinnista ole mitään hyötyä.
5. Turvallisuus ei ole tärkeää. Ehkä kävijät eivät välitä siitä, että heidän sivustollasi jakamiaan kissavideoita ei suojata TLS:llä ja HTTP/2:lla (mikä voi olla totta).

Kaikki riippuu suorituskyvystä ja on hyviä ja huonoja uutisia.

Hyvä uutinen on, että NGINX:ssä tehtyjen testien perusteella teoriasta ennustetut tulokset seuraavat: monimutkaisilla verkkosivuilla, joita pyydetään tyypillisellä latenssilla, HTTP/2-suorituskyky on parempi kuin HTTP/1.x ja HTTPS. Tulokset on jaettu kolmeen ryhmään tyypillisen edestakaisen matka-ajan (RTT) mukaan:

• Erittäin alhaiset RTT:t (0–20 ms): HTTP/1.x:n, HTTP/2:n ja HTTPS:n välillä ei ole käytännössä mitään eroa.
• Keskimääräiset (verkkotyypilliset) RTT:t (30–250 ms): HTTP/2 on nopeampi kuin HTTP/1.x, ja molemmat ovat nopeampia kuin HTTPS. Yhdysvaltojen naapurikaupungeissa RTT on noin 30 ms ja noin 70 ms rannikolta rannikolle (noin 3000 mailia). Yhdellä lyhyimmistä reiteistä Tokion ja Lontoon välillä RTT on noin 240 ms.
• Korkeat RTT:t (300 ms ja enemmän): HTTP/1.x on nopeampi kuin HTTP/2, joka on nopeampi kuin HTTPS.

Kuvassa näkyy aika ennen renderöinnin alkamista eli aikaa, jonka jälkeen käyttäjä näkee verkkosivun ensimmäisen sisällön. Tämän ajan katsotaan usein määräävän sen, kuinka käyttäjät näkevät verkkosivuston reagointikyvyn.

Tarkemmat tiedot testausprosessista ja tuloksista löytyvät osoitteesta esityksiä nginx.conf 2015 -konferenssista.

Jokainen verkkosivu ja käyttäjäistunto on kuitenkin erilainen. Jos sinulla on esimerkiksi videon suoratoisto tai suuria ladattuja tiedostoja, tulokset voivat olla erilaisia ​​tai jopa päinvastaisia.

Tärkeintä on, että sinun on ensin ymmärrettävä mahdolliset kustannukset ja suurimmat edut käytettäessä HTTP/2:ta. Sen jälkeen sinun tulee testata sovellusten suorituskykyä ja tehdä valinta.

Lopeta HTTP/2

Lopettaminen tarkoittaa, että asiakas voi muodostaa yhteyden välityspalvelimeen tietyn protokollan, kuten HTTP/2, kautta, ja sitten välityspalvelin muodostaa yhteyden palvelinsovelluksiin, tietokantoihin jne. käyttämällä täysin eri protokollaa (katso kuva alla).

Käytettäessä erilliset palvelimet, on mahdollista siirtyä usean palvelimen arkkitehtuuriin. Palvelimia voidaan jakaa fyysisesti, virtuaalisesti tai pilviympäristössä, kuten AWS. Tämä lisää arkkitehtuuriin monimutkaisuutta verrattuna yhden palvelimen ratkaisuun tai palvelin+tietokanta-yhdistelmään, mutta tarjoaa monia etuja ja on välttämättömyys paljon kuormitettaville sivustoille.

Fyysisen tai virtuaalinen palvelin asennettu eteen olemassa oleva järjestelmä, tulevat saataville lisäominaisuuksia. Uusi palvelin vapauttaa muut palvelimet asiakasviestien käsittelystä. Lisäksi sitä voidaan käyttää kuormituksen tasapainottamiseen, staattisten tiedostojen välimuistiin ja muihin tarkoituksiin. Helpottaa huomattavasti lisäämistä ja korvaamista palvelinsovelluksia ja muita palvelimia tarpeen mukaan.

NGINX- ja NGINX Plus -palveluita käytetään usein kaikkiin näihin tarkoituksiin - TLS- ja HTTP/2-terminointiin, kuormituksen tasapainottamiseen ja muihin. Olemassa oleva ympäristö ei vaadi muutoksia, lukuun ottamatta osaa, joka koskee käyttäjän vuorovaikutusta NGINX-palvelimen kanssa.

Aloita SPDY:n käyttö

SPDY on edeltäjä HTTP-protokolla/2 ja sen suorituskyky on verrattavissa HTTP/2:een. Koska SPDY on ollut olemassa useita vuosia, kaikki suositut selaimet tukevat sitä, toisin kuin HTTP/2, joka ilmestyi suhteellisen hiljattain. Tätä kirjoitettaessa kuilu on kuitenkin sulkeutumassa ja yli 60 % selaimista tukee jo HTTP/2:ta, kun taas SPDY tukee yli 80 %:a.

Jos on kiireellinen tarve ottaa käyttöön uusi kuljetusprotokolla, ja käyttääksesi protokollaa, jolla on maksimaalinen tuki käyttäjien keskuudessa, sinun tulee aloittaa SPDY:stä. Myöhemmin, vuoden 2016 alussa, kun SPDY:n tuki poistetaan, vaihda HTTP/2:een. Tähän mennessä useampi käyttäjä käyttää HTTP/2:ta tukevia selaimia, joten tämä siirtymä saattaa olla optimaalinen useimpien käyttäjien kannalta.

Vältä HTTP/1.x-optimointeja

Ennen HTTP/2:n käyttöönottoa on tarpeen tunnistaa HTTP/1.x:n optimoinnit. Tässä on neljä harkittavaa optimointityyppiä:

1. Jakaminen. Tiedostojen asettaminen päälle eri verkkotunnuksia rinnakkaiseen siirtoon selaimeen; Sisällönjakeluverkot (CDN) tekevät tämän automaattisesti. Tämä optimointi voi heikentää HTTP/2:n suorituskykyä. Voit käyttää HTTP/2-ystävällistä jakoa HTTP/1.x-käyttäjille (katso HTTP/2-ystävällinen jako).
2. Spritejen käyttö. Spritet ovat kuvakokoelmia, jotka siirretään yhtenä tiedostona; Tämän jälkeen asiakkaan puolelta haetaan kuvia kokoelmasta tarpeen mukaan. Tämä optimointi on vähemmän tehokas käytettäessä HTTP/2:ta, vaikka siitä voi silti olla hyötyä.
3. Tiedostojen yhdistäminen. Kuten sprite, jotkut tiedostot, jotka yleensä tallennetaan erikseen, yhdistetään yhdeksi. Sitten selain löytää ja suorittaa koodin tarvittaessa yhdistetystä tiedostosta.
4. Tiedostojen upottaminen. CSS, JavaScript ja jopa kuvat lisätään suoraan HTML-tiedostoon, mikä vähentää siirrettävien tiedostojen määrää suurentamalla alkuperäistä HTML-tiedostoa.

Viimeiset kolme optimointityyppiä, pienten tiedostojen yhdistäminen suurempiin tiedostoihin, uusien yhteyksien karsiminen ja lisäyhteyksien alustaminen, ovat erityisen tärkeitä TLS:ää käytettäessä.

Ensimmäinen optimointi, sharding, toimii eri tavalla - se pakottaa avaamaan enemmän yhteyksiä käyttämällä muita verkkotunnuksia. Yhdessä nämä näennäisesti ristiriitaiset menetelmät voivat olla varsin tehokkaita parantamaan HTTP/1.x-sivustojen suorituskykyä. He kaikki käyttävät kuitenkin aikaa, vaivaa ja resursseja toimintojen kehittämiseen, toteuttamiseen, hallintaan ja ylläpitoon.

Ennen HTTP/2:n käyttöönottoa sinun tulee etsiä nämä optimoinnit ja ymmärtää, kuinka ne tällä hetkellä vaikuttavat sovellusten suunnitteluun ja työnkulkuun. Tämä tulee tehdä, jotta voit muuttaa tai kumota näitä optimointeja siirryttyäsi HTTP/2:een.

Ota käyttöön HTTP/2 tai SPDY

Itse asiassa HTTP/2:een tai SPDY:hen siirtyminen on melko yksinkertaista. NGINX-käyttäjille sinun on yksinkertaisesti otettava protokolla käyttöön NGINX-kokoonpanossa HTTP/2-esimerkissä kuvatulla tavalla. Tämän jälkeen palvelin ilmoittaa asiakasselaimelle mahdollisuudesta käyttää HTTP/2:ta tai SPDY:tä.

Kun HTTP/2 on otettu käyttöön palvelimella, käyttäjät, joiden selaimet tukevat HTTP/2:ta, muodostavat yhteyden ja työskentelevät verkkosovellusten kanssa HTTP/2:n kautta. Ihmisten, joilla on vanhempia selainversioita, on käytettävä HTTP/1.x:n kautta (katso kuva alla). Kun otat HTTP/2:ta tai SPDY:tä käyttöön paljon kuormitettavilla sivustoilla, sinun tulee mitata suorituskykyä ennen ja jälkeen ja peruuttaa muutokset, jos kielteisiä seurauksia ilmenee.

Huomautus: Koska HTTP/2:n käyttöönotto käyttää yhtä yhteyttä, joistakin NGINX:n kokoonpanoasetuksista tulee entistä tärkeämpiä. Suositeltu katselu NGINX-kokoonpano Kanssa erityistä huomiota ohjeiden, kuten output_buffers, proxy_buffers ja ssl_buffer_size, parametrien konfigurointiin ja testaamiseen. Sinun tulee kiinnittää huomiota erityisiin TLS- ( ja )- ja NGINX-suorituskykyvinkkeihin, kun käytät TLS:ää.

Huomautus: Kun käytät salauksia HTTP/2:n kanssa, ota huomioon seuraavat asiat: HTTP/2:n RFC:ssä on pitkä luettelo salauksista, joita tulee välttää. Jos haluat muokata salausluetteloa itse, on suositeltavaa harkita ssl_ciphers-asetusten määrittämistä ja ssl_prefer_server_ciphers-toiminnon käyttöönottoa ja sitten asianmukaisten salausten testaamista kaikilla suosituilla selainversioilla. Indikaattori for suositut selaimet Qualysin SSL-palvelintestiä (marraskuusta 2015 lähtien) pidetään epäluotettavana HTTP/2-kättelyjen laskennassa.

Yllättäen HTTP/1.x-optimoinnin poistaminen tai muuttaminen on HTTP/2:n käyttöönoton luovin osa. On useita asioita, jotka on otettava huomioon.

Ennen kuin teet muutoksia, sinun tulee ottaa huomioon vanhempien selainten käyttäjät, joita tämä saattaa koskea. Tämä mielessä pitäen HTTP/1.x-optimoinnin kumoamiseen tai tarkistamiseen on kolme päästrategiaa:

• Kaikki on valmista. Jos sovelluksia ei ole optimoitu HTTP/1.x:lle tai pieniä muutoksia on tehty, olet valmis käyttämään HTTP/2:ta.
• Sekalainen lähestymistapa. Tietojen yhdistämistä voidaan vähentää, mutta ei kokonaan eliminoida. Esimerkiksi joitakin kuvaspriitejä saattaa jäädä, kun HTML-koodiin upotettu data poistetaan.
• HTTP/1.x-optimoinnin täydellinen hylkääminen (mutta katso HTTP/2-ystävällinen jako ja huomautukset). Voit yksinkertaisesti päästä eroon optimoinnista kokonaan.

Välimuistissa on joitain erityispiirteitä. Teoriassa välimuisti toimii tehokkaasti, kun sitä käytetään moniin pieniin tiedostoihin. Tässä tapauksessa se kuitenkin pätee suuri määrä I/O-toiminnot. Siksi toisiinsa liittyvien tiedostojen yhdistäminen voi olla hyödyllistä sekä työnkulun että sovelluksen suorituskyvyn kannalta. Jakaminen on ehkä haastavin ja samalla ehkä menestynein HTTP/1.x-optimointistrategia. Jakamista voidaan käyttää parantamaan HTTP/1.x:n suorituskykyä, mutta HTTP/2:ssa (joka käyttää vain yhtä yhteyttä) se jätetään suurelta osin huomiotta.

Jos haluat käyttää jakamista yhdessä HTTP/2:n kanssa, sinun on tehtävä kaksi asiaa:

• Tee siitä niin verkkotunnuksia resurssien jakamista varten he päättivät samoihin IP-osoitteisiin.
• Varmista, että käytetään jokerimerkkivarmennetta - tässä tapauksessa se on voimassa kaikille jakamiseen käytetyille verkkotunnuksille. Tai varmista, että sinulla on asianmukainen usean verkkotunnuksen varmenne.

Tarkemmat tiedot löytyvät.

Jos nämä ehdot täyttyvät, HTTP/1.x:n jakaminen tapahtuu - koska verkkotunnukset ovat erilaisia, joten selaimet voivat luoda lisäsarjat yhteydet - ja se ei tapahdu HTTP/2:lle, koska yksittäisiä verkkotunnuksia käsitellään yhtenä ja yhteys voi käyttää mitä tahansa niistä.

Johtopäätös

On todennäköistä, että HTTP/2 ja TLS auttaa parantamaan sivustosi suorituskykyä ja antaa käyttäjille mahdollisuuden olla varma, että heidän yhteysnsa on turvallinen. Lisäksi HTTP/2-tuen käyttöönotto ei todennäköisesti vaadi paljon vaivaa.

Yllä kuvattujen vinkkien pitäisi auttaa sinua saavuttamaan paras suoritus HTTP/2 vähimmällä vaivalla, jotta loppuaikasi voidaan käyttää nopeiden, tehokkaiden ja turvallisten sovellusten rakentamiseen.

Tunnisteet: Lisää tunnisteita

Viime vuonna maailmassa verkkoteknologiat Tapahtui erittäin tärkeä tapahtuma: HTTP-protokollan uusi versio, HTTP/2, hyväksyttiin ja standardoitiin. HTTP/2 on jo tuettu suosituissa verkkopalvelimissa: Apache ja Nginx. HTTP/2:n käyttöönotto IIS:ssä on käynnissä. Tuki on toteutettu myös useimmissa nykyaikaisissa selaimissa.

HTTP/2:n käyttö viime aikoina on laajentunut merkittävästi.

Vuoden 2015 puolivälissä HTTP/2:een siirtyneiden sivustojen ja verkkopalvelujen prosenttiosuus oli pieni – vain 0,4 %. Hyvin tuoreet tilastot (tammikuu 2016) osoittavat merkittävän kasvun: 0,4 prosentista 6,5 ​​prosenttiin. On täysi syy uskoa, että kasvuvauhti kiihtyy lähitulevaisuudessa.

miettiä käytännön näkökohtia HTTP/2:een siirtyminen kannattaa nyt. Haluaisimme käsitellä tätä aihetta tämän päivän artikkelissa. Olemme erityisen kiinnostuneita sopeutumisongelmasta olemassa olevista tekniikoista optimoida verkkosivuston suorituskyky uuden protokollan ominaisuuksien mukaan.
Ennen kuin siirrymme suoraan tämän ongelman tarkasteluun, siirrytään HTTP/2-protokollan historiaan ja kuvataan lyhyesti tärkeimmät innovaatiot, jotka erottavat sen HTTP/1.1:stä.

HTTP:stä HTTP/2:een

Hieman historiaa

Ensimmäinen kuvaus HTTP-protokollasta (HyperText Siirtoprotokolla) julkaistiin vuonna 1991. Vuonna 1999 kehitettiin ja kuvattiin HTTP 1.1, joka on edelleen käytössä. Siinä kaukainen aika(melkein 20 vuotta sitten) verkkosivustot eivät olleet sen kaltaisia ​​kuin nyt. Suhteellisesti lyhyt aika Ajan myötä sivustot alkoivat painaa paljon enemmän. Kotisivu Keskimääräinen nykyaikainen verkkosivusto sisältää noin 1,9 Mt tietoa: kuvia, JS:ää, CSS:ää ja paljon muuta.

Määrärajoituksen vuoksi samanaikaisia ​​yhteyksiä HTTP/1.1:ssä suuren määrän "raskasta" sisältöä sisältävien sivujen lataaminen on hidasta. On kaksi tapaa ratkaista tämä ongelma. Ensimmäinen on käyttää erilaisia ​​suorituskyvyn optimointitekniikoita (joista olemme jo kirjoittaneet), ja toinen on yrittää muokata itse HTTP-protokollaa mahdollisten pullonkaulojen poistamiseksi. Tarkastellaanpa tällaisia ​​yrityksiä yksityiskohtaisemmin.

Googlen insinöörit esittelivät ensimmäisen laajan HTTP-uudistusprojektin vuonna 2009. Tämä on SPDY-protokolla, jonka tarkoituksena oli ensisijaisesti nopeuttaa verkkosivustojen ja sovellusten toimintaa muokkaamalla perinteisillä tavoilla pyyntöjen vastaanottaminen ja lähettäminen.

SPDY vaatii sekä palvelinpuolen että asiakaspuolen tuen. Google Developers loi erikoistuneet moduulit Apachelle (mod_spdy) ja Nginxille (ngx_http_spdy_module). Sitä tuetaan lähes kaikissa suosituissa selaimissa.

HTTP/2, joka esiteltiin kuusi vuotta myöhemmin, perustuu suurelta osin SPDY:hen. Työryhmä loi uuden version HTTP:stä Hypertekstin siirto Pöytäkirjan työryhmä. Toukokuussa 2015 HTTP/2-spesifikaatio julkaistiin nimellä RFC 7540.

HTTP/2-protokolla on taaksepäin yhteensopiva HTTP/1.1:n kanssa. Pullonkaulojen poistamiseen ja tuottavuuden parantamiseen tähtäävät muutokset jatkavat pitkälti SPDY-linjaa. Tarkastellaanpa lyhyesti tärkeimpiä niistä.

HTTP/2: tärkeimmät innovaatiot

Multipleksointi

Tämä on ehkä HTTP/2:n tärkein etu. HTTP/1.1 edellyttää erillisen TCP-yhteyden muodostamista jokaista pyyntöä varten. Multipleksoinnin avulla selain voi tehdä useita pyyntöjä yhdessä TCP-yhteydessä:

Nykyaikaisissa selaimissa samanaikaisten TCP-yhteyksien määrä on rajoitettu. Siksi sivut, joilla on paljon staattista sisältöä, eivät lataudu niin nopeasti kuin haluaisimme.

HTTP/2:ssa multipleksoinnin ansiosta staattisia elementtejä ladataan rinnakkain, mikä parantaa merkittävästi suorituskykyä.

Prioriteetit

Toinen HTTP/2:n innovaatio on priorisointi. Jokaiselle pyynnölle voidaan määrittää prioriteetti.
On olemassa kaksi lähestymistapaa prioriteettien määrittämiseen: painoon perustuva ja riippuvuusperusteinen.

Ensimmäisessä lähestymistavassa jokainen lanka saa tietyn painon. Sitten painon perusteella palvelin jakaa kuorman säikeiden kesken. Tätä lähestymistapaa on jo käytetty SPDY-protokollassa.

Toinen menetelmä, joka on HTTP/2:ssa tärkein, on seuraava: selain pyytää palvelinta lataamaan ensin tietyt sisältöelementit. Selain voi esimerkiksi pyytää palvelinta lataamaan ensin CSS-tiedostoja tai JavaScriptiä ja sitten HTML-koodia tai kuvia.

HTTP/2:ssa priorisointi ei ole pakollinen, mutta toivottava menetelmä. Multipleksointi ei kuitenkaan toimi kunnolla ilman sitä. Latausnopeudet voivat olla jopa hitaampia kuin HTTP/1.1. Alemman prioriteetin resurssit vievät kaistanleveyttä, mikä johtaa huonoon suorituskykyyn.

HTTP-otsikon pakkaus

Moderni verkkosivu koostuu monista elementeistä: kuvista, JS:stä, CSS:stä ja muista. Selain lähettää HTTP-otsikon pyynnössä ladata jokainen näistä elementeistä. Lähettäessäsi pyydettyjä elementtejä palvelin lisää niihin myös otsikon. Kaikki tämä liittyy tarpeettomaan resurssien kulutukseen.

HTTP/2:ssa otsikot lähetetään pakatussa muodossa. Tämä vähentää palvelimen ja selaimen välillä vaihdettavan tiedon määrää. HPACK:ia käytetään gzip/deflate-algoritmien sijaan. Tämä vähentää haavoittuvuutta BREACH-hyökkäyksille.

HTTP/2 ja suojaus

Yksi SPDY-protokollan tärkeimmistä vaatimuksista on asiakkaan ja palvelimen välisen yhteyden pakollinen salaus (HTTPS). HTTP/2:ssa se ei ole pakollinen. Selainkehittäjät päättivät kuitenkin ottaa uuden protokollan käyttöön vain TLS(HTTPS)-yhteyksille. Siksi niiden, jotka harkitsevat siirtymistä HTTP/2:een, tulisi ensin vaihtaa HTTPS:ään.

Tätä ei tarvita vain HTTP/2:lle. IN Google-haku käyttö suojattu yhteys on yksi sijoituskriteereistä. Selaimet (katso ja ) merkitsevät pian "haitallisiksi" sivustot, jotka eivät tue https:ää. Lisäämme myös, että monet HTML5-ominaisuudet - esimerkiksi maantieteellinen sijainti - eivät ole käytettävissä ilman suojattua yhteyttä.

HTTP/2-perusasetukset Nginxissä ja Apachessa

Tuodaan lyhyet ohjeet HTTP/2:n käyttöönotosta ja perusmäärityksestä Nginxissä ja Apachessa. Kuten edellä mainittiin, useimmat nykyaikaiset selaimet toimivat HTTP/2:n kanssa vain TLS:n kautta, joten sopivat asetukset on määritettävä verkkopalvelimesi asetuksissa.

Nginx

HTTP/2-tuki on otettu käyttöön vain Nginxin uusimmissa versioissa (1.9.5 ja uudemmat). Jos sinulla on eri versio asennettuna, sinun on päivitettävä se.

Sen jälkeen auki asetustiedosto/etc/nginx/nginx.conf ja etsi seuraava rivi palvelinosiosta:

Kuuntele 443 ssl;

Ja korvaa se seuraavalla:

Kuuntele 443 ssl http2;

Tallenna muutokset ja käynnistä Nginx uudelleen:

$ sudo-palvelu nginx lataa uudelleen

Apache

Apachessa HTTP/2:ta tuetaan vain versioissa 2.4.17 ja uudemmissa. Jos sinulla on enemmän kuin varhainen versio, päivitä ja ota mod_http2-moduuli käyttöön. Lisää sen jälkeen asetustiedostoon seuraavat rivit:

# https-palvelimelle Protokollat ​​h2 http/1.1 # http-palvelimelle Protokollat ​​h2c http/1.1

Tämän jälkeen käynnistä Apache uudelleen. Siinä kaikki - tämä riittää perusasetuksiin.

HTTP/2 ja verkkosivujen optimointi

HTTP/2 on taaksepäin yhteensopiva HTTP/1.1:n kanssa. Siksi sinun ei periaatteessa tarvitse tehdä mitään: palvelusi toiminta ei ole uhattuna.
Mutta kun suositut verkkopalvelimet ja -selaimet siirtyvät HTTP/2:een, huomaat, että sivustosi, joka oli aiemmin optimoitu nopeampaan sivujen latausnopeuteen ja parempaan suorituskykyyn, ei enää toimi niin nopeasti kuin ennen.

Monet HTTP/1.1:ssä onnistuneesti käytetyt optimointimenetelmät eivät toimi HTTP/2:ssa. Joitakin niistä on muutettava, ja joistakin on luovuttava kokonaan. Tarkastellaan tätä asiaa tarkemmin.

Kuvien yhdistäminen Spriteiksi

HTTP/1.1:ssä oli helpompi ladata sellainen iso kuva kuin tehdä paljon pyyntöjä ja ladata paljon pieniä. Tämä johtuu siitä, että pyynnöt ovat jonossa peräkkäin. Yleisin tapa lisätä latausnopeutta oli yhdistää useita pieniä kuvia sprite-tiedostoksi.

Sprite palasi vastauksena yhteen pyyntöön. Vaikka käyttäjä kävisi sivulla, jossa oli vain yksi pieni kuva, koko sprite piti ladata.

HTTP/2:ssa ei ole tällaisia ​​ongelmia sen multipleksoinnin kanssa, mutta spritien käyttö voi olla hyödyllistä tietyissä tilanteissa. Useiden kuvien yhdistäminen spriteen (varsinkin jos kaikki kuvat ovat samalla sivulla) parantaa pakkausta ja vähentää näin kokonaismäärä ladatut tiedot.

Kuvien upottaminen DataURI:lla

Toinen suosittu tapa ratkaisut useiden HTTP-pyyntöjen ongelmaan HTTP/1.1:ssä - kuvien upottaminen data-URI:n avulla. Tämä lisää merkittävästi tyylisivun kokoa.

Jos JS- ja CSS-ketjutusta käytetään samanaikaisesti kuvien upottamisen kanssa optimointia varten, käyttäjän on todennäköisesti ladattava kaikki asiaankuuluva koodi, vaikka hän ei vieraisi näillä kuvilla olevalla sivulla.
HTTP/2:ssa tämä käytäntö pikemminkin huonontaa kuin parantaa suorituskykyä.

JS- ja CSS-ketjutus

Verkkosivustojen suorituskyvyn optimoimiseksi käytetään usein pienten CSS- ja JS-tiedostojen ketjuttamista. Monet pienet tiedostot yhdistetään yhdeksi suureksi tiedostoksi. Tällä tavalla on mahdollista ohittaa HTTP-pyyntöjen lukumäärän rajoitus.

Yhdistämistä käytettäessä voi kuitenkin syntyä sama ongelma kuin spriteillä: vierailemalla sivuston yhdellä sivulla, käyttäjä lataa kaikki sillä käytetyt CSS- ja JS-tiedostot (ja on hyvin todennäköistä, että suurinta osaa näistä tiedostoista ei koskaan tule joita hän käyttää). Voit tietysti valita tiedostot huolellisesti jokaiselle sivuston sivulle, mutta tämä vie liian paljon aikaa.

Toinen ongelma on se, että kaikki ketjutetun tiedoston elementit on tyhjennettävä välimuistista samanaikaisesti. On mahdotonta asettaa yhtä vanhenemispäivää joillekin elementeille ja toinen toisille (jota myös käytetään paljon useammin). Jos muutat edes yhtä riviä CSS:ssä, kaikki elementit vanhenevat kerralla.

Pitäisikö HTTP/2:ssa käyttää ketjutusta? Jos HTTP-pyynnöt eivät vaadi merkittäviä resursseja, voit pärjätä ilman sitä. Monien pienten tyylitiedostojen lataaminen ei ole ongelma. Vanhenemisen tai välimuistin tallentamisen kanssa ei tule ongelmia.

Verkkotunnuksen jakaminen

HTTP/1.1:llä on rajoitus avoimien yhteyksien määrälle. Voit kiertää tämän rajoituksen lataamalla staattisia resursseja saman toimialueen useista aliverkkotunnuksista. Tätä tekniikkaa kutsutaan verkkotunnuksen jakamiseksi; sitä käytetään usein esimerkiksi sivuilla, joilla on paljon kuvia. Tämä auttaa lisäämään latausnopeutta, mutta samalla se aiheuttaa lisäongelmia.

HTTP/2:een siirtymisen myötä verkkotunnuksen jakamisen tarve katoaa. Voit pyytää niin paljon resursseja kuin tarvitset. Lisäksi HTTP/2:n tapauksessa jakaminen ei paranna suorituskykyä, vaan sillä on pikemminkin päinvastainen vaikutus, koska se luo lisää TCP-yhteyksiä ja häiritsee priorisointia.

Milloin vaihtaa?

Milloin sinun pitäisi vaihtaa HTTP/2:een? Tähän kysymykseen ei ole varmaa vastausta eikä voi olla. Annamme kuitenkin yhden vihjeen: tarkista säännöllisesti palvelusi liikennelokit. Kun huomaat, että useimmat kävijät käyttävät selaimia, jotka tukevat HTTP/2:ta, voit siirtyä eteenpäin. Päällä nykyinen hetki HTTP/2-tuki on toteutettu Chromessa (mukaan lukien mobiiliversio Androidille), Firefox, Opera, Edge, Safari.

Kun suunnittelet siirtymääsi, sinun tulee ottaa huomioon myös projektisi erityispiirteet. Jos sinulla on paljon käyttäjiä, jotka tulevat luoksesi mobiililaitteet, tämä tarkoittaa, että sinun tulee vaihtaa HTTP/2:een mahdollisimman pian. Älypuhelimissa ja tableteissa uuden protokollan edut ovat erityisen ilmeisiä. Tässä on kuitenkin otettava huomioon liian monet vivahteet: esimerkiksi monilla maailman alueilla on edelleen paljon käyttäjiä Opera selain Mini, mutta se ei vielä tue HTTP/2:ta.

Jos aiot käynnistää uuden verkkopalvelun, harkitse mahdollisuutta siirtyä HTTP/2:een. Tietenkin joudut käyttämään HTTP/1.1:tä vielä jonkin aikaa, mutta voit nyt tehdä optimointitoimenpiteitä, jotka helpottavat elämääsi tulevaisuudessa.

Hyödyllisiä linkkejä

Lopuksi, tässä on hyödyllisiä linkkejä kiinnostuneille lukijoille. Tämä on asiakirja, joka kuvaa http2:ta teknisestä ja protokollatason näkökulmasta. Se ilmestyi alun perin esityksenä, jonka pidin Tukholmassa huhtikuussa 2014. Olen sittemmin saanut monia kysymyksiä esityksen sisällöstä ihmisiltä, ​​jotka eivät voineet osallistua tapahtumaan, joten päätin muuntaa sen täydelliseksi asiakirjaksi yksityiskohtineen ja asianmukaisine selityksineen.
Kirjoitushetkellä (28. huhtikuuta 2014) lopullista http2-spesifikaatiota ei ole viimeistelty tai julkaistu. Nykyinen versio Luonnoksen nimi on draft-12, mutta odotamme näkevämme ainakin yhden version lisää ennen kuin http2 on valmis. Tässä asiakirjassa kuvataan nykyinen tilanne, joka saattaa muuttua lopullisessa eritelmässä tai ei. Kaikki virheet sisällä tämä asiakirja- omani, joka ilmestyi minun syytäni. Kerro minulle niistä, niin julkaisen korjauksia sisältävän päivityksen.

Tämän asiakirjan versio on 1.2.

Tekijä

Nimeni on Daniel Stenberg ja työskentelen Mozillassa. Avata ohjelmisto ja verkostot, joissa olen ollut mukana yli kaksikymmentä vuotta erilaisissa projekteissa. Minut tunnetaan ehkä parhaiten curlin ja libcurlin pääkehittäjänä. Olin monta vuotta mukana IETF HTTPbis -työryhmässä ja työskentelin molempien parissa HTTP-tuki 1.1, vaatimustenmukaisuuden varmistamiseksi uusimmat vaatimukset ja http2:n standardointityötä.

Sähköposti: [sähköposti suojattu]
Twitter: @bagder
Verkkosivusto: daniel.haxx.se
Blogi: daniel.haxx.se/blog

Auttaa!

Jos löydät tästä asiakirjasta kirjoitusvirheitä, puutteita, virheitä tai suoranaisia ​​valheita, lähetä minulle korjattu versio kappaleesta, niin julkaisen korjatun version. Kiitän kaikkia, jotka auttoivat! Toivon, että ajan myötä pystyn parantamaan tekstiä.

Lisenssi

Tämä asiakirja on lisensoitu Creative Commons Attribution 4.0 -lisenssillä: creativecommons.org/licenses/by/4.0

HTTP tänään

HTTP 1.1:stä on tullut protokolla, jota käytetään todella kaikkeen Internetissä. Valtavia investointeja on tehty protokolliin ja infrastruktuuriin, jotka nyt hyödyntävät sitä. Se on päässyt siihen pisteeseen, että nykyään on usein helpompi ajaa jotain HTTP:n päällä kuin rakentaa jotain uutta tilalle.

HTTP 1.1 on valtava

Kun HTTP luotiin ja julkaistiin maailmalle, se luultavasti pidettiin enemmän yksinkertaisena ja suoraviivaisena protokollana, mutta aika on osoittanut, että näin ei ole. HTTP 1.0 RFC 1945:ssä on 60-sivuinen spesifikaatio, joka julkaistiin vuonna 1996. HTTP 1.1:tä kuvaava RFC 2616 julkaistiin vasta kolme vuotta myöhemmin vuonna 1999, ja se on kasvanut merkittävästi 176 sivuun. Lisäksi, kun me IETF:ssä työskentelimme päivittääksemme eritelmiä, se jaettiin kuusi asiakirjoja, joissa on lopulta enemmän sivuja. Epäilemättä HTTP 1.1 on suuri ja sisältää lukemattomia yksityiskohtia, hienouksia ja ei vähiten valinnaisia ​​osia.

Vaihtoehtojen maailma

HTTP 1.1:n luonne, jossa on monia pieniä yksityiskohtia ja vaihtoehtoja myöhempään muokkaukseen, on kasvattanut ohjelmistoekosysteemin, jossa ei ole yhtä toteutusta, joka tekee kaiken - ja itse asiassa on mahdotonta sanoa tarkalleen, mitä se on ". Tämä johti tilanteeseen, jossa alun perin vähän käytettyjä ominaisuuksia esiintyi vain harvoissa toteutuksissa, ja niitä ottaneet havaitsivat myöhemmin niiden vähäisen käytön.
Tämä aiheutti myöhemmin yhteensopivuusongelmia, kun asiakkaat ja palvelimet alkoivat käyttää näitä ominaisuuksia aktiivisemmin. HTTP liukuhihna ( HTTP-liukuhihna) on yksi valaisevista esimerkeistä tällaisista mahdollisuuksista.

TCP:n väärä käyttö

HTTP 1.1 on kulkenut pitkän tien hyödyntääkseen todella TCP:n tarjoamaa tehoa ja suorituskykyä. HTTP-asiakkaiden ja -selaimien on oltava todella luovia löytääkseen tapoja parantaa sivujen latausaikoja.

Muut rinnakkain vuosien varrella tehdyt kokeet ovat myös vahvistaneet, että TCP ei ole niin helppo korvata, joten jatkamme työtä sekä TCP:n että sen päällä toimivien protokollien parantamiseksi.

TCP:tä voidaan helposti käyttää täysimääräisesti, jotta vältetään taukoja tai aikajaksoja, joita olisi voitu käyttää lähettämiseen tai vastaanottamiseen lisää tiedot. Seuraavissa luvuissa korostetaan joitain näistä käytön haitoista.

Siirron koko ja määrä esineitä

Kun tarkastelet joidenkin nykypäivän suosituimpien sivustojen trendejä ja vertailet, kuinka kauan niiden kotisivun lataaminen kestää, trendit tulevat ilmeisiksi. Muutaman viime vuoden aikana siirrettävän tiedon määrä on noussut vähitellen 1,5 megatavuun ja yli, mutta meille tässä yhteydessä tärkeintä on kohteiden määrä, joka on nyt keskimäärin lähes sata. Koko sivun näyttämiseksi on ladattava sata objektia.

Kuten kaaviosta näkyy, trendi oli kasvava, mutta myöhemmin ei ole merkkejä sen muuttumisesta edelleen.

Viive tappaa

HTTP 1.1 on erittäin herkkä latenssille, osittain siksi, että HTTP-putkistolla on edelleen ongelmia ja se on poistettu käytöstä suurimmalta osalta käyttäjistä.

Vaikka olemme kaikki nähneet käyttäjien kaistanleveyden merkittävää kasvua viime vuosina, emme ole nähneet vastaavanlaista latenssin vähenemistä. Korkean latenssin kanavat, kuten monet modernit mobiiliteknologiat, vähentää merkittävästi hyvän ja nopean verkkonavigoinnin tunnetta, vaikka sinulla olisi todella nopea yhteys.

Toinen esimerkki, jossa alhaista latenssia todella vaaditaan, on joissakin videotyypeissä, kuten videoneuvotteluissa, peleissä ja vastaavissa, joissa on lähetettävä muutakin kuin pelkkä valmiiksi luotu stream.

Jonon alun estäminen

Kuljetin HTTP-siirto– Tämä on tapa lähettää seuraava pyyntö odottamalla jo vastausta edelliseen pyyntöön. Se on kuin jonottaisi kassalle supermarketissa tai pankissa. Et tiedä millaisia ​​ihmisiä edessäsi on: nopeat asiakkaat tai ärsyttäviä ihmisiä, jotka vievät loputtomasti aikaa palvelun suorittamiseen - estävät jonon alun.

Voit toki valita jonon huolellisesti ja lopulta valita oikean jonon, ja joskus voit luoda oman jonon, mutta lopulta et voi välttää päätöksen tekemistä ja kun valitset jonon, et voi. muuta sitä.

Uuden jonon luominen maksaa suorituskykyä ja resursseja, eikä sitä voi skaalata pidemmälle pieni määrä jonoja. Täydellistä ratkaisua tähän ongelmaan ei ole.

Vielä tänäkin päivänä, vuonna 2014, useimmat pöytätietokoneiden verkkoselaimet toimitetaan siten, että HTTP-putkisto on oletuksena poistettu käytöstä.

Lisätietoja tästä ongelmasta löytyy Firefoxin ongelmanseurantaohjelmasta osoitteessa .

Toimenpiteet viivästymisen voittamiseksi

Kuten aina, kun ihmiset kohtaavat vikoja, he kokoontuvat yhteen löytääkseen ratkaisuja. Jotkut kiertotavat ovat fiksuja ja hyödyllisiä, jotkut ovat vain kauheita kainalosauvoja.

Spritejen luominen

Spritemaking on termi, jota käytetään usein kuvaamaan useiden pienten kuvien yhdistämistä yhdeksi suureksi. Käytä sitten javascriptiä tai CSS:ää suuren kuvan osien "leikkaamiseen" pienempien kuvien näyttämiseksi.

Sivusto käyttää tätä temppua nopeuttaakseen asioita. Hanki yksi iso pyyntö huomattavasti nopeampi HTTP 1.1:ssä kuin sadan yksittäisen pienen kuvan hakeminen.

Tietysti tällä on haittapuolensa niille sivuston sivuille, jotka vaativat vain yhden tai kaksi pientä kuvaa. Tämä myös heittää pois kaikki kuvat välimuistista kerralla sen sijaan, että säilytettäisiin joitain eniten käytetyistä.

Upottaminen

Upottaminen on toinen temppu lähettämisen välttämiseksi yksittäisiä kuvia, sen sijaan data on CSS-tiedostoon upotettu URL-osoite. Tällä on samat edut ja haitat kuin spriteillä.

Icon1 ( tausta: url(data:image/png;base64, ) ei toistoa; ) .icon2 ( tausta: url(data:image/png;base64, ) ei toistoa; )

yhdistys

Aivan kuten kahdessa edellisessä tapauksessa, nykyään suurilla sivustoilla voi olla monia JavaScript-tiedostoja. Kehittäjien apuohjelmien avulla voit yhdistää kaikki nämä tiedostot yhdeksi valtavaksi palaksi niin, että selain vastaanottaa yhden tiedoston useiden pienten sijaan. Suuri määrä dataa lähetetään, kun vain pieni fragmentti todella tarvitaan. Tarpeettoman suuri määrä dataa on ladattava uudelleen, kun muutoksia on tehtävä.

Kehittäjien ärsyttäminen ja pakottaminen noudattamaan näitä vaatimuksia on tietysti "vain" tuskaa mukana oleville ihmisille, eikä se näy suorituskaavioissa.

Jakaminen

Viimeinen temppu, jonka mainitsen, että sivustojen omistajat käyttävät parantaakseen latausaikoja selaimissa, kutsutaan usein "sharkingiksi". Tämä tarkoittaa periaatteessa palvelun hajauttamista mahdollisimman monelle eri isännälle. Ensi silmäyksellä tämä kuulostaa hullulta, mutta siihen on yksinkertainen syy!

HTTP salli alun perin asiakkaan käyttää enintään kahta TCP-yhteyttä isäntä kohden. Jotta vältytään rikkomasta määritelmiä, edistyneet sivustot keksivät vain uusia isäntänimiä ja voila, voit saada suurempi määrä yhteyksiä verkkosivustollesi ja lyhentää sivun latausaikaa.

Ajan myötä tämä rajoitus poistettiin spesifikaatiosta, ja nykyään asiakkaat käyttävät 6-8 yhteyttä isäntä kohden, mutta ne ovat edelleen rajallisia, joten sivustot jatkavat tekniikkaa, jolla lisätään yhteyksien määrää. Kun esineiden määrä kasvaa, kuten aiemmin osoitin, suuri määrä yhteyksiä alettiin käyttää yksinkertaisesti sen varmistamiseksi, että HTTP toimii hyvin ja tekee sivustosta nopeamman. Ei ole epätavallista, että sivustot käyttävät tätä tekniikkaa käyttämällä yli 50 tai jopa 100 yhteyttä.

Toinen syy jakamiseen on kuvien ja vastaavien resurssien isännöinti erillisillä isännillä, jotka eivät käytä evästeitä, koska evästeet voivat nykyään olla melko suuria. Käyttämällä evästettömiä kuvaisäntiä voit parantaa suorituskykyä tekemällä huomattavasti vähemmän HTTP-pyyntöjä!

Alla oleva kuva näyttää, miltä pakettitallennus näyttää, kun selaat yhtä ruotsalaista huippusivustoa ja kuinka pyynnöt jakautuvat useiden isäntien kesken.

HTTP-päivitys

Eikö olisi parempi tehdä parannettu protokolla? Joka sisältäisi seuraavat...

1. Luo protokolla, joka olisi vähemmän herkkä RTT:lle
2. Korjaa liukuhihna- ja jonon pään esto-ongelma
3. Lopeta tarve ja halu saada lisää yhteyksiä jokaiseen isäntään
4. Säilytä olemassa olevat rajapinnat, kaikki sisältö, URI-muoto ja mallit
5. Tee se sisällä työryhmä IETF HTTPbis

IETF- ja HTTPbis-työryhmä

Internet Engineering Task Force (IETF) on organisaatio, joka kehittää ja edistää Internet-standardeja. Lähinnä protokollatasolla. He ovat tunnettuja RFC-sarjoistaan, jotka dokumentoivat kaikkea TCP:stä, DNS:stä, FTP:hen parhaita käytäntöjä, HTTP ja monet protokollamuunnelmat, joita ei ole käytetty missään.

IETF:ssä on omistettuja "työryhmiä", jotka muodostetaan pienen tehtäväjoukon ympärille tavoitteen saavuttamiseksi. Ne luovat "peruskirjan" joukosta periaatteita ja rajoituksia tietyn tavoitteen saavuttamiseksi. Kuka tahansa voi osallistua keskusteluun ja kehitykseen. Jokaisella, joka osallistuu ja ilmaisee jotain, on yhtäläiset mahdollisuudet ja mahdollisuudet vaikuttaa tulokseen ja jokainen otetaan huomioon ihmisenä ja yksilönä riippumatta siitä, missä yrityksessä henkilö työskentelee.

HTTPbis-työryhmä perustettiin kesällä 2007, ja sen tehtävänä oli päivittää HTTP 1.1 -spesifikaatio - tästä syystä "bis"-liite. Ryhmäkeskustelu uusi versio HTTP-protokolla todella alkoi vuoden 2012 lopussa. HTTP 1.1 -päivityksen työ valmistui vuoden 2014 alussa.

HTTPbis-työryhmän viimeinen kokous ennen odotettua http2-määrityksen lopullista julkaisua pidetään New Yorkissa kesäkuun 2014 alussa.

Muutama iso HTTP-alan toimija puuttui työryhmän keskusteluista ja kokouksista. En halua nimetä tässä mitään tiettyä yritystä tai tuotteen nimeä, mutta on selvää, että jotkut Internet-toimijat näyttävät nykyään luottavan siihen, että IETF pärjää hyvin ilman näitä yrityksiä...

Suffiksi "bis"

Ryhmän nimi on HTTPbis, jossa pääte "bis" tulee latinalaisesta adverbistä, joka tarkoittaa "kaksi". Bis käytetään usein päätteenä tai osana nimeä IETF:ssä päivityksessä tai toisella spesifikaatioyrityksellä. Sama kuin HTTP 1.1:n tapauksessa.

Tunnisteet: Lisää tunnisteita

HTTP 1.1 -protokolla palveli uskollisesti lähes 20 vuotta, joten synty uusi spesifikaatio se oli vain ajan kysymys. Se korvattiin HTTP/2:lla, joka otettiin virallisesti käyttöön viime vuonna ja perustuu Googlen kehittämään SPDY-protokollaan.

Jos epäilet edelleen, kannattaako nyt vaihtaa HTTP/2:een, vastaus on: kyllä, se kannattaa. Ensinnäkin kaikki suosittujen web-palvelimien uudet versiot tukevat jo protokollaa.

Jos haluat ottaa sen käyttöön Nginxissä (versio 1.9.5 tai uudempi), sinun on lisättävä kuunteluohje asetustiedostoon (palvelinosio):

Palvelin (kuuntele 443 ssl http2; palvelimen_nimi esimerkki.fi; ssl_sertifikaattipalvelin.crt; ssl_sertifikaatin_avain palvelin.avain; )

# Nginx tukee HTTP/2:ta vain, kun se on yhdistetty TLS:n kanssa

No, Apachessa (alkaen versiosta 2.4.17 ja uudemmista) sinun on lisättävä seuraavat asetukset määritystiedostoon:

# https-palvelimelle Protokollat ​​h2 http/1.1 # http-palvelimelle Protokollat ​​h2c http/1.1

# HTTP/2-tuki suojatuille ja suojaamattomille yhteyksille

Toiseksi kaikki suosituimpien selainten uudet versiot tukevat myös HTTP/2:ta.

Ja kolmanneksi, uusi määritys on paljon nopeampi ja tuottavampi kuin HTTP 1.1. Lisäksi W3Techsin mukaan yli 7,1 % verkkosivustoista tukee jo HTTP/2:ta.

Tärkeimmät erot HTTP/2:n ja HTTP 1.1:n välillä

Protokollien välillä on vain muutamia keskeisiä eroja.

Binääri

Toisin kuin teksti HTTP 1.1, HTTP/2 on binaarinen. Siksi protokolla on tehokkaampi jäsentämisen aikana, kompaktimpi lähetyksen aikana ja altis vähemmän virheille.

Multipleksointi

HTTP 1.1:ssä selaimet käyttävät useita yhteyksiä palvelimeen ladatakseen verkkosivun, ja tällaisten yhteyksien määrä on rajoitettu. Mutta tämä ei ratkaise ongelmaa, jossa kanava on estetty hitaiden pakettien takia. Kun taas HTTP/2 käyttää multipleksointia, mikä sallii selaimen käyttää sellaista TCP-yhteys kaikkiin pyyntöihin.

Kaikki tiedostot ladataan rinnakkain. Pyynnöt ja vastaukset on erotettu kehyksiin, joissa on metadataa, joka yhdistää pyynnöt ja vastaukset. Joten ne eivät mene päällekkäin ja aiheuta sekaannusta. Tässä tapauksessa vastaukset vastaanotetaan heti, kun ne ovat valmiita, joten raskaat pyynnöt eivät estä yksinkertaisempien kohteiden käsittelyä ja toimittamista.

Priorisointi

Multipleksoinnin mukana tuli liikenteen priorisointi. Pyynnöt voidaan priorisoida tärkeyden ja riippuvuuden perusteella.

Joten kun verkkosivua ladataan, selain vastaanottaa ensin tärkeät tiedot, kuten esimerkiksi CSS-koodin, ja kaikki merkityksetön käsitellään viimeisenä.

HPACK-otsikon pakkaus

HTTP-protokolla on suunniteltu siten, että pyyntöjä lähetettäessä otsikot, jotka sisältävät lisätietoja. Palvelin puolestaan ​​liittää vastauksiin myös otsikot. Ja koska verkkosivut koostuvat monista tiedostoista, kaikki otsikot voivat viedä kohtuullisen määrän tilaa. Siksi HTTP/2 sisältää otsikkopakkauksen, joka vähentää merkittävästi aputietojen määrää, jotta selain voi lähettää kaikki pyynnöt kerralla.

Server Push

HTTP 1.1 -protokollaa käytettäessä selain pyytää sivua, palvelin vastaa HTML:llä ja odottaa, että selain käsittelee sen ja pyytää kaikki tarvittavat tiedostot: JavaScript, CSS ja valokuvat. Siksi uusi protokolla otettiin käyttöön mielenkiintoinen ominaisuus nimeltä Server Push.

Sen avulla palvelin voi välittömästi, odottamatta vastausta verkkoselaimelta, lisätä välimuistiin tarvitsemansa tiedostot nopeaa toimitusta varten.

Salaus

HTTP/2-protokolla ei vaadi kanavan salausta. Kuitenkin kaikki nykyaikaiset selaimet toimivat HTTP/2:n kanssa vain yhdessä TLS:n kanssa, kuten Nginx. Protokollan laajamittaisen käyttöönoton pitäisi siis edistää salauksen leviämistä Internetissä.

Siksi, jos käytät jo TLS:ää, kannattaa käyttää HTTP/2:ta, joka avaa salauksen täyden potentiaalin. Salattua yhteyttä luotaessa tapahtuu vain yksi TLS-kättely, mikä yksinkertaistaa huomattavasti koko prosessia ja lyhentää yhteysaikaa.

HTTP/2-optimointi

HTTP/2:n suuri optimointi verrattuna HTTP 1.1:een – useiden optimointien poistaminen käytöstä tai muuttaminen edellinen versio protokollaa.

• Verkkotunnuksen jakamisesta kannattaa luopua. Tämä menetelmä useiden tiedostojen jakamiseen eri verkkotunnuksia ja CDN on relevantti HTTP 1.1:lle, koska se ratkaisee ongelman rinnakkaisliitännät. Mutta uuden protokollan tapauksessa tällainen ratkaisu heikentää suorituskykyä ja eliminoi liikenteen priorisoinnin.
• Jos mahdollista, hävitä tai muokkaa spritejä. Useiden pienten kuvien yhdistäminen yhdeksi suureksi kuvaksi voi parantaa sivun latausnopeutta, mutta jos käyttäjä vieraili verkkosivulla, jossa oli yksi pieni kuva, koko sprite lähetettiin silti hänelle. HTTP/2:n tapauksessa tämä ratkaisu on vähemmän hyödyllinen multipleksoinnin myötä.
• Toinen tapa optimoida kuvia on upottaminen DataURI:n avulla. Se voi olla hyödyllinen myös HTTP/2:ssa, mutta se on varmasti vähemmän tehokas kuin edellisen version tapauksessa.
• On parempi välttää tiedostojen yhdistämistä (ketjuttamista). Menetelmä on samanlainen kuin sprite - kaikki tarvittavat tiedostot, CSS ja JavaScript, yhdistetään yhdeksi suureksi siirtoa varten yhdessä streamissa yhden yhteyden kautta. Joten jos käyttäjä tulee sivulle yhdellä pienellä JS-koodilla, hänelle lähetettäisiin silti koko yhdistetty tiedosto. Toinen monimutkaisuus on, että kaikki yhdistetyt tiedostot on purettava välimuistista samanaikaisesti, ja yksi koodimuutos minkä tahansa niistä edellyttää koko sarjan päivittämistä. Joten saman multipleksoinnin ansiosta tämä lähestymistapa ei ole järkevä.
• Sinun tulee myös välttää tiedostojen upottamista HTML-koodiin.

Tärkein

HTTP/2-protokollaa on jo merkittävästi optimoitu verrattuna HTTP 1.1:een, joten pelkkä uuden määrityksen käyttöönotto voi parantaa verkkopalveluiden suorituskykyä. Ja poistamalla käytöstä muita temppuja, joita käytettiin HTTP 1.1:n nopeuttamiseen, voit hyödyntää HTTP/2:ta täysimääräisesti.