mirror of
https://github.com/ilyamak04/DevOps.git
synced 2025-04-05 15:34:49 +02:00
100 lines
4.9 KiB
Markdown
100 lines
4.9 KiB
Markdown
### на базе Red Hat
|
||
|
||
- `firewall-cmd --zone=public --add-masquerade --permanent`
|
||
- `firewall-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 для наглядности. 🚀 |