Linux (Архитектура): Почему epoll устарел? Революция io_uring

Боль: Высоконагруженные базы данных (PostgreSQL, Redis) и веб-серверы тратят до 30% времени CPU просто на "общение" с ядром (System Calls). Старый механизм асинхронного ввода-вывода (epoll) требует постоянных переключений контекста.

Революция: io_uring Это новый интерфейс ядра Linux (появился в 5.1, стал стандартом сейчас), который меняет всё.

В чем суть (на пальцах):

epoll: Приложение: "Ядро, есть данные?" -> Ядро: "Нет" -> Приложение ждет -> Ядро: "Есть" -> Приложение: "Дай". (Куча системных вызовов).

io_uring: Приложение и Ядро создают два кольцевых буфера (Ring Buffers) в общей памяти.

Приложение кладет запрос в буфер "Submission".

Ядро забирает его, делает работу и кладет результат в буфер "Completion".

Ноль системных вызовов (Zero Syscall overhead).

Взгляд архитектора: Если вы видите, что ваш Nginx или MySQL после обновления ядра стали работать на 20-40% быстрее — это io_uring. Архитектор должен знать: для I/O-intensive задач (файловые хранилища, БД) выбор дистрибутива с новым ядром (5.10+) — это бесплатный прирост производительности.

#linux #kernel #performance #iouring #epoll #architect #highload

🎓 Собеседование сисадмина. Выпуск #7: Веб-серверы и Проксирование (Nginx & Troubleshooting)

Привет, коллеги! В 2026 году «просто поднять Apache» — это путь к увольнению по статье за профнепригодность. Веб-сервер сегодня — это первая линия обороны «цифровой крепости», где мы жонглируем TLS 1.3, отечественными сертификатами и отбиваемся от ботов еще до того, как они нагрузят наш бэкенд на ARM-процессорах.

Разберем три вопроса, на которых валят тех, кто застрял в 2015-м.

---
❓ Вопрос 1: «В чем разница между proxy_pass на IP и на Unix-сокет? Когда что выбирать?»

❌ Ответ новичка: «IP — это для интернета, а сокет — это внутри сервера. Сокет вроде бы быстрее».
✅ Ответ инженера:

* Unix Sockets: Обмен данными идет напрямую через ядро Linux без участия сетевого стека (TCP/IP).
* Плюс: Меньше задержки (latency) и нагрузки на CPU.
* Минус: Работает только в рамках одной ОС. Если бэкенд переедет на соседний контейнер/сервер, придется переписывать конфиг.

* TCP (IP:Port): Данные проходят через весь сетевой стек, даже если бэкенд на том же хосте (loopback).
* Плюс: Легко масштабировать — просто меняем `127.0.0.1` на IP другого сервера.
* Вывод: В 2026-м для высоконагруженных локальных связок (Nginx + PHP-FPM/Python) используем сокеты, для микросервисов — TCP.

---

❓ Вопрос 2: «Что такое "проблема Client IP" за прокси-сервером и как ее решить?»

❌ Ответ новичка: «В логах бэкенда будет IP балансировщика. Чтобы увидеть реальный IP, нужно что-то включить в настройках».
✅ Ответ инженера:

По умолчанию бэкенд видит IP того, кто к нему обратился — т.е. вашего Nginx. Чтобы передать адрес клиента, мы используем заголовок X-Forwarded-For или X-Real-IP.

* На стороне Nginx: прокидываем заголовок.
* На стороне бэкенда: используем модуль (например, `ngx_http_realip_module`), чтобы подменить адрес источника в логах и логике приложения.
* Важно:* В 2026-м обязательно настраиваем `set_real_ip_from`, чтобы доверять заголовкам только от своих балансировщиков, иначе любой школьник подменит свой IP в HTTP-заголовке.

---

❓ Вопрос 3: «Зачем нужно прокси-буферирование (proxy_buffering) и когда его вредно выключать?»

❌ Ответ новичка: «Буферизация — это кэш. Ее лучше включить, чтобы все работало быстрее».
✅ Ответ инженера:

Буферизация позволяет Nginx «впитать» ответ от бэкенда максимально быстро и отпустить воркер бэкенда заниматься следующими задачами.

* Если включено: Nginx забирает ответ в память (или на диск) и сам медленно отдает его клиенту с плохим 5G-интернетом. Бэкенд свободен.
* Если выключено (off): Бэкенд будет «висеть» открытым, пока клиент не скачает последний байт. При 1000 медленных клиентах ваш бэкенд захлебнется в процессах.
* Исключение: SSE (Server-Sent Events) или стриминг, где данные должны уходить клиенту мгновенно.

---

Практический пример: Bulletproof Proxy Config 2026

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

upstream backend_cluster {
    server unix:/run/php-fpm.sock weight=5; # Быстрый локальный сокет
    server 192.168.10.50:8080 backup;       # Резерв на случай падения
}

server {
    listen 443 ssl http2;
    server_name service.local;

    # Работа с реальными IP (только от доверенного шлюза)
    set_real_ip_from  10.0.0.1;
    real_ip_header    X-Forwarded-For;

    location / {
        proxy_pass http_backend_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # Защита от "залипания" бэкенда
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        proxy_buffering on;
        proxy_buffer_size 8k;
    }
}

Зачем это нужно

Понимание работы прокси — это разница между «у нас сервер упал под нагрузкой» и «мы просто увеличили количество воркеров».

Вывод: Берегите бэкенды, делегируйте всю «грязную» работу по общению с клиентами Nginx'у.

#собеседование_AF #nginx #linux #proxy #highload #sysadmin #admin_future

🐧 Linux: XDP — Аннигиляция пакетов на входе в «Цифровую крепость»

Привет, коллеги! Сегодня четверг, 12 марта 2026 года, и если ваш сетевой стек до сих пор захлебывается от входящего мусора, пока iptables задумчиво перебирает цепочки правил, у меня для вас плохие новости. В эпоху 400-гигабитных каналов и повсеместного IPv6 классический путь пакета через всё ядро Linux — это непозволительная роскошь.

Техническая суть:

Мы переходим на XDP (eXpress Data Path). Это база для современного сетевого админа. XDP позволяет запускать eBPF-код прямо в контексте драйвера сетевой карты, до того, как ядро вообще начнет создавать структуру `sk_buff`.

Под капотом: Пакет перехватывается на уровне RX-очереди. Мы можем либо пробросить его дальше (XDP_PASS), либо мгновенно аннигилировать (XDP_DROP), либо отправить обратно (XDP_TX). Это дает нам производительность, близкую к DPDK, но без необходимости писать драйверы в пользовательском пространстве и терять интеграцию с ОС.

Практика:

В 2026-м мы не пишем байт-код руками. Используем современные обертки для быстрой фильтрации DDoS на подлете:

# 1. Устанавливаем xdp-tools (стандарт для современных дистрибутивов)
# 2. Вешаем фильтр, который будет дропать всё, что не соответствует нашим ACL
# на уровне драйвера (native mode) или программно (skb mode)

xdp-loader load eth0 ./drop_malicious_traffic.o --mode native

# 3. Мониторим статистику прохождения пакетов через eBPF-карты
bpftool map dump name xdp_stats_map

# Пример простейшего правила для xdp-filter (современная замена многим задачам iptables)
xdp-filter load eth0 -p ipv6 --ip 2001:db8:dead:beef::/64 -a drop

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

Экономия ресурсов CPU. Пока

nftables

тратит циклы на разбор каждого заголовка, XDP просто «срезает» ненужное на входе. Это единственный способ держать аптайм, когда на твой ARM-кластер прилетает «привет» от ботнета в пару терабит.

#linux #xdp #ebpf #networking #highload #admin_future