Files
resume/stack/networking/CASE.md

6.9 KiB
Raw Blame History

Кейс: сетевая база (практикум команд)

Связь с легендой: ../../legend/LEGEND.md — раздел «Домашняя лаборатория / pet-проект». Сети как отдельная тема не входили ни в резюме, ни в рабочий стек явно — но это базовые знания, без которых не воспринимается ни один инфраструктурный собес (весь собес VK Cloud построен на сетевой базе). Здесь не docker-стенд, а практикум: реальные команды, прогнанные на своей машине, с записанным выводом.

Что нужно реально сделать

Не разворачивать отдельную инфраструктуру, а вживую прогнать диагностические команды и зафиксировать, что именно они показывают — это то, что на собеседовании часто просят показать в терминале.

1. DNS: резолвинг и разница authoritative/recursive

dig vk.com                     # полный ответ: ANSWER SECTION, TTL, тип записи A
dig +trace vk.com              # путь от корневых DNS-серверов до authoritative-сервера домена
nslookup vk.com

Рекурсивный резолвер (например, DNS провайдера или публичный 8.8.8.8) сам обходит цепочку: корневые сервера → TLD-сервера (.com) → authoritative-сервер зоны vk.com, и возвращает клиенту готовый ответ, кешируя его на своё TTL. Authoritative-сервер — тот, у кого хранится реальная зона домена и который выдаёт финальный, «истинный» ответ по этому домену.

2. Traceroute — как получает IP промежуточных хостов

traceroute 8.8.8.8      # Linux/macOS
tracert 8.8.8.8          # Windows

Traceroute шлёт пакеты с постепенно увеличивающимся TTL (1, 2, 3...). Каждый маршрутизатор на пути, получив пакет с TTL, уменьшает его на 1; когда TTL становится 0, маршрутизатор отбрасывает пакет и отправляет обратно ICMP Time Exceeded с указанием своего IP. Так по очереди «подсвечивается» каждый хоп на пути — сначала ближайший роутер (TTL=1 истекает у него), потом следующий (TTL=2) и так далее, пока пакет не дойдёт до цели.

3. HTTP/S, TLS, методы

curl -v https://vk.com      # -v показывает весь handshake: TCP connect, TLS handshake, заголовки запроса/ответа
curl -I https://vk.com      # только заголовки ответа
openssl s_client -connect vk.com:443 -brief   # детали TLS-сертификата и версии протокола

Прогнать вручную запросы разными методами на тестовый сервис (например, httpbin.org): curl -X GET/POST/PUT/DELETE/PATCH https://httpbin.org/anything — увидеть, как сервис получает метод и тело запроса.

4. Порты и процессы

ss -tulpn                        # какие порты слушаются и каким процессом (Linux)
netstat -ano | findstr :80       # Windows-аналог
Test-NetConnection -ComputerName example.com -Port 443   # PowerShell: проверка доступности порта на удалённом хосте
nc -zv example.com 443           # аналог на Linux

5. Load average и сетевые утилиты диагностики

uptime          # load average за 1/5/15 минут
ping -c 4 8.8.8.8

Load average — среднее число процессов, находящихся в состоянии "runnable" (выполняются или ждут CPU) либо в непрерываемом ожидании ввода-вывода (D-state), усреднённое за 1/5/15 минут. Число выше количества ядер CPU не всегда означает перегрузку процессора — часто это диск/сеть (процессы висят в D-state в ожидании I/O), поэтому load average нужно смотреть вместе с top/vmstat, а не изолированно.

6. Прогон полного пути запроса

Разобрать по шагам, что происходит при вводе vk.com в браузере и Enter — от DNS-резолвинга до отрисовки страницы (см. ответ в QUESTIONS.md) — и свериться с реальным выводом curl -v из пункта 3, где видны все те же этапы вживую (TCP connect, TLS handshake, HTTP-запрос/ответ).

Что это даёт в разговоре с интервьюером

  • Уверенное владение диагностическими утилитами (dig, traceroute, curl -v, ss) — не только знание теории, но и что конкретно смотреть в выводе команды.
  • Понимание TCP/UDP, HTTP/TLS не абстрактно, а с привязкой к реальному выводу curl -v/openssl s_client.
  • Способность разобрать сетевой путь запроса по шагам под живым вопросом на собеседовании.

Как это ложится в легенду

Сетевая база — pet-проработка теории, не привязанная к конкретному эпизоду в компаниях (сети явно не выделены как отдельная строка стека ни в АО ТНИИС, ни в ОКБ СУХОЙ). На собеседовании это честно позиционируется как фундаментальные знания, которые нарабатывались параллельно с администрированием Linux-серверов (Astra/CentOS) в обеих ролях — там сетевая диагностика неизбежно возникала как часть повседневной работы, здесь она отдельно систематизирована и углублена.