HTACCESS atšķirības starp serveriem

[spainis]

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?

[daGrevis]

Tad domāsim kā mūsu vajadzībām būs vislabāk. :D

[codez]

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

[spainis]

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 June 10, 2013 by spainis

[codez]

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?

[spainis]

bet kā transport'a layeris websocketiem tāpat tiek izmantots HTTP

 

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

Edited June 10, 2013 by spainis

[codez]

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/