4.9 KiB
на базе Red Hat
firewall-cmd --zone=public --add-masquerade --permanentfirewall-cmd --reload
На базе Debian
firewall Ubuntu - ufw
# Установка UFW
sudo apt update
sudo apt install ufw
# Открываем порт, используемый для SSH (по умолчанию 22)
sudo ufw allow <ssh-port>/tcp
# Закрываем все входные
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Включаем фаерволл
sudo ufw enable
# Перезагрузить
ufw reload
# Показать состояние ufw и активные правила
sudo ufw status verbose
ufw status numbered
# Отключить фаерволл
sudo ufw disable
# Удалить правило (будут применены настройки по умолчанию)
sudo ufw delete allow <port>/<protocol> # удалить разрешение
sudo ufw delete deny <port>/<protocol> # удалить запрет
# Сброс всех правил
sudo ufw reset
# Вывести логи ufw
sudo tail -f -n 100 /var/log/ufw.log
# Изменить уровень логирования
sudo ufw logging <low/medium/high>
# Разрешить доступ ко всем портам с определённого IP-адреса
sudo ufw allow from <IPv4>
# Разрешить доступ к порту с определённого IP-адреса
sudo ufw allow from <IPv4> to any port <port>
# Пресеты
# Вывести список пресетов
sudo ufw app list
# Открыть все соединения, которые нужны Nginx
sudo ufw allow "Nginx Full"
# Удалить правило для пресета
sudo ufw delete allow "Nginx Full"
# Интерфейсы
sudo ufw allow in on wg0
sudo ufw allow out on wg0
Да, все данные в конечном счёте передаются в бинарном виде, потому что сеть работает с битами и байтами. Но разница в том, как и где происходит эта "бинаризация" данных.
⚡ HTTP/1.1: Текстовый протокол с бинарной передачей на сетевом уровне Формат данных: человекочитаемый текст (например, заголовки GET / HTTP/1.1 и тело в формате JSON). Процесс передачи: Сервер создаёт текстовый HTTP-запрос. Когда данные отправляются через сетевой стек (TCP/IP), они преобразуются в биты и байты для физической передачи. Важно: серверу и клиенту нужно "читать" эти текстовые данные, что добавляет накладные расходы на парсинг и обработку. 🚀 HTTP/2: Бинарный протокол уже на уровне приложения Формат данных: заголовки и служебные данные сразу преобразуются в бинарные фреймы ещё до того, как они попадут в сетевой стек.
Процесс передачи:
Сервер упаковывает запросы в бинарные фреймы (например, HEADERS, DATA), ещё на уровне приложения. Эти бинарные фреймы напрямую передаются по TCP, без дополнительной текстовой обработки. Преимущества:
Меньше накладных расходов на парсинг. Эффективнее сжатие заголовков (HPACK). Возможность мультиплексирования (несколько запросов в одном соединении). 🤖 gRPC (на HTTP/2): Максимальная бинаризация Здесь бинаризация идёт ещё глубже: Сами данные (не только заголовки) сериализуются в бинарный формат с помощью Protobuf. Это даёт ещё большую производительность по сравнению с текстовыми форматами (например, JSON). 🎯 Краткий вывод: HTTP/1.1: текстовый формат на уровне приложения → преобразование в биты на уровне сети. HTTP/2: бинарный формат уже на уровне приложения → передача в сеть без дополнительного преобразования. gRPC: данные бинаризуются ещё глубже (через Protobuf) и передаются поверх HTTP/2. Если нужно, могу показать примеры пакетов в Wireshark для наглядности. 🚀