Jump to content
php.lv forumi

HTACCESS atšķirības starp serveriem


eT`
 Share

Recommended Posts

bet, piemēram, ja ir web frontends + web socketu endpoints kur frontends ir, piemeram, python un websocketus handlo node.js, un abiem endpointiem vajaga atrasties zem viena domēna un vienigais, kas mainās ir path daļa(viss pēc /s ir jāsūta uz nodejs), tad ar piposim visu cauri node'u(nav ar tā sliktākā iespēja) vai ari python'am(beats the purpose) uz node.js?

Link to comment
Share on other sites

  • Replies 36
  • Created
  • Last Reply

Top Posters In This Topic

bet, piemēram, ja ir web frontends + web socketu endpoints kur frontends ir, piemeram, python un websocketus handlo node.js, un abiem endpointiem vajaga atrasties zem viena domēna un vienigais, kas mainās ir path daļa(viss pēc /s ir jāsūta uz nodejs), tad ar piposim visu cauri node'u(nav ar tā sliktākā iespēja) vai ari python'am(beats the purpose) uz node.js?

 

Un tu gribi likt tam visam priekšā apache? Apache tak ir webserveris un strādā ar http protokolu un pat izmantojot kaut kādus kreisos websocket pluginus, apache nav paredzēts un pielāgots darbam ar websocket protokolu (pāris meklejumi googlē rāda, ka ar to ir problēma, piemēram, pēkšņi apache sāk vērt ciet konekcijas).

Ja vajadzīgs viens domeins un websocket appa un web apa atrodas atseviški, tad websocketam izveidojam atsevišķu subdomeinu, ieliekam dns ierakstu uz citu adresi un izvietojam websocket serveri uz cita servera.

 

Šeit atkal piebildīšu, ka, piemēram, Play2 FW iebūvētais serveris māk apstrādāt abus protokolus un pats FW māk tos routot

Link to comment
Share on other sites

nu tad vajaga 2 ssl sertifikātus

 

un kāpēc uzreiz apache, ir tak ar nginx, uzliekam timeout'u uz 1d priekš route'a un gatavs

 

un websocket'i nav nekas  vairāk par prastu http pieprasījumu, kuru upgrade'o ar 101 header'i uz tādu, kuru netaisa ciet

Edited by spainis
Link to comment
Share on other sites

un websocket'i nav nekas  vairāk par prastu http pieprasījumu, kuru upgrade'o ar 101 header'i uz tādu, kuru netaisa ciet

 

Http protokols paredz papriekšu nosutīt datus un tad saņemt atbildi, kamēr Websocket protokols paredz daudzu datus sutīšanu un atbilžu saņemšanu.

Http protokolam atbilst tikai Websocket headeris, viss tālākais krīt āra no http protokola.

 

Ja vajadzīgs SSL, tad visdrīzāk Nginx ir viens no risinājumiem, taču principā sanāk, ka šeit Nginx tiek izmantots kā proxy serveris un tādā gadījum, kāpēc neņemt īstu plaši konfigurējamu proxy serveri, piemēram, HAProxy?

Link to comment
Share on other sites

ja izmanto nginx tad ir par vienu serveri mazāk ko konfigurēt :), veiktspējas ziņā atšķirības starp nginx un haproxy nav : https://github.com/observing/balancerbattle

 

Ja aplikācija ir salīdzinoši maza (noslodzes ziņā) un viss (proxy, web apps, websocket apps) ir uz vienas instances, tad visdrīzāk piekrītu, ka nginx būtu vienkāršākais variants. Bet tiklīdz web apps un websocket apps tiek likti uz atsevišķām instancēm un vēl vairāk, ja pēkšņi proxy ir jāpilda arī load balancera funkcijas, tad HAProxy ir labāks par nginx, kaut vai health checku dēļ, bet konfigurācijas dēļ nav atšķirības, jo nāktos konfigurēt 2 nginx versijas (vienu proxy, vienu web) vai HAProxu + Nginx priekš web.

 

Refernecei šeit ir abi apskatitie varianti:

1)Nginx: http://www.exratione.com/2013/06/websockets-over-ssl-with-nodejs-and-nginx/

2)HaProxy + Nginx: http://www.exratione.com/2012/12/websockets-over-ssl-haproxy-nodejs-nginx/

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...