WebSockets і реалтайм

Що таке WebSocket і чим він відрізняється від звичайного HTTP-запиту?

WebSocket — протокол двобічного обміну повідомленнями поверх одного постійного TCP-зʼєднання. У HTTP кожна порція даних коштує окремого циклу «клієнт спитав — сервер відповів», і сервер не має способу заговорити першим: він лише реагує на те, що до нього прийшло. WebSocket знімає цю асиметрію всередині вже відкритого каналу — обидві сторони шлють дані тоді, коли їм є що сказати. Друга відмінність суто економічна: заголовки, кукі й автентифікація їдуть один раз, під час відкриття каналу, а не з кожним повідомленням. Межа теж важлива, і сильна відповідь її називає: HTTP нікуди не дівається, він потрібен рівно один раз — щоб канал відкрити, — і відкриває канал усе одно клієнт. Для тестування наслідок прямий: звична схема «зробив запит — перевірив відповідь» тут не працює, бо запиту немає.

Навіщо знадобився WebSocket, якщо реалтайм можна зробити полінгом?

Полінг (polling) реалтайм не робить, а імітує, і платить за це двічі. Перша ціна — накладні витрати: кожні N секунд іде повноцінний HTTP-цикл із заголовками, кукі й автентифікацією, а маса таких циклів повертає «нічого нового». Друга — затримка: подія, що сталася одразу після опитування, чекатиме наступного. long polling із затримкою майже справляється — сервер притримує запит, поки не назбирається що віддати, — але й тут кожне повідомлення означає закритий цикл і відкритий наступний. Специфікація WebSocket описує цю практику різко: імітувати двобічний обмін через HTTP — зловживання протоколом, і мета нового протоколу сформульована саме як обмін в обидва боки без купи HTTP-зʼєднань і long polling.

Як виглядає відкриття WebSocket-зʼєднання? Які заголовки й статус там беруть участь?

У протоколі дві фази: спершу сторони домовляються — це рукостискання (handshake), — і лише потім починається обмін даними. Домовляються звичайним HTTP-запитом GET, у якому їдуть три заголовки: Upgrade: websocket, Connection: Upgrade і Sec-WebSocket-Key. Рішення суто практичне: завдяки йому той самий порт приймає і звичайні HTTP-запити, і запити на відкриття каналу, окремої точки входу заводити не треба. Успіхом вважається рівно одна відповідь — 101 Switching Protocols із заголовком Sec-WebSocket-Accept. Після цієї відповіді HTTP-семантика на цьому зʼєднанні закінчується: далі йде самостійний протокол поверх того самого TCP.

Апгрейд повернув не 101, а 200, 401 або 404. Що це означає для діагностики?

Що каналу немає й шукати кадри марно — далі діє звичайна семантика HTTP, тобто діагностика така сама, як для будь-якого запиту. 401 — сервер не пустив через автентифікацію: перевіряй токен чи кукі, з якими сторінка відкриває зʼєднання. 404 — такого шляху на сервері немає: типово переплутаний ендпоінт або не те середовище. 200 означає, що сервер обробив звернення як звичайний запит і каналу не відкрив, тобто про апгрейд ніхто не домовився: перевіряй, чи запит справді пішов із заголовками апгрейду й чи цей шлях узагалі очікує WebSocket. Практичне правило для звіту про дефект: спершу назви статус рукостискання, і половина гіпотез відпаде сама. Формулювання «WebSocket зламаний» без цього статусу нічого не діагностує.

У чому різниця між ws і wss?

Це дві схеми адрес того самого протоколу: ws за замовчуванням іде на порт 80, wss — на 443 і поверх TLS. Різниця змістовна: під TLS канал отримує рівно той набір властивостей, що й HTTPS, — сервер доводить, що він саме той, за кого себе видає, вміст закритий від сторонніх, а підміна даних дорогою помітна. Посередник на шляху бачить IP-адресу й доменне імʼя (воно їде відкрито в SNI під час рукостискання TLS), але вміст кадрів для нього закритий. По ws:// вміст повідомлень читається відкрито будь-ким на шляху, тому для будь-чого, що містить токени чи дані користувача, вибір фактично один. В адресі схема стоїть на тому самому місці, що http чи https, і живе за тими самими правилами.

Чому зі сторінки на HTTPS не працює ws://?

Бо сторінка, відкрита по https, — захищений контекст, а незахищений підресурс із неї є змішаним контентом (mixed content). Далі йде деталь, на якій усе й тримається: такий вміст ділиться на дві категорії — той, що браузер мовчки переписує на захищену схему, і той, що просто ріжеться. Перша категорія вузька: лише картинки, аудіо й відео, підключені через атрибут src, та фонові зображення з CSS. Усе інше автоматично потрапляє в другу, і WebSocket разом з ним. Тому ws:// не «підтягнеться» до wss:// мовчки — його просто заблокують. Слід завжди лишається в консолі браузера: він пише і про автоматичне оновлення схеми, і про блокування. Правильна відповідь тут не переказує правило, а звʼязує його зі змішаним контентом.

Чому дефект зі змішаним контентом доїжджає до продакшену, хоча локально все працювало?

Бо локальні адреси браузер вважає захищеними походженнями: file:, а також петльові http://localhost/ і http://127.0.0.1/. На стенді розробника блокування просто не вмикається, і той самий код виглядає робочим. Тому перевіряти змішаний контент треба на середовищі з реальним доменом і https, а не на локальному запуску. Є ще окрема пастка внутрішніх середовищ: коли стенд відкривають за IP-адресою замість доменного імені, блокується навіть той запит, який зазвичай був би оновлюваним. Практичний висновок для QA: «на localhost працює» — не аргумент у тікеті про реалтайм, і в чеклист середовищ варто закладати перевірку саме на домені.

Що таке кадр і чому до нього не можна застосувати схему «запит-відповідь»?

Коли рукостискання позаду, обмін іде окремими кадрами (frames). Кадр не несе службових атрибутів HTTP — у ньому немає ні методу, ні шляху, ні коду відповіді, — а найважливіше те, що йому нічого не відповідає у зворотний бік: сервер відправляє кадр з власної ініціативи, а не тому, що його про це попросили. Звідси головна складність тестування реалтайму: немає номера запиту, за яким можна дочекатися «своєї» відповіді. Наслідок для автотестів — чекати треба на спостережуваний наслідок кадру (змінився статус на екрані, зʼявилося повідомлення в списку), а не на сам факт обміну й тим паче не на секунди. Це ж пояснює, чому реалтайм-тести так легко стають flaky, коли в них зашивають фіксовану паузу.

Навіщо клієнт маскує кадри й чи означає це, що вони зашифровані?

Не означає — це найпоширеніша плутанина в темі. За специфікацією клієнт накладає на кожен кадр, що йде до сервера, випадковий 32-бітний ключ, а серверу така операція заборонена. Мета — не приватність, а захист проміжних вузлів: маскування не дає скрипту сформувати такі байти, які проксі помилково прочитає як HTTP-запит і, наприклад, покладе собі в кеш. Від підслуховування захищає TLS, тобто wss, а не маскування: по ws:// вміст кадрів іде відкрито, попри всі ключі. Асиметрія тут теж змістовна — ризик підробки створює саме браузерний клієнт, тому вимога адресована йому.

Що таке Ping і Pong у WebSocket і чому в трафіку продукту частіше видно власний heartbeat?

Ping і Pong — керівні кадри, вбудований механізм підтримання зʼєднання живим. Отримавши Ping, сторона зобовʼязана повернути Pong з ідентичним вмістом — виняток один: якщо до неї вже прийшов кадр Close. Нюанс, який відрізняє відповідь «з практики» від переказу специфікації: браузерний API не дає керувати цими кадрами з JavaScript. Тому команди роблять keepalive власноруч — звичайними повідомленнями за таймером, — і саме їх видно у вкладці з кадрами. Практичний наслідок: регулярні однакові повідомлення в трафіку — часто не логіка продукту, а keepalive, і асерти на «кількість отриманих повідомлень» об нього спотикаються.

Які стани має WebSocket-обʼєкт на клієнті?

Зʼєднання з боку сторінки видно як обʼєкт із властивістю readyState, що приймає чотири значення: CONNECTING (0), OPEN (1), CLOSING (2), CLOSED (3). До них додаються чотири події, на які вішають обробники: open, message, error і close. Для тестування корисні дві речі. Перша: між створенням обʼєкта й станом OPEN є проміжок, тому «сторінка завантажилась» не дорівнює «канал відкритий» — саме тут живе частина гонок у ранніх асертах. Друга: код закриття приходить в обробник close, тому саме звідти беруть діагностику, коли зʼєднання впало.

Що означає код закриття 1006 і чим він відрізняється від 1000 та 1001?

1000 і 1001 — коди нормального закриття, вони справді приїжджають у кадрі Close: перший означає, що зʼєднання виконало своє призначення, другий — що сторона «йде» (сервер вимикається або користувач пішов зі сторінки). 1006 — інша природа: це зарезервоване значення, яке заборонено ставити в кадр Close, і по мережі воно не передається ніколи. Його виставляє локальна реалізація на клієнті, коли зʼєднання закрилося ненормально — тобто прощального кадру не було взагалі. Типові причини: зникла мережа, помер процес на бекенді, проксі закрив зʼєднання, яке довго мовчало. Тому фраза «сервер закрив нас із кодом 1006» некоректна: це діагноз стану каналу, а не слова сервера, і шукати треба мережу й інфраструктуру.

Хто відповідає за перепідключення і що таке backoff?

Протокол цим не займається — перепідключення пише застосунок. Специфікація адресує клієнту рекомендацію: після аварійного закриття не ломитися одразу, а нарощувати паузу (backoff), причому перший повтор зсувати на випадкову величину, а кожен наступний відкладати довше — класична схема тут зветься урізаним двійковим експоненційним нарощуванням. Сенс саме в цьому: якщо сервер щойно впав, синхронний натовп клієнтів, які повторюють спробу однаково й одразу, доб'є його ще раз. Для QA це окремий предмет перевірки, а не деталь реалізації: дивимося, чи клієнт узагалі пробує знову, чи інтервали ростуть і чи немає шторму запитів у мережевій панелі. Випадкова складова в першій паузі — теж частина правильної відповіді, бо без неї всі клієнти прокидаються синхронно.

Що успадковує нове зʼєднання після перепідключення?

Нічого. Механізму «продовжити стару сесію» у протоколі немає: після розриву відбувається повне нове рукостискання, і це інше зʼєднання. Отже, автентифікацію, підписки на канали чи кімнати, стан «на що я підписаний» відновлює сам застосунок — і саме тут ховаються найдорожчі дефекти реалтайму. Перевіряти треба не факт «сокет знову живий», а поведінку продукту: чи ожили підписки, чи не випали з історії повідомлення, надіслані в момент обриву, чи не видає інтерфейс старі дані за свіжі. «Зʼєднання відновилося» і «застосунок працює як раніше» — два різні твердження, і тест має перевіряти друге.

Які гарантії WebSocket отримує від TCP і де вони закінчуються?

WebSocket не винаходить транспорт, а лягає поверх TCP і бере гарантії звідти. Транспорт дає впорядкований і надійний потік байтів: пропажу він помічає за номерами послідовності й контрольними сумами, лікує повторною відправкою, а заразом стримує швидкість під час перевантаження; саме зʼєднання встановлюється в три кроки й далі впізнається за парою сокетів. Звідси перший наслідок: порядок кадрів у межах одного зʼєднання гарантований транспортом, тому «повідомлення переплуталися в мережі» — малоймовірна гіпотеза. Другий наслідок важливіший: гарантія живе рівно стільки, скільки живе зʼєднання. Надійність означає виявлення втрат і повторну передачу в живому каналі, а не обіцянку, що канал доживе до кінця сценарію, — тому все цікаве для QA починається на розриві. Для контрасту: UDP працює без зʼєднання й без цих гарантій, зате з мінімальними накладними витратами.

Повідомлення в чаті іноді відображаються не в тому порядку. Де шукати причину?

Насамперед — не в мережі. Порядок кадрів у межах зʼєднання забезпечує транспорт, тож найімовірніший винуватець — застосунок: фронтенд отримав два оновлення одного обʼєкта підряд і обробив їх асинхронно, наприклад дочекавшись відповіді на супутній HTTP-запит або вставивши елемент після рендера. Друга типова причина — перепідключення посеред сценарію: після нового рукостискання це вже інше зʼєднання, і те, що прийшло до розриву й після нього, може зійтися в інтерфейсі непередбачувано. Тому в тікеті варто одразу фіксувати, чи був розрив, і додавати кадри з мережевої панелі — це відрізняє «фронтенд переставив» від «сервер надіслав у такому порядку».

Коли краще SSE, а коли WebSocket?

Критерій один — чи потрібен зворотний канал. Server-Sent Events (SSE) везе дані лише в один бік — від сервера до клієнта: браузер відкриває потік через EventSource, відповідь іде з типом text/event-stream, і відправити щось назад цим самим каналом не вийде. Якщо задача — стрічка оновлень, нотифікації чи прогрес довгої операції, SSE простіший і має вбудований козир: відновлюється він сам силами браузера, а тривалість паузи сервер задає полем retry; обірвати потік назовсім може лише явний виклик .close(). Якщо клієнт має відповідати в тому ж каналі — чат, спільне редагування, ігри — потрібен WebSocket, але перепідключення тоді доводиться писати руками. Плюсом до відповіді йде обмеження, про яке часто забувають: поки з'єднання йдуть без HTTP/2, на один домен браузер дозволяє не більше шести таких потоків, і рахунок ведеться на всі вкладки разом; HTTP/2 ліміт не скасовує, а робить узгоджуваним, із типовим значенням 100.

Як подивитися WebSocket-трафік у DevTools?

У вкладці Network серед фільтрів за типом ресурсу є кнопка WS — вона лишає тільки WebSocket-зʼєднання. Ключове, що дивує новачків: у списку буде єдиний рядок, і це рукостискання з кодом 101, — а кадри туди не потрапляють зовсім: хоч тисяча повідомлень, рядок усе одно залишиться один. Щоб побачити самі повідомлення, треба клацнути URL зʼєднання й відкрити вкладку Messages: там таблиця останньої сотні кадрів із даними, довжиною й часом, а напрямок кодує колір рядка — те, що пішло від сторінки, підсвічене зеленим, вхідне лишається білим. Обмеження в сто рядків варто памʼятати під час довгих сесій: ранні кадри просто витісняються. Тротлінг мережі в сучасних версіях DevTools діє й на WebSocket, тож поведінку на повільному звʼязку можна відтворити звідти ж.

Як ти тестуватимеш чат?

Розкладу задачу на чотири групи перевірок, бо всі вони випливають із механіки протоколу. Доставка: повідомлення дійшло тому клієнту, якому призначене, і не дійшло сторонньому — ставиться це на двох сесіях одночасно, коли діємо в першій, а результат дивимося в другій. Порядок: два оновлення одного обʼєкта підряд не мають переставлятися в інтерфейсі, і шукати причину тут треба у фронтенді, а не в мережі. Перепідключення: після обриву клієнт має повторювати спробу з наростаючою паузою, а не влаштовувати шторм запитів. Стан після розриву: підписки повернулися, повідомлення з моменту обриву не загубилися, інтерфейс не показує застаріле як актуальне. Окремо назву дисципліну очікувань: чекаю на наслідок кадру в інтерфейсі, а не на фіксовану кількість секунд, бо жорстка пауза або зайва, або замала.

Реалтайм-тести зелені поодинці й падають у паралельному прогоні. З чого почнеш?

З ізоляції стану, а не з таймаутів. Одне WebSocket-зʼєднання тримає підписки й чергу повідомлень, тому реалтайм-тести особливо чутливі до того, що залишив по собі попередній тест: залогінений користувач, відкрита кімната, недоставлені повідомлення. Свіжий контекст браузера на кожен тест зазвичай дешевший за полювання на протікання стану. Друга підозра — спільні дані: два тести працюють з тією самою кімнатою чи тим самим користувачем і бачать чужі повідомлення як свої. Третя — очікування: якщо в тесті є фіксована пауза, під навантаженням у CI вона просто перестає вистачати, і тоді падіння виглядає випадковим, хоча причина детермінована. Збільшення таймаута тут лікує симптом і ховає справжню гонку.

Три кейси з робочого життя QA: тріаж скарги «реалтайм не працює» за мережевою панеллю, тест доставки повідомлення двома паралельними сесіями в Playwright і перевірка того, що застосунок переживає розрив каналу. Скрізь — що дивитися і який висновок з цього випливає.

Кейс 1. Тріаж: «чат не оновлюється» — за пʼять хвилин у DevTools

Приходить скарга: повідомлення зʼявляється лише після перезавантаження сторінки. Перед тим як писати тікет на бекенд, треба відповісти на три питання по черзі — і кожне відсікає половину гіпотез.

Питання 1: канал узагалі відкрився? Відкрий Network, увімкни фільтр WS і перезавантаж сторінку. Зʼєднання займе один рядок — це рукостискання, і в колонці статусу має стояти 101.

Name                    Status   Type    Time
socket?token=eyJhbGci   101      websocket   Pending

Питання 2: якщо не 101 — що саме відповів сервер? Тут працює звичайна діагностика HTTP, бо рукостискання і є звичайний HTTP-запит.

Питання 3: якщо 101 є — чи ходять кадри? Клацни на URL зʼєднання й відкрий вкладку Messages. Памʼятай про дві особливості панелі: у списку запитів кадри рядками не зʼявляються (сто повідомлень не дадуть ста запитів), а сама таблиця тримає лише останню сотню — під час довгої сесії ранні кадри витісняються.

Дві пастки цього тріажу. Перша: 1006 не приходить від сервера — його ставить сама реалізація на клієнті, тому фраза «сервер закрив зʼєднання з кодом 1006» у тікеті одразу веде розслідування не туди. Друга: браузер не «підтягне» ws:// до wss:// мовчки — WebSocket належить до блокованого змішаного контенту, а не до оновлюваного, тож слід шукати в консолі, а не в мережі.

Кейс 2. Playwright: доставка повідомлення двома сесіями

Головна перевірка реалтайму — дія в одній сесії дає наслідок в іншій. Робиться це двома незалежними контекстами браузера: кожен зі своїми кукі й своїм зʼєднанням.

import { test, expect, chromium } from '@playwright/test';

test('повідомлення від Анни зʼявляється в Богдана без перезавантаження', async () => {
  const browser = await chromium.launch();

  // два контексти = дві незалежні сесії й два окремі WebSocket-зʼєднання
  const annaCtx = await browser.newContext({ storageState: 'auth/anna.json' });
  const bohdanCtx = await browser.newContext({ storageState: 'auth/bohdan.json' });
  const anna = await annaCtx.newPage();
  const bohdan = await bohdanCtx.newPage();

  await anna.goto('https://app.example.com/chat/42');
  await bohdan.goto('https://app.example.com/chat/42');

  const text = `привіт ${Date.now()}`;
  await anna.getByTestId('message-input').fill(text);
  await anna.getByTestId('send').click();

  // чекаємо на НАСЛІДОК кадру, а не на секунди
  await expect(bohdan.getByTestId('message-list')).toContainText(text);

  await browser.close();
});

Що дивитися і чому:

• Жодного waitForTimeout. Кадр не має пари, тому очікувати «відповідь на запит» тут нема чого — лишається очікування спостережуваного наслідку. Фіксована пауза буває або зайвою (тест повільніший без причини), або замалою (червоний тест у CI під навантаженням), і третього стану в неї немає.
• Асерт на чужій сторінці — і є перевірка доставки. Якщо перевіряти лише сторінку відправника, тест зеленітиме навіть тоді, коли сервер узагалі нікому нічого не розіслав: свій текст фронтенд часто малює локально ще до підтвердження.
• Негативна половина не менш важлива. Доставка «потрібному клієнту» означає й «не чужому»: третій контекст, відкритий на іншій кімнаті, після цієї дії має лишитися без нового повідомлення. Асерт на відсутність пишеться через not і потребує явного очікування стабільного стану, інакше він проходить просто тому, що кадр ще не встиг прийти.
• Унікальний текст на кожен прогін. Реалтайм-тести особливо чутливі до чужого стану: одне зʼєднання тримає підписки й чергу повідомлень, тож повідомлення від попереднього прогону легко приймається за своє. Таймстемп у тексті прибирає цей клас хибних зелених.
• Свіжі контексти замість спільного профілю. Ізоляція тут дешевша за розслідування: два тести, що працюють з тією самою кімнатою під тим самим користувачем, бачитимуть кадри один одного.

Кейс 3. Розрив каналу: перевіряємо не «зʼєднання відновилося», а «застосунок працює як раніше»

Найдорожчі дефекти реалтайму живуть на перепідключенні. Після обриву відбувається повне нове рукостискання: це інше зʼєднання, яке не успадковує ні автентифікації, ні підписок, — відновлює їх сам застосунок. Розрив у тесті імітується переведенням контексту в офлайн.

test('після розриву каналу оновлення статусу знову доходять', async ({ page, context }) => {
  // підписку ставимо ДО навігації: канал відкривається під час завантаження сторінки
  const wsPromise = page.waitForEvent('websocket');
  await page.goto('https://app.example.com/orders/1001');

  // фіксуємо факт відкриття каналу й ловимо його закриття
  const ws = await wsPromise;
  const closed = new Promise<void>((resolve) => ws.on('close', () => resolve()));

  await context.setOffline(true);
  await closed;
  await context.setOffline(false);

  // головний асерт — не «сокет живий», а поведінка продукту
  await expect(page.getByTestId('order-status')).toHaveText('У дорозі');
  await expect(page.getByTestId('connection-banner')).toBeHidden();
});

Коли треба відтворити те, чого на живому сервері на замовлення не викличеш — дубль повідомлення, оновлення в неправильному порядку, мовчання після реконекту, — канал підміняють на рівні тесту. Маршрут реєструють до page.goto(): зʼєднання відкривається під час завантаження сторінки й повз пізніше поставлений маршрут просто проскочить.

await page.routeWebSocket('wss://api.example.com/socket', (ws) => {
  ws.onMessage(() => {
    // сервер відповідає рівно тим, що потрібно сценарію
    ws.send(JSON.stringify({ type: 'order.status', value: 'У дорозі' }));
  });
});

Що дивитися і чому:

• Перевіряти треба стан, а не факт зʼєднання. «Сокет знову живий» і «продукт поводиться як до обриву» — це різні речі. Предмет асерту: чи повернулися підписки, чи не загубилися оновлення з моменту обриву, чи не показує інтерфейс застаріле як актуальне. Зелений readyState цього не доводить.
• Шторм перепідключень видно в панелі. Правильний клієнт нарощує паузу між спробами й перший інтервал робить випадковим; ряд однакових спроб через рівні короткі проміжки — готовий дефект, бо в проді такі клієнти доб'ють сервер, що тільки піднімається. Це перевірка не «на око»: рядки спроб у Network мають розходитися в часі.
• Код закриття підказує сценарій. Примусовий офлайн — це саме аварійне закриття: прощального кадру немає, тож в обробнику close буде 1006. Код 1001 приходить тоді, коли інша сторона встигла попрощатися — деплой, перезапуск, вихід зі сторінки. Для тесту стану різниці немає, для звіту про дефект — є.
• Мок перевіряє фронтенд, а не інтеграцію. Підміна каналу дає керовані сценарії розриву, але з нею тест уже нічого не каже про реального сервера. Розумний набір комбінує: живий канал для основних сценаріїв доставки, мок — для розривів, дублів і поламаного порядку.
• Асерти безпосередньо на кадри — найкрихкіший варіант. Вони привʼязуються і до формату повідомлень, і до таймінгу одночасно, тож ламаються від будь-якої зміни контракту. Читати кадри корисно для діагностики, ставити на них головний асерт функціонального тесту — ні.

Навіщо WebSocket і що саме він змінює

• Можу пояснити, чому схеми «запит — відповідь» не вистачає для реалтайму: сервер не має способу заговорити першим, а зміщується лише ініціатива всередині каналу — відкриває зʼєднання все одно клієнт.
• Знаю ціну полінгу (polling) і long polling: порожні цикли із заголовками, кукі й автентифікацією, затримка до наступного опитування, а в long polling — закриття циклу на кожне повідомлення.

Рукостискання й апгрейд

• Памʼятаю склад рукостискання (handshake): звичайний GET із заголовками Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key — і що єдина ознака успіху це 101 разом із Sec-WebSocket-Accept, після чого HTTP на зʼєднанні вичерпується й заголовки з кожним повідомленням більше не їдуть.
• Можу пояснити, що будь-який інший код читається за звичайною семантикою HTTP: 401 — відмова автентифікації, 404 — немає шляху, 200 — про апгрейд ніхто не домовився, і кадрів у всіх трьох випадках не буде.

ws проти wss і змішаний контент

• Знаю різницю схем: ws за замовчуванням іде на порт 80, wss — на 443 і поверх TLS, тобто отримує набір властивостей HTTPS: підтверджену особу сервера, закритий від сторонніх вміст, помітну підміну даних.
• Можу пояснити, чому з https-сторінки ws:// не працює: це змішаний контент (mixed content), причому не оновлюваний, а блокований — і чому дефект не видно на localhost, який вважається захищеним походженням.

Кадри, маскування й keepalive

• Розумію, що кадр (frame) не несе службових атрибутів HTTP — жодного методу, шляху чи коду відповіді — і, головне, не має пари: сервер відправляє його з власної ініціативи.
• Знаю асиметрію маскування — клієнт накладає на кожен свій кадр випадковий 32-бітний ключ, серверу така операція заборонена — і не плутаю його із шифруванням: від підслуховування рятує лише wss.
• Памʼятаю, що Ping/Pong — вбудований keepalive із обовʼязковою відповіддю тими самими даними, але браузерний API ними не керує, тому в трафіку видно власний heartbeat застосунку.
• Знаю чотири стани readyState (CONNECTING, OPEN, CLOSING, CLOSED) і чотири події — open, message, error, close.

TCP під каналом

• Розумію, що порядок кадрів у межах зʼєднання забезпечує транспорт, але гарантія живе рівно стільки, скільки живе саме зʼєднання: розрив її скасовує.

Закриття й перепідключення

• Знаю різницю нормального закриття (кадр Close з кодом: 1000 — призначення виконано, 1001 — сторона йде) і аварійного, де прощального кадру не було взагалі.
• Можу пояснити 1006: його заборонено ставити в кадр Close, по мережі він не ходить, його виставляє локальна реалізація — це діагноз обриву, а не слова сервера.
• Розумію, що перепідключення пише застосунок, а не протокол, і що правильна схема — бекоф (backoff) із випадковою першою затримкою, інакше клієнти доб'ють сервер синхронним натовпом.
• Памʼятаю, що механізму «продовжити сесію» немає: і після обриву, і після перезавантаження сторінки це нове зʼєднання з новим рукостисканням, тому автентифікацію й підписки відновлює сам застосунок, а стан реалтайму в тесті починається з нуля.

Сусіди по темі: SSE і полінг

• Знаю, що Server-Sent Events (SSE) везе дані лише в один бік — від сервера до клієнта — через EventSource, з типом відповіді text/event-stream і вбудованим у браузер відновленням потоку.
• Можу сформулювати критерій вибору: є що слати назад — WebSocket; потрібні лише оновлення від сервера — SSE, але з памʼяттю про ліміт зʼєднань: без HTTP/2 їх шість на домен і спільні вони на всі вкладки разом, а HTTP/2 ліміт не знімає, лише робить узгоджуваним.

DevTools і що перевіряє QA

• Знаю, що у списку запитів зʼєднання займає рівно один рядок зі статусом 101, скільки б повідомлень не пройшло, а самі кадри дивляться у вкладці Messages після фільтра WS.
• Можу розкласти тестування реалтайму на чотири предмети — доставка потрібному клієнту, порядок, поведінка при перепідключенні, стан після розриву — і памʼятаю, що доставку перевіряють двома сесіями.
• Знаю правило очікувань: кадр не має пари, тому тест чекає на наслідок в інтерфейсі, а не на фіксовану паузу, яка або зайва, або замала.