Comments 16
Низкая производительность транспортного протокола UDP в наложенных, контейнерных сетях уже длительное время занимает умы разработчиков ядра Linux.
все настолько серьезно? А зачем тогда разрабатывают QUIC?
Лишние прерывания при обработке пакета — ничто по сравнению с просадкой пропускной способности TCP когда на маршруте встречается участок с большим пингом (собственно, Интернет) и участок с большими потерями (Wi-Fi).
Кроме того, не забывайте: QUIC точно так же как и TCP умеет в переменный размер пакетов (точно не знаю, но надеюсь на это).
Google собирает статистику с 80-90% сайтов в интернете. В случае TCP это долгие хэндшейки, и блокировки по SNI. А в случае QUIC пакет туда, 5-6 пакетов обратно и всё.
Обычным компаниям/пользователям QUIC нафиг не нужен.
Есть 2 непересекающихся области: сеть внутри ДЦ, и сеть от серверов до клиентов, через интернет.
В первом случае задержки субмиллисекундные, потенциально есть поддержка ECN, на свитчах мелкие буферы, есть проблема с одновременным приемом большого количества пакетов. В этой части как раз и vxlan, и всякие congestion control алгоритмы типа dctcp и timely.
В куске сети от сервера до клиента все иначе: задержки до единиц секунд, типично - несколько десятков мс, высокий джиттер, есть потери, буфер на железках по сети может быть размером в гигабайты. Тут важно угадывать скорость конкретного соединения, переполнить буферы и получить дроп уже не так просто. на этой части сети рулят CC типа BBR.
В идеале, у вас на сервере должно быть 2 независимых сетевых стека, слишком уж разные требования. По факту так конечно никто не делает, но вот использовать разные congestion протоколы - хорошая идея. Это можно сделать как на уровне софта, так и более хитрыми способами, например на лету определяя класс конкретного соединения и выставлять ему правильный congestion control алгоритм в ebpf программе.
Ну почему никто не делает. Как раз это стандартная практика, насколько я понимаю. На входе для клиентского трафика стоят L7 балансеры, которые оптимизированы как раз на прием трафика для второго случая. Их задача принять и проксировать трафик дальше во внутреннюю сеть ДЦ, где межсервисное взаимодействие может быть каким угодно. Вот и получается. Снаружи делаем QUIC, а внутри можно оставить старый добрый TCP.
L7 хороший пример, но в идеале надо и на самих L7 балансировщиках иметь разные настройки в сторону клиентов и в сторону апстримов. Но, в целом, конкретно там можно пожертвовать производительностью в сторону апстримов, т.к. конкретно в этом случае намного важнее обеспечить качественный канал в сторону клиентов.
Спасибо. Заниматаельно. Особенно в свете инициатив гугла по HTTP 3.0, который также использует UDP. Это значит, что без поддержки GRO в контейнере мы получим обратный эффект при внедрении HTTP 3.0.
Я как-то настраивал сервер WireGuard внутри KVM, так сильно удивился низкой скорости. Настроил так же на голом том же сервере - скорость подскочила в несколько раз. Очень похоже, что как раз влияло то, что описано в статье.
Надо учитывать, что это самое GRO чаще приходится отключать, чем включать, в частности на сетевых интерфейсах с чипами intel с драйвером ixgbe, меньше сбоев если отключить.
с ACK уже так не работают - на каждый пакет не шлют ACK. Как минимум посмотрите Selective acknowledgments, и если вы упоминаете про скользящее окно, то там тоже уже не так работает.
Что у вас было с MTU на стенде, и почему был выбран настолько древний дистрибутив, который уже скоро год как не поддерживается?
Вообще обычно использование протокола UDP преследует цель минимизации латентности, а не максимизации пропускной способности. Поэтому довольно странен такой подход к понятию производительности в данном случае.
Когда TCP быстрее UDP