Skip to content

Files

Latest commit

 

History

History
544 lines (335 loc) · 66.2 KB

Ajax.md

File metadata and controls

544 lines (335 loc) · 66.2 KB

AJAX, JSON, CORS и т.д.

Порт

Номер, который, выдаёт операционная система каждой программе, которая хочет отослать данные в сеть.


TCP/IP

Сетевая модель передачи данных, представленных в цифровом виде.

T.е. теоретическое описание принципов работы набора сетевых протоколов, взаимодействующих друг с другом.

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

Название TCP/IP происходит из двух важнейших протоколов семейства — Transmission Control Protocol (TCP) и Internet Protocol (IP), которые были первыми разработаны и описаны в данном стандарте.

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

Как правило, извлечённые данные в свою очередь сформированы в соответствии с протоколом IP и имеют другой вид идентификационной информации — ip адрес получателя (число размером в 4 байта), ip адрес отправителя и данные. А так же много другой необходимой служебной информации. Данные, сформированные в соответствии с IP протоколом, называются пакетами.

Далее извлекаются данные из пакета. Но и эти данные, как правило, ещё не являются изначально отправляемыми данными. Этот кусок информации тоже составлен в соответствии определённому протоколу. Наиболее широко используется TCP протокол. В нём содержится такая идентификационная информация, как порт отправителя (число размером в два байта) и порт источника, а так же данные и служебная информация. Извлечённые данные из TCP, как правило, и есть те данные, которые программа, работающая на компьютере В, отправляла «программе-приёмнику» на компьютере A.

Вложенность протоколов (в данном случае TCP поверх IP поверх Ethernet) называется стеком протоколов.

Фактически TCP/IP не один протокол, а несколько. Именно поэтому вы часто слышите, как его называют набором, или комплектом протоколов, среди которых TCP и IP - два основных.

Ссылки


HTTP

Протокол передачи данных.

HyperText Transfer Protocol, «протокол передачи гипертекста»

Протокол прикладного уровня (верхний 7-й уровень модел OSI) предназначенный для передачи произвольных данных при клиент-серверном взаимодействии.

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

HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения.


HTTP/2

Вторая версия сетевого протокола HTTP.

Цели

  • Добавить механизмы согласования протокола - клиент и сервер могут использовать HTTP 1.1, 2.0 или, гипотетически, иные, не HTTP-протоколы.
  • Уменьшение задержек доступа для ускорения загрузки страниц, в частности путём:
    • Сжатия данных в заголовках HTTP
    • Использования push-технологий на серверной стороне
    • Конвейеризации запросов
    • Устранения проблемы блокировки «head-of-line» протоколов HTTP 1.0/1.1
    • Мультиплексирования множества запросов в одном соединении TCP
  • Сохранение совместимости с существующими применениями HTTP

Отличия от HTTP 1.1

  • Протокол HTTP/2 является бинарным. По сравнению с предыдущим стандартом изменены способы разбиения данных на фрагменты и транспортирования их между сервером и клиентом.
  • В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений.
  • Также часть улучшений получена за счёт мультиплексирования запросов и ответов для преодоления проблемы «head-of-line blocking» протоколов HTTP 1; сжатия передаваемых заголовков и введения явной приоритизации запросов.

Новшества HTTP/2 заключаются в повышении эффективности передачи данных по сети.

HTTP/2 вводит технологию Server Push, которая позволяет серверу отправлять данные в клиентский кэш по собственной инициативе. Однако, при использовании этой технологии данные нельзя отправлять прямо в приложение. Данные, отправленные сервером по своей инициативе, обрабатывает браузер, при этом нет API, которые позволяют, например, уведомить приложение о поступлении данных с сервера и отреагировать на это событие.

Именно в подобной ситуации весьма полезной оказывается технология Server-Sent Events (SSE). SSE — это механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.

После соединения сервер может отправлять данные по своему усмотрению, например, когда окажется готовым к передаче очередной фрагмент данных. Этот механизм можно представить себе как одностороннюю модель издатель-подписчик. Кроме того, в рамках этой технологии существует стандартное клиентское API для JavaScript, называемое EventSource, реализованное в большинстве современных браузеров как часть стандарта HTML5 W3C. Обратите внимание на то, что для браузеров, которые не поддерживают API EventSource, существуют полифиллы.

Так как технология SSE основана на HTTP, она отлично сочетается с HTTP/2. Её можно скомбинировать с некоторыми возможностями HTTP/2, что открывает дополнительные перспективы. А именно, HTTP/2 даёт эффективный транспортный уровень, основанный на мультиплексированных каналах, а SSE даёт приложениям API для передачи данных с сервера.

Технология SSE основана на HTTP. Это означает, что с использованием HTTP/2 не только несколько SSE-потоков могут передавать данные в одном TCP-соединении, но то же самое может быть сделано и с комбинацией из нескольких наборов SSE-потоков (отправка данных клиенту по инициативе сервера) и нескольких запросов клиента (уходящих к серверу).

Благодаря HTTP/2 и SSE теперь имеется возможность организации двунаправленных соединений, основанных исключительно на возможностях HTTP, и имеется простое API, которое позволяет обрабатывать в клиентских приложениях данные, поступающие с серверов. Недостаточные возможности в сфере двунаправленной передачи данных часто рассматривались как основной недостаток при сравнении SSE и WebSocket. Благодаря HTTP/2 подобного недостатка больше не существует. Это открывает возможности по построению систем обмена данными между серверными и клиентскими частями приложений исключительно с использованием возможностей HTTP, без привлечения технологии WebSocket.

Ссылки


HTTPS

Расширение протокола HTTP, реализует упаковку данных в криптографический протокол SSL или TLS.

Метод — это указание операции над ресурсом.

Методы HTTP-протокола:

  • GET — получение данных с ресурса. Не имеет тела, информацию можно передать только через querystring. Кэшируется.
  • HEAD — как GET но не возвращает данных. Используют для проверки существования сайта, получения метаданных. Кэшируется.
  • POST — отправка данных к ресурсу. Не кэшируется.
  • PUT — замещение данных ресурса. Не кэшируется.
  • DELETE — удаление данных ресурса. Не кэшируется.
  • OPTIONS — предварительный запрос к серверу при кросс-доменном запросе. Не кэшируется (???).

Ссылки


JSON (Javascript Object Notation)

Формат данных, который используется для представления объектов в виде строки.

Если нужно с сервера взять объект с данными и передать его клиенту, то в качестве промежуточного формата – для передачи по сети, почти всегда используют именно его.

Данные в формате JSON (RFC 4627) представляют собой:

  • JS-объекты { ... } или
  • Массивы [ ... ] или
  • Значения одного из типов:
    • строки в двойных кавычках,
    • число,
    • логическое значение true/false,
    • null.

Ссылки


AJAX (Asynchronous JavaScript and XML)

Технология отправки запросов к серверу из клиентского кода JavaScript без перезагрузки страницы

Слать AJAX-запросы к серверам с другим доменом запрещено на уровне браузера. Ajax не кроссдоменный, но подходит много для каких задач.

Асинхронный

Браузер предоставляет для AJAX специальный API: конструктор XMLHttpRequest

AJAX работает через XMLHttpRequest (XMLHTTP, XHR), т.е. через запросы HTTP/HTTPS

Т.е. асинхронный обмен данными (JSON/XML/TXT) через HTTP/HTTPS запросы

Сейчас вместо чаще XML используют формат JSON.

При использовании AJAX:

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

AJAX использует два метода работы с веб-страницей:

  • изменение Web-страницы без перезагрузки, используя DHTML (совокупность технологий CSS, DOM и JavaScript)
  • динамическое обращение к серверу. Может осуществляться несколькими способами, в частности, XMLHttpRequest, и использование техники скрытого фрейма.

Алгоритм запроса к серверу выглядит так:

  • Проверка существования на странице объекта XMLHttpRequest. Создание данного объекта для каждого типа браузера — уникальный процесс.
  • Инициализация соединения с сервером.
  • Посылка запроса серверу (GET или POST)
  • Обработка полученных данных.

От сервера можно получить данные нескольких видов:

  • Обычный текст
  • XML
  • JSON

Альтернативы AJAX:

  • Java-апплеты, позднее технология JavaFX;
  • Технология Silverlight корпорации Microsoft;
  • Протокол WebSocket.

Ссылки


DHTML (Dynamic HTML)

Совокупность технологий HTML, CSS, DOM и JavaScript.
Обычный HTML код, дополненный скриптами и каскадными таблицами стилей.

Позволяет делать веб-страницы "интерактивными". Определенные действия посетителя ведут к изменениям внешнего вида и содержания страницы без обращения к серверу.

Для адекватного функционирования динамических сайтов требуется специальный браузер, имеющий встроенную поддержку DHTML. Технология такова, что формирование и интерактивное динамическое поведение таких страниц реализуется именно в самом браузере, как говорят «на стороне клиента». В устаревших браузерах DHTML веб-страницы будут представлены как обычные, статические.

Подход к созданию интерактивного веб-сайта, использует сочетание:

  • статичного языка разметки HTML,
  • встраиваемого (и выполняемого на стороне клиента) скриптового языка JavaScript,
  • CSS (каскадных таблиц стилей)
  • DOM (объектной модели документа).

Конкурирующая техника включает(-ла) в себя Adobe Flash и Silverlight.

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

Ссылки


JSONP (JSON with Padding - JSON с набивкой)

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

Не имеет отношения к AJAX
Устаревший но хитрый способ двунаправленного кроссдоменного взаимодействия, основанный на загрузке скрипта с другого домена.
В частности, с помощью протокла JSONP можно организовать некоторые разновидности технологии COMET.
Насколько я понимаю, работает также с использование XMLHttpRequest, т.е. поверх HTTP/HTTPS

Согласно политике ограничения домена, веб-страница, расположенная на сервере server1.example.com, не может связаться с сервером, отличным от server1.example.com. Эта операция запрещена в большинстве браузеров.

Идея основана на лазейке в стандартах: загружать скрипты с других доменов не запрещено!

Запросы для JSONP получают не JSON, а произвольный JavaScript-код. Они обрабатываются интерпретатором JavaScript, а не парсером JSON.

Существуют серьезные риски, связанные с безопасностью при использовании JSONP, в большинстве ситуаций использование CORS является лучшим выбором.

JSONP кроссдоменный, но подходит только для случаев, когда надо кроссдоменно передать JSON.

Набивка (префикс)
Набивка обычно является именем функции обратного вызова, определённой внутри контекста выполнения в браузере. Кроме имени функции префикс может означать имя переменной, оператор if, или любой другой оператор JavaScript. Ответ на JSONP-запрос (строго говоря — запрос, соответствующий паттерну JSONP) не является объектом JSON и не расценивается браузером, как таковой. «Начинка» может быть любым выражением на JavaScript, и вовсе не требует, чтобы внутри обязательно был JSON. Но обычно это фрагмент JavaScript, применяющий вызов функции к неким JSON-данным.

Другими словами, типичное применение JSONP предоставляет междоменный доступ к существующему JSON API путём оборачивания начинки JSON в вызов функции.

Недостатки

  • Прежде всего, это лазейка, костыль. Разработчики стандартов просто не были настолько хитры, чтобы предугадать динамическое взаимодействие на уровне скриптов.
  • Безопасность. Подгрузка скриптов ни разу не безопасней, чем Аякс. Целое семейство вирусов занимается тем, что добавляет на страницу браузера скрипты для отрисовки баннеров порно и казино. Когда вы подключаетесь к интернету через мобильных операторов, обсосы вставляют в HTML-трафик скрипты для отрисовки виджетов (если соединение не HTTPS)
  • Только GET. JSONP работает только методом GET, что сводит на нет возможности REST-интерфейса. Для REST-сервисов приходится писать прокладки-прокси, т.е. множить костыли. Неустранимое ограничение — позволяет только получение данных GET методом, то есть отправка данных через POST метод остается недоступной.
  • Нельзя отслеживать. Добавив скрипт на страницу, в дальнейшем вы не можете отследить его судьбу. Если у Аякс-запроса есть специальные коллбеки для основных событий (начало, удачное завершение, таймаут, неудачное завершение), то у скрипта ничего такого нет. Загрузился ли он? Ответил ли сервер? Была ли ошибка? Никто не знает.

Каковы проблемы JSONP?

  • Это вне стандартов.
  • Это небезопасно.
  • Если запрос провалился, то ничего мы никогда не узнаем, не обработаем ошибку правильно, не можем отследить судьбу запроса.
  • Мы работаем только с GET — никаких модных REST API.
  • И в общем, так делать не надо в 2017 году.

Приложениям на js нужен надежный способ забирать данные с серверов. Чтобы это была законно, а не по-воровски в обход протоколов и стандартов. Таким способом стал CORS – Cross-Origin Resource Sharing, кросс-доменные запросы.

Ссылки


JSONPP (Parameterized JSON with padding — параметризованный JSONP)

Развитие идеи JSONP.

Включает в себя:

  • URL источника,
  • имя функции, которая будет обрабатывать JSON данные,
  • строка для eval после получения данных
  • строка для eval после окончания обработки данных


CORS

Кросс-доменные запросы. Разрешаем кросс-доменный AJAX (если сервер согласен его принять)

Cross-origin resource sharing (англ. — «совместное использование ресурсов между разными источниками»)
Технология современных браузеров, которая позволяет предоставить веб-странице доступ к ресурсам другого домена. Современный стандарт кроссдоменных запросов
Слать AJAX-запросы к серверам с другим доменом запрещено на уровне браузера
Фактически - расширение поверх AJAX

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

Говорят, что агент пользователя делает запрос с другого источника (cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

Здесь:

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

Браузер добавит заголовок Origin с адресом страницы, откуда инициирован запрос. Подделать заголовок скриптом не удастся

Т.е. по факту я в своём приложении создаю AJAX запрос с опр. набором параметров (заголовки и т.д.), и если сервер поддерживает CORS - он пришлёт ответ

Простые и сложные CORS-запросы

  • Сложные идут в два этапа (preflight запрос и собственно запрос). Сначала браузер делает запрос по тому же урлу, но методом OPTIONS. Сервер должен ответить: какими другими методами и дополнительными заголовками (помимо стандартных) можно обращаться к этому урлу. И только получив разрешение, браузер сделает запрос на основной урл.
  • Запрашиваешь JSON - автоматически должен использовать сложный запрос

Технология CORS может быть использована как более современная и надёжная альтернатива JSONP, так как позволяет использовать все преимущества XMLHttpRequest, и не имеет риска инъекции, как JSONP. С другой стороны, технология CORS поддерживается только современными браузерами, а JSONP работает и в старых тоже.

Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищенному соединению. Современные браузеры используют CORS в API-контейнерах, таких как XMLHttpRequest или Fetch, чтобы снизить риски, присущие запросам с других источников.

Ссылки


COMET

Общий термин, описывающий различные техники получения данных по инициативе сервера.

Когда дело доходит до доставки данных с сервера клиенту, мы ограничены двумя основными подходами: client pull или server push. В качестве простого примера веб-приложения можно привести браузер. Когда сайт, открытый в браузере запрашивает с сервера данные, это называется client pull. Обратная технология, когда сервер активно перенаправляет обновления на сайт, называется server push.

Методика отправки данных по инициативе сервера, разработанная поверх AJAX.

Можно сказать, что AJAX – это «отправил запрос – получил результат», а COMET – это «непрерывный канал, по которому приходят данные».
COMET можно реализовать по протоколу JSONP. Можно и иначе
COMET - методика отправки данных по инициативе сервера, разработанная поверх AJAX.

Примеры COMET-приложений

  • Чат – человек сидит и смотрит, что пишут другие. Новые сообщения приходят «сами по себе», не надо жать кнопку для обновления окна.
  • Аукцион – человек смотрит на экран и видит, как обновляется текущая ставка за товар.
  • Интерфейс редактирования – когда один редактор начинает изменять документ, другие видят информацию об этом. Совместное редактирование.

Какие API предоставляет браузер для взаимодействия COMET?

  • SSE (server-side events) API — события посылаемые сервером — однонаправленное HTTP-подключение к серверу. Поддерживают короткие запросы, длинные запросы, потоковое подключение к серверу.
  • Web Sockets API — двунаправленное взаимодействие с сервером. Работает по собственному протоколу.

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

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

Polling
Использование периодических запросов к серверу через AJAX. Например, скрипт из браузера каждые 5 секунд отправляет запрос на серверный скрипт и запрашивает количество новых непрочитанных сообщений.
Можно дополнительно снизить нагрузку на сервер путем снижения частоты отсылаемых запросов, но это опять же пойдет в ущерб актуальности данных и в разрез с условием задачи о мгновенном информировании пользователя о письме.

Long polling (это вариант реализации COMET)
Есть несколько вариантов реализации, но, к сожалению, практически все они завязаны на конкретном браузере и ведут себя по-своему. Единственным кроссбраузерным и гарантированно работающим решением является так называемая "очередь длинных запросов", или "long polling".

Сначала браузер отправляет AJAX-запрос на сервер и ожидает ответа. Соединение остается открытым до тех пор, пока на сервере не наступит ожидаемое событие (или, как в нашем случае, пока серверный скрипт не отвалится по таймауту). Сразу после наступления события данные отправляются в браузер и соединение закрывается. Браузер после получения данных сразу же открывает новое соединение и все повторяется.

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


WebSocket

Протокол для пересылки любых данных, на любой домен, безопасно и почти без лишнего сетевого трафика. Замена AJAX.

Один из API браузера, который он предоставляет чтоб реализовать COMET.
Альтернатива - SSE (server-side events) API.

WebSocket - протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
Предназначен для решения любых задач и снятия ограничений обмена данными между браузером и сервером.
независимый протокол, основанный на протоколе TCP
Не стоит использовать веб-сокеты в REST API, поскольку вам хватит таких HTTP-запросов, как GET, POST, DELETE и PUT.
В отличие от CORS работает вообще без AJAX, отдельный протокол, даже на HTTP

Протокол WebSocket работает над TCP& также как и HTTP. Т.е. на том же уровне, что и HTTP, заменяет его, а не "поверх него"
AJAX работает на HTTP
Это означает, что при соединении браузер отправляет по HTTP специальные заголовки, спрашивая: «поддерживает ли сервер WebSocket?».
Если сервер в ответных заголовках отвечает «да, поддерживаю», то дальше HTTP прекращается и общение идёт на специальном протоколе WebSocket, который уже не имеет с HTTP ничего общего.

Соединение WebSocket можно открывать как WS:// или как WSS://. Протокол WSS представляет собой WebSocket над HTTPS.
Кроме большей безопасности, у WSS есть важное преимущество перед обычным WS – большая вероятность соединения.
Дело в том, что HTTPS шифрует трафик от клиента к серверу, а HTTP – нет.
Если между клиентом и сервером есть прокси, то в случае с HTTP все WebSocket-заголовки и данные передаются через него. Прокси имеет к ним доступ, ведь они никак не шифруются, и может расценить происходящее как нарушение протокола HTTP, обрезать заголовки или оборвать передачу.
А в случае с WSS весь трафик сразу кодируется и через прокси проходит уже в закодированном виде. Поэтому заголовки гарантированно пройдут, и общая вероятность соединения через WSS выше, чем через WS.

Проверить поддержку браузером WebSocket можно, пройдя по ссылке: http://caniuse.com/#feat=websockets.

Это сдвиг парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Как только ваша страница решила, что она хочет открыть веб сокет на сервер, она создает специальный javascript-объект WebSocket и навешивает на новый объект три колл-бека:

  • первый вызовется, когда соединение будет установлено:
  • второй - когда соединено закроется
  • третий - каждый раз, когда браузер получает какие-то данные через веб-сокет

Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос

Если сервер поддерживает ВебСокеты, то он отвечает опр. образом

Если браузер это устраивает, то он просто оставляет TCP-соединение открытым. Все — «рукопожатие» совершено, канал обмена данными готов.

Как только одна сторона хочет передать другой какую-то информацию, она отправляет дата-фрей. Это просто строка текста — последовательность байт. Никаких заголовков, метаданных! Что именно отправлять, разработчики полностью оставили на ваше усмотрение: хотите XML, хотите JSON, да хоть стихи Пушкина.

Каждый раз, когда браузер будет получать такое сообщение, он будет «дергать» ваш колл-бек onmessage.

Легко понять, что КПД такого протокола стремится к 95%. Это не классический AJAX-запрос, где на каждую фитюльку приходится пересылать несколько килобайт заголовков. Разница будет особенно заметна если делать частый обмен небольшими блоками данных. Скорость обработки так же стремится к скорости чистого TCP-сокета — ведь все уже готово — соединение открыто — всего лишь байты переслать.

В качестве единственной разрешенной кодировки выбрана UTF-8

А картинку можно отправить? Да. С помощью WebSockets так же можно передавать и бинарные данные. Для них используется другой дата-фрейм опр. вида

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

Стандартность
Самим своим выходом WebSockets отправит на свалку истории Comet и все приблуды накрученные поверх него — Bayuex, LongPolling, MultiPart и так далее. Это все полезные технологии, но по большей части, они работают на хаках, а не стандартах. Отсюда периодески возникают проблемы

Время жизни канала
В отличие от HTTP веб-сокеты не имеют ограничений на время жизни в неактивном состоянии. Это значит, что больше не надо периодически рефрешить соединение, т.к. его не вправе «прихлопывать» всякие прокси. Значит, соединение может висеть в неактивном виде и не требовать ресурсов. Конечно, можно возразить, что на сервере будут забиваться TCP-сокеты. Для этого достаточно использовать хороший мультиплексор, и нормальный сервер легко потянет до миллиона открытых коннектов.

Комплексные веб-приложения
Как известно в HTTP предусмотрено ограничение на число одновременных октрытых сессий к одному серверу. Из-за этого если у вас много различных асинхронных блоков на странице, то вам приходилось делать не только серверный, но и клиентский мультиплексор — именно отсюда идет Bayeux Protocol.

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

Кросс-доменные приложения
И еще один «камень в ботинке» AJAX-разработчика — проблемы с кросс-доменными приложениями. Да, и для них тоже придумана масса хаков. Помашем им ручкой и смахнем скупую слезу. WebSockets не имеет таких ограничений. Ограничения вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере. Думаю, внимательные уже заметили новый заголовок Origin. Через него передается информация откуда хотят подключиться к вашему websocket-у. Если этот адрес вас не устраивает, то вы отказываете в соединение.

WebSocket и SSE Насколько я понимаю, сейчас WebSocket - не самая актуальная технология. При прочих равных лучше использовать HTTP/2+SSE.

Несмотря на чрезвычайно широкое распространение связки HTTP/2+SSE, технология WebSocket, совершенно определённо, не исчезнет, в основном из-за того, что она отлично освоена и из-за того, что в весьма специфических случаях у неё есть преимущества перед HTTP/2, так как она была создана для обеспечения двустороннего обмена данными с меньшей дополнительной нагрузкой на систему (например, это касается заголовков).

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

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

Если вам нужно, например, показывать пользователям в реальном времени новости или рыночные данные, или вы создаёте чат-приложение, использование связки HTTP/2+SSE даст вам эффективный двунаправленный канал связи, и, в то же время — преимущества работы с технологиями из мира HTTP. А именно, технология WebSocket нередко становится источником проблем, если рассматривать её с точки зрения совместимости с существующей веб-инфраструктурой, так как её использование предусматривает перевод HTTP-соединения на совершенно другой протокол, ничего общего с HTTP не имеющий. Кроме того, тут стоит учесть соображения масштабируемости и безопасности. Компоненты веб-систем (файрволы, средства обнаружения вторжений, балансировщики нагрузки) создают, настраивают и поддерживают с оглядкой на HTTP. В результате, если говорить об отказоустойчивости, безопасности и масштабируемости, для больших или очень важных приложений лучше подойдёт именно HTTP-среда.

Ссылки


SSE API (Server-Sent events)

SSE — это механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.

События посылаемые сервером, т.е. однонаправленное HTTP-подключение к серверу.

Ещё один вариант API, который предоставляет браузер для взаимодействия COMET.

Альтернатива WebSocket. Технология SSE основана на HTTP, т.е. нет необходимости вводить новый протокол (WebSocket) - а это важное преимущество (безопасность, простоат, настройка сервера)

Отлично работате с HTTP/2

Несмотря на чрезвычайно широкое распространение связки HTTP/2+SSE, технология WebSocket, совершенно определённо, не исчезнет, в основном из-за того, что она отлично освоена и из-за того, что в весьма специфических случаях у неё есть преимущества перед HTTP/2, так как она была создана для обеспечения двустороннего обмена данными с меньшей дополнительной нагрузкой на систему (например, это касается заголовков).

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

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

Если вам нужно, например, показывать пользователям в реальном времени новости или рыночные данные, или вы создаёте чат-приложение, использование связки HTTP/2+SSE даст вам эффективный двунаправленный канал связи, и, в то же время — преимущества работы с технологиями из мира HTTP. А именно, технология WebSocket нередко становится источником проблем, если рассматривать её с точки зрения совместимости с существующей веб-инфраструктурой, так как её использование предусматривает перевод HTTP-соединения на совершенно другой протокол, ничего общего с HTTP не имеющий. Кроме того, тут стоит учесть соображения масштабируемости и безопасности. Компоненты веб-систем (файрволы, средства обнаружения вторжений, балансировщики нагрузки) создают, настраивают и поддерживают с оглядкой на HTTP. В результате, если говорить об отказоустойчивости, безопасности и масштабируемости, для больших или очень важных приложений лучше подойдёт именно HTTP-среда.

Ссылки


Server Push

HTTP/2 вводит технологию Server Push, которая позволяет серверу отправлять данные в клиентский кэш по собственной инициативе. Однако, при использовании этой технологии данные нельзя отправлять прямо в приложение. Данные, отправленные сервером по своей инициативе, обрабатывает браузер, при этом нет API, которые позволяют, например, уведомить приложение о поступлении данных с сервера и отреагировать на это событие.

Именно в подобной ситуации весьма полезной оказывается технология Server-Sent Events (SSE). SSE — это механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.

Ссылки


XMLHttpRequest (XHR)

Объект, который дает возможность браузеру из JavaScript делать HTTP-запросы к серверу без перезагрузки страницы.

  • Все современные браузеры (IE7+, Firefox, Chrome, Safari и Opera) имеют встроенный объект XMLHttpRequest.
  • Может работать с синхронными и асинхронными запросами
  • Как правило, XMLHttpRequest используют для загрузки данных.

В современной веб-разработке XMLHttpRequest используется по трём причинам:

По историческим причинам: существует много кода, использующего XMLHttpRequest, который нужно поддерживать.

Необходимость поддерживать старые браузеры и нежелание использовать полифилы (например, чтобы уменьшить количество кода).

Потребность в функционале, который fetch пока что не может предоставить, к примеру, отслеживание прогресса отправки на сервер.

XMLHttpRequest может осуществлять запросы на другие сайты, используя ту же политику CORS, что и fetch.

Ссылки


Fetch

встроенный метод браузера для AJAX-запросов, замена XMLHttpRequest.

Большинство браузеров уже поддерживает fetch – новый встроенный метод для AJAX-запросов, призванный заменить XMLHttpRequest.

Он гораздо мощнее, чем httpGet.

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

Ссылки



Документация API при помощи RAML

Специализированный язык для описания REST API

В частности, его используют для описани документации IT-Kamasutra

Ссылки



Полезные ссылки



Legmo, 2019