TCP_USER_TIMEOUT: как одна опция стека устранила даунтайм СтримМедиа

При параметре net.ipv4.tcp_retries2 = 15 (значение по умолчанию в Linux) ядро выполняет 15 попыток ретрансмиссии с экспоненциально растущими интервалами:

# Интервалы ретрансмиссии (приблизительно):
# Попытка 1:  0.2 с  (RTT-based)
# Попытка 2:  0.4 с
# Попытка 3:  0.8 с
# Попытка 4:  1.6 с
# Попытка 5:  3.2 с
# Попытка 6:  6.4 с
# Попытка 7:  12.8 с
# Попытка 8:  25.6 с
# Попытка 9:  51.2 с
# Попытка 10: 102.4 с
# ... и так далее до попытки 15
# Суммарное время ожидания: ~15 минут

Это означает, что при отказе удалённого узла приложение будет ждать до 15 минут, прежде чем TCP-стек закроет соединение с ошибкой ETIMEDOUT. Всё это время воркер заблокирован.

В Kubernetes ситуация дополнительно усложнялась поведением iptables и conntrack. При отказе узла conntrack-таблица очищалась, и ядро начинало отбрасывать пакеты с состоянием «invalid». Это блокировало даже RST-пакеты, которые в нормальных условиях мгновенно закрыли бы соединение:

# Проверка conntrack rules на узле:
iptables -L -v -n | grep -i invalid
# Chain KUBE-FORWARD
# DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  ctstate INVALID

Таким образом, даже после перезапуска упавшего узла, он не мог отправить RST на уже установленные соединения.

Для gRPC-сервисов СтримМедиа (написаны на Go) мы реализовали установку TCP_USER_TIMEOUT через syscall:

package tcputil

import (
    "fmt"
    "net"
    "syscall"
    "time"

    "golang.org/x/sys/unix"
)

// SetTCPUserTimeout устанавливает максимальное время ожидания
// подтверждения отправленных данных перед закрытием соединения.
func SetTCPUserTimeout(conn net.Conn, timeout time.Duration) error {
    tcpconn, ok := conn.(*net.TCPConn)
    if !ok {
        return fmt.Errorf("not a TCP connection")
    }
    rawConn, err := tcpconn.SyscallConn()
    if err != nil {
        return fmt.Errorf("error getting raw connection: %v", err)
    }
    var setsockoptErr error
    err = rawConn.Control(func(fd uintptr) {
        setsockoptErr = syscall.SetsockoptInt(
            int(fd),
            syscall.IPPROTO_TCP,
            unix.TCP_USER_TIMEOUT,
            int(timeout/time.Millisecond),
        )
    })
    if err != nil {
        return err
    }
    return setsockoptErr
}

// Использование с gRPC:
// conn, _ := grpc.Dial(addr, grpc.WithKeepaliveParams(...))
// SetTCPUserTimeout(conn, 30*time.Second)

Для сервисов за Envoy proxy (используемого в их Service Mesh) мы настроили TCP_USER_TIMEOUT через socket options в конфигурации кластера:

# Envoy cluster configuration с TCP_USER_TIMEOUT
clusters:
  - name: upstream_service
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    upstream_connection_options:
      tcp_keepalive:
        keepalive_probes: 3
        keepalive_time: 10
        keepalive_interval: 5
    transport_socket_matches:
      - name: tcp_user_timeout
        transport_socket:
          name: raw_buffer
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.raw_buffer.v3.RawBuffer
    # Socket option: TCP_USER_TIMEOUT = 30000ms
    # Опция 18 (TCP_USER_TIMEOUT) на уровне IPPROTO_TCP (6)

Для Linkerd поддержка TCP_USER_TIMEOUT была добавлена в edge-24.10.1 через PR #13024 и #3174.

Как дополнительный уровень защиты мы уменьшили tcp_retries2 на всех узлах кластера:

# Уменьшение максимального числа ретрансмиссий (системно)
# Было: 15 (~15 минут ожидания)
# Стало: 7 (~25 секунд ожидания)
sysctl -w net.ipv4.tcp_retries2=7

# Для сохранения после перезагрузки:
echo "net.ipv4.tcp_retries2 = 7" >> /etc/sysctl.d/99-tcp-tuning.conf
sysctl -p /etc/sysctl.d/99-tcp-tuning.conf

Важное ограничение: sysctl применяется глобально — ко всем TCP-соединениям на узле. Для внутрикластерного трафика 7 ретрансмиссий — оптимально, но для внешних соединений через нестабильные каналы может быть слишком агрессивно. Поэтому мы рекомендуем комбинировать sysctl с per-socket TCP_USER_TIMEOUT.

На тестовом кластере из 4 узлов воспроизвели сценарий инцидента:

# Имитация аппаратного сбоя (kill -9 без graceful shutdown)
# На узле с сервисом A:
iptables -A OUTPUT -p tcp --sport 8443 -j DROP
iptables -A INPUT -p tcp --dport 8443 -j DROP

# Наблюдаем за клиентами сервиса A:
# Без TCP_USER_TIMEOUT: зависание 924 секунд (15.4 минуты)
# С TCP_USER_TIMEOUT=30s: ошибка через 31 секунду, переподключение к здоровой реплике

Развернули изменения на production-кластере по группам:

1. Неделя 1: некритичные сервисы (логирование, аналитика) — 12 инстансов
2. Неделя 2: бэкенд-сервисы (каталог, рекомендации) — 24 инстанса
3. Неделя 3: критичные сервисы (транскодирование, стриминг) — 14 инстансов

После полного rollout мы провели серию контролируемых экспериментов с отказами узлов. Результат: каскадного отказа не происходит. Сервисы переключаются на здоровые реплики за 30-35 секунд, деградация заметна только для запросов, «застрявших» в момент отказа.