|
Ah, I can't see any decent way to handle this. I mean, you could do a
modulo kind of distribution to servers, based on source IP, but I expect
that would have serious problems balancing.
After a TCP connection is set up (necessary of course to send the cert)
it is very difficult and would be a really nasty hack to migrate it to
another machine. You have to pick your real server on connection
establishment and stick to it. Otherwise, you'd have to do really gross
stuff with buffering, rewrite lots of packets and do overly
complex computations on the fly. Very very bad for performance, bad for
abstraction, and lots of code work.
-Tymm
On Fri, 25 Jun 1999, Wensong Zhang wrote:
> Date: Fri, 25 Jun 1999 23:09:37 +0800
> From: Wensong Zhang <wensong@xxxxxxxxxxxx>
> To: Lars Marowsky-Bree <lmb@xxxxxxxxx>
> Cc: Joseph Mack <mack@xxxxxxxxxxx>, linux-virtualserver@xxxxxxxxxxxx,
> psysadmin <psysadmin@xxxxxxxxxxx>
> Subject: Re: LVS and Apache-SSL
>
>
>
> Lars Marowsky-Bree wrote:
>
> > On 1999-06-24T15:48:02,
> > Wensong Zhang <wensong@xxxxxxxxxxxx> said:
> >
> > > I tested LVS with servers running Apache-SSL.
> > > LVS uses the VS patch for kernel 2.2.9, and uses
> > > the PCC scheduling. It worked without any problem.
> >
> > However, this was not the point why SSL needs special support.
> >
> > Obviously, anything which is based on a TCP connection from the client to
> > the
> > server will most likely work very well.
> >
>
> SSL is a little bit different.
>
> In use, the client will send a connection request to the server. The
> server will return a signed digital certificate. The client then
> authenticates the certificate using the digital signature and the
> public key of the CA.
>
> If the certificate is not authentic the connection is dropped. If it is
> authentic then the client sends a session key (such as a) and encrypts
> the data using the servers public key. This ensures only the server can
> read it since decrypting requires knowing the server private key.
> The server sends its session key (such as b) and encrypts with its
> private key, the client decrypt it with server's public key and get b.
>
> Since both the client and the server get a and b, they can generate
> the same session key based on a and b. Once they have the session key,
> they can use this to encrypt and decrypt data in communication. Since the
> data sent between the client and server is encrypted, it can't be read by
> anyone else.
>
> Since the key exchange and generating is very time-consuming, for
> performance reasons, once the SSL session key is exchanged and
> generated in a TCP connection, other TCP connections can also
> use this session key between the client and the server in the life-span
> of the key.
>
> So, we have make the connections from the same client is sent to
> the same server in the life-span of the key. That's why the PCC
> scheduling is used here.
>
> Have I made it clear?
>
> Wensong
>
>
> >
> > It is just that we can use the SSL session ID to do better than that and
> > separate the requests all comeing in from the same proxy into multiple
> > sessions and schedule them to different machines, so not all of aol.com hits
> > a single https server.
> >
> > Mind you I have no idea how to implement this, since this would require the
> > load balancer to do scheduling based on in-band data, which we currently
> > don't
> > do at all, do we?
> >
> > Sincerely,
> > Lars Marowsky-Brée
> >
> > --
> > Lars Marowsky-Brée
> > Network Management
> >
> > teuto.net Netzdienste GmbH - DPN Verbund-Partner
>
>
>
>
|
