По импут лагу ответили ерунду. QUIC используется для UDP т.е. для видеопотока от сервера до пользователя, UDP вообще не гарантирует доставку пакета и не получает подтверждения получения пакета как TCP. BBR - вот эта штука для поиска bottleneck-мест на сети и в 99% случаев это будет оборудование местного провайдера и хрен что с этим сделаешь. WebRTC тоже на оклик никак не повлияет.
TCP сложный и очень, очень старый. В нем лаг - трудноуправляемая штука чисто из-за дизайна протокола, TCP Congestion Control - как раз одна из причин этого. QUIC решает проблемы надежности другим способом, уже не говоря о том, что она не сильно-то здесь и нужна. Можно, например, непрерывно слать состояние джойстика и вообще забить на то, что некоторые пакеты не дошли до сервера.
Но даже на TCP BBR2 хорошо решает проблемы с RTT и пропускной способностью. В штатх Google - ISP, для его клиентов будет очень даже
По импут лагу ответили ерунду. QUIC используется для UDP т.е. для видеопотока от сервера до пользователя, UDP вообще не гарантирует доставку пакета и не получает подтверждения получения пакета как TCP. BBR - вот эта штука для поиска bottleneck-мест на сети и в 99% случаев это будет оборудование местного провайдера и хрен что с этим сделаешь. WebRTC тоже на оклик никак не повлияет.
TCP сложный и очень, очень старый. В нем лаг - трудноуправляемая штука чисто из-за дизайна протокола, TCP Congestion Control - как раз одна из причин этого. QUIC решает проблемы надежности другим способом, уже не говоря о том, что она не сильно-то здесь и нужна. Можно, например, непрерывно слать состояние джойстика и вообще забить на то, что некоторые пакеты не дошли до сервера.
Но даже на TCP BBR2 хорошо решает проблемы с RTT и пропускной способностью. В штатх Google - ISP, для его клиентов будет очень даже