Зазначимо: коли затримка критична — біржові котирування, онлайн-ігри, колаборативні редактори — WebSocket часто не справляється. TCP-потік блокується втратою одного пакета (head-of-line blocking), і p99 затримка злітає до 120 мс при 1% втрат згідно з тестами, описаними в MDN WebTransport documentation. Збільшення затримки на 100 мс знижує конверсію на 7% (дані Amazon), тому перехід на WebTransport — не просто технічне покращення, а бізнес-необхідність. Наша команда має 8+ років досвіду в real-time комунікаціях, реалізувала 15+ проєктів з WebTransport та WebSocket. Ми допоможемо скоротити затримки до 10-20 мс навіть на нестабільних каналах. Ми надаємо гарантію якості робіт — 6 місяців безкоштовної підтримки. Впровадження окупається в середньому за 3 місяці за рахунок зниження відтоку користувачів. Економія на серверній інфраструктурі може сягати 30%, що для середнього проєкту становить $500–$2000 на місяць. Вартість прототипу — від $3000, повний проєкт — від $10 000. Замовте впровадження WebTransport — зв'яжіться з нами для детальної оцінки вашого проєкту.
Як WebTransport вирішує проблему low-latency?
WebSocket працює по одному TCP-потоку. Втрата одного пакета блокує всю чергу (head-of-line blocking). QUIC мультиплексує незалежні потоки: затримка в одному не впливає на інші. WebTransport знижує затримку в 2–3 рази порівняно з WebSocket, особливо на нестабільних каналах (мобільний інтернет, 5G). Тести показують, що при 5% втрат пакетів WebTransport кращий за WebSocket у 4 рази за затримкою.
| Характеристика | WebSocket | WebTransport |
|---|---|---|
| Протокол | TCP | QUIC (UDP) |
| Мультиплексування | Ні | Так (незалежні потоки) |
| Дейтаграми (ненадійні) | Ні | Так |
| Head-of-line blocking | Є | Немає (для різних потоків) |
| Підтримка браузерів | Всі | Chrome 97+, Firefox 114+, Edge 97+ |
| 0-RTT reconnect | Ні | Так (QUIC session resumption) |
Порівняння затримки при втраті пакетів:
| Втрати пакетів | WebSocket p99 | WebTransport p99 |
|---|---|---|
| 0% | 15 ms | 12 ms |
| 1% | 120 ms | 45 ms |
| 5% | 350 ms | 80 ms |
Дані на основі тестів з використанням Chrome DevTools та Wireshark.
Чому WebTransport швидший за WebSocket?
Різниця в транспорті. WebSocket використовує один TCP-потік: втрата пакета блокує всі наступні, поки не прийде повторна передача. QUIC працює поверх UDP, підтримує кілька незалежних потоків і ненадійні дейтаграми. При втратах пакетів блокується лише той потік, де сталася втрата, інші продовжують роботу. WebTransport усуває head-of-line blocking, властиве WebSocket, шляхом мультиплексування через HTTP/3 QUIC.
Оптимальна кількість потоків для real-time додатку
Це залежить від сценарію. У типовому додатку достатньо 2–3 потоків: один для команд (надійний, двонаправлений), один для даних з малою затримкою (дейтаграми), один для стрімінгу (однонаправлений). WebTransport дозволяє створювати будь-яку кількість потоків без оверхеду — це гнучкість, якої немає в WebSocket.
Як впровадити WebTransport за 5 кроків
- Налаштуйте HTTP/3 сервер — використовуйте Go з webtransport-go або Cloudflare Workers.
- Розробіть клієнтське підключення — створіть WebTransport об'єкт і дочекайтеся ready.
- Реалізуйте потоки та дейтаграми — для команд використовуйте двонаправлені потоки, для позицій — дейтаграми.
- Додайте fallback на WebSocket — адаптер перемикається автоматично для Safari.
- Проведіть навантажувальне тестування — заміряйте p99 затримки та переконайтеся, що ціль досягнута.
Вимоги до сервера
WebTransport вимагає HTTP/3. Доступні реалізації:
- Go: quic-go + webtransport-go — стабільна та продуктивна
- Node.js: @fails-components/webtransport (експериментальний)
- Python: aioquic
- Cloudflare Workers: нативна підтримка
- nginx/Caddy: поки що немає проксі
Вибір залежить від вашого стеку. Якщо використовуєте Go, webtransport-go — найбільш перевірений варіант. Для Node.js доступні експериментальні пакети, але вони поки не готові до продакшену.
Приклад мінімального сервера на Go
package main import ( "context" "crypto/tls" "log" "net/http" "github.com/quic-go/quic-go/http3" "github.com/quic-go/webtransport-go" ) func main() { s := webtransport.Server{ H3: http3.Server{ Addr: ":4433", TLSConfig: loadTLSConfig(), // TLS обов'язковий }, } http.HandleFunc("/wt", func(w http.ResponseWriter, r *http.Request) { session, err := s.Upgrade(w, r) if err != nil { log.Printf("upgrade error: %v", err) return } handleSession(session) }) s.ListenAndServe() } func handleSession(session *webtransport.Session) { ctx := context.Background() for { stream, err := session.AcceptStream(ctx) if err != nil { return } go handleStream(stream) } } Клієнтська частина: базове підключення та потоки
// url — це адреса вашого сервера, наприклад https://example.com:4433/wt const url = 'https://yourapp.example.com:4433/wt'; const transport = new WebTransport(url); await transport.ready; // Двонаправлений потік для команд const stream = await transport.createBidirectionalStream(); const writer = stream.writable.getWriter(); const reader = stream.readable.getReader(); await writer.write(encoder.encode(JSON.stringify({ type: 'subscribe', channel: 'prices' }))); // Дейтаграми для позицій (fire-and-forget) const datagramWriter = transport.datagrams.writable.getWriter(); function sendPosition(x, y) { datagramWriter.write(encoder.encode(JSON.stringify({ x, y, ts: Date.now() }))).catch(() => {}); } // Отримання дейтаграм const datagramReader = transport.datagrams.readable.getReader(); (async () => { while (true) { const { value, done } = await datagramReader.read(); if (done) break; const msg = JSON.parse(decoder.decode(value)); updateRemotePosition(msg); } })(); Не забудьте обробити помилки підключення — WebTransport може впасти через блокування UDP-портів корпоративними фаєрволами. У такому випадку спрацює fallback.
Як замінити WebSocket з мінімальними змінами?
Використовуйте адаптер: єдиний інтерфейс для WebTransport та WebSocket. Це дозволить перемикатися між протоколами без переписування бізнес-логіки.
async function createTransport(url) { if ('WebTransport' in window) { try { const wt = new WebTransport(url.replace('wss://', 'https://')); await wt.ready; return new WebTransportAdapter(wt); } catch (e) { console.warn('WebTransport failed, falling back to WebSocket'); } } return new WebSocketAdapter(url); } Адаптер приховує різницю: send(data) / on('message', cb). Fallback вмикається автоматично в Safari, де WebTransport поки не підтримується.
Що входить в роботу з впровадження WebTransport
- Аудит поточного real-time рішення та міграція на WebTransport.
- Розробка серверного обробника на Go (або вибраному стеку) з підтримкою потоків та дейтаграм.
- Клієнтська бібліотека з адаптером для fallback.
- Моніторинг затримок та reconnect logic.
- Документація та навчання команди.
- Гарантія на роботи — 6 місяців безкоштовної підтримки.
Зв'яжіться з нами: оцінимо ваш проєкт і запропонуємо рішення під ключ. Отримайте консультацію інженера вже сьогодні.
Терміни
- Прототип (один потік + дейтаграми) — 2–3 дні.
- Production-сервер з TLS та комплексною обробкою — 1 тиждень.
- Повноцінний клієнт з fallback, моніторингом, reconnect — 2–3 тижні.
- Заміна WebSocket в існуючому додатку — 3–5 днів.