HTTP versiyalari va real-time aloqa: HTTP/2, HTTP/3, SSE va WebSocket

Qisqacha: HTTP/1.1 bitta ulanishda so'rovlarni navbat bilan yuboradi. HTTP/2 bitta ulanishda o'nlab so'rovni bir vaqtda yuboradi (multiplexing), HTTP/3 esa buni UDP ustidagi QUIC protokolida qiladi va yo'qolgan paket boshqalarni to'xtatmaydi. Server o'zi xabar yuborishi kerak bo'lsa (chat, jonli narxlar), SSE yoki WebSocket ishlatiladi.

Bu darsda

• HTTP/1.1 dagi "navbatda tiqilish" muammosini tushuntira olasiz.
• HTTP/2 multiplexing va HTTP/3 + QUIC nimani yaxshilaganini bilasiz.
• Brauzer va server HTTP versiyasini qanday kelishishini (ALPN, Alt-Svc) ko'rasiz.
• Polling, long polling, SSE va WebSocket farqini ayta olasiz va vazifaga mosini tanlaysiz.
• SSE oqimi va WebSocket salomlashuvini terminalda o'z ko'zingiz bilan ko'rasiz.

Oldin bilishingiz kerak: Manzilni yozganda nima bo'ladi: to'liq sayohat, Protokol qatlamlari: TCP va UDP, HTTPS va TLS.

1. Nega bu kerak?

1997-yilda oddiy veb-sahifa bitta HTML va 2–3 ta rasmdan iborat edi. Bugun bitta sahifani ochish uchun brauzer ko'pincha 50–100 ta fayl so'raydi: CSS, JavaScript, shriftlar, rasmlar, ikonkalar.

Oldingi darsda ko'rdik: har bir so'rov uchun vaqt ketadi. 100 ta faylni bittalab, navbat bilan so'rasak, sahifa juda sekin ochiladi. Birinchi muammo — ko'p faylni tez yuklash.

Ikkinchi muammo boshqacha. Client–server darsida HTTP qoidasini o'rgandik: mijoz so'raydi, server javob beradi. Server o'zi birinchi bo'lib gapira olmaydi. Lekin Telegram'da do'stingiz xabar yozsa, u sizda darhol chiqishi kerak. Birja kursi, taksi haydovchisining xaritadagi joyi, futbol hisobi — hammasi "jonli" yangilanishi kerak. Bu real-time (real vaqt) aloqa deyiladi.

Bu darsda ikkala muammo qanday hal qilinganini ko'ramiz.

2. HTTP/1.1: bitta kassali navbat

2.1 Qayta ishlatiladigan ulanish

HTTP/1.0 da har bir fayl uchun yangi TCP ulanish ochilardi. Ulanish ochish qimmat (oldingi dars): TCP va TLS uchun kamida ikki borib-kelish.

1997-yilgi HTTP/1.1 ulanishni qayta ishlatishni odatiy qildi. Bu keep-alive ("tirik saqla") deyiladi. Bitta ulanish ochiladi, undan ketma-ket ko'p so'rov o'tadi. curl -I chiqishlarida ko'rgan Connection: keep-alive sarlavhasi shu haqida.

2.2 Navbatda tiqilish

Lekin HTTP/1.1 da bitta ulanishda bir vaqtda faqat bitta so'rov-javob o'ta oladi. Keyingi so'rov oldingi javob to'liq kelishini kutadi:

HTTP/1.1, bitta ulanish:
So'rov 1 (katta rasm) ──► ...kutish... ◄── Javob 1
                         So'rov 2 (CSS) ──► ◄── Javob 2
                                     So'rov 3 (JS) ──► ...

Bozordagi bitta kassani tasavvur qiling. Oldingizdagi odam 50 ta mahsulot olgan. Sizda bitta non — lekin baribir kutasiz. Bu muammo Head-of-Line blocking (navbat boshidagi tiqilish) deyiladi.

Brauzerlar bunga qarshi bir saytga parallel 6 tagacha ulanish ochadi — oltita kassa. Lekin 100 ta fayl uchun oltita kassa ham kam. Dasturchilar hiylalarga borishgan: hamma ikonkani bitta katta rasmga yig'ish, hamma JS'ni bitta ulkan faylga birlashtirish.

3. HTTP/2: bitta ulanish, ko'p oqim

HTTP/2 2015-yilda standart bo'ldi. U HTTP'ning ma'nosini o'zgartirmadi: metodlar, sarlavhalar, status kodlari o'sha-o'sha. O'zgargani — xabarlar simda qanday uzatilishi.

3.1 Binar freymlar

HTTP/1.1 xabari — oddiy matn. HTTP/2 da har bir xabar kichik binar bo'laklarga — freymlarga (frame) bo'linadi. Har freymda "men qaysi so'rovga tegishliman" degan raqam bor. Bu raqamli yo'lak oqim (stream) deyiladi.

Matn o'rniga binar — kompyuter uchun o'qish osonroq va xatosizroq. Siz esa buni sezmaysiz ham: DevTools va curl baribir odatiy sarlavhalarni ko'rsatadi.

3.2 Multiplexing

Freymlarda oqim raqami bo'lgani uchun, turli so'rovlarning freymlari bitta ulanishda aralash yurishi mumkin. Qabul qiluvchi ularni raqamga qarab ajratib yig'ib oladi:

HTTP/2, bitta ulanish:
──► [CSS 1] [JS 1] [Rasm 1] [CSS 2] [JS 2] ──►
◄── [JS 1] [CSS 1] [Rasm 1] [JS 2] [CSS 2] ◄──

Bu multiplexing (bir kanalda ko'p oqim) deyiladi. Endi katta rasm kichik CSS'ni kutib turmaydi — ikkalasi baravar keladi. Olti ulanish ham kerak emas — bittasi yetadi.

Hayotdan o'xshatish: bitta yuk mashinasiga turli do'konlarning qutilari aralash yuklangan. Har qutida do'kon raqami yozilgan. Manzilda ularni raqamiga qarab ajratishadi.

3.3 Sarlavhalarni siqish

Har so'rovda deyarli bir xil sarlavhalar ketadi: User-Agent, Accept, Cookie. 100 ta so'rovda — 100 marta. HTTP/2 HPACK usuli bilan ularni siqadi: bir marta yuborilgan sarlavha keyingi safar qisqa raqam bilan almashtiriladi.

Yana bir farq: HTTP/2 da sarlavha nomlari doim kichik harf bilan yoziladi (content-type). Sarlavhalar darsida aytganimizdek, ma'nosi o'zgarmaydi.

Maslahat: Brauzerlar HTTP/2 ni faqat HTTPS ustida ishlatadi. Shifrlanmagan http:// sayt har doim HTTP/1.1 bilan ochiladi.

Tekshirib ko'ring: HTTP/2 da nega brauzer bir saytga 6 ta ulanish ochmaydi?

4. HTTP/3 va QUIC

4.1 TCP darajasidagi tiqilish

HTTP/2 navbatni HTTP darajasida yo'q qildi. Lekin pastda — TCP'da — muammo qoldi.

TCP darsidan eslang: TCP ma'lumotni qat'iy tartibda yetkazadi. Bitta paket yo'qolsa, TCP undan keyingi hamma paketni ushlab turadi — yo'qolgani qayta kelguncha. HTTP/2 da bitta TCP ulanishda 30 ta fayl oqyapti. Bitta paket yo'qolsa — 30 tasi ham to'xtaydi. Holbuki yo'qolgan paket faqat bitta rasmga tegishli edi.

Yaxshi simli internetda bu kam sezildi. Lekin telefonda, zaif mobil internetda paketlar tez-tez yo'qoladi.

4.2 QUIC — UDP ustidagi yangi transport

Yechim radikal bo'ldi: TCP'dan voz kechish. QUIC bilan TCP darsida qisqa tanishgan edik: u UDP ustida ishlaydi va TCP'ning kerakli ishlarini (ishonchli yetkazish, qayta yuborish) o'zi bajaradi. Endi asosiy tafsilot: u buni har bir oqim uchun alohida qiladi.

HTTP/3 (2022-yilda standart bo'lgan) — QUIC ustidagi HTTP. U nimani yaxshiladi:

• Oqimlar mustaqil. Bitta rasmning paketi yo'qolsa, faqat o'sha rasm kutadi. Qolganlari oqishda davom etadi.
• Tezroq ulanish. QUIC ichida TLS 1.3 o'rnatilgan. TCP va TLS salomlashuvi alohida emas, bitta borib-kelishda birga bajariladi. Saytga qayta kirganda esa ma'lumotni birinchi paketdayoq yuborish mumkin. Bu 0-RTT deyiladi: RTT (round-trip time) — borib-kelish vaqti, 0-RTT — "borib-kelishni kutmasdan".
• Tarmoq almashsa ham ulanish saqlanadi. Uydan chiqdingiz — telefon Wi-Fi'dan mobil internetga o'tdi, IP manzil o'zgardi. TCP ulanish uziladi. QUIC ulanishni IP bo'yicha emas, o'z raqami bo'yicha taniydi va davom etadi.

Google, YouTube, Facebook, Cloudflare ortidagi saytlar HTTP/3 ni allaqachon ishlatadi. Zamonaviy brauzerlarning hammasi uni qo'llaydi.

Tekshirib ko'ring: Nega HTTP/3 aynan telefon foydalanuvchilariga ko'proq foyda beradi?

5. Versiya qanday tanlanadi?

5.1 ALPN — TLS ichidagi kelishuv

Brauzer serverga ulanganda, server qaysi HTTP versiyasini bilishini qayerdan biladi? So'rab ko'radi — TLS salomlashuvi vaqtida. ClientHello ichida brauzer ro'yxat yuboradi: "men h2 va http/1.1 ni bilaman". Server bittasini tanlaydi. Bu kengaytma ALPN (Application-Layer Protocol Negotiation — ilova protokolini kelishish) deyiladi.

h2 — HTTP/2 ning qisqa nomi. HTTPS darsidagi curl -v chiqishida ALPN qatorlarini ko'rgan edik:

* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1

Nega bu yerda HTTP/1.1? Windows bilan keladigan curl (Git Bash ichidagisi ham) HTTP/2 qo'llovisiz yig'ilgan — u faqat http/1.1 ni taklif qiladi. Server ham shuni tanladi.

Git Bash'dagi openssl bilan ikkala versiyani taklif qilib ko'ramiz:

echo | openssl s_client -connect example.com:443 \
  -servername example.com -alpn h2,http/1.1 2>/dev/null \
  | grep ALPN

Natija:

ALPN protocol: h2

Ikkalasi taklif qilinsa — server HTTP/2 ni tanlaydi. Brauzer ham xuddi shunday qiladi. Linux va macOS'dagi curl odatda HTTP/2 ni qo'llaydi — u yerda curl -I chiqishi HTTP/2 200 bilan boshlanadi.

5.2 HTTP/3 ga qanday o'tiladi: Alt-Svc

HTTP/3 boshqa transportda (UDP) ishlaydi. Brauzer serverning HTTP/3 bilishini oldindan bilmaydi. Shuning uchun birinchi so'rov odatda HTTP/2 (TCP) bilan ketadi. Server esa javobiga TCP darsida ko'rgan sarlavhani qo'shadi:

Alt-Svc: h3=":443"; ma=2592000

Alt-Svc — "Alternative Service", "muqobil xizmat": "HTTP/3 (h3) ham 443-portda bor, 30 kun eslab qol." Brauzer eslab qoladi va keyingi so'rovlarni HTTP/3 bilan yuboradi.

6. Real-time: server o'zi xabar yuborishi kerak

Endi ikkinchi muammoga o'tamiz. Malika Telegram'ga o'xshash kichik chat yozmoqchi. Ali xabar yuborsa, u Malikada darhol chiqishi kerak. Lekin HTTP'da Malikaning brauzeri so'ramasa, server unga hech narsa yubora olmaydi. To'rt xil yechim bor — eng oddiysidan boshlaymiz.

6.1 Polling — tez-tez so'rash

Polling (so'rab turish): brauzer har necha soniyada serverdan so'raydi: "Yangi xabar bormi?"

Brauzer: Yangi xabar bormi?  Server: Yo'q.
(3 soniya)
Brauzer: Yangi xabar bormi?  Server: Yo'q.
(3 soniya)
Brauzer: Yangi xabar bormi?  Server: Ha, Alidan: "Salom!"

Uzoq yo'lda mashinadagi bolani eslang: "Yetib keldikmi? — Yo'q. — Yetib keldikmi? — Yo'q..."

Afzalligi — juda oddiy, oddiy HTTP so'rovlari. Kamchiligi — javoblarning ko'pi "yo'q", ya'ni behuda. 10 000 foydalanuvchi har 3 soniyada so'rasa — serverga soniyasiga 3 000 dan ortiq bo'sh so'rov. Xabar ham 3 soniyagacha kechikadi.

6.2 Long polling — javobni ushlab turish

Long polling (uzoq kutish) aqlliroq. Brauzer so'raydi, server esa yangilik bo'lmasa darhol javob bermaydi — ulanishni ochiq ushlab turadi. Xabar kelishi bilan javob beradi. Yoki, masalan, 30 soniyadan keyin "hech narsa yo'q" deydi. Brauzer javob olishi bilan darhol yangi so'rov yuboradi.

Xabar deyarli kechikmay yetadi va bo'sh javoblar kamayadi. Telegram botlari aynan shu usulda ishlashi mumkin: bot getUpdates so'roviga timeout qo'shib yuboradi, Telegram serveri esa yangi xabar kelguncha javobni ushlab turadi. Botlarni kursning backend qismida yozamiz.

6.3 SSE — serverdan uzluksiz oqim

SSE (Server-Sent Events — server yuboradigan hodisalar) — bitta HTTP javob, lekin u tugamaydi. Server ulanishni yopmaydi va yangilik bo'lganda javobga yangi qator yozib qo'shaveradi.

Radioni eslang: bir marta to'lqinga ulanasiz, keyin radio o'zi gapiraveradi. Siz radioga gapira olmaysiz — aloqa bir tomonlama: serverdan brauzerga.

Buni o'z ko'zingiz bilan ko'rish mumkin. Vikipediya o'zidagi har bir tahrirni SSE orqali ochiq efirga uzatadi. -N bayrog'i curl'ga "javobni kelgan zahoti chiqar, yig'ib turma" deydi:

curl -N https://stream.wikimedia.org/v2/stream/recentchange

Terminalda to'xtovsiz yangi qatorlar oqa boshlaydi (qisqartirilgan):

event: message
id: [{"topic":"eqiad.mediawiki.recentchange",...}]
data: {"$schema":"/mediawiki/recentchange/1.0.0",...}

event: message
id: [{"topic":"eqiad.mediawiki.recentchange",...}]
data: {"$schema":"/mediawiki/recentchange/1.0.0",...}

Har bir blok — bitta hodisa: kimdir dunyoning qayeridadir Vikipediya'da nimanidir o'zgartirdi. Oqim to'xtamaydi — Ctrl + C bilan o'zingiz to'xtatasiz.

Javob sarlavhalarida content-type: text/event-stream bor — bu SSE'ning MIME turi. Formati oddiy matn: event:, id:, data: qatorlari va hodisalar orasida bo'sh qator.

Brauzerda SSE'ni EventSource degan tayyor JavaScript vositasi o'qiydi. Ulanish uzilsa, u o'zi qayta ulanadi. Uni WebSocket va SSE darsida ishlatamiz.

SSE qayerda: yangiliklar lentasi, birja narxlari, bildirishnomalar. Yana bir mashhur misol — AI chatlar. ChatGPT yoki Claude javobni so'zma-so'z "yozayotgandek" ko'rsatadi. Ularning API'lari javobni aynan SSE oqimi bilan yuboradi.

6.4 WebSocket — ikki tomonlama kanal

WebSocket — brauzer va server orasidagi doimiy, ikki tomonlama kanal. Ikkala tomon ham xohlagan paytda xabar yubora oladi. SSE radio bo'lsa, WebSocket — telefon qo'ng'irog'i: ikkalangiz ham gapirasiz va eshitasiz.

WebSocket oddiy HTTP so'rovi bilan boshlanadi. Brauzer "keling, WebSocket'ga o'tamiz" deydi:

GET /chat HTTP/1.1
Host: example.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

Upgrade — "yangilash, boshqa protokolga o'tish". Server rozi bo'lsa, javob beradi. Ochiq sinov serveri echo.websocket.org ning haqiqiy javobi:

HTTP/1.1 101 Switching Protocols
upgrade: websocket
connection: Upgrade
sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 Switching Protocols — "protokolni almashtiryapman". Bu 1xx oilasidagi kam uchraydigan status kodi. Shu lahzadan boshlab ulanishda HTTP tugaydi. Endi u orqali kichik WebSocket xabarlari ikki tomonga erkin yuradi: matn yoki binar.

WebSocket manzillari o'z sxemasiga ega: ws:// (shifrlanmagan) va wss:// (TLS bilan, xuddi https:// kabi).

Qayerda: chatlar, onlayn o'yinlar, bir hujjatni bir necha kishi birga tahrirlash, taksi ilovasida haydovchining joyi.

6.5 Solishtirish va tanlash

Tanlash uchun oddiy savol: brauzer ham tez-tez xabar yuboradimi?

• Yo'q, faqat server yangilik beradi → SSE. U oddiy HTTP ustida ishlaydi, sozlash oson.
• Ha, ikkala tomon ham tinmay gaplashadi → WebSocket.
• Ma'lumot kamdan-kam o'zgaradi (masalan, ob-havo) → oddiy polling ham yetadi.

Tekshirib ko'ring: Sayt pastki burchagida "Yangi buyurtma keldi" degan bildirishnoma chiqadi. Foydalanuvchi serverga hech narsa yubormaydi. Qaysi usul mos?

7. Ko'p uchraydigan xatolar

7.1 Hamma narsaga WebSocket

"Real-time kerak — demak WebSocket" — keng tarqalgan xato. WebSocket ulanishlarini server alohida boshqaradi, ular oddiy HTTP keshlari va vositalari bilan ishlamaydi. Bir tomonlama oqim uchun SSE oddiyroq va yetarli.

7.2 Juda tez polling

Har 500 millisekundda so'rash — 1 000 foydalanuvchida soniyasiga 2 000 so'rov. Server behuda so'rovlardan "bo'g'ilib" qoladi. Tuzatish: oraliqni oshiring, long polling yoki SSE'ga o'ting.

7.3 HTTP/1.1 dagi SSE va 6 ulanish chegarasi

Sayt SSE ishlatadi va HTTP/1.1 da ishlaydi. Foydalanuvchi uni 7 ta tabda ochdi — yettinchi tab "qotib" qoldi. Sababi: brauzer bitta saytga 6 tadan ortiq ulanish ochmaydi, oltitasini SSE oqimlari band qilgan. Tuzatish: serverni HTTP/2 da ishlating — u yerda hamma oqim bitta ulanishga sig'adi.

7.4 HTTPS sahifada ws://

Sahifa https:// da, WebSocket esa ws:// ga ulanmoqchi. Brauzer uni mixed content sifatida bloklaydi. Tuzatish: wss:// ishlating.

7.5 HTTP/1.1 davri hiylalari

Hamma JS'ni bitta 3 MB faylga yig'ish, hamma ikonkani bitta rasmga birlashtirish — HTTP/1.1 dagi 6 ulanish cheklovi uchun o'ylab topilgan. HTTP/2 da ular foydasini yo'qotadi: bitta kichik o'zgarish uchun butun ulkan faylni qayta yuklash kerak bo'ladi. Fayllarni oqilona bo'laklarga bo'lish afzal. Buni frontend asboblari qismida ko'ramiz.

8. Mashqlar

1-mashq (oson): Protokol ustuni

Chrome'da https://www.youtube.com ni oching, F12 → Network. Jadval sarlavhasi (Name, Status...) ustida sichqonchaning o'ng tugmasini bosing va Protocol ustunini yoqing. Sahifani yangilang.

Qaysi qiymatlarni ko'ryapsiz? Ular nimani bildiradi?

2-mashq (o'rta): Jonli SSE oqimi

Git Bash'da bajaring:

curl -N https://stream.wikimedia.org/v2/stream/recentchange

Bir necha soniya kuzating, keyin Ctrl + C bosing. Savollar:

1. Nega buyruq o'zi tugamadi?
2. Hodisalar bir-biridan qanday ajratilgan?
3. Bu SSE ekanini qaysi sarlavha isbotlaydi? (Ishora: faqat sarlavhalarni ko'rish uchun -I emas, -i ishlating — u sarlavhalarni ham, tanani ham chiqaradi.)

HTTP/1.1 200 OK
content-type: text/event-stream; charset=utf-8
cache-control: no-cache

3-mashq (qiyin): Texnologiyani tanlang

Har bir vazifa uchun usulni tanlang (polling, long polling, SSE yoki WebSocket) va bir gap bilan sababini ayting:

1. Taksi ilovasida yo'lovchi haydovchining xaritadagi joyini ko'radi, haydovchi esa yo'lovchi bilan chatda yozishadi.
2. Valyuta kursi sahifasi: dollar kursi kuniga bir necha marta o'zgaradi.
3. Futbol sayti: gol bo'lsa, hisob darhol yangilanadi.
4. Uchta dasturchi bitta hujjatni bir vaqtda tahrirlaydi.
5. Kichik Telegram bot o'z serveridan yangi xabarlarni oladi.

9. Real ishda

• Frontend: sayt tezligini tahlil qilganda DevTools'dagi Protocol ustuniga qaraysiz. http/1.1 ko'rsangiz — serverda HTTP/2 yoqilmagan, bu oson yutuq.
• Backend va DevOps: HTTP/2 va HTTP/3 odatda Nginx yoki Cloudflare darajasida yoqiladi. Node.js ilovasining o'zi ko'pincha oddiy HTTP/1.1 da qoladi.
• Real-time: chat va bildirishnomalar uchun WebSocket va SSE'ni frontendda ham, backendda ham yozasiz. Socket.IO kabi kutubxonalar WebSocket ustiga qulayliklar qo'shadi — hozir nomini bilish kifoya.
• Intervyu: "HTTP/1.1, 2 va 3 farqi?", "WebSocket va SSE farqi, qachon qaysi biri?" — o'rta darajadagi intervyularda tez-tez so'raladi.

Xulosa

• HTTP/1.1: bitta ulanish — bir vaqtda bitta so'rov; brauzer 6 tagacha ulanish ochadi.
• HTTP/2: binar freymlar va multiplexing — bitta ulanishda ko'p so'rov baravar.
• HTTP/3: QUIC (UDP) ustida; yo'qolgan paket faqat o'z oqimini to'xtatadi, tarmoq almashsa ulanish saqlanadi.
• Versiya TLS ichida ALPN bilan kelishiladi; HTTP/3 haqida brauzer Alt-Svc dan biladi.
• Real-time: polling → long polling → SSE (serverdan oqim) → WebSocket (ikki tomonlama).

Keyingi dars: Origin va Same-Origin Policy — brauzer nega bir saytga boshqa saytning ma'lumotini o'qishga ruxsat bermasligini va CORS bu chegarani qanday ochishini ko'ramiz.