Мэтью Болл – Метавселенная.  Создание пространственного интернета (страница 14)

У Netflix есть и другие хитрости. Например, компания получает видеофайлы от нескольких месяцев до нескольких часов до того, как они станут доступны зрителям. Это дает компании возможность провести обширный анализ на основе машинного обучения, который позволяет уменьшить (или "сжать") размер файла, анализируя данные кадра, чтобы определить, какую информацию можно отбросить. В частности, алгоритмы компании будут "наблюдать" за сценой с голубым небом и решать, что, если пропускная способность интернета зрителя внезапно снизится, 500 различных оттенков голубого можно будет сократить до 200, или 50, или 25. Аналитика стримера даже делает это на основе контекста, понимая, что сцены с диалогами могут быть более сжатыми, чем сцены с быстро развивающимся действием. Кроме того, Netflix будет предварительно загружать контент на локальные узлы. Если вы попросите новый эпизод "Stranger Things", он будет находиться всего в нескольких кварталах от вас и, следовательно, будет доставлен сразу же.

Вышеописанные подходы работают только потому, что Netflix - это несинхронный опыт; вы не можете ничего "предварительно сделать" для контента, который производится в прямом эфире. Именно поэтому прямые видеопотоки, например, CNN или Twitch, значительно менее надежны, чем потоки по запросу от Netflix или HBO Max. Но даже у стримеров есть свои хитрости. Например, передача обычно задерживается на две-тридцать секунд, а значит, остается возможность предварительно отправить контент в случае временной перегрузки. Рекламные паузы также могут использоваться как сервером контент-провайдера, так и пользователем для восстановления соединения, если предыдущее оказалось ненадежным. Большинство видео в реальном времени требует только одностороннего непрерывного соединения - например, от сервера CNN к пользователю. Иногда соединение бывает двусторонним, как в случае с чатом Twitch, но при этом передается лишь небольшой объем данных (сам чат), и он не имеет критического значения, поскольку не влияет непосредственно на происходящее в видео (помните, что это, скорее всего, произошло на две-тридцать секунд раньше).

В целом, очень немногие онлайн-проекты требуют высокой пропускной способности, низкой задержки и постоянного подключения, кроме многопользовательских виртуальных миров с визуализацией в реальном времени. Большинству впечатлений достаточно одного или, в крайнем случае, двух из этих элементов. Высокочастотным биржевым трейдерам (и особенно высокочастотным торговым алгоритмам) требуется минимально возможное время доставки, поскольку это может быть разницей между покупкой или продажей ценной бумаги с прибылью или убытком. Однако сами ордера являются простыми и легкими и не требуют постоянного соединения с сервером.

Основным исключением является программное обеспечение для видеоконференций, такое как Zoom, Google Meet или Microsoft Teams, которое позволяет многим людям одновременно получать и отправлять видеофайлы высокого разрешения и участвовать в совместной работе. Однако такой опыт возможен только с помощью программных решений, которые не очень подходят для создания виртуальных миров с большим количеством участников в режиме реального времени.

Вспомните свой последний вызов Zoom. Время от времени несколько пакетов, скорее всего, приходили слишком поздно или, возможно, вообще не приходили, то есть вы не слышали ни слова, ни двух - или, возможно, несколько ваших слов не были услышаны другими участниками разговора. Несмотря на это, скорее всего, вы или ваши слушатели все равно поняли, что было сказано, и разговор мог продолжаться. Возможно, вы временно потеряли, но затем быстро восстановили связь. Zoom может прислать вам пропущенные пакеты, затем ускорить воспроизведение и отредактировать паузы, чтобы "догнать" вас до "прямого эфира". Возможно, вы полностью потеряли соединение - либо из-за проблем в локальной сети, либо из-за проблемы, возникшей между вашей локальной сетью и удаленным сервером Zoom. Если это произошло, вы, скорее всего, возобновили работу, и никто не узнал о вашем уходе, а если и узнал, то вряд ли ваше отсутствие было разрушительным. Это объясняется тем, что видеоконференции - это совместный опыт, сосредоточенный на одном человеке, а не общий опыт, которым руководят многие пользователи, работающие вместе. А если бы вы были докладчиком? Хорошая новость заключается в том, что разговор может продолжаться и без вас: либо подключится другой участник, либо все будут ждать, когда вы присоединитесь. Если в какой-то момент перегрузка сети приведет к тому, что вы или другие участники просто не смогут услышать или увидеть происходящее, Zoom прекратит загрузку или скачивание видео от разных участников звонка, чтобы приоритетнее использовать то, что важнее всего: звук. Или, наоборот, звонок мог прерываться из-за разной задержки - то есть разные участники звонка получали "живое" видео и аудио на четверть, половину или даже целую секунду позже или раньше друг друга, - что приводило к попыткам говорить по очереди и постоянным прерываниям. В конце концов, участники звонка, вероятно, придумали, как с этим справиться. Просто всем нужно немного терпения.

Виртуальные миры предъявляют более высокие требования к производительности и сильнее страдают даже от малейших сбоев, чем любой из этих видов деятельности. Передаются гораздо более сложные наборы данных, и они требуются гораздо чаще и от всех пользователей.

В отличие от видеозвонка, в котором фактически один создатель и несколько зрителей, виртуальный мир, как правило, включает в себя множество общих участников. Соответственно, потеря одного человека (неважно, насколько временная) влияет на весь коллективный опыт. И даже если пользователь не пропадает совсем, а лишь слегка рассинхронизируется с остальными участниками разговора, он полностью теряет способность влиять на виртуальный мир.

Представьте, что вы играете в шутер от первого лица. Если игрок А отстает от игрока Б на 75 миллисекунд, он может выстрелить в место, где, по его мнению, находится игрок Б, но при этом игрок Б и сервер игры знают, что игрок Б уже ушел. Это расхождение означает, что сервер виртуального мира должен решить, чей опыт является "истинным" (то есть должен быть отображен и сохраняться у всех участников), а чей должен быть отвергнут. В большинстве случаев опыт отставшего участника будет отклонен, чтобы другие участники могли продолжить. Метавселенная не может функционировать как параллельная плоскость для человеческого существования, если многие из тех, кто находится в ней, испытывают противоречивые (и затем недействительные) версии.

Вычислительные ограничения, связанные с количеством пользователей в одной симуляции (о которых я расскажу в следующем разделе), часто означают, что если пользователь отключится от данной сессии, он никогда не сможет к ней вернуться. Это нарушает работу не только этого пользователя, но и его друзей, которые должны выйти из виртуального мира, если хотят возобновить игру вместе, или продолжить ее без него или без нее.

Другими словами, задержки и лаги могут расстраивать отдельных пользователей Netflix и Zoom, но в виртуальном мире эти проблемы ставят человека под угрозу виртуальной смерти, а коллектив - в состояние постоянной фрустрации. На момент написания этой статьи только три четверти американских домохозяйств могут стабильно участвовать в большинстве виртуальных миров, работающих в режиме реального времени. На Ближнем Востоке это могут сделать менее четверти домохозяйств.

Это расширенное описание проблемы синхронности очень важно для понимания того, как будет развиваться и расти Метавселенная в ближайшие десятилетия. Хотя многие считают, что Metaverse зависит от инноваций в устройствах, таких как гарнитуры VR, игровые движки (например, Unreal) или платформы вроде Roblox, сетевые возможности будут определять и ограничивать многое из того, что возможно, когда и для кого.

Как мы рассмотрим в последующих главах, простых, недорогих или быстрых решений не существует. Нам понадобится новая кабельная инфраструктура, стандарты беспроводной связи, аппаратное оборудование, а в перспективе даже реконструкция основополагающих элементов набора интернет-протоколов, таких как протокол Border Gateway Protocol.

Большинство людей никогда не слышали о BGP, но этот протокол повсюду вокруг нас, служа своего рода стражем трафика цифровой эры, управляя тем, как и куда передаются данные в различных сетях. Проблема BGP заключается в том, что он был разработан для первоначального использования в Интернете - обмена статичными, асинхронными файлами. Он не знает и тем более не понимает, какие данные он передает (будь то электронное письмо, живая презентация или набор входных данных, предназначенных для уклонения от виртуального огня в виртуальной симуляции с визуализацией в реальном времени), их направление (входящие или исходящие), влияние перегруженности сети и так далее. Вместо этого BGP следует довольно стандартной универсальной методике маршрутизации трафика, которая, по сути, взвешивает кратчайший путь, самый быстрый путь и самый дешевый путь (с общим предпочтением последней переменной). Таким образом, даже если соединение поддерживается, оно может быть неоправданно длинным (латентным) и может быть разорвано, чтобы определить приоритет сетевого трафика, который не нужно доставлять в реальном времени.