> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите
> что надо все в юзерспейс. А сейчас (и ещё помню новость
> про FUSE) уже ярые противники этого подхода.

Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про "икание" звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки.

Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.