WebSockets через 3G-соединение

Я играл с Socket.io, node.js и WebSockets, все из которых я могу нормально работать с Wi-Fi-соединением.

Однако, когда я тестирую приложение, поддерживающее WebSocket, через 3G-соединение (например, на моем iPhone), похоже, что возврат к длинному опросу является единственным работоспособным решением.

При подключении Socket.io соединение перестает работать с "Недопустимым соединением WebSocket или Origin not verified", прежде чем вернуться к длительному опросу.

Я не знаю, предназначены ли WebSockets для работы над 3G - кто-нибудь успел заставить их работать так? Я пробовал несколько разных методов, и все, похоже, терпят неудачу, что заставляет меня думать, что я пытаюсь сделать невозможное.

Ответ 1

Некоторые операторы мобильной связи, как известно, известны тем, что устанавливают совершенно пропущенные прозрачные прокси, которые вы вынуждены проходить. Это настоящее раздражение, с которым рабочая группа WebSocket столкнулась с этим с самого начала. Протокол разработан, чтобы гарантировать, что он будет очень быстро работать в присутствии таких продуктов, чтобы ваше приложение сразу могло вернуться к другим методам. Если вы обнаружите, что для выявления аномалии и отступления требуется много времени, сообщите об этом в рабочую группу hybi в IETF, чтобы можно было диагностировать и устранить проблему.

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

Ответ 2

Как говорит Вилли Тарро, он разбил прозрачные прокси, используемые операторами мобильной связи. Я уверен, что это не исключительно для них (например, брандмауэры корпоративной компании). Вы можете обойти это, используя другой номер порта (по крайней мере, у мобильных операторов). Что-то, кроме порта 80. Использование SSL также может работать, но я еще не пробовал его.

Тогда у вас возникнут проблемы с фолками за брандмауэрами, блокирующими все внешние порты 80 и 443.

Напишите свое приложение для веб-приложений, чтобы перевернуть между портом 80 и другим портом при каждой попытке подключения, и ваш хост прослушивает эти два порта. Тогда у вас есть хороший шанс подключиться к серверу. Используйте порт iptables REDIRECT, если вы используете linux для одновременного прослушивания двух портов.

Ответ 3

Вы можете использовать протокол Server-Sent Events вместо WebSockets.

SSE является более простым, совместимым с HTTP и может проходить через прокси.

Ответ 4

Имели те же ошибки с плохим соединением веб-сокета в определенных мобильных сетях. Решил их:

(1) перемещение портов: перемещение по серверу и клиенту для подключения к серверу SSL (порт 443)

(2) ping keep-alive: отправка периодических "пинговых" сообщений с клиента на сервер каждые X секунд и ожидание возврата "понга" с сервера. Если сервер не дает "понг" обратно в течение Y секунд, перезапустите соединение на клиенте.

реализация (1) даст вам большую часть пути.