Всё у вас смешалось, кони, люди...Давайте по пунктам:
1) В сетях Ethernet по умолчанию не работает Flow Control
Ну то есть как, он работает... Проблема в том, что он требует:
- Active Queue Management на стороне всех устройств одновременно, не только коммутаторов, но и сетевых карточек.
- Реализацию ETS (IEEE 802.1Qaz) на всей цепочке
- Реализацию PFC (IEEE 802.1Qbb) на всей цепочке
- Реализацию QCN (IEEE 802.1Qau) на всей цепочке
- Алгоритмы Random Early Detection на очередях
И это всё появилось спустя долгие годы проб, ошибок и коллапсов сетей. TCP при этом развивался отдельно и изобретал свой Flow Control на более высоком уровне.
Современный Flow Control и TCP никак не связаны.
2) TCP часто используется не по назначению
TCP - это протокол для потоковой передачи данных сквозь широкополосную сеть с большими задержками. Не всякому приложению нужны потоки, не все готовы мириться с непредсказуемыми задержками. Но его используют повсеместно, потому что в нем есть сравнительно простое и рабочее решению по управлению потоком передачи данных (см п.1, там всё сложно, а старые Pause-фреймы вообще не работали никогда вне LAN).
Вот несколько примеров, когда TCP вреден:
- RTC, обмен данными в реальном времени и постоянные дропы и ретрансмиты TCP - вещи не совместимые
- RPC, удаленный вызов процедур порождает огромное количество соединений в которых служебных данных больше чем полезных. Если нет потока, то TCP мешает и лишний раз грузит ядро ОС глупым разбором заголовков.
Если у вас там потоковая проливка через ESB между базами данных, то да - TCP прекрасное решение.
3) TCP постоянно теряет пакеты, это норма
Проблема в том, что люди почему-то не понимают, что TCP не просто может восстановить потерянные данные в потоке, а то что на самом деле он растит пропускную способность пока не начнутся потери и потом её снижает на основании получения запроса на Retransmit. По умолчанию он так управляет потоком. TCP сейчас использует CUBIC для контролирования пропускной способности и очередную вариацию slow start чтобы начать соединение.
1+2+3: В реальности сейчас у нас есть TCP, который используется как попало, где попало и в общем случае экспоненциально растит скорость потока, пока не начнутся потери, и потом снижает скорость. Вот только если у тебя радио-сеть (с большими потерями), то TCP в ней работает особенно плохо. Он не способен подгадать Transmission Rate. Он считает, что раз потери - значит перегрузка. А бывает так, что потери - проблема с уровнем сигнала.
Есть например такой протокол RTP, который всё это учитывает и который реализован поверх UDP. За управление потоком RTP отвечает протокол RTCP, который в свежих версиях стандарта разрешили даже муксить в один порт. Причем телефония исторически работает через UDP.
То же самое с RoCEv2 (RDMA поверх UDP), которая учитывает все возможные варианты Flow Control из п.1 и дополнительно умеет реализовать собственные, если Flow Control не настроен в Lossless.
C RDMA, была попытка (iWarp) сделать это привычным способом поверх TCP... да сплыла. В Ethernet-сетях победил RoCEv2, работающий поверх UDP. Как бы старательно не пытались настроить iWarp в современных реалиях всё что нужно сделать для снижения задержек и стабилизации его работы - бороться с TCP/IP стеком ОС и оптимизациями всех коммутаторов и роутеров на цепочке соединения. Хуже него только NVMe-over-TCP но это каким нужно быть бараном, чтобы в реальности пробрасывать так диски... Нормальную сетевку, которая всё это умеет можно взять за $100.
Дальше что там было по списку? Игрушки? Игрушки используют P2P-сети поверх UDP и львиную долю стека протоколов SIP, RTP для передачи данных там еще сбоку иногда торчит WebRTC и что-то для обмена данных с сервером через веб-сервисы. Но как я и сказал выше всё RPC в перспективе убежит на QUIC и UDP, потому что TCP - это слишком...
Про QoS и приоритезацию траффика я не понял. Она делается сейчас через Diffserv на уровне IP (L3), за исключением Lossless-сетей с PFC и ручным управлением потоков, там она требуется на коммутационном уровне. Внутри каждого L2-домена для lossless-сети используется приоритеты PCP (802.1p), таков стандарт. Транзитные сети с MPLS приоритезируют через свой MPLS CoS, но это по середине между L2 и L3... Короче, я к тому что ни TCP, ни UDP понятия не имеют о том, что их кто-то там приоритезирует.
И вообще в UDP нет ничего плохого. Там нет сессионности - ну добавьте. Там нет управления потоком - ну добавьте. Собственно QUIC это всё и сделал. Ничего плохого в этом нет.
