WebSockets (WS) – взаємозв’язок сервера і клієнта для отримання інформації з боку сервера без необхідності попередньо запитувати клієнтську частину, отримуючи так зване PUSH-повідомлення. Ідеальна схема взаємодії JavaScript WebSocket виглядає так, щоб у серверній частині був один потік, який обробляє інформацію, наприклад, прослуховує зміни БД або події, що запускаються іншими процесами, для одночасної відправки інформації всім клієнтам без використання ресурсів. Клієнт WebSocket в JS і HTML5 з використанням інтерфейсу WS, надається більшістю сучасних браузерів: IE 10 +, Chrome 16+, Firefox 11+, Safari 6+.
Визначення WebSockets
Веб-сокети визначені у вигляді двостороннього зв’язку між сервером і клієнтом. Ключовими моментами JavaScript WebSocket є істинний паралелізм та оптимізація продуктивності, що призводить до більш чуйним і насиченим веб-додатків.
Протокол встановлює повнодуплексний зв’язок з нуля. Веб-сокети – це крок вперед щодо забезпечення функціональності настільних ПК в браузерах. Вони демонструють новий етап еволюції, який тривалий час очікувався в інтернет-технології клієнт/сервер.
Основні особливості JavaScript WebSocket наступні:
Найбільша перевага JavaScript WebSocket — це двосторонній зв’язок (повний дуплекс) по одному TCP-з’єднання. HTTP має свій власний набір схем, таких як http і https. Протокол веб-сокета також має аналогічну схему, визначену в його шаблоні URL. Остання специфікація протоколу WS визначається, як RFC 6455 – пропонований стандарт. RFC 6455 підтримується різними браузерами, такими як Internet Explorer, Mozilla Firefox, Google Chrome.
Дуплексний зв’язок
Перш ніж перейти до необхідності застосування веб-сокетів, необхідно поглянути на існуючі методи, які використовуються для дуплексного зв’язку client Java WebSocket. Вони полягають в наступному:
- голосування;
- довгий опитування;
- streaming;
- постбэк і AJAX;
- HTML5.
Опитування може бути визначений, як метод, який виконує періодичні запити незалежно від даних, існуючих в передачі. Вони відправляються синхронно. Відповідь сервера включає в себе доступні дані або деякі попередження.
Довгий опитування, як випливає з назви, включає в себе схожу техніку опитування. Клієнт і сервер підтримують з’єднання активним, поки не будуть отримані деякі дані або не закінчиться час очікування. Якщо з’єднання втрачено з яких-небудь причин, Java client WebSocket може почати процедуру заново і виконати послідовний запит. Довгий опитування — не що інше, як поліпшення продуктивності в порівнянні з процесом опитування, але постійні запити можуть сповільнювати процес.
Варіанти Streaming і AJAX
Це вважається найкращим варіантом для передачі даних в режимі реального часу. Сервер підтримує з’єднання відкритим і активним з клієнтом до тих пір, поки не будуть отримані необхідні дані. В цьому випадку з’єднання вважається відкритим на невизначений термін. Потокова передача включає заголовки HTTP, збільшують розмір файлу і затримку. Це можна розглядати як головний недолік.
Це скорочена форма асинхронного Javascript і XML. Об’єкт XmlHttpRequest дозволяє виконувати Javascript без перезавантаження всієї веб-сторінки. AJAX відправляє і отримує лише частину веб-сторінки. Основними недоліками AJAX порівняно з вебсокетами JavaScript є:
HTML5 – це надійна структура для розробки і проектування веб-додатків. Основними стовпами є API-інтерфейси розмітки, CSS3 і Javascript.
Функціональні можливості
WebSocket являє собою серйозне оновлення в історії веб-комунікацій. До його існування всі комунікації між веб-клієнтами і серверами ґрунтувалися тільки на HTTP. Web Socket допомагає в динамічному потоці сполук, які є постійними полнодуплексными. Повний дуплекс відноситься до зв’язку з обох кінців зі значною швидкістю. Це називається зміною гри з-за його ефективного подолання всіх недоліків існуючих протоколів.
Важливість WS для розробників і архітекторів:
Websocket API підтримує можливість визначення субпротоколов — бібліотек протоколів, які можуть інтерпретувати певні їх типи. Приклади таких протоколів включають XMPP, STOMP і AMQP. Розробникам більше не потрібно думати над типом з’єднання з точки зору парадигми HTTP «запит-відповідь».
Єдина вимога на стороні браузера — це запуск бібліотеки JavaScript, яка може інтерпретувати рукостискання WS, встановлювати і підтримувати з’єднання. На стороні сервера промисловим стандартом є використання існуючих бібліотек протоколів, які працюють поверх TCP і використовують шлюз.
Функціональні можливості веб-сокетів:
Реалізація клієнта JavaScript
Вихідний код JavaScript з ім’ям файлу wsclient.js включають в сторінку HTML5, щоб він міг відкрити з’єднання WebSocket. Сценарій містить код для створення клієнта WS з використанням його інтерфейсу.
Проста сторінка HTML5 використовується для створення форми підключення до кінцевої точки сервера і обміну повідомленнями. HTML-сторінка використовує wsclient.js скрипт, щоб запустити HTML-файл, відкрити його в браузері, наприклад, Google Chrome, вибравши «Файл» -> «Відкрити».
Простий сервер може бути легко реалізований на Java. Він просто повертає повідомлення, отримане від клієнта, у верхньому регістрі:
Налаштування Java WebSocket spring
Spring-boot-starter-websocket — надає корисні значення за замовчуванням для WS. Насамперед, налаштовують брокер повідомлень STOMP. В ньому WebSocketConfig.Java визначають кінцеву точку STOMP брокера повідомлень і кінцеву точку додатки websocket.@Configuration — клас конфігурації Spring.
EnableWebSocketMessageBroker — включає обробку повідомлень, підтримувану брокером. Тут використовують STOMP в якості брокера повідомлень.
Метод ConfigureMessageBroker () дозволяє простого посередника на основі пам’яті передавати повідомлення клієнту по адресатам з префіксами «/topic/queue». Він також означає префікс «/app» для тих, що пов’язані з анульованими методами @Message Mapping в класі контролера. Цей префікс буде використовуватися для визначення всіх відображень повідомлень. Наприклад, «/app/message» — це кінцева точка, для якої призначено метод WebSocket Controller.processMessage From Client ().
Аналогічно, RegisterStompEndpoints () включає підтримку STOMP і реєструє кінцеві точки stomp «/привітанні». При цьому всі повідомлення веб-сокета JavaScript будуть направлятися через STOMP, що також додає додатковий рівень безпеки до кінцевої точки веб-сокета. При створенні з’єднання WS з javascript використовують тільки цю конкретну кінцеву точку Stomp.
У наведеній нижче конфігурації, щоб включити підтримку SockJs для надання опціонального зворотної дії, необхідно внести наступні зміни: registry.addEndpoint («/ вітання») .withSockJS ().
Перевага використання sockJS тут полягає в тому, що всякий раз, коли з’єднання веб-сокета вимкнено або не може бути встановлено, тоді воно буде знижений до HTTP, і зв’язок між клієнтом і сервером все ще може продовжуватися.
Обробка помилок
Як тільки між клієнтом і сервером встановлено з’єднання, з примірника WS запускається подія Open. Помилки, які мають місце під час спілкування, генеруються. Це визначається за допомогою події OnError. Виникнення помилки завжди супроводжується розривом з’єднання.
OnError — подія викликається, коли щось не так відбувається між комунікаціями. За помилкою події слід завершення з’єднання. Рекомендується завжди інформувати користувача про непередбачені помилки і намагатися знову підключити з’єднання.
Коли справа доходить до обробки помилок, потрібно враховувати як внутрішні, так і зовнішні параметри:
Перевірка доступності мережі
У сучасних настільних і мобільних додатках звичайної завданням є перевірка доступності мережі. Найбільш поширений спосіб WebSocket php JavaScript — виконати HTTP-запит до веб-сайту, який повинен бути активований, наприклад, google.com. Якщо запит виконується успішно, настільні або мобільний пристрій повідомляє, що існує активне з’єднання. Аналогічно в HTML є XMLHttpRequest для визначення доступності мережі.
HTML5 ж зробив цей процес ще простіше, і представив спосіб перевірити, чи браузер приймати веб-відповіді. Це досягається з допомогою навігатора об’єкта.
Автономний режим означає що, пристрій не підключено, який користувач обрав автономний режим на панелі інструментів браузера.
Testing Java WebSocket використовує простий WS-client. Як тільки з’єднання встановлено, відправляють дані на сервер і роздруковують отриманий відповідь: import websocket.
Події OnOpen, OnClose і OnMessage
Сервер WebSocket — це проста програма, яка може обробляти події та дії WS. Зазвичай він надає методи, аналогічні API-інтерфейсу клієнта. У той же час більшість мов програмування надають реалізацію зв’язку між сервером і клієнтом WebSocket, виділяючи ініційовані події і дії.
Сервер WebSocket працює аналогічно клієнтам. Він реагує на події і, при необхідності, виконує дії. Незалежно від використовуваної мови програмування, кожен сервер WebSocket виконує певні процедури. Він ініціалізується за адресою веб-сокета, обробляє події OnOpen, OnClose і OnMessage, а також надсилає повідомлення клієнтам. Існує чотири основні події Websocket API:
- відкрито;
- повідомлення;
- закрито;
- помилка.
Кожне з подій обробляється за допомогою реалізації таких функцій, як OnOpen, OnMessage , OnClose і OnError відповідно. Це також може бути реалізовано за допомогою методу addEventListener..
Примірник веб-сокетів в Java
Кожному серверу WS потрібно дійсний хост і порт. Приклад створення екземпляра Websocket на сервері: var server = new WebSocketServer(«ws://localhost:8181»).
Будь дійсний URL може використовуватися зі специфікацією порту, який раніше не використовувався. Дуже корисно вести облік підключених клієнтів, так як він накопичує та зберігає різні дані або відправляє різні повідомлення кожному з них.
Fleck являє вхідні з’єднання (клієнти) з інтерфейсом IwebSocketConnection. Всякий раз, коли хтось підключається або відключається від сервісу, можна створити або оновити порожній список: var clients = new List ().
Після цього викликають метод Start, і чекають підключення клієнтів. Після запуску сервер може приймати вхідні з’єднання. У Fleck методу Start потрібний параметр, який вказує сокет, який викликав події: server.Start(socket) =>{});
Для того щоб реалізувати сервер WebSocket в C#, потрібно використовувати зовнішню бібліотеку. Для отримання того ж результату на Java, використовуються переваги технології, включеної в стандартну бібліотеку з використанням пакету javax.websocket, починаючи з Java EE 7.
Створюють проект Java WebSocket client на основі Java EE 7 за допомогою однієї з безкоштовних онлайн-середовищ IDE, наприклад, Eclipse та NetBeans. В NetBeans створюють новий веб-застосунок і обов’язково використовують GlassFish в якості сервера (версія 4.0). Якщо користувач надає перевагу використовувати Eclipse, йому доведеться вибрати Tomcat 8. Таким чином, визначають пакет, який можна назвати MyServer, і всередині нього створюють клас WebSocket Server. Код для реалізації сервера цілком читабельний, і його поведінка легко зрозуміти.
Переваги веб-сокета
WS вирішує кілька проблем з REST або HTTP. HTTP — це односторонній протокол, в якому клієнт завжди ініціює запит. Сервер обробляє і повертає відповідь, а потім клієнт використовує його. Websocket — це двонаправлений протокол, в якому немає визначених шаблонів повідомлень, таких як запит/відповідь. Або клієнт, або сервер може відправити повідомлення іншій стороні.
HTTP дозволяє повідомленням запиту перейти від клієнта до сервера, а потім він відправляє відповідь. У певний момент часу клієнт спілкується з сервером або навпаки. Як правило, нове з’єднання TCP ініціюється для HTTP-запиту і припиняється після одержання відповіді. Необхідно встановити нове TCP-з’єднання для іншого HTTP-запиту / відповіді.
Для WS HTTP-з’єднання оновлюється з використанням стандартного механізму оновлення. Клієнт і сервер обмінюються даними через один і той же TCP-з’єднання в межах життєвого циклу з’єднання WS.
Websocket — це протокол низького рівня. Все, включаючи простий шаблон запиту/відповіді, способи створення, оновлення, видалення необхідних ресурсів та коди стану. Всі вони ретельно визначені для HTTP.
WS — це протокол з відстеженням стану, тоді як HTTP — це протокол без збереження стану.
З’єднання WS можуть масштабуватися вертикально на одному сервері, тоді як HTTP може масштабуватися горизонтально. Існує кілька запатентованих рішень для горизонтального масштабування, але вони не засновані на стандартах.
HTTP поставляється з безліччю інших переваг, таких як кешування, маршрутизація та мультиплексування. Все це повинно бути визначено поверх WebSocket і бази даних Java.