Если вы хотите использовать UDP для производительности по TCP, есть ли что-то, что может действовать как посредник на стороне отправителя и на стороне получателя, где ему подаются пакеты и он отправляет их по UDP, но также обрабатывает исправление ошибок / повторную передачу?
Идея здесь в том, чтобы иметь возможность использовать существующий протокол на основе UDP без необходимости программировать исправление ошибок / повторную передачу на уровне приложения. Например, запустите это промежуточное программное обеспечение на локальной конечной точке и удаленной конечной точке, и традиционное приложение подключается к localhost и порту, который прослушивает это программное обеспечение, а затем оно передается на другой конец.
UDP просто слепо отправляет дейтаграммы. У него нет контроля перегрузки, повторной передачи или концепции потока. Любая реализация этих функций будет эффективно повторять TCP и должна решать те же проблемы. Были бы хоть какие-то накладные расходы.
Существуют другие виды транспорта, кроме TCP или UDP. Например, SCTP. Однако неясно, что у них будет какое-либо преимущество в производительности. Кроме того, поддержка сетевыми и программными стеками не так широко распространена, как TCP.
Было изобретено несколько транспортов по UDP. QUIC очень популярен.
Определите, как вы считаете, что TCP снижает производительность, подробно изучив потоки TCP. TCP зрелый и хорошо изученный. Воспользуйтесь этим опытом и инструментами, чтобы либо оптимизировать его, либо узнать, что вы действительно хотите от своего транспорта.