В каких ситуациях длинный / короткий опрос AJAX предпочтительнее HTML5 WebSockets?
==================================================================================

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

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

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

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

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

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

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

Я рекомендую учиться[WebSockets](https://caniuse.com/#feat=websockets).

Comparison:

of different communication techniques on the web

**AJAX** - `request` → `response`. 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** - `request` → `wait` → `response`. 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)](https://caniuse.com/#search=ajax) | [wikipedia](https://en.wikipedia.org/wiki/Push_technology#Long_polling)

**WebSockets** - `client` ↔ `server`. 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)](https://caniuse.com/#feat=websockets) | [wikipedia](https://en.wikipedia.org/wiki/WebSocket#Browser_implementation)

**WebRTC** - `peer` ↔ `peer`. 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)](https://caniuse.com/#feat=rtcpeerconnection) | [wikipedia](https://en.wikipedia.org/wiki/WebRTC)

**Server-Sent Events** - `client` ← `server`. 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)](https://caniuse.com/#feat=eventsource) | [wikipedia](https://en.wikipedia.org/wiki/Server-sent_events)

Advantages:

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

Security considerations

Люди часто беспокоятся о безопасности WebSockets. Реальность такова, что это не имеет большого значения или даже делает WebSockets лучшим вариантом. Прежде всего, с AJAX, есть более высокий шанс[MITM](https://en.wikipedia.org/wiki/Man-in-the-middle_attack), поскольку каждый запрос является новым 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.



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



Одна из конкурирующих технологий, которую вы пропустили, - это отправленные сервером события / источник события.[Что такое Long-Polling, Websockets, Server-Sent Events (SSE) и Comet?](https://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet) имеет хорошее обсуждение всех этих. Имейте в виду, что некоторые из них проще, чем другие, интегрировать на стороне сервера.