1. Та же проблема
2. Согласование контента
3. переадресовывать
4. Адаптивный дизайн
5. Проблема с традиционными решениями
6. Разделенный браузер
7. Облачный браузер

Очень похожая концепция с облачным браузером называется разделенным браузером. Эта статья объяснит различия между ними.

Та же проблема

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

Согласование контента

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

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

переадресовывать

Перенаправление очень похоже на согласование содержимого, но вместо предоставления правильного представления для того же ресурса, оно перенаправит браузер на другой ресурс.

Адаптивный дизайн

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

Проблема с традиционными решениями

Хотя это будет работать, если браузер способен обрабатывать представление, есть много случаев, когда это не так. Наиболее очевидным примером является поставщик контента, который просто не заботится о различных устройствах и обслуживает, например, настольное приложение для мобильного устройства. Чтобы обойти эту проблему, некоторые компании предлагают трансформирующий прокси (он же Split Browser).

Разделенный браузер

Есть много компаний, предлагающих это решение, примеры Опера мини / Turbo , Амазонский шелк , Google Data Saver а также Nokia Xpress , Следующая диаграмма последовательности показывает поток. Обратите внимание, что в этой последовательности используется протокол http, но это не обязательно (например, Google Saver Data Saver использует SPDY ). Даже ответ не должен быть веб-контентом (например, Opera Mini использует OBML ). W3C опубликовал заметку рабочей группы о том, как трансформирующие прокси должен действовать. Например, он должен предоставлять префикс x-device для каждого исходного заголовка HTTP Accept. Кроме того, прокси должен предоставить HTTP-заголовок через браузер.

Обратите внимание, что в этом решении клиент является частью Интернета, как он мог бы разыменовать URI , Разделенный браузер может частично преобразовывать контент для лучшего взаимодействия с пользователем, но взаимодействие происходит от пользовательского агента клиента. Типичным примером является то, что макет рестайлинг для размещения на маленьком дисплее.

Облачный браузер

Хотя приведенные выше решения обеспечивают наилучшее представление, у них есть один недостаток. Пользовательский опыт всегда ограничен возможностями клиента. Несмотря на то, что разделенный браузер может оптимизировать содержимое, необходимое клиенту для обработки содержимого. Облачный браузер обойдет эту проблему, прекратив все на сервере. По идее, браузер существует в облаке. Инициатор (клиент) только инициирует события, но не несет ответственности ни за ресурсы, ни за представление. Это может обеспечить идентификатор но не имеет отношения к ресурсу (например, id dashboard123 может указывать на совершенно разные ресурсы в Cloud Browser от разных поставщиков). Вы можете сравнить его с удаленным дисплеем (хотя на самом деле это больше, чем дисплей). От облачного браузера до исходного сервера он действует так же, как обычный браузер. Можно даже использовать любой из ранее упомянутых методов, таких как согласование контента. Вот упрощенная диаграмма последовательности:

Это означает, что практически любой клиент может предоставить браузер без ограничений ни для клиентских возможностей, ни для инфраструктуры. Характеристики клиента менее актуальны в решении Cloud Browser для исходного сервера, поскольку решение Cloud Browser гарантирует, что наилучшее представление будет предоставлено клиенту. Кроме того, архитектура Cloud Browser немного отличается. Например, навигация может осуществляться с помощью отдельного устройства (например, смартфона) и регулярно отображаться в облачном браузере. DOM события нажатия клавиш. Поскольку клиент абстрагируется, а облачный браузер использует вместо него виртуальное устройство, у этого решения есть некоторые проблемы. Примером является метрика QoE. Традиционно вы будете рассчитывать метрики против клиента, где в решении Cloud Browser это не имеет смысла, поскольку Cloud Browser улучшит работу (например, включит плавную анимацию на устройстве с ограниченными ресурсами). Очевидно, что это не проблема, так как вы получите правильные метрики от виртуального устройства, однако есть случаи, когда это менее понятно. Допустим, веб-приложение рассчитало доступную пропускную способность (которая является пропускной способностью между CDN и облачным браузером) и на основе этой пропускной способности обеспечивает наилучшее соответствие видеоданных. Это не будет работать, если пропускная способность между облачным обозревателем и клиентом облачного обозревателя не будет одинаковой. Это вероятно или больше или меньше. Есть много способов обойти эту проблему, которую обсуждает Целевая группа.

Похожие

Комментарии