Peut nginx être utilisé comme un proxy inverse pour un backend serveur websocket?

Nous travaillons sur Ruby on Rails application qui doit profiter de websockets html5. À l'heure actuelle, nous avons deux "serveurs" pour ainsi dire: notre principale application en cours d'exécution sur nginx+passager, et d'un autre serveur à l'aide de Pratique Naik est Crampe cadre (qui est en cours d'exécution sur Mince) pour gérer les websocket connexions.

Idéalement, lorsque vient le temps pour le déploiement, nous aurions l'application rails en cours d'exécution sur nginx+passager, et le serveur websocket serait mandaté derrière nginx, donc nous n'aurions pas besoin d'avoir le serveur websocket en cours d'exécution sur un port différent.

Problème est, dans cette configuration, il semble que nginx est de fermer les connexions à Mince trop tôt. La connexion est établie avec succès à la Fine serveur, puis immédiatement fermé avec un code de réponse de 200. Notre conjecture est que nginx ne se rend pas compte que le client tente d'établir une connexion websocket trafic.

Certes, je ne suis pas du tout calée avec nginx config, donc, est-il même possible de configurer nginx pour agir comme un proxy inverse pour un serveur websocket? Ou dois-je attendre pour nginx pour offrir un soutien pour le nouveau protocole de transfert websocket des trucs? En supposant que le fait d'avoir à la fois le serveur d'application et le serveur websocket à l'écoute sur le port 80 est une exigence, peut-être que dire que je Mince en cours d'exécution sur un serveur distinct, sans nginx en frontal pour l'instant?

Merci d'avance pour tout conseil ou suggestion. 🙂

-Jean

InformationsquelleAutor John Reilly | 2010-03-10
  1. 26

    Vous ne pouvez pas utiliser nginx pour le moment[il n'est pas vrai non plus], mais je suggère de regarder à HAProxy. Je l'ai utilisé pour exactement cet effet.

    Le truc est de mettre en longs délais d'attente, de sorte que les connexions socket ne sont pas fermées. Quelque chose comme:

    timeout client  86400000 # In the frontend
timeout server  86400000 # In the backend

    Si vous voulez servir le dire rails et des crampes d'application sur le même port, vous pouvez utiliser des règles ACL pour détecter une connexion websocket et utiliser un autre serveur. Si votre haproxy frontend config ressemblerait à quelque chose comme

    frontend all 0.0.0.0:80
  timeout client    86400000
  default_backend   rails_backend
  acl websocket hdr(Upgrade)    -i WebSocket
  use_backend   cramp_backend   if websocket

    Pour l'intégralité du backend ressemblerait

    backend cramp_backend
  timeout server  86400000
  server cramp1 localhost:8090 maxconn 200 check
    • C'est génial, merci! Je n'ai pas utilisé de HAProxy avant, mais j'ai toujours eu l'intention d'apprendre. Regarde comme j'ai une bonne raison de le faire maintenant. 🙂
    • Cette réponse n'est plus vrai (pas étonnant vu que c'est 3 ans). Découvrez @mak réponse plus bas (à l'heure actuelle) pour savoir comment configurer cela nginx >= 1.3.13
    InformationsquelleAutor mloughran
  2. 12

    Comment utiliser mon nginx_tcp_proxy_module module?

    Ce module est conçu pour général TCP proxy avec Nginx. Je pense qu'il est également idéal pour les websocket. Et je viens de l'ajouter tcp_ssl_module dans la branche de développement.

    • Vous pense, mais je n'ai pas testé avec WebSocket?
    • Je ne sais pas si il l'avais testé à l'époque il a fait ce commentaire, mais je peux confirmer que sa TCP proxy n'est désormais explicitement les websockets.
    • Cet article explique comment configurer, tester et utiliser yaoweibin du module hôte Websocket connexions: letseehere.com/reverse-proxy-web-sockets
    • J'ai testé le module et il fonctionne bien. Toutefois, vous devez savoir que si vous prévoyez servir de l'adresse http du contenu avec noeud et nginx sur le port standard 80, alors vous ne pouvez pas utiliser ce module en tant que l'un des deux va utiliser le port 80 et l'autre doit utiliser un port différent. Aller avec haproxy solution (comme décrit par @mloughran) en revanche si c'est votre situation.
    InformationsquelleAutor yaoweibin
  3. 11

    nginx (>= 1.3.13) prend désormais en charge de proxy inverse websockets.

    # the upstream server doesn't need a prefix! 
# no need for wss://or http://because nginx will upgrade to http1.1 in the config below
upstream app_server {
    server localhost:3000;
}

server {
    # ...

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

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_redirect off;
    }
}
    • Bien que cela fonctionne bien pour http, j'ai un problème avec le protocole https. J'ai en quelque sorte 301. J'avais réussi à l'installation de nginx avec websocket sur http mais sur ssl-je obtenir t 301. github.com/websocket-rails/websocket-rails/issues/333 c'est la question que j'ai créé. Laissez-moi savoir si vous pouvez aider. Merci
    InformationsquelleAutor mak
  4. 7

    Hors de la boîte (c'est à dire des sources officielles) de Nginx peut établir que HTTP 1.0 connexions en amont (=backend), ce qui signifie pas de keepalive est possibe: Nginx va sélectionner un serveur en amont, d'ouvrir une connexion à elle, proxy cache (si vous voulez) et fermer la connexion. C'est tout.

    C'est la raison fondamentale de cadres nécessitant des connexions persistantes à l'arrière-plan ne fonctionnerait pas par le biais de Nginx (pas de HTTP/1.1 = pas de keepalive et pas les websockets, je suppose). Malgré cet inconvénient, il y a un avantage évident: Nginx pouvez choisir parmi plusieurs amonts (équilibrage de charge) et le basculement vers vivant dans le cas où certains d'entre eux ont échoué.

    Modifier: Nginx supporte le protocole HTTP 1.1 pour les backends & keepalive depuis la version 1.1.4. "fastcgi" et "proxy" amonts sont pris en charge. Ici c'est les docs

    • Il a obtenu, grâce. Essentiellement, ensuite, ce que j'essaie de faire est actuellement impossible. Peut-être un jour nginx soutiendra HTTP/1.1 keepalives de backends, mais pour l'instant je vais devoir trouver une autre solution. Merci pour la réponse.
    InformationsquelleAutor Alexander Azarov
  5. 5

    Pour tous ceux qui s'interrogent sur la même problème, nginx désormais officiellement compatible avec HTTP 1.1 en amont. Voir nginx documentation "keepalive" et "proxy_http_version 1.1".

    • Oui, mais il ne prend pas en charge les websockets jusqu'à la version 1.3
    • En effet, et il convient de noter qu'il n'a pas fait dans la 1.3 encore ni même si elle sortira. Leur feuille de route permettra de donner quelques informations sur l'état de l'implémentation de Websocket (actuellement prévue pour la 1.3.x): trac.nginx.org/nginx/roadmap
    InformationsquelleAutor Even André Fiskvik
  6. 3

    Comment sur Nginx avec le nouveau HTTP Pousser module: http://pushmodule.slact.net/. Il prend en charge la connexion de jonglerie (façon de parler) que l'on peut avoir à s'inquiéter avec un serveur proxy inverse. C'est certainement une alternative viable pour les Websockets qui ne sont pas entièrement dans le mélange encore. Je sais que développeur de le HTTP Poussez le module est toujours de travailler sur une version stable, mais il est en développement actif. Il existe des versions de celui-ci étant utilisé dans la production de code. Pour citer l'auteur, "Un outil utile avec un nom ennuyeux."

    • Merci, c'est une bonne suggestion. En fait nous avons été en utilisant que très module pour atteindre le serveur de push pour un certain temps, mais maintenant nous sommes désireux de soutenir communication bi-directionnelle... Et depuis nous avons seulement besoin de soutenir les navigateurs webkit pour notre application, nous espérons aller avec un pur websocket approche maintenant. Mais j'apprécie la réponse! 🙂
    InformationsquelleAutor Eric Lubow
  7. 2

    J'utilise nginx pour proxy inverse pour une comète style serveur avec le temps d'interrogation connexions et il fonctionne très bien. Assurez-vous de configurer proxy_send_timeout et proxy_read_timeout aux valeurs appropriées. Assurez-vous également que votre serveur back-end que nginx est la transmission par proxy supporte le protocole http 1.0, car je ne pense pas que nginx du module de proxy http 1.1 encore.

    Juste pour dissiper une certaine confusion dans quelques unes des réponses: Keepalive permet à un client de réutiliser une connexion pour envoyer une autre requête HTTP. Il n'a rien à voir avec le temps d'interrogation ou de détenir des connexions ouvertes jusqu'à ce qu'un événement se produit qui est ce que la question initiale était de savoir. Donc, il n'est pas question de nginx du module de proxy prend uniquement en charge le protocole HTTP 1.0 qui n'ont pas de keepalive.

    InformationsquelleAutor Mark Maunder