Сбой рукопожатия socket.io в Google https

Question

Сбой рукопожатия socket.io в Google https

У нас есть следующие настройки для балансировки нагрузки Google HTTPS.

Два интерфейса: 1. HTTP-трафик на статический IP-адрес 2. HTTPS-трафик на тот же статический IP-адрес (DNS настроен на доменное имя)

Правила хоста и пути Все собираются на бэкэнд

Один бэкэнд: с протоколом HTTP с привязкой сеанса к IP-адресу клиента

Внутренний экземпляр имеет приложение MEAN, работающее на порте 3000.

Из нашего клиентского приложения мы можем подключиться к внутреннему приложению, используя доменное имя loadbalancer. Но у нас также есть функция чата с socket.io

Для сокетного соединения мы не смогли использовать доменное имя loadbalancer. Выдает ошибку 400.

Если мы пытаемся использовать внутренний IP-адрес напрямую для подключения через сокет, он работает, но если клиент работает по протоколу HTTPS, это создает другую проблему, поскольку внутренним сервером является http.

Документация Google гласит, что loadbalancer поддерживает веб-сокеты по умолчанию. Так что не уверен, что происходит. Все остальные примеры, которые я вижу, являются относительно старыми и, по-моему, неактуальными. Любая помощь приветствуется. Благодарю.

4

google-cloud-platform https google-compute-engine socket socket.io

Источник

NunnaS 20 апр '18 в 00:54

1 ответ

Другие вопросы по тегам google-cloud-platform https google-compute-engine socket socket.io

Md Daud Walizarif 10 авг '20 в 23:19 2020-08-10 23:19 · Answer 1 · 2020-08-10 23:19

Для WebSockets через балансировщик нагрузки HTTP(S) тайм-аут серверной службы (ответа) является пределом времени жизни соединения (соединения WebSockets прерываются после настроенного тайм-аута ответа). Следовательно, таймаут должен быть установлен на максимальное время, в течение которого соединение WebSocket будет оставаться открытым. Соответствующее значение тайм-аута ответа зависит от используемого вами приложения.

Вам нужно будет провести несколько экспериментов, чтобы найти подходящий тайм-аут ответа, чтобы избежать закрытия тайм-аута соединения (немного увеличьте его значение и повторите попытку; например, если 30 секунд недостаточно, попробуйте 40 секунд,50 секунд и т. Д.).

Найдено на StackOverflow.

MFC 05 апр '19 в 11:37 2019-04-05 11:37 · Answer 2 · 2019-04-05 11:37

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

Комментарий @jfriend00 послужил провидением для моего плебейского мнения.

На конечной точке развертывания nodejs я должен передать порядок транспорта следующим образом:

  app = express()
  server = require('http').Server(app)# {key: tlskey, cert: tlscert},app)
  io = require('socket.io')(server, { transports: ['websocket', 'polling'], cookie:true, secure: true })
  app.use bodyParser.urlencoded(extended: true)

Что происходит? Я указываю в socket.io явно использовать транспорт websocket. Если это не помогло, пожалуйста, вернитесь к опросу. Поскольку HTTPS GCE Ingress устанавливает некоторые заголовки (выполняет некоторые обновления заголовков до wss), мне нужно secure:true флаг, чтобы соответствовать им на моем бэкэнде. Без вышеуказанного error 400 происходит на стороне клиента.

Служба работает как NodePortс Generate_Cookie,

Если это все еще не удается, попробуйте просто transports: ['polling']это самый простой протокол.

Вот ссылка на socket.io doc