Основы компьютерных сетей и Linux для технического собеседования

Практический курс для новичков, covering базовые принципы работы компьютерных сетей, ключевые протоколы (TCP/IP, HTTP, DNS, DHCP), работу в терминале Linux и пошаговое создание локального сервера. Материал сфокусирован на вопросах, часто встречающихся на технических собеседованиях.

1. Основы компьютерных сетей и ключевые протоколы (TCP/IP, HTTP, DNS, DHCP)

Основы компьютерных сетей и ключевые протоколы (TCP/IP, HTTP, DNS, DHCP)

Представьте: вы открываете браузер, вводите адрес сайта и через секунду видите страницу. За эти мгновения ваш компьютер обменивается данными с десятками устройств по всему миру, проходя через маршрутизаторы, серверы и DNS-системы. На техническом собеседовании вас почти наверняка спросят, как именно это работает — и поверхностного ответа будет недостаточно.

Модель OSI и стек TCP/IP

Чтобы устройства могли общаться между собой, им нужен единый «язык». Описание этого языка называется моделью сетевого взаимодействия. Существует эталонная модель OSI из семи уровней — от физического (кабели, сигналы) до прикладного (браузер, почтовый клиент). На практике используется упрощённая модель TCP/IP из четырёх уровней:

| Уровень TCP/IP | Что делает | Примеры протоколов | |---|---|---| | Прикладной | Интерфейс для приложений | HTTP, DNS, SMTP, FTP | | Транспортный | Надёжная доставка данных между процессами | TCP, UDP | | Сетевой | Адресация и маршрутизация пакетов | IP, ICMP, ARP | | Канальный | Передача данных по физическому каналу | Ethernet, Wi-Fi |

На собеседовании часто просят назвать уровни OSI или сравнить OSI с TCP/IP. Ключевое отличие: OSI — теоретическая модель, TCP/IP — то, что реально работает в интернете.

IP-адресация и подсети

Каждое устройство в сети получает IP-адрес — уникальный идентификатор, по которому к нему можно доставить данные. IPv4-адрес выглядит как четыре числа от 0 до 255, разделённых точками: 192.168.1.10.

Часть адреса обозначает сеть, а часть — хост внутри сети. Границу определяет маска подсети. Например, маска 255.255.255.0 (или /24 в CIDR-нотации) означает: первые 24 бита — сеть, последние 8 — хосты. В такой подсети может быть до устройств (адреса .0 и .255 зарезервированы).

> Приватные адреса — диапазоны 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — используются внутри локальных сетей и не маршрутизируются в интернете. Именно такие адреса вы видите на домашнем роутере.

Протокол TCP: надёжная доставка

TCP (Transmission Control Protocol) гарантирует, что данные дойдут в правильном порядке и без потерь. Для этого он использует трёхстороннее рукопожатие (three-way handshake):

  • Клиент отправляет пакет с флагом SYN (запрос на соединение).
  • Сервер отвечает SYN-ACK (подтверждение запроса и свой запрос).
  • Клиент отправляет ACK (подтверждение).
  • После этого данные передаются с контролем целостности. Если пакет потерян — TCP запросит повторную отправку. Именно поэтому загрузка файла через HTTP всегда завершается полностью, даже при нестабильном соединении.

    UDP (User Datagram Protocol) — полная противоположность: данные отправляются без гарантий, но зато быстрее. UDP используют для видеозвонков, онлайн-игр и DNS-запросов — там, где важна скорость, а потеря нескольких пакетов некритична.

    HTTP: язык веба

    HTTP (HyperText Transfer Protocol) — протокол прикладного уровня, по которому браузер общается с веб-сервером. Работает по модели клиент-сервер: клиент отправляет запрос, сервер возвращает ответ.

    Базовый HTTP-запрос выглядит так:

    Сервер отвечает с кодом состояния:

  • 200 — OK, всё хорошо
  • 301 — ресурс перемещён (редирект)
  • 404 — ресурс не найден
  • 500 — ошибка на стороне сервера
  • HTTP работает поверх TCP на порту 80. Его защищённая версия HTTPS добавляет шифрование через TLS и работает на порту 443. На собеседовании часто спрашивают разницу: HTTP передаёт данные открытым текстом, HTTPS шифрует их, защищая от перехвата.

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

    Когда вы вводите google.com, ваш компьютер не знает IP-адрес этого сервера. За перевод доменного имени в IP отвечает DNS (Domain System).

    Процесс разрешения имени:

  • Браузер проверяет локальный кэш — может, этот адрес уже известен.
  • Если нет — запрос идёт к DNS-резолверу (обычно на роутере или у провайдера).
  • Резолвер обращается к корневым DNS-серверам, затем к TLD-серверам (для .com, .ru и т.д.), затем к авторитетным DNS-серверам домена.
  • Ответ возвращается клиенту и кэшируется на время TTL (Time To Live), указанное в записи.
  • Проверить DNS-разрешение можно командой:

    На собеседовании могут спросить: «Что произойдёт, если DNS-сервер недоступен?» — пользователь не сможет открыть сайт по имени, но прямой переход по IP-адресу будет работать.

    DHCP: автоматическая настройка сети

    Когда ваш ноутбук подключается к Wi-Fi, он получает IP-адрес, маску подсети, адрес шлюза и DNS-серверы — всё автоматически. За это отвечает DHCP (Dynamic Host Configuration Protocol).

    Процесс получения адреса (DORA):

  • Discover — устройство широковещательно спрашивает: «Есть ли DHCP-сервер?»
  • Offer — сервер предлагает свободный IP-адрес.
  • Request — устройство запрашивает предложенный адрес.
  • ACK — сервер подтверждает выдачу.
  • Адрес выдаётся на определённый срок — аренду (lease). Когда срок истекает, устройство может продлить аренду или получить новый адрес.

    > DHCP — это именно то, почему вам не нужно вручную настраивать IP-адрес на каждом устройстве дома. Без него каждое устройство пришлось бы конфигурировать вручную.

    Как протоколы работают вместе

    Когда вы открываете https://example.com, происходит следующее:

  • DNS разрешает example.com в IP-адрес.
  • TCP устанавливает соединение с сервером (трёхстороннее рукопожатие).
  • TLS выполняет обмен ключами для шифрования.
  • HTTP-запрос упаковывается в TCP-сегменты, затем в IP-пакеты и отправляется через сеть.
  • Сервер обрабатывает запрос и возвращает ответ тем же путём.
  • Каждый уровень добавляет свой заголовок к данным — этот процесс называется инкапсуляцией. На принимающей стороне заголовки снимаются в обратном порядке.

    2. Знакомство с Linux и базовая работа в терминале

    Знакомство с Linux и базовая работа в терминале

    Представьте: вы пришли на собеседование, и интервьюер просит «показать содержимое директории, найти все файлы с расширением .log, посмотреть, какие процессы потребляют больше всего памяти». Если вы не знаете, как работать с командной строкой Linux, собеседование закончится раньше, чем начнётся. Терминал — это не пережиток прошлого, а основной инструмент системного администратора, DevOps-инженера и backend-разработчика.

    Почему Linux, а не Windows

    Linux — семейство операционных систем с открытым исходным кодом, построенных на ядре, которое написал Линус Торвальдс в 1991 году. Подавляющее большинство серверов в мире (более 96% топ-1 миллиона веб-серверов по данным W3Techs) работают на Linux. Облачные платформы AWS, Google Cloud, Azure — все используют Linux как основу. Docker и Kubernetes — тоже Linux-технологии.

    На собеседовании вас не будут спрашивать «почему Linux лучше Windows». Но если вы не можете навигировать по файловой системе через терминал, это красный флаг для любого технического интервью.

    Первый запуск терминала

    Терминал (или эмулятор терминала) — программа, которая принимает текстовые команды и отправляет их операционной системе. В Linux-дистрибутивах по умолчанию установлен терминал с оболочкой Bash (Bourne Again Shell).

    После открытия терминала вы увидите приглашение командной строки — промпт. Он выглядит примерно так:

    bash pwd

    Вывод: /home/student

    bash ls # имена файлов и папок ls -l # подробный список с правами, владельцем, размером ls -la # подробный список, включая скрытые файлы (начинаются с точки) ls -lh # подробный список с размерами в человекочитаемом формате (KB, MB) bash cd /var/log # перейти в абсолютный путь cd .. # перейти на уровень выше cd ~ # вернуться в домашнюю директорию cd - # вернуться в предыдущую директорию bash touch file.txt # создать пустой файл mkdir my_project # создать директорию mkdir -p a/b/c # создать вложенную цепочку директорий за раз

    cp file.txt copy.txt # скопировать файл cp -r my_project backup/ # скопировать директорию рекурсивно (флаг -r обязателен)

    mv file.txt new_name.txt # переименовать файл mv file.txt ~/Documents/ # переместить файл в другую директорию

    rm file.txt # удалить файл rm -r my_project/ # удалить директорию со всем содержимым rm -i file.txt # удалить с подтверждением (спросит «да/нет») bash cat file.txt # вывести весь файл целиком head -n 20 file.txt # первые 20 строк tail -n 20 file.txt # последние 20 строк tail -f /var/log/syslog # следить за файлом в реальном времени (отлично для логов) less file.txt # постраничный просмотр (выход — клавиша q) wc -l file.txt # подсчитать количество строк bash nano file.txt # открыть файл в редакторе nano

    Ctrl+O — сохранить, Ctrl+X — выйти

    bash find / -name "*.log" # найти все .log-файлы во всей системе find /var/log -type f -size +10M # найти файлы больше 10 МБ в /var/log find . -name "config*" -mtime -7 # файлы, изменённые за последние 7 дней bash grep "error" /var/log/syslog # найти строки с «error» в логе grep -r "TODO" ~/my_project/ # рекурсивный поиск по директории grep -i "warning" file.txt # поиск без учёта регистра grep -n "function" script.py # показать номера строк с совпадением bash ls -la > listing.txt # записать вывод в файл (перезаписать) echo "backup" >> log.txt # дописать в конец файла bash cat /var/log/syslog | grep "error" | wc -l

    Посчитать количество строк с «error» в системном логе

    ps aux | sort -k4 -nr | head -5

    Топ-5 процессов по потреблению памяти

    bash echo PATH # список директорий, где система ищет исполняемые файлы echo PATH — критически важная концепция. Когда вы набираете ls, система ищет исполняемый файл ls в каждой директории, перечисленной в PATH, вы получите ошибку command not found.

    История команд позволяет не набирать одно и то же повторно:

    Права и суперпользователь

    Многие системные операции требуют привилегий. Команда sudo (superuser do) запускает команду от имени суперпользователя root:

    Если вы попытаетесь выполнить привилегированную команду без sudo`, система вернёт ошибку «Permission denied». Права доступа к файлам — тема, которой мы посвятим отдельную статью, но базовый принцип прост: каждый файл принадлежит владельцу и группе, и у каждого из них — свой набор прав на чтение, запись и выполнение.

    Пакетный менеджер: установка программ

    В Linux программы устанавливаются через пакетный менеджер — утилиту, которая скачивает, устанавливает и обновляет программное обеспечение из репозиториев. В Debian/Ubuntu это apt:

    В CentOS/RHEL используется yum или dnf, в Arch Linux — pacman. На собеседовании достаточно знать, что пакетный менеджер берёт на себя зависимости и обновления — вам не нужно вручную компилировать программы из исходников (хотя и это возможно).

    Практический сценарий: быстрая диагностика

    Допустим, сервер работает медленно. Вот типичная цепочка команд для диагностики, которую стоит знать наизусть:

    Эти пять команд — ваш первый инструмент при любом инциденте. На собеседовании, если вас попросят «что вы будете делать, если сервер тормозит?», начните именно с них.

    3. Управление файловой системой и правами доступа в Linux

    Управление файловой системой и правами доступа в Linux

    На собеседовании вас могут попросить: «Почему скрипт не запускается, хотя файл существует?» Ответ почти всегда кроется в правах доступа. В Linux каждый файл и каждая директория принадлежат конкретному пользователю и группе, а система строго контролирует, кто может читать, изменять или выполнять каждый объект. Без понимания этой системы вы не сможете безопасно администрировать сервер — и собеседующий это проверит.

    Структура файловой системы Linux

    В отличие от Windows с его дисками C:\ и D:\, в Linux всё — единое дерево с корнем /. Каждый физический диск, флешка или сетевой ресурс монтируется в определённую точку этого дерева.

    Ключевые директории корневого уровня:

    | Директория | Назначение | |---|---| | /bin | Базовые системные утилиты (ls, cp, cat) | | /etc | Конфигурационные файлы системы и сервисов | | /home | Домашние директории пользователей | | /var | Переменные данные: логи, почта, базы данных | | /tmp | Временные файлы (очищаются при перезагрузке) | | /usr | Установленные программы и их файлы | | /dev | Файлы устройств (диски, терминалы) | | /proc | Виртуальная файловая система с информацией о процессах и ядре |

    > /proc — особая директория: она не существует на диске. Это «окно» в ядро Linux. Например, /proc/cpuinfo содержит информацию о процессоре, а /proc/meminfo — об оперативной памяти. Команда cat /proc/cpuinfo покажет характеристики CPU без установки дополнительных программ.

    Типы файлов в Linux

    Всё в Linux — файл. Это не метафора, а буквальное утверждение. Даже подключённые устройства представлены как файлы в директории /dev. Различают несколько типов:

  • Обычный файл (-) — текстовый документ, скрипт, бинарная программа
  • Директория (d) — контейнер для других файлов
  • Символическая ссылка (l) — аналог ярлыка в Windows, указывает на другой файл
  • Сокет (s) — файл для межпроцессного взаимодействия
  • Канал (p) — именованный канал для передачи данных между процессами
  • Узнать тип файла можно командой file или по первому символу в выводе ls -l:

    Тройка прав: read, write, execute

    Каждый файл в Linux имеет три набора прав — для владельца (owner), группы (group) и всех остальных (others). В каждом наборе — три бита:

  • r (read) — чтение: для файла — просмотр содержимого, для директории — список файлов внутри
  • w (write) — запись: для файла — изменение, для директории — создание/удаление файлов внутри
  • x (execute) — выполнение: для файла — запуск как программы, для директории — вход в неё
  • Разберём вывод ls -l на конкретном примере:

    Читаем слева направо:

    | Позиция | Значение | |---|---| | -rwxr-xr-- | Тип файла и права | | 1 | Количество жёстких ссылок | | deploy | Владелец | | web | Группа | | 2048 | Размер в байтах | | Mar 10 14:30 | Дата последнего изменения | | script.sh | Имя файла |

    Разбираем права -rwxr-xr-- по частям: первая тройка rwx — владелец может читать, записывать и выполнять; вторая r-x — группа может читать и выполнять, но не записывать; третья r-- — все остальные могут только читать.

    Числовое представление прав

    Каждое право кодируется битом: r = 4, w = 2, x = 1. Складываются они для каждого набора:

    | Права | Буквы | Число | |---|---|---| | Чтение + запись + выполнение | rwx | 7 | | Чтение + выполнение | r-x | 5 | | Только чтение | r-- | 4 | | Чтение + запись | rw- | 6 | | Нет прав | --- | 0 |

    Таким образом, права rwxr-xr-- записываются как 754. Это числовая нотация, которую используют в команде chmod:

    > На собеседовании часто спрашивают: «Какие права должны быть у веб-страниц?» — 644 для файлов и 755 для директорий. Владелец может записывать, все остальные — только читать. А вот конфиги с паролями — 600, чтобы никто, кроме владельца, не имел доступа.

    Изменение владельца и группы

    Команда chown (change owner) меняет владельца и/или группу файла:

    Команда chgrp меняет только группу:

    Для выполнения chown нужны права суперпользователя — обычный пользователь не может передать владение своим файлом кому-то другому.

    Специальные биты: SUID, SGID, sticky bit

    Помимо базовых прав, существуют три специальных бита, которые часто встречаются на собеседованиях:

    SUID (Set User ID, бит 4): если установлен на исполняемом файле, программа запускается с правами владельца файла, а не того, кто её вызвал. Классический пример — /usr/bin/passwd:

    Команда passwd меняет пароль, а для этого нужно писать в /etc/shadow, доступный только root. Благодаря SUID любой пользователь может запустить passwd, и она выполнится с правами root.

    SGID (Set Group ID, бит 2): на директории — все новые файлы внутри наследуют группу директории, а не группу создателя. Полезно для совместных проектов:

    Sticky bit (бит 1): на директории — файлы внутри могут удалять только их владельцы. Классический пример — /tmp:

    Без sticky bit любой пользователь мог бы удалить чужие файлы в /tmp.

    Символическая нотация chmod

    Помимо числового способа, chmod поддерживает символьную нотацию — изменение прав относительно текущих:

    Символьная нотация удобна, когда нужно добавить или убрать одно право, не трогая остальные. Числовая — когда вы точно знаете итоговый набор прав.

    Ссылки: жёсткие и символические

    В Linux файл на самом деле — не имя, а inode — структура данных на диске, содержащая метаданные и указатели на блоки данных. Имя файла — это просто запись в директории, которая указывает на inode.

    Жёсткая ссылка (hard link) — дополнительная запись в директории, указывающая на тот же inode. Удаление одной ссылки не уничтожает файл, пока существует хотя бы одна:

    Символическая ссылка (symlink, soft link) — файл-указатель, содержащий путь к другому файлу. Если исходный файл удалён, ссылка становится «битой»:

    > На собеседовании могут спросить: «В чём разница между жёсткой и символической ссылкой?» Жёсткая ссылка указывает на inode (нельзя создать для директорий и между разными файловыми системами), символическая — на путь (может указывать на директории и на файлы на других дисках).

    umask: права по умолчанию

    Когда вы создаёте новый файл, система автоматически назначает ему права. Конкретные значения определяются параметром umask — маской, которая вычитается из максимальных прав (666 для файлов, 777 для директорий):

    Если в вашей организации требуется, чтобы все новые файлы были доступны только владельцу, системный администратор установит umask 0077 — тогда новые файлы получат права 600, а директории 700.

    Практический сценарий: настройка веб-проекта

    Допустим, вы разворачиваете веб-приложение. Типичная последовательность настройки прав:

    Здесь deploy — пользователь, от которого работает приложение, www-data — группа веб-сервера (nginx или Apache). Конфигурационные файлы с паролями получают права 600 — доступ только владельцу. Директория с конфигами — 700, чтобы никто не мог даже увидеть список файлов внутри.

    4. Настройка сетевых интерфейсов и диагностика в Linux

    Настройка сетевых интерфейсов и диагностика в Linux

    Сервер без сети — это дорогой обогреватель. На техническом собеседовании вас почти гарантированно спросят: «Как проверить, доступен ли сервер?», «Как посмотреть открытые порты?», «Почему два сервера в одной подсети не видят друг друга?». Все ответы лежат в области сетевой диагностики Linux — и это та область, где теория TCP/IP встречается с практикой командной строки.

    Сетевые интерфейсы: как Linux видит сеть

    Сетевой интерфейс — программный объект, через который операционная система взаимодействует с сетевым оборудованием. Каждый интерфейс получает имя и, как правило, IP-адрес.

    Посмотреть все сетевые интерфейсы можно несколькими способами. Классическая команда:

    Вывод содержит несколько блоков. Например:

    Разберём по строкам: eth0 — имя интерфейса (первый Ethernet-адаптер), inet 192.168.1.50/24 — IPv4-адрес с маской подсети, brd 192.168.1.255 — широковещательный адрес, mtu 1500 — максимальный размер пакета в байтах.

    > Старая команда ifconfig до сих пор встречается, но она считается устаревшей. На современных системах используйте ip — она входит в пакет iproute2 и предоставляет больше возможностей.

    Маршрутизация: как пакеты находят путь

    Когда ваш сервер отправляет пакет на другой IP-адрес, ядро Linux смотрит в таблицу маршрутизации и решает, через какой интерфейс и на какой шлюз отправить пакет.

    Посмотреть таблицу маршрутов:

    Типичный вывод:

    Первая строка — маршрут по умолчанию: все пакеты, для которых нет более специфичного маршрута, отправляются через шлюз 192.168.1.1 (обычно это роутер). Вторая строка — локальная подсеть: пакеты для 192.168.1.0/24 отправляются напрямую через eth0.

    Добавить временный маршрут:

    Удалить маршрут:

    > На собеседовании могут спросить: «Что произойдёт, если удалить маршрут по умолчанию?» — сервер потеряет связь со всеми адресами за пределами локальной подсети. Он сможет общаться только с устройствами в своей 192.168.1.0/24, но не с интернетом.

    Проверка связности: ping и traceroute

    ping — базовая проверка доступности хоста. Отправляет ICMP Echo Request и ждёт ответа:

    Ключевые параметры вывода: time=12.3 ms — задержка (латентность), ttl=117 — количество оставшихся прыжков, packet loss — процент потерянных пакетов.

    Если ping не проходит, это может означать: сервер выключен, межсетевой экран блокирует ICMP, проблема с маршрутизацией. Отсутствие ответа на ping не обязательно означает, что сервер недоступен — многие серверы намеренно игнорируют ICMP-запросы.

    traceroute (или tracepath) показывает маршрут пакета до целевого хоста — через какие промежуточные узлы он проходит:

    Каждая строка вывода — один маршрутизатор на пути. Если на каком-то этапе звёздочки ( *) вместо адресов, значит промежуточный узел не ответил вовремя.

    DNS-диагностика

    Если сервер недоступен по имени, но доступен по IP — проблема в DNS. Проверить разрешение имён:

    Посмотреть, какие DNS-серверы использует система:

    Файл /etc/resolv.conf содержит адреса DNS-резолверов. Если он пуст или содержит неверные адреса, система не сможет разрешать доменные имена.

    > На практике часто встречается ситуация: вы изменили DNS-запись домена, но сервер всё ещё отвечает по старому IP. Причина — кэш DNS. Очистить локальный кэш: sudo systemd-resolve --flush-caches (на системах с systemd-resolved).

    Просмотр открытых портов и соединений

    Каждый сервис на сервере слушает определённый порт. Веб-сервер — 80 или 443, SSH — 22, база данных PostgreSQL — 5432. Посмотреть, какие порты открыты и какие процессы их используют:

    Флаги: -t — TCP, -u — UDP, -l — только слушающие сокеты, -n — показывать номера портов (не имена сервисов), -p — показывать процесс, занимающий порт.

    Пример вывода:

    Здесь SSH слушает на порту 22 на всех интерфейсах (0.0.0.0:22), nginx — на порту 80.

    Старая команда netstat -tulnp делает то же самое, но ss работает быстрее и является рекомендуемой заменой.

    Посмотреть активные соединения (не только слушающие):

    Межсетевой экран: iptables и firewalld

    Linux имеет встроенный межсетевой экран — Netfilter, которым управляют через команды iptables или nftables (в новых дистрибутивах). На практике часто используется обёртка firewalld.

    Посмотреть текущие правила:

    Типичные задачи на собеседовании:

    > Важный нюанс: если вы настраиваете правила удалённо через SSH, обязательно сначала разрешите порт 22, иначе вы потеряете доступ к серверу. Это классическая ошибка, которую часто обсуждают на собеседованиях.

    Сетевые файлы конфигурации

    Ключевые файлы, которые отвечают за сетевые настройки:

    | Файл | Назначение | |---|---| | /etc/hostname | Имя компьютера | | /etc/hosts | Локальная таблица соответствия имён и IP-адресов | | /etc/resolv.conf | Адреса DNS-серверов | | /etc/network/interfaces | Статическая конфигурация сети (Debian) | | /etc/netplan/*.yaml | Конфигурация сети (Ubuntu 18.04+) |

    Файл /etc/hosts — локальный аналог DNS. Записи в нём проверяются до обращения к DNS-серверу:

    Это полезно для тестирования: можно указать, что myapp.local ведёт на 127.0.0.1, и открывать проект в браузере по этому имени.

    Статическая настройка IP-адреса

    На серверах IP-адрес обычно назначается статически, а не через DHCP. В системах с Netplan (Ubuntu 18.04+) конфигурация выглядит так:

    Применить конфигурацию:

    В системах с традиционным /etc/network/interfaces (Debian, старые версии Ubuntu):

    Практический сценарий: сервер не отвечает

    Допустим, вы не можете подключиться к серверу по SSH. Диагностическая цепочка:

    Если ping не проходит — проблема на сетевом уровне (маршрутизация, кабель, выключен сервер). Если ping проходит, но SSH не подключается — проблема на уровне сервиса (демон не запущен, порт занят, firewall блокирует). Это логика, по которой строится любая сетевая диагностика.

    5. Пошаговое создание и запуск простого локального сервера на Linux

    Пошаговое создание и запуск простого локального сервера на Linux

    На собеседовании вас могут спросить: «Разверните веб-сервер и покажите, как он работает». Это не теоретический вопрос — интервьюер хочет увидеть, что вы понимаете, как связаны между собой сетевые протоколы, права доступа, процессы и конфигурация Linux. Развертывание простого сервера — это практический экзамен, который проверяет все знания из предыдущих статей разом.

    Что мы будем строить

    Цель — создать на локальной машине (или виртуалке) с Linux работающий веб-сервер nginx, который отдаёт статическую HTML-страницу. По итогу вы откроете браузер, введёте IP-адрес сервера и увидите свою страницу. Звучит просто, но за этим стоит цепочка из семи шагов, каждый из которых проверяет конкретные навыки.

    Шаг 1: Обновление системы и установка nginx

    Перед установкой любого ПО обновите индекс пакетов — это гарантирует, что вы получите актуальные версии:

    Установите nginx — один из самых популярных веб-серверов в мире. Он используется как прямой сервер статического контента, обратный прокси и балансировщик нагрузки:

    После установки nginx автоматически запускается. Проверить:

    В выводе вы должны увидеть Active: active (running). Если статус inactive — запустите вручную:

    > systemctl enable не запускает сервис немедленно — он создаёт символическую ссылку в директории автозагрузки. Сервис стартует автоматически при следующей перезагрузке. На собеседовании это частый вопрос: «Чем отличается start от enable

    Шаг 2: Проверка базовой работоспособности

    Откройте браузер на этой же машине и перейдите по адресу http://localhost или http://127.0.0.1. Вы должны увидеть приветственную страницу nginx.

    Из терминала проверить можно командой curl — утилитой для выполнения HTTP-запросов:

    Если вы видите HTML-код приветственной страницы — nginx работает. Также проверьте, что порт 80 действительно занят:

    В выводе должен быть nginx, слушающий на 0.0.0.0:80 или :::80 (IPv6).

    Шаг 3: Создание собственной HTML-страницы

    По умолчанию nginx отдаёт файлы из директории /var/www/html/. Замените стандартную страницу своей:

    Вставьте простой HTML:

    Сохраните файл (Ctrl+O, затем Ctrl+X в nano). Обратите внимание: файл создан через sudo, поэтому его владелец — root. Проверьте права:

    Права 644 — владелец может читать и писать, все остальные — только читать. Это корректно для веб-контента: nginx (запущенный от имени пользователя www-data) должен иметь возможность читать файл.

    Шаг 4: Настройка конфигурации nginx

    Конфигурация nginx хранится в /etc/nginx/. Основной файл — /etc/nginx/nginx.conf, а отдельные конфигурации сайтов — в /etc/nginx/sites-available/ с символическими ссылками в /etc/nginx/sites-enabled/.

    Создайте конфигурацию для вашего сайта:

    Минимальная конфигурация:

    Разберём директивы:

  • listen 80 — слушать на порту 80
  • server_name localhost — обрабатывать запросы с заголовком Host: localhost
  • root /var/www/html — директория с файлами сайта
  • index index.html — файл по умолчанию при обращении к директории
  • location / { try_files ... } — для любого URL искать соответствующий файл, иначе вернуть 404
  • Активируйте конфигурацию через символическую ссылку:

    Удалите стандартную конфигурацию, чтобы она не конфликтовала:

    Проверьте корректность конфигурации перед перезапуском:

    Если вывод syntax is ok и test is successful — перезапустите nginx:

    > reload перечитывает конфигурацию без разрыва соединений, в отличие от restart, который останавливает и запускает сервис заново. На продакшн-серверах всегда используйте reload.

    Шаг 5: Настройка межсетевого экрана

    Если сервер должен быть доступен с других машин, нужно разрешить входящий трафик на порт 80. На Ubuntu используется ufw (Uncomplicated Firewall):

    После включения проверьте:

    Вывод должен содержать правила ALLOW для портов 22, 80 и 443. Если вы работаете на виртуальной машине, убедитесь также, что проброс портов настроен в настройках гипервизора (VirtualBox, VMware) или что машина находится в той же виртуальной сети.

    Шаг 6: Проверка с другого устройства

    Возьмите IP-адрес сервера:

    С другого компьютера в той же сети откройте браузер и перейдите по http://192.168.x.x. Или проверьте из терминала:

    Если страница не открывается, пройдите по цепочке диагностики:

    Шаг 7: Мониторинг и логи

    Веб-сервер работает, но на собеседовании могут спросить: «А как вы узнаете, что что-то пошло не так?» — через логи.

    Nginx пишет два типа логов:

  • Access log (/var/log/nginx/access.log) — каждый запрос к серверу: IP клиента, время, URL, код ответа
  • Error log (/var/log/nginx/error.log) — ошибки конфигурации, проблемы с файлами, сбои
  • Следить за логами в реальном времени:

    Посмотреть последние записи:

    Типичная строка access log:

    Здесь: IP клиента 192.168.1.100, метод GET, путь /index.html, протокол HTTP/1.1, код ответа 200, размер ответа 312 байт, User-Agent браузера.

    Расширение: добавление второго сайта

    Чтобы закрепить навыки, добавьте второй сайт на том же сервере. Создайте директорию:

    Создайте конфигурацию, слушающую на другом порту:

    Активируйте и перезагрузите:

    Теперь http://192.168.x.x отдаёт первый сайт, а http://192.168.x.x:8080 — второй. Это базовый приём виртуальных хостов — на одном сервере работают несколько сайтов.

    Что здесь проверяется на собеседовании

    Развертывание сервера — это не просто «установил nginx». Интервьюер оценивает, понимаете ли вы полную цепочку:

  • Пакетный менеджер — как установить ПО
  • Система инициализации — как управлять сервисами через systemd
  • Файловая система и права — почему файлы должны быть доступны для чтения пользователю www-data
  • Конфигурация — как настроить сервер через текстовые файлы
  • Сеть — порты, интерфейсы, маршрутизация
  • Безопасность — межсетевой экран, минимальные привилегии
  • Диагностика — логи, мониторинг, команды проверки
  • Если вы можете пройти все семь шагов без подглядывания в документацию — вы готовы к техническому собеседованию по этой теме.