WebSocket nima: ta’rif va nima uchun kerak
WebSocket — server va brauzer (yoki boshqa mijoz) o‘rtasida bitta TCP ulanish doirasida doimiy, ikki tomonlama (full-duplex) aloqa kanali o‘rnatadigan protokol.
U HTTP kabi “so‘rov yuborib, javob kutish” modelidan farq qiladi: ulanish ochilgach, har ikki tomonda istalgan payt xabar yuborish mumkin.
HTTP’dan farqi: uzun so‘rovlar, polling va real taqqoslash
HTTP/1.1’dagi odatiy ishlashda mijoz resurs so‘raydi, server javob qaytaradi; yangi xabar kelishi uchun yana so‘rov qilishga to‘g‘ri keladi. Bu “polling”ga olib keladi: mijoz ma’lum oraliqda so‘raydi.
WebSocket’da esa TCP ulanish saqlanib qoladi, shuning uchun server ham, mijoz ham bir xil ulanishdan xabar almasha oladi.
| Yondashuv | Qanday ishlaydi | Asosiy cheklov | WebSocket bilan farqi |
|---|---|---|---|
| Polling (tez-tez so‘rash) | Mijoz vaqt oralig‘ida so‘rov yuboradi | Keraksiz so‘rovlar va kechikish | Server o‘zi xabar yuboradi, so‘rov shart emas |
| Long-polling | So‘rov serverda “kutish”ga o‘tadi, javob kelishi bilan tugaydi | Doimiy qayta ulanish va og‘ir sessiya boshqaruvi | Ulanish uzilmaguncha doimiy kanal |
| Server-Sent Events (SSE) | Server mijozga bir yo‘nalishda yuboradi | Mijozdan serverga xabar yo‘q yoki noqulay | Ikkala yo‘nalishda ham xabar almashish |
Texnik asoslar: handshake, URI va xabar kadrlari
WebSocket HTTP bilan boshlangan handshake orqali ishga tushadi: mijoz serverga HTTP so‘rov yuboradi va “Connection” hamda “Upgrade” sarlavhalari bilan WebSocket ga o‘tishni so‘raydi.
Shakllangan ulanishdan keyin ma’lumot “kadr” (frame) ko‘rinishida uzatiladi: har bir xabarga opkod (masalan, matn yoki binar) va uzunlik bilan bog‘liq metama’lumotlar birga keladi.
WebSocket URL sxemalari
WebSocket manzili odatda ws:// yoki wss:// ko‘rinishida bo‘ladi. wss:// amalda TLS orqali himoyalangan WebSocket ulanishini anglatadi.
Masalan, brauzerda ulanish ws://example.com/chat yoki wss://example.com/chat tarzida belgilanadi.
Subprotokollar va sarlavha talablar
Ba’zi tizimlarda WebSocket “subprotocol” ishlatiladi: mijoz Sec-WebSocket-Protocol orqali ro‘yxat (yoki tanlov) yuboradi, server mos keladiganini tanlaydi.
Handshake paytida esa Sec-WebSocket-Key kabi qiymatlar ishlatiladi; bu serverning handshake javobini to‘g‘ri hisoblashini tekshirishga yordam beradi.
Tarix: paydo bo‘lish sababi va qaysi texnologiyalarni almashtirish
WebSocket g‘oyasi oldingi “real-time” yondashuvlar (polling va long-polling) samarasizligi bilan bog‘liq holda shakllangan: kechikish, keraksiz tarmoq yuklamasi va sessiya boshqaruvi murakkabligi muammo bo‘lgan.
Protokol spetsifikatsiyasi birinchi marta 2011-yillarda standartlash yo‘liga kirgan; brauzerlarni qamrab olish va amaliy integratsiya keyingi yillarda tezlashdi.
Standartlashdagi asosiy nuqtalar
WebSocket protokoli spetsifikatsiyasi sifatida RFC 6455 e’lon qilingan (2011-yil). Bu hujjat protokol handshake, frame formati va ulanishni yopish kabi xatti-harakatlarni aniqlab beradi.
Shundan so‘ng WebSocket’ning brauzerlar va serverlar ekotizimiga kirishi orqali chat, o‘yinlar, real-time monitoring va savdo/auksion kabi yo‘nalishlarda oldingi yondashuvlar ulushini qisqartirdi.
Ishlash mexanizmi: ulanish ochishdan tortib xabar yuborishgacha
WebSocket’da asosiy oqim quyidagicha: mijoz handshake qiladi, ulanish “Upgrade” orqali WebSocket’ga o‘tadi, keyin esa ikkala tomon xabar almasha oladi.
Bu jarayonni ketma-ket tushunish muhim: noto‘g‘ri sozlangan handshake yoki origin/sessiya tekshiruvlari ulanishni to‘xtatib qo‘yishi mumkin.
1) Handshake bosqichi
Mijoz serverga HTTP so‘rov yuboradi, bunda WebSocket ga o‘tish so‘raladi. Server javob qaytarganda, ulanish WebSocket rejimiga o‘tadi.
Natija: HTTP konteksti WebSocket ulanishiga “almashinadi”, endi keyingi almashinuv HTTP javoblar kabi emas, WebSocket frame-lar bilan ketadi.
2) Ulanish davomida xabar formatlanishi
Ulanish ochiq bo‘lganda, xabarlar frame ko‘rinishida yuboriladi. Matn (text) yoki binar (binary) ko‘rinishlari odatda opkod orqali farqlanadi.
Qabul qiluvchi tomonda har bir frame rejalashtirilgan tartibda yig‘iladi va ishlov beriladi; bu esa real-time servislarda barqaror ishlashni ta’minlaydi.
3) Close va qayta ulanish masalasi
WebSocket’ni yopishda tomonlar “close” xabarini almashadi; bu ulanishni tartibli tugatishga yordam beradi.
Amaliyotda mijoz tomon odatda uzilish bo‘lsa qayta ulanishni rejalashtiradi, biroq buni haddan tashqari tez qayta urinish (retry storm) qilmasdan qilish kerak.
Amaliy sozlash: qaysi hollarda WebSocket tanlanadi va tipik xatolar
WebSocket ayniqsa serverdan mijozga tez-tez yangilanishlar kerak bo‘lganda va “har safar so‘rov yuborish” samarasiz bo‘lib qolsa tanlanadi. Chat, real-time dashboard, o‘yin holati sinxronizatsiyasi, live-notifikatsiya kabi holatlar bunga mos.
Lekin sizning protokol talablari va xavfsizlik modeli aniq bo‘lishi kerak: masalan, ulanish davomiyligi, ulanishni cheklash va autentifikatsiya yo‘li.
Tanlash mezonlari (tezkor tekshiruv ro‘yxati)
Xabarlar tez-tez keladimi? Agar “har bir yangilanish uchun HTTP so‘rov” bo‘lsa, WebSocket foyda berishi mumkin.
Ikkala yo‘nalish ham muhimmi? Mijoz serverga ham real-time ma’lumot yuborishi kerak bo‘lsa, WebSocket mos.
Kechikishni kamaytirish kerakmi? Ulanish ochiq turgani uchun kechikish odatda polling’dan past bo‘ladi.
Server tomonda bir nechta ulanishni boshqarish uchun resursingiz yetarlimi? Har bir WebSocket sessiyasi ochiq socket bo‘lib qoladi.
Tipik xatolar
Authni noto‘g‘ri qo‘llash: handshakedan keyin token tekshiruvini kechiktirish uzilishlarga olib kelishi mumkin; odatda ulanish ochilishidan oldin autentifikatsiyani rejalash kerak.
Proxy va reverse proxy sozlanmaganligi: Nginx/servislarda WebSocket uchun maxsus headerlar va vaqt limitlari moslanmasa, ulanish “osilib” qolishi yoki tez uzilishi mumkin.
Origin nazorat qilinmasligi: brauzer xavfsizligi uchun
Origintekshiruvini e’tiborsiz qoldirish xavf tug‘diradi.Retry strategiya yo‘qligi: ulanish uzilganda mijoz darhol cheksiz qayta urinsa, serverga yuk oshadi. Backoff bilan qayta ulanish kerak.
FAQ
WebSocket faqat brauzerdami?
Yo‘q. WebSocket mijoz-server modeli bo‘lib, brauzer hamda serverdan boshqa dasturlar (masalan, mobil ilovalar yoki back-end xizmatlar) ham WebSocket ulanishi o‘rnatishi mumkin.
WebSocket ulanishini HTTP bilan birga ishlatish mumkinmi?
Ha, odatda veb-ilova HTTP’ni sahifa va API uchun ishlatadi, WebSocket esa real-time kadrlar almashinuvi uchun alohida kanal bo‘ladi. Handshake HTTP asosida boshlanadi, keyin esa alohida WebSocket rejimiga o‘tiladi.
WebSocket ishlashi uchun TLS shartmi?
Shart emas, ammo amaliyotda ko‘pincha wss:// tanlanadi. TLS tarmoqdagi ma’lumotning maxfiyligini ta’minlash va “man-in-the-middle” xavflarini kamaytirish uchun ishlatiladi.
HTTP’dagi REST o‘rniga hammasini WebSocketga o‘tkazish kerakmi?
Har doim ham emas. Agar resurslar so‘rov-javob uslubida ishlasa, HTTP REST yetarli bo‘lishi mumkin. WebSocket odatda tez-tez yangilanadigan real-time oqimlar uchun tanlanadi.
Ulanish uzilib qolsa nima bo‘ladi?
Ulanish uzilganda mijoz tomonda “reconnect” logikasi bo‘lishi kerak. Close yoki tarmoq uzilishi sababiga qarab qayta ulanishni kechiktirish (backoff) va holatni tiklash (masalan, so‘nggi xabarlar ketma-ketligi) rejalashtiriladi.
WebSocket’da xabar formati qanday aniqlanadi?
Protokol darajasida xabarlar frame ko‘rinishida va matn/binar kabi turlarda uzatiladi. Sizning dastur darajasida esa (masalan, chat) JSON, soddalashtirilgan binar format yoki boshqa sxema bo‘lishi mumkin; bu sizning ilova dizayningizga bog‘liq.
Xulosa
WebSocket — HTTP’dan keyingi “real-time” ehtiyojlar uchun mo‘ljallangan, bitta ulanishda ikki tomonlama xabar almashishni ta’minlaydigan protokol. U handshake orqali ishga tushadi va keyin frame-lar asosida doimiy kanal beradi.
To‘g‘ri tanlov qilish uchun sizga real-time chastotasi, ikkala yo‘nalishdagi ehtiyoj va server/proxy resurslarini baholash kerak; shunda WebSocket imkoniyatidan aniq foyda olasiz.
