Што е HTTP/3 и зошто е важен?

HTTP/3 е третата голема верзија на протоколот што го овозможува функционирањето на интернетот. За разлика од претходните верзии, тој е изграден врз QUIC наместо TCP. Со тоа се намалува доцнењето при воспоставување врска, се избегнува блокирањето на повеќе барања поради загуба на еден пакет и се овозможува врската да остане активна кога корисникот на мобилен уред преминува од една мрежа на друга. Во овој напис ќе објасниме што е HTTP/3, кога може да донесе забележливи подобрувања, кога разликата е мала и како може да се овозможи на твојот хостинг.

HTTP/3 е третата голема верзија на Hypertext Transfer Protocol, односно протоколот што ги определува правилата според кои веб-прелистувачите и серверите разменуваат податоци. Во 2022 година IETF официјално го стандардизира HTTP/3 како RFC 9114, како дел од група стандарди со кои беше модернизиран HTTP. Денес сите поголеми веб-прелистувачи имаат вградена поддршка за HTTP/3.

На почетокот на 2026 година, HTTP/3 учествувал со приближно 21% од глобалниот сообраќај на мрежата на Cloudflare. HTTP/2 и понатаму бил најзастапен со околу 51%, додека HTTP/1.x сè уште учествувал со приближно 27%.

Најголемата промена се случува на транспортното ниво. HTTP/3 го напушта TCP и работи преку QUIC, протокол изграден врз UDP. Оваа промена решава дел од проблемите со перформансите што HTTP/2 не можеше целосно да ги отстрани, особено кај мобилни и нестабилни мрежи каде што почесто доаѓа до загуба на пакети.

Кој проблем го решава HTTP/3?

HTTP/1.1 обработува по едно барање во даден момент преку една TCP-врска. Поради тоа, веб-прелистувачите мора истовремено да отвораат повеќе врски за побрзо да ги вчитаат сите елементи на една веб-страница. Со HTTP/2 ова е подобрено со можноста повеќе барања да се пренесуваат истовремено преку една TCP-врска. Сепак, проблем се појавува кога ќе се изгуби само еден пакет со податоци.

TCP ги пренесува податоците по точно определен редослед. Ако еден пакет се изгуби, пакетите што следуваат мора да почекаат тој повторно да биде испратен, без разлика на кое HTTP барање му припаѓаат. Кај мрежи каде што почесто се губат пакети, пристапот на HTTP/1.1 со повеќе одделни врски понекогаш може да биде поефикасен од една TCP-врска кај HTTP/2.

Овој проблем се нарекува head-of-line blocking, односно блокирање на податоците што чекаат во ред. Тој е поизразен кај мобилни мрежи, Wi-Fi и преоптоварени мрежи.

HTTP/3 го решава овој проблем со QUIC, каде што секое барање може да користи независен тек на податоци. Ако се изгуби пакет, се забавува само текот на кој му припаѓа, додека останатите продолжуваат да се пренесуваат нормално.

Како HTTP/3 се разликува од HTTP/2?

Од гледна точка на корисникот, HTTP/2 и HTTP/3 функционираат слично. И двата овозможуваат истовремено пренесување повеќе барања, компресија на заглавијата и безбедна комуникација. Главната разлика е во транспортниот слој.

Карактеристика	HTTP/2	HTTP/3
Транспорт	TCP	QUIC преку UDP
Шифрирање	Незадолжително, TLS 1.2 или 1.3	Задолжително, TLS 1.3 е вграден во QUIC
Head-of-line blocking	Да, на TCP-ниво	Не, тековите се независни
Воспоставување врска	2 или 3 циклуси на размена	1 циклус, или 0-RTT при повторно поврзување
Преминување меѓу мрежи	Не, врската се прекинува при промена на IP-адресата	Да, врската може да продолжи при преминување од Wi-Fi на мобилна мрежа
Компресија на заглавија	HPACK	QPACK

Побрзото воспоставување врска е најзначајно при првата посета и при повторно поврзување. Кај HTTP/3, QUIC може да го намали бројот на чекори потребни за воспоставување безбедна врска.

Можноста врската да продолжи и при промена на мрежата е особено важна за корисниците на мобилни уреди. На пример, ако корисникот премине од Wi-Fi на мобилна мрежа, HTTP/3 може да ја задржи активната врска без целосно повторно поврзување.

Ова може да биде корисно кај активности што не треба да се прекинат, како пополнување формулар, нарачување производ или плаќање преку интернет.

Што е QUIC и зошто HTTP/3 го користи?

QUIC е транспортен протокол што првично го разви Google, а подоцна IETF го стандардизира како RFC 9000. Тој работи преку UDP бидејќи TCP не може значително да се менува без промени во јадрото на оперативните системи и во мрежната опрема меѓу корисниците и серверите. Таквите промени не се практични во размери на целиот интернет.

QUIC повторно ги воспоставува главните механизми за сигурен пренос што ги има TCP, како повторно испраќање на изгубени пакети, контрола на преоптоварување и пренос на податоците по правилен редослед. Разликата е во тоа што QUIC ги извршува овие функции во корисничкиот простор на оперативниот систем и користи независни текови на податоци за различни барања.

Шифрирањето со TLS 1.3 е составен дел од самиот протокол, наместо дополнителен слој над него. Секој QUIC-тек независно се справува со загубата на пакети. Тоа значи дека ако при вчитување слика се изгубат пакети, тоа нема да го блокира вчитувањето на JavaScript-датотеката.

Зошто HTTP/3 е важен за брзината на веб-страниците?

Најголемите придобивки од HTTP/3 се забележуваат кај мрежи што не се целосно стабилни. Според мерења на Akamai, HTTP/3 може да го намали мрежното доцнење за околу 30% кај мрежи со поголемо доцнење и почеста загуба на пакети, како мобилните мрежи и мрежите во земји каде што интернет-инфраструктурата е послабо развиена.

Токму во вакви услови бавните веб-страници почесто ги тераат корисниците да се откажат од посетата.

Кај брзи и стабилни оптички интернет-врски, ситуацијата е посложена. Научен труд претставен на ACM Web Conference во 2024 година, „QUIC is not Quick Enough over Fast Internet“ од Zhang и неговите соработници, покажал дека QUIC во Chrome може да има до 45,2% помал проток на податоци од HTTP/2 при брзина од 1 Gbps. Разликата во перформансите почнува да станува забележлива при брзини од околу 500 до 600 Mbps.

Како главни причини се наведуваат начинот на кој QUIC ги обработува ACK-потврдите во корисничкиот простор и недостигот од целосна поддршка за UDP Generic Receive Offload во најчесто користените оперативни системи.

Употребата на HTTP/3 достигнала врв од приближно 28% во 2023 година, а во 2026 година се движи околу 21%. Една од причините за ова е токму разликата во протокот на податоци кај многу брзи мрежи.

HTTP/3 е зрела технологија и неговите предности се реални, но тоа не значи дека автоматски ќе донесе подобри перформанси во секоја мрежа и за секоја веб-страница.

Кој има најголема корист од HTTP/3?

Најголемо подобрување најчесто забележуваат веб-страници со многу посетители преку мобилни уреди, меѓународна публика или корисници што пристапуваат преку нестабилни мрежи.

Најтипични примери се:

• Онлајн продавници, каде што процесот на нарачување може да започне преку Wi-Fi, а да продолжи преку мобилна мрежа. Можноста за продолжување на врската при промена на мрежата помага процесот на плаќање да не се прекине.
• Медиумски веб-страници и сервиси за семрежно емитување, особено кога корисниците гледаат содржина преку мобилна мрежа. Независните текови значат дека загубата на пакет при пренос на видео не мора да го запре вчитувањето на JavaScript или CSS што се потребни за читачот на видеа.
• SaaS апликации со корисници од различни делови на светот. Побрзото воспоставување врска може да го намали времето потребно апликацијата да стане подготвена за користење при нова сесија.
• WordPress и е-трговски веб-страници што веќе користат CDN. Во вакви случаи HTTP/3 често може да се овозможи со едноставна поставка на CDN-мрежата, без промени на основниот сервер.

Веб-страниците што главно ги посетуваат корисници на персонални компјутери преку брзи и стабилни интернет-врски може да забележат многу мало подобрување. Во одредени ситуации каде што е најважен максималниот проток на податоци, HTTP/3 може дури да има и малку послаби перформанси.

Кои се ограничувањата на HTTP/3?

Пред HTTP/3 да се овозможи на активна веб-страница, треба да се земат во предвид неколку практични ограничувања.

Протокот на UDP на Linux-серверите може да биде ограничен од начинот на кој оперативниот систем ги обработува мрежните пакети. Без соодветна поддршка за UDP GRO, HTTP/3 може да го оптовари процесорот пред целосно да го искористи достапниот мрежен капацитет.

Некои корпоративни заштитни ѕидови и мрежни уреди го блокираат или ограничуваат UDP-сообраќајот преку портата 443. Современите веб-прелистувачи можат да го препознаат тоа и автоматски да преминат на HTTP/2, но таквото преминување може да додаде дополнително доцнење при првото барање.

Пребарувачите и роботите на социјалните мрежи и понатаму во голема мера користат HTTP/1.1 и HTTP/2. Анализите на Cloudflare покажуваат дека дури и неколку години по стандардизацијата на HTTP/3, голем дел од овие роботи речиси воопшто не го користат.

Поради тоа, HTTP/3 не носи директна предност за SEO или за брзината со која пребарувачите ја прегледуваат веб-страницата.

Отстранувањето грешки и анализирањето на мрежниот сообраќај исто така се посложени. QUIC користи шифрирање уште на транспортниот слој, па снимањето и анализирањето на пакетите е помалку корисно отколку кај TCP, освен ако немате пристап до потребните TLS-клучеви.

Како да овозможите HTTP/3 на сервер?

Начинот на активирање зависи од серверската конфигурација.

Преку CDN

За повеќето веб-страници ова е наједноставниот начин.

Cloudflare, на пример, овозможува HTTP/3 преку поставките за мрежа во својата контролна табла. HTTP/3 врската се воспоставува на серверите на Cloudflare, додека основниот сервер на веб-страницата може и понатаму да користи HTTP/2 или HTTP/1.1.

Тоа значи дека HTTP/3 може да се користи без директни промени на веб-серверот.

Преку NGINX

NGINX додаде поддршка за HTTP/3 преку модулот ngx_http_v3_module во верзијата 1.25.0.

За негово користење е потребна соодветна серверска конфигурација и поддршка за TLS 1.3. Во серверскиот блок се додава директива како:

listen 443 quic reuseport;

Потребно е и UDP портата 443 да биде дозволена во заштитниот ѕид на серверот.

Преку LiteSpeed

LiteSpeed Web Server и OpenLiteSpeed веќе подолг период имаат поддршка за HTTP/3.

Во многу конфигурации HTTP/3 е овозможен стандардно, па најчесто е потребно само да се провери дали UDP портата 443 е отворена.

А што е со Apache?

Apache HTTP Server, заклучно со 2026 година, нема вградена HTTP/3 поддршка во стабилните изданија наменети за продукциска употреба.

Најчестото решение е пред Apache да се постави NGINX или LiteSpeed како обратен посреднички сервер, или да се користи CDN што ќе ја воспоставува HTTP/3 врската со посетителите.

Дали cPanel поддржува HTTP/3?

Не директно. cPanel и EasyApache 4 немаат вграден модул за HTTP/3, бидејќи самиот Apache сè уште нема своја поддршка за HTTP/3.

Администраторите што сакаат да користат HTTP/3 на сервер управуван преку cPanel најчесто поставуваат обратен посреднички сервер (reverse proxy) пред Apache или ја воспоставуваат HTTP/3 врската преку CDN.

Ова не е само поставка што може едноставно да се вклучи, туку одлука што зависи од начинот на кој е поставена серверската инфраструктура.

Ако најголемиот дел од посетителите пристапуваат преку десктоп-компјутери и значителен дел од сообраќајот доаѓа од роботи на пребарувачи, HTTP/3 најчесто нема висок приоритет.

Но, ако веб-страницата има голем број посетители преку мобилни уреди и се важни непреченото завршување на нарачките и брзата реакција на веб-апликацијата, наједноставно решение е HTTP/3 да се овозможи преку CDN.

Како да проверите дали HTTP/3 работи?

Отворете ги алатките за програмери во современ веб-прелистувач, преминете во табот Network, кликнете со десното копче на насловите на колоните и додајте ја колоната Protocol. Кај страниците што се вчитуваат преку HTTP/3, во оваа колона ќе се прикаже вредноста h3.

Корисниците што работат преку командна линија можат да ја користат следнава команда:

curl -I --http3 https://www.vasatawebstranica.com

Современите верзии на curl може да имаат поддршка за HTTP/3, зависно од начинот на кој се компајлирани и од достапните библиотеки.

Може да се користат и онлајн алатки, како HTTP3Check.net, за да се провери дали одреден домен успешно воспоставува HTTP/3 врска од надворешна мрежа.

Дали треба да му дадете приоритет на HTTP/3 денес?

За повеќето активни веб-страници, HTTP/3 е корисно подобрување, но не и неопходност. Веб-страниците што веќе користат HTTP/2 преку HTTPS и работат зад CDN веќе ги имаат добиено најголемите придобивки што може да ги донесе самиот протокол. Овозможувањето HTTP/3 носи дополнително подобрување, најмногу за корисници на мобилни уреди и посетители што пристапуваат преку нестабилни мрежи.

За повеќето веб-страници, најдобар редослед на чекори е:

1. Проверете дали HTTPS е задолжително овозможен на целата веб-страница и дали се користи важечки SSL-сертификат.
2. Проверете дали HTTP/2 е овозможен на основниот сервер и дали навистина се користи на веб-страниците.
3. Ако користите CDN, овозможете HTTP/3 преку него. Во многу случаи не се потребни промени на основниот сервер.
4. Размислете за HTTP/3 директно на серверот само ако вашата серверска околина го поддржува, на пример преку NGINX или LiteSpeed, и ако имате значителен сообраќај од мобилни уреди.

Кај повеќето веб-страници, поголемо подобрување на перформансите може да се постигне со оптимизирање на барањата кон базата на податоци, користење кеширање со Redis и OPcache, оптимизирање на сликите и избор на серверска инфраструктура што одговара на обемот на сообраќај.

Затоа HTTP/3 не треба да се гледа како замена за основната оптимизација на веб-страницата. Тој е дополнително подобрување што има најголема вредност кога основната конфигурација, кеширањето, сликите, серверот и базата на податоци веќе се добро оптимизирани.

Ако не е јасно каде е главниот проблем со брзината, најдобро е прво да се проверат показатели како TTFB, оптоварувањето на серверот и брзината на барањата кон базата на податоци. Така може да се утврди која оптимизација ќе донесе најголемо реално подобрување.