Pull to refresh

Comments 16

Низкая производительность транспортного протокола UDP в наложенных, контейнерных сетях уже длительное время занимает умы разработчиков ядра Linux.

все настолько серьезно? А зачем тогда разрабатывают QUIC?

Лишние прерывания при обработке пакета — ничто по сравнению с просадкой пропускной способности TCP когда на маршруте встречается участок с большим пингом (собственно, Интернет) и участок с большими потерями (Wi-Fi).


Кроме того, не забывайте: QUIC точно так же как и TCP умеет в переменный размер пакетов (точно не знаю, но надеюсь на это).

Google собирает статистику с 80-90% сайтов в интернете. В случае TCP это долгие хэндшейки, и блокировки по SNI. А в случае QUIC пакет туда, 5-6 пакетов обратно и всё.

Обычным компаниям/пользователям QUIC нафиг не нужен.

Не нужен, но в том же траефике включается одной опцией. Мелочь а приятно

Замеры уже проводили, как лучше?

Прувы не представлю, но по интуитивным ощущениям сайт 3дньюс, стал шустрее подргужать фремворки на которых вариться, если так можно выразиться. Включил 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, так сильно удивился низкой скорости. Настроил так же на голом том же сервере - скорость подскочила в несколько раз. Очень похоже, что как раз влияло то, что описано в статье.

Может быть virtio забыли настроить? На KVM с virtio сеть вполне быстро работает.

Надо учитывать, что это самое GRO чаще приходится отключать, чем включать, в частности на сетевых интерфейсах с чипами intel с драйвером ixgbe, меньше сбоев если отключить.

с ACK уже так не работают - на каждый пакет не шлют ACK. Как минимум посмотрите Selective acknowledgments, и если вы упоминаете про скользящее окно, то там тоже уже не так работает.

Что у вас было с MTU на стенде, и почему был выбран настолько древний дистрибутив, который уже скоро год как не поддерживается?

На графике нагрузочного тестирования TCP и UDP в docker все выглядит почти одинаково. И, если я не ошибаюсь, единственное что docker просаживает по производительности — это сеть. Если не отключить через --net=host.

Вообще обычно использование протокола UDP преследует цель минимизации латентности, а не максимизации пропускной способности. Поэтому довольно странен такой подход к понятию производительности в данном случае.

Sign up to leave a comment.