У веб-сокетов есть пара существенных недостатков с точки зрения масштабируемости, которых избегает ajax.Поскольку ajax отправляет запрос / ответ и закрывает соединение (.. или вскоре после этого), если кто-то остается на веб-странице, он не использует ресурсы сервера при простое.Веб-сокеты предназначены для потоковой передачи данных обратно в браузер, и для этого они связывают ресурсы сервера.Серверы имеют ограничение на количество одновременных соединений, которые они могут держать открытыми одновременно.Не говоря уже о том, что в зависимости от вашей серверной технологии они могут связать поток для обработки сокета.Таким образом, веб-сокеты предъявляют более ресурсоемкие требования к обеим сторонам на соединение.Вы можете легко исчерпать все свои потоки, обслуживающие клиентов, и тогда новые клиенты не смогут войти, если множество пользователей просто сидят на странице.Это то, где nodejs, vertx, netty действительно могут помочь, но даже у них также есть верхние пределы.
Также существует проблема состояния нижележащего сокета и написания кода с обеих сторон, которые продолжаютразговор о состоянии, который не имеет отношения к стилю ajax, потому что он не содержит состояний.Веб-сокеты требуют, чтобы вы создали протокол низкого уровня, который решается за вас с помощью ajax.Такие вещи, как сердцебиение, закрытие простаивающих соединений, переподключение на ошибки и т. Д., Жизненно важны сейчас.Это то, что вам не нужно было решать при использовании AJAX, потому что он не имел состояния.Состояние очень важно для стабильности вашего приложения и, что более важно, для здоровья вашего сервера.Это не тривиально.До HTTP мы создали множество TCP-протоколов с отслеживанием состояния (FTP, telnet, SSH), а затем произошел HTTP.И никто больше этого не делал, потому что даже с его ограничениями HTTP был на удивление проще и надежнее.Веб-сокеты возвращают хорошие и плохие протоколы с отслеживанием состояния.Вы узнаете достаточно скоро, если вы не получили дозу этого последнего шага.
Если вам нужна потоковая передача данных в реальном времени, эти дополнительные издержки оправданы, потому что опрос сервера для получения потоковых данных хуже, ноЕсли все, что вы делаете, это взаимодействие с пользователем-> запрос-> ответ-> обновить пользовательский интерфейс, то ajax проще и будет использовать меньше ресурсов, потому что после отправки ответа разговор окончен и дополнительные ресурсы сервера не используются.Поэтому я думаю, что это компромисс, и архитектор должен решить, какой инструмент соответствует их проблеме.AJAX имеет свое место, и веб-сокеты имеют свое место.
Обновление
Таким образом, архитектура вашего сервера имеет значение, когда мы говорим о потоках.Если вы используете традиционно многопоточный сервер (или процессы), где каждое сокетное соединение получает свой собственный поток для ответа на запросы, тогда веб-сокеты очень важны для вас.Таким образом, для каждого соединения у нас есть сокет, и в конечном итоге ОС перестанет работать, если у вас их слишком много, и то же самое относится и к потокам (особенно к процессам).Потоки тяжелее сокетов (с точки зрения ресурсов), поэтому мы стараемся и сохраняем, сколько потоков у нас работает одновременно.Это означает создание пула потоков, который представляет собой фиксированное количество потоков, которое используется всеми сокетами.Но как только сокет открыт, поток используется для всего разговора.Длина этих разговоров определяет, как быстро вы можете переназначить эти потоки для новых входящих сокетов. Длина вашего разговора определяет, насколько вы можете масштабироваться.Однако, если вы используете потоковую передачу, эта модель не подходит для масштабирования.Вы должны нарушить дизайн потока / сокета.
Модель запросов / ответов HTTP делает ее очень эффективной при переворачивании потоков для новых сокетов.Если вы просто собираетесь использовать запрос / ответ, используйте HTTP, он уже создан и намного проще, чем переопределение чего-то подобного в веб-сокетах.
Поскольку веб-сокеты не должны быть запросом / ответом как HTTP и могут передавать данные, если на вашем сервере есть фиксированное количество потоков в его пуле потоков, и у вас есть такое же количество веб-сокетов, связывающих все ваши потоки с активными разговорами.Вы не можете обслуживать новых клиентов!Вы достигли своей максимальной вместимости.Вот где дизайн протокола также важен для веб-сокетов и потоков.Ваш протокол может позволить вам ослабить поток на сокет для каждой модели разговора таким образом, чтобы люди, которые просто сидят там, не использовали поток на вашем сервере.
Вот где приходят асинхронные однопоточные серверы. В Java мы часто вызываемэто NIO для неблокирующих IO.Это означает, что это другой API для сокетов, где отправка и получение данных не блокируют поток, выполняющий вызов.
Так традиционно при блокировке сокетов, когда вы вызываете socket.read () или socket.write (), они ждут, пока данные будут получены или отправлены, прежде чем вернуть управление вашей программе.Это означает, что ваша программа застряла в ожидании данных сокета, чтобы войти или выйти, пока вы не сможете сделать что-либо еще.Вот почему у нас есть потоки, поэтому мы можем выполнять работу одновременно (одновременно).Отправьте эти данные клиенту X, пока я жду данных от клиента Y. Параллелизм - это название игры, когда мы говорим о серверах.
На сервере NIO мы используем один поток для обработки всех клиентов и регистрации обратных вызововполучать уведомления при поступлении данных.Например,
socket.read( function( data ) {
// data is here! Now you can process it very quickly without waiting!
});
Вызов socket.read () будет немедленно возвращен без чтения каких-либо данных, но наша функция, которую мы предоставили, будет вызвана, когда она поступит. Этот дизайн радикально меняет то, как вы строите и разрабатываете свой кодпотому что если вы застряли в ожидании чего-то, вы не сможете получить новых клиентов.У вас есть одна нить, вы не можете сделать две вещи одновременно!Вы должны поддерживать движение этого потока.
NIO, Асинхронный ввод-вывод, Программа, основанная на событиях, так как все это известно, гораздо более сложная конструкция системы, и я бы не стал предлагать вам написать это, еслиВы начинаете.Даже очень старшим программистам очень трудно создавать надежные системы.Поскольку вы асинхронны, вы не можете вызывать API, которые блокируют.Как и чтение данных из БД или отправка сообщений на другие серверы должны выполняться асинхронно.Даже чтение / запись из файловой системы может замедлить работу одного потока и снизить масштабируемость.Когда вы переходите в асинхронный режим, это все время происходит в асинхронном режиме, если вы хотите поддерживать движение одного потока.Вот где это становится сложным, потому что в конечном итоге вы столкнетесь с API, таким как БД, который не будет асинхронным, и вам придется использовать больше потоков на некотором уровне.Таким образом, гибридные подходы распространены даже в асинхронном мире.
Хорошая новость заключается в том, что есть и другие решения, которые уже используют этот низкоуровневый API, который вы можете использовать.NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python и т. Д. Может быть какая-то неясная библиотека для C ++, но, честно говоря, я бы не стал беспокоиться.Серверная технология не требует очень быстрых языков, потому что она связана с IO больше, чем с CPU.Если вы не умеете работать, используйте Java.Он имеет огромное сообщество кода для извлечения, и его скорость очень близка (а иногда и лучше), чем C ++.Если вы просто ненавидите это, используйте Node или Python.