Вопрос по html5, network-protocols, javascript, websocket, ajax – В каких ситуациях длинный / короткий опрос AJAX предпочтительнее HTML5 WebSockets?

291

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

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

При исследовании длинных / коротких опросов я наткнулся на HTML5 WebSockets. этоseems легко реализовать, но я не уверен, есть ли какие-то скрытые недостатки. Например, я думаю, что WebSockets поддерживается только определенными браузерами. Есть ли другие недостатки WebSockets, о которых я должен знать?

Поскольку кажется, что обе технологии делают одно и то же, в каких типах сценариев предпочтение будет отдаваться одному другому? В частности, сделали ли HTML5 WebSockets AJAX длинным / коротким опросом устаревшим, или есть веские причины предпочесть AJAX над WebSockets?

Ваш Ответ

3   ответа
490

WebSockets, безусловно, будущее.

Длинный опрос - это грязный обходной путь, который предотвращает создание соединений для каждого запроса, как это делает AJAX, но длинный опрос был создан, когда WebSockets не существовало. Теперь из-за WebSockets, длинный опрос уходит.

WebRTC обеспечивает одноранговую связь.

Я рекомендую учитьсяWebSockets.

Comparison:

of different communication techniques on the web

AJAX - requestresponse. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection. Supported in all major browsers.

Long poll - requestwaitresponse. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic. support chart (full) | wikipedia

WebSockets - clientserver. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted. support chart (very good) | wikipedia

WebRTC - peerpeer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required. support chart (medium) | wikipedia

Server-Sent Events - clientserver. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia

Advantages:

Основное преимуществоWebSockets на стороне сервера, это то, что это не HTTP-запрос (после рукопожатия), а правильный протокол связи на основе сообщений. этоenables you to achieve huge performance and architecture advantages, Например, в файле node.js вы можете использовать одну и ту же память для разных соединений с сокетами, чтобы каждый из них мог обращаться к общим переменным. Следовательно, вам не нужно использовать базу данных в качестве точки обмена в середине (например, с AJAX или Long Polling с таким языком, как PHP). Вы можете хранить данные в ОЗУ или даже сразу же переиздавать их между сокетами.

Security considerations

Люди часто беспокоятся о безопасности WebSockets. Реальность такова, что это не имеет большого значения или даже делает WebSockets лучшим вариантом. Прежде всего, с AJAX, есть более высокий шансMITM, поскольку каждый запрос является новым TCP-соединением, которое проходит через интернет-инфраструктуру. С WebSockets, когда он подключен, гораздо сложнее перехватывать между ними с дополнительно принудительной маскировкой кадров при передаче данных от клиента к серверу, а также с дополнительным сжатием, которое требует больших усилий для проверки данных.All modern protocols support both: HTTP and HTTPS (encrypted).

P.S.

Remember that WebSockets generally have a very different approach of logic for networking, больше похоже на игры в реальном времени было все это время, а не как http.

@bagz_man Длинный опрос - это "хакерский" использование технологии для достижения результатов, которые технология не допускала по определению и не являлась стандартной альтернативой. Причина, по которой существует длинный опрос, заключается именно в том, что WS не делала, период.
Длинный опрос не является грязным обходным путем и отличается от webSocket. Эти два предназначены для использования в другом сценарии.
Это не о совместимости само по себе. Самое главное, что он собирается полностью переосмыслить, как происходит общение. Поскольку RESTful API работают с шаблоном Request & gt; Response, двунаправленная связь здесь будет бессмысленной. Поэтому попытка использовать WebSockets для запроса RESTful API - это немного странная попытка, и она вообще не видит никакой выгоды. Если вам нужны данные из RESTful API, но в режиме реального времени, вы создаете API WebSockets для передачи данных, которые будут работать с двунаправленной связью, такой как WebSockets. Вы пытаетесь сравнить вещи под углом, что они не сопоставимы :)
@moka: Cloudflare 'sfree-tier будет поглощать длительную атаку 400 Гбит / с. Может ли ваш кошелек поглотить счет AWS? Также AWS и Cloudflare имеют противоположные взгляды, когда дело касается жалоб на ваше происхождение. Это просто необходимо помнить, пока мы обсуждаем компромиссы. :)
Привет @pithhelmet, все зависит от серверного программного обеспечения (язык / технология). WebSocket является слоем поверх TCP, и существует множество способов реализации потоков TCP. Современные веб-серверы используют архитектуру, основанную на событиях, и очень эффективны с пулами потоков. Какие технологии вы используете? Node.js использует события за кулисами для ввода-вывода и события с одним потоком в контексте выполнения, так что это удивительно эффективно. Использование потока для каждого соединения - очень неэффективно с точки зрения оперативной памяти (1 Мб + на поток), а также процессора, поскольку эти потоки будут просто простаивать или, что еще хуже, - бесконечный цикл проверки данных.
7

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

не на героку они пока не поддерживаются
Я понимаю, что эта тема немного устарела, но ... WebSockets не может быть лучшим ответом для всех двунаправленных коммуникаций. Недавно я заметил, что документация по поддержке веб-сокетов в Spring 4 предполагает, что WebSockets лучше подходят для перемещения больших объемов данных или низкой задержки. Если они неприменимы или не являются приоритетными, то я полагаю, что они предлагают использовать длинные опросы. Я не знаю полного оправдания этой точки зрения, я просто решил, что ребята из Spring знают, о чем они вообще говорят.
WebSockets поддерживаются каждым сервером ... Вам просто нужно установить node.js или что-то подобное.
Немного подправил, чтобы объяснить, что да, любой сервер будет поддерживать WebSockets. Однако, если вы используете хостинг, вы не сможете их использовать.
@ Stoney кроме того, что вам нужно было бы настроить websocket на сервере (обработчики и т. Д.) Нет просто никакой причины использовать Long polling over websocket. Websocket намного быстрее (с низкой задержкой) и позволяет серверу «общаться». клиенту без запроса клиента. В настоящее время я использую сигнализатор (одна из лучших реализаций websocket, когда-либо сделанных на мой взгляд - он работает на клиенте и сервере и позволяет клиенту вызывать методы на сервере и на сервере на клиенте, как будто нет разницы) на каждом сайт, который я делаю - динамическая загрузка контента, бездонные страницы и т. д.
11

Одна из конкурирующих технологий, которую вы пропустили, - это отправленные сервером события / источник события.Что такое Long-Polling, Websockets, Server-Sent Events (SSE) и Comet? имеет хорошее обсуждение всех этих. Имейте в виду, что некоторые из них проще, чем другие, интегрировать на стороне сервера.

Из всего этого, что бы вы предложили изучить? somdow
У меня был успех с длительным опросом, единственный трюк (для него и других технологий) - не связывать серверный поток. Если вы не используете асинхронный код сервера, он не будет масштабироваться.
@somdow Maksims-Mihejevs хорошо ответили на ваш вопрос в первых двух параграфах своего ответа. Используйте веб-сокеты.

Похожие вопросы