Веб-сокеты, веб-воркеры, сервис-воркеры… эти термины вы, возможно, читали или слышали. Может быть, не все из них, но, вероятно, по крайней мере один из них. И даже если вы хорошо разбираетесь во фронтенд-разработке, есть большая вероятность, что вам нужно посмотреть, что они означают. Или, может быть, вы похожи на меня и время от времени смешиваете их. Все термины выглядят и звучат ужасно похоже, и их действительно легко запутать.
Итак, давайте разберем их вместе и выделим веб-сокеты, веб-воркеры и сервис-воркеры. Не в будничном смысле, когда мы глубоко погружаемся и получаем практический опыт с каждым — больше как маленький помощник, чтобы добавить в закладки в следующий раз. I вам нужно освежить.
Краткая справка
Мы начнем с общего обзора для быстрого сравнения и противопоставления.
| Особенность | Что это |
|---|---|
| Веб-сокет | Устанавливает открытое и постоянное двустороннее соединение между браузером и сервером для отправки и получения сообщений по одному соединению, инициированному событиями. |
| Веб-воркер | Позволяет запускать сценарии в фоновом режиме в отдельных потоках, чтобы предотвратить блокировку сценариев друг другом в основном потоке. |
| Сервис работник | Тип Web Worker, создающий фоновую службу, выполняющую промежуточную функцию для обработки сетевых запросов между браузером и сервером даже в офлайн-ситуациях. |
Веб-сокеты
Веб-сокет — это протокол двусторонней связи. Думайте об этом как о продолжающемся звонке между вами и вашим другом, который не прекратится, пока один из вас не решит повесить трубку. Единственная разница в том, что вы являетесь браузером, а ваш друг — сервером. Клиент отправляет запрос на сервер, а сервер отвечает, обрабатывая запрос клиента и наоборот.
Коммуникация основана на событиях. А WebSocket объект устанавливается и подключается к серверу, а сообщения между сервером инициируют события, которые отправляют и получают их.
Это означает, что при установлении начального соединения у нас есть взаимодействие клиент-сервер, при котором соединение инициируется и поддерживается до тех пор, пока клиент или сервер не решат разорвать его, отправив сообщение CloseEvent. Это делает веб-сокеты идеальными для приложений, которым требуется непрерывная и прямая связь между клиентом и сервером. Большинство определений, которые я видел, вызывают приложения чата в качестве общего варианта использования — вы вводите сообщение, отправляете его на сервер, запускаете событие, и сервер отвечает данными без необходимости снова и снова пинговать сервер.
Рассмотрим этот сценарий: вы собираетесь уходить и решили включить Google Maps. Вы, вероятно, уже знаете, как работают Google Maps, но если вы этого не знаете, оно автоматически определяет ваше местоположение после подключения к приложению и отслеживает его, куда бы вы ни пошли. Он использует передачу данных в режиме реального времени, чтобы отслеживать ваше местоположение, пока это соединение активно. Это веб-сокет, устанавливающий постоянный двусторонний диалог между браузером и сервером, чтобы поддерживать эти данные в актуальном состоянии. Спортивное приложение с результатами в реальном времени также может использовать веб-сокеты таким образом.
Большая разница между веб-сокетами и веб-воркерами (и, в более широком смысле, как мы увидим, сервис-воркерами) заключается в том, что они имеют прямой доступ к DOM. В то время как веб-воркеры (и сервис-воркеры) работают в отдельных потоках, веб-сокеты являются частью основного потока, что дает им возможность манипулировать DOM.
Существуют инструменты и службы, помогающие устанавливать и поддерживать соединения через веб-сокеты, в том числе: Кластер сокетов, АсинхронныйAPI, ковбой, Король веб-сокетов, каналыи Горилла веб-сокет. У MDN есть текущий список, который включает другие услуги.
Дополнительная информация о веб-сокетах
Веб-воркеры
Рассмотрим сценарий, в котором вам нужно выполнить кучу сложных вычислений, одновременно внося изменения в DOM. JavaScript — это однопоточное приложение, и выполнение более одного сценария может нарушить пользовательский интерфейс, в который вы пытаетесь внести изменения, а также выполнить сложные вычисления.
Здесь в игру вступают веб-воркеры.
Web Workers позволяют запускать сценарии в фоновом режиме в отдельных потоках, чтобы предотвратить блокировку сценариев друг другом в основном потоке. Это делает их идеальными для повышения производительности приложений, требующих интенсивных операций, поскольку эти операции могут выполняться в фоновом режиме в отдельных потоках, не влияя на пользовательский интерфейс при рендеринге. Но они не так хороши в доступе к DOM, потому что, в отличие от веб-сокетов, веб-воркер работает вне основного потока в своем собственном потоке.
Web Worker — это объект, который выполняет файл сценария с помощью Worker объекта для выполнения задач. И когда мы говорим о работниках, они, как правило, делятся на один из трех типов:
- Преданные работники: Выделенный работник доступен только сценарию, который его вызывает. Он по-прежнему выполняет задачи типичного веб-работника, такие как многопоточные сценарии.
- Общие рабочие: Общий работник — это противоположность преданного работника. К нему можно получить доступ из нескольких сценариев, и он может выполнять практически любую задачу, которую выполняет веб-воркер, если они существуют в том же домене, что и рабочий.
- Работники службы: Service Worker действует как сетевой прокси между приложением, браузером и сервером, позволяя запускать сценарии даже в случае отключения сети. Мы собираемся добраться до этого в следующем разделе.
Дополнительная информация о веб-воркерах
Рабочие службы
Есть некоторые вещи, которые мы как разработчики не можем контролировать, и одна из таких вещей — сетевое подключение пользователя. К какой бы сети ни подключался пользователь, она и есть. Мы можем только сделать все возможное, чтобы оптимизировать наши приложения, чтобы они работали как можно лучше при любом используемом соединении.
Сервисные работники — это одна из вещей, которые мы можем сделать для постепенного повышения производительности приложения. Service Worker находится между приложением, браузером и сервером, обеспечивая безопасное соединение, которое работает в фоновом режиме в отдельном потоке благодаря, как вы уже догадались, Web Workers. Как мы узнали из предыдущего раздела, сервис-воркеры — это один из трех типов веб-воркеров.
Итак, зачем вам сервис-воркер, сидящий между вашим приложением и браузером пользователя? Опять же, у нас нет контроля над сетевым подключением пользователя. Скажем, соединение обрывается по какой-то неизвестной причине. Это нарушит связь между браузером и сервером, предотвратив передачу данных туда и обратно. Сервисный работник поддерживает соединение, действуя как асинхронный прокси-сервер, способный перехватывать запросы и выполнять задачи даже после потери сетевого соединения.
Это основная движущая сила того, что часто называют «офлайн-сначала» разработка. Мы можем хранить активы в локальном кеше, а не в сети, предоставлять важную информацию, если пользователь выходит из сети, выполнять предварительную выборку данных, чтобы они были готовы, когда они потребуются пользователю, и предоставлять запасные варианты в ответ на сетевые ошибки. Они полностью асинхронны, но, в отличие от веб-сокетов, у них нет доступа к DOM, поскольку они работают в своих собственных потоках.
Еще одна важная вещь, которую нужно знать о Service Workers, это то, что они перехватывают каждый запрос и ответ от вашего приложения. Как таковые, они имеют некоторые последствия для безопасности, в первую очередь то, что они следуют политике одного и того же происхождения. Таким образом, это означает отсутствие запуска сервисного работника из CDN или стороннего сервиса. Для них также требуется защищенное HTTPS-соединение, а это значит, что для их работы вам понадобится SSL-сертификат.
Дополнительная информация о сервисных работниках
Подведение итогов
Это очень подробное объяснение различий (и сходств) между веб-сокетами, веб-воркерами и сервис-воркерами. Опять же, терминология и понятия достаточно похожи, чтобы их можно было смешивать друг с другом, но, надеюсь, это даст вам лучшее представление о том, как их различать.
Мы начали с краткой справочной таблицы. Вот то же самое, но немного расширенное, чтобы сделать более толстые сравнения.
| Особенность | Что это | Многопоточный? | HTTPS? | Доступ к ДОМУ? |
|---|---|---|---|---|
| Веб-сокет | Устанавливает открытое и постоянное двустороннее соединение между браузером и сервером для отправки и получения сообщений по одному соединению, инициированному событиями. | Работает в основном потоке | Не требуется | Да |
| Веб-воркер | Позволяет запускать сценарии в фоновом режиме в отдельных потоках, чтобы предотвратить блокировку сценариев друг другом в основном потоке. | Работает в отдельном потоке | необходимые | Нет |
| Сервис работник | Тип Web Worker, создающий фоновую службу, выполняющую промежуточную функцию для обработки сетевых запросов между браузером и сервером даже в офлайн-ситуациях. | Работает в отдельном потоке | необходимые | Нет |
