Алгоритмы управления TCP-соединениями. Стоит ли менять?

Все эти истории для серверов которые отдают десятки гигабит в тысячи соединений и миллионы пакетов в секунду. Тебе они какого либо ощутимого прироста не дадут.

А про DPDK ничего не говорили?

Прогнал несколько раз
iperf -C cubic
iperf -C reno
ipert -C bbr
между двумя серверами.
Кубик и ббр одинаково, рено примерно на 2% быстрее.
Но, между ними канал без потерь.
Человек в своём блоге написал почему и при каких обстоятельствах у него tcp bbr оказался быстрее чем даже udp. Прочти статью там ещё раз.
Если у тебя аналогичная ситуация с потерями до сервера впн, то может быть тебе поможет, если сделаешь также на краях тоннеля. Но 5Гбит вместо 1Гбит это тебе не сделает. Так что никакой магии.
PS: немного скосоглазил и результаты рено и кубика перепутал.

Некоторые дрепаные конторы типа Инком Пишут свои протоколы тцп. Дабы потом сидеть на шее бюджетных годами организаций кому они продали свое ПО. Но , Кулибыны везде сеть.

подчеркнув, что такой подход с TCP работает быстрее UDP

Попытки сравнивать скорость TCP и UDP то уже признак безграмотности, т.к. протоколы решают совершенно разные задачи.

Речь про тоннель, который можно сделать и поверх tcp и поверх udp.
Тоннель тоже будет решать разные задачи?

Туннель это какие-то общие слова. Очевидно, для туннеля поверх UDP будет использоваться какая-то другая прога (ну или другой алгоритм в рамках той же) чем для туннеля поверх TCP, потому что одинаково их использовать невозможно. Всё зависит от того, какие именно там алгоритмы.

как например чел описал в своём блоге

https://konishchev.ru/posts/tcp-bbr/
Вот тебе источник.

Как это часто со мной бывает, я решил пойти не самым простым, но зато самым любимым мной путём – и написал свой тоннель.

Ну понятно, автор реализовал поверх UDP свой протокол управления ретрансмиссиями и окном приёма, и он оказался хуже чем BBR. UDP vs TCP тут совершенно ни при чём.

Если бы он реализовал поверх UDP тот же BBR - результаты бы наверно совпали. А ещё он мог реализовать более продвинутый протокол, не скованный рамками tcp-соединения, и получил бы ещё более хороший результат, но очевидно он этого не делал.

Ты наковырял из носа каких-то фантазий и ринулся их опровергать.

Я процитировал фразу по твоей ссылке, если что.

Ты зашёл в тему, ткнулся в базворд и начал голосить.
Я тебе дал ссылку, по которой ты дочитал до очередного базворда и опять начал голосить.
Вот поверь, мне IRL поехавших хватает.

Не знаю что за базворды, я написал всё по делу и от своих слов не отказываюсь: 1) писать «TCP быстрее UDP» или наоборот - признак неграмотности, 2) судя по ссылке, автор просто реализовал плохой алгоритм управления каналом, но почему-то приписал это в заслугу TCP+BBR, который оказался лучше. А ты не пойми чем недоволен.