هل يمكن استخدام Nginx كوكيل عكسي لخادم Websocket الخاص بالخلف؟

Question

نحن نعمل على تطبيق Ruby On Rails الذي يحتاج إلى الاستفادة من Websockets HTML5. في الوقت الحالي، لدينا اثنين من "خوادم" منفصلة حتى يتكلم: تطبيقنا الرئيسي يعمل على Nginx + Passenger، وخادم منفصل باستخدام Pratik Naik's شد عضلي الإطار (الذي يعمل على نحيف) للتعامل مع اتصالات WebSocket.

من الناحية المثالية، عندما يتعلق الأمر بوقت النشر، لدينا تطبيق القضبان قيد التشغيل على Nginx + Passenger، وسيقوم خادم WebSocket خلف Nginx، لذلك لن نحتاج إلى تشغيل خادم Websocket على منفذ مختلف.

المشكلة هي، في هذا الإعداد، يبدو أن Nginx يغلق الاتصالات إلى رقيقة مبكرة جدا. يتم إنشاء الاتصال بنجاح إلى خادم رقيقة، ثم أغلقت على الفور مع رمز استجابة 200. تخميننا هو أن Nginx لا يدرك أن العميل يحاول إنشاء اتصال طويل الأمد لحركة مرور Websocket.

من المسلم به، أنا لست جميعا أضاءت مع تكوين Nginx، لذلك، هل من الممكن تكوين nginx للعمل كوكيل عكسي لخادم Websocket؟ أو هل يجب علي الانتظار ل Nginx عرض دعم لأشياء Handshake Websocket الجديدة الجديدة؟ على افتراض أن وجود كل من خادم التطبيق وخادم Websocket الاستماع على المنفذ 80 هو شرط، قد يعني ذلك أن لدي رقيقة تعمل على خادم منفصل دون Nginx أمام الآن؟

شكرا مقدما على أي نصيحة أو اقتراحات. :)

-يوحنا

Answer 1

لا يمكنك استخدام nginx لهذا حاليا^{ليس صحيحا بعد الآن}, ، لكن أود أن أقترح النظر إلى Haproxy. لقد استخدمتها لهذا الغرض بالضبط.

الحيلة هي وضع مهلة طويلة بحيث لا يتم إغلاق اتصالات المقبس. شيء مثل:

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

إذا كنت ترغب في الخدمة، فتقول إن القضبان وتطبيق شجاع على نفس المنفذ، يمكنك استخدام قواعد ACL للكشف عن اتصال WebSocket واستخدام الخلفية المختلفة. لذلك فإن تكوين واجهة Haproxy الخاص بك سوف تبدو مثل

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

للاكتمال أن تبدو الخلفية

backend cramp_backend
  timeout server  86400000
  server cramp1 localhost:8090 maxconn 200 check

Answer 2

ماذا عن استخدام بلدي nginx_tcp_proxy_module وحدة.?

تم تصميم هذه الوحدة لوكيل TCP العام مع Nginx. أعتقد أنه من المناسب أيضا ل Websocket. وأنا فقط أضف TCP_SSL_MODULE في فرع التطوير.

Answer 3

Nginx (> = 1.3.13) يدعم الآن عكس المواقع الوكيل.

# 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;
    }
}

Answer 4

خارج الصندوق (أي مصادر رسمية) يمكن Nginx إنشاء اتصالات HTTP 1.0 فقط إلى Upstream (= الخلفية)، مما يعني عدم وجود Keepalive هو Possibe: سيقوم Nginx بتحديد خادم Upstream، فتح اتصال به، وكيل، ذاكرة التخزين المؤقت (إذا كنت تريد ) وإغلاق الاتصال. هذا هو.

هذا هو الأطر الأساسية الأساسية التي تتطلب الاتصالات المستمرة بالخلفية لن تعمل من خلال Nginx (لا http / 1.1 = لا يوجد keepalive ولا توجد أجهزة فيديو مساعدة وأعتقد). على الرغم من وجود هذا العيب، فهناك فائدة واضحة: Nginx يمكن أن تختار من العديد من المنقذات (توازن الحمل) والفشل في حيا على قيد الحياة في حالة فشل بعضهم.

تعديل: يدعم Nginx HTTP 1.1 للرجوع إليه وحجبه منذ الإصدار 1.1.4. "Fastcgi" و "الوكيل" المنصوص عليها مدعومة. هنا هو المستندات

Answer 5

بالنسبة لأي شخص يتساءل عن نفس المشكلة، يدعم Nginx الآن رسميا HTTP 1.1 Upstream. انظر وثائق nginx ل "keepalive" و "proxy_http_version 1.1".

Answer 6

ماذا عن Nginx مع وحدة دفع HTTP الجديدة: http://pushmodule.slact.net/. وبعد إنه يعتني بالاتصال شعوذة (حتى يتكلم) أنه قد يقلق المرء مع وكيل عكسي. من المؤكد أنه بديل قابل للتطبيق لميبروكيتس والتي ليست كاملة في المزيج بعد. أعلم أن مطور وحدة دفع HTTP لا تزال تعمل على نسخة مستقرة بالكامل، ولكنها في التطوير النشط. هناك إصدارات من استخدامها في قوالب الإنتاج. لاقتبس المؤلف، "أداة مفيدة باسم مملة".

Answer 7

يمكنني استخدام nginx لعكس الوكيل إلى خادم نمط المذنب مع اتصالات الاقتراع الطويلة ويعمل بشكل رائع. تأكد من تكوين proxy_send_timeout و proxy_read_timeout إلى القيم المناسبة. تأكد أيضا من الخادم الخلفي الخاص بك أن nginx هو موافق لدعم HTTP 1.0 لأنني لا أعتقد أن الوحدة النمطية الوكيل Nginx لا http 1.1 حتى الآن.

فقط لمسح بعض الارتباك في عدد قليل من الإجابات: يسمح Keepalive عميل بإعادة استخدام اتصال بإرسال طلب HTTP آخر. ليس لديه أي شيء يتعلق به مع اقتراع طويل أو عقد اتصالات مفتوحة حتى يحدث حدث ما هو ما يسأله السؤال الأصلي عنه. لذلك لا يهم وحدة وكيل Nginx يدعم فقط HTTP 1.0 التي لا تحتوي على keepalive.