Сети
Сокеты, модели OSI и TCP/IP, IP-адресация, порты, TCP и UDP, HTTP/HTTPS и TLS handshake.
31 вопросов
JuniorТеорияОчень частоЧто такое сокет и какие операции с ним можно выполнять?
Что такое сокет и какие операции с ним можно выполнять?
Сокет — абстракция ОС, один конец двунаправленного канала. TCP: socket() создать; bind() привязать к адресу/порту; сервер listen() + accept(); клиент connect(); send()/recv() для данных; close() освобождает FD. У UDP нет listen/accept/connect (опц.); используют sendto()/recvfrom() с явным peer.
Типичные ошибки
- ✗Забывать вызвать
bind()на сервере передlisten()— ОС не будет знать, какой порт слушать - ✗Воспринимать возвращаемое значение
recv()как null-терминированную строку —recvвозвращает количество байт, а не C-строку; всегда добавляйте null-терминатор вручную или используйте счётчик - ✗Не устанавливать
SO_REUSEADDRна серверном сокете — после перезапуска порт остаётся в состоянии TIME_WAIT иbind()завершается ошибкой примерно на 2 минуты
Уточняющие вопросы
- →В чём разница между блокирующим и неблокирующим сокетом? Как перевести сокет в неблокирующий режим?
- →Что такое
select()/poll()/epoll()и зачем они нужны?
JuniorТеорияОчень частоВ чём разница между TCP и UDP? Когда использовать UDP?
В чём разница между TCP и UDP? Когда использовать UDP?
TCP: с соединением, надёжная упорядоченная доставка, flow+congestion, 3-way handshake, заголовок 20+ Б. UDP: без соединения, best-effort, без порядка и ретрансмиссий, 8 Б, ниже задержка. UDP — задержка > надёжности (игры, VoIP, DNS), надёжность сверху (QUIC/HTTP3), broadcast/multicast. TCP — HTTP, файлы, email.
Типичные ошибки
- ✗Считать, что UDP всегда быстрее — преимущество задержки проявляется только при высокой частоте пакетов или очень малых нагрузках; TCP может быть столь же быстрым при крупной объёмной передаче
- ✗Думать, что UDP 'ненадёжный' и потому бесполезный — UDP является основой HTTP/3 (QUIC), который надёжен, но быстрее TCP в сетях с потерями
- ✗Использовать TCP для broadcast — TCP строго точка-точка; отправляйте UDP-датаграммы на broadcast-адрес (255.255.255.255) или в группу multicast
Уточняющие вопросы
- →Что такое QUIC и как он обеспечивает надёжность поверх UDP?
- →Как DNS-резольвер решает, когда использовать TCP вместо UDP?
MiddleТеорияОчень частоРазница между HTTP и HTTPS.
Разница между HTTP и HTTPS.
HTTP (порт 80) — открытая передача: заголовки, куки, тело видны любому. HTTPS (порт 443) — HTTP поверх TLS: конфиденциальность (шифрование), целостность (MAC), аутентификация (сертификат сервера). Домен виден через TLS SNI и DNS; шифруются только путь, query и тело. HTTPS не защищает от атак уровня приложения — XSS, SQLi.
Типичные ошибки
- ✗Считать, что HTTPS означает безопасность/надёжность сайта — HTTPS только гарантирует, что канал зашифрован; сервер за ним всё ещё может быть вредоносным или скомпрометированным
- ✗Отправлять конфиденциальные данные в параметрах запроса URL через HTTPS — URL может появляться в серверных логах, заголовках Referer и истории браузера даже при шифровании при передаче
- ✗Не реализовывать HSTS — без
Strict-Transport-Securityбраузеры могут быть переведены на HTTP при первом посещении; HSTS принудительно использует HTTPS даже до первого ответа
Уточняющие вопросы
- →Что такое certificate pinning и каковы его риски?
- →Как Let's Encrypt автоматизирует выдачу сертификатов с протоколом ACME?
MiddleТеорияОчень частоКак работает SSL/TLS-рукопожатие?
Как работает SSL/TLS-рукопожатие?
TLS 1.3 (1-RTT): (1) Клиент → ClientHello + key_share + шифры; (2) Сервер → ServerHello + key_share + Certificate + CertificateVerify + Finished; обе стороны выводят ключ из эфемерного DH; (3) Клиент → Finished, трафик шифруется. TLS 1.3 убрал RSA key exchange (forward secrecy обязательна). 0-RTT уязвим к replay.
Типичные ошибки
- ✗Путать SSL и TLS — SSL (2.0, 3.0) устарел и сломан; правильный термин — TLS; 'SSL-сертификат' — устаревшее неверное название для сертификата X.509
- ✗Использовать самоподписанные сертификаты в production без цепочки доверия — клиенты отклоняют их, если явно не добавить CA в хранилище доверия; используйте публичный CA (Let's Encrypt)
- ✗Не проверять статус отзыва CRL/OCSP — скомпрометированный сертификат остаётся доверенным до истечения срока действия, если не проверять отзыв
Уточняющие вопросы
- →Что такое прямая секретность и почему TLS 1.3 делает её обязательной?
- →Чем взаимный TLS (mTLS) отличается от стандартного TLS и когда он используется?
MiddleТеорияОчень частоКак работает трёхэтапное TCP-рукопожатие?
Как работает трёхэтапное TCP-рукопожатие?
1. SYN: клиент шлёт SYN с ISN_c. 2. SYN-ACK: сервер отвечает SYN+ACK, подтверждает ISN_c+1, шлёт ISN_s. 3. ACK: клиент подтверждает ISN_s+1; ESTABLISHED. Закрытие — 4-way FIN (каждая сторона: FIN + ACK). Активно закрывающая сторона в TIME_WAIT (2×MSL, ~60–120 с), чтобы дубликаты не испортили новое соединение на той же пятёрке.
Типичные ошибки
- ✗Думать, что TIME_WAIT — это баг — это намеренный механизм защиты; реальная проблема — исчерпание портов из-за слишком многих короткоживущих соединений
- ✗Считать, что после отправки SYN соединение готово к передаче данных — данные могут передаваться только после полного завершения трёхэтапного обмена
- ✗Путать порядковые номера и номера подтверждения — номер ACK — это следующий ожидаемый байт, а не последний полученный
Уточняющие вопросы
- →Что такое SYN-флуд атака и как её смягчают с помощью SYN cookies?
- →Как TCP Fast Open (TFO) снижает задержку соединения?
JuniorТеорияЧастоСравните HTTP-методы (GET, POST, PUT, PATCH, DELETE) по safety и idempotency.
Сравните HTTP-методы (GET, POST, PUT, PATCH, DELETE) по safety и idempotency.
Safe (без изменения состояния): GET, HEAD, OPTIONS. Idempotent (повтор = эффект одного вызова): GET, HEAD, PUT, DELETE, OPTIONS. Не idempotent: POST (создаёт новый ресурс), PATCH (зависит от патча). Поэтому клиенты и прокси могут безопасно повторять idempotent-запросы при таймауте.
Типичные ошибки
- ✗Использовать GET для модифицирующих действий — кеши и prefetcher всё поломают
- ✗Делать POST-обработчики idempotent без документации
- ✗Использовать PATCH для полной замены (это задача PUT)
Уточняющие вопросы
- →Как сервер использует idempotency keys для дедупликации POST?
- →Почему DELETE обычно возвращает 204 No Content?
JuniorТеорияЧастоЧто такое IP-адрес? IPv4 vs IPv6, маска подсети, размер в памяти.
Что такое IP-адрес? IPv4 vs IPv6, маска подсети, размер в памяти.
IP-адрес идентифицирует хост. IPv4: 32 бита (4 Б), четыре октета 192.168.1.1, ~4.3 млрд — исчерпаны. IPv6: 128 бит (16 Б), восемь hex-групп 2001:db8::1, ~3.4×10³⁸. Маска подсети /n в CIDR — n старших бит = сетевой префикс. В C++: in_addr (4 Б), in6_addr (16 Б), в sockaddr_in/sockaddr_in6.
Типичные ошибки
- ✗Рассматривать IP-адреса как 32-битные целые без учёта порядка байт — используйте
htonl/ntohlдля конвертации между порядком байт хоста и сети (big-endian) - ✗Думать, что ::1 — только тестовый адрес —
::1это loopback IPv6, аналог 127.0.0.1 - ✗Считать, что 192.168.x.x — единственный частный диапазон — 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 — все диапазоны RFC 1918
Уточняющие вопросы
- →Что такое NAT и зачем он используется с IPv4?
- →Как
getaddrinfo()разрешает имя хоста в адреса IPv4 и IPv6?
JuniorТеорияЧастоЧто такое NAT и зачем он нужен в IPv4?
Что такое NAT и зачем он нужен в IPv4?
NAT сопоставляет множество приватных IP (10.x, 172.16.x, 192.168.x) с одним публичным, переписывая source IP+port в исходящих пакетах и ведя таблицу соединений. Причины: дефицит IPv4 и побочный perimeter-security эффект (нет входящих без port forwarding). IPv6 устраняет NAT — каждому устройству глобальный адрес.
Типичные ошибки
- ✗Делать P2P-приложения, считая, что оба пира могут принимать соединения — NAT обычно мешает
- ✗Пытаться хостить сервер за домашним NAT без port forwarding
- ✗Путать NAT (router) и PAT (port address translation, что обычно и делают домашние роутеры)
Уточняющие вопросы
- →Что такое hole punching для обхода NAT?
- →Почему WebRTC нужны STUN/TURN серверы?
JuniorТеорияЧастоЧто такое порт и сколько их доступно?
Что такое порт и сколько их доступно?
Порт — 16-битное число (0–65535), всего 65536, мультиплексирует трафик к процессам. Диапазоны: 0–1023 — well-known (HTTP 80, HTTPS 443, SSH 22, DNS 53), нужен root на Linux; 1024–49151 — IANA; 49152–65535 — эфемерные (ОС для исходящих). Соединение = пятёрка (протокол, src IP, src port, dst IP, dst port).
Типичные ошибки
- ✗Думать, что каждый номер порта может использоваться только одним соединением — соединение определяется пятёркой, поэтому один порт назначения может обслуживать много одновременных соединений от разных клиентов
- ✗Пытаться привязаться к порту < 1024 без привилегий на Linux — результат
EACCES; используйте привилегиюCAP_NET_BIND_SERVICEвместо запуска от root - ✗Путать пространства имён портов UDP и TCP — они независимы; TCP-порт 80 и UDP-порт 80 — разные сокеты
Уточняющие вопросы
- →Что такое
SO_REUSEPORTи чем он отличается отSO_REUSEADDR? - →Сколько одновременных TCP-соединений теоретически может обслужить сервер на одном порту?
JuniorТеорияЧастоЧто такое сериализация и зачем она нужна сетевым системам?
Что такое сериализация и зачем она нужна сетевым системам?
Сериализация — преобразование объектов в памяти в поток байт для передачи или хранения; десериализация — обратный процесс. Сетевым системам она нужна потому, что сырой layout памяти платформозависим (порядок байт, padding, указатели), поэтому требуется переносимый wire-формат (JSON, Protobuf, MessagePack, CBOR).
Типичные ошибки
- ✗Отправлять сырые структуры через сеть — порядок байт, padding и значения указателей ломают совместимость между машинами
- ✗Класть
std::stringилиstd::vectorнапрямую в провод — их layout зависит от компилятора - ✗Пропускать версионирование схемы — добавление поля позже ломает всех старых клиентов, ожидавших прежний формат
Уточняющие вопросы
- →В чём компромисс между текстовыми форматами (JSON) и бинарными (Protobuf, FlatBuffers)?
- →Как развивать схему Protobuf, не ломая старых клиентов?
MiddleТеорияЧастоЧто такое CORS и как работает preflight-запрос?
Что такое CORS и как работает preflight-запрос?
CORS ослабляет Same-Origin Policy в браузере. Простые запросы (GET/POST, безопасные заголовки) проверяют Access-Control-Allow-Origin в ответе. Сложные (кастомные заголовки, PUT, DELETE) — сначала preflight OPTIONS; сервер должен разрешить origin/methods/headers. Только браузер.
Типичные ошибки
- ✗Ставить
Access-Control-Allow-Origin: *вместе сAllow-Credentials: true— запрещено; нужен явный origin - ✗Забыть обрабатывать OPTIONS preflight на сервере
- ✗Считать, что CORS защищает от CSRF — не полностью; нужен SameSite / CSRF-токены
Уточняющие вопросы
- →Почему заголовок Authorization вызывает preflight?
- →Зачем
Access-Control-Max-Age?
MiddleТеорияЧастоКак работает резолвинг DNS от начала до конца?
Как работает резолвинг DNS от начала до конца?
OC-resolver проверяет /etc/hosts, затем шлёт запрос recursive DNS (например 8.8.8.8, 1.1.1.1). Recursive ходит root → TLD → authoritative и возвращает A/AAAA. Кеши на всех уровнях (браузер, ОС, recursive) уважают TTL. DNS по UDP/53; DoT/DoH добавляют TLS.
Типичные ошибки
- ✗Хардкодить IP вместо DNS — ломается при изменениях инфраструктуры
- ✗Забывать, что
localhostзависит отnsswitch.conf/hosts - ✗Длинные TTL дают устаревшие записи при деплоях
Уточняющие вопросы
- →Чем итеративный DNS-запрос отличается от рекурсивного?
- →Почему DNS на UDP и когда падает на TCP?
MiddleДизайнЧастоВы выбираете стиль взаимодействия для нового сервиса и сравниваете REST API с RPC-фреймворком gRPC. Объясните, чем они различаются по транспорту, формату сериализации и стилю взаимодействия (запрос/ответ против streaming) и какие системы склоняют вас к одному варианту, а не к другому.
Вы выбираете стиль взаимодействия для нового сервиса и сравниваете REST API с RPC-фреймворком gRPC. Объясните, чем они различаются по транспорту, формату сериализации и стилю взаимодействия (запрос/ответ против streaming) и какие системы склоняют вас к одному варианту, а не к другому.
REST использует HTTP/1.1 или HTTP/2 с JSON и ресурсные URL — дружелюбен к браузеру, легко дебажится. gRPC — HTTP/2 с Protocol Buffers (бинарный, со схемой), RPC-стиль, двунаправленный streaming, сгенерированные stub'ы. REST — для публичных API и браузеров; gRPC — для микросервисов, low-latency polyglot, streaming.
Типичные ошибки
- ✗Выбирать gRPC для публичного браузерного API — нужен gRPC-Web с ограничениями
- ✗Сравнивать JSON vs Protobuf без стратегии версионирования
- ✗Игнорировать дебаггабельность — Protobuf не человекочитаем
Уточняющие вопросы
- →Как Protobuf поддерживает обратную совместимость?
- →Что даёт мультиплексирование HTTP/2 для gRPC?
MiddleТеорияЧастоКакие основные TCP-флаги (SYN, ACK, FIN, RST, PSH, URG) и какую роль играет каждый?
Какие основные TCP-флаги (SYN, ACK, FIN, RST, PSH, URG) и какую роль играет каждый?
SYN открывает соединение (initial handshake). ACK подтверждает полученные байты (стоит почти на каждом сегменте). FIN корректно закрывает одну сторону. RST резко обрывает соединение. PSH подсказывает получателю немедленно отдать буфер (low-latency трафик). URG с urgent pointer помечает out-of-band данные, сейчас почти не используется.
Типичные ошибки
- ✗Путать FIN и RST — FIN корректен, RST — односторонний разрыв
- ✗Считать, что PSH действительно flush'ит буферы ядра — это лишь хинт
- ✗Принимать ретрансмиссии за новые SYN
Уточняющие вопросы
- →Что такое half-closed connection?
- →Почему RST часто видно при connection refused?
MiddleТеорияЧастоКак протокол WebSocket апгрейдится от HTTP и для чего он нужен?
Как протокол WebSocket апгрейдится от HTTP и для чего он нужен?
Клиент шлёт HTTP/1.1 GET с Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key. Сервер отвечает 101 Switching Protocols с соответствующим Sec-WebSocket-Accept. Это же TCP далее используется для full-duplex фреймов. Применения: чат, мультиплеер, дашборды, push. Поверх TLS: порт 443 со схемой wss://.
Типичные ошибки
- ✗Забыть обрабатывать ping/pong — прокси режут idle-соединения
- ✗Не реализовать reconnect с exponential backoff в клиенте
- ✗Пытаться использовать server push HTTP/2 там, где проще WebSocket
Уточняющие вопросы
- →Чем server-sent events HTTP/2 отличаются от WebSocket?
- →Почему WebSocket key использует SHA-1 — это безопасно?
SeniorДизайнЧастоПриложение вызывает HTTP API по сети. Пройдите от начала до конца всё, что система делает, чтобы доставить этот запрос и вернуть ответ — от вызова приложения вниз через операционную систему и сетевой стек, через физическую сеть, до сервера и обратно. Затроньте, как разрешается адрес назначения, как устанавливаются соединение и шифрование, как данные оборачиваются при спуске по стеку и где в пути задействуются промежуточные узлы.
Приложение вызывает HTTP API по сети. Пройдите от начала до конца всё, что система делает, чтобы доставить этот запрос и вернуть ответ — от вызова приложения вниз через операционную систему и сетевой стек, через физическую сеть, до сервера и обратно. Затроньте, как разрешается адрес назначения, как устанавливаются соединение и шифрование, как данные оборачиваются при спуске по стеку и где в пути задействуются промежуточные узлы.
Запрос проходит: (1) API; (2) сокет ОС + TCP/IP; (3) DNS (кеш → stub → recursive → authoritative); (4) 3-way TCP handshake; (5) TLS при HTTPS; (6) HTTP; (7) ARP, маршрутизация, NAT, балансировщик; (8) сервер; (9) ответ обратно. Инкапсуляция: HTTP body → TCP → IP → Ethernet.
Открыть задачу →Типичные ошибки
- ✗Пропускать задержку DNS в оценках — холодный DNS-запрос добавляет 20–200 мс; кэш ОС, кэш браузера и управление TTL EDNS0 критически важны для производительности
- ✗Не учитывать стоимость установки соединения — TCP + TLS добавляет 1.5–2 RTT; пул соединений и keep-alive устраняют эти накладные расходы для последующих запросов
- ✗Игнорировать буфер TCP ОС и алгоритм Нэгла — небольшие записи по умолчанию объединяются;
TCP_NODELAYотключает Нэгла для протоколов, чувствительных к задержке
Уточняющие вопросы
- →На каком этапе задействуется ARP, и как это отличается для запроса через подсеть?
- →Как обратный прокси (nginx) изменяет жизненный цикл запроса по сравнению с прямым соединением?
JuniorТеорияИногдаКакие проблемы IPv4 решает IPv6?
Какие проблемы IPv4 решает IPv6?
У IPv6 128-битные адреса (vs 32-бит) — практически безграничное пространство, NAT не нужен. Заголовок фиксированный, проще (extension headers вместо опций). Роутеры не фрагментируют — только отправитель через PMTUD. Встроенный IPsec, SLAAC, улучшенный multicast. Медленное распространение — coexistence (dual-stack, NAT64/DNS64), не техника.
Типичные ошибки
- ✗Хардкодить IPv4-only сокеты —
getaddrinfoвозвращает оба семейства - ✗Забывать скобки вокруг IPv6 в URL:
http://[::1]:8080/ - ✗Считать IPv4-mapped (
::ffff:1.2.3.4) рабочими везде
Уточняющие вопросы
- →Что такое SLAAC и чем отличается от DHCPv6?
- →Почему в ICMPv6 меньше «unreachable» типов, чем в ICMP для IPv4?
JuniorТеорияИногдаСравните модели сети OSI и TCP/IP.
Сравните модели сети OSI и TCP/IP.
OSI — теоретическая эталонная модель из 7 уровней (Физический, Канальный, Сетевой, Транспортный, Сеансовый, Представительный, Прикладной). TCP/IP имеет 4: Доступ к сети (≈L1+L2), Интернет (L3 IP), Транспорт (L4 TCP/UDP), Приложение (≈L5–L7 HTTP/DNS). На практике реализуется TCP/IP; OSI используется для обучения и диагностики уровня проблемы.
Типичные ошибки
- ✗Путать уровень 'Application' TCP/IP с уровнем Application OSI — Application в TCP/IP охватывает OSI L5+L6+L7
- ✗Размещать TLS на L4 — TLS логически находится между L4 (TCP) и L7 (HTTP), часто называют L4.5 или 'поверх транспорта, ниже приложения'
- ✗Думать, что ARP — протокол уровня L3 — ARP работает на границе L2/L3; он отображает адреса L3 (IP) на адреса L2 (MAC)
Уточняющие вопросы
- →Что происходит на каждом уровне при отправке HTTP-запроса?
- →Чем коммутатор отличается от маршрутизатора с точки зрения уровней OSI?
MiddleТеорияИногдаОпишите протоколы прикладного уровня (HTTP, FTP, DNS, WebSocket).
Опишите протоколы прикладного уровня (HTTP, FTP, DNS, WebSocket).
HTTP/1.1: текст по TCP, stateless, keep-alive. HTTP/2: бинарное фреймирование, мультиплексирование, HPACK. HTTP/3: QUIC/UDP, без HoL. FTP: два TCP — управление (21) + данные (20); заменён SFTP. DNS: имена → IP по UDP/53, TCP fallback. WebSocket: апгрейд HTTP до full-duplex канала.
Типичные ошибки
- ✗Думать, что HTTP/2 решает все проблемы задержки — мультиплексирование помогает, но head-of-line blocking на уровне TCP остаётся; HTTP/3 (QUIC) решает это
- ✗Использовать FTP для безопасной передачи файлов — FTP передаёт учётные данные в открытом тексте; используйте SFTP (на основе SSH) или FTPS (FTP + TLS) для безопасности
- ✗Оставлять WebSocket-соединения живыми без heartbeat — NAT-шлюзы и балансировщики нагрузки закрывают простаивающие соединения; отправляйте ping-фреймы на уровне приложения каждые 30-60 секунд
Уточняющие вопросы
- →Как работает сжатие заголовков HTTP/2 (HPACK) и что такое HPACK bombing?
- →Что такое WebSocket upgrade handshake и какие HTTP-заголовки задействованы?
MiddleТеорияИногдаЧем L4 и L7 load balancer'ы отличаются?
Чем L4 и L7 load balancer'ы отличаются?
L4 (transport) маршрутизирует по IP/port без инспекции payload — быстрый и простой, не терминирует TLS (например AWS NLB, IPVS). L7 (application) инспектирует HTTP-заголовки, пути и методы — поддерживает routing rules, TLS termination, retry и observability (например AWS ALB, nginx, Envoy). L4 быстрее по throughput; L7 гибче.
Типичные ошибки
- ✗Пытаться сделать canary на L4 — нужен payload inspection
- ✗Ставить L7 LB перед сырым TCP — тратит CPU на парсинг
- ✗Забывать, что L7 видит plaintext — TLS терминируется там
Уточняющие вопросы
- →Как consistent hashing улучшает L4?
- →Что такое sticky session и когда она нужна?
MiddleТеорияИногдаЧто такое сериализация, и какие C++ библиотеки для неё используются?
Что такое сериализация, и какие C++ библиотеки для неё используются?
Сериализация превращает граф объектов в памяти в поток байт для хранения или передачи; десериализация восстанавливает его. Текстовые форматы (JSON, XML) читаемы; бинарные (Protobuf, FlatBuffers, Cap'n Proto) компактны и быстры. Популярные C++ библиотеки: nlohmann/json, Protobuf, cereal, Boost.Serialization.
Типичные ошибки
- ✗Сериализовать сырые указатели — значения указателей специфичны для адресного пространства; сериализуйте указуемые данные, не адрес
- ✗Пропускать версионирование схемы — добавление обязательного Protobuf-поля ломает всех существующих читателей; резервируйте номера полей и используйте optional
- ✗Выбирать JSON для высокопропускного RPC — стоимость парсинга доминирует при высоком RPS; бинарные форматы на порядки быстрее
Уточняющие вопросы
- →Как Protobuf обеспечивает обратную совместимость через optional-поля и зарезервированные номера полей?
- →Чем zero-copy дизайн FlatBuffers отличается от классического парсинга Protobuf?
SeniorТеорияИногдаЧем HTTP/2 и HTTP/3 отличаются от HTTP/1.1 на транспортном уровне?
Чем HTTP/2 и HTTP/3 отличаются от HTTP/1.1 на транспортном уровне?
HTTP/2 мультиплексирует множество потоков поверх одного TCP-соединения и сжимает заголовки, но потеря пакета останавливает все потоки — это TCP head-of-line blocking. HTTP/3 вместо этого работает поверх QUIC на UDP, давая независимое восстановление потерь по потокам и более быстрое объединённое рукопожатие транспорта и TLS.
Типичные ошибки
- ✗Считать, что
HTTP/2полностью убирает head-of-line blocking — он убирает его лишь на уровне HTTP, неTCP - ✗Думать, что
QUIC— транспорт рядом сTCP, а не протокол поверхUDP - ✗Полагать, что
HTTP/3всегда быстрее, игнорируя, что часть сетей режет или блокируетUDP
Уточняющие вопросы
- →Почему
QUICвстраивает TLS-рукопожатие в установление соединения? - →Что такое connection migration в
QUICи чем это помогает мобильным клиентам?
SeniorТеорияИногдаЧто такое RPC? Библиотеки и протоколы.
Что такое RPC? Библиотеки и протоколы.
RPC позволяет вызвать функцию в другом процессе/машине как локальную: заглушки сериализуют аргументы, передают по сети и возвращают результат. gRPC использует Protobuf+HTTP/2.
Типичные ошибки
- ✗Проектировать RPC как локальный вызов функции — сетевые вызовы могут завершаться с ошибкой, быть медленными или частично выполненными; всегда обрабатывайте таймауты, повторные попытки и идемпотентность
- ✗Не версионировать интерфейс сервиса — добавление обязательного поля в Protobuf-сообщение ломает всех существующих клиентов
- ✗Использовать синхронный блокирующий RPC для всех вызовов — для высокопроизводительных сервисов потоковая передача или async gRPC предотвращает исчерпание потоков
Уточняющие вопросы
- →Как gRPC обрабатывает service discovery и балансировку нагрузки?
- →В чём разница между потоковой передачей gRPC и WebSocket?
SeniorТеорияИногдаКак работает управление перегрузкой в TCP и чем оно отличается от управления потоком?
Как работает управление перегрузкой в TCP и чем оно отличается от управления потоком?
Управление перегрузкой — это реакция отправителя на пропускную способность сети: оно растит cwnd экспоненциально в slow start, линейно в congestion avoidance и уменьшает при потере. Управление потоком защищает буфер получателя через advertised window. Отправитель шлёт по минимуму из двух окон.
Типичные ошибки
- ✗Путать
cwnd(окно перегрузки, оценка отправителя) сrwnd(окно приёма, объявляемое получателем) - ✗Считать slow start медленным — он растёт экспоненциально и на деле агрессивен
- ✗Забывать, что отправитель шлёт по min(
cwnd,rwnd), и доминировать может любой предел
Уточняющие вопросы
- →Что вызывает переход от slow start к congestion avoidance?
- →Чем отличаются алгоритмы на основе потерь и на основе задержки, как BBR?
SeniorТеорияИногдаПройдитесь по шагам TLS 1.3 handshake.
Пройдитесь по шагам TLS 1.3 handshake.
1) Клиент → ClientHello: ciphersuites, key shares (X25519/secp256r1), SNI. 2) Сервер → ServerHello, Certificate, CertificateVerify, Finished — под handshake-ключом. 3) Клиент проверяет цепочку, шлёт Finished. 1-RTT; 0-RTT через session ticket. TLS 1.3 убрал RSA, MD5/SHA-1, compression, renegotiation.
Типичные ошибки
- ✗Путать TLS 1.2 (2-RTT) с TLS 1.3 (1-RTT)
- ✗Использовать 0-RTT для не-idempotent запросов — риск replay-атаки
- ✗Доверять серту без OCSP/CRL проверки отзыва
Уточняющие вопросы
- →Почему RSA key exchange убрали в TLS 1.3?
- →Что такое OCSP stapling?
JuniorТеорияРедкоКакой диапазон IPv4-адресов зарезервирован для multicast?
Какой диапазон IPv4-адресов зарезервирован для multicast?
Диапазон 224.0.0.0/4 — от 224.0.0.0 до 239.255.255.255, исторически «класс D». Его определяющий признак — старшие четыре бита равны 1110. Адрес назначения вне этого блока является unicast (или broadcast) и никогда не может обозначать multicast-группу.
Типичные ошибки
- ✗Путать multicast-блок
224.0.0.0/4с зарезервированным блоком «класса E»240.0.0.0/4 - ✗Думать, что multicast — это только
224.x.x.x; блок тянется до239.255.255.255включительно - ✗Считать, что multicast — это флаг в заголовке, а не закодирован в самом адресе назначения
Уточняющие вопросы
- →Чем особен link-local поддиапазон
224.0.0.0/24? - →Как IPv4-адрес multicast-группы отображается на MAC-адрес Ethernet?
MiddleТеорияРедкоЧто такое MTU и как работает фрагментация в IPv4 и IPv6?
Что такое MTU и как работает фрагментация в IPv4 и IPv6?
MTU — наибольший пакет, который канал переносит без фрагментации (Ethernet ~1500 байт). В IPv4 роутеры могут фрагментировать пакеты, а получатель собирает их; в IPv6 роутерам фрагментировать нельзя, фрагментирует только отправитель после Path MTU Discovery через ICMP 'Packet Too Big'. Firewall'ы, дропающие ICMP, ломают PMTUD — отсюда TCP MSS clamping.
Типичные ошибки
- ✗Блокировать весь ICMP на firewall — ломает PMTUD
- ✗Считать MTU всегда 1500 — VPN/tunnel уменьшают
- ✗Путать MTU и MSS (MSS = MTU - IP - TCP заголовки)
Уточняющие вопросы
- →Как работает TCP MSS clamping и зачем он иногда нужен?
- →Что такое jumbo frame и когда он полезен?
MiddleТеорияРедкоЧем отличается shutdown() от close() для сокета, разделяемого после fork()?
Чем отличается shutdown() от close() для сокета, разделяемого после fork()?
close() лишь убирает одну ссылку на fd. После fork() ссылку держат оба процесса, поэтому close() в потомке оставляет соединение живым через родителя. shutdown() действует на сам разделяемый объект сокета — он закрывает направление и может послать TCP FIN, что видно каждому процессу.
Типичные ошибки
- ✗Ожидать, что
close()в потомке разорвёт соединение — он лишь убирает ссылку потомка - ✗Менять роли местами: считать
shutdown()вызовом со счётчиком ссылок, аclose()— глобальным - ✗Считать
shutdown()локальным для процесса — он меняет общий сокет, и пир видит FIN
Уточняющие вопросы
- →Что делает каждый из аргументов
SHUT_RD,SHUT_WRиSHUT_RDWRдляshutdown()? - →Почему
shutdown(SHUT_WR)— чистый способ сигнализировать конец потока перед чтением ответа?
SeniorДизайнРедкоВам нужно спроектировать один сервер, выдерживающий 100k одновременных клиентских соединений, в большинстве своём простаивающих, но долгоживущих. Наивная модель «поток на соединение» рушится на таком масштабе, поэтому объясните, какую модель ввода-вывода и конкурентности вы построите вместо неё, почему она масштабируется там, где наивная — нет, сколько рабочих потоков вы запустите относительно числа ядер CPU и какие лимиты операционной системы придётся настроить.
Вам нужно спроектировать один сервер, выдерживающий 100k одновременных клиентских соединений, в большинстве своём простаивающих, но долгоживущих. Наивная модель «поток на соединение» рушится на таком масштабе, поэтому объясните, какую модель ввода-вывода и конкурентности вы построите вместо неё, почему она масштабируется там, где наивная — нет, сколько рабочих потоков вы запустите относительно числа ядер CPU и какие лимиты операционной системы придётся настроить.
Откажитесь от модели «поток на соединение» — 100k потоков исчерпают память и планировщик. Используйте событийный мультиплексор ввода-вывода (epoll/kqueue/IOCP) с неблокирующими сокетами, небольшой пул примерно из одного потока на ядро и уведомление о готовности за O(1). Это классическая проблема C10k/C10M.
Типичные ошибки
- ✗Брать
select()/poll()при масштабе — ониO(n)на вызов и упираются около 1024 дескрипторов - ✗Плодить неограниченное число потоков, исчерпывая память стеков и топя планировщик в переключениях
- ✗Забывать настроить лимиты ядра —
ulimit -n, диапазон эфемерных портов, буферы сокетов
Уточняющие вопросы
- →Почему edge-triggered режим
epollэффективнее, но хитрее level-triggered? - →Как
SO_REUSEPORTпомогает распределять accept между рабочими потоками?
SeniorТеорияРедкоЧто меняет TLS 1.3 и в чём риск 0-RTT?
Что меняет TLS 1.3 и в чём риск 0-RTT?
TLS 1.3 сокращает рукопожатие до одного round trip, убирает устаревшие шифры и обмен ключами RSA и требует forward secrecy. 0-RTT позволяет возобновлённой сессии отправить данные приложения в первом пакете, но эти ранние данные можно воспроизвести — поэтому они должны нести только идемпотентные запросы.
Типичные ошибки
- ✗Называть данные
0-RTTпросто «небезопасными» — они зашифрованы, проблема именно в replay - ✗Слать неидемпотентные запросы (например, изменяющий состояние
POST) как ранние данные0-RTT - ✗Считать, что возобновление
TLS 1.3с0-RTTсохраняет forward secrecy для ранних данных
Уточняющие вопросы
- →Как сервер может смягчить replay-атаки
0-RTTна уровне приложения? - →Почему
TLS 1.3убрал обмен ключами RSA в пользу эфемерного Diffie-Hellman?
