У яких ситуаціях віддавав би перевагу довгому / короткому опитуванню AJAX перед HTML5 WebSockets?


306

Я будую невеликий додаток для чату для друзів, але не знаю, як своєчасно отримувати інформацію, яка не настільки ручна чи настільки рудиментарна, як примушування до оновлення сторінки.

В даний час я реалізую це за допомогою простого AJAX, але це має недолік регулярного натискання сервера, коли минув короткий таймер.

Досліджуючи довгі / короткі опитування, я натрапив на HTML5 WebSockets. Це здається простим у виконанні, але я не впевнений, чи є якісь приховані недоліки. Наприклад, я думаю, що WebSockets підтримується лише певними браузерами. Чи є інші недоліки WebSockets, про які я повинен знати?

Оскільки здається, що обидві технології роблять одне і те ж, у яких сценаріях ви б хотіли використовувати один за іншим? Більш конкретно, чи HTML5 WebSockets зробив AJAX довгий / короткий опитування застарілим, чи є вагомі причини віддати перевагу AJAX над WebSockets?

Відповіді:


508

WebSockets - це безумовно майбутнє.

Довге опитування - це брудне рішення, щоб запобігти створенню з'єднань для кожного запиту, як AJAX - але довге опитування було створено, коли WebSockets не існувало. Зараз через WebSockets триває довге опитування.

WebRTC дозволяє здійснювати одноранговий зв’язок.

Я рекомендую вивчити WebSockets .

Порівняння:

різних технік спілкування в Інтернеті

  • AJAX - requestresponse. Створює з'єднання з сервером, надсилає заголовки запитів із необов'язковими даними, отримує відповідь від сервера та закриває з'єднання. Підтримується у всіх основних браузерах.

  • Довге опитування - requestwaitresponse. Створює підключення до сервера, як AJAX, але підтримує постійне з'єднання відкритим на деякий час (хоча недовго). Під час з'єднання відкритий клієнт може отримувати дані з сервера. Клієнту доводиться періодично підключатися після закриття з'єднання через тайм-аути або дані eof. На стороні сервера вона все ще трактується як запит HTTP, такий же як AJAX, за винятком того, що відповідь на запит відбудеться зараз або через деякий час у майбутньому, визначений логікою програми. діаграма підтримки (повна) | Вікіпедія

  • WebSockets - clientserver. Створіть TCP-з'єднання з сервером і тримайте його відкритим, наскільки це потрібно. Сервер або клієнт можуть легко закрити з'єднання. Клієнт проходить процедуру рукостискання, сумісного з HTTP. Якщо це вдасться, то сервер і клієнт можуть обмінюватися даними в обох напрямках у будь-який час. Це ефективно, якщо програма вимагає частого обміну даними обома способами. WebSockets мають обрамлення даних, що включає маскування кожного повідомлення, що надсилається від клієнта до сервера, тому дані просто шифруються. діаграма підтримки (дуже хороша) | Вікіпедія

  • WebRTC - peerpeer. Транспорт для встановлення зв'язку між клієнтами є транспортно-агностичним, тому він може використовувати UDP, TCP або навіть більш абстрактні шари. Зазвичай це використовується для передачі даних з великим обсягом, наприклад, потокової передачі відео / аудіо, де надійність є вторинною і кілька кадрів або зниження прогресу якості можуть бути принесені в жертву на користь часу відгуку і, щонайменше, деякої передачі даних. Обидві сторони (однолітки) можуть передавати дані один одному незалежно. Хоча він може використовуватися абсолютно незалежно від будь-яких централізованих серверів, він все ще потребує певного способу обміну даними кінцевих точок, де в більшості випадків розробники все ще використовують централізовані сервери для "зв’язку" однолітків. Це потрібно лише для обміну необхідними даними для встановлення з'єднання, після чого централізований сервер не потрібен. діаграма підтримки (середня) | Вікіпедія

  • Події, надіслані сервером - clientserver. Клієнт встановлює стійке і довготривале підключення до сервера. Лише сервер може надсилати дані клієнту. Якщо клієнт хоче надіслати дані на сервер, для цього знадобиться використовувати іншу технологію / протокол. Цей протокол сумісний із протоколом HTTP та простий у реалізації в більшості платформ на стороні сервера. Це кращий протокол, який слід використовувати замість тривалого опитування. діаграма підтримки (хороша, крім IE) | Вікіпедія

Переваги:

Основна перевага WebSockets на стороні сервера полягає в тому, що це не запит HTTP (після рукостискання), а належний протокол зв'язку на основі повідомлень. Це дає змогу досягти величезних переваг продуктивності та архітектури . Наприклад, у node.js ви можете поділяти однакову пам’ять для різних підключень сокетів, тому кожен може отримати доступ до спільних змінних. Тому вам не потрібно використовувати базу даних як пункт обміну посередині (наприклад, AJAX або Long Polling з мовою, як PHP). Ви можете зберігати дані в оперативній пам’яті або навіть знову публікувати їх між сокетами.

Міркування щодо безпеки

Люди часто стурбовані безпекою WebSockets. Реальність полягає в тому, що це має незначне значення або навіть ставить WebSockets як кращий варіант. Перш за все, у AJAX більше шансів на MITM , оскільки кожен запит є новим TCP-з'єднанням, яке проходить через Інтернет-інфраструктуру. Після підключення до WebSockets набагато складніше перехоплення між ними, додатково примусового маскування кадру при передачі даних з клієнта на сервер, а також додаткового стиснення, що вимагає більше зусиль для зондування даних. Всі сучасні протоколи підтримують як HTTP, так і HTTPS (зашифровані).

PS

Пам’ятайте, що WebSockets, як правило, дуже відрізняється логікою підключення до мереж , більше схожий на ігри в реальному часі весь цей час, а не як http.


15
Справа не в сумісності. Найголовніше - це те, щоб повністю переосмислити спосіб спілкування. Оскільки API RESTful працює з шаблоном Request> Response, двосторонній зв'язок тут буде безглуздим. Отож, спроба використовувати WebSockets для запиту API RESTful - це трохи дивна спроба, і явно не бачу користі від цього. Якщо вам потрібні дані з API RESTful, але в режимі реального часу, тоді ви створюєте api WebSockets для передачі даних, які працюватимуть із двостороннім зв’язком, як WebSockets. Ви намагаєтеся порівняти речі за кутом, які вони не порівнянні :)
moka

2
Привіт, @pithhelmet, все залежить від програмного забезпечення (мова / техніка) на сервері. WebSocket є шаром над TCP, і існує багато способів здійснення реалізації потоку TCP. Сучасні веб-сервери використовують архітектуру, засновану на подіях, і дуже ефективні з пуловими потоками. Яку техніку ви використовуєте? Node.js використовує події за кадром для IO та події з єдиним потоком у контексті виконання, тому це надзвичайно ефективно. Використання потоку для кожного з'єднання - дуже неефективно з точки зору оперативної пам’яті (1 Мб + на потік), а також процесора, оскільки ці потоки будуть простоювати або ще гірше - нескінченний цикл перевірки даних.
мока

4
Тривале опитування не є брудним вирішенням і відрізняється від webSocket. Ці два призначені для використання в різних сценаріях.
bagz_man

5
@bagz_man Довге опитування - це "хакі" використання технології для досягнення результатів, які технологія за визначенням не дозволяла і не була доступна стандартна альтернатива. Причина Довгого опитування існує саме в тому, що WS цього не зробив, Період.
мока

4
@moka: Вільний рівень Cloudflare поглинає стійку атаку 400 + Gbps. Чи може ваш гаманець поглинути рахунок AWS? Також AWS та Cloudflare мають протилежні погляди, коли справа стосується скарг на ваше походження. Це просто щось пам’ятати, поки ми обговорюємо компроміси. :)
danneu

11

Однією з проблемних технологій, яку ви пропустили, є події, що надсилаються сервером / джерело подій. Що таке довгі опитування, веб-розетки, події, надіслані сервером (SSE) та комета? про все це добре обговорює. Майте на увазі, що деякі з них простіше, ніж інші, інтегруватись із стороною сервера.


З усього цього, в кого б ви не запропонували заглянути?
somdow

Я мав успіх у довготерміновому опитуванні, єдиний трюк (для нього та інших технологій) - не зав'язування потоку сервера. Якщо ви не використовуєте асинхронний код сервера, він не змінюватиме масштаб.
bmm6o

1
@somdow Maksims-Mihejevs чудово відповів на ваше запитання в перших двох абзацах своєї відповіді. Використовуйте веб-розетки.
Джефф Шеффілд

7

Для чатів або будь-якого іншого додатка, який постійно веде розмову з сервером, WebSocketsнайкращий варіант. Однак ви можете користуватися лише WebSocketsна сервері, який їх підтримує, щоб це обмежило ваші можливості використовувати їх, якщо ви не можете встановити потрібні бібліотеки. У такому випадку вам потрібно буде скористатися, Long Pollingщоб отримати подібний функціонал.


5
WebSockets підтримується на кожному сервері ... Вам просто потрібно встановити node.js або щось подібне.
noob

9
Трохи підмітив, щоб пояснити, що так, будь-який сервер підтримуватиме WebSockets. Однак якщо ви користуєтесь хостинговою службою, можливо, ви не зможете ними скористатися.
Брант Олсен

Я усвідомлюю, що цей потік трохи старий, але ... WebSockets не може бути найкращою відповіддю для всього двостороннього спілкування. Нещодавно я помітив, що документація для підтримки веб-сокетів Spring 4 говорить про те, що WebSockets краще підходять для переміщення великої кількості даних або низької затримки. Якщо вони не застосовуються або не є пріоритетними, тоді, я вважаю, вони пропонують використовувати тривале опитування. Я не знаю повного виправдання для цього погляду, я просто зрозумів, що весняні знають, про що вони взагалі говорять.
Стоні

1
@Stoney, крім того, що вам потрібно було б встановити веб-сокет на сервері (обробники тощо), просто немає причин використовувати довге опитування через веб-сокет. Вебсокет набагато швидший (низька затримка) і дозволяє серверу "говорити" з клієнтом, не вимагаючи від нього клієнта. В даний час я використовую сигналр (одна з найкращих реалізацій websocket, коли-небудь зроблену на мою думку - він працює на клієнті та сервері і дозволяє клієнтові викликати методи на сервері, а сервер на клієнті, як ніби немає різниці) на кожному веб-сайт, який я роблю - динамічне завантаження контенту, бездонні сторінки тощо
DividedByZero

0

Опитування XHR проти SSE проти WebSockets

  • Опитування XHR На запит відповідає, коли відбувається подія (може бути негайно або після затримки). Подальші запити потрібно буде отримати для отримання подальших подій.

    Браузер робить асинхронний запит сервера, який може зачекати, коли дані стануть доступними, перш ніж відповісти. Відповідь може містити закодовані дані (як правило, XML або JSON) або Javascript, які слід виконати клієнтом. В кінці обробки відповіді браузер створює та надсилає ще один XHR, щоб чекати наступної події. Таким чином, браузер завжди зберігає запит із сервером, на який потрібно відповідати, коли відбувається кожна подія. Вікіпедія

  • Сервер надсилає події Клієнт надсилає запит на сервер. Сервер в будь-який час надсилає нові дані на веб-сторінку.

    Традиційно веб-сторінка повинна надсилати запит на сервер для отримання нових даних; тобто сторінка запитує дані з сервера. За допомогою подій, що надсилаються сервером, сервер може надсилати нові дані на веб-сторінку в будь-який час, натискаючи повідомлення на веб-сторінку. Ці вхідні повідомлення можна розглядати як події + дані всередині веб-сторінки. Мозила

  • WebSockets Після початкового рукостискання (через протокол HTTP). Зв'язок здійснюється двосторонньо, використовуючи протокол WebSocket.

    Рукостискання починається з запиту / відповіді HTTP, що дозволяє серверам обробляти HTTP-з’єднання, а також з'єднання WebSocket на тому ж порту. Після встановлення зв'язку комунікація переходить на двонаправлений бінарний протокол, який не відповідає протоколу HTTP. Вікіпедія

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.