Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: Сети и протоколы · Уровень: Middle+/Senior ## TL;DR - WebSocket (RFC 6455) — полнодуплексный двунаправленный канал поверх одного TCP, устанавливается HTTP Upgrade-рукопожатием, затем переходит на бинарный фрейм-протокол. - Использует тот же порт (80/443), проходит прокси/файрволлы как HTTP; после upgrade — это уже не HTTP. - Фреймы: text/binary/ping/pong/close + fragmentation; клиент обязан **маскировать** payload. - Выбирать вместо polling/SSE, когда нужна низкая латентность И двунаправленность (чат, игры, коллаборация). SSE достаточно для server→client односторонних потоков. - Масштабирование — главная боль: stateful соединения, sticky-сессии или pub/sub-бэкплейн (Redis/NATS/Kafka), лимиты на FD/память. - В Go: `gorilla/websocket` (де-факто, но архивный) и `coder/websocket` (бывш. nhooyr.io/websocket, контекст-aware, рекомендуемый). ## Теория ### Установка: HTTP Upgrade ``` GET /ws HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: chat # опц. субпротоколы HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= # SHA1(key+GUID), base64 ``` - После `101` соединение перестаёт быть HTTP — дальше бинарные WS-фреймы. - `Sec-WebSocket-Accept` = base64(SHA1(client_key + magic_GUID)) — подтверждает, что сервер понял WS (защита от случайного апгрейда кешами). - Поверх TLS — это `wss://` (рекомендуется всегда). - HTTP/2 имеет своё расширение для WS (RFC 8441, CONNECT), но классика — поверх h1. ### Структура фрейма - **FIN** бит (последний фрейм сообщения) + **opcode**: 0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong, 0x0 continuation. - **MASK** бит + 32-битный masking key: **клиент → сервер фреймы ОБЯЗАНЫ быть замаскированы** (XOR), сервер → клиент — нет. Это защита от cache-poisoning через прокси. - **Payload length**: 7 / 7+16 / 7+64 бит (расширяемая длина). - **Fragmentation**: большое сообщение можно слать частями (FIN=0 у промежуточных). ### Ping/Pong (keep-alive на уровне WS) - Control-фреймы `ping`/`pong` для проверки живости и удержания соединения (NAT, прокси-таймауты). - На `ping` peer обязан ответить `pong` (с тем же payload). - Сервер обычно периодически шлёт ping и закрывает соединение, если нет pong в дедлайн → детект мёртвых клиентов. TCP keep-alive здесь недостаточно надёжен/быстр. ### WebSocket vs SSE vs Polling | | Long Polling | SSE | WebSocket | |---|---|---|---| | Направление | client↔server (через переоткрытие) | server→client | полный дуплекс | | Транспорт | HTTP | HTTP (text/event-stream) | TCP после upgrade | | Латентность | высокая | низкая | низкая | | Авто-reconnect | вручную | встроен (Last-Event-ID) | вручную | | Бинарные данные | да | нет (только текст/UTF-8) | да | | Через HTTP/2 мультиплекс | да | да | сложнее | | Сложность/инфра | низкая | низкая | высокая (stateful) | Правило: нужен только server→client (нотификации, прогресс, котировки) — бери **SSE** (проще, авто-reconnect, обычный HTTP). Нужен дуплекс/низкая латентность в обе стороны (чат, игры, совместное редактирование) — **WebSocket**. ### WebSocket в Go ```go // coder/websocket (рекомендуемый, контекст-aware) func handler(w http.ResponseWriter, r *http.Request) { c, err := websocket.Accept(w, r, nil) if err != nil { return } defer c.Close(websocket.StatusInternalError, "") ctx := r.Context() for { typ, data, err := c.Read(ctx) if err != nil { return } // включая закрытие if err := c.Write(ctx, typ, data); err != nil { return } } } ``` ```go // gorilla/websocket — паттерн с отдельными read/write горутинами var upgrader = websocket.Upgrader{ ReadBufferSize: 1024, WriteBufferSize: 1024, CheckOrigin: func(r *http.Request) bool { return true }, // проверяйте Origin! } conn, _ := upgrader.Upgrade(w, r, nil) // gorilla: writes НЕ потокобезопасны — один writer-горутина обязательна ``` ### Масштабирование - Каждое соединение = живая горутина(ы) + FD + буферы. 100k соединений = тюнинг ulimit/FD, память на буферы. - **Stateful**: соединение привязано к конкретному инстансу. Сообщение для пользователя надо доставить на тот инстанс, где он висит. - **Sticky sessions** (балансировщик держит клиента на одном инстансе) ИЛИ **pub/sub backplane**: инстансы публикуют/подписываются на сообщения через Redis Pub/Sub, NATS, Kafka → любой инстанс может доставить любому клиенту. - **Fan-out** (broadcast): hub-паттерн (реестр клиентов + канал рассылки), но не блокируйте hub медленным клиентом — per-client буфер + дроп/отключение при переполнении. - Graceful shutdown: слать close-фрейм с кодом, давать клиентам переподключиться к другому инстансу. ## Подводные камни / gotchas - **`CheckOrigin` по умолчанию у gorilla отклоняет cross-origin**; разработчики ставят `return true` — это открывает **CSWSH** (Cross-Site WebSocket Hijacking). Проверяйте Origin/используйте токены. - **Writes не потокобезопасны** (gorilla): одновременная запись из двух горутин = коррупция. Один writer-горутина или мьютекс. - **Медленный клиент (slow consumer)** забивает буфер → рост памяти/блокировка hub. Нужен bounded буфер и политика дропа/дисконнекта. - **Забытый ping/pong** → мёртвые соединения копятся, FD-лик; промежуточные прокси режут "тихие" соединения по таймауту. - **WS не проходит некоторые корпоративные прокси** без правильной поддержки Upgrade; нужен fallback (SSE/long-polling) — поэтому socket.io-подобные либы делают fallback. - **TLS обязателен на практике** (`wss://`): по `ws://` многие прокси ломают/инспектируют апгрейд. - **Backpressure**: WebSocket не даёт application-level flow control из коробки — реализуйте сами (кредиты/ack), иначе быстрый отправитель утопит получателя. - **Сообщение vs фрейм**: одно логическое сообщение может быть фрагментировано; не привязывайте бизнес-логику к границам TCP-чтений. - **HTTP/2 и WS**: классический WS не мультиплексируется в h2; за reverse-proxy надо явно поддерживать upgrade (nginx `proxy_set_header Upgrade`). ## Вопросы на собеседовании **В:** Как устанавливается WebSocket-соединение? **О:** Обычным HTTP-запросом с `Upgrade: websocket`/`Connection: Upgrade` и `Sec-WebSocket-Key`. Сервер отвечает `101 Switching Protocols` с `Sec-WebSocket-Accept = base64(SHA1(key + magic GUID))`. После этого соединение переключается на бинарный фрейм-протокол, перестав быть HTTP. **В:** Зачем клиент маскирует фреймы, а сервер нет? **О:** Маскирование (XOR с ключом) защищает от cache-poisoning/инъекций через промежуточные прокси, которые могли бы принять часть payload за HTTP-запрос. Угроза актуальна только для трафика client→server, поэтому маскируется только он. **В:** Когда выбрать SSE вместо WebSocket? **О:** Когда нужен только односторонний поток server→client (нотификации, прогресс, лента). SSE проще: обычный HTTP, встроенный авто-reconnect с Last-Event-ID, легко проходит прокси. WebSocket — когда нужен полный дуплекс и/или бинарные данные с низкой латентностью. **В:** Зачем ping/pong, если есть TCP keep-alive? **О:** TCP keep-alive медленный (десятки минут по умолчанию) и не проверяет живость приложения/прокси. WS ping/pong на уровне приложения быстро детектит мёртвых peer'ов и удерживает соединение через NAT/прокси-таймауты. **В:** Главная сложность масштабирования WebSocket? **О:** Соединения stateful и привязаны к инстансу. Чтобы доставить сообщение пользователю, нужно знать, на каком инстансе он висит. Решения: sticky sessions либо pub/sub backplane (Redis/NATS/Kafka), через который инстансы обмениваются сообщениями. **В:** Что такое CSWSH и как защититься? **О:** Cross-Site WebSocket Hijacking — вредоносная страница открывает WS к вашему серверу, используя cookie жертвы (WS не подчиняется same-origin/CORS как fetch). Защита: проверять заголовок `Origin`, использовать CSRF-токены/auth-токены вместо cookie-only. **В:** Как обработать медленного клиента при broadcast? **О:** Per-client bounded буфер (канал); если он переполнен — дропать сообщения или закрывать соединение, но НЕ блокировать общий hub. Иначе один slow consumer затормозит рассылку всем. **В:** Почему в gorilla нельзя писать из нескольких горутин? **О:** Write не потокобезопасен. Стандартный паттерн — одна writer-горутина, читающая из канала, плюс одна reader-горутина; либо мьютекс на запись. Иначе фреймы перемешаются. ## На что копают на senior+ - Архитектура hub/connection registry, backpressure через bounded каналы, политика дропа. - Конкретный backplane: Redis Pub/Sub (нет персистентности, at-most-once) vs Kafka/NATS (гарантии, переподключение); presence/online-статусы. - Лимиты ОС: FD ulimit, эфемерные порты, память на горутины/буферы при 100k+ соединениях, epoll vs горутина-на-соединение (gnet и подобные). - Graceful deploy stateful-сервиса: drain, close-коды (1001 going away), reconnect-стратегии клиента с backoff+jitter. - Безопасность: Origin-проверка, аутентификация (токен в первом сообщении vs subprotocol vs query), rate limiting на сообщения. - WS over HTTP/2 (RFC 8441) и почему обычно остаются на h1; поведение за L7-прокси (nginx/Envoy) с upgrade. - Сравнение coder/websocket (контекст-aware, проще, без отдельного write-горутины) vs gorilla (архивный, больше контроля, legacy-кодовые базы).