Hypertekstinsiirtoprotokolla on kehittynyt dramaattisesti perustamisestaan lähtien, ja HTTP/2 on yksi merkittävimmistä harppauksista siinä, miten siirrämme tietoja WWW:ssä. Jos olet huomannut verkkosivujen latautuvan nopeammin viime vuosina, HTTP/2 toimii todennäköisesti kulissien takana.
Tässä oppaassa kerrotaan kaikki, mitä sinun on tiedettävä HTTP/2:sta –sen keskeisistä mekanismeista ja suorituskykyeduista käytännön käyttöönottovaiheisiin. Oletpa sitten kehittäjä, joka haluaa optimoida verkkopalvelimensa tai vain utelias siitä, mikä saa nykyaikaiset verkkosivustot toimimaan, löydät täältä toimivia tietoja.
Nopea vastaus: HTTP/2 ja miksi sillä on merkitystä
HTTP/2 on merkittävä muutos hypertekstinsiirtoprotokollan versioon 1.1, jonka Internet Engineering Task Force on standardoinut RFC 7540:ssä (toukokuu 2015). Siinä keskitytään viiveen vähentämiseen, verkon resurssien käytön parantamiseen ja verkkosivujen latautumisen nopeuttamiseen – jasamalla säilytetään täysi yhteensopivuus nykyisten HTTP-semantiikoiden kanssa.
Vuonna 2026 HTTP/2 on lähes kaikkialla käytössä. W3Techsin tietojen mukaan yli 1/3 suosituimmista verkkosivustoista käyttää aktiivisesti HTTP/2:ta, ja useimmat suuret CDN:t (Cloudflare, AWS CloudFront, Fastly) ottavat sen oletusarvoisesti käyttöön HTTPS-liikenteessä. Jos sivustosi toimii HTTPS:ssä nykyaikaisella verkkopalvelimella, hyödyt todennäköisesti jo HTTP/2:sta ilman lisäkonfigurointia.
Protokolla esittelee useita uusia ominaisuuksia, jotka korjaavat HTTP 1.1:n suorituskyvyn pullonkauloja:
- Multipleksointi: Useat tietovirrat kulkevat yhtä TCP-yhteyttä pitkin samanaikaisesti.
- Otsikon pakkaaminen (HPACK): Otetaan käyttöön otsikkokenttien pakkaus, joka vähentää huomattavasti turhaa HTTP-otsikon metatietoa.
- Binäärinen kehyskerros: Täysin yleinen kehyskerros, joka korvaa tekstipohjaiset komennot tehokkaalla binääriviestien kehystyksellä.
- Palvelimen työntäminen: Resurssien ennakoiva toimittaminen ennen kuin selain pyytää niitä nimenomaisesti
- Virran priorisointi: Asiakkaan vihjeet, jotka kertovat palvelimille, mitkä resurssit ovat tärkeimpiä.
Tämä tarkoittaa käytännössä seuraavaa:
- Nopeampi sivulataus, erityisesti resursseja vaativilla sivustoilla.
- Alkuperää kohti tarvitaan vähemmän TCP-yhteyksiä
- Parempi suorituskyky matkaviestinverkoissa, joissa on suuri viive
- Parempi verkon käyttöaste kautta linjan
HTTP/0.9:stä HTTP/2:een: Lyhyt historiikki
HTTP-protokolla on kulkenut pitkän matkan sen jälkeen, kun Tim Berners-Lee esitteli HTTP/0.9-protokollan vuonna 1991 yksinkertaisena mekanismina HTML-dokumenttien hakemiseen. Vuonna 1996 seurasi HTTP/1.0, johon lisättiin otsikot ja tilakoodit, ja HTTP/1.1 standardoitiin RFC 2068:ssa (1997) ja myöhemmin tarkennettiin RFC 2616:ssa (1999). Lähes kahden vuosikymmenen ajan HTTP/1.1 oli asiakas-palvelin-viestinnän selkäranka verkossa.
Mutta verkko muuttui dramaattisesti. Nykyaikaiset verkkosivut muuttuivat yksinkertaisista dokumenteista monimutkaisiksi sovelluksiksi, jotka lataavat kymmeniä JavaScript-nippuja, CSS-tiedostoja, kuvia ja API-kutsuja. Jopa laajakaistayhteyksillä ja tehokkailla laitteistoilla HTTP/1.1:n arkkitehtuuri aiheutti pullonkauloja:
- Linjan pään estäminen: Kukin TCP-yhteys pystyi käsittelemään vain yhden pyynnön kerrallaan, mikä aiheutti tarpeetonta verkkoliikennettä resurssien jonoutuessa.
- Yhteyden yleiskustannukset: Työpöytä- ja mobiiliselaimet avaavat yleensä 6-8 rinnakkaista TCP-yhteyttä per alkuperä tämän rajoituksen kiertämiseksi.
- Ylimääräiset otsikot: Jokainen HTTP-pyyntö lähetti toistuvasti samat sanalliset otsikot (evästeet, user-agent, accept-otsikot).
Google tunnisti nämä ongelmat ja käynnisti SPDY-projektin vuonna 2009. SPDY toteutettiin ensimmäisen kerran Chromessa noin vuonna 2010, ja siinä otettiin käyttöön useita uudistuksia:
- Binäärinen kehystys tekstipohjaisten protokollien sijasta
- Useiden pyyntöjen multipleksointi yhden yhteyden kautta
- Otsikon pakkaaminen yleiskustannusten vähentämiseksi
- Kriittisten resurssien priorisointi
IETF:n HTTP-työryhmä näki SPDY:n potentiaalin ja hyväksyi sen HTTP/2:n lähtökohdaksi vuonna 2012. ietf http -työryhmän laajan työn jälkeen RFC 7540 (HTTP/2) ja RFC 7541 (HPACK) julkaistiin toukokuussa 2015.
Selainten käyttöönotto eteni nopeasti:
- Chrome poisti SPDY:n käytöstä HTTP/2:n hyväksi Chrome 51:stä alkaen (toukokuu 2016).
- Firefox lisäsi HTTP/2-tuen versiossa 36 (helmikuu 2015).
- Safari seurasi versiossa 9 (syyskuu 2015)
- Microsoft Edge toimitettiin HTTP/2-tuella alkuperäisestä julkaisustaan lähtien.
- Jopa Internet Explorer 11 sai HTTP/2-tuen Windows 8.1:ssä ja uudemmissa versioissa.
Suunnittelun tavoitteet ja tärkeimmät erot HTTP/1.1:een verrattuna
HTTP/2 säilyttää täyden yhteensopivuuden HTTP/1.1-semantiikan kanssa. Menetelmät, kuten GET ja POST, toimivat identtisesti. Tilakoodit pysyvät ennallaan. URI:t ja HTTP-otsikkokentät noudattavat samoja sääntöjä. Muuttuu vain se, miten tiedot liikkuvat johtojen välityksellä – siirtokerroksen mekaniikka, joka määrittää todellisen kuormitusnopeuden.
Protokollan suunnittelun tavoitteet olivat selkeät:
| Tavoite | Miten HTTP/2 saavuttaa sen |
|---|---|
| Vähennä latenssia | Multipleksointi eliminoi HTTP-tason linjan pään eston. |
| Parempi yhteyden käyttö | Yksi TCP-yhteys käsittelee kaikki alkuperäiseen osoitteeseen osoitetut pyynnöt. |
| Leikkaa otsikon yläpuolelta | HPACK-pakkaus pienentää aiemmin siirrettyjä otsikkoarvoja. |
| Mobiilin suorituskyvyn parantaminen | Vähemmän yhteyksiä ja pienemmät otsikot hyödyttävät korkean viiveen verkkoja. |
Tämän rakenteen kauneus on sovellustasolla taaksepäin yhteensopivuus. Olemassa olevaa verkkosovelluskoodia – reitityksiä, käsittelijöitä ja vastauslogiikkaa – ei tarvitse muuttaa. Ainoastaan asiakas- ja palvelinpinon on tuettava HTTP/2:tä, jotta siitä olisi hyötyä.
Tämä on jyrkässä ristiriidassa HTTP/1.1:n kiertotapojen kanssa, jotka kehittäjien oli toteutettava manuaalisesti:
- Toimialueen jakaminen: Varojen jakaminen useille verkkotunnuksille useampien yhteyksien avaamiseksi.
- Omaisuuserien ketjuttaminen: CSS- ja JavaScript-tiedostojen niputtaminen pyyntöjen vähentämiseksi
- Kuvaspritejä: Useiden kuvien yhdistäminen yhdeksi tiedostoksi
- Sisäverhoilu: CSS:n ja JavaScriptin upottaminen suoraan HTML:ään
HTTP/2:n ydinmekaniikka, joka korvaa nämä hakkeroinnit:
- Binäärinen kehyskerros: Kehyksiin jaetut viestit kuljettavat dataa tehokkaasti binäärisinä protokollayksikköinä.
- Multipleksoidut virrat: Useita samanaikaisia vaihtoja tapahtuu saman yhteyden kautta.
- HPACK-otsikon pakkaaminen: Dynaamiset taulukot seuraavat otsikoita, mikä eliminoi redundanssin.
- Palvelimen työntäminen: Palvelimet lähettävät ennakoivasti asiakkaan tarvitsemia resursseja.
- Virran priorisointi: Asiakkaat ilmoittavat, mitkä resurssit ovat tärkeimpiä virran riippuvuuspainotusten avulla.
Binäärikehystys, virrat, viestit ja multipleksointi
HTTP/2:n ytimessä on binäärinen kehyskerros, joka on perustavanlaatuinen ero HTTP/1.1:n tekstipohjaiseen muotoon. Jokainen HTTP-viesti jaetaan binäärikehyksiin, joiden rakenne on johdonmukainen: 9 tavun kehysotsikko, joka sisältää pituuden, tyypin, liput ja virran tunnisteet, ja sen jälkeen valinnaiset hyötykuorman tiedot.
Hierarkian ymmärtäminen edellyttää kolmen käsitteen ymmärtämistä:
Virrat ovat itsenäisiä, kaksisuuntaisia kanavia yhden yhteyden sisällä. Jokaisella streamilla on yksilöllinen 31-bittinen tunniste. Asiakkaat käynnistävät streameja parittomilla tunnuksilla (1, 3, 5…), kun taas palvelimet käyttävät parillisia tunnuksia (2, 4, 6…) palvelimen käynnistämiin streameihin, kuten push. Odottamaton virran tunniste aiheuttaa virheen. Samanaikaisten virtojen enimmäismäärä -asetus ohjaa, kuinka moni voi olla aktiivinen samanaikaisesti.
Viestit edustavat täydellisiä HTTP-pyyntöjä tai -vastauksia. Täydellinen otsikkolohko koostuu yhdestä tai useammasta kehyksestä, ja vastaukset voivat sisältää useita datakehyksiä. Kun vastaanottaja kohtaa otsikkolohkon palasia, se kokoaa ne uudelleen koko viestin muodostamiseksi.
Kehykset ovat langan pienimmät yksiköt. Yleisiä kehys- ja virhetyyppejä ovat mm:
- DATA-kehykset: Kuljettavat pyynnön/vastauksen rungon sisällön
- HEADERS-kehys: Sisältää HTTP-otsikkokenttiä, jotka on mahdollisesti jaettu useisiin kehyksiin, joita kutsutaan otsikkolohkofragmenteiksi.
- ASETUKSET: Yhteyden ohjausviestit konfigurointia varten
- WINDOW_UPDATE: Virtauksenvalvontaikkunan säädöt
- PUSH_PROMISE: Ilmoittaa palvelimen työntöstä
- RST_STREAM: Lopettaa virran virhekoodilla
- VOITTAJAISET: Käynnistää yhteyden sulkeutumisen
Taika tapahtuu multipleksoinnin avulla. Koska useiden samanaikaisesti avoinna olevien virtojen kehykset voidaan lomittaa yhden TCP-yhteyden kautta – ja kumpikin päätepiste lomittaa kehykset tarpeen mukaan – ei ole odotusta. Vastaanottaja kokoaa kehykset uudelleen virran tunnisteen mukaan.
Ajattele tyypillisen verkkosivun lataamista, joka tarvitsee:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- sankarikuva.jpg (200 KB)
HTTP/1.1:ssä selaimesi avaa useita yhteyksiä noutaakseen nämä tiedot rinnakkain, mikä aiheuttaa edelleen rajoituksia. HTTP/2:n avulla kaikki viisi resurssia lähetetään samanaikaisesti yhden yhteyden kautta useina tietovirtoina. Eri tietovirtojen datakehykset lomittuvat toisiinsa, ja sekä asiakas että palvelin hallitsevat koko yhteyttä tehokkaasti.
Tämä poistaa useiden TCP-yhteyksien tarpeen, mikä vähentää yhteyden virtauksenvalvontaikkunan yleiskustannuksia ja parantaa huomattavasti verkon suorituskykyä.
Otsikon pakkaaminen HPACK:n avulla
HPACK, joka on määritelty RFC 7541:ssä (joka julkaistiin HTTP/2:n ohella toukokuussa 2015), tarjoaa otsikkopakkauksen, joka on suunniteltu erityisesti HTTP/2:lle. Tämä on tärkeää, koska HTTP/1.1-otsikot olivat laajoja ja täysin pakkaamattomia, mikä aiheutti tarpeetonta verkkoliikennettä jokaisen pyynnön yhteydessä.
Tarkastellaan tyypillisen HTTP-pyynnön otsikoita:
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...Nämä otsikot ylittävät usein 700-800 tavua per pyyntö. Evästeiden kanssa ne voivat kasvaa useisiin kilotavuihin. Kun tämä kerrotaan kymmenillä pyynnöillä sivua kohti, tuhlaat huomattavaa kaistanleveyttä, mikä on erityisen tuskallista mobiiliverkoissa.
HPACK pakkaa otsikot kolmen mekanismin avulla:
- Staattinen taulukko: 61 ennalta määriteltyä yleistä otsikkokentän/arvoparia (kuten :method: GET tai :status: 200), joita ei tarvitse koskaan lähettää.
- Dynaaminen taulukko: Yhteyskohtainen taulukko, jonka asiakas ja palvelin rakentavat yhdessä ja johon tallennetaan aiemmin siirrettyjä otsikkoarvoja uudelleenkäyttöä varten.
- Huffman-koodaus: Merkkijonoarvot koodataan käyttämällä ennalta määriteltyä Huffman-taulukkoa, joka kutistaa tekstin esityksiä.
Tulos on dramaattinen. Kun ensimmäinen pyyntö luo yhteiset otsikot dynaamiseen taulukkoon, seuraavat pyynnöt saattavat lähettää vain indeksiviittauksia. Otsikot, jotka aluksi olivat kilotavuja, kutistuvat kymmeniin tavuihin.
HPACK suunniteltiin erityisesti välttämään CRIMEn ja BREACHin kaltaisia tietoturva-aukkoja, jotka vaikuttivat aiempiin pakkausjärjestelmiin, kuten SPDY:n DEFLATEen. Käyttämällä staattisia Huffman-koodeja ja huolellista taulukkohallintaa HPACK estää hyökkääjiä käyttämästä pakkaussuhdeanalyysiä salaisuuksien poimimiseen hyökkääjän ja uhrin sekoitetuista tiedoista.
On syytä huomata, että HPACK toimii vain HTTP-otsakkeilla. Vastausrungot käyttävät edelleen tavallisia sisällön koodausmekanismeja, kuten gzip- tai Brotli-menetelmiä HTTP-kerroksessa, täysin erillään otsikkopakkauksesta.
Palvelimen työntö ja virran priorisointi
HTTP/2 ottaa käyttöön kaksi optimointiominaisuutta, joiden tarkoituksena on korvata HTTP/1.1:n kiertotiet: palvelimen työntövoima resurssien ennakoivaa toimitusta varten ja virran priorisointi resurssien älykästä järjestämistä varten.
Palvelimen työntö
Server push mahdollistaa sen, että verkkopalvelin voi lähettää resursseja asiakkaalle ennen kuin niitä on erikseen pyydetty. Mekanismi toimii PUSH_PROMISE-kehysten avulla:
- Asiakas pyytää /index.html
- Palvelin vastaa HTML:llä, mutta lähettää myös PUSH_PROMISE-kehykset, joissa ilmoitetaan, että se työntää /styles.css ja /app.js-tiedostot
- Palvelin lähettää nämä resurssit uusiin palvelimen käynnistämiin streameihin (joissa stream-tunnisteiden numerot ovat parillisia, kuten pienempien stream-tunnisteiden määrityssäännöt edellyttävät).
- Selain vastaanottaa resursseja ennen HTML:n jäsentämistä, kun se havaitsee tarvitsevansa niitä.
Näin vältytään edestakaisilta matkoilta. Sen sijaan:
- Pyydä HTML → Vastaanota HTML
- Parseeraa HTML, löydä tarvittava CSS → Pyydä CSS:ää
- CSS:n jäsentäminen, tarvittavien fonttien löytäminen → fonttien pyytäminen
Palvelimen työntäminen yhdistää vaiheet 2-3 vaiheeseen 1.
Palvelinten työntäminen on kuitenkin osoittautunut käytännössä ongelmalliseksi:
- Selaimissa saattaa olla jo resursseja välimuistissa, jolloin työntäminen on turhaa.
- Väärin konfiguroidut palvelimet työntävät liian aggressiivisesti, mikä tuhlaa kaistanleveyttä.
- Välimuistitietoja ei ole koskaan otettu laajasti käyttöön.
- Monet CDN:t ja selaimet rajoittavat nyt pushia tai poistavat sen käytöstä oletusarvoisesti.
Asiakkaat voivat poistaa push-toiminnon kokonaan käytöstä asettamalla SETTINGS_ENABLE_PUSH = 0 yhteyden esipuheessa. Kun asiakkaan yhteyden esipuhe poistaa pushin välittömästi käytöstä, palvelimen yhteyden esipuhe koostuu kuittauksesta ja noudattamisesta.
Virran priorisointi
Virtojen priorisoinnin avulla asiakkaat voivat ilmoittaa resurssien tärkeydestä, mikä auttaa palvelimia jakamaan kaistanleveyden tehokkaasti. Mekanismi käyttää:
- Painot: Arvot 1-256, jotka ilmaisevat suhteellisen merkityksen
- Riippuvuudet: Virrat voivat olla riippuvaisia toisista virroista, jolloin muodostuu riippuvuuspuu virran riippuvuusilmoitusten avulla.
Käytännön esimerkki:
- HTML stream (paino 256, ei riippuvuutta) – korkein prioriteetti
- CSS stream (painoarvo 200, riippuu HTML:stä) – korkea prioriteetti
- Taiton yläpuolella olevat kuvat (paino 100, riippuu CSS:stä)
- Analytics JavaScript (painoarvo 16, riippuu HTML:stä) – alhainen prioriteetti
Näin varmistetaan, että kriittiset renderöintipolun resurssit saapuvat ensimmäisenä, mikä parantaa koettua latausnopeutta, vaikka kokonaissiirtoaika pysyisikin samanlaisena.
Tärkeitä varoituksia:
- Priorisointi on neuvoa-antavaa, ei pakollista
- Palvelintoteutukset vaihtelevat suuresti siinä, miten ne kunnioittavat prioriteetteja.
- Välittäjät (välityspalvelimet, CDN:t) voivat järjestää kehykset uudelleen.
- Virittäminen edellyttää testausta todellisella liikenteellä, ei oletuksia.
Mainostettu samanaikaisen virran raja vaikuttaa siihen, kuinka monella virralla voi olla aktiiviset prioriteetit kerrallaan.
Virtauksen hallinta, virheiden käsittely ja turvallisuusnäkökohdat
HTTP/2 toteuttaa TCP:n yläpuolella oman virranohjauksensa ja virheenkäsittelynsä, mikä vastaa tilanteisiin, joissa sovelluskerroksen älykkyys on parempi kuin kuljetuskerroksen oletusarvot.
Virtauksen säätö
Virranohjaus estää nopeita lähettäjiä kuormittamasta hitaita vastaanottajia. HTTP/2 käyttää luottopohjaista järjestelmää WINDOW_UPDATE-kehysten avulla:
- Jokaisella virralla on oma vastaanottimen virranohjausikkunansa
- Yhteydellä on myös yhteysvirran valvontaikkuna
- Ikkunan oletuskoko: 65,535 tavua (64 KB).
- Lähettäjät eivät voi lähettää DATA-kehyksiä, jotka ylittävät vastaanottajan käytettävissä olevan ikkunan.
- Vastaanottajat lähettävät WINDOW_UPDATE-kehyksiä myöntääkseen lisää luottoa.
Tärkeimmät ominaisuudet:
- Virtauksenohjaus on hop-by-hop (sovelletaan jokaisen lähettäjä/vastaanottajaparin välillä).
- Sitä ei voi poistaa käytöstä
- Ainoastaan DATA-kehykset lasketaan ikkunaan; muita pakollisia kehystietoja ei lasketa.
- Sekä virran virtauksen valvonta että yhteyden virtauksen valvonta toimivat toisistaan riippumatta.
Tämä estää yhtä nopeaa virtaa monopolisoimasta yhteysresursseja, mikä on erityisen tärkeää, kun asiakkaiden ja lähteiden välissä on välityspalvelimia tai CDN:iä.
Virheiden käsittely
HTTP/2 tarjoaa yksityiskohtaisen virheilmoituksen:
- Virran tason virheet: RST_STREAM lopettaa välittömästi yhden virran vaikuttamatta muihin virtoihin, ja virhekoodit ovat PROTOCOL_ERROR tai FLOW_CONTROL_ERROR.
- Yhteystason virheet: GOAWAY sulkee yhteyden sulavasti, jolloin lennossa olevat pyynnöt voidaan suorittaa loppuun, mutta uudet pyynnöt estetään.
Protokolla määrittelee virhekoodirekisterin, joka sisältää:
- PROTOCOL_ERROR (0x1): Yleinen protokollarikkomus
- FLOW_CONTROL_ERROR (0x3): Virtauksenohjaussääntöjä rikottu
- FRAME_SIZE_ERROR (0x6): Kehys ylitti SETTINGS_MAX_FRAME_SIZE-arvon.
- INADEQUATE_SECURITY (0xc): Kuljetuskerroksen tietoturvamääritys riittämätön
Turvallisuusnäkökohdat
Vaikka RFC 7540 ei teknisesti edellytä salausta, kaikki tärkeimmät verkkoselaimet edellyttävät HTTP/2:n käyttöä TLS:n (Transport Layer Security) kautta. Tämä tekee TLS 1.2+:sta tosiasiallisen perustason:
- Yhteys alkaa TLS-kättelyllä, johon sisältyy ALPN (Application-Layer Protocol Negotiation).
- ALPN-laajennus neuvottelee ”h2”-tunnisteen HTTP/2:lle.
- Palvelimien on vältettävä heikkoja salausyhdistelmiä, jotka on sisällytetty mustalle listalle.
- RC4:ää tai muita vanhentuneita algoritmeja käyttävät salakirjoitussarjat aiheuttavat INADEQUATE_SECURITY-virheitä.
Yksityisyyden suojaan liittyviä näkökohtia ovat:
- ASETUKSET ja prioriteettikuviot voivat antaa asiakkaille sormenjäljen.
- Yksi yhteys alkuperää kohti korreloi kaiken käyttäjän toiminnan kyseiseen alkuperään.
- Binäärinen protokolla peittää liikenteen, mutta ei piilota sitä verkon tarkkailijoilta.
TCP-linjan pään esto
HTTP/2 ratkaisee HTTP-tason linjan pään eston multipleksoinnin avulla, mutta TCP-tason esto säilyy. Kun TCP-paketti katoaa, kaikki kyseisen yhteyden virrat pysähtyvät, kunnes uudelleenlähetys on suoritettu – myös virrat, joiden tiedot saapuivat onnistuneesti.
Tämä rajoitus oli syynä HTTP/3:een, joka toimii QUICin (UDP-pohjainen) kautta ja tarjoaa todellisen virtojen riippumattomuuden. Yhteen virtaan vaikuttava pakettihäviö ei estä muita virtoja.
HTTP/2:n käyttöönotto ja käyttö käytännössä
Vuonna 2026 HTTP/2:n käyttöönotto on helppoa. Useimmat nykyaikaiset verkkopalvelimet ja CDN:t tukevat sitä valmiiksi, ensisijaisesti HTTPS:n kautta. HTTP-päivitysmekanismi hoitaa neuvottelut läpinäkyvästi.
Asiakaspuolen vaatimukset
Käyttäjien ei tarvitse tehdä mitään erityistä:
- Kaikki nykyaikaiset työpöytäselaimet (Chrome, Firefox, Safari, Edge) tukevat HTTP/2:ta oletusarvoisesti.
- Mobiiliselaimissa (Chrome Androidissa, Safari iOS:ssä) on täysi tuki.
- Yhteensopivuuden varmistaminen nykyisillä selainversioilla
- HTTP/2 neuvottelee automaattisesti, kun se on käytettävissä
Palvelinpuolen konfigurointi
Apache HTTP Server (2.4.17+):
- Ota käyttöön mod_http2-moduuli (ei vanhempi mod_spdy).
- Lisää protokollat h2 http/1.1 TLS-virtuaali-isäntiin
- Varmista, että OpenSSL:n versio tukee ALPN:ää
Nginx (1.9.5+):
server {
listen 443 ssl http2;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# ... rest of configuration
}IIS (Windows Server 2016+):
- HTTP/2 on oletusarvoisesti käytössä HTTPS:ssä TLS 1.2+:n kanssa.
- Ei lisäkonfigurointia
CDN-palveluntarjoajat:
- Cloudflare: HTTP/2 oletusarvoisesti käytössä kaikissa suunnitelmissa
- AWS CloudFront: HTTPS-jakeluille oletusarvoisesti käytössä.
- Fastly: Tuettu ja oletusarvoisesti käytössä
Tarkastus ja vianmääritys
Vahvista, että HTTP/2 toimii tällä tarkistuslistalla:
- Selaimen DevTools: Avaa Network-välilehti, ota Protocol-sarake käyttöön, etsi ”h2”.
- Komentorivi: curl –http2 -I https://example.com näyttää HTTP/2:n vastauksessa.
- Verkkotyökalut: HTTP/2-testipalvelut tarkistavat kokoonpanon
- Tarkista välittäjät: CDN:n tai käänteisen välityspalvelimen on tuettava HTTP/2:ta, ei vain alkuperäisen palvelimen.
Yleiset ongelmat, jotka estävät HTTP/2:n käytön:
- OpenSSL-versio liian vanha ALPN-tukea varten
- Vain TLS 1.0/1.1 -konfiguraatio
- Heikot salaussarjat, jotka käynnistävät varajärjestelyn
- Väärin konfiguroitu välityspalvelin poistaa HTTP/2-tuen
HTTP/2 ja sen jälkeen
HTTP/2 on edelleen hallitseva protokolla nykyaikaisessa verkkoviestinnässä, vaikka HTTP/3 (RFC 9114, julkaistu 2022) alkaa ottaa käyttöön. HTTP/3 puuttuu TCP:n head-of-line-estoon toimimalla QUICin kautta, mutta HTTP/2:n yhden TCP-yhteyden malli palvelee edelleen tehokkaasti suurinta osaa verkkoliikenteestä.
Useimmilla sivustoilla HTTP/2 parantaa huomattavasti verkkosuorituskykyä vähäisellä määritystyöllä. Aloita kehysten vaihtaminen HTTP/2:n kautta jo tänään, ja käyttäjillesi – niin työpöydällä kuin mobiililaitteissakin – tarjotaan nopeampia ja tehokkaampia sivulatauksia.
Keskeiset asiat
- HTTP/2 mullistaa verkon suorituskyvyn multipleksoinnin avulla, mikä mahdollistaa useita samanaikaisia tiedonvaihtoja yhden yhteyden kautta.
- HPACK-otsikon pakkaaminen poistaa turhan otsikon lähetyksen, mikä hyödyttää erityisesti mobiilikäyttäjiä.
- Server push ja stream priorisointi optimoivat resurssien jakelun, mutta toteutus vaihtelee.
- Virtauksenohjaus estää resurssien niukkuuden useiden virtojen välillä.
- Käyttöönotto on suoraviivaista nykyaikaisilla palvelimilla, ja se edellyttää lähinnä HTTPS-konfiguraatiota.
- Kaikki tärkeimmät selaimet tukevat HTTP/2:ta, joten loppukäyttäjät voivat ottaa sen saumattomasti käyttöön.
Seuraavat vaiheet
Jos et ole vielä vahvistanut HTTP/2:ta verkkopalvelimellasi, nyt on oikea aika. Avaa selaimesi kehittäjätyökalut, lataa sivustosi ja tarkista Protocol-sarake. Jos näet http/1.1:n h2:n sijasta http/1.1:n, tarkista palvelinkonfiguraatiosi – saatat jättää huomattavia suorituskykyhyötyjä käyttämättä.
Ne, jotka jo käyttävät HTTP/2:tä, kannattaa harkita palvelimen HTTP/2-yhteysmittausten seurantaa. Ymmärrys siitä, miten useat samanaikaiset virrat käyttäytyvät todellisessa liikenteessä, auttaa tunnistamaan optimointimahdollisuuksia ennen kuin käyttäjät huomaavat ongelmia.