Вс. Сен 26th, 2021

WebSockets vs HTTP

От создателя: в приложениях реального времени само собой очевидно, что нам нужно получать информацию с серверов, как только она станет доступной — и, по сущности, классическая парадигма HTTP — запрос/ответ не подходит. Это поэтому, что сервер будет молчать, есть ли новые данные либо нет, до тех пор, пока не будет выслан запрос.

Это ограничение привело к возникновению всевозможных хаков и обходных решений, так как разработчики стремились адаптировать модель запроса/ответа к требованиям более оживленной сети реального времени, некоторые из которых стали формализованными и достаточно широко распространенными.

Все эти технологии и подходы — от Comet до длинноватого поллинга HTTP — имеют одну общую черту: по сущности, они призваны создать иллюзию реального (событийного) обмена данными, потому, когда на сервере появляются какие-то новые данные, он посылает ответ.

Несмотря на то, что HTTP не является протоколом, управляемым событиями, не в реальном времени, эти подходы на самом деле работают достаточно хорошо в определенных случаях использования, к примеру, в чате Gmail. Однако проблемы появляются в приложениях с малой задержкой либо масштабировании, в основном из-за требований к обработке, связанных с HTTP.

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

Конкретно эти проблемы в конечном итоге побудили разработчиков Майкла Картера и Яна Хиксона создать WebSockets — по сути, тонкий транспортный уровень, построенный поверх стека TCP/IP. Мысль состояла в том, чтобы предоставить веб-приложениям то, что по сущности является коммуникационным уровнем TCP, максимально приближенным к начальному, исключив несколько абстракций, чтобы устранить определенные трудности, связанные с безопасностью, и другие задачи.

Ранее мы писали о концептуальном глубочайшем погружении в WebSockets, а также освещали эволюцию HTTP и ассоциировали HTTP/2 и HTTP/3, потому не будем возвращаться к этому тут.

Вместо этого в этом посте будут рассмотрены некие методы, используемые для обхода ограничений парадигмы HTTP — запроса/ответа в приложениях реального времени, некие проблемы этой парадигмы и то, как WebSockets может посодействовать их преодолеть.

HTTP

HTTP — это, по сущности, протокол запроса/ответа в клиент-серверной модели и основной режим связи в интернет. Первоначальная версия, предложенная Тимом Бернерсом-Ли в 1989 году, была очень ограниченной и ее стремительно изменили для поддержки более широкой функциональности браузера и сервера.

Эти модификации были в конечном итоге задокументированы рабочей группой HTTP в 1996 году как HTTP/1.0 (RFC 1945), несмотря на то что HTTP/1.0 не считается формальной спецификацией либо стандартом.

HTTP/1.1

HTTP/1.1 является более широко поддерживаемой версией в веб-браузерах и на серверах, и его возникновение стало большим шагом вперед, потому что HTTP/1.1 позволил сделать некие довольно важные оптимизации и улучшения, от неизменных и конвейерных соединений до новых полей заголовка запроса/ответа. Главными из их являются два заголовка, которые служат основой для многих улучшений, помогающих сделать Веб более динамичным в реальном времени.

Заголовок Keep-Alive: употребляется для установки постоянной связи между хостами. Это значит, что соединение может быть повторно применено для более чем одного запроса, что приметно снижает задержку запроса, поскольку клиенту не необходимо повторно согласовывать соединение TCP 3-Way-Handshake после отправки первого запроса. Еще один положительный эффект заключается в том, что в целом соединение со временем становится резвее из-за механизма медленного запуска TCP. До HTTP/1.1 вам приходилось открывать новое соединение для каждой пары запрос/ответ.

Заголовок Upgrade: употребляется для обновления соединения до режима расширенного протокола (к примеру, WebSockets).

HTTP-опрос

HTTP-опрос представляет собой шаг вперед по сопоставлению с классическим механизмом запроса/ответа — несмотря на то что, существуют различные версии опроса, но только длиннющий опрос каким-либо образом применим к приложениям реального времени.

К примеру, короткий опрос HTTP используется таймером на базе AJAX, чтобы клиентские устройства отправляли запросы к серверу через фиксированные интервалы. Но сервер по-прежнему будет немедленно отвечать на каждый запрос, или предоставляя новые данные, либо отправляя «пустой» ответ, если новых данных нет, перед закрытием соединения. Так что для приложений реального времени это принесет не так много полезности, когда клиенту нужно знать о новых данных, как только они становятся доступными.

Конкретно это ограничение привело к развитию длинноватого опроса HTTP, который, по сути, представляет собой способ, предназначенный для имитации функции отправки данных на сервер.

Мы тщательно рассмотрели длинный опрос HTTP здесь, но, по сущности, длинный опрос — это метод, при котором сервер предпочитает держать клиентское соединение открытым как можно подольше (обычно до 20 секунд), доставляя ответ только после того, как данные становится легкодоступным или истек порог тайм-аута.

WebSockets vs HTTP

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

Потоковая передача HTTP

Потоковая передача HTTP — это способ передачи данных в стиле push, который позволяет веб-серверу безпрерывно отправлять данные клиенту по одному HTTP-соединению, которое остается открытым нескончаемо. По сути, клиент делает HTTP-запрос, а сервер посылает ответ неопределенной длины.

Но, хотя потоковая передача HTTP является производительной, обычный в использовании и может быть кандидатурой WebSockets, у нее есть ограничения. Основная неувязка с точки зрения реального времени заключается в том, что посредник может оборвать соединение — будь то из-за тайм-аута либо просто потому, что он обслуживает несколько запросов в «повторяющемся стиле», поэтому не всегда можно гарантировать работу в реальном времени.

HTTP/2.0

HTTP/2.0 произошел от экспериментального протокола — SPDY — который был сначало анонсирован Google в 2009 году. К 2015 году рабочая группа HTTP опубликовала HTTP/2.0 в качестве предлагаемого эталона, взяв за отправную точку спецификацию SPDY.

Мы разглядели HTTP/2.0 в деталях ранее, это было по существу обновление производительности предназначено для увеличения скорости веб-коммуникаций. Основными достижениями в области связи в реальном времени были:

Мультиплексирование: заместо того, чтобы передавать данные в формате открытого текста, данные кодируются как двоичные и инкапсулируются снутри кадров, которые могут быть мультиплексированы по двунаправленным каналам, известным как потоки, по одному TCP-соединению. Это позволяет делать множество параллельных запросов /ответов одновременно.

Server push: Server push — это функция производительности, которая позволяет серверу отправлять ответы клиенту, до того, как клиент их запросит. Эта функция полезна, когда сервер знает, что клиенту необходимы «отправленные» ответы для полной обработки начального запроса.

Несмотря на эти и другие шаги вперед, взрывной рост интернет-трафика, вызванный массовым распространением мобильных устройств, привел к тому, что HTTP / 2.0 столкнулся с трудностями в обеспечении плавного и прозрачного просмотра веб-страниц — в особенности в условиях постоянно растущих требований приложений реального времени и их юзеров.

Плюсы HTTP/2.0

Все браузеры поддерживают протокол HTTP/2 поверх HTTPS с установкой сертификата SSL.

HTTP/2 позволяет клиенту отправлять все запросы сразу через одно TCP-соединение. Теоретически клиент должен резвее получать данные.

TCP — это надежный и размеренный протокол соединения.

Минусы HTTP/2.0

Параллельные запросы имеют возможность увеличить нагрузку на серверы. Серверы HTTP/2 имеют возможность получать запросы большими партиями, что может привести к истечению времени ожидания запросов. Неувязка скачка нагрузки на сервер может быть решена методом установки балансировщика нагрузки или прокси-сервера, который может ограничивать запросы.

Серверная помощь приоритезации HTTP/2 еще не развита. Помощь программного обеспечения все еще развивается. Некие сети CDN или балансировщики нагрузки имеют возможность некорректно поддерживать приоритизацию.

Функцию push в HTTP/2 бывает трудно реализовать правильно.

HTTP/2 имеет HTTP-блокировку заголовка строчки, но блокировка на уровне TCP все еще может вызывать задачи.

HTTP/3.0

HTTP/3.0 — это новенькая итерация HTTP, которая разрабатывается с 2018 года, и, несмотря на то что на момент написания (по состоянию на октябрь 2020 года) он все еще является черновиком эталона, некоторые браузеры уже используют его.
Цель HTTP/3 — обеспечить резвые, надежные и безопасные веб-соединения для всех форм устройств, устраняя задачи HTTP/2 связанные с передачей данных. Для этого он употребляет другой сетевой протокол транспортного уровня, именуемый QUIC, который работает по протоколу пользовательских дейтаграмм (UDP) заместо TCP, который использовался всеми предыдущими версиями HTTP.

Некие потенциальные проблемы с HTTP/3 уже начинают появляться. К примеру:

Разветвления транспортного уровня. Переход на HTTP/3 включает не только изменение уровня приложения, но и изменение нижележащего транспортного уровня. Как следует, внедрение HTTP/3 немного сложнее по сопоставлению с его предшественником.

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

Плюсы HTTP/3.0

Внедрение нового (другого) транспортного протокола QUIC, работающего по UDP, значит уменьшение задержки как теоретически, так, пока и экспериментально.

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

Минусы HTTP/3.0

Разветвления транспортного уровня. Переход на HTTP/3 включает не только изменение уровня приложения, но и изменение нижележащего транспортного уровня. Как следует, внедрение HTTP/3 немного сложнее по сопоставлению с его предшественником.

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

HTTP/3 еще не на сто процентов стандартизирован.

WebSockets

WebSockets vs HTTP

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

WebSocket решает несколько заморочек с HTTP:

Двунаправленный протокол — хоть какой клиент / сервер может отправить сообщение другой стороне (в HTTP запрос всегда инициируется клиентом, а ответ обрабатывается сервером, что делает HTTP однонаправленным протоколом)

Полнодуплексная связь — клиент и сервер имеют возможность одновременно разговаривать друг с другом независимо.

Единое TCP-соединение — клиент и сервер обмениваются данными через одно и то же TCP-соединение (неизменное соединение) на протяжении всего жизненного цикла соединения WebSocket.

Плюсы WebSocket

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

WebSockets поддерживает единое неизменное соединение открытым, устраняя проблемы с задержкой, возникающие при использовании способов HTTP-запросов / ответов.

WebSockets обычно не употребляют XMLHttpRequest, и поэтому заголовки не отправляются каждый раз, когда нам необходимо получить дополнительную информацию с сервера. Это, в свою очередь, понижает объем данных, отправляемых на сервер.

Минусы WebSocket

WebSockets не восстанавливаются автоматом при разрыве соединения — это то, что вам необходимо реализовать самостоятельно, и это одна из обстоятельств, по которым существует множество клиентских библиотек.

Браузеры старше 2011 года имеют возможность не поддерживать WebSocket, но это становится все наименее актуальным.

Почему протокол WebSocket — наилучший выбор

Как правило, WebSockets будет наилучшим выбором в контексте постоянного взаимодействия в реальном времени.

Способы на основе HTTP, как правило, намного более ресурсоемки на серверах, тогда как WebSockets занимают очень мало места. Между тем, такие подходы, как длиннющий опрос, также требуют большого количества переходов меж серверами и устройствами, и эти шлюзы нередко имеют разные представления о том, как длительно типичное соединение может оставаться открытым. Если соединение остается открытым очень долго, что-то может убить его, может быть, даже когда соединение делало что-то принципиальное.

Почему вы должны использовать WebSockets:

Веб-сокеты управляются событиями (в отличие от HTTP). Можно утверждать, что маневренность событиями является предпосылкой для приложения реального времени.

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

Не плохая модель безопасности.

Ably, WebSockets и HTTP

Большая часть Ably’s client library используют WebSocket для установления соединения в реальном времени с Ably, а потом используют простой HTTP-запрос для всех других операций REST, включая аутентификацию.

Но пакеты клиентской библиотеки SDK, подобно нашей Javascript browser library, предусмотрены для выбора наилучшего доступного транспорта в зависимости от браузера и подключения. Поддерживая дополнительные протоколы связи с возможностью возврата к меньшему общему знаменателю, Ably гарантирует, что фактически каждый используемый сегодня браузер сможет установить соединение с Ably в реальном времени. В текущее время, следующие протоколы связи поддерживаются Javascript browser library в порядке от наилучшего к худшему:

WebSockets (поддерживается 98% браузеров по всему миру по состоянию на октябрь 2020 г.)

потоковая передача XHR

опрос XHR

опрос JSONP

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

Автор: Martin Fietkiewicz

Редакция: Команда webformyself.

Докладывает webformyself.com

от Admin

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *