Dnia czwartek, 17 maja 2012 07:07:23 Roberto De Ioris pisze: > > Yes, and this is how people deploy https load balancing using haproxy, > > they > > use tcp mode and source balancing. > > There is patch for nginx that add support for storing SSL sessions in > > memcached, so with session reuse enabled client can send requests to any > > backend server. > > > > [1] http://hezmatt.org/~mpalmer/blog/2011/06/28/ssl-session-caching-in- > > nginx.html > > [2] http://hezmatt.org/~mpalmer/blog/2011/07/24/followup-to-ssl-session- > > caching-with-nginx.html > > [3] http://wiki.nginx.org/3rdPartyModules#Third_party_patches > > The first 2 links have been illuminating for me, thanks. > > I am not an ssl expert, so i will need to invest a bit of time on it if we > want to make something kick-ass.
I'm no expert either and it's just an idea for a possible feature, I'm not rushing anything. Especially that "tcp router" would work differently, since it's plain tcp you can't have hostname header acting as a routing key, when routing plain tcp packets you have no idea where to send them, unless you parse them (but then you are on the http level again, and with ssl you need to setup client session - and you are back to the https router again). So to get our routing key back we could use: listening ip:port -> list of backends mapping (like haproxy), so workers subscribe using fastrouter's listening ip:port instead of domain name. You would start fastrouter using: uwsgi --fastrouter-subscription-server = :2626 --fastrouter-listen 1.2.3.4:443 and workers would have those line in config: subscribe-to = fastrouter_ip:2626:1.2.3.4:443 every client packet that is send to 1.2.3.4:443 would be forwarded to those workers. This way "tcp fastrouter" would work much like current http(s) fastrouter, the only change would be in the way requests are forwarded. Dowside is that we would need unique listening ip:port for each app. Another solution I can think of is the use of SNI [1] to get requested hostname. With SNI enabled clients hostname is sent as plain text along with SSL session request, any modern browser supports that, and IMHO if someone is still using IE6 or FF1 than he has more serious problems than being unable to connect to our web app. We would need to call that "ssl router" since the routing key would only work with SSL connections, but the only change would be the way of extracting hostname - you would need to parse SSL handshake instead of http headers. Disclaimer: I have no idea about technical issues with ideas above, it's just whats on my mind when I think about it. Maybe it's stupid/impossible, don't take my words as anything other than just random thoughts. [1] http://en.wikipedia.org/wiki/Server_Name_Indication Łukasz Mierzwa _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
