Бинарный UDP протокол для high-load систем

var msgs [BATCH_SIZE]ipv4.Message
var buffers [BATCH_SIZE][MAX_PACKET_SIZE]byte

for i := range msgs {
    msgs[i].Buffers = [][]byte{buffers[i][:]}
}

// Читаем до 256 пакетов за раз
n, err := p.ReadBatch(msgs[:], 0)

for i := 0; i < n; i++ {
    if msgs[i].N == 0 || msgs[i].N > MAX_PACKET_SIZE {
        continue
    }
    buf := buffers[i][:msgs[i].N]
    addr := msgs[i].Addr.(*net.UDPAddr)
    w.handlePacket(buf, addr)
}Go

Что происходит:

1. Создаём массив из 256 сообщений и буферов по 1400 байт каждый
2. Вызываем ReadBatch — один системный вызов recvmmsg() в Linux
3. Получаем n пакетов (от 1 до 256)
4. Обрабатываем каждый пакет в цикле

При загрузке 100 000 пакетов в секунду и среднем batch size 50, мы делаем всего 2000 системных вызовов в секунду вместо 100 000. Экономия: ~50 ms в секунду только на syscall overhead.

SO_REUSEPORT и масштабирование

По умолчанию один UDP-сокет может обрабатываться только одной горутиной. Для масштабирования на все ядра CPU используется SO_REUSEPORT — опция ядра Linux, позволяющая нескольким сокетам слушать один порт:

func listenUDPReusePort(port int) (*net.UDPConn, error) {
    config := &net.ListenConfig{
        Control: func(network, address string, c syscall.RawConn) error {
            return c.Control(func(fd uintptr) {
                // Разрешаем нескольким сокетам слушать один порт
                _ = syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, 
                    unix.SO_REUSEPORT, 1)
                
                // Увеличиваем буферы чтения/записи до 16 MB
                _ = syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, 
                    syscall.SO_RCVBUF, SOCKET_READ_BUF)
                _ = syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, 
                    syscall.SO_SNDBUF, SOCKET_WRITE_BUF)
            })
        },
    }
    conn, err := config.ListenPacket(context.Background(), 
        "udp", fmt.Sprintf(":%d", port))
    if err != nil {
        return nil, err
    }
    return conn.(*net.UDPConn), nil
}Go

Теперь каждый воркер создаёт свой сокет на том же порту 9093. Ядро Linux автоматически распределяет входящие пакеты между сокетами:

Количество воркеров равно количеству CPU-ядер:

numWorkers := runtime.NumCPU()
var wg sync.WaitGroup
wg.Add(numWorkers)
for i := 0; i < numWorkers; i++ {
    go workerLoop(i, &wg)
}Go

На сервере с 8 ядрами — 8 воркеров, каждый обрабатывает ~12.5% трафика. Никакой координации между воркерами не требуется — ядро само балансирует нагрузку.

Архитектура воркера

Каждый воркер — независимая горутина со своим сокетом и пулом буферов:

type Worker struct {
    id              int
    arena           [2][]byte       // Двойной буфер для аллокаций
    active          int             // 0 или 1
    off             [2]int          // Смещения в буферах
    udpConn         *net.UDPConn    // Свой сокет
    msgBuf          [128]byte       // Временный буфер
    verifyBuf       [256]byte       // Буфер для верификации
    transferMsgBuf  [256]byte       // Буфер для транзакций
    base64DecodeBuf [64]byte        // Буфер для base64
    errBuf          [64]byte        // Буфер для ошибок
}Go

Обратите внимание: все буферы предвыделены в структуре воркера. Никаких аллокаций в runtime. Метод alloc() использует двойной буфер arena[2] для временных данных:

//go:nosplit
func (w *Worker) alloc(n int) []byte {
    if n <= 0 || n > MAX_PACKET_SIZE {
        return nil
    }
    if w.off[w.active]+n > len(w.arena[w.active]) {
        w.active = 1 - w.active  // Переключаемся на другой буфер
        w.off[w.active] = 0
    }
    if n > len(w.arena[w.active]) {
        return nil
    }
    buf := w.arena[w.active][w.off[w.active] : w.off[w.active]+n]
    w.off[w.active] += n
    return buf
}Go

Это bump-allocator: просто двигаем указатель вперёд. Когда буфер заканчивается — переключаемся на второй. После обработки пакета оба буфера сбрасываются.

Диспетчеризация пакетов

Функция handlePacket определяет тип пакета по размеру и первым байтам:

func (w *Worker) handlePacket(buf []byte, addr *net.UDPAddr) {
    // Снапшот: начинается с "SNAP"
    if bytes.Equal(buf[0:4], []byte(SNAPSHOT_MAGIC)) {
        w.handleSnapshot(buf, addr)
        return
    }
    
    // Команды: 53 байта (cmd + peerID + sig)
    if len(buf) == 53 {
        cmdType := buf[0]
        if cmdType == 0x01 || cmdType == 0x02 {
            w.handleCommandWithSig(buf, addr)
            return
        }
    }
    
    // Транзакция: 89 байт
    if len(buf) == 89 && buf[0] == 0x03 {
        w.handleTransfer(buf, addr)
        return
    }
    
    // Неизвестный пакет — игнорируем
}Go

Диспетчеризация занимает ~5 ns — просто проверка длины и первых байт. Никакого парсинга JSON, никакой валидации схемы.

Бенчмарки и цифры

Реальные цифры обработки пакетов на Intel Core i7-4790:

Обработка пакета (handlePacket):
  - Диспетчеризация:     ~5 ns
  - Чтение баланса:      ~0.35 ns
  - Верификация подписи: ~100 ns (BLAKE3)
  - Запись ответа:       ~50 ns
  
Итого на пакет: ~155 ns
Пропускная способность: ~6.5M пакетов/сек на ядроОценка

Сравним с типичным HTTP/JSON API:

Разница: 25-50 раз быстрее. И это без учёта того, что HTTP создаёт аллокации (GC нагрузка), а UDP-обработка в MEMORIA — zero-allocation.

Компромиссы UDP

UDP не идеален. Вот какие проблемы приходится решать на уровне приложения:

1. Потеря пакетов

UDP не гарантирует доставку. Если пакет потерялся — клиент не получит ответ. Решение: таймаут и повтор. Клиент ждёт ответ 100 ms, если не получил — повторяет запрос.

2. Дубликаты пакетов

Повторные запросы могут привести к двойным транзакциям. Решение: ReqID cache (разбирали в предыдущей статье). Каждый запрос имеет уникальный 8-байтовый ID, который запоминается на 10 секунд.

3. Порядок пакетов

UDP не гарантирует порядок доставки. Решение: timestamp в каждой транзакции. Если приходит транзакция с более старым timestamp, чем последняя обработанная — она игнорируется.

4. Размер пакета

Максимальный размер UDP-пакета — 65 535 байт, но на практике MTU Ethernet = 1500 байт. С заголовками IP (20) + UDP (8) остаётся 1472 байта полезной нагрузки. MEMORIA использует лимит 1400 байт для запаса.

5. DDoS-атаки

UDP легко спуфить — отправитель может подделать IP-адрес. Решение: IP rate limiter (64 шарда, 10 запросов в секунду на IP) + криптографические подписи. Даже если злоумышленник отправит миллион пакетов, без валидной подписи они будут отброшены.

В следующей статье мы разберём, как BLAKE3 используется для подписей снапшотов и почему он быстрее SHA-256.