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 - TCP/IP — это 4-уровневая модель (Link / Internet / Transport / Application), на практике вместо OSI обсуждают именно её. - TCP даёт надёжную, упорядоченную, байт-ориентированную доставку поверх ненадёжного IP за счёт sequence/ack-номеров, ретрансмиссий и контрольных сумм. - Установка — 3-way handshake (SYN / SYN-ACK / ACK), закрытие — 4-way (FIN/ACK обе стороны), активный закрыватель уходит в `TIME_WAIT` на 2×MSL. - Flow control = защита получателя (sliding window), congestion control = защита сети (slow start, congestion avoidance, fast recovery, CUBIC/BBR). - Бэкендеру критичны: `TIME_WAIT`-исчерпание портов, Nagle vs delayed ACK (латентность), TCP keep-alive vs HTTP keep-alive (это разные вещи), backlog очередей accept. ## Теория ### Модель TCP/IP vs OSI | TCP/IP | Аналог OSI | Примеры | |---|---|---| | Application | L5-L7 | HTTP, gRPC, DNS, TLS | | Transport | L4 | TCP, UDP, QUIC(поверх UDP) | | Internet | L3 | IP, ICMP, маршрутизация | | Link | L1-L2 | Ethernet, ARP, MAC | Senior-нюанс: TLS формально живёт между L4 и L7, поэтому в собеседовании TLS обычно относят к "L6-ish" в OSI, но в TCP/IP-модели это просто часть Application. ### TCP handshake (установка) ``` Client Server | --- SYN (seq=x) ----------> | # клиент шлёт ISN | <-- SYN-ACK (seq=y, ack=x+1)| # сервер подтверждает + свой ISN | --- ACK (ack=y+1) --------> | # соединение ESTABLISHED ``` - ISN (Initial Sequence Number) выбирается рандомно (защита от спуфинга/предсказания). - Параметры согласуются в опциях SYN: MSS, window scaling, SACK, timestamps. - **SYN backlog / accept queue**: ОС держит две очереди — incomplete (SYN получен) и complete (handshake завершён, ждёт `accept()`). Переполнение complete-queue (`somaxconn`, `net.core.somaxconn`) приводит к дропу/ретрансмиссии SYN — частая причина "таймаутов на подключение" под нагрузкой. - **TCP Fast Open (TFO)**: позволяет слать данные уже в SYN, экономит RTT, но требует поддержки с обеих сторон и редко включён. ### TCP teardown (закрытие) ``` | --- FIN -----------> | (активный закрыватель -> FIN_WAIT_1) | <-- ACK ------------ | | <-- FIN ------------ | | --- ACK -----------> | (-> TIME_WAIT) ``` - Возможен **simultaneous close** и **half-close** (одна сторона закрыла отправку, но читает — `CloseWrite()` в Go: `tcpConn.CloseWrite()`). ### TIME_WAIT Активный закрыватель остаётся в `TIME_WAIT` на 2×MSL (обычно 60s в Linux, MSL=30s, не настраивается без пересборки ядра). - **Зачем**: (1) гарантировать доставку последнего ACK; (2) дать "умереть" задержавшимся сегментам старого соединения, чтобы они не попали в новое с тем же 4-tuple. - **Проблема**: при большом числе исходящих коротких соединений (например, сервис, который дёргает другой сервис без пулинга) исчерпываются эфемерные порты → "cannot assign requested address". - **Решения**: переиспользование соединений (HTTP keep-alive, пулы!), `net.ipv4.tcp_tw_reuse=1` (для исходящих, безопасно), расширение `ip_local_port_range`. `tcp_tw_recycle` — **удалён/опасен** (ломал NAT), не упоминать как решение. ### Flow control (контроль потока) - Защищает **получателя** от переполнения буфера. - Receiver объявляет `rwnd` (receive window) в каждом ACK; sender не шлёт больше, чем `min(rwnd, cwnd)` неподтверждённых байт. - **Window scaling** (опция) расширяет окно за пределы 64КБ — обязательно для high-BDP линков (high bandwidth-delay product). - **Zero window / silly window syndrome**: если получатель медленно читает, окно схлопывается в ноль; отправитель шлёт window probes. ### Congestion control (контроль перегрузки) Защищает **сеть**. Sender держит `cwnd` (congestion window): 1. **Slow start**: cwnd растёт экспоненциально до `ssthresh`. 2. **Congestion avoidance**: линейный рост (AIMD). 3. **Fast retransmit / fast recovery**: 3 дубликата ACK → ретрансмит без ожидания таймаута. 4. Алгоритмы: **CUBIC** (дефолт в Linux, loss-based), **BBR** (Google, model-based по bandwidth+RTT, лучше на длинных/лоссистых линках). ### Nagle и delayed ACK - **Nagle (`TCP_NODELAY=false`, дефолт on)**: буферизует мелкие записи, пока не подтверждён предыдущий пакет → меньше мелких сегментов, но +латентность. - **Delayed ACK**: получатель откладывает ACK (~40-200ms), надеясь приклеить его к данным. - **Антипаттерн**: Nagle + delayed ACK вместе дают артефактную задержку до ~40ms на request/response протоколах. Поэтому для RPC/интерактивных протоколов ставят `TCP_NODELAY`. ```go // Go по умолчанию ВЫКЛЮЧАЕТ Nagle для TCP-соединений (SetNoDelay(true) по дефолту). ln, _ := net.Listen("tcp", ":8080") conn, _ := ln.Accept() tcp := conn.(*net.TCPConn) tcp.SetNoDelay(true) // дефолт, но явно ``` ### Keep-alive: два разных уровня | | TCP keep-alive | HTTP keep-alive | |---|---|---| | Уровень | L4 (ОС) | L7 (приложение) | | Цель | детектить мёртвые peer'ы, держать NAT-маппинг | переиспользовать TCP-соединение для нескольких HTTP-запросов | | Управление | `SetKeepAlive`, `tcp_keepalive_time` | `Connection: keep-alive`, `http.Transport.IdleConnTimeout` | ```go d := &net.Dialer{ Timeout: 5 * time.Second, KeepAlive: 30 * time.Second, // TCP keep-alive probes } ``` Go 1.20+ умеет настраивать keep-alive count/interval через `net.KeepAliveConfig`. ### Где это всплывает в Go - `net.Dialer` — таймауты подключения, keep-alive, dual-stack (Happy Eyeballs для IPv4/IPv6). - `net.TCPConn` — `SetNoDelay`, `SetLinger`, `CloseWrite`, `SetReadBuffer/SetWriteBuffer`. - `SetLinger(0)` шлёт RST вместо FIN при закрытии → соединение НЕ уходит в TIME_WAIT (но теряются недоставленные данные — использовать осторожно). ## Подводные камни / gotchas - **TIME_WAIT на стороне клиента-сервиса**: если ваш сервис — активный закрыватель тысяч исходящих коннектов без пула, порты кончатся. Лечится пулингом, а не тюнингом ядра. - **Путают TCP keep-alive и HTTP keep-alive** — это разные механизмы на разных уровнях. - **`tcp_tw_recycle`** — мёртвое и вредное, упоминание как решения = красный флаг. - **Half-open соединения**: если peer упал без FIN (kill -9, обрыв сети), вы узнаете об этом только при попытке записи или по keep-alive/таймауту чтения. Отсюда обязательность read/write deadlines. - **`backlog`/`somaxconn`**: дефолты Linux менялись (128 → 4096 в новых ядрах), под нагрузкой надо проверять `ss -lnt` (колонка Recv-Q для слушающего сокета = текущая accept-queue). - **MSS vs MTU и Path MTU Discovery**: чёрные дыры PMTUD (ICMP заблокирован файрволлом) → зависания на больших ответах. Классика прода. - **Nagle включён в вашем не-Go клиенте** + delayed ACK = плавающие 40ms задержки, которые сложно диагностировать. ## Вопросы на собеседовании **В:** Зачем нужен TIME_WAIT и почему он на стороне того, кто закрывает первым? **О:** Чтобы (1) надёжно доставить последний ACK на FIN peer'а и (2) дать задержавшимся сегментам старого соединения исчезнуть до переиспользования того же 4-tuple. Длится 2×MSL. На активном закрывателе, потому что именно он рискует получить ретрансмит FIN и должен на него ответить. **В:** В чём разница между flow control и congestion control? **О:** Flow control защищает получателя (rwnd, объявляется в ACK). Congestion control защищает сеть (cwnd, локальная оценка отправителя через slow start/AIMD/loss/RTT). Отправитель ограничен `min(rwnd, cwnd)`. **В:** Что такое проблема Nagle + delayed ACK? **О:** Nagle придерживает мелкие сегменты до подтверждения предыдущего, delayed ACK придерживает ACK ~40ms. На request/response это даёт взаимную блокировку и латентность до ~40ms. Лечится `TCP_NODELAY`. Go ставит NoDelay по умолчанию. **В:** Чем TCP keep-alive отличается от HTTP keep-alive? **О:** TCP keep-alive — L4-механизм ОС для детекта мёртвых соединений и удержания NAT. HTTP keep-alive — L7, переиспользование одного TCP для нескольких HTTP-запросов. Они независимы. **В:** Сервис под нагрузкой получает "cannot assign requested address" при исходящих запросах. Причина? **О:** Исчерпание эфемерных портов из-за множества соединений в TIME_WAIT (сервис — активный закрыватель). Правильное решение — переиспользование соединений (HTTP-пул, MaxIdleConnsPerHost), затем `tcp_tw_reuse` и расширение `ip_local_port_range`. НЕ `tcp_tw_recycle`. **В:** Что произойдёт, если accept-queue переполнится? **О:** Новые завершённые handshake-соединения дропаются, клиенту приходит ретрансмит SYN или таймаут. Регулируется `somaxconn` и backlog в `listen()`. Симптом — спорадические таймауты на connect под пиком. **В:** Как обнаружить, что peer "тихо" умер? **О:** Через TCP keep-alive probes или, что надёжнее на уровне приложения, через read/write deadlines (`SetReadDeadline`). Без них горутина может висеть бесконечно на мёртвом соединении. **В:** Зачем window scaling и SACK? **О:** Window scaling позволяет окну превысить 64КБ — нужно для высокого BDP (high bandwidth × delay), иначе throughput упирается в потолок. SACK (selective ACK) позволяет подтверждать непрерывные блоки при потерях, избегая ретрансмита уже доставленного. ## На что копают на senior+ - Различие CUBIC vs BBR и когда BBR выигрывает (длинные/лоссистые линки, bufferbloat). - Bandwidth-Delay Product и расчёт нужного размера окна/буферов под конкретный RTT. - Поведение под NAT и почему `tcp_tw_recycle` его ломал (timestamp-эвристика на агрегированных адресах). - Как RST отличается от FIN, когда ядро шлёт RST (закрытый порт, `SO_LINGER 0`, переполнение очереди), и почему RST не имеет рукопожатия подтверждения. - Diagnostics-инструментарий: `ss -tin` (cwnd, rtt, retrans), `tcpdump`, `nstat`, что смотреть при подозрении на потери/ретрансмиты. - Влияние выбора TCP vs QUIC на head-of-line blocking на L4 (см. HTTP/3).