Вернуться к главной странице, списку всех тем
2. Глобальная сеть Интернет, правила передачи данных в этой сети
Что ты узнаешь: как запрос из браузера доходит до сервера и обратно, что такое IP, порт, DNS и TLS, как настроить nginx перед своим приложением и включить HTTPS
Что нужно знать заранее: тема 1 — терминал, права, systemd, порты
Сколько времени займёт: 3 часа теории + 6–8 часов практики
Твой шаг в сквозном проекте: поставишь nginx перед сервисом «Заметки», дашь ему доменное имя и включишь HTTPS — снаружи приложение станет выглядеть как настоящий сайт
Сеть — совокупность устройств и соединяющих их каналов связи (кабели, Wi-Fi, сетевое оборудование), позволяющая обмениваться информацией. Сети обеспечивают:
- удалённую работу — сотрудники используют общие ресурсы компании из дома
- быстрый обмен данными — файл мгновенно доставляется коллеге на другом континенте
- работу интернет-сервисов — социальные сети, онлайн-магазины, стриминговые платформы
Когда два компьютера соединены кабелем или через Wi-Fi, они могут передавать данные друг другу. Множество таких соединений образует сеть:
- в офисе компьютеры объединены в локальную сеть — можно совместно использовать файлы, принтер и общий доступ в Интернет
- Интернет — глобальная сеть, связывающая миллиарды устройств по всему миру: огромное количество соединённых между собой компьютеров и маршрутизаторов
Сетевые технологии — всё, что помогает устройствам общаться:
- Wi-Fi — беспроводная передача данных
- Ethernet — проводная технология, устройства соединяются кабелями
- протоколы — наборы правил, определяющих, как именно передаются данные
Представь, что ты хочешь отправить сообщение другу по сети. Можно писать его с заглавной буквы или без, ставить точку или нет. Как другу понять, что пишешь именно ты и что это, скажем, файл, а не письмо? Нужно заранее договориться о формате обмена — это и есть протокол
Основные сетевые протоколы
TCP/IP — стек (набор) протоколов, организованных в четыре уровня. TCP отвечает за надёжность доставки, IP — за адресацию и маршрутизацию
Модель TCP/IP состоит из четырёх уровней:
- Прикладной уровень (Application Layer)
Взаимодействие пользовательских программ с сетью:
- HTTP — загрузка веб-страниц и других ресурсов в браузере
- FTP — передача файлов
- SMTP — отправка электронной почты
- Транспортный уровень (Transport Layer)
Передача данных между двумя хостами (устройствами в сети):
- TCP — гарантирует доставку с контролем ошибок и порядка; используется в вебе, почте, при передаче файлов, в SSH
- UDP — упрощённый протокол без подтверждения доставки; применяется там, где важнее скорость (видеозвонки, онлайн-игры, DNS-запросы)
- Сетевой уровень (Internet Layer)
Маршрутизация пакетов — небольших блоков данных с адресом назначения:
- IP — адресация и доставка пакетов через множество промежуточных устройств
- Канальный уровень (Link Layer) Физическая передача данных между устройствами в одной локальной сети: Ethernet, Wi-Fi
Каждый уровень добавляет к данным свой заголовок — как если бы письмо клали в конверт, конверт в пакет, пакет в мешок. На принимающей стороне всё разворачивается в обратном порядке
Пример: что происходит, когда ты открываешь сайт
Ты вводишь github.com в браузере. За доли секунды происходит следующее:
- DNS. Браузер не знает, где находится
github.com. Он спрашивает у DNS-резолвера и получает IP-адрес, например140.82.121.4 - TCP-соединение. Браузер устанавливает соединение с этим IP на порт 443. Это «тройное рукопожатие»:
SYN→SYN-ACK→ACK - TLS-рукопожатие. Стороны договариваются о шифровании, сервер показывает сертификат, браузер его проверяет
- HTTP-запрос. Внутри зашифрованного канала браузер отправляет
GET / HTTP/1.1с заголовками - Ответ. Сервер (скорее всего, за ним стоит nginx) возвращает код
200 OKи HTML-страницу - Отрисовка. Браузер разбирает HTML, видит ссылки на CSS, скрипты и картинки и запрашивает их — обычно уже по существующему соединению
Держи эту цепочку в голове: когда сайт «не открывается», задача инженера — понять, на каком из шести шагов всё сломалось. Отдельная команда для проверки есть на каждый шаг, и в практической части ты пройдёшь их все
Наиболее распространённые коды ответа HTTP
- 200 OK — запрос выполнен успешно
- 301 Moved Permanently — ресурс окончательно перемещён на новый адрес
- 307 Temporary Redirect — временное перенаправление
- 308 Permanent Redirect — постоянное перенаправление (аналог 301, но с сохранением метода запроса)
- 400 Bad Request — некорректный запрос
- 401 Unauthorized — требуется аутентификация (ты не представился)
- 403 Forbidden — доступ запрещён (представился, но прав не хватает)
- 404 Not Found — ресурс не найден
- 405 Method Not Allowed — метод запроса не поддерживается
- 418 I’m a teapot — шуточный код из RFC 2324, сервер — чайник и не может заварить кофе
- 429 Too Many Requests — превышен лимит запросов
- 499 Client Closed Request — клиент закрыл соединение, не дождавшись ответа (нестандартный код, придуман в nginx)
- 500 Internal Server Error — внутренняя ошибка сервера
- 502 Bad Gateway — nginx не смог достучаться до приложения за ним
- 503 Service Unavailable — сервис временно недоступен
- 504 Gateway Timeout — nginx достучался, но не дождался ответа
Три последних кода — твой ежедневный хлеб. Запомни разницу: 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) — протокол шифрования данных при передаче. Он решает три задачи:
- Шифрование — по дороге никто не прочитает содержимое
- Целостность — никто не подменит данные незаметно
- Подлинность — ты действительно общаешься с тем сайтом, чьё имя в адресной строке, а не с подставным
Третье — самое интересное. Работает через сертификаты. Сертификат — файл, где написано «этот открытый ключ принадлежит домену notes.ru», и подпись удостоверяющего центра (CA), который это проверил. Список доверенных CA вшит в твой браузер и операционную систему
Как проходит рукопожатие (TLS 1.3, упрощённо):
- Клиент здоровается и присылает список поддерживаемых шифров и своё имя запрашиваемого домена (SNI — благодаря ему на одном IP может жить много HTTPS-сайтов)
- Сервер выбирает шифр и присылает свой сертификат
- Клиент проверяет сертификат: подписан ли доверенным CA, не истёк ли срок, тот ли домен указан
- Стороны вычисляют общий сеансовый ключ и дальше общаются симметричным шифрованием — оно быстрое
Практические вещи, о которых нужно знать:
- Let’s Encrypt — бесплатный CA, выдаёт сертификаты автоматически по протоколу ACME. Утилита
certbotполучает и раз в 60 дней обновляет их сама. Сертификат живёт 90 дней, и просроченный сертификат — одна из самых частых причин ночных инцидентов - Самоподписанный сертификат — сделан своими руками, без CA. Шифрование работает, но браузер ругается: подлинность никто не подтвердил. Годится для учёбы и внутренних сервисов
- Терминация TLS — расшифровка обычно происходит на nginx или балансировщике, а до приложения трафик идёт уже открытым, внутри доверенной сети. Поэтому приложению не нужно ничего знать про сертификаты
SSH (Secure Shell) — протокол для безопасного удалённого управления серверами, работает поверх TCP. Аутентификация обычно по ключам:
- открытый ключ размещается на сервере в
~/.ssh/authorized_keys, его можно свободно распространять - закрытый ключ хранится только у тебя и никогда никуда не отправляется
Nginx: привратник перед приложением
В теме 1 наш сервис «Заметки» слушал порт 8080 и отдавал текст. В таком виде в интернет его не выпускают. Перед приложением почти всегда ставят веб-сервер — чаще всего nginx
Зачем он нужен:
- Обратный прокси (reverse proxy). Принимает запросы на 80/443 и передаёт их приложению на 8080. Приложение можно перезапускать, менять порт, переписать на другом языке — снаружи ничего не меняется
- Терминация TLS. Сертификат лежит в одном месте, а не в каждом приложении
- Отдача статики. Картинки и стили 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, в облаках — «группы безопасности»
Теоретические вопросы
-
Что такое сетевой пакет? Ответ: Блок данных, передаваемый по сети. Состоит из заголовка (адреса отправителя и получателя, тип протокола) и полезной нагрузки (собственно данные). Аналогия: конверт с адресом снаружи и письмом внутри — маршрутизаторы читают только адрес
-
Что такое IP-адрес и зачем он нужен? Ответ: Уникальный идентификатор устройства в сети, «почтовый адрес» компьютера. IPv4 выглядит как
192.168.1.1(четыре числа от 0 до 255), эти адреса практически исчерпаны. IPv6 —2001:0db8:85a3::7334, адресов в нём практически неограниченно -
Чем приватный IP-адрес отличается от публичного? Ответ: Приватные диапазоны (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) используются только внутри локальных сетей и не маршрутизируются в интернете. Наружу такие устройства выходят через NAT под общим публичным адресом -
Что такое сетевой порт? Ответ: Число от 1 до 65535, указывающее, какому приложению на устройстве предназначены данные. Если IP — адрес дома, порт — номер квартиры. Один IP обслуживает множество сервисов благодаря портам
-
Какие популярные порты ты знаешь? Ответ: 80 — HTTP, 443 — HTTPS, 22 — SSH, 53 — DNS, 25/587 — SMTP, 5432 — PostgreSQL, 3306 — MySQL, 6379 — Redis, 9090 — Prometheus
-
Что такое стек TCP/IP? Ответ: Набор протоколов из четырёх уровней: канальный (Ethernet, Wi-Fi), сетевой (IP), транспортный (TCP, UDP), прикладной (HTTP, SSH, DNS). Каждый уровень добавляет свой заголовок при отправке и снимает его при получении
-
В чём разница между TCP, UDP и ICMP? Ответ: TCP — с установкой соединения, гарантирует доставку и порядок; как заказное письмо с уведомлением. UDP — без соединения и гарантий, зато быстро; как открытка. ICMP — служебный протокол диагностики, не передаёт пользовательские данные, на нём работает
ping -
Что такое «тройное рукопожатие» TCP? Ответ: Установка соединения в три шага: клиент шлёт
SYN, сервер отвечаетSYN-ACK, клиент подтверждаетACK. Только после этого начинается передача данных. Именно поэтому у TCP выше задержка на старте, чем у UDP -
Какие бывают HTTP-методы, заголовки и коды ответа? Ответ: Методы:
GET(получить),POST(создать),PUT/PATCH(обновить),DELETE(удалить),HEAD(только заголовки). Заголовки:Content-Type,Authorization,User-Agent,Cookie. Коды: 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера -
Чем 502 отличается от 504 и от 503? Ответ: 502 Bad Gateway — прокси не смог соединиться с приложением (оно упало или указан не тот порт). 504 Gateway Timeout — соединился, но не дождался ответа в отведённое время (приложение тормозит). 503 Service Unavailable — приложение само ответило, что не готово принимать запросы
-
Что такое DNS и как он работает? Ответ: Распределённая система преобразования доменных имён в IP-адреса. Резолвер спрашивает у корневых серверов, кто отвечает за зону
.com, те — у серверов.com, те — у серверов домена, и наконец приходит IP. Ответ кешируется на время TTL -
Что такое TTL у DNS-записи и почему это важно на практике? Ответ: Время в секундах, на которое ответ можно закешировать. Пока TTL не истёк, клиенты используют старый адрес. Перед переносом сервиса TTL заранее снижают, иначе часть пользователей будет ходить на старый сервер ещё сутки
-
Чем
Aотличается отCNAME? Ответ:Aуказывает прямо на IP-адрес,CNAME— на другое доменное имя, которое потом само разрешается в IP.CNAMEнельзя ставить на корень домена и нельзя совмещать с другими записями того же имени -
Что такое TLS и какие три задачи он решает? Ответ: Протокол шифрования канала. Обеспечивает конфиденциальность (никто не прочитает), целостность (никто не подменит) и подлинность сервера (ты общаешься с тем, чьё имя в адресной строке — это подтверждает сертификат)
-
Что такое сертификат и кто такой удостоверяющий центр? Ответ: Сертификат связывает доменное имя с открытым ключом и подписан удостоверяющим центром (CA). Браузер доверяет ограниченному списку CA, вшитому в систему. Если подпись неизвестна или домен не совпадает — браузер показывает предупреждение
-
Чем самоподписанный сертификат отличается от выданного Let’s Encrypt? Ответ: Шифрование одинаковое. Разница в доверии: самоподписанный никем не подтверждён, браузер ругается. Let’s Encrypt — бесплатный CA, которому доверяют все браузеры; сертификат живёт 90 дней и обновляется автоматически через
certbot -
Что такое SNI и зачем он нужен? Ответ: Расширение TLS, в котором клиент сообщает запрашиваемое доменное имя ещё до шифрования. Без него сервер не знал бы, какой из сертификатов предъявить, и на одном IP-адресе нельзя было бы разместить несколько HTTPS-сайтов
-
Что такое обратный прокси и зачем ставить nginx перед приложением? Ответ: Сервер, который принимает запросы клиентов и передаёт их вглубь, приложению. Даёт терминацию TLS, отдачу статики, балансировку, ограничение частоты запросов, единые логи и возможность менять приложение, не трогая внешний интерфейс
-
Чем
nginx -s reloadлучше, чемrestart? Ответ:reloadперечитывает конфиг, запускает новые рабочие процессы и даёт старым доработать текущие запросы — простоя нет.restartрвёт все соединения. Перед любым применением конфига делаютnginx -t -
Какие методы балансировки поддерживает nginx? Ответ: Round Robin (по кругу, по умолчанию), Least Connections (наименее загруженному), IP-hash (клиент закрепляется за сервером), Weighted (пропорционально весам). Плюс пассивные проверки: сервер, который отвечает ошибками, временно выводится из ротации
-
Зачем nginx проставляет заголовок
X-Forwarded-For? Ответ: Приложение за прокси видит IP самого прокси, а не клиента. ВX-Forwarded-Fornginx кладёт настоящий адрес клиента — иначе в логах приложения все запросы будут «от 127.0.0.1» -
Что такое клиент и сервер? Ответ: Клиент инициирует запрос (браузер, мобильное приложение,
curl), сервер отвечает на него (веб-сервер, база данных). Одна и та же программа может быть и тем, и другим: nginx — сервер для браузера и клиент для приложения -
Что такое API? Ответ: Набор правил, по которым одна программа обращается к другой. Аналогия: меню в ресторане — список того, что можно заказать, и как это сделать; внутреннее устройство кухни клиенту не видно
-
Что такое фронтенд и бэкенд? Ответ: Фронтенд — видимая часть, работающая в браузере (HTML, CSS, JavaScript). Бэкенд — серверная часть: бизнес-логика, работа с базой, безопасность, обмен с другими сервисами через API
-
Что такое VPN и чем он отличается от прокси? Ответ: VPN создаёт зашифрованный туннель и заворачивает в него весь трафик устройства на уровне сети. Прокси работает на уровне приложения и обслуживает только тот трафик, который явно на него направили (обычно только браузер)
-
Что такое firewall? Ответ: Фильтр трафика по правилам: что пропустить, что заблокировать. Основной принцип — «запрещено всё, что не разрешено явно». Наружу открывают только нужные порты, обычно 22, 80 и 443
-
Что такое «облако»? Ответ: Модель аренды вычислительных ресурсов через интернет с оплатой по факту использования. Раньше каждая фабрика строила свою электростанцию, теперь все подключаются к общей сети и платят за киловатты. Подробно — в теме 6
Вопросы с собеседований
-
Что такое кэширующий сервер и какие проблемы он решает? Ответ: Промежуточный сервер, который хранит копии часто запрашиваемых ответов и отдаёт их сам, не беспокоя приложение. Снижает нагрузку на бэкенд и базу, ускоряет ответ пользователю, помогает пережить всплеск трафика. Примеры: кеш в nginx, Varnish, CDN. Главная сложность не в кешировании, а в инвалидации — как понять, что копия устарела
-
По какому протоколу работает DNS? Ответ: Обычно UDP на порту 53 — запрос и ответ короткие, соединение устанавливать дорого. На TCP переходят, когда ответ не помещается в пакет (например, при передаче зоны между серверами). Есть и зашифрованные варианты: DNS over TLS (853) и DNS over HTTPS (443)
-
Что делает DNS-сервер, если не нашёл запись у себя? Ответ: Рекурсивный резолвер сам идёт по цепочке: корневые серверы → серверы зоны (
.ru) → серверы домена, и возвращает клиенту готовый ответ. Авторитативный сервер так не делает — он отвечает только за свои зоны, а на чужой запрос вернёт отказ или отсылку. Полученный ответ резолвер кеширует на время TTL -
Что такое SMTP и как он работает? Ответ: Протокол отправки почты. Почтовый клиент передаёт письмо серверу (порт 587 с шифрованием), сервер отправителя находит через DNS-запись
MXсервер получателя и передаёт письмо ему (порт 25). Забирают почту уже другими протоколами — IMAP или POP3. Для защиты от подделки отправителя используют записи SPF, DKIM и DMARC — все они хранятся в DNS -
Что такое выделенный IP-адрес в облаке и как ограничить доступ к приложению? Ответ: Статический публичный адрес, закреплённый за твоим аккаунтом: он не меняется при пересоздании сервера. Ограничивают доступ на нескольких уровнях: группой безопасности облака (пускать 22-й порт только со своего адреса), локальным файрволом (
ufw), а на уровне приложения — директивамиallowиdenyв nginx. Подробнее в теме 6 -
Опиши жизненный цикл HTTP-запроса. Ответ: Разрешение имени через DNS → установка TCP-соединения (тройное рукопожатие) → рукопожатие TLS, если HTTPS → отправка запроса со строкой метода и заголовками → обработка на сервере → ответ с кодом состояния, заголовками и телом → закрытие или переиспользование соединения (
keep-alive). Умение разложить сбой по этим шагам и есть навык диагностики -
Что такое keep-alive и зачем он нужен? Ответ: Переиспользование одного TCP-соединения для нескольких запросов. Без него на каждую картинку пришлось бы заново делать тройное рукопожатие и рукопожатие TLS — это десятки миллисекунд на ровном месте. В HTTP/1.1 включено по умолчанию. Отсюда же практическое следствие: балансировка по соединениям распределяет нагрузку тем хуже, чем дольше живут соединения
-
Чем HTTP/2 отличается от HTTP/1.1, а HTTP/3 — от обоих? Ответ: HTTP/1.1 — текстовый, в одном соединении запросы идут по очереди. HTTP/2 — двоичный, умеет мультиплексирование: много запросов параллельно в одном соединении, плюс сжатие заголовков. Но он работает поверх TCP, поэтому потеря одного пакета тормозит все потоки сразу — это называют блокировкой начала очереди. HTTP/3 переносит всё на QUIC поверх UDP, где потоки независимы, и заодно ускоряет установку соединения
-
Что такое сессионная привязка (sticky sessions) и почему её стараются избегать? Ответ: Балансировщик закрепляет клиента за конкретным сервером — обычно по IP или cookie. Нужна, если сессия хранится в памяти сервера. Плоха тем, что мешает равномерной балансировке, а при перезапуске сервера пользователи теряют сессии. Правильное решение — хранить состояние снаружи, например в Redis; тогда любая копия приложения обслужит любого пользователя, и масштабирование из темы 5 начинает работать
-
Что такое CORS и почему браузер блокирует запрос? Ответ: Правило браузера: скрипт со страницы одного домена не может читать ответы с другого, если тот явно не разрешил это заголовком
Access-Control-Allow-Origin. Для «непростых» запросов браузер сначала посылает предварительный запрос методомOPTIONS. Важная деталь для диагностики: ограничение существует только в браузере — тот же запрос черезcurlпройдёт, и это регулярно сбивает с толку -
Что такое MTU и как проявляется его неверная настройка? Ответ: Максимальный размер пакета, обычно 1500 байт. Симптом неверного MTU характерный: небольшие запросы проходят, а крупные зависают — соединение устанавливается, но данные не идут. Чаще всего встречается в туннелях (VPN, оверлейные сети Kubernetes), где заголовки съедают часть размера. Проверяют пингом с запретом фрагментации:
ping -M do -s 1472 адрес -
Как быстро понять, где именно теряется запрос? Ответ: По шагам:
dig— разрешается ли имя;pingиtraceroute— доходит ли до узла и где обрывается путь;telnet адрес портилиnc -vz— открыт ли порт;curl -v— доходит ли запрос до приложения; логи nginx — дошёл ли он до прокси; логи приложения — дошёл ли внутрь. Полезен выводcurl -wс таймингами: он показывает, что именно долго — разрешение имени, соединение, TLS или сам ответ -
Зачем на веб-сервере включают сжатие? Ответ: Директивы
gzip onили более эффективный brotli уменьшают объём текстовых ответов (HTML, CSS, JS, JSON) в несколько раз, ускоряя загрузку и экономя трафик. Сжимать картинки и видео бессмысленно — они уже сжаты, и процессор потратится впустую -
Что такое WebSocket и чем он отличается от обычного HTTP? Ответ: Постоянное двустороннее соединение: сервер может сам отправить сообщение клиенту, не дожидаясь запроса. Начинается как обычный HTTP-запрос с заголовком
Upgrade, после чего протокол меняется. Для nginx это важно: чтобы соединение не рвалось, в конфиге прокси нужно явно пробрасывать заголовкиUpgradeиConnectionи увеличивать таймауты -
Что такое HSTS? Ответ: Заголовок
Strict-Transport-Security, которым сервер сообщает браузеру: «ко мне ходить только по HTTPS». Браузер запоминает это на указанный срок и больше не делает первого незашифрованного запроса, который можно перехватить. Внедрять стоит осознанно: пока срок не истёк, вернуться на HTTP не получится
Практическая часть
Задание 1. Поймать живой пакет
Цель: увидеть своими глазами, из чего состоит сетевой пакет
Шаги: в одном терминале запусти захват ICMP-пакетов:
sudo tcpdump -nn -c1 -X icmp
В другом терминале:
ping -c1 8.8.8.8
Ожидаемый вывод: в первом окне появится байт-дамп одного пакета: слева шестнадцатеричные байты, справа их текстовое представление. Найди в нём IP-адреса отправителя и получателя
Типичные ошибки:
tcpdumpбезsudoне имеет прав слушать интерфейс- Ничего не поймалось — возможно, нужен явный интерфейс:
sudo tcpdump -i any -nn -c1 -X icmp
Задание 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 показывает всю цепочку делегирования
Типичные ошибки:
- Нет команды
dig— установиsudo apt install -y dnsutils - Результат отличается от того, что показывает браузер: браузер и система кешируют ответы. Локальный кеш сбрасывается
sudo systemd-resolve --flush-caches(илиresolvectl flush-caches)
Задание 6. Firewall
Цель: научиться открывать и закрывать порты
Шаги:
sudo ufw status # текущее состояние
sudo ufw allow 12345/tcp # открыть порт
sudo ufw status numbered
sudo ufw delete allow 12345/tcp # закрыть обратно
Типичные ошибки:
- Включить
ufw enableна удалённом сервере, не разрешив предварительно порт 22 — так теряют доступ к серверу. Правило: сначалаsudo ufw allow 22/tcp, потомenable
Задание 7. Сквозной проект: nginx перед «Заметками»
Цель: превратить приложение из темы 1 в нормальный сайт с доменным именем и HTTPS
Шаги:
-
Убедись, что «Заметки» работают:
systemctl status notes curl http://localhost:8080/ -
Установи nginx и проверь, что он поднялся:
sudo apt install -y nginx curl http://localhost/ # должна открыться стартовая страница nginx -
Создай конфиг
/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; } } -
Отключи дефолтный сайт, проверь конфиг и примени:
sudo rm -f /etc/nginx/sites-enabled/default sudo nginx -t # обязательно перед применением sudo systemctl reload nginx -
Придумай доменное имя. Настоящего домена у нас нет, поэтому обманем свой компьютер — добавь в
/etc/hostsстроку:127.0.0.1 notes.localЭто локальный аналог DNS-записи: файл
/etc/hostsпроверяется раньше, чем DNS-сервер -
Проверь:
curl http://notes.local/ curl -I http://notes.local/healthz -
Теперь 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"— для какого имени выдан -
Замени конфиг
/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 -
Проверь результат:
curl -k https://notes.local/ # -k = не проверять сертификат, он самоподписанный curl -I http://notes.local/ # должен вернуться 301 на httpsОткрой
https://notes.localв браузере: увидишь предупреждение о недоверенном сертификате — это ожидаемо и ровно то, что мы разбирали в теории -
Сломай и почини. Останови приложение и посмотри, что скажет 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 и пишет причину в лог
Типичные ошибки:
nginx: [emerg] bind() to 0.0.0.0:80 failed— порт 80 уже кем-то занят, ищи черезss -tulpn | grep :80- 502 при работающем приложении — почти всегда неверный порт или адрес в
proxy_pass. Проверьcurl http://127.0.0.1:8080/напрямую - Изменил конфиг, но ничего не поменялось — забыл
reload - Браузер продолжает открывать HTTP вместо HTTPS — он запомнил старый редирект; проверяй через
curl, он ничего не кеширует
Проверь себя: тема освоена, если ты можешь
- Рассказать по шагам, что происходит от ввода адреса в браузере до появления страницы
- Объяснить разницу между TCP и UDP и привести по два примера использования
- По коду ответа 502 / 503 / 504 назвать вероятную причину и место, куда смотреть
- Проверить DNS-запись через
digи объяснить, почему изменения применяются не мгновенно - Объяснить, что такое сертификат, кто его подписывает и почему браузер ругается на самоподписанный
- Написать конфиг nginx-прокси с нуля, проверить его через
nginx -tи применить без простоя - Показать своё приложение, работающее по HTTPS на доменном имени