Почему UDP-пересылка превосходит WebSocket и gRPC для доставки шредов

При получении шредов Solana в реальном времени транспортный протокол напрямую влияет на задержку. Многие провайдеры инфраструктуры предлагают данные шредов через WebSocket или gRPC — это кажется удобным, но вносит существенные накладные расходы. Оба протокола работают поверх TCP, а значит наследуют затраты на установку соединения, задержки управления перегрузкой и, что критичнее всего, блокировку очереди при потере пакетов. Один потерянный пакет останавливает весь поток до завершения повторной передачи. Для непрерывного потока чувствительных ко времени данных, таких как шреды, это поведение разрушительно для производительности.

Чтобы понять, почему блокировка очереди так проблематична, рассмотрим ситуацию при пакетной доставке шредов. Лидер производит десятки шредов за слот, и они поступают на вашу инфраструктуру в быстрой последовательности. При использовании TCP-протоколов, таких как WebSocket или gRPC, пакеты доставляются в строгой последовательности. Если пакет №47 потерян из-за сетевого джиттера, пакеты с 48 по 100 должны ждать в буфере до повторной передачи и получения пакета №47. Ваше приложение не видит ничего во время этой паузы — хотя пакеты 48-100 уже прибыли на ваш сетевой интерфейс. Весь поток замирает на время одного цикла повторной передачи, обычно 1-10ms в зависимости от сетевых условий.

UDP устраняет все эти проблемы. Нет рукопожатия, нет цикла подтверждений, нет гарантий порядка, способных вызвать задержки. Каждый шред приходит как независимая датаграмма. Если один пакет потерян, остальные продолжают поступать без прерывания. Это полностью соответствует тому, как Turbine в Solana распространяет шреды по сети валидаторов — независимыми UDP-пакетами с использованием кодов стирания для избыточности. Пересылая шреды по UDP, мы сохраняем те же семантики доставки, которые использует сама Solana, не добавляя искусственных узких мест.

Встроенное в формат шредов Solana кодирование стирания обеспечивает естественное решение для потери пакетов. Шреды каждого блока включают как шреды данных, так и шреды кодирования (чётности). Даже при потере некоторых UDP-пакетов, кодирование стирания Reed-Solomon позволяет восстановить полный блок из подмножества шредов. Это значит, что отсутствие гарантированной доставки в UDP на практике не является проблемой — прикладной уровень уже обрабатывает избыточность. Механизм повторной передачи TCP в этом контексте избыточен и вреден, добавляя задержку без улучшения надёжности.

WebSocket и gRPC также добавляют накладные расходы на сериализацию и фреймирование, которых UDP избегает. Фрейм WebSocket включает заголовок с опкодом, ключом маскирования и полями длины. gRPC добавляет фреймирование HTTP/2, состояние сжатия заголовков и сериализацию Protocol Buffer. Эти слои добавляют время обработки как на стороне отправителя, так и получателя. При использовании сырого UDP данные шреда — это и есть полезная нагрузка. Никакой обёртки, никакой сериализации, никакого фреймирования. Ваше приложение считывает пакет и немедленно получает байты шреда, готовые к обработке.

GetShreds пересылает шреды по сырому UDP в Jito-совместимом формате, что позволяет вашему валидатору или пайплайну обрабатывать их без дополнительного слоя десериализации. Наши тесты стабильно показывают дополнительные 5-15ms задержки при использовании WebSocket или gRPC по сравнению с прямой UDP-доставкой. Для MEV-стратегий, где на счету каждая миллисекунда, эта разница определяет, поймаете вы возможность или упустите. Мы измерили это, запустив идентичные пайплайны обработки шредов параллельно — один потребляющий из WebSocket-потока, другой из нашего UDP-фида — на одном оборудовании в одном дата-центре.

Управление соединениями — ещё одно практическое преимущество UDP. WebSocket и gRPC соединения могут обрываться из-за таймаутов простоя, перезагрузок серверов, реконфигурации балансировщиков нагрузки или изменений сетевых путей. При обрыве соединения ваш клиент должен обнаружить сбой, переподключиться и, возможно, повторно аутентифицироваться, прежде чем данные снова потекут. Это окно переподключения может длиться секунды, в течение которых вы полностью пропускаете шреды. У UDP нет соединения, которое может оборваться — пакеты просто приходят на ваш порт. Если наш edge-нод перезагрузится, ваше приложение испытает кратковременный разрыв в данных, но немедленно возобновит приём при возобновлении пакетов, без какой-либо логики переподключения.

Мы используем bare-metal серверы во Франкфурте и Амстердаме, каждый из которых подключён напрямую к Turbine и пересылает шреды по UDP с субмиллисекундным временем обработки. Без KYC, без кредитных карт — просто оплатите в SOL и начните получать шреды за считанные минуты. Наша инфраструктура специально построена для пересылки шредов, с оптимизациями обработки пакетов на уровне ядра и прямыми сетевыми путями к основным кластерам валидаторов Solana.