Сокет на стороне клиента.io без узла.сервер js

использовать сокет.io на стороне клиента, обычно мы запускаем узел.JS server и идите так:

<script src="/socket.io/socket.io.js"></script>

или с определенным портом:

<script src="http://localhost:3700/socket.io/socket.io.js"></script>

вопрос:

необходимо ли использовать node.сервер js для обслуживания socket.io.js ?

...или это возможно

сделайте локальную копию socket.io.js вместо того, чтобы идти на сервер каждый раз, когда нам нужен сокет.Ио?


как, мы идем посмотреть источник и скопировать все мы получили от источника из тега ,

вставить и сохранить его как socket.io-local.js так что в следующий раз мы используем:

<script src="socket.io-local.js"></script>

будет работать ?


обновления

Спасибо за большой ответ каждого,

Я спрашиваю это, потому что в случае, если я участвую, у меня на самом деле нет доступа к серверу:

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

поэтому мне придется подумать, как обойти тот факт, что у меня нет сервера для меня.

от того, что я тестировал, кажется, это работает, но я действительно не знаю, что происходит за сценой.

3 ответов


вы можете хоста розетка.io клиентская библиотека в любом месте и вытащить его на страницу. Тем не менее, это почти наверняка не работает С вашим Java-сервером.

чтобы понять, почему, вам нужно понять, какой сокет.io действительно делает за кулисами; клиентская библиотека-это только небольшая его часть.

гнездо.io фактически определяет и реализует свой собственный протокол для связи в реальном времени между a браузер и сервер. Он делает это таким образом, что поддерживает несколько транспорта: если, например, браузер или прокси-сервер не поддерживает WebSockets, он может вернуться к опроса.

какой сокет.клиент ввода-вывода на самом деле делает это:

  1. делает XHR GET запрос /socket.io/1. Сервер отвечает идентификатором сеанса, настроенными тайм-аутами и поддерживаемыми транспортами.
  2. клиент выбирает лучший транспорт, который поддерживает браузер пользователя. В современных браузерах, он будет использовать WebSockets.
  3. если WebSockets поддерживаются, он создает новый WebSocket для инициирования подключения WebSocket (HTTP GET с Upgrade: websocket заголовок) на специальный URL -/socket.io/1/websocket/<session id>.
  4. если WebSockets не поддерживаются браузером или не удается подключиться (в дикой природе есть много посредников, таких как прокси, фильтры, устройства сетевой безопасности и т. д., которые не поддерживают Запросы WebSocket), библиотека возвращается к длинному опросу XHR и делает запрос XHR на /socket.io/1/xhr-polling/<sesion id>. Сервер не отвечает на запрос, пока не будет доступно новое сообщение или не будет достигнут тайм-аут, после чего клиент повторяет запрос XHR.

гнездо.серверный компонент io обрабатывает другой конец этого беспорядка. Он обрабатывает все URL-адреса в разделе /socket.io/, настройка сеансов, разбор обновлений WebSocket, фактически отправка сообщений и куча других счетоводство.

без всех услуг, предоставляемых сокетом.io server, клиентская библиотека довольно бесполезна. Он просто сделает запрос XHR на URL-адрес, который не существует на вашем сервере.

Я предполагаю, что ваш Java-сервер просто реализует протокол WebSockets. Вы можете подключиться непосредственно к нему с помощью API WebSocket, предоставляемые браузером.

это возможно что ваш сервер реализует сокет.io протокол – для этого есть несколько заброшенных Java-проектов – но это маловероятно. Поговорите с разработчиком вашего сервера, чтобы узнать, как именно он реализовал " сервер сокетов."


автономная сборка сокета.io-клиент автоматически предоставляется сокетом.сервер ввода-вывода Как /socket.io/socket.io.js. В качестве альтернативы вы можете служить файл socket.io-client.js найдено в корне этот репозиторий.

https://github.com/LearnBoost/socket.io-client

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

я обнаружил, что при установке вы можете обслуживать сгенерированный клиентский скрипт из сокета.io by чтение файла /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js. Поэтому мой модуль добавляет прослушиватель для своего собственного URL-адреса, и когда он обслуживает мой пользовательский клиентский скрипт, он также служит сокету.IO клиентский скрипт с ним. Виола! Только одна ссылка на скрипт для пользователей моего модуля:)


хотя это технически возможно, я не понимаю, зачем вам это делать. Если вы обеспокоены уменьшением данных, которые идут по проводу, это изменение фактически не будет делать ничего, кроме нескольких символов, сохраненных в shorter src тег. Простое изменение местоположения файла JS на сервере фактически не улучшит производительность - JS должен быть отправлен.

правильное кэширование (какой сокет.IO имеет) вернет 304 не измененный (и не повторно отправляет файл JS каждый раз, когда вы загрузить страницу).