Протокол Homa снова пытается потеснить TCP там, где миллисекунда задержки превращается в простой дорогих GPU. Профессор emeritus Stanford Джон Оустерхаут продвигает новый транспортный протокол для дата-центров и ИИ-нагрузок, сообщает The Register. Для русскоязычных команд, которые строят LLM-инфраструктуру, высоконагруженные сервисы или просто платят за GPU-кластеры, это не академическая забава: речь о том, кто управляет трафиком внутри дата-центра и сколько времени железо ждет сеть.
Оустерхаут утверждает, что TCP, несмотря на все заслуги перед интернетом и облаками, плохо подходит для современных дата-центров. Его аргумент простой: TCP проектировался как поток байтов, где получатель видит непрерывную передачу данных, но не понимает, короткое сообщение перед ним или длинное. В ИИ-инфраструктуре это больно: большие передачи весов модели, градиентов, чекпойнтов и KV-кэша все чаще конкурируют с короткими запросами агентов, метаданными, координацией и обращениями к кэшу. Длинный поток может занять канал, а короткая операция, от которой зависит следующий шаг вычисления, застрянет в очереди.
Homa предлагает другой подход. Протокол основан на сообщениях, а не на байтовом потоке. Длина сообщения известна заранее, примерно как в модели RPC, а управление перегрузкой переносится ближе к получателю. Первый пакет сообщает, сколько данных должно прийти, после чего принимающая сторона может планировать отправку последующих пакетов. Короткие сообщения получают приоритет по алгоритму shortest remaining processing time, то есть сначала обслуживаются задачи с наименьшим оставшимся объемом работы. Звучит не так романтично, как «новая эра сетей», зато инженерно понятно.
Цифры, которые приводит Оустерхаут, выглядят бодро. Для коротких сообщений p99-задержка у Homa составляет 92 микросекунды против 1,2 миллисекунды у TCP в сети 100 Гбит/с при загрузке 80%. Это примерно в 13 раз быстрее на хвосте распределения, где обычно и живут самые неприятные инциденты. Для длинных сообщений, по его словам, Homa тоже выигрывает у TCP примерно в два раза. Главная ставка здесь не на среднюю температуру по дата-центру, а на хвостовые задержки: именно они заставляют GPU ждать и портят SLO там, где сервис вроде бы «в среднем» работает нормально.
Важная деталь: Оустерхаут не предлагает выключить TCP рубильником и надеяться на лучшее. По его словам, Homa может работать рядом с TCP. Реализация собирается из исходников на GitHub и ставится как модуль в Linux-ядро на клиентах и серверах, без перезагрузки. Приложения можно переносить постепенно. Более того, Оустерхаут утверждает, что наличие Homa в сети ускоряет и оставшиеся TCP-приложения, потому что часть конкурирующего трафика уходит в более управляемый режим. Это сильный аргумент для инфраструктурных команд: миграция протокола редко проходит под лозунгом «давайте остановим прод».
История у проекта не вчерашняя. Работа над Homa началась как PhD-диссертация Бехнама Монтазери, опубликованная в 2019 году; сейчас он работает staff engineer в Google. Оустерхаут после ухода из преподавания взялся продвигать протокол как личную миссию. Сейчас он готовит документ для стандартизации в IETF и работает над upstream-процессом для Linux kernel. В марте протокол был backport-нут в Red Hat Enterprise Linux 8 и 9.5. Параллельно идут прототипы с крупными компаниями, в том числе с одной организацией из финансового сектора.
Скептики тоже есть, и они не из тех, кого можно отмахнуть словом «ретрограды». Сетевой архитектор Иван Пепельняк еще в 2023 году критиковал Homa и спорил с тем, как Оустерхаут описывает производительность TCP. Его позиция: у Homa есть риск оказаться решением, которое сначала ищет красивую проблему, а уже потом реальную эксплуатационную боль. Это нормальная фаза для любого сетевого протокола: красивые графики задержек должны пережить не только конференционный зал, но и грязную смесь драйверов, сетевых карт, версий ядра, политик безопасности и приложений, которые никто не переписывал со времен первой волны микросервисов.
При этом претензии к TCP давно не маргинальны. В базах данных для обхода сетевого стека используют DPDK. В системах хранения появился NVMe over Fabrics с RDMA, Fibre Channel и TCP как транспортами. В вебе Google продвинул QUIC, который лег в основу HTTP/3 и помог обойти head-of-line blocking в TCP. Высокочастотный трейдинг и многопользовательские игры годами ищут способы выжать задержку ниже. AWS развивал Scalable Reliable Datagram, а сетевые коммутаторы top-of-rack научились активнее помечать раннюю перегрузку и управлять очередями. Homa входит не в пустую комнату, а в длинную очередь кандидатов на роль «TCP, но для конкретной боли».
Для разработчиков и бизнеса главный вывод прагматичный: протокол Homa пока не заменяет TCP в интернете, браузерах и обычных корпоративных сетях. Но для дата-центров с плотными AI-нагрузками он подсвечивает реальный сдвиг: сеть снова становится частью модели производительности, а не скучной прослойкой между сервером и сервером. Если GPU простаивает из-за миллисекунды координации, оптимизация Python-кода или покупка еще одной стойки может оказаться более дорогим способом не решить проблему. Вопрос теперь не в том, «умрет ли TCP», а в том, сколько специализированных транспортов появится рядом с ним, пока ИИ-кластеры учатся не спотыкаться о собственную инфраструктуру; детали проекта и аргументацию Оустерхаута можно сверить у .