Skip to the content.

Вернуться к главной странице, списку всех тем

2. Глобальная сеть Интернет, правила передачи данных в этой сети

Что ты узнаешь: как запрос из браузера доходит до сервера и обратно, что такое IP, порт, DNS и TLS, как настроить nginx перед своим приложением и включить HTTPS

Что нужно знать заранее: тема 1 — терминал, права, systemd, порты

Сколько времени займёт: 3 часа теории + 6–8 часов практики

Твой шаг в сквозном проекте: поставишь nginx перед сервисом «Заметки», дашь ему доменное имя и включишь HTTPS — снаружи приложение станет выглядеть как настоящий сайт


Сеть — совокупность устройств и соединяющих их каналов связи (кабели, Wi-Fi, сетевое оборудование), позволяющая обмениваться информацией. Сети обеспечивают:

Когда два компьютера соединены кабелем или через Wi-Fi, они могут передавать данные друг другу. Множество таких соединений образует сеть:

Сетевые технологии — всё, что помогает устройствам общаться:

Представь, что ты хочешь отправить сообщение другу по сети. Можно писать его с заглавной буквы или без, ставить точку или нет. Как другу понять, что пишешь именно ты и что это, скажем, файл, а не письмо? Нужно заранее договориться о формате обмена — это и есть протокол

Основные сетевые протоколы

TCP/IP — стек (набор) протоколов, организованных в четыре уровня. TCP отвечает за надёжность доставки, IP — за адресацию и маршрутизацию

Модель TCP/IP состоит из четырёх уровней:

  1. Прикладной уровень (Application Layer) Взаимодействие пользовательских программ с сетью:
    • HTTP — загрузка веб-страниц и других ресурсов в браузере
    • FTP — передача файлов
    • SMTP — отправка электронной почты
  2. Транспортный уровень (Transport Layer) Передача данных между двумя хостами (устройствами в сети):
    • TCP — гарантирует доставку с контролем ошибок и порядка; используется в вебе, почте, при передаче файлов, в SSH
    • UDP — упрощённый протокол без подтверждения доставки; применяется там, где важнее скорость (видеозвонки, онлайн-игры, DNS-запросы)
  3. Сетевой уровень (Internet Layer) Маршрутизация пакетов — небольших блоков данных с адресом назначения:
    • IP — адресация и доставка пакетов через множество промежуточных устройств
  4. Канальный уровень (Link Layer) Физическая передача данных между устройствами в одной локальной сети: Ethernet, Wi-Fi

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

Пример: что происходит, когда ты открываешь сайт

Ты вводишь github.com в браузере. За доли секунды происходит следующее:

  1. DNS. Браузер не знает, где находится github.com. Он спрашивает у DNS-резолвера и получает IP-адрес, например 140.82.121.4
  2. TCP-соединение. Браузер устанавливает соединение с этим IP на порт 443. Это «тройное рукопожатие»: SYNSYN-ACKACK
  3. TLS-рукопожатие. Стороны договариваются о шифровании, сервер показывает сертификат, браузер его проверяет
  4. HTTP-запрос. Внутри зашифрованного канала браузер отправляет GET / HTTP/1.1 с заголовками
  5. Ответ. Сервер (скорее всего, за ним стоит nginx) возвращает код 200 OK и HTML-страницу
  6. Отрисовка. Браузер разбирает HTML, видит ссылки на CSS, скрипты и картинки и запрашивает их — обычно уже по существующему соединению

Держи эту цепочку в голове: когда сайт «не открывается», задача инженера — понять, на каком из шести шагов всё сломалось. Отдельная команда для проверки есть на каждый шаг, и в практической части ты пройдёшь их все

Наиболее распространённые коды ответа HTTP

Три последних кода — твой ежедневный хлеб. Запомни разницу: 502 значит «приложение лежит или порт неверный», 504 — «приложение живо, но тормозит», 503 — «приложение само сказало, что не готово»

DNS: телефонная книга интернета

DNS (Domain Name System) — система доменных имён, преобразующая удобные для человека адреса (example.com) в IP-адреса (192.0.2.123)

Основные типы записей, которые тебе придётся заводить руками:

Тип Что означает Пример
A Имя → IPv4-адрес notes.ru → 192.0.2.10
AAAA Имя → IPv6-адрес notes.ru → 2001:db8::10
CNAME Имя → другое имя (псевдоним) www.notes.ru → notes.ru
MX Куда доставлять почту домена notes.ru → mail.notes.ru
TXT Произвольный текст: подтверждение владения доменом, настройки почты  
NS Какие серверы отвечают за эту зону  

У каждой записи есть TTL — на сколько секунд ответ можно закешировать. Отсюда главный практический вывод: смена DNS-записи действует не мгновенно. Если TTL был 86400 (сутки), часть пользователей ещё сутки будет ходить на старый адрес. Перед переездом TTL заранее снижают до 300 секунд

TLS: откуда берётся замочек в браузере

TLS (Transport Layer Security) — протокол шифрования данных при передаче. Он решает три задачи:

  1. Шифрование — по дороге никто не прочитает содержимое
  2. Целостность — никто не подменит данные незаметно
  3. Подлинность — ты действительно общаешься с тем сайтом, чьё имя в адресной строке, а не с подставным

Третье — самое интересное. Работает через сертификаты. Сертификат — файл, где написано «этот открытый ключ принадлежит домену notes.ru», и подпись удостоверяющего центра (CA), который это проверил. Список доверенных CA вшит в твой браузер и операционную систему

Как проходит рукопожатие (TLS 1.3, упрощённо):

  1. Клиент здоровается и присылает список поддерживаемых шифров и своё имя запрашиваемого домена (SNI — благодаря ему на одном IP может жить много HTTPS-сайтов)
  2. Сервер выбирает шифр и присылает свой сертификат
  3. Клиент проверяет сертификат: подписан ли доверенным CA, не истёк ли срок, тот ли домен указан
  4. Стороны вычисляют общий сеансовый ключ и дальше общаются симметричным шифрованием — оно быстрое

Практические вещи, о которых нужно знать:

SSH (Secure Shell) — протокол для безопасного удалённого управления серверами, работает поверх TCP. Аутентификация обычно по ключам:

Nginx: привратник перед приложением

В теме 1 наш сервис «Заметки» слушал порт 8080 и отдавал текст. В таком виде в интернет его не выпускают. Перед приложением почти всегда ставят веб-сервер — чаще всего nginx

Зачем он нужен:

Устройство конфигурации: главный файл /etc/nginx/nginx.conf, а конфиги отдельных сайтов лежат в /etc/nginx/conf.d/*.conf либо в sites-available/ со ссылкой из sites-enabled/

Минимальный конфиг обратного прокси:

server {
    listen 80;                    # на каком порту принимаем
    server_name notes.local;      # для какого доменного имени этот блок

    location / {                  # для всех путей
        proxy_pass http://127.0.0.1:8080;   # передать приложению

        # Приложение за прокси не видит настоящего клиента —
        # nginx обязан сам рассказать ему, кто пришёл и как
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Балансировка между несколькими копиями приложения:

upstream notes_backend {
    # least_conn — отдать запрос копии с наименьшим числом активных соединений
    least_conn;
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082 backup;   # включится, только если упали остальные
}

server {
    listen 80;
    location / {
        proxy_pass http://notes_backend;
    }
}

Методы балансировки: round robin (по кругу, по умолчанию), least_conn (наименее загруженному), ip_hash (один клиент всегда попадает на один сервер — нужно, если сессия хранится в памяти), weighted (server ... weight=3 — мощной машине больше запросов)

Две команды, без которых nginx не трогают:

sudo nginx -t          # проверить синтаксис конфига, НЕ применяя его
sudo systemctl reload nginx   # применить без разрыва текущих соединений

reload вместо restart — потому что перезагрузка конфига не рвёт активные запросы. А nginx -t перед этим спасает от ситуации «применил конфиг с опечаткой, nginx не поднялся, сайт лежит»

Дополнительные понятия

DHCP — протокол, автоматически выдающий устройству IP-адрес, маску, шлюз и адреса DNS при подключении к сети

MAC-адрес — уникальный аппаратный идентификатор сетевой карты (00:1A:2B:3C:4D:5E), используется внутри локальной сети

NAT — подмена адресов, благодаря которой десятки устройств домашней сети выходят в интернет через один внешний IP. Поэтому у тебя дома адрес вида 192.168.1.x — он приватный и снаружи недоступен

Firewall (брандмауэр) — фильтр входящего и исходящего трафика по правилам. В Ubuntu — ufw, в облаках — «группы безопасности»

Теоретические вопросы

  1. Что такое сетевой пакет? Ответ: Блок данных, передаваемый по сети. Состоит из заголовка (адреса отправителя и получателя, тип протокола) и полезной нагрузки (собственно данные). Аналогия: конверт с адресом снаружи и письмом внутри — маршрутизаторы читают только адрес

  2. Что такое IP-адрес и зачем он нужен? Ответ: Уникальный идентификатор устройства в сети, «почтовый адрес» компьютера. IPv4 выглядит как 192.168.1.1 (четыре числа от 0 до 255), эти адреса практически исчерпаны. IPv6 — 2001:0db8:85a3::7334, адресов в нём практически неограниченно

  3. Чем приватный IP-адрес отличается от публичного? Ответ: Приватные диапазоны (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) используются только внутри локальных сетей и не маршрутизируются в интернете. Наружу такие устройства выходят через NAT под общим публичным адресом

  4. Что такое сетевой порт? Ответ: Число от 1 до 65535, указывающее, какому приложению на устройстве предназначены данные. Если IP — адрес дома, порт — номер квартиры. Один IP обслуживает множество сервисов благодаря портам

  5. Какие популярные порты ты знаешь? Ответ: 80 — HTTP, 443 — HTTPS, 22 — SSH, 53 — DNS, 25/587 — SMTP, 5432 — PostgreSQL, 3306 — MySQL, 6379 — Redis, 9090 — Prometheus

  6. Что такое стек TCP/IP? Ответ: Набор протоколов из четырёх уровней: канальный (Ethernet, Wi-Fi), сетевой (IP), транспортный (TCP, UDP), прикладной (HTTP, SSH, DNS). Каждый уровень добавляет свой заголовок при отправке и снимает его при получении

  7. В чём разница между TCP, UDP и ICMP? Ответ: TCP — с установкой соединения, гарантирует доставку и порядок; как заказное письмо с уведомлением. UDP — без соединения и гарантий, зато быстро; как открытка. ICMP — служебный протокол диагностики, не передаёт пользовательские данные, на нём работает ping

  8. Что такое «тройное рукопожатие» TCP? Ответ: Установка соединения в три шага: клиент шлёт SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. Только после этого начинается передача данных. Именно поэтому у TCP выше задержка на старте, чем у UDP

  9. Какие бывают HTTP-методы, заголовки и коды ответа? Ответ: Методы: GET (получить), POST (создать), PUT/PATCH (обновить), DELETE (удалить), HEAD (только заголовки). Заголовки: Content-Type, Authorization, User-Agent, Cookie. Коды: 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера

  10. Чем 502 отличается от 504 и от 503? Ответ: 502 Bad Gateway — прокси не смог соединиться с приложением (оно упало или указан не тот порт). 504 Gateway Timeout — соединился, но не дождался ответа в отведённое время (приложение тормозит). 503 Service Unavailable — приложение само ответило, что не готово принимать запросы

  11. Что такое DNS и как он работает? Ответ: Распределённая система преобразования доменных имён в IP-адреса. Резолвер спрашивает у корневых серверов, кто отвечает за зону .com, те — у серверов .com, те — у серверов домена, и наконец приходит IP. Ответ кешируется на время TTL

  12. Что такое TTL у DNS-записи и почему это важно на практике? Ответ: Время в секундах, на которое ответ можно закешировать. Пока TTL не истёк, клиенты используют старый адрес. Перед переносом сервиса TTL заранее снижают, иначе часть пользователей будет ходить на старый сервер ещё сутки

  13. Чем A отличается от CNAME? Ответ: A указывает прямо на IP-адрес, CNAME — на другое доменное имя, которое потом само разрешается в IP. CNAME нельзя ставить на корень домена и нельзя совмещать с другими записями того же имени

  14. Что такое TLS и какие три задачи он решает? Ответ: Протокол шифрования канала. Обеспечивает конфиденциальность (никто не прочитает), целостность (никто не подменит) и подлинность сервера (ты общаешься с тем, чьё имя в адресной строке — это подтверждает сертификат)

  15. Что такое сертификат и кто такой удостоверяющий центр? Ответ: Сертификат связывает доменное имя с открытым ключом и подписан удостоверяющим центром (CA). Браузер доверяет ограниченному списку CA, вшитому в систему. Если подпись неизвестна или домен не совпадает — браузер показывает предупреждение

  16. Чем самоподписанный сертификат отличается от выданного Let’s Encrypt? Ответ: Шифрование одинаковое. Разница в доверии: самоподписанный никем не подтверждён, браузер ругается. Let’s Encrypt — бесплатный CA, которому доверяют все браузеры; сертификат живёт 90 дней и обновляется автоматически через certbot

  17. Что такое SNI и зачем он нужен? Ответ: Расширение TLS, в котором клиент сообщает запрашиваемое доменное имя ещё до шифрования. Без него сервер не знал бы, какой из сертификатов предъявить, и на одном IP-адресе нельзя было бы разместить несколько HTTPS-сайтов

  18. Что такое обратный прокси и зачем ставить nginx перед приложением? Ответ: Сервер, который принимает запросы клиентов и передаёт их вглубь, приложению. Даёт терминацию TLS, отдачу статики, балансировку, ограничение частоты запросов, единые логи и возможность менять приложение, не трогая внешний интерфейс

  19. Чем nginx -s reload лучше, чем restart? Ответ: reload перечитывает конфиг, запускает новые рабочие процессы и даёт старым доработать текущие запросы — простоя нет. restart рвёт все соединения. Перед любым применением конфига делают nginx -t

  20. Какие методы балансировки поддерживает nginx? Ответ: Round Robin (по кругу, по умолчанию), Least Connections (наименее загруженному), IP-hash (клиент закрепляется за сервером), Weighted (пропорционально весам). Плюс пассивные проверки: сервер, который отвечает ошибками, временно выводится из ротации

  21. Зачем nginx проставляет заголовок X-Forwarded-For? Ответ: Приложение за прокси видит IP самого прокси, а не клиента. В X-Forwarded-For nginx кладёт настоящий адрес клиента — иначе в логах приложения все запросы будут «от 127.0.0.1»

  22. Что такое клиент и сервер? Ответ: Клиент инициирует запрос (браузер, мобильное приложение, curl), сервер отвечает на него (веб-сервер, база данных). Одна и та же программа может быть и тем, и другим: nginx — сервер для браузера и клиент для приложения

  23. Что такое API? Ответ: Набор правил, по которым одна программа обращается к другой. Аналогия: меню в ресторане — список того, что можно заказать, и как это сделать; внутреннее устройство кухни клиенту не видно

  24. Что такое фронтенд и бэкенд? Ответ: Фронтенд — видимая часть, работающая в браузере (HTML, CSS, JavaScript). Бэкенд — серверная часть: бизнес-логика, работа с базой, безопасность, обмен с другими сервисами через API

  25. Что такое VPN и чем он отличается от прокси? Ответ: VPN создаёт зашифрованный туннель и заворачивает в него весь трафик устройства на уровне сети. Прокси работает на уровне приложения и обслуживает только тот трафик, который явно на него направили (обычно только браузер)

  26. Что такое firewall? Ответ: Фильтр трафика по правилам: что пропустить, что заблокировать. Основной принцип — «запрещено всё, что не разрешено явно». Наружу открывают только нужные порты, обычно 22, 80 и 443

  27. Что такое «облако»? Ответ: Модель аренды вычислительных ресурсов через интернет с оплатой по факту использования. Раньше каждая фабрика строила свою электростанцию, теперь все подключаются к общей сети и платят за киловатты. Подробно — в теме 6

Вопросы с собеседований

  1. Что такое кэширующий сервер и какие проблемы он решает? Ответ: Промежуточный сервер, который хранит копии часто запрашиваемых ответов и отдаёт их сам, не беспокоя приложение. Снижает нагрузку на бэкенд и базу, ускоряет ответ пользователю, помогает пережить всплеск трафика. Примеры: кеш в nginx, Varnish, CDN. Главная сложность не в кешировании, а в инвалидации — как понять, что копия устарела

  2. По какому протоколу работает DNS? Ответ: Обычно UDP на порту 53 — запрос и ответ короткие, соединение устанавливать дорого. На TCP переходят, когда ответ не помещается в пакет (например, при передаче зоны между серверами). Есть и зашифрованные варианты: DNS over TLS (853) и DNS over HTTPS (443)

  3. Что делает DNS-сервер, если не нашёл запись у себя? Ответ: Рекурсивный резолвер сам идёт по цепочке: корневые серверы → серверы зоны (.ru) → серверы домена, и возвращает клиенту готовый ответ. Авторитативный сервер так не делает — он отвечает только за свои зоны, а на чужой запрос вернёт отказ или отсылку. Полученный ответ резолвер кеширует на время TTL

  4. Что такое SMTP и как он работает? Ответ: Протокол отправки почты. Почтовый клиент передаёт письмо серверу (порт 587 с шифрованием), сервер отправителя находит через DNS-запись MX сервер получателя и передаёт письмо ему (порт 25). Забирают почту уже другими протоколами — IMAP или POP3. Для защиты от подделки отправителя используют записи SPF, DKIM и DMARC — все они хранятся в DNS

  5. Что такое выделенный IP-адрес в облаке и как ограничить доступ к приложению? Ответ: Статический публичный адрес, закреплённый за твоим аккаунтом: он не меняется при пересоздании сервера. Ограничивают доступ на нескольких уровнях: группой безопасности облака (пускать 22-й порт только со своего адреса), локальным файрволом (ufw), а на уровне приложения — директивами allow и deny в nginx. Подробнее в теме 6

  6. Опиши жизненный цикл HTTP-запроса. Ответ: Разрешение имени через DNS → установка TCP-соединения (тройное рукопожатие) → рукопожатие TLS, если HTTPS → отправка запроса со строкой метода и заголовками → обработка на сервере → ответ с кодом состояния, заголовками и телом → закрытие или переиспользование соединения (keep-alive). Умение разложить сбой по этим шагам и есть навык диагностики

  7. Что такое keep-alive и зачем он нужен? Ответ: Переиспользование одного TCP-соединения для нескольких запросов. Без него на каждую картинку пришлось бы заново делать тройное рукопожатие и рукопожатие TLS — это десятки миллисекунд на ровном месте. В HTTP/1.1 включено по умолчанию. Отсюда же практическое следствие: балансировка по соединениям распределяет нагрузку тем хуже, чем дольше живут соединения

  8. Чем HTTP/2 отличается от HTTP/1.1, а HTTP/3 — от обоих? Ответ: HTTP/1.1 — текстовый, в одном соединении запросы идут по очереди. HTTP/2 — двоичный, умеет мультиплексирование: много запросов параллельно в одном соединении, плюс сжатие заголовков. Но он работает поверх TCP, поэтому потеря одного пакета тормозит все потоки сразу — это называют блокировкой начала очереди. HTTP/3 переносит всё на QUIC поверх UDP, где потоки независимы, и заодно ускоряет установку соединения

  9. Что такое сессионная привязка (sticky sessions) и почему её стараются избегать? Ответ: Балансировщик закрепляет клиента за конкретным сервером — обычно по IP или cookie. Нужна, если сессия хранится в памяти сервера. Плоха тем, что мешает равномерной балансировке, а при перезапуске сервера пользователи теряют сессии. Правильное решение — хранить состояние снаружи, например в Redis; тогда любая копия приложения обслужит любого пользователя, и масштабирование из темы 5 начинает работать

  10. Что такое CORS и почему браузер блокирует запрос? Ответ: Правило браузера: скрипт со страницы одного домена не может читать ответы с другого, если тот явно не разрешил это заголовком Access-Control-Allow-Origin. Для «непростых» запросов браузер сначала посылает предварительный запрос методом OPTIONS. Важная деталь для диагностики: ограничение существует только в браузере — тот же запрос через curl пройдёт, и это регулярно сбивает с толку

  11. Что такое MTU и как проявляется его неверная настройка? Ответ: Максимальный размер пакета, обычно 1500 байт. Симптом неверного MTU характерный: небольшие запросы проходят, а крупные зависают — соединение устанавливается, но данные не идут. Чаще всего встречается в туннелях (VPN, оверлейные сети Kubernetes), где заголовки съедают часть размера. Проверяют пингом с запретом фрагментации: ping -M do -s 1472 адрес

  12. Как быстро понять, где именно теряется запрос? Ответ: По шагам: dig — разрешается ли имя; ping и traceroute — доходит ли до узла и где обрывается путь; telnet адрес порт или nc -vz — открыт ли порт; curl -v — доходит ли запрос до приложения; логи nginx — дошёл ли он до прокси; логи приложения — дошёл ли внутрь. Полезен вывод curl -w с таймингами: он показывает, что именно долго — разрешение имени, соединение, TLS или сам ответ

  13. Зачем на веб-сервере включают сжатие? Ответ: Директивы gzip on или более эффективный brotli уменьшают объём текстовых ответов (HTML, CSS, JS, JSON) в несколько раз, ускоряя загрузку и экономя трафик. Сжимать картинки и видео бессмысленно — они уже сжаты, и процессор потратится впустую

  14. Что такое WebSocket и чем он отличается от обычного HTTP? Ответ: Постоянное двустороннее соединение: сервер может сам отправить сообщение клиенту, не дожидаясь запроса. Начинается как обычный HTTP-запрос с заголовком Upgrade, после чего протокол меняется. Для nginx это важно: чтобы соединение не рвалось, в конфиге прокси нужно явно пробрасывать заголовки Upgrade и Connection и увеличивать таймауты

  15. Что такое HSTS? Ответ: Заголовок Strict-Transport-Security, которым сервер сообщает браузеру: «ко мне ходить только по HTTPS». Браузер запоминает это на указанный срок и больше не делает первого незашифрованного запроса, который можно перехватить. Внедрять стоит осознанно: пока срок не истёк, вернуться на HTTP не получится

Практическая часть

Задание 1. Поймать живой пакет

Цель: увидеть своими глазами, из чего состоит сетевой пакет

Шаги: в одном терминале запусти захват ICMP-пакетов:

sudo tcpdump -nn -c1 -X icmp

В другом терминале:

ping -c1 8.8.8.8

Ожидаемый вывод: в первом окне появится байт-дамп одного пакета: слева шестнадцатеричные байты, справа их текстовое представление. Найди в нём IP-адреса отправителя и получателя

Типичные ошибки:

Задание 2. Разобраться в своей сети

Цель: уметь ответить, какой у машины адрес, MAC и какие порты открыты

Шаги:

ip addr show          # интерфейсы, IPv4- и IPv6-адреса
ip link show          # MAC-адреса
ip route              # через какой шлюз идёт трафик наружу
ss -tulpn             # какие порты слушаются и каким процессом

Ответь письменно: какой у тебя адрес — приватный или публичный? Как ты это определил? Какой процесс слушает порт 8080 (это должны быть «Заметки» из темы 1)?

Задание 3. Почувствовать разницу между TCP и UDP

Цель: понять на практике, что значит «с установкой соединения» и «без»

Шаги:

TCP — терминал 1: nc -l 12345, терминал 2: echo "привет TCP" | nc localhost 12345

UDP — терминал 1: nc -u -l 12346, терминал 2: echo "привет UDP" | nc -u localhost 12346

Теперь главный эксперимент: отправь сообщение туда, где никто не слушает

echo "есть кто?" | nc localhost 12399        # TCP: Connection refused — сразу ошибка
echo "есть кто?" | nc -u localhost 12399     # UDP: тишина, отправитель ничего не узнал

Ожидаемый вывод: TCP честно сообщает об ошибке, UDP молча теряет данные. В этом вся разница между «заказным письмом» и «открыткой»

Задание 4. Ручной HTTP-запрос и разбор TLS

Цель: увидеть протокол без браузера

Шаги:

curl -v https://ya.ru                              # подробный вывод: TLS, заголовки, тело
curl -I https://ya.ru                              # только заголовки ответа
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://ya.ru   # только код и время

Посмотри на сертификат сайта:

echo | openssl s_client -connect ya.ru:443 -servername ya.ru 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Ожидаемый вывод: кому выдан сертификат, кто его выдал (тот самый CA) и до какой даты он действителен

Ответь письменно: найди в выводе curl -v строки, где происходит TLS-рукопожатие. Какая версия TLS использована?

Задание 5. DNS

Цель: научиться проверять, куда на самом деле указывает имя

Шаги:

dig ya.ru A                 # IPv4-адрес
dig ya.ru AAAA              # IPv6-адрес
dig ya.ru MX                # почтовые серверы домена
dig +short ya.ru            # только ответ, без лишнего
dig @8.8.8.8 ya.ru          # спросить конкретно у DNS-сервера Google
dig ya.ru +trace            # проследить весь путь: корень → .ru → ya.ru

Ожидаемый вывод: в секции ANSWER — адреса и TTL записей. +trace показывает всю цепочку делегирования

Типичные ошибки:

Задание 6. Firewall

Цель: научиться открывать и закрывать порты

Шаги:

sudo ufw status                    # текущее состояние
sudo ufw allow 12345/tcp           # открыть порт
sudo ufw status numbered
sudo ufw delete allow 12345/tcp    # закрыть обратно

Типичные ошибки:

Задание 7. Сквозной проект: nginx перед «Заметками»

Цель: превратить приложение из темы 1 в нормальный сайт с доменным именем и HTTPS

Шаги:

  1. Убедись, что «Заметки» работают:

    systemctl status notes
    curl http://localhost:8080/
    
  2. Установи nginx и проверь, что он поднялся:

    sudo apt install -y nginx
    curl http://localhost/          # должна открыться стартовая страница nginx
    
  3. Создай конфиг /etc/nginx/conf.d/notes.conf:

    server {
        listen 80;
        server_name notes.local;
    
        # Логи именно этого сайта — отдельно от всех остальных
        access_log /var/log/nginx/notes-access.log;
        error_log  /var/log/nginx/notes-error.log;
    
        location / {
            proxy_pass http://127.0.0.1:8080;
    
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
    
            # Сколько ждать приложение, прежде чем ответить клиенту 504
            proxy_connect_timeout 3s;
            proxy_read_timeout    10s;
        }
    }
    
  4. Отключи дефолтный сайт, проверь конфиг и примени:

    sudo rm -f /etc/nginx/sites-enabled/default
    sudo nginx -t                     # обязательно перед применением
    sudo systemctl reload nginx
    
  5. Придумай доменное имя. Настоящего домена у нас нет, поэтому обманем свой компьютер — добавь в /etc/hosts строку:

    127.0.0.1   notes.local
    

    Это локальный аналог DNS-записи: файл /etc/hosts проверяется раньше, чем DNS-сервер

  6. Проверь:

    curl http://notes.local/
    curl -I http://notes.local/healthz
    
  7. Теперь HTTPS. Выпусти самоподписанный сертификат:

    sudo mkdir -p /etc/nginx/tls
    sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
      -keyout /etc/nginx/tls/notes.key \
      -out    /etc/nginx/tls/notes.crt \
      -subj "/CN=notes.local"
    

    Разбор флагов: -x509 — сразу готовый сертификат, а не запрос на выпуск; -nodes — не шифровать приватный ключ паролем (иначе nginx будет спрашивать его при каждом старте); -days 365 — срок жизни; -subj "/CN=notes.local" — для какого имени выдан

  8. Замени конфиг /etc/nginx/conf.d/notes.conf на версию с HTTPS:

    # Весь HTTP-трафик отправляем на HTTPS
    server {
        listen 80;
        server_name notes.local;
        return 301 https://$host$request_uri;
    }
    
    server {
        listen 443 ssl;
        http2 on;
        server_name notes.local;
    
        ssl_certificate     /etc/nginx/tls/notes.crt;
        ssl_certificate_key /etc/nginx/tls/notes.key;
        ssl_protocols       TLSv1.2 TLSv1.3;
    
        access_log /var/log/nginx/notes-access.log;
        error_log  /var/log/nginx/notes-error.log;
    
        location / {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
    
    sudo nginx -t && sudo systemctl reload nginx
    
  9. Проверь результат:

    curl -k https://notes.local/            # -k = не проверять сертификат, он самоподписанный
    curl -I http://notes.local/             # должен вернуться 301 на https
    

    Открой https://notes.local в браузере: увидишь предупреждение о недоверенном сертификате — это ожидаемо и ровно то, что мы разбирали в теории

  10. Сломай и почини. Останови приложение и посмотри, что скажет nginx:

    sudo systemctl stop notes
    curl -k -i https://notes.local/         # ожидаем 502 Bad Gateway
    sudo tail -n 5 /var/log/nginx/notes-error.log
    sudo systemctl start notes
    curl -k -i https://notes.local/         # снова 200
    

    Прочитай строку в notes-error.log — там будет connect() failed (111: Connection refused). Так выглядит настоящая диагностика 502 на боевом сервере

Ожидаемый вывод: https://notes.local отдаёт заметки; HTTP редиректит на HTTPS; при остановленном приложении nginx возвращает 502 и пишет причину в лог

Типичные ошибки:

Проверь себя: тема освоена, если ты можешь

Следующая тема: Git, GitLab, GitHub →