WebSocket-Verbindung fehlgeschlagen: Fehler beim WebSocket-Handshake: Unerwarteter Antwortcode: 400

Ich versuche, Socket.io mit Angular zu integrieren, und ich habe Schwierigkeiten, eine Verbindung von der Clientseite zum Server herzustellen. Ich habe andere verwandte Fragen durchgesehen, aber mein Problem tritt lokal auf, daher gibt es keinen Webserver in der Mitte.

So sieht mein Servercode aus:

const app = express();
const server = http.createServer(app);
const io = require('socket.io').listen(server);

io.on('connection', function(socket) {
  socket.emit('greet', { hello: 'Hey, Mr.Client!' });

  socket.on('respond', function(data) {
    console.log(data);
  });
  socket.on('disconnect', function() {
    console.log('Socket disconnected');
  });
});

Ich lade die clientseitigen JavaScript-Dateien mit Grunt in der folgenden Reihenfolge:

dist: {
    src: [
        public/bower_components/angular/angular.min.js,
        ...
        public/bower_components/socket.io-client/dist/socket.io.min.js,
        public/bower_components/angular-socket-io/socket.min.js,
        ...
    ]
}

Dann in meinem Controller:

function MyController($scope) {

    let socket = io.connect(window.location.href);
    socket.connect('http://localhost:3000');
    socket.on('greet', function(data) {
      console.log(data);
      socket.emit('respond', { message: 'Hello to you too, Mr.Server!' });
    });

    ...
}

Vor der eigentlichen Verwendung der btford/angular-socket-io Bibliothek möchte ich sicherstellen, dass ich eine korrekte Verbindung herstellen kann, aber ich erhalte die folgende Fehlermeldung in der Konsole:

Das Interessante ist, dass, wenn ich den Node.js-Serverprozess neu starte, er es schafft, die Nachricht zu senden, aber Polling anstelle von Websockets verwendet.

Ich habe alle möglichen Optionen im Socket.connect-Aufruf ausprobiert, aber nichts hat funktioniert.

Jede Hilfe wäre willkommen.

UPDATE (30.12.2016):

Ich habe gerade festgestellt, dass Websockets teilweise funktioniert. Ich sehe eine 101 Switching Protocols-Anforderung in der Chrome-Entwicklerkonsole. Die einzigen Frames, die ich dort sehe, sind jedoch die engine.io-Protokollpakete (Ping, Pong). Meine Anwendungs-Socket-Nachrichten fallen jedoch aus irgendeinem Grund immer noch auf die Abfrage zurück …

Problem gelöst! Ich habe gerade herausgefunden, wie ich das Problem lösen kann, aber ich würde trotzdem gerne wissen, ob dies ein normales Verhalten ist oder nicht.

Es scheint, dass, obwohl die Websocket-Verbindung korrekt hergestellt wird (angezeigt durch die 101 Switching Protocols-Anforderung), immer noch standardmäßig Long-Polling verwendet wird. Die Lösung war so einfach wie das Hinzufügen dieser Option zur Socket.io-Verbindungsfunktion:

{transports: ['websocket']}

Der Code sieht also letztendlich so aus:

const app = express();
const server = http.createServer(app);
var io = require('socket.io')(server);

io.on('connection', function(socket) {
  console.log('connected socket!');

  socket.on('greet', function(data) {
    console.log(data);
    socket.emit('respond', { hello: 'Hey, Mr.Client!' });
  });
  socket.on('disconnect', function() {
    console.log('Socket disconnected');
  });
});

und auf dem Client:

var socket = io('ws://localhost:3000', {transports: ['websocket']});
socket.on('connect', function () {
  console.log('connected!');
  socket.emit('greet', { message: 'Hello Mr.Server!' });
});

socket.on('respond', function (data) {
  console.log(data);
});

Und die Nachrichten erscheinen jetzt als Rahmen:

funktionierende Websockets

Dies Github-Problem wies mich in die richtige Richtung. Danke an alle, die mitgeholfen haben!

Das hat bei mir mit Nginx, Nodeserver und Angular 4 funktioniert

Bearbeiten Sie Ihre Nginx-Webserver-Konfigurationsdatei wie folgt:

server {
listen 80;
server_name 52.xx.xxx.xx;

location / {
    proxy_set_header   X-Forwarded-For $remote_addr;
    proxy_set_header   Host $http_host;
    proxy_pass         "http://127.0.0.1:4200";
    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection "upgrade";
}

Die derzeit akzeptierte Lösung ist irreführend.

Laut dem amtliche DokumentationHinzufügen der transports: [ 'websocket' ] Option entfernt effektiv die Möglichkeit, auf Long-Polling zurückzugreifen, wenn die Websocket-Verbindung nicht hergestellt werden kann. Diese Option macht socket.io in erster Linie so robust, weil es sich an viele Szenarien anpassen kann.

In dem speziellen Fall, in dem man sich ausschließlich auf Websockets verlassen möchte, direkt über die WebSocket API ist empfohlen.

In anderen Fällen (angeblich die meisten Benutzer) ist dies höchstwahrscheinlich ein Problem mit der Reverse-Proxy-/Serverkonfiguration.

Die offizielle Dokumentation schlägt abhängig von Ihrer Umgebung Folgendes vor:

NginX-Konfiguration

http {
  server {
    listen 3000;
    server_name io.yourhost.com;

    location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;

      proxy_pass http://nodes;

      # enable WebSockets
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }
  }

  upstream nodes {
    # enable sticky session based on IP
    ip_hash;

    server app01:3000;
    server app02:3000;
    server app03:3000;
  }
}

Apache HTTPD-Konfiguration

Header add Set-Cookie "SERVERID=sticky.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<Proxy "balancer://nodes_polling">
    BalancerMember "http://app01:3000" route=app01
    BalancerMember "http://app02:3000" route=app02
    BalancerMember "http://app03:3000" route=app03
    ProxySet stickysession=SERVERID
</Proxy>

<Proxy "balancer://nodes_ws">
    BalancerMember "ws://app01:3000" route=app01
    BalancerMember "ws://app02:3000" route=app02
    BalancerMember "ws://app03:3000" route=app03
    ProxySet stickysession=SERVERID
</Proxy>

RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) balancer://nodes_ws/$1 [P,L]
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /(.*) balancer://nodes_polling/$1 [P,L]

ProxyTimeout 3

HAProxy-Konfiguration

listen chat
  bind *:80
  default_backend nodes

backend nodes
  option httpchk HEAD /health
  http-check expect status 200
  cookie io prefix indirect nocache # using the `io` cookie set upon handshake
  server app01 app01:3000 check cookie app01
  server app02 app02:3000 check cookie app02
  server app03 app03:3000 check cookie app03

Auch lesenswert Dies beim Aktualisieren von Verbindungen in HAProxy.

Weitere Einzelheiten finden Sie unter dem Link zur offiziellen Dokumentation oben.

BEARBEITEN:

Lack (Quelle hier)

sub vcl_recv {
    if (req.http.upgrade ~ "(?i)websocket") {
        return (pipe);
    }
}

sub vcl_pipe {
    if (req.http.upgrade) {
        set bereq.http.upgrade = req.http.upgrade;
        set bereq.http.connection = req.http.connection;
    }
}

Ich habe dies gelöst, indem ich die Transporte von „websocket“ auf „polling“ geändert habe.

   var socket = io.connect('xxx.xxx.xxx.xxx:8000', {
      transports: ['polling']
   });

Gemessen an den Nachrichten, die Sie über Socket.IO senden socket.emit('greet', { hello: 'Hey, Mr.Client!' });es scheint, dass Sie die verwenden hackathon-starter Kesselplatte. Wenn ja, könnte das Problem daran liegen express-status-monitor Modul erstellt seine eigene socket.io-Instanz, wie folgt: https://github.com/RafalWilinski/express-status-monitor#using-module-with-socketio-in-project

Du kannst entweder:

1. Entfernen Sie dieses Modul

2. Übergeben Sie Ihre socket.io-Instanz und den Port als websocket wenn Sie die erstellen expressStatusMonitor Beispiel wie unten:

   const server = require('http').Server(app);
   const io = require('socket.io')(server);
   ...
   app.use(expressStatusMonitor({ websocket: io, port: app.get('port') })); 
   

Hatte das gleiche Problem, meine App ist hinter nginx. Durch diese Änderungen an meiner Nginx-Konfiguration wurde der Fehler behoben.

location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}

Ich hatte die gleichen Probleme, ich verfeinerte die Eingabe des virtuellen Apache2-Hosts und hatte Erfolg.

Hinweis: Auf dem Server hatte ich erfolgreich den Port 9001 installiert und funktionierte ohne Probleme. Diese Richtlinie für Apache2 nur keine Relevanz mit nginx, diese Antwort für Liebhaber von Apache2 + Etherpad.

<VirtualHost *:80>
  ServerName pad.tejastank.com
  ServerAlias pad.tejastank.com
  ServerAdmin [email protected]

  LoadModule  proxy_module         /usr/lib/apache2/modules/mod_proxy.so
  LoadModule  proxy_http_module    /usr/lib/apache2/modules/mod_proxy_http.so
  LoadModule  headers_module       /usr/lib/apache2/modules/mod_headers.so
  LoadModule  deflate_module       /usr/lib/apache2/modules/mod_deflate.so

  ProxyVia On
  ProxyRequests Off
  ProxyPreserveHost on

    <Location />
        ProxyPass http://localhost:9001/ retry=0 timeout=30
        ProxyPassReverse http://localhost:9001/
    </Location>
    <Location /socket.io>
        # This is needed to handle the websocket transport through the proxy, since
        # etherpad does not use a specific sub-folder, such as /ws/ to handle this kind of traffic.
        # Taken from https://github.com/ether/etherpad-lite/issues/2318#issuecomment-63548542
        # Thanks to beaugunderson for the semantics
        RewriteEngine On
        RewriteCond %{QUERY_STRING} transport=websocket    [NC]
        RewriteRule /(.*) ws://localhost:9001/socket.io/$1 [P,L]
        ProxyPass http://localhost:9001/socket.io retry=0 timeout=30
        ProxyPassReverse http://localhost:9001/socket.io
    </Location>


  <Proxy *>
    Options FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  </Proxy>
</VirtualHost>

Vorab-Tipps: Bitte aktivieren Sie mit Hilfe von a2enmod alle Mods von Apache2

Starten Sie Apache2 neu, um die Wirkung zu erzielen. Aber offensichtlich a2ensite zum Aktivieren der Website erforderlich.