A client-first virtual server accepts traffic, waits for the first data from the client and then makes a load balancing decision (selects a pool and node). It connects to the selected node (server) and shuttles data back and fro between the client and the server.
For more details, take a look at the document: Server First, Client First and Generic Streaming Protocols.
The SSL passthrough virtual server type is a slightly specialized version of the client-first virtual server. It forwards SSL-encrypted data without any modification, but with two key differences:
You can use an SSL Session ID persistence class with an SSL passthrough virtual server. This persistence class identifies when a new SSL session is established by a server, and pins future connections that use that session to the same server. This technique is used to improve performance. An SSL session identifies the encryption key and connection state; using persistence with the session ID allows clients to re-use previously-negotiated SSL credentials, so the compute-intensive RSA operation does not need to be repeated. Not using this technique will decrease the capacity of your server farm and increase latency.
Note: many clients (browsers) routinely renegotiate their SSL session every few minutes to reduce the opportunity to sniff large quantities of data that use the same key, so SSL session ID persistence is not appropriate to pin client sessions to the same server. Because you cannot inspect the encrypted application data (to accurately identify user sessions), you would need to use IP address persistence for this purpose.
SSL Passthrough allows you to use a Stingray-specific hack to the SSL protocol that prepends the connection with data that identifes the client IP address and port. This is an alternative to the 'X-Cluster-Client-Ip' header that Stingray adds to plaintext HTTP connections. This capability is disabled by default, and only functions if the destination node is another Stingray Traffic Manager; check the Stingray Product Documentation (keys 'ssl_enhance' and 'ssl_trust_magic') for more details.
None of the ssl TrafficScript functions operate with an SSL Passthrough virtual server.If you need to inspect, persist or modify the data in an SSL connection, or you want to centralize the SSL decryption, then you should terminate and decrypt the SSL connection on Stingray Traffic Manager. This is easy to do; start with an existing SSL Passthrough service and apply the 'SSL Decrypt a Service' wizard to apply the correct configuration: