💡 Полезные Советы

WAL (Write-Ahead Logging), или журналирование с упреждающей записью - это один из самых популярных и надежных механизмов работы баз данных. Его главная задача - обеспечить сохранность данных при сбоях (например, отключении электричества) и значительно ускорить работу при одновременном чтении и записи.

Чтобы понять WAL, давайте сравним его со старым классическим подходом.

Простая аналогия: Бухгалтерская книга
Представьте, что база данных - это огромная бухгалтерская книга, с которой работают несколько человек.

• Стандартный режим (Rollback Journal): Когда бухгалтер хочет изменить запись на странице 10, он берет чистый лист (журнал откатов), переписывает туда старые данные со страницы 10, прячет в сейф, а затем стирает старые данные в самой книге и пишет новые. Если в этот момент придет начальник и захочет почитать страницу 10, ему скажут: "Подождите, я еще не закончил писать!". Чтение блокируется записью.
• Режим WAL: Бухгалтер не трогает саму книгу. Он берет стикер (WAL-файл), пишет на нем новые данные и приклеивает поверх страницы 10. Если приходит начальник, бухгалтер говорит: "Читай страницу 10, а если там есть стикер - читай данные со стикера". В итоге бухгалтер может клеить новые стикеры, а начальник может одновременно читать книгу со стикерами. Никто никого не ждет. Периодически (например, ночью, когда никого нет) данные со стикеров аккуратно переписываются в саму книгу.

Как это работает технически?

В традиционном подходе каждое изменение напрямую модифицирует основной файл базы данных. Это медленно и требует строгих блокировок.

В режиме WAL процесс выглядит так:

• Запись: Когда вы обновляете или добавляете данные, база данных не трогает основной файл (db.sqlite3 или аналогичный). Вместо этого она дописывает изменения в конец специального файла - WAL-журнала (db.sqlite3-wal). Дописывать в конец файла (последовательная запись) жесткому диску гораздо проще и быстрее, чем искать нужное место в гигантском основном файле (случайная запись).
• Чтение: Когда кто-то делает SELECT-запрос, база данных сначала смотрит в основной файл, а затем сверяется с WAL-файлом. Если нужные данные были недавно изменены, она берет свежую версию из WAL.
• Чекпоинт (Checkpoint): Со временем WAL-файл разрастается. База данных автоматически (или по вашей команде) запускает процесс "чекпоинта" - она берет все накопленные изменения из WAL-файла и переносит их в основной файл базы данных. После этого WAL-файл можно перезаписывать заново.

Главные преимущества WAL

• Параллельность (Concurrency): Это главная фишка WAL. Читатели не блокируют писателей, а писатели не блокируют читателей. В веб-разработке это критически важно: пользователи могут просматривать сайт, пока фоновый процесс обновляет базу данных.
• Скорость записи: Как уже упоминалось, Append-only (запись только в конец файла) работает намного быстрее, особенно на классических HDD дисках, да и на SSD снижает износ.
• Надежность (ACID): Так как изменения сначала гарантированно записываются в лог на диск, при внезапном отключении сервера база данных после перезагрузки просто прочитает WAL-файл и применит изменения, которые не успели попасть в основной файл.

Есть ли у WAL минусы?

Да, идеальных решений не бывает:

• Сетевые диски: Режим WAL требует использования разделяемой памяти (тот самый файл *-shm). Это значит, что он не работает (или работает с риском поломки данных), если файл базы лежит на сетевой файловой системе (NFS, SMB). База и приложение должны быть на одном физическом сервере/контейнере.
• Немного замедляется чтение: Так как базе нужно проверять два места (основной файл и WAL), чтение может стать микроскопически медленнее, особенно если WAL-файл сильно разросся до чекпоинта.
• Много файлов: Вместо одного аккуратного файла у вас появляется три (.sqlite3, .sqlite3-wal, .sqlite3-shm).

Где это используется?

WAL - это не эксклюзив SQLite. Это фундаментальный концепт.

• PostgreSQL использует WAL в качестве основы своей архитектуры, не только для надежности, но и для репликации (передачи данных на резервные серверы).
• В MySQL (InnoDB) есть Redo Log, который по сути выполняет точно такую же функцию упреждающей записи.

Как включить через командную строку (SQLite CLI).

Если у вас установлена консольная утилита sqlite3, откройте терминал и подключитесь к файлу вашей базы данных (в Django по умолчанию это db.sqlite3):

sqlite3 db.sqlite3

Затем внутри консоли SQLite выполните команду:

sqlite> PRAGMA journal_mode=WAL;

В ответ консоль должна вывести слово wal. Выйти из утилиты можно командой .exit.

Дополнительная настройка для Django

Так как настройка постоянная, вам не обязательно менять settings.py в Django. Вы можете просто выполнить PRAGMA journal_mode=WAL один раз, и Django начнет работать с базой в режиме WAL.

Однако, если вы хотите, чтобы при создании базы на новом сервере Django сам пытался использовать WAL, вы можете передать опцию init_command в настройках подключения к базе данных (в settings.py):

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
        'OPTIONS': {
            # Этот запрос будет выполняться при каждом новом соединении
            'init_command': 'PRAGMA journal_mode=WAL;',
        }
    }
}

Как убедиться, что WAL работает?

Когда режим WAL включен и к базе данных происходит активное обращение, рядом с вашим файлом базы данных появятся два новых временных файла:

• db.sqlite3-wal - файл самого лога (Write-Ahead Log).
• db.sqlite3-shm - файл разделяемой памяти (Shared Memory).

Важно: Никогда не удаляйте эти файлы вручную во время работы приложения! Это может привести к повреждению данных. SQLite сам управляет их жизненным циклом.

Как вернуть стандартный режим?

Если по какой-то причине WAL вам не подошел (например, база лежит на сетевом диске без поддержки блокировок, что для WAL критично), вы можете вернуть стандартный режим (DELETE) командой:

PRAGMA journal_mode=DELETE;

Глоссарий.

• Django: Популярный фреймворк на языке Python для быстрой разработки веб-приложений.
• SQLite: Легковесная реляционная база данных, которая хранит все таблицы и данные в одном обычном файле на диске (часто db.sqlite3).
• WAL (Write-Ahead Logging / Журналирование с упреждающей записью): Современный механизм работы баз данных. При изменении данных они сначала быстро дописываются в специальный лог-файл, что позволяет другим пользователям продолжать чтение без блокировки базы.
• Rollback Journal (Журнал откатов): Классический (и более медленный) режим SQLite. При изменении данных старые значения копируются во временный журнал. Во время этого процесса база блокируется для других операций.
• PRAGMA: Специальная SQL-команда в SQLite, которая используется для изменения внутренних настроек и параметров базы данных (например, для переключения в режим WAL).
• Чекпоинт (Checkpoint): Процесс в режиме WAL, во время которого накопленные в лог-файле изменения массово переносятся в основной файл базы данных.
• .shm файл (Shared Memory): Временный файл разделяемой памяти, который SQLite создает рядом с базой в режиме WAL. Он нужен как "оглавление", чтобы несколько процессов могли быстро находить данные в лог-файле.
• Последовательная запись (Append-only): Добавление данных строго в конец файла (как в режиме WAL). Для жесткого диска это самая быстрая операция, так как не нужно тратить время на поиск нужного места на диске.
• Параллельность (Concurrency): Способность базы данных или приложения обрабатывать множество запросов (чтение и запись) от разных пользователей одновременно, не заставляя их ждать друг друга.
• ACID (Atomicity, Consistency, Isolation, Durability): Набор стандартов для баз данных, гарантирующий, что транзакции (изменения данных) будут выполнены надежно и не потеряются даже при сбое питания или критической ошибке сервера.
• Сетевая файловая система (NFS, SMB): Способ хранения файлов, при котором они физически находятся на другом сервере, а компьютер обращается к ним по локальной сети. Режим WAL крайне не рекомендуется использовать на таких системах из-за проблем с блокировками файлов.

Ситуация с блокировками классических VPN-сервисов и протоколов (OpenVPN, WireGuard, Outline, Shadowsocks  и т.д.) становится всё сложнее. Системы глубокого анализа трафика (DPI) легко распознают их сигнатуры и режут скорость или блокируют соединения полностью.

Сегодня мы разберем ультимативное решение - селф-хостинг Amnezia VPN на собственном сервере с использованием протокола Xray (Reality), который маскирует ваш трафик под обычные запросы к белым сайтам.

Мы не просто поставим VPN, а сделаем это по уму, защитив сервер от взлома.

Задача 1: Аренда сервера (VPS).

Для начала нам нужен виртуальный сервер за пределами РФ. (нужен VPS за пределами РФ и не у хостера, который аффилирован с российскими компаниями или имеет российские стыки. Это не паранойя - это реальная техническая проблема, и она влияет и на приватность, и на обход блокировок, и на SEO‑репутацию IP.)

1. Выберите любого удобного хостинг-провайдера (Hetzner, DigitalOcean, Vultr или Linode (Akamai), OVHcloud, Scaleway или посредников например PQ.Hosting). Локация: Для пользователей из РФ идеальный баланс между пингом и стабильностью дают Германия, Нидерланды или Швеция.
2. Арендуйте самый дешевый тариф (обычно хватает 1 vCPU и 2 GB RAM).
3. Операционная система: Строго чистая Ubuntu 22.04(и выше) или Debian 12(и выше).
4. Виртуализация: Строго KVM (Избегайте OpenVZ или LXC - на них Docker (сердце Amnezia) может работать нестабильно или не запуститься вовсе.).

После оплаты хостер выдаст вам IP-адрес сервера и пароль пользователя root.

Задача 2: Базовая безопасность сервера (Отказ от паролей).

Оставлять сервер с доступом по паролю в интернете - плохая идея. Его начнут атаковать боты-брутфорсеры в первые же минуты. Мы настроим доступ по криптографическому SSH-ключу.

Откройте PowerShell (если у вас Windows) или терминал (Linux/macOS) и выполните следующие шаги:

0. Первая кровь - смена пароля root

• Подключитесь к серверу через терминал:

  ssh root@ВАШ_IP

• Введите команду passwd для смены пароля.

• Важно: Не используйте простые слова. Мы рекомендуем генерировать пароль длиной не менее 13 символов, включающий цифры, спецсимволы и разные регистры.

  Для создания надежного пароля воспользуйтесь генератором на нашем сайте riopass.ru. Такой пароль методом брутфорса (перебора) будут взламывать десятилетиями.

На домашнем ПК:

1. Генерация ключа:
Введите команду:

ssh-keygen -t ed25519 -f "$HOME\.ssh\vpn_key" -C "amnezia-server"

Нажмите дважды Enter, когда система попросит ввести пароль (passphrase). В вашей папке .ssh появятся два файла: vpn_key (ваш секретный ключ) и vpn_key.pub (публичный ключ для сервера).

2. Копирование публичного ключа на сервер:
Выведите содержимое публичного ключа на экран и скопируйте его:

cat "$HOME\.ssh\vpn_key.pub"

Теперь подключитесь к вашему новому серверу по паролю, который дал хостер:

ssh root@ВАШ_IP_АДРЕС

Создайте папку для ключей и запишите туда скопированный ключ:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Вставьте ваш ключ (ssh-ed25519...) в редактор, сохраните файл (Ctrl+O, Enter, Ctrl+X) и выдайте права:

chmod 600 ~/.ssh/authorized_keys

3. Отключение входа по паролю:
Теперь скажем серверу пускать только владельца ключа. Откройте конфигурацию SSH:

nano /etc/ssh/sshd_config

Найдите и измените следующие строки:

PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

Перезапустите службу SSH, чтобы применить настройки:

systemctl restart ssh

Готово! Ваш сервер теперь неприступен, но лучше ещё настройте Firewall и Fail2Ban!

Задача 3: Установка Amnezia VPN

Теперь переходим к самому VPN. Никаких сложных консольных команд больше не будет - всё делается через удобное приложение.

1. Подключение сервера:
   1. Скачайте клиент Amnezia VPN (если не открывается ищите зеркало сайта) для вашего компьютера и запустите его.

   2. Выберите "Настроить свой сервер".

      

   3. Введите IP-адрес сервера и имя пользователя root.

      

   4. В поле "Пароль или закрытый ключ SSH" нужно вставить содержимое вашего приватного ключа.
   5. Откройте PowerShell и введите: cat "$HOME\.ssh\vpn_key". Выделите весь текст от -----BEGIN OPENSSH PRIVATE KEY----- до конца и скопируйте его в окно Amnezia. Нажмите Продолжить.
2. Выбор протокола Xray:
   1. Программа подключится к серверу и предложит варианты настройки. Выберите "Пользовательская установка" (или Мастер настройки), чтобы вручную выбрать протоколы.
   2. Обязательно отметьте протокол Xray. Он обеспечивает максимальную защиту от блокировок по сигнатурам.
   3. Клиент сам установит Docker и развернет контейнеры. Это займет пару минут.
3. Маскировка трафика (SNI):
   Чтобы провайдер не резал скорость, трафик нужно замаскировать под легальный сайт.
   1. Перейдите в настройки сервера в Amnezia -> Протоколы -> Xray.
   2. В поле "Сайт для маскировки" (SNI) впишите крупный зарубежный домен, который не заблокирован в РФ. Отличные вариант будет, чтоб домен находился в той же стране что и Ваш VPS и был.
   3. Сохраните настройки. Сервер перегенерирует ключи.

Этап 4: Раздельное туннелирование (Split Tunneling)

Главная "фишка" Amnezia - возможность выбирать, какие сайты должны ходить через VPN, а какие напрямую. Это полезно, если вам нужно зайти в российский банк или на Госуслуги, не выключая туннель.

1. Перейдите на вкладку "Раздельное туннелирование" в приложении.

   

   

2. Исключение конкретных приложений
   Если вы не хотите, чтобы VPN влиял на пинг в онлайн-играх или работу тяжелого софта, который чувствителен к смене IP, вы можете настроить App-based Split Tunneling.

   1. В настройках выберите режим работы "Приложения из списка не должны работать через VPN" или "Для всех, кроме списка".

      

   2. Добавьте исполняемые файлы (например, browser.exe, discord.exe или ваш рабочий терминал).
      Это позволяет, например, оставить один браузер "чистым" для работы с российскими сервисами, а другой пустить через туннель для обхода блокировок. Единственный минус, это нужна настраивать на каждом клиенте, хотя можно слить настройки в бэкап и разворачивать их.
3.  Доступ к домашнему серверу и локалке (LAN Bypass)
   Типичная проблема: включаешь VPN и больше не можешь зайти на свой домашний NAS, Raspberry Pi или сервер на Proxmox по локальному адресу. Чтобы этого не происходило, в Amnezia нужно настроить исключения для локальных подсетей.
   1. Перейдите в настройки раздельного туннелирования.

   2. В поле для исключения IP-адресов добавьте вашу домашнюю подсеть в формате CIDR.

      

   3. Например, если адрес вашего сервера 192.168.1.10, добавьте диапазон 192.168.1.0/24.
   4. Теперь весь трафик к вашим локальным железкам будет идти напрямую, минуя сервер VPN, а доступ к админ-панелям и сетевым папкам сохранится.

Как поделиться доступом с телефоном?

Вам не нужно настраивать всё заново на смартфоне.

1. Скачайте приложение Amnezia на телефон с Google Play или iStore.
2. В десктопном клиенте (на компьютере) нажмите кнопку «Поделиться» в настройках сервера или подключения.
3. Отсканируйте появившийся QR-код камерой смартфона прямо из приложения Amnezia.

Поздравляем! Теперь у вас есть собственный, надежный и неподконтрольный цензуре VPN, работающий на максимальной скорости вашего провайдера.

Остались вопросы или что-то не работает? Пишите на почту тех поддержки riopass.ru, разберем любые ошибки!

FAQ: Частые вопросы и решение проблем

В: Как правильно выбрать домен для маскировки (SNI) под конкретную страну?
О: Строгой привязки нет, но для максимальной «естественности» лучше выбирать крупные сайты той страны, где физически находится ваш сервер. Это нужно, чтобы у DPI не возникло подозрений, почему плотный трафик в Германию идет под маской сайта США. Ищите сайты главных банков, университетов или государственных порталов (например, для Финляндии - www.nokia.com, для Латвии - www.swedbank.lv, для Германии - www.sap.com).

Важно: Сайт должен поддерживать HTTPS (TLS) и не быть заблокированным в РФ. При смене SNI клиент перегенерирует ключи, их нужно будет обновить на ваших устройствах.

В: Провайдер всё-таки заблокировал IP-адрес моего сервера. Что делать?
О: Такое случается, если ваш сервер привлек внимание систем DPI (например, вы раздали доступ десятку друзей, и они начали одновременно качать торренты).
Решение: Напишите в поддержку вашего хостинг-провайдера с просьбой сменить IP-адрес (многие идут навстречу бесплатно). Если откажут - просто арендуйте новый сервер за пару евро. С нашей инструкцией вы перенастроите всё с нуля ровно за 5 минут.

В: Сервер пингуется, но интернет через VPN не работает (скорость 0 байт/с). В чем дело?
О: Это типичный сценарий работы ТСПУ (систем глубокого анализа трафика Роскомнадзора). Пинг (протокол ICMP) - это крошечные диагностические пакеты, которые почти никогда не блокируют. А вот ваш VPN-трафик идет по другим протоколам (UDP/TCP) и передает большие объемы зашифрованных данных. Провайдер блокирует не сам сервер, а распознанный поток VPN-трафика к нему. Скорее всего, под фильтр попал домен (SNI), под который вы маскируетесь. Смените его в настройках.

В: Скорость через VPN сильно упала (до 0.1 - 1 Мбит/с). Как исправить?
О: Ваш магистральный провайдер пытается "зашейпить" (искусственно ограничить) подозрительный трафик.
Решение: Зайдите в настройки клиента Amnezia -> Протоколы -> Xray и просто смените "Сайт для маскировки" (например, с www.microsoft.com на www.apple.com). Сервер сгенерирует новые ключи, вы станете "новым" пользователем для провайдера, и скорость восстановится. В идеале нужно поставить такой сервис, блокировка трафика которого положила бы пол интернета.
В: Безопасно ли использовать встроенный DNS-сервер от Amnezia?
О: Да, это идеальное решение. Поднятый на вашем сервере DNS предотвращает утечки запросов (DNS Leaks). Вы сами контролируете этот узел: он не собирает логи и никуда ничего не передает. Дополнительный плюс - он кэширует ваши запросы, поэтому при повторном обращении к ресурсам ответ возвращается мгновенно, делая серфинг более быстрым и отзывчивым.

В: VPN подключен, но сайты вообще не грузятся. В чем дело?
О: Если сам туннель работает, но страницы выдают ошибку ERR_NAME_NOT_RESOLVED, значит проблема со службой доменных имен.
Решение: В приложении Amnezia перейдите в Настройки -> Соединение и включите опцию "Использовать кастомный DNS". Впишите туда надежные публичные адреса: 1.1.1.1 (от Cloudflare) или 8.8.8.8 (от Google) или другие публичные DNS.

В: Можно ли поделиться своим VPN с семьей или друзьями?
О: Технически - да. Протокол Xray позволяет использовать один QR-код на множестве устройств одновременно, никаких конфликтов IP-адресов не будет.
Но есть нюанс: Чем больше людей с разных провайдеров (МТС, Ростелеком, Мегафон) будут одновременно генерировать тяжелый трафик на ваш единственный IP-адрес в Европе, тем быстрее этот IP улетит в бан Роскомнадзора. Делитесь доступом с умом и только в узком семейном кругу.

В: Мой российский провайдер увидит, какие сайты я посещаю?
О: Нет. Провайдер и системы цензуры будут видеть только то, что вы установили защищенное HTTPS-соединение с сайтом, который вы указали для маскировки (например, с сервером Microsoft). Весь ваш реальный интернет-серфинг, скачанные файлы и DNS-запросы надежно зашифрованы и спрятаны внутри этого туннеля.
В: Можно ли поднять SOCKS5 прокси на этом сервере?
О: Крайне не рекомендуется выставлять его наружу! Сам по себе SOCKS5 не имеет шифрования. Если вы пропишете внешний (публичный) IP вашего сервера в клиенте, ТСПУ моментально увидит открытый трафик и может заблокировать весь IP-адрес сервера целиком. Использовать SOCKS5 безопасно только в том случае, если он настроен для работы исключительно внутри зашифрованного VPN-туннеля (по внутренним локальным IP-адресам вроде 10.0.x.x).
В: Почему периодически обрывается прямое подключение к серверу по SSH?
О: Чаще всего это банальный таймаут - сервер сам разрывает соединение из-за долгого бездействия (если вы ничего не вводите в консоль). Однако, если падает даже активное подключение, это может означать, что провайдер видит сам факт SSH-соединения с зарубежным IP и обрывает его. В тяжелых случаях поможет смена хостинг-провайдера на менее "засвеченного" у систем фильтрации.

DHCP (Dynamic Host Configuration Protocol) - это сетевой протокол, который автоматически раздает устройствам IP-адреса и другие важные настройки (маску подсети, шлюз по умолчанию и адреса DNS-серверов). Без него каждый адрес в сети пришлось бы вбивать руками.

Процесс получения IP-адреса называется DORA (по первым буквам четырех этапов):

1. D - Discover (Поиск): Новое устройство кричит на всю сеть (широковещательный запрос): "Эй! Мне нужен IP-адрес. Тут есть DHCP-сервер?"
2. O - Offer (Предложение): Роутер (или выделенный сервер) слышит запрос, резервирует свободный адрес и отвечает: "Я тут. Возьми вот этот IP".
3. R - Request (Запрос): Устройство отвечает: "Отлично, беру! Оформи аренду".
4. A - Acknowledge (Подтверждение): Сервер фиксирует выдачу: "Договорились. Адрес твой на следующие 24 часа".

Динамические адреса - это удобно для смартфонов, но плохо для серверов. Например, если вы подняли сервер Minecraft или развернули виртуалку в Proxmox, смена IP после перезагрузки сломает все доступы. Для таких случаев в DHCP используют Static Lease (Резервирование) - жесткую привязку нужного IP-адреса к MAC-адресу сетевой карты устройства.

Пример: Клиентский ПК без интернета
Во время удаленной поддержки клиент жалуется, что сеть "отвалилась". Ты просишь его проверить IP-адрес в настройках Windows, и он диктует что-то вроде 169.254.x.x.
Это так называемый адрес APIPA (Automatic Private IP Addressing). Он означает, что процесс DORA сломался на первом же шаге: ПК прокричал "Discover", но DHCP-сервер ему не ответил (или до него не дошел запрос из-за проблем со свитчем). ОС поняла, что ответа не будет, и назначила себе этот резервный адрес.

Подробнее про APIPA (169.254.x.x)

APIPA (Automatic Private IP Addressing) - это встроенный в операционные системы (Windows, macOS, большинство дистрибутивов Linux) механизм "спасения утопающих".

Когда ПК отправляет широковещательный DHCP Discover, но в ответ тишина (таймаут), ОС понимает: "Сервера нет, но сеть как-то строить надо". Тогда она делает следующее:

1. Выбирает случайный адрес из зарезервированного диапазона 169.254.0.1 – 169.254.255.254 с маской подсети 255.255.0.0 (или /16).
2. Проверяет на конфликты: Перед тем как назначить этот адрес сетевому интерфейсу, ПК отправляет специальный запрос (Gratuitous ARP) в сеть: "Эй, у кого-нибудь уже есть этот 169.254.x.y?". Если ответа нет - забирает адрес себе. Если есть - генерирует новый и спрашивает снова.

APIPA не назначает основной шлюз (Default Gateway) и DNS.
Это значит, что интернета на этом ПК не будет. Однако, если в кабинете стоит свитч, к которому подключены пять компьютеров, и роутер внезапно "умер", все пять ПК получат адреса 169.254.x.x. Они смогут пинговать друг друга, и ты даже сможешь расшарить между ними папку по локалке. Это так называемая Link-Local сеть.

Два DHCP-сервера в одной сети: Эффект гонки (Race Condition)

Представь ситуацию: в офисе работает основной роутер (сеть 192.168.1.0/24), но кто-то из сотрудников принес из дома свой Wi-Fi роутер (сеть 10.0.0.0/24), воткнул его LAN-портом в офисную розетку и забыл выключить на нем DHCP. Это называется Rogue DHCP (ложный/паразитный DHCP-сервер).

Оба сервера находятся в одном широковещательном домене (L2-сегменте). Что произойдет, когда новый клиент включит ПК?

Сработает правило: Кто первый встал, того и тапки.

1. Клиент кричит на всю сеть DHCP Discover.
2. Этот крик слышат оба DHCP-сервера.
3. Оба сервера моментально формируют пакет DHCP Offer (один предлагает 192.168.1.50, другой - 10.0.0.20) и отправляют его клиенту.
4. Клиент получает оба предложения, но принимает то, которое пришло к нему первым. Второе он просто игнорирует.
5. Клиент отправляет DHCP Request на первый пришедший IP, официально забирая его. Проигравший сервер видит это и возвращает свой IP обратно в пул свободных.

От чего зависит скорость ответа?

• От загрузки процессора роутера/сервера.
• От топологии (какой сервер физически ближе по количеству свитчей к клиенту).
• От настроек (некоторые enterprise-серверы искусственно делают микро-задержку пинга перед выдачей IP, чтобы проверить, не занят ли он, а дешевый домашний роутер выпаливает адрес не глядя).

Последствия для сети:

Абсолютный хаос. Половина офиса (те, кто успел получить правильный IP от 192.168.1.x) будет работать нормально. Вторая половина получит IP 10.0.0.x, неправильный шлюз (домашний роутер сотрудника) и останется без интернета и доступа к корпоративным ресурсам. Причем после перезагрузки ПК ситуация может поменяться местами.

Для защиты от таких паразитных серверов на умных (управляемых) коммутаторах настраивают функцию DHCP Snooping. Она разрешает пакетам DHCP Offer проходить только через один конкретный (доверенный) порт, к которому подключен легальный сервер, а на всех остальных портах такие пакеты жестко блокируются.

Защита инфраструктуры: DHCP Snooping

DHCP Snooping - это как раз тот самый "фейсконтроль" на уровне управляемого коммутатора (свитча), который защищает сеть от хаоса с двумя серверами.

Чтобы понять, какой именно порт блокируется, нужно посмотреть на то, как коммутатор делит все свои порты после включения этой функции. Он разбивает их на два лагеря: Trusted (Доверенные) и Untrusted (Недоверенные).

Как это выглядит под капотом
По умолчанию, когда ты включаешь DHCP Snooping на свитче, абсолютно все порты становятся недоверенными (Untrusted). Доверенные порты сетевой администратор должен назначить руками.

1. Trusted (Доверенный) порт: Это порт, к которому физически подключен твой легальный DHCP-сервер (или аплинк-порт, который ведет к другому коммутатору, за которым стоит сервер).
   1. Что разрешено: Через этот порт коммутатор пропускает любые DHCP-пакеты. И запросы от клиентов (Discover, Request), и ответы от сервера (Offer, Acknowledge).
2. Untrusted (Недоверенный) порт:
   1. Это порты, куда подключаются обычные пользователи, рабочие станции, принтеры и, потенциально, тот самый принесенный из дома роутер сотрудника.
   2. Что разрешено: Коммутатор разрешает получать из этого порта только клиентские запросы (Discover, Request), потому что ПК должны иметь возможность попросить IP.
   3. Что БЛОКИРУЕТСЯ: Если из этого порта вдруг "вылетает" пакет от имени сервера (например, DHCP Offer с предложением IP-адреса), коммутатор понимает: "Ага, за этим портом сидит самозванец!". Он моментально отбрасывает (drop) этот пакет, а сам порт может перевести в состояние ошибки (err-disable), выключив на нем линк и отправив алерт админу.

Binding Database

DHCP Snooping Binding Database (База данных привязок) - это специальная таблица, которую коммутатор (свитч) автоматически создает и хранит в своей оперативной памяти, когда на нем активирована функция DHCP Snooping.

Позже эта таблица используется для защиты от подмены IP-адресов и мак-спуфинга (например, с помощью функции Dynamic ARP Inspection), чтобы никто не мог вручную прописать себе чужой IP и перехватывать трафик.

Как выглядит эта таблица

Если зайти в консоль управления коммутатором (например, Cisco) и ввести команду show ip dhcp snooping binding, вы увидите примерно такую картину:

Сама по себе Binding Database - это просто лог-файл. Но она является фундаментом для работы двух очень мощных технологий защиты от хакеров внутри локальной сети:

1. Dynamic ARP Inspection (DAI) - Защита от перехвата трафика
   1. Проблема: Хакер в локальной сети может отправить фальшивое сообщение (ARP-ответ) всем компьютерам: "Эй, теперь я ваш роутер (шлюз), отправляйте весь интернет-трафик через меня!". Это называется атакой Man-in-the-Middle (Человек посередине).
   2. Как помогает база: Если включить DAI, коммутатор перестает верить устройствам на слово. Когда порт хакера пытается заявить: "Мой IP - это IP роутера", свитч мгновенно сверяется с Binding Database. Он видит: "Так, на порту №8 у нас числится IP 192.168.1.51, а ты пытаешься выдать себя за шлюз 192.168.1.1. Блокирую!". Пакет уничтожается.
2. IP Source Guard (IPSG) - Защита от подмены IP-адреса
   1. Проблема: Пользователь может вручную зайти в настройки сетевого адаптера Windows и прописать себе чужой IP-адрес (например, адрес начальника или сервера), чтобы получить чужие права доступа или избежать ограничений по скорости.
   2. Как помогает база: Свитч проверяет каждый исходящий пакет данных от пользователя. Если в пакете указан IP-адрес отправителя 192.168.1.100, а в базе привязок за этим портом числится 192.168.1.50, коммутатор просто не выпустит этот трафик за пределы порта.

Атака "Человек посередине" (Man-in-the-Middle, MITM) - это вид кибератаки, при которой злоумышленник тайно перехватывает (и зачастую изменяет) канал связи между двумя сторонами. Жертвы при этом уверены, что общаются напрямую друг с другом.

В классическом сценарии пользователь отправляет данные на сервер, но они сначала попадают на устройство злоумышленника. Злоумышленник читает информацию, может её модифицировать, и только потом отправляет конечному серверу. Чтобы это работало с зашифрованными протоколами (такими как HTTPS или MTProto в Telegram), атакующему необходимо подменить ключи шифрования, чтобы устройство жертвы доверяло "промежуточному" серверу как оригинальному.

 Несколько реальных MITM‑атак:
1. Wi‑Fi Honeypot
Фальшивая точка доступа с именем вроде “Free Airport Wi‑Fi”.
Пользователь подключается - весь трафик идёт через злоумышленника.

2. ARP Spoofing в офисной сети
Атакующий убеждает жертву, что он - это шлюз.
Жертва отправляет пакеты злоумышленнику - он пересылает их дальше.

3. Подмена DNS

Жертва думает, что заходит на tbank.ru , а попадает на поддельный сайт.

4. Корпоративный MITM‑прокси

Компании устанавливают свой корневой сертификат CA и расшифровывают HTTPS для мониторинга.

Анализ MITM-атаки в клиенте Telega

Полный технический анализ MITM в клиенте Telega

Авторы статьи выяснили, что создатели этого приложения намеренно внедрили в него функционал для полного перехвата и чтения переписки своих пользователей.

Вот как технически реализована эта атака внутри клиента:
1. Подмена IP-адресов серверов (DC Proxy)
Оригинальный Telegram имеет жестко прописанные адреса своих дата-центров (DC). Клиент Telega при запуске обращается к своему собственному API (https://api.telega.info/v1/dc-proxy) и получает список подменных IP-адресов. В результате приложение направляет весь трафик не на настоящие серверы Telegram, а на серверы, контролируемые создателями Telega (зарегистрированные на их собственную автономную систему).
2. Внедрение собственного RSA-ключа шифрования
Просто перенаправить трафик недостаточно - оригинальный Telegram использует публичные RSA-ключи, вшитые в приложение, для первичного обмена ключами сессии. Сервер должен иметь соответствующий приватный ключ, иначе соединение не установится.
Реверс-инжиниринг библиотеки libtmessages.49.so в клиенте Telega показал, что разработчики добавили свой собственный (дополнительный) публичный RSA-ключ, которого нет в официальном клиенте. Благодаря этому, когда клиент Telega связывается с подставным сервером, этот сервер может расшифровать первичный запрос с помощью своего приватного ключа. Это классический пример MITM - сервер злоумышленников (Telega) терминирует на себе шифрование, читает данные в открытом виде, а затем уже от своего имени отправляет их на настоящие серверы Telegram.
3. Отключение Perfect Forward Secrecy (PFS)
PFS - это криптографическое свойство, которое гарантирует, что даже если долгосрочный ключ будет скомпрометирован в будущем, прошлые сессии расшифровать не удастся (так как для каждой сессии генерируются уникальные ключи). В коде Telega передача флага usePfs была модифицирована таким образом, что эта дополнительная защита отключена по умолчанию.
4. Принудительное отключение секретных чатов (End-to-End)
Секретные чаты в Telegram используют сквозное (End-to-End) шифрование, при котором ключи генерируются только на устройствах собеседников и не передаются на сервер. MITM-атака на такие чаты практически невозможна без ведома пользователей.
Чтобы обойти эту "проблему", клиент Telega через удаленные настройки (Remote Config Firebase) получает флаг enable_sc = false. Из-за этого приложение полностью скрывает кнопку создания секретного чата, а все входящие запросы на секретный чат тихо игнорируются, лишая пользователей возможности безопасного общения.

5. Встроенная цензура (Модерация)
Помимо перехвата трафика, авторы статьи обнаружили систему "черных списков", работающую независимо от модерации самого Telegram. Клиент по команде со своих серверов может блокировать пользователям доступ к определенным каналам, ботам и даже личным сообщениям с конкретными людьми.

Приложение Telega - это троянский конь. Разработчики клиента целенаправленно разрушили криптографическую защиту Telegram (подменили серверы связи, внедрили свой RSA-ключ и отключили E2E-шифрование), чтобы пропускать весь трафик через себя и иметь возможность читать, анализировать или модифицировать переписку пользователей. Это подчеркивает главное правило кибербезопасности: использование неофициальных клиентов мессенджеров полностью компрометирует безопасность вашей переписки.

Почему классический MITM невозможен в официальном Telegram (MTProto + Fake TLS)?

После прочтения разбора "Телеги" может возникнуть вопрос: а может ли провайдер, товарищ майор или хакер в публичном Wi-Fi перехватить трафик обычного Telegram, например, вклинившись в соединение через прокси? Короткий ответ - нет. И вот почему сеть Telegram (на базе протокола MTProto и обертки Fake TLS) криптографически защищена от атак «Человек посередине» на уровне сети:

• Абсолютное доверие только вшитым ключам: В официальном приложении Telegram "намертво" прописаны публичные RSA-ключи серверов (те самые, которые создатели Telega подменили в своем коде). Если кто-то попытается вклиниться в сеть и подсунуть свой сертификат или ключ, официальный клиент просто откажется устанавливать соединение.
• Fake TLS - это только маскировка: Технология Fake TLS (используемая в MTProxy) создана для обхода систем DPI (глубокого анализа пакетов). Она "заворачивает" пакеты Telegram в оболочку, которая для провайдера выглядит как обычное защищенное соединение с условным google.com. Если оборудование попытается просканировать этот трафик методом MITM, прокси-сервер сбросит соединение или прикинется обычным веб-сайтом.
• Двойное шифрование: Даже если злоумышленник узнает «секрет» вашего MTProxy и снимет обертку Fake TLS, внутри он обнаружит монолитный зашифрованный MTProto-трафик. Ключи для его расшифровки генерируются непосредственно на вашем устройстве (по протоколу Диффи-Хеллмана) и никогда не передаются по сети в открытом виде.

Главный вывод: Архитектура Telegram выстроена так, что перехватить трафик "по пути" от вашего смартфона до серверов - математически нерешаемая задача на сегодняшний день. Именно поэтому единственный способ читать чужую переписку - это заставить жертву добровольно установить зараженный клиент (как Telega), который сольет ключи прямо с устройства.

Интернет может казаться магией, но под капотом скрываются строгие и логичные алгоритмы. Один из самых важных - это DNS (Domain Name System или Система доменных имён). Если бы не DNS, нам бы пришлось запоминать длинные ряды цифр вместо удобных названий сайтов, таких как www.riopass.ru.

Что такое DNS?

Представьте себе классическую телефонную книгу. Вы знаете имя человека (например, Иван Иванов), но вам нужен его номер телефона, чтобы дозвониться. Вы открываете книгу, находите имя и смотрите соответствующий ему номер.

DNS делает абсолютно то же самое для интернета:

• Люди привыкли использовать понятные доменные имена (например, yandex.ru, google.com).
• Компьютеры и серверы общаются друг с другом исключительно с помощью IP-адресов (например, 192.0.2.1 или 2a00:1450:4010:c05::8b).

DNS - это глобальная телефонная книга интернета, которая мгновенно переводит человекочитаемые адреса в машинные IP-адреса.

Как происходит преобразование адреса?

Когда вы вводите адрес в строку браузера и нажимаете Enter, начинается увлекательное путешествие, которое обычно занимает миллисекунды. Этот процесс делится на два больших этапа: локальный поиск и поиск в глобальной сети.

Локальное преобразование
Прежде чем беспокоить глобальные серверы, ваш компьютер пытается найти ответ у себя "в карманах".

• Кэш браузера: Ваш браузер (Chrome, Safari, Firefox) хранит записи о сайтах, которые вы недавно посещали. Первым делом он проверяет свой собственный кэш.
• Кэш операционной системы (ОС): Если браузер не нашел IP-адрес, он передает запрос операционной системе (Windows, macOS, Linux). ОС проверяет свой кэш DNS. Также на этом этапе проверяется локальный файл hosts (специальный текстовый файл, где пользователи могут вручную прописать соответствие IP и домена).
• Кэш маршрутизатора (Роутера): Если на компьютере ответа нет, запрос уходит на ваш домашний или офисный роутер. У него тоже есть своя небольшая память для DNS-запросов.

Если ни на одном из этих локальных этапов IP-адрес не найден, компьютер обращается за помощью во внешний мир.

Клиент -> Резолвер: рекурсивный запрос
Резолвер -> ROOT/TLD/авторитетный: итеративные запросы

Преобразование в рамках интернета

Здесь в игру вступает иерархия серверов интернета. Ваш запрос передается рекурсивному DNS-серверу (обычно его предоставляет ваш интернет-провайдер). Его задача - бегать по инстанциям, пока не найдет нужный ответ.

Вот как выглядит его маршрут:

• Корневые серверы (Root Nameservers):
  Рекурсивный сервер не знает, где находится example.com, поэтому он идет к "самым главным" серверам интернета - корневым. Они не знают точного IP-адреса сайта, но знают, кто отвечает за зону .com, .ru или .org.
• Серверы доменных зон верхнего уровня (TLD Nameservers):
  Корневой сервер отправляет запрос к серверу, отвечающему за конкретную зону (например, к TLD-серверу зоны .com). Этот сервер тоже не знает точный IP сайта, но знает, у какого сервера находится эта информация.
• Авторитативные серверы (Authoritative Nameservers):
  Это финальная инстанция. TLD-сервер указывает на авторитативный сервер, который физически хранит нужную DNS-запись для example.com. Этот сервер выдает точный IP-адрес.

Рекурсивный сервер получает IP-адрес, сохраняет его в свой кэш (чтобы в следующий раз ответить быстрее) и отдает вашему браузеру. Браузер подключается к серверу по полученному IP-адресу, и вы видите сайт.

Виды DNS-запросов: Как именно общаются серверы

1. Рекурсивный запрос (Recursive Query)
   Это запрос в стиле: "Сделай всю работу за меня и дай готовый ответ".
   Когда ваш компьютер обращается к DNS-серверу провайдера (или к 8.8.8.8), он отправляет именно рекурсивный запрос. Это означает, что сервер берет на себя обязательство пройти по всем инстанциям (корневые серверы, TLD, авторитативные) и вернуть вашему компьютеру либо готовый IP-адрес, либо сообщение об ошибке (если домена не существует). Ваш компьютер при этом просто ждет.
2. Итеративный запрос (Iterative / Non-recursive Query)
   Это запрос в стиле: "Дай мне лучший ответ, который у тебя есть прямо сейчас".
   Именно так общаются между собой сами DNS-серверы в глобальной сети. Когда рекурсивный сервер провайдера спрашивает корневой сервер: "Где example.com?", он делает итеративный запрос. Корневой сервер не будет искать ответ сам. Он скажет: "Я не знаю точный IP, но я знаю, кто отвечает за зону .com. Вот его адрес, иди спроси у него". Рекурсивный сервер принимает этот ответ и делает следующий итеративный запрос уже к TLD-серверу.

Направления запросов: Прямые, Обратные и Инверсные

Помимо способа поиска, запросы делятся по тому, что именно мы ищем. Здесь важно не путать термины.

1. Прямой запрос (Forward DNS Query)
   Это классика, о которой мы говорили выше. У нас есть доменное имя (человекочитаемое), и мы хотим получить его IP-адрес (машинный).
   Это самый частый сценарий. Допустим, мы хотим узнать, на каком IP-адресе "живет" сайт riopass.ru.
   В Windows (через cmd или PowerShell): -> Введите команду: -> nslookup riopass.ru, если порт 53 заблокирован то nslookup riopass.ru 8.8.8.8
   В ответе вы увидите DNS-сервер, который обработал ваш запрос, и ниже сам IP-адрес сайта.

2. Обратный запрос (Reverse DNS Query / rDNS)
   Здесь всё наоборот: у нас есть IP-адрес, и мы хотим узнать, какое доменное имя за ним закреплено. Это часто используется для проверки на спам (почтовые серверы проверяют, совпадает ли IP-адрес отправителя с его доменом) или при трассировке сетей (утилита traceroute). Для этого используется специальная доменная зона in-addr.arpa и записи типа PTR (Pointer).

   Теперь попробуем выполнить rDNS-запрос. Возьмем всем известный публичный DNS-сервер от Google с адресом 8.8.8.8 и проверим, какое доменное имя за ним закреплено в глобальной сети. В Windows: ->Просто введите IP вместо домена: -> nslookup 8.8.8.8 -> В ответе в строке Name: вы увидите dns.google.

3. Инверсный запрос (Inverse Query / IQUERY)
   А вот здесь кроется технический нюанс, о котором многие забывают. Инверсный запрос - это старый и специфический механизм. В нем клиент просил сервер найти доменное имя, основываясь на любой известной ресурсной записи (не обязательно на IP-адресе).
   Из-за высокой нагрузки на серверы и сложностей в реализации, инверсные запросы были официально признаны устаревшими (deprecated) еще в 2002 году документом RFC 3425. Сегодня в современном интернете они не используются, их место полностью заняли обратные запросы (rDNS).

Дополнение:
По умолчанию утилиты ищут A-запись (IPv4-адрес). Но если вам нужно узнать, какие серверы обрабатывают электронную почту для домена (MX-записи), тип запроса нужно указать явно. Попробуем на примере Яндекса: -> В Windows: -> nslookup -type=MX yandex.ru

В Linux / macOS: -> dig yandex.ru MX +short -> В ответ вы получите список серверов (например, mx.yandex.ru) и их приоритеты - именно туда отправляются письма, когда вы пишете на адрес @yandex.ru.

Часто задаваемые вопросы (FAQ)

1. Почему при переезде сайта на другой хостинг он какое-то время не работает?
Это связано с процессом обновления кэша. На каждом этапе (у провайдеров, на роутерах) DNS-записи кэшируются на определенное время (этот параметр называется TTL - Time to Live). Пока это время не истечет, серверы будут отдавать старый IP-адрес. Полное обновление по всему миру может занимать от пары часов до 48 часов.

2. Что значит "Сбросить DNS-кэш" (Flush DNS)?
Иногда ваш компьютер запоминает устаревший или ошибочный IP-адрес (например, если сайт недавно сменил сервер). Очистка (сброс) кэша заставляет операционную систему забыть старые данные и выполнить глобальный поиск заново, получив актуальный адрес.

3. Зачем люди меняют DNS-серверы на 8.8.8.8 (Google) или 1.1.1.1 (Cloudflare)?
По умолчанию вы используете рекурсивные серверы вашего интернет-провайдера. Иногда они работают медленно, нестабильно или блокируют определенные ресурсы. Переключение на публичные серверы от Google или Cloudflare часто ускоряет загрузку страниц и повышает приватность.

4. Что такое записи типа A, CNAME, MX?
На авторитативном сервере данные хранятся в виде разных записей:

• A-запись: Связывает домен с IPv4-адресом (самая частая).
• CNAME: "Псевдоним", связывает один домен с другим (например, www.site.com с site.com).
• MX-запись: Указывает, какой сервер обрабатывает электронную почту для этого домена.

Сетевые сокеты (Berkeley Sockets).
С точки зрения операционной системы, сокет - это дескриптор файла. В Unix-подобных системах "всё есть файл", и сокет не исключение. Это абстракция, которая позволяет программе читать и записывать данные в сеть так же просто, как в текстовый документ на диске.

Техническая формула: Socket = IP Address + Port + Protocol (TCP/UDP)
Дескриптор файла - это маленькое целое число, которое операционная система выдаёт процессу, когда тот открывает файл, сокет, канал, pipe, устройство или любой другой ресурс ввода‑вывода. Это идентификатор, через который программа взаимодействует с ресурсом.

История: Эпоха BSD

История Berkeley Sockets API - это фактически история того, как интернет стал интернетом. До 1983 года мир сетевых технологий напоминал Вавилонскую башню: каждый производитель железа (IBM, DEC, Xerox) имел свои протоколы, которые не умели "разговаривать" друг с другом.

В начале 80-х программирование под сеть было кошмаром. Если вы писали софт для мейнфрейма IBM, вы использовали одни системные вызовы; для машин DEC - другие. Не существовало единой абстракции "соединения".

Разработчики из Computer Systems Research Group (CSRG) в Университете Беркли, работая над релизом 4.2BSD, поставили цель: сделать работу с сетью такой же простой, как работу с файлами в Unix.

"Всё есть файл"

Гениальность Berkeley Sockets заключалась в адаптации концепции Unix "Everything is a file".

• Чтобы прочитать данные из файла, вы его открываете, читаете и закрываете.
• Билл Джой и его команда предложили делать то же самое с сетью.

Они ввели понятие дескриптора сокета. Сокет - это "конечная точка" (IP-адрес + Порт). Программисту стало неважно, как именно пакеты летят по проводам; ему достаточно было создать сокет и писать в него данные.

Популярность Berkeley Sockets была обусловлена двумя факторами:

• Открытость: Код BSD был доступен для изучения и копирования.
• Финансирование DARPA: Агентство продвигало TCP/IP как основной протокол для своей сети (предшественника интернета), и реализация Беркли была лучшей на рынке.

Как это работает  жизненный цикл сокета(Lifecycle)?

Жизненный цикл сокета - это последовательность системных вызовов, через которые проходит любое сетевое соединение. Каждый шаг меняет состояние сокета в ядре и определяет, что с ним можно делать дальше. Ниже - подробное, но компактное объяснение, ориентированное на разработчика, который хочет понимать, что реально происходит под капотом.

Чтобы понять, как работает жизненный цикл сокета, проще всего представить его как процесс установки телефонной связи в офисе. Есть "телефонный аппарат" (сам сокет), "номер" (IP и порт) и "оператор" (ядро ОС).

1. socket() - Покупка телефона
Процесс начинается с системного вызова socket(). На этом этапе вы просто сообщаете операционной системе: "Мне нужно устройство для связи".

• Что происходит: ОС выделяет ресурс и возвращает дескриптор (целое число).
• Параметры: Вы выбираете "тип" связи. Обычно это AF_INET (IPv4) и SOCK_STREAM (TCP, для надежности) или SOCK_DGRAM (UDP, для скорости).

2. bind() - Присвоение номера
У вас есть телефон, но у него нет номера. Вызов bind() привязывает сокет к конкретному адресу сетевой карты и порту.

• Для сервера: Это обязательно. Сервер должен "сидеть" на известном порту (например, 80 для HTTP), чтобы клиенты знали, куда стучаться.
• Для клиента: Обычно не вызывается вручную; ОС сама выделяет свободный случайный порт при подключении.

3. listen() - Перевод в режим ожидания (Только сервер)
Этот вызов превращает обычный сокет в пассивный. Сервер говорит системе: "Я готов принимать звонки".

• Очередь (backlog): В параметрах указывается размер очереди. Если 10 клиентов постучатся одновременно, а сервер занят, listen определит, сколько из них подождут, а кому сразу придет отказ.
• Что происходит, если очередь заполнена? Пришли 10 клиентов, они сидят в очереди в ядре ОС. Пришёл 11, ОС смотрит "мест нет". ОС либо просто игнорирует пакет (клиент отвалится по таймауту), либо отправляет ему ECONNREFUSED (отказ в соединении).

4. connect() vs accept() - Установка связи
Здесь пути клиента и сервера расходятся:

• connect() (Клиент): Клиент инициирует "трехэтапное рукопожатие" (TCP Three-way Handshake). Он отправляет запрос серверу.
• accept() (Сервер): Это блокирующий вызов. Сервер "засыпает" на этой строчке кода, пока не придет клиент. Как только соединение установлено, accept "просыпается" и создает новый отдельный сокет специально для этого клиента.
• Важно: Основной сокет продолжает слушать других, а новый - используется для общения с конкретным подключившимся пользователем.

5. send() / recv() - Разговор
Когда соединение установлено, начинается обмен данными.

• Байты, а не объекты: Сокеты ничего не знают о JSON, картинках или тексте. Они передают только сырые байты.
• Потоковый режим: В TCP данные могут прийти не целиком, а кусками. Разработчику нужно проверять, сколько байт реально получено, и "склеивать" их.

6, close() - Повесить трубку
Когда данные переданы, одна из сторон (или обе) вызывает close(). Это высвобождает дескриптор в ОС и закрывает порт.

WebSockets: Живое общение в браузере

Протокол HTTP (до версии 1.1 включительно) был "молчаливым". Клиент спросил - сервер ответил - соединение закрылось. Чтобы сделать чат, браузеру приходилось каждые 2 секунды отправлять пустые запросы (Polling). Это создавало огромную нагрузку на сервер и дикие задержки.
Протокол WebSocket (RFC 6455)
В 2011 году появился WebSocket. Его главная фишка - Full-Duplex (полный дуплекс). Это значит, что и клиент, и сервер могут одновременно слать данные друг другу по одному открытому каналу.
Почему HTTP не справлялся?

Чтобы понять ценность WebSocket, нужно осознать масштаб проблемы Polling (опроса).

Представьте чат на 1000 человек. При обычном опросе (Short Polling) сервер получает 500 запросов в секунду, даже если никто ничего не пишет. Каждый такой запрос - это:

• Установление TCP-соединения (3-way handshake).
• Огромные HTTP-заголовки (Cookies, User-Agent), которые весят больше, чем само сообщение "Привет".
• Закрытие соединения.

Long Polling (длинные опросы) немного спасали ситуацию: сервер держал запрос открытым, пока не появятся данные. Но это все равно был "костыль", съедающий ресурсы сервера.

Внутри канала: Что такое Фреймы (Frames)?

Когда соединение установлено, данные больше не передаются в виде текста с заголовками. Они упаковываются в бинарные фреймы.

Фрейм - это очень компактный конверт. В нем есть:

• FIN бит: Указывает, является ли этот кусок данных финальным или за ним последуют еще.
• Opcode: Тип данных (0x1 - текст, 0x2 - бинарные данные, 0x8 - закрытие соединения, 0x9 - пинг).
• Payload length: Размер данных. Для маленьких сообщений заголовок фрейма весит всего 2-10 байт. Сравни это с 500+ байтами заголовков HTTP.

Ключевые отличия для IT-специалиста

Сетевой сокет (L4): Это программный интерфейс (API) операционной системы. Когда ты открываешь сокет, ты говоришь ОС: "Выдели мне порт и отправляй все байты с этого IP-адреса моему приложению".

WebSocket (L7): Это протокол прикладного уровня. Он добавляет к "сырому" сокету правила: как поздороваться (Handshake), как зашифровать данные (Masking) и как делить поток байтов на понятные сообщения (Frames).

Когда и что выбирать?