TCP/IP: как не убить сеть, когда она уже работает — инженерное руководство по настройке и отладке

TCP/IP — это не просто набор протоколов, а архитектура, которая определяет, как данные перемещаются по сети от точки А в точку Б. В теории всё выглядит логично: приложение отправляет запрос, TCP гарантирует доставку, IP маршрутизирует пакеты, а физический слой обеспечивает передачу. Но на практике всё гораздо сложнее: пакеты теряются, соединения обрываются, маршрутизация работает как лотерея, а логи серверов пестрят ошибками "Connection reset by peer". В этой статье мы разберёмся, как TCP/IP работает в реальных условиях, какие инженерные решения помогут избежать проблем и как отлаживать сеть, когда она уже "работает", но работает плохо.

Почему сеть перестаёт быть предсказуемой: реальные сценарии

Представьте ситуацию: у вас есть микросервисная архитектура, где десятки сервисов общаются через API. Всё работает стабильно, пока не произойдёт одно из следующего:

  • Масштабирование: количество запросов растёт экспоненциально, а TCP-соединения начинают падать из-за перегрузки.
  • Изменение конфигурации: новый член команды "слегка" меняет настройки маршрутизатора, и трафик между двумя дата-центрами начинает теряться.
  • Обновление ПО: после апгрейда ОС или сетевых драйверов появляются задержки или сбросы соединений.
  • Внешние факторы: провайдер обновил маршруты, и ваш трафик теперь идёт через страны с высокой лаженностью, увеличивая задержки в 10 раз.

В таких случаях проблема редко кроется в приложении — чаще всего это ошибки на уровне TCP/IP. Давайте разберёмся, как этого избежать.

Как TCP/IP работает на самом деле: инженерные детали

TCP/IP — это четырёхслойная модель, но на практике каждый слой имеет свои подводные камни. Давайте рассмотрим их подробно.

1. Прикладной слой: HTTP/2, gRPC и другие протоколы

На этом уровне работают ваши приложения: HTTP, FTP, SSH, gRPC и другие. Но даже здесь могут быть проблемы:

  • HTTP/1.1 vs HTTP/2: если сервер поддерживает только HTTP/1.1, а клиенты используют HTTP/2, могут возникать проблемы с multiplexing (мультиплексированием) соединений.
  • gRPC и TCP-таймауты: gRPC использует HTTP/2 поверх TCP, и если таймауты на уровне TCP слишком короткие, соединения будут обрываться при долгих запросах.
  • Кеширование и CDN: если CDN не настроен правильно, запросы могут уходить в никуда, а клиенты получать ошибки 504 (Gateway Timeout).

Пример: Если ваш сервис использует gRPC и клиенты жалуются на "deadline exceeded", проверьте настройки таймаутов как в приложении, так и на уровне TCP (tcp_keepalive_time, tcp_fin_timeout).

2. Транспортный слой: TCP vs UDP и их настройки

Здесь ключевые протоколы — TCP (гарантированная доставка) и UDP (без гарантий). Но даже TCP не так прост, как кажется.

TCP: механизмы и настройки

TCP использует несколько механизмов для обеспечения надёжности:

  1. Sliding Window: контролирует количество не подтверждённых пакетов. Если окно слишком большое, сеть может завалиться (network congestion).
  2. ACK и Retransmission: если пакет не подтверждён (ACK не пришёл), TCP переотправляет его. Но если сеть нестабильна, это может привести к бесконечным ретрансмиссиям.
  3. Slow Start и Congestion Control: алгоритмы, которые регулируют скорость передачи данных при перегрузке. Если они настроены неправильно, производительность может падать.

Ключевые параметры TCP в Linux и их влияние:

Параметр Описание Рекомендация для высоконагруженных систем
tcp_window_scaling Включает масштабирование окна для больших сетей. Включить (=1), если сеть с высокой задержкой.
tcp_retries2 Количество попыток переотправки при потере пакета. Увеличить до 10-15 для нестабильных сетей.
tcp_keepalive_time Время до отправки keepalive-пакета для проверки активности соединения. Уменьшить до 300 секунд для сервисов с частыми запросами.
tcp_fin_timeout Время ожидания закрытия соединения (CLOSE_WAIT). Уменьшить до 30-60 секунд, чтобы избежать утечек.
tcp_tw_reuse Позволяет повторно использовать TIME_WAIT-порты. Включить (=1) для серверов с высокой нагрузкой.
tcp_max_syn_backlog Максимальное количество ожидающих SYN-пакетов. Увеличить до 8192 для серверов с большим количеством подключений.

Пример конфигурации для сервера с высокой нагрузкой:

# Увеличиваем размер окна для большей пропускной способности
echo "net.ipv4.tcp_window_scaling=1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_rmem=4096 87380 16777216" >> /etc/sysctl.conf  # Минимальное/по умолчанию/максимальное
echo "net.ipv4.wmem=4096 65536 16777216" >> /etc/sysctl.conf

# Настраиваем таймауты и ретрансмиссии
echo "net.ipv4.tcp_retries2=15" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_time=300" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_probes=5" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_intvl=60" >> /etc/sysctl.conf

# Оптимизируем TIME_WAIT и SYN-queue
echo "net.ipv4.tcp_tw_reuse=1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog=8192" >> /etc/sysctl.conf

# Применяем изменения
sysctl -p

Когда это критично:

  • Если ваш сервис работает с клиентами по всему миру (например, глобальное API), настройка tcp_window_scaling и увеличение размеров буферов (tcp_rmem, tcp_wmem) может улучшить производительность в 2-3 раза.
  • Если у вас много коротких соединений (например, микросервисы), уменьшение tcp_fin_timeout поможет избежать накопления состояний CLOSE_WAIT.

UDP: когда гарантии не нужны

UDP используется, когда важна скорость, а не надёжность: VoIP, видеостриминг, DNS, QUIC. Но и здесь есть подводные камни:

  • Потери пакетов: если приложение не реализовано с учётом потерь (например, не использует FEC — Forward Error Correction), качество связи упадёт.
  • Порты и брандмауэры: UDP-пакеты могут блокироваться на уровне брандмауэра, если не настроены правильные правила.
  • Бroadcast и Multicast: если ваше приложение использует broadcast-трафик (например, для обнаружения устройств в локальной сети), убедитесь, что маршрутизаторы не блокируют его.

Пример: Если ваш VoIP-сервис работает через UDP, но качество звука плохое, проверьте:

  1. Потери пакетов с помощью ping -c 100 <сервер> (хотя ping использует ICMP, это может дать представление о потере пакетов).
  2. Настройки брандмауэра (iptables -L -n или ufw status).
  3. Нагрузку на сеть (iftop, nload).

3. Сеть (Network): IP и маршрутизация

Здесь происходит основная "магия" — пакеты должны дойти из точки А в точку Б. Но на практике это не всегда так.

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

  • Public vs Private IP: если ваш сервер использует private IP (например, 10.0.0.1), но должен быть доступен из интернета, убедитесь, что настроен NAT или проброс портов.
  • Subnet Mask: неправильная маска подсети может привести к тому, что трафик не будет маршрутизироваться между подсетями. Например, если у вас /24 и /25, а маршрутизатор не знает о /25, трафик уйдёт в никуда.
  • CIDR: при настройке маршрутов используйте правильные блоки CIDR. Например, 192.168.1.0/24 — это 256 адресов, а 192.168.1.0/25 — только 128.

Пример ошибки: Если у вас есть два сервера в одной подсети (192.168.1.0/24), но один из них настроен с маской /25, они не смогут общаться друг с другом, потому что их адреса будут в разных подсетях.

Маршрутизация: статические и динамические маршруты

Маршрутизация может быть статической (ручной настройкой) или динамической (протоколы OSPF, BGP).

Статические маршруты:

# Добавление статического маршрута в Linux
sudo ip route add 192.168.2.0/24 via 192.168.1.2 dev eth0

# Проверка маршрутов
ip route show

Вывод может выглядеть так:

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
192.168.2.0/24 via 192.168.1.2 dev eth0

Если маршрут отсутствует, пакеты уйдут по дефолтному маршруту (обычно в интернет), и вы получите ошибку "Network unreachable".

Динамическая маршрутизация: Если у вас большая сеть, используйте протоколы:

  • OSPF для внутренней маршрутизации.
  • BGP для внешней (между провайдерами).

Пример проблемы с динамической маршрутизацией: Если два маршрутизатора обмениваются маршрутами через OSPF, но один из них не отправляет обновления (например, из-за фильтрации трафика на уровне ACL), сеть разделится на две части, и трафик между ними перестанет работать.

Traceroute и MTR: как найти утечку

Если пакеты теряются, используйте traceroute или mtr (комбинация traceroute и ping):

# Traceroute в Linux
traceroute google.com

# MTR (более детальный анализ)
mtr google.com

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

1  192.168.1.1 (192.168.1.1)  0.5 ms  0.4 ms  0.3 ms
2  10.0.0.1 (10.0.0.1)  12.3 ms  11.8 ms  12.1 ms
3  * * *
4  203.0.113.45 (203.0.113.45)  45.2 ms  44.8 ms  45.0 ms

Звёздочки (*) означают потерю пакетов. Если они появляются на каком-то hop'e, проблема может быть в маршрутизаторе или линии связи на этом участке.

4. Ссылка (Link): Ethernet, Wi-Fi и физический уровень

На этом уровне происходят реальные потери пакетов из-за:

  • Перегрузки сети: если сеть загружена на 100%, пакеты будут теряться.
  • Ошибок на физическом уровне: плохой кабель, неисправный switch или конфликты на уровне MAC-адресов.
  • Wi-Fi: если ваш сервис работает через Wi-Fi, потери пакетов могут быть связаны с интерференцией, расстоянием или настройками точки доступа.

Инструменты для диагностики:

  1. ifconfig / ip link: проверка статуса интерфейса.

    ip link show eth0

    Если интерфейс в состоянии DOWN или есть ошибки (RX-errors, TX-errors), проблема на физическом уровне.

  2. ethtool: проверка скорости и дуплекса.

    ethtool eth0

    Если скорость и дуплекс не совпадают между switch и сервером (например, один работает на 100Mbps, а другой на 1Gbps), это может привести к потерям пакетов.

  3. tcpdump: анализ трафика на уровне кадра.

    tcpdump -i eth0 -nn -vv 'icmp'  # Проверка ICMP-пакетов (ping)
tcpdump -i eth0 -nn -vv 'tcp port 80'  # Проверка HTTP-трафика

Практика: как настроить TCP/IP правильно

1. Настройка TCP-соединений для высоконагруженных систем

Если ваш сервис работает с высокой нагрузкой (например, API с тысячами запросов в секунду), настройки по умолчанию могут не сработать. Вот что нужно сделать:

Оптимизация буферов TCP

По умолчанию размер буферов TCP в Linux ограничен. Для высоконагруженных систем увеличьте их:

# Увеличиваем размеры буферов отправки и приёма
echo "net.ipv4.tcp_rmem=4096 87380 16777216" >> /etc/sysctl.conf
echo "net.ipv4.tcp_wmem=4096 65536 16777216" >> /etc/sysctl.conf
echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
echo "net.core.wmem_max=16777216" >> /etc/sysctl.conf
sysctl -p

Почему это работает:

  • Увеличение tcp_rmem и tcp_wmem позволяет TCP отправлять и принимать большие пакеты, что уменьшает количество сегментов и улучшает производительность.
  • rmem_max и wmem_max — максимальные размеры буферов на уровне ядра.

Настройка SYN-queue для защиты от DoS

Если ваш сервис подвержен атакам типа SYN-flood, настройте очередь SYN-пакетов:

echo "net.ipv4.tcp_max_syn_backlog=8192" >> /etc/sysctl.conf
echo "net.ipv4.tcp_synack_retries=5" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf  # Включает защиту от SYN-flood
sysctl -p

Почему это важно:

  • tcp_max_syn_backlog — количество ожидающих SYN-пакетов в очереди.
  • tcp_syncookies — защита от SYN-flood, которая позволяет серверу отвечать на SYN-пакеты без создания полного соединения.

2. Проверка и настройка маршрутизации

Если трафик не доходит до цели, первым делом проверьте маршруты.

Статические маршруты

Допустим, у вас есть два дата-центра, и трафик между ними должен идти через VPN. Настройте статический маршрут:

# На сервере в дата-центре A
sudo ip route add 10.1.0.0/16 via 192.168.100.2 dev tun0

# Проверка
ip route show

Пример проблемы: Если вы добавили маршрут, но трафик всё равно не идёт, проверьте:

  1. Доступность шлюза (ping 192.168.100.2).
  2. Правильность интерфейса (ip link show tun0).
  3. Правила брандмауэра (iptables -L -n).

Dynamic Routing: OSPF и BGP

Если у вас большая сеть, используйте динамическую маршрутизацию.

Пример конфигурации OSPF на Linux (с помощью bird):

# Установка BIRD (маршрутизатор)
sudo apt install bird2

# Конфигурация /etc/bird/bird.conf
protocol device {
    scan time 10;
}

protocol kernel {
    persist;
    learn;
    hold time 10;
    scan time 10;
}

protocol static {
    route 10.0.0.0/8 via 192.168.1.2;
}

protocol ospf {
    import all;
    export all;
    neighbor 192.168.1.1 as 65001;
    area 0.0.0.0 {
        interface "eth0";
    };
}

# Перезапуск BIRD
sudo systemctl restart bird

Почему это нужно:

  • OSPF автоматически обновляет маршруты при изменении топологии сети.
  • Если маршрутизатор выйдет из строя, OSPF найдёт альтернативный путь.

3. Настройка брандмауэра: iptables и firewalld

Брандмауэр может блокировать трафик, даже если сеть в целом работает.

Проверка правил iptables

# Просмотр текущих правил
sudo iptables -L -n -v

# Проверка правил для конкретного порта (например, 8080)
sudo iptables -L -n | grep 8080

Пример проблемы: Если вы видите правило DROP all, но ожидаете, что трафик будет проходить, добавьте исключение:

sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 8080 -j ACCEPT

Firewalld (modern alternative)

# Разрешить трафик на порт 8080
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Типичные ошибки и как их избежать

1. Неправильные таймауты TCP

Сценарий: Сервер ждёт ответа от клиента слишком долго и сбрасывает соединение, хотя на самом деле проблема в сети (например, высокие задержки).

Признаки:

  • Логи сервера: "Connection timed out" или "Connection reset by peer".
  • netstat -n | grep TIME_WAIT показывает много соединений в состоянии TIME_WAIT.

Решение:

  • Уменьшите tcp_fin_timeout (время ожидания закрытия соединения):
    echo "net.ipv4.tcp_fin_timeout=30" >> /etc/sysctl.conf
  • Увеличьте количество повторных попыток (tcp_retries2):
    echo "net.ipv4.tcp_retries2=15" >> /etc/sysctl.conf
  • Включите повторное использование портов в состоянии TIME_WAIT:
    echo "net.ipv4.tcp_tw_reuse=1" >> /etc/sysctl.conf

2. Конфликт портов

Сценарий: Два сервиса пытаются слушать один и тот же порт (например, оба на 8080), и один из них падает с ошибкой "Address already in use".

Признаки:

  • ss -tulnp | grep 8080 показывает два процесса, слушающих один порт.
  • Логи сервиса: "Bind failed: Address already in use".

Решение:

  1. Найдите процесс, который занимает порт:
    sudo lsof -i :8080
  2. Закройте его или перенастройте сервис на другой порт.

Автоматизация: Используйте скрипт для проверки занятых портов перед запуском сервиса:

#!/bin/bash
PORT=8080
if ss -tulnp | grep -q ":$PORT "; then
    echo "Порт $PORT занят! Проверьте процессы:"
    sudo lsof -i :$PORT
    exit 1
fi
echo "Порт $PORT свободен. Запуск сервиса..."

3. Неправильная маршрутизация

Сценарий: Трафик уходит не по тому пути, или маршрут отсутствует вовсе.

Признаки:

  • traceroute показывает неожиданные hop'ы.
  • ping доходит до шлюза, но не до целевого сервера.
  • Ошибка "Network unreachable".

Решение:

  1. Проверьте таблицу маршрутизации:
    ip route show
  2. Добавьте статический маршрут, если нужно:
    sudo ip route add 10.1.0.0/16 via 192.168.1.2 dev eth0
  3. Проверьте, что шлюз доступен:
    ping 192.168.1.2

Пример сложного случая: Если у вас есть несколько выходов в интернет (например, через разные провайдеров), и трафик должен идти через определённый, используйте политики маршрутизации (policy-based routing):

# Создаём таблицу маршрутизации 100
sudo ip route add default via 192.168.1.2 dev eth0 table 100

# Добавляем правило для трафика на порт 8080
sudo ip rule add fwmark 1 lookup 100

# Настраиваем iptables для добавления метки
sudo iptables -t mangle -A OUTPUT -p tcp --dport 8080 -j MARK --set-mark 1

4. Перегрузка соединений

Сценарий: Сервер не успевает обрабатывать запросы, и TCP начинает сбрасывать соединения.

Признаки:

  • Высокий процент RETRANS (ретрансмиссий) в tcpdump.
  • Логи сервера: "Connection reset by peer" или "Too many open files".
  • netstat -s показывает высокие значения TCPBacklogDrop или TCPSynRetrans.

Решение:

  1. Увеличьте размер очереди SYN-пакетов:
    echo "net.ipv4.tcp_max_syn_backlog=16384" >> /etc/sysctl.conf
  2. Увеличьте количество файлов, которые может открыть процесс:
    echo "fs.file-max=100000" >> /etc/sysctl.conf
echo "* soft nofile 100000" >> /etc/security/limits.conf
echo "* hard nofile 100000" >> /etc/security/limits.conf
  3. Оптимизируйте приложение:
    • Используйте connection pooling (например, PgBouncer для PostgreSQL).
    • Уменьшите время ожидания ответа от клиента.

5. Брандмауэр блокирует трафик

Сценарий: Пакеты доходят до сервера, но брандмауэр их отбрасывает.

Признаки:

  • tcpdump показывает входящие пакеты, но сервис их не видит.
  • Логи брандмауэра (/var/log/syslog или journalctl -u firewalld) содержат записи о блокировке.

Решение:

  1. Проверьте правила брандмауэра:
    sudo iptables -L -n -v
sudo firewall-cmd --list-all
  2. Добавьте исключение для нужного порта:
    sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload
  3. Проверьте, что правила применяются:
    sudo iptables -L -n | grep 8080

Пример отладки: почему соединения обрываются с ошибкой "Connection reset by peer"

Сценарий: Ваш сервис падает с ошибкой "Connection reset by peer" при высокой нагрузке.

Шаг 1: Проверка логи сервера

journalctl -u my-service --no-pager -n 50

Пример лога:

ERROR: Connection reset by peer (104)
ERROR: Too many open files

Шаг 2: Анализ трафика с помощью tcpdump

sudo tcpdump -i eth0 -nn -vv 'tcp port 8080 and (tcp[r:5] & 0x30 == 0x10)' | grep -i "reset"

Что ищем:

  • RST (reset) пакеты — это признак того, что соединение было сброшено.
  • Если видите много RST, проблема может быть в перегрузке или неправильных настройках TCP.

Шаг 3: Проверка состояний соединений

ss -tulnp | grep 8080
netstat -s | grep -i "reset\|backlog"

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

TCPBacklogDrop: 12345
TCPSynRetrans: 5678

Это говорит о том, что сервер не успевает обрабатывать SYN-пакеты.

Шаг 4: Оптимизация TCP и приложения

  1. Увеличьте SYN-queue:
    echo "net.ipv4.tcp_max_syn_backlog=16384" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf
sysctl -p
  2. Ограничьте количество одновременно открытых файлов:
    echo "* soft nofile 65536" >> /etc/security/limits.conf
echo "* hard nofile 65536" >> /etc/security/limits.conf
  3. Оптимизируйте приложение:
    • Добавьте connection pooling.
    • Уменьшите таймауты ожидания ответа от клиента.

Шаг 5: Проверка на перегрузку сети

iftop -i eth0

Если видите, что входящий трафик на порт 8080 составляет 90% от пропускной способности, проблема может быть в перегрузке.

Дополнительные инструменты для отладки TCP/IP

1. Wireshark и TShark

Для глубокого анализа сетевого трафика используйте Wireshark или его консольную версию, TShark:

tshark -i eth0 -f "port 8080" -Y "tcp.flags.reset == 1"

Что искать:

  • RST пакеты — сбросы соединений.
  • ACK без соответствующего SYN — возможные проблемы с состоянием соединения.
  • Дублирующиеся пакеты — возможные проблемы на уровне маршрутизации или физического слоя.

2. ss и netstat

ss — современная замена netstat:

# Просмотр всех TCP-соединений
ss -tulnp

# Просмотр состояний соединений
ss -tulnp | grep ESTAB

# Статистика TCP
ss -s

Полезные флаги:

  • -t — только TCP.
  • -u — только UDP.
  • -l — только слушающие порты.
  • -n — не разрешать имена (быстрее).
  • -p — показать процессы, использующие соединения.

3. iperf3: тестирование пропускной способности

Если подозреваете, что проблема в пропускной способности, используйте iperf3:

# На сервере-приёмнике:
iperf3 -s

# На сервере-отправителе:
iperf3 -c <IP_сервера_приёмника> -t 60 -P 10  # 10 параллельных потоков

Интерпретация результатов:

  • Если Bandwidth низкий, проблема может быть в сети или на сервере.
  • Если есть потери пакетов (Packets lost), проверьте физический уровень или маршрутизацию.

4. curl и telnet: базовые проверки

Перед тем как копаться в настройках TCP/IP, проверьте базовые вещи:

# Проверка соединения с портом
telnet example.com 8080

# Проверка HTTP-запроса
curl -v http://example.com:8080

Что искать:

  • Если telnet подключается, но curl нет, проблема может быть в приложении или HTTP-протоколе.
  • Если и telnet не подключается, проблема на уровне TCP/IP (брандмауэр, маршрутизация, порт не слушается).

TCP/IP в облачных средах: AWS, GCP, Azure

В облачных средах настройка TCP/IP имеет свои особенности.

1. AWS: Security Groups и NACLs

В AWS трафик контролируется Security Groups (на уровне экземпляра) и NACLs (на уровне подсети).

Пример проблемы:

  • Вы настроили Security Group для разрешения трафика на порт 8080, но соединения всё равно сбрасываются.
  • Проверьте NACL для подсети:
    # В консоли AWS: EC2 > Network ACLs
    Убедитесь, что есть правило для разрешения входящего и исходящего трафика на порт 8080.

Настройка Security Group:

  1. Перейдите в EC2 > Security Groups.
  2. Выберите группу, связанную с вашим экземпляром.
  3. Добавьте правило:
    • Тип: Custom TCP
    • Порт: 8080
    • Источник: 0.0.0.0/0 (или ограничьте по IP).

2. GCP: Firewall Rules

В GCP трафик контролируется Firewall Rules:

# Проверка правил брандмауэра
gcloud compute firewall-rules list

Пример настройки:

gcloud compute firewall-rules create allow-8080 \
    --allow=tcp:8080 \
    --source-ranges=0.0.0.0/0 \
    --target-tags=http-server

Привязка к экземпляру:

gcloud compute instances add-tags instance-1 --tags=http-server

3. Azure: Network Security Groups (NSG)

В Azure используются Network Security Groups:

# Проверка правил NSG
az network nsg rule list --resource-group my-resource-group --nsg-name my-nsg

Пример добавления правила:

az network nsg rule create \
    --resource-group my-resource-group \
    --nsg-name my-nsg \
    --name allow-8080 \
    --priority 100 \
    --direction Inbound \
    --protocol Tcp \
    --destination-port-ranges 8080 \
    --access Allow \
    --source-address-prefixes *

Заключение: TCP/IP — это инженерная задача

TCP/IP — это не волшебство, а сложная система, которую нужно правильно настроить и поддерживать. Если вы игнорируете настройки TCP, маршрутизацию, брандмауэры и физический уровень, sooner or later сеть начнёт вас подводить.

Практический чек-лист для стабильной сети:

  1. Проверяйте маршруты: всегда используйте ip route show и traceroute, чтобы убедиться, что трафик идёт по правильному пути.
  2. Настраивайте TCP под нагрузку: оптимизируйте буферы, таймауты и SYN-queue для вашего трафика.
  3. Мониторьте открытые порты: избегайте конфликтов и следите за состоянием соединений (ss -tulnp).
  4. Используйте инструменты отладки: tcpdump, ss, netstat, iperf3 — они помогут быстро найти проблему.
  5. Не забывайте о брандмауэрах: они могут быть причиной проблем, даже если сеть в целом работает.
  6. Тестируйте в условиях нагрузки: используйте iperf3 и симуляцию высокой нагрузки, чтобы выявить слабые места.
  7. Документируйте настройки: если вы меняете параметры TCP или маршрутизацию, фиксируйте изменения, чтобы можно было откатить при необходимости.

Если вы будете следовать этим правилам, ваша сеть будет стабильной, а ваши сервисы — быстрыми и надёжными. А если что-то пойдёт не так, вы сможете быстро найти и устранить проблему, не теряя времени на догадки.

Дополнительные материалы: