Сети и протоколы
WebSocket: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту WebSocket: upgrade, framing, выбор транспорта, backpressure, переподключение, потолки масштаба и production-сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Ни один не про заучивание определения — каждый отражает решение, которое senior-инженер принимает, пока real-time-сервис деградирует под нагрузкой.
Цель
Убедись, что связываешь upgrade, формат frame, выбор транспорта, backpressure, переподключение и потолки масштабирования в единую операционную модель — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Коллега предлагает открыть сырой TCP-сокет на отдельном порту, чтобы пропустить HTTP-upgrade и 'сэкономить round-trip'. Почему это неверное рассуждение?
Heads-up Обмен key/accept — это один SHA-1-хеш, микросекунды CPU. Он не добавляет round-trip и не является затратой по латентности — он доказывает, что сервер намеренно обработал upgrade, а не отдал закэшированный ответ.
Heads-up Браузеры вообще не могут открывать произвольные сырые TCP-сокеты; WebSocket API существует именно потому, что сырой TCP недоступен JavaScript на странице. Предпосылка невозможна, а не просто непортабельна.
Heads-up Upgrade идёт по уже существующему соединению; 101 — это ответ на тот же GET. Экономить нечего.
Викторина
Completed
Кастомный WebSocket-клиент (вне браузера) шлёт твоему серверу немаскированные frame в стиле server-to-client. Должен ли сервер их принимать и зачем вообще нужен masking?
Heads-up Masking — не шифрование; ключ передаётся открытым текстом в самом frame. Это структурная защита от cache poisoning, и RFC делает её обязательной для client-frame независимо от доверия.
Heads-up Всё наоборот: frame server-to-client никогда не маскируются (same-origin policy и так блокирует их чтение), а frame client-to-server обязаны быть маскированы всегда.
Heads-up Немаскированные frame декодируются тривиально — ключ применять не нужно. Причина отклонять — требование RFC и модель угрозы cache poisoning, а не сбой декодирования.
Викторина
Completed
Дашборд пушит ~5 обновлений в минуту 100k пользователям, которые ничего не шлют обратно. Инженер тянется за WebSocket. Что лучше по умолчанию и почему?
Heads-up 0-5 мс WebSocket против 3-8 мс SSE реально, но бессмысленно при 5 обновлениях в минуту. Это стоит тебе кастомной логики переподключения и риска совместимости с proxy без всякой выгоды для server-push-only потока.
Heads-up Long-polling тоже работает везде, но при 100k пользователей держит 100k открытых запросов и платит ~500 байт заголовков на каждый poll. SSE даёт ту же совместимость с proxy одним эффективным потоком и встроенным переподключением.
Heads-up Здесь один канал на пользователя; мультиплексирование многих stream на клиента решает проблему, которой у этой фичи нет. Это лишняя сложность по сравнению с обычным SSE.
Викторина
Completed
Память broadcast-сервера стабильно растёт под нагрузкой, пока не срабатывает OOM killer; 100 из 10 000 клиентов на медленных мобильных каналах. Каков механизм и первое надёжное исправление?
Heads-up 'Утечка' — это безграничные send queue для клиентов, которые не успевают: ограниченные, намеренные буферы без политики выселения. Перезапуски маскируют симптом; high-water mark лечит причину.
Heads-up GC-паузы удлиняются, потому что heap раздут очередями сообщений — это симптом, а не причина. Ограничение роста очереди убирает раздувание; выбор коллектора вторичен.
Heads-up Больше серверов размазывает тот же дефект; каждый всё равно раздувается от своих медленных клиентов. Без high-water mark и выселения масштабирование вширь лишь откладывает OOM.
Викторина
Completed
Ты раскатываешь новый билд; все 10 миллионов подключённых клиентов отваливаются с кодом 1006 и переподключаются. Клиент использует exponential backoff, но без jitter. Почему сервер всё равно с трудом восстанавливается?
Heads-up Больший backlog поднимает обрыв, но синхронные волны на 10 М всё равно его переполняют. Структурное исправление — десинхронизировать клиентов через jitter, а не поглощать синхронный всплеск.
Heads-up 1006 — аварийное закрытие (нет close frame) — именно тот случай, когда клиентам надо переподключаться. Проблема в том, как они переподключаются, а не подключаться ли вообще.
Heads-up Чистый exponential backoff — это детерминированное удвоение; jitter — отдельная явная рандомизация (например, delay умножается на random(0.5,1.5)), которую надо добавить сверху.
Викторина
Completed
Два WebSocket-сервера за балансировщиком. User A на Server 1 шлёт сообщение в чат, оно должно дойти до User B на Server 2. Sticky sessions включены. Почему одного sticky-роутинга мало и что закрывает разрыв?
Heads-up Stickiness стабильно направляет данного клиента на его собственный сервер; у неё нет механизма доставить сообщение A на другой сервер B. Межсерверный fan-out требует pub/sub.
Heads-up Балансировка по frame разбросала бы состояние одного клиента по серверам и сломала бы in-flight unACK'd state. Stickiness плюс pub/sub — вот связка: stickiness для локальности per-connection state, pub/sub для fan-out.
Heads-up Общая БД хранит сообщения, но не пушит их; сервер без опроса не получает сигнал, что появилась новая строка. Pub/sub (или streams с consumer-ами) даёт сигнал real-time fan-out.
Итог
Сквозная линия юнита — одна операционная модель: upgrade переиспользует существующее соединение, поэтому общая инфраструктура его маршрутизирует; framing и обязательный client masking защищают провод; выбор транспорта (WebSocket против SSE против long-polling) следует за направлением потока данных; backpressure — каноничный сбой, на который отвечает high-water mark; переподключение должно быть с jitter, иначе оно становится thundering herd; а горизонтальный масштаб требует pub/sub для fan-out плюс sticky sessions для per-connection state. Каждый production-инцидент в юните сводится к этим рычагам.