В прошлый раз мы обсуждали перспективы QUIC, которому пророчат светлое будущее в качестве замены TCP. Сегодня поговорим об относительно нишевом протоколе для дата-центров — играющем роль инструмента для обмена RPC-сообщениями.
Что к чему
Одним из основных протоколов передачи данных до сих пор остается TCP, разработанный в начале 1980-х. Но из-за своей «консервативности» он не учитывает все особенности современных дата-центров, которые используют технологию удаленного вызова процедур — RPC. Такой трафик состоит из множества коротких сообщений, рассылаемых тысячам серверов и коммутаторов, и TCP не всегда подходит для подобной коммуникации. Он требует предварительной установки соединения, повторно запрашивает данные при потере и гарантирует их целостность, что само по себе хорошо, но накладывает издержки на производительность.
Существует несколько механизмов, сокращающих латентность в сетях ЦОД. Это — DCTCP, pFabric, pHost от инженеров из IETF, Стэнфорда и Беркли соответственно. Но одним из последних решений в этой области стал транспортный протокол Homa, разработанный в Массачусетском технологическом институте (MIT).
Как он работает
Сперва клиент отправляет серверу лишь небольшую часть сообщения и метаданные с информацией о его объеме. Приемник с помощью механизма SRPT (Shortest Remaining Processing Time) приоритезирует пакеты — он отдает предпочтение сообщениям с наименьшим оставшимся временем обработки. К слову, аналогичный механизм использует pFabric.
Далее, информация о приоритетах поступает отправителю в виде служебного пакета GRANT (стр.5). Он также содержит инструкции по передаче следующей последовательности байтов (авторы их называют RTT-байтами). Обмен такими пакетами происходит до тех пор, пока все RPC-сообщение не будет передано.
Что думает сообщество
Протокол считают перспективным — он может составить конкуренцию TCP. При работе с Homa клиенту не нужно поддерживать открытое подключение и ждать пакеты ACK, подтверждающие доставку сообщений. Так сокращается число передаваемых пакетов и растет пропускная способность. Что интересно, профессор из Калифорнийского университета в Беркли Джон Оустерхаут уже работает над реализацией Homa в качестве модуля для ядра Linux. Хотя автору еще предстоит решить проблемы, связанных с балансировкой нагрузки и многоядерной обработкой.
В то же время некоторые представители ИТ-сообщества ставят под вопрос практическую применимость протокола. Один из резидентов Hacker News отметил, что Homa во многом дублирует решения QUIC и RDMA. Число компаний, использующих QUIC, продолжает расти, поэтому Homa рискует остаться «на обочине» технологического развития.
Какие еще есть альтернативы
Альтернативой также может служить протокол Qnet — собственный сетевой протокол операционной системы реального времени QNX. Он использует принцип передачи сообщений ОС QNX Neutrino для реализации сети. Тонкостям работы этой технологии посвящена большая статья на Хабре. В целом Qnet можно назвать нишевым решением, но его до сих пор используют в Blackberry.
Что касается самого протокола Homa, то можно сказать, что его перспективы туманны. Неуверенности добавляет тот факт, что в портфолио Джона Оустерхаута, активного члена Homa-комьюнити, уже есть пара решений, которым так и не удалось «взлететь». Например, хранилище типа «ключ-значение» RAMCloud, которое является аналогом Memcached или Redis. Со временем станет понятно, заменит ли Homa протокол TCP в дата-центрах, или повторит сюжет известного комикса xkcd про четырнадцать-пятнадцать конкурирующих стандартов.
О протоколах в корпоративном блоге VAS Experts:
О чем еще мы пишем на Хабре:
Комментарии (6)
Tangeman
28.09.2021 22:58клиенту не нужно поддерживать открытое подключение и ждать пакеты ACK, подтверждающие доставку сообщений
Да, но вместо ACK у нас есть GRANT — другое название но такая же функция. Если взять старый добрый RUDP (который так и не стал RFC но всё же использовался) то будет почти то же самое — соединения не надо поддерживать, а детали можно подкрутить.
lunacyrcus
29.09.2021 01:19Ну, можно сказать что все подобные протоколы так или иначе дублируют принципы заложенные в TCP и его логику, только реализуются либо поверх UDP, либо в очень упоротых случаях еще и UDP заново изобретают (целесообразность чего уже вообще сомнительна).
Как-то интереса ради (и для своих целей) и сам сочинил подобный протокол поверх UDP, так вот вообще нет особого труда в том чтобы превзойти TCP по множеству параметров важным во множестве задач (как вот задержки, логика обработки задержек, или транспортный overhead, или скорость реакции на проблемы соединения, встроенное шифрование, и еще может несколько), то конечно смешно если всерьез говорят мол "мы тут сделали еще 1 клон, он оказался лучше чем TCP" (который реально древний, и в общем-то очень крутой и просто-таки серьезно-научный по своим временам) .
sim31r
12.10.2021 22:40+1Во всех играх практически так делают. TCP весьма громоздкий и задумчивый для динамичных игр.
mikhailian
29.09.2021 01:19Джона Оустерхаута, активного члена Homa-комьюнити
Гыгыгы.... Сказали бы, что это автор Tcl
Dark_Purple
Одним из основных протоколов передачи данных до сих пор остается TCP, разработанный в начале 1980-х. Но из-за своей «консервативности» он не учитывает все особенности современных дата-центров, которые используют технологию удаленного вызова процедур — RPC. Такой трафик состоит из множества коротких сообщений, рассылаемых тысячам серверов и коммутаторов, и TCP не всегда подходит для подобной коммуникации. Он требует предварительной установки соединения, повторно запрашивает данные при потере и гарантирует их целостность, что само по себе хорошо, но накладываетиздержки на производительность.
Как насчет UDP?
fougasse
Ну, для RPC нужна гарантия доставки, вроде как.
Естественно, есть реализации “reliable” UDP и они, действительно, испольется. Либо контроль происходит на более высоких уровнях.
Ну и в UDP отличная от TCP парадигма пакетно-ориентированая против потоково-ориентированой.