16 min. lasīt

HTTP/2: pilnīgs ceļvedis par mūsdienu tīmekļa veiktspēju

Hiperteksta pārsūtīšanas protokols kopš tā pirmsākumiem ir būtiski attīstījies, un HTTP/2 ir viens no nozīmīgākajiem pavērsieniem datu pārsūtīšanā pasaules tīmeklī. Ja pēdējo gadu laikā esat pamanījis, ka tīmekļa lapas ielādējas ātrāk, pastāv liela iespēja, ka HTTP/2 darbojas aizkulisēs.

Šajā rokasgrāmatā ir izklāstīts viss, kas jums jāzina par HTTP/2 – sākot notā pamatmehānikas un veiktspējas priekšrocībām un beidzot ar praktiskiem izvēršanas soļiem. Neatkarīgi no tā, vai esat izstrādātājs, kas vēlas optimizēt savu tīmekļa serveri, vai vienkārši interesējaties par to, kas padara mūsdienīgas tīmekļa vietnes ērtas, šeit atradīsiet noderīgu informāciju.

Ātrā atbilde: Kas ir HTTP/2 un kāpēc tas ir svarīgi

HTTP/2 ir hiperteksta pārsūtīšanas protokola 1.1 versijas būtiska pārskatīta versija, ko Interneta inženierijas darba grupa standartizēja ar RFC 7540 (2015. gada maijs). Tajā galvenā uzmanība ir pievērsta latentuma samazināšanai, tīkla resursu izmantošanas uzlabošanai un tīmekļa lapu ielādēšanas paātrināšanai, vienlaikus saglabājot pilnīgu atpakaļejošu savietojamību ar esošo HTTP semantiku.

2026. gadā HTTP/2 lietošana būs gandrīz izplatīta. Saskaņā ar W3Techs datiem vairāk nekā 1/3 no populārākajām vietnēm aktīvi izmanto HTTP/2, un lielākā daļa lielāko CDN (Cloudflare, AWS CloudFront, Fastly) to pēc noklusējuma nodrošina HTTPS datplūsmai. Ja jūsu vietne darbojas HTTPS režīmā, izmantojot mūsdienīgu tīmekļa serveri, jūs, visticamāk, jau izmantojat HTTP/2 priekšrocības bez papildu konfigurācijas.

Protokolā ir ieviestas vairākas galvenās funkcijas, kas novērš HTTP 1.1 vājās vietas veiktspējas ziņā:

  • Multipleksēšana: Vairākas datu plūsmas vienlaicīgi ceļo pa vienu TCP savienojumu.
  • galvenes saspiešana (HPACK): Ieviesta galvenes lauka saspiešana, kas ievērojami samazina lieko HTTP galvenes metadatu apjomu.
  • Binary framing slānis: Pilnīgi vispārīgs rāmju slānis, kas aizstāj teksta komandas ar efektīvu bināro ziņojumu ierāmēšanu.
  • Servera stumšana: Proaktīva resursu piegāde, pirms pārlūkprogramma tos nepārprotami pieprasa.
  • Straumju prioritāšu noteikšana: Klientu mājieni, kas serveriem norāda, kuri resursi ir vissvarīgākie.

Lūk, ko tas nozīmē praksē:

  • Ātrāka lapas ielāde, jo īpaši vietnēs, kurās ir daudz resursu.
  • Mazāk nepieciešamo TCP savienojumu katrai izcelsmei
  • Labāka veiktspēja mobilajos tīklos ar lielu latentumu
  • Uzlabota tīkla izmantošana visās jomās

No HTTP/0.9 līdz HTTP/2: īsa vēsture

Kopš Tims Berners-Lī (Tim Berners-Lee) 1991. gadā ieviesa HTTP/0.9 kā vienkāršu HTML dokumentu saņemšanas mehānismu, HTTP protokols ir krietni attīstījies. HTTP/1.0 sekoja 1996. gadā, pievienojot galvenes un statusa kodus, un HTTP/1.1 tika standartizēts RFC 2068 (1997) un vēlāk precizēts RFC 2616 (1999). Gandrīz divas desmitgades HTTP/1.1 kalpoja par klienta-servera saziņas pamatu tīmeklī.

Taču tīmeklī notikušas būtiskas pārmaiņas. Mūsdienu tīmekļa lapas no vienkāršiem dokumentiem kļuva par sarežģītām lietojumprogrammām, kurās ir desmitiem JavaScript pakešu, CSS failu, attēlu un API izsaukumu. Pat ar platjoslas pieslēgumiem un jaudīgu aparatūru HTTP/1.1 arhitektūra radīja sastrēgumus:

  • Līnijas bloķēšanas vadītājs: Katrs TCP savienojums vienlaikus varēja apstrādāt tikai vienu pieprasījumu, tādējādi radot nevajadzīgu tīkla datplūsmu, jo resursi gaidīja rindā.
  • Pieslēguma pieskaitāmās izmaksas: Lai apietu šo ierobežojumu, darbvirsmas tīmekļa pārlūkprogrammas un mobilās tīmekļa pārlūkprogrammas parasti atver 6-8 paralēlus TCP savienojumus katrai izcelsmei.
  • lieki virsraksti: Katrā HTTP pieprasījumā vairākkārt nosūtītas vienas un tās pašas verbālās galvenes (sīkfaili, lietotāja aģents, akceptēt galvenes).

Uzņēmums Google atzina šīs problēmas un 2009. gadā uzsāka SPDY projektu. Pirmo reizi tas tika ieviests pārlūkprogrammā Chrome ap 2010. gadu, un SPDY ieviesa vairākus jauninājumus:

  • Binary framing nevis uz tekstu balstīti protokoli
  • Vairāku pieprasījumu multipleksēšana, izmantojot vienu savienojumu
  • galvenes saspiešana, lai samazinātu pieskaitāmās izmaksas
  • Kritisko resursu prioritāšu noteikšana

IETF HTTP darba grupa saskatīja SPDY potenciālu un 2012. gadā pieņēma to par HTTP/2 sākumpunktu. Pēc apjomīga IETF http darba grupas darba 2015. gada maijā tika publicēts RFC 7540 (HTTP/2) un RFC 7541 (HPACK).

Pārlūkprogrammu ieviešana notika ātri:

  • Sākot ar Chrome 51 (2016. gada maijs), Chrome atteicās no SPDY, aizstājot to ar HTTP/2.
  • Firefox pievienoja HTTP/2 atbalstu 36. versijā (2015. gada februārī)
  • Safari sekoja 9. versijā (2015. gada septembris)
  • Microsoft Edge tika piegādāts ar HTTP/2 atbalstu jau sākotnējā versijā
  • Pat Internet Explorer 11 ieguva HTTP/2 atbalstu operētājsistēmā Windows 8.1 un jaunākās versijās

Dizaina mērķi un galvenās atšķirības no HTTP/1.1

HTTP/2 saglabā pilnīgu savietojamību ar HTTP/1.1 semantiku. Tādas metodes kā GET un POST darbojas identiski. Stāvokļa kodi paliek nemainīgi. URI un HTTP galvenes lauki atbilst tiem pašiem noteikumiem. Mainās tikai tas, kā šie dati pārvietojas pa vadu – transporta slāņa mehānika, kas nosaka faktisko ielādes ātrumu.

Protokola izstrādes mērķi bija skaidri:

MērķisKā HTTP/2 to sasniedz
Samazināt latentumuMultipleksēšana novērš HTTP līmeņa līnijas bloķēšanu
Labāka savienojuma izmantošanaViens TCP savienojums apstrādā visus pieprasījumus uz izcelsmes vietu.
Nogrieziet galveni virs galvasHPACK saspiešana samazina iepriekš pārsūtītās galvenes vērtības.
Uzlabot mobilo ierīču veiktspējuMazāks savienojumu skaits un mazāki galvenes numuri ir izdevīgi augstas latentuma pakāpes tīkliem.

Šīs konstrukcijas priekšrocība ir atpakaļejošā savietojamība lietojumprogrammu līmenī. Jūsu esošais tīmekļa lietojumprogrammas kods – maršruti, apstrādātāji, atbildes loģika – nav jāmaina. Tikai klienta un servera paketei jāatbalsta HTTP/2, lai redzētu ieguvumus.

Tas krasi atšķiras no HTTP/1.1 apvedceļiem, kas izstrādātājiem bija jāievieš manuāli:

  • Domēna sadale: Aktīvu izkliedēšana vairākos domēnos, lai atvērtu vairāk savienojumu
  • Aktīvu savienošana: CSS un JavaScript failu apvienošana, lai samazinātu pieprasījumu skaitu
  • Attēlu sprites: Vairāku attēlu apvienošana vienā failā
  • Ielaidumi: CSS un JavaScript iestrādāšana tieši HTML

HTTP/2 pamatmehānika, kas aizstāj šos hakerus:

  • Binary framing slānis: Ziņojumi, kas sadalīti rāmjos, efektīvi pārnēsā datus kā bināra protokola vienības.
  • Multipleksētas plūsmas: Vairākas vienlaicīgas apmaiņas notiek, izmantojot vienu un to pašu savienojumu.
  • HPACK galvenes saspiešana: Dinamiskās tabulas izseko galvenes, novēršot lieko darbu.
  • Servera stumšana: Serveri proaktīvi nosūta resursus, kas būs nepieciešami klientam.
  • Straumju prioritāšu noteikšana: Klienti signalizē, kuri resursi ir vissvarīgākie, izmantojot plūsmas atkarības svērumus.

Binary Framing, plūsmas, ziņojumi un multipleksēšana

HTTP/2 pamatā ir binārais kadrēšanas slānis, kas ir būtiska atkāpe no HTTP/1.1 teksta formāta. Katrs HTTP ziņojums tiek sadalīts binārajos rāmjos ar konsekventu rāmja izkārtojumu: 9 baitu rāmja galvene, kas satur garumu, tipu, karogus un plūsmas identifikatorus, un pēc tam seko izvēles dati par komerckravu.

Lai izprastu hierarhiju, ir jāsaprot trīs jēdzieni:

Straumes ir neatkarīgi divvirzienu kanāli vienā savienojumā. Katrai plūsmai ir unikāls 31 bita identifikators. Klienti ierosina plūsmas ar nepāra numuru identifikatoriem (1, 3, 5…), savukārt serveri izmanto pāra numuru identifikatorus (2, 4, 6…) servera ierosinātām plūsmām, piemēram, push. Neparedzēts plūsmas identifikators izraisa kļūdu. Maksimālais vienlaicīgo plūsmu iestatījums nosaka, cik daudz plūsmu var būt aktīvas vienlaicīgi.

Ziņojumi ir pabeigti HTTP pieprasījumi vai atbildes. Pilns galvenes bloks sastāv no viena vai vairākiem rāmjiem, un atbildes var ietvert vairākus datu rāmjus. Kad uztvērējs sastopas ar galvenes bloka fragmentiem, tas tos atkal saliek kopā, lai rekonstruētu pilnu ziņojumu.

Rāmīši ir vismazākās vadu vienības. Biežāk sastopamie kadru un kļūdu tipi ir šādi:

  • DATU rāmji: Pārnēsā pieprasījuma/atbilde korpusa saturu
  • Rāmis HEADERS: Satur HTTP galvenes laukus, kas, iespējams, sadalīti vairākos rāmjos, ko sauc par galvenes bloka fragmentiem.
  • IESTATĪJUMI: Savienojuma vadības ziņojumi konfigurācijai
  • WINDOW_UPDATE: plūsmas vadības loga pielāgojumi
  • PUSH_PROMISE: Paziņo par servera stumšanu
  • RST_STREAM: Pārtrauc plūsmu ar kļūdas kodu
  • PIEDĀVĀJUMS: Iniciē graciozu savienojuma izslēgšanu

Maģiskais efekts rodas, izmantojot multipleksēšanu. Tā kā kadrus no vairākām vienlaicīgi atvērtām plūsmām var pārkārtot vienā TCP savienojumā – ar jebkuru no galapunktiem, kas pēc vajadzības pārkārto kadrus -, nav jāgaida. Uztvērējs atkārtoti saliek kadrus pēc plūsmas identifikatora.

Apsveriet tipiskas tīmekļa lapas ielādi, kurai nepieciešams:

  • index.html (10 KB)
  • styles.css (25 KB)
  • app.js (100 KB)
  • logo.png (15 KB)
  • hero-image.jpg (200 KB)

Izmantojot HTTP/1.1, pārlūkprogramma paralēli atver vairākus savienojumus, lai tos iegūtu, un joprojām tiek pārsniegti ierobežojumi. Izmantojot HTTP/2, visi pieci resursi tiek pārsūtīti vienlaicīgi, izmantojot vienu savienojumu kā vairākas datu plūsmas. Datu kadri no dažādām datu plūsmām pārklājas, un gan klients, gan serveris efektīvi pārvalda visu savienojumu.

Tas novērš nepieciešamību pēc vairākiem TCP savienojumiem, samazinot savienojuma plūsmas kontroles loga režiju un ievērojami uzlabojot tīmekļa veiktspēju.

Virsraksta saspiešana ar HPACK

HPACK, kas definēts RFC 7541 (publicēts kopā ar HTTP/2 2015. gada maijā), nodrošina tieši HTTP/2 paredzēta galvenes saspiešana. Tas ir svarīgi, jo HTTP/1.1 galvenes bija izvērstas un pilnīgi nesaspiestas, tādējādi radot nevajadzīgu tīkla datplūsmu katrā pieprasījumā.

Aplūkojiet tipiska HTTP pieprasījuma galvenes:

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...

Šie galvenes dati bieži vien pārsniedz 700-800 baitus vienā pieprasījumā. Izmantojot sīkfailus, tie var sasniegt vairākus kilobaitus. Ja reizina ar vairākiem desmitiem pieprasījumu vienā lapā, jūs izšķērdējat ievērojamu joslas platumu, kas ir īpaši sāpīgi mobilajos tīklos.

HPACK saspiež galvenes, izmantojot trīs mehānismus:

  1. Statiskā tabula: 61 iepriekš definēts kopīgs galvenes lauka/vērtības pāris (piemēram, :method: GET vai :status: 200), kas nekad nav jānosūta.
  2. Dinamiskā tabula: Iepriekš pārsūtīto galvenes vērtību saglabāšana atkārtotai izmantošanai: specifiska savienojuma tabula, ko klients un serveris veido kopā.
  3. Huffmana kodēšana: Teksta vērtības tiek kodētas, izmantojot iepriekš definētu Huffmana tabulu, samazinot teksta attēlojumu.

Rezultāts ir dramatisks. Pēc tam, kad pirmais pieprasījums nosaka kopīgās galvenes dinamiskajā tabulā, turpmākajos pieprasījumos var tikt pārsūtītas tikai indeksu atsauces. Sākotnēji kilobaitu lielās galvenes samazinās līdz desmitiem baitu.

HPACK tika īpaši izstrādāts, lai izvairītos no tādām drošības ievainojamībām kā CRIME un BREACH, kas skāra iepriekšējās saspiešanas shēmas, piemēram, SPDY DEFLATE. Izmantojot statiskus Huffman kodus un rūpīgu tabulu pārvaldību, HPACK neļauj uzbrucējiem izmantot saspiešanas koeficienta analīzi, lai iegūtu noslēpumus no jauktiem uzbrucēja/ upura datiem.

Ir vērts atzīmēt, ka HPACK darbojas tikai ar HTTP galvenēm. Atbildes korpusos joprojām tiek izmantoti standarta satura kodēšanas mehānismi, piemēram, gzip vai Brotli HTTP slānī, kas ir pilnīgi atsevišķi no galvenes kompresijas.

Servera push un plūsmas prioritāšu noteikšana

HTTP/2 ievieš divas optimizācijas funkcijas, kas paredzētas, lai aizstātu HTTP/1.1 apiešanas iespējas: servera push proaktīvai resursu piegādei un plūsmas prioritāšu noteikšana inteliģentai resursu sakārtošanai.

Servera Push

Serveris push ļauj tīmekļa serverim nosūtīt resursus klientam, pirms tie ir skaidri pieprasīti. Šis mehānisms darbojas, izmantojot PUSH_PROMISE rāmjus:

  • Klienta pieprasījumi /index.html
  • Serveris atbild ar HTML, bet arī nosūta PUSH_PROMISE rāmjus, paziņojot, ka tas būs push /styles.css un /app.js
  • Serveris nosūta šos resursus jaunās servera iniciētās plūsmās (ar plūsmas identifikatoriem, kuros izmantoti pāra skaitļi saskaņā ar zemākas vērtības plūsmas identifikatoru piešķiršanas noteikumiem).
  • Pārlūkprogramma saņem resursus, pirms HTML analizēšanas atklāj, ka tie tai ir vajadzīgi.

Tādējādi tiek novērsti apļveida braucieni. Tā vietā:

  1. Pieprasīt HTML → Saņemt HTML
  2. Izanalizējiet HTML, atrodiet vajadzīgo CSS → Pieprasīt CSS
  3. CSS analīze, nepieciešamo fontu atklāšana → Pieprasīt fontus

Servera piespiešana 2.-3. posmu darbību apvieno ar 1. darbību.

Tomēr praksē servera piespiešana ir izrādījusies problemātiska:

  • Pārlūkprogrammās resursi jau var būt kešatmiņā, tāpēc stumšana ir nelietderīga.
  • Nepareizi konfigurēti serveri darbojas pārāk agresīvi, izšķērdējot joslas platumu.
  • Cache digest mehānismi nekad nav guvuši plašu izplatību
  • Daudzi CDN un pārlūkprogrammas tagad pēc noklusējuma ierobežo vai atspējoš.

Klienti var pilnībā atslēgt push, iestatot SETTINGS_ENABLE_PUSH = 0 savā savienojuma priekšvārdā. Ja klienta savienojuma priekšvārds uzreiz izslēdz push, servera savienojuma priekšvārds sastāv no apstiprinājuma un atbilstības.

Straumes prioritāšu noteikšana

Straumju prioritātes noteikšana ļauj klientiem signalizēt par resursu nozīmīgumu, palīdzot serveriem efektīvi sadalīt joslas platumu. Mehānisms izmanto:

  • Svars: Vērtības no 1-256, kas norāda relatīvo nozīmi
  • Atkarības: plūsmas var būt atkarīgas no citām plūsmām, veidojot atkarību koku, izmantojot plūsmu atkarību deklarācijas.

Praktisks piemērs:

  • HTML plūsma (svars 256, nav atkarības) – augstākā prioritāte
  • CSS plūsma (svars 200, atkarīgs no HTML) – augsta prioritāte
  • Attēli virs pārlocījuma (svars 100, atkarīgs no CSS)
  • Analītika JavaScript (svars 16, atkarīgs no HTML) – zema prioritāte

Tas nodrošina, ka svarīgākie renderēšanas ceļa resursi tiek saņemti pirmie, tādējādi uzlabojot uztveramo ielādes ātrumu, pat ja kopējais pārsūtīšanas laiks paliek līdzīgs.

Svarīgi brīdinājumi:

  • Prioritāšu noteikšana ir ieteicama, nevis obligāta
  • Serveru implementācijas ievērojami atšķiras pēc prioritāšu ievērošanas.
  • Starpnieki (starpnieki, CDN) var mainīt kadru secību.
  • Lai veiktu regulēšanu, ir jāveic testēšana, izmantojot reālu datplūsmu, nevis pieņēmumus.

Reklāmētais vienlaicīgās plūsmas ierobežojums ietekmē to, cik daudzām plūsmām vienlaikus var būt aktīvas prioritātes.

Plūsmas kontrole, kļūdu apstrāde un drošības apsvērumi

HTTP/2 īsteno savu plūsmas kontroli un kļūdu apstrādi virs TCP, risinot scenārijus, kuros lietojumlīmeņa inteliģence pārspēj transporta slāņa noklusējuma iestatījumus.

Plūsmas kontrole

Plūsmas kontrole neļauj ātriem sūtītājiem pārslogot lēnus uztvērējus. HTTP/2 izmanto uz kredītiem balstītu sistēmu ar WINDOW_UPDATE kadriem:

  • Katrai plūsmai ir savs uztvērēja plūsmas kontroles logs.
  • Savienojumam ir arī savienojuma plūsmas kontroles logs
  • Noklusējuma loga lielums: 65 535 baiti (64 KB)
  • Sūtītāji nevar pārraidīt DATA kadrus, kas pārsniedz uztvērēja pieejamo logu.
  • Saņēmēji nosūta WINDOW_UPDATE kadrus, lai piešķirtu vairāk kredīta.

Galvenās īpašības:

  • Plūsmas kontrole ir hop-by-hop (tiek piemērota starp katru sūtītāja/saņēmēja pāri).
  • To nevar atspējot
  • Tikai DATA kadri tiek ieskaitīti logā; citi obligātie kadru dati netiek ieskaitīti.
  • Gan plūsmas plūsmas kontrole, gan savienojuma plūsmas kontrole darbojas neatkarīgi.

Tas neļauj vienai ātrai straumei monopolizēt savienojuma resursus, kas ir īpaši svarīgi, ja starp klientiem un sākumpunktu atrodas starpniekserveri vai CDN.

Kļūdu apstrāde

HTTP/2 nodrošina detalizētu kļūdu signalizēšanu:

  • Straumes līmeņa kļūdas: RST_STREAM nekavējoties pārtrauc vienas plūsmas darbību, neietekmējot pārējās, norādot tādus kļūdu kodus kā PROTOCOL_ERROR vai FLOW_CONTROL_ERROR.
  • Savienojuma līmeņa kļūdas: GOAWAY graciozi izslēdz savienojumu, ļaujot pabeigt lidojumā esošos pieprasījumus, vienlaikus novēršot jaunu pieprasījumu veikšanu.

Protokolā ir definēts kļūdu kodu reģistrs, tostarp:

  • PROTOCOL_ERROR (0x1): Vispārīgs protokola pārkāpums
  • FLOW_CONTROL_ERROR (0x3): Pārkāpti plūsmas kontroles noteikumi
  • FRAME_SIZE_ERROR (0x6): Kadra izmērs pārsniegts SETTINGS_MAX_FRAME_SIZE
  • INADEQUATE_SECURITY (0xc): Transporta slāņa drošības konfigurācija ir nepietiekama

Drošības apsvērumi

Lai gan RFC 7540 tehniski neprasa šifrēšanu, visas galvenās tīmekļa pārlūkprogrammas pieprasa HTTP/2 ar transporta slāņa drošību (TLS). Tādējādi TLS 1.2+ ir de facto pamatlīnija:

  • Savienojums sākas ar TLS rokas satricinājumu, ieskaitot ALPN (Application-Layer Protocol Negotiation).
  • ALPN paplašinājums vienojas par “h2” identifikatoru HTTP/2
  • Serveriem jāizvairās no vāju šifru kopām, kas iekļautas melnajā sarakstā.
  • Cipher suites, kas izmanto RC4 vai citus novecojušus algoritmus, izraisa INADEQUATE_SECURITY kļūdas.

Konfidencialitātes apsvērumi:

  • Iestatījumi un prioritāšu modeļi var iegūt klientu pirkstu nospiedumus.
  • Viens savienojums katrai izcelsmei saista visas lietotāja darbības ar šo izcelsmi.
  • Binārais protokols aizsedz datplūsmu, bet neslēpj to no tīkla novērotājiem

TCP līnijas bloķēšana

HTTP/2, izmantojot multipleksēšanu, atrisina HTTP līmeņa bloķēšanu, bet TCP līmeņa bloķēšana saglabājas. Ja TCP pakete tiek zaudēta, visas plūsmas šajā savienojumā tiek apturētas, līdz tiek pabeigta atkārtota pārraide – pat tās, kuru dati ir veiksmīgi saņemti.

Šis ierobežojums pamato HTTP/3, kas darbojas, izmantojot QUIC (UDP), lai nodrošinātu patiesu plūsmas neatkarību. Paketes zudums, kas ietekmē vienu plūsmu, nebloķē citas.

HTTP/2 izvēršana un izmantošana praksē

2026. gadā HTTP/2 iespējošana ir vienkārša. Lielākā daļa moderno tīmekļa serveru un CDN to atbalsta jau sākotnēji, galvenokārt izmantojot HTTPS. HTTP atjaunināšanas mehānisms pārredzami risina sarunas.

Klienta puses prasības

Lietotājiem nekas īpašs nav jādara:

  • Visas mūsdienīgās darbvirsmas tīmekļa pārlūkprogrammas (Chrome, Firefox, Safari, Edge) pēc noklusējuma atbalsta HTTP/2.
  • Pilnīgs atbalsts mobilajās tīmekļa pārlūkprogrammās (Chrome operētājsistēmā Android, Safari operētājsistēmā iOS).
  • Atbilstība pašreizējām pārlūkprogrammas versijām nodrošina saderību
  • HTTP/2 pārrunas notiek automātiski, kad tas ir pieejams

Servera puses konfigurācija

Apache HTTP serveris (2.4.17+):

  • Ieslēgt mod_http2 moduli (nevis vecāko mod_spdy).
  • Protokolu h2 http/1.1 pievienošana TLS virtuālajiem hostiem
  • Pārliecinieties, ka OpenSSL versija atbalsta 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 pēc noklusējuma iespējots HTTPS ar TLS 1.2+
  • Nav nepieciešama papildu konfigurācija

CDN pakalpojumu sniedzēji:

  • Cloudflare: HTTP/2 iespējots pēc noklusējuma visos plānos
  • AWS CloudFront: Ieslēgts pēc noklusējuma HTTPS izplatīšanai.
  • Fastly: atbalstīta un iespējota pēc noklusējuma

Verifikācija un problēmu novēršana

Apstipriniet, ka HTTP/2 darbojas, izmantojot šo kontrolsarakstu:

  • Pārlūka DevTools: Atveriet cilni Tīkls, iespējojiet kolonnu Protokols, meklējiet “h2”.
  • Komandas rinda: curl –http2 -I https://example.com rāda HTTP/2 atbildi.
  • Tiešsaistes rīki: HTTP/2 testēšanas pakalpojumu konfigurācijas pārbaude
  • Pārbaudiet starpniekus: CDN vai reversajam starpniekserverim jāatbalsta HTTP/2, ne tikai izcelsmes serveris.

Biežāk sastopamās problēmas, kas kavē HTTP/2:

  • OpenSSL versija ir pārāk veca ALPN atbalstam
  • Tikai TLS 1.0/1.1 konfigurācija
  • Vāju šifru komplektu izmantošana, lai aktivizētu atteikuma režīmu
  • Nepareizi konfigurēts starpniekserveris, kas atņem HTTP/2 atbalstu

HTTP/2 un tālāk

HTTP/2 joprojām ir dominējošais mūsdienu tīmekļa saziņas protokols, pat ja HTTP/3 (RFC 9114, publicēts 2022. gadā) tiek ieviests. HTTP/3 risina TCP head-of-line bloķēšanas problēmu, darbojoties ar QUIC, taču HTTP/2 vienotā TCP savienojuma modelis turpina efektīvi apkalpot lielāko daļu tīmekļa datplūsmas.

Lielākajai daļai vietņu HTTP/2 nodrošina ievērojamus tīmekļa veiktspējas uzlabojumus ar minimāliem konfigurēšanas darbiem. Jau šodien sāciet apmainīties ar kadriem, izmantojot HTTP/2, un jūsu lietotāji – gan datorā, gan mobilajā ierīcē – varēs ātrāk un efektīvāk ielādēt lapas.

Galvenie secinājumi

  • HTTP/2 revolucionāri uzlabo tīmekļa veiktspēju, izmantojot multipleksēšanu, kas ļauj veikt vairākus vienlaicīgus datu apmaiņu savienojumus vienā savienojumā.
  • HPACK galvenes saspiešana novērš lieko galvenes pārraidi, kas ir īpaši izdevīgi mobilajiem lietotājiem.
  • Servera izstumšana un plūsmas prioritāšu noteikšana optimizē resursu piegādi, lai gan to īstenošana atšķiras.
  • Plūsmas vadība novērš resursu izsīkšanu vairākās plūsmās.
  • Izvietošana ir vienkārša modernajos serveros, galvenokārt ir nepieciešama HTTPS konfigurācija.
  • Visas galvenās pārlūkprogrammas atbalsta HTTP/2, tādējādi nodrošinot ērtu ieviešanu galalietotājiem.

Turpmākie soļi

Ja neesat pārbaudījis HTTP/2 savā tīmekļa serverī, tagad ir īstais brīdis. Atveriet pārlūkprogrammas izstrādātāja rīkus, ielādējiet vietni un pārbaudiet slejā Protokols. Ja “h2” vietā redzat “http/1.1”, pārskatiet sava servera konfigurāciju – jūs atstājat uz galda ievērojamu veiktspējas pieaugumu.

Tiem, kas jau izmanto HTTP/2, apsveriet iespēju uzraudzīt servera HTTP/2 savienojumu rādītājus. Izpratne par vairāku vienlaicīgu plūsmu uzvedību reālas datplūsmas apstākļos palīdz noteikt optimizācijas iespējas, pirms lietotāji pamana problēmas.