Популярным инструментом проброски пакетов был IPVS. Он выполнял задачи балансировки через тоннель и Direct Routing.
В первом случае, для каждого соединения устанавливался TCP-канал и пакет от пользователя шел на балансер, потом на миньон, а потом в обратном порядке.
Вот тут не совсем честно. У IPVS есть 3 метода доставки трафика до обслуживающих нод:
Gatewaying, он же Direct Routing — пересылка пакетов в пределах одного броадкаст сегмента.
Tunneling — туннелирование, работает в маршрутизируемых сетях, инкапсулирует пакеты в IPv4/IPv6.
Masquerading — классический DNAT.
Так вот обратный трафик идет через балансер только в случае Masquerading. В остальных двух случаях настройки на облуживающих нодах позволяют возвращать трафик клиенту без задействования балансировщика.
Да, точно. Но тут сравнение с Gnu TLS c малым размером TLS Record, который умещается в один TCP пакет. Такое поведение не самое распространенное, и не позволяет использовать механизмы GSO и TSO в ядре. Ну и версия kTLS там правда очень древняя. Была еще статья, в которой сравнивался OpenSSL (кажется 1.1.0) в более честных условиях, там были изменения в обратную сторону, но незначительные
и да, в той статье есть таблица, где у kTLS без аппаратного ускорения производительность оказалась ниже, чем в userspace (это я возвращаюсь к вопросу «будет ли выигрыш если исходные данные в userspace»)
Это одна из первых статей, после этого в ядре было несколько итераций оптимизации кода AES. Но я не берусь утверждать, что стало сильно лучше, вероятнее всего при проксировании действительно профита видно не будет
имелось в виду не «будет ли работать», а «будет ли профит в случае множества относительно медленных клиентов», очевидно, что хранить состояние всех сессий в сетевой карте невозможно, не убьёт ли производительность то, что контекст придётся постоянно передавать в сетевую карту/из сетевой (что-то вроде context switch в OS).
Конкретно у Mellanox в их Crypto-enabled BlueField воткнут «64-bit Armv8 A72» на 16 ядер и 16GB оперативки. Всё это с отдельным интерконнектом в собственно сетевой чип, поэтому вполне можно держать все сессии. Быстро перепрограммировать сетевой чип из BlueField точно умеют, а про передавать контекст в карту/из карты — это в общем случае надо делать только на старте сессии. Карта умеет трекать TCP Seq Number, и TLS Record Number. Соответственно от ядра нужно только получать данные на отправку.
Тут, кстати, нашел доку по картам Chelsio. У них указывается «The typical T6 adapter supports 32K simultaneous TLS/SSLsessions.» — вполне неплохая цифра одновременных TLS соединений.
в случае «nginx проксирует и обеспечивает tls» выигрыша, думаю, ждать не стоит.
По первым тестам использование шифрования в ядре без использования sendfile() давало несколько процентов производительности, но сейчас подтвердить или опровергнуть эти данные не могу — не получается быстро найти статью с картинками сравнения.
А можно ссылочку на статью, где производительность Kernel TLS просела относительно user-space?
Теоретически, выгоду могут получить любые проекты, использующие TLS. вот сразу в голову пришло — тот же Postfix MTA, всё пересылку ведет через файлы, умеет использовать sendfile, но в режиме TLS такое не поддерживает.
Но меня больше интересуют проекты, в которых уже была реализована поддержка. Правда, я больше искал в направлении WEB-серверов, возможно проекты в других направлениях используют.
Выгода действительно в том, чтобы избавиться от копирования при отдаче статичного контента. В основном это раздача on-line видео. В этой заметке Netfilx довольно глубоко описывают профит.
Использование аппаратного шифрования в сетевой карте — это достаточно новая тема. Mellanox предлагает такое только в своих ConnectX-6 DX, которые имеют интерфейсы 2х100 Gbit или 1х200 Gbit. На таких скоростях даже «дешевое» шифрование с использованием AES-NI будет потреблять значительную количество CPU, которое можно было бы использовать в более нужных вещах. Насколько оно хорошо работает — это, конечно, вопрос. Но не думаю, что в этом проблема будет, потому что офлоадить IPSec с множеством соединений научились еще в Intel 82599, а шифрование потока в TLS не сильно отличается.
Вот тут не совсем честно. У IPVS есть 3 метода доставки трафика до обслуживающих нод:
Так вот обратный трафик идет через балансер только в случае Masquerading. В остальных двух случаях настройки на облуживающих нодах позволяют возвращать трафик клиенту без задействования балансировщика.
Да, точно. Но тут сравнение с Gnu TLS c малым размером TLS Record, который умещается в один TCP пакет. Такое поведение не самое распространенное, и не позволяет использовать механизмы GSO и TSO в ядре. Ну и версия kTLS там правда очень древняя. Была еще статья, в которой сравнивался OpenSSL (кажется 1.1.0) в более честных условиях, там были изменения в обратную сторону, но незначительные
Это одна из первых статей, после этого в ядре было несколько итераций оптимизации кода AES. Но я не берусь утверждать, что стало сильно лучше, вероятнее всего при проксировании действительно профита видно не будет
Конкретно у Mellanox в их Crypto-enabled BlueField воткнут «64-bit Armv8 A72» на 16 ядер и 16GB оперативки. Всё это с отдельным интерконнектом в собственно сетевой чип, поэтому вполне можно держать все сессии. Быстро перепрограммировать сетевой чип из BlueField точно умеют, а про передавать контекст в карту/из карты — это в общем случае надо делать только на старте сессии. Карта умеет трекать TCP Seq Number, и TLS Record Number. Соответственно от ядра нужно только получать данные на отправку.
Тут, кстати, нашел доку по картам Chelsio. У них указывается «The typical T6 adapter supports 32K simultaneous TLS/SSLsessions.» — вполне неплохая цифра одновременных TLS соединений.
По первым тестам использование шифрования в ядре без использования sendfile() давало несколько процентов производительности, но сейчас подтвердить или опровергнуть эти данные не могу — не получается быстро найти статью с картинками сравнения.
А можно ссылочку на статью, где производительность Kernel TLS просела относительно user-space?
Но меня больше интересуют проекты, в которых уже была реализована поддержка. Правда, я больше искал в направлении WEB-серверов, возможно проекты в других направлениях используют.
Использование аппаратного шифрования в сетевой карте — это достаточно новая тема. Mellanox предлагает такое только в своих ConnectX-6 DX, которые имеют интерфейсы 2х100 Gbit или 1х200 Gbit. На таких скоростях даже «дешевое» шифрование с использованием AES-NI будет потреблять значительную количество CPU, которое можно было бы использовать в более нужных вещах. Насколько оно хорошо работает — это, конечно, вопрос. Но не думаю, что в этом проблема будет, потому что офлоадить IPSec с множеством соединений научились еще в Intel 82599, а шифрование потока в TLS не сильно отличается.