The server itself is responsible for keeping track of things.
For example, consider one of the most popular types of servers - the web application server.
HTTP is a stateless protocol. That is, instead of connecting for a long-term session, every request is a short-term connection ended by a disconnect until (if!) the client sends another request. Each HTTP request has a standard format. It has a URL, which tells where imside the server the request should be routed. It has a "reply port" assigned at the client side when the incoming port listener accepts the connection and it uses the reply port (which is randomly chosen) to respond to the client with the web response.
In between times, a server such as
Tomcat maintains a pool of identical, but idle threads. When a request comes in, Tomcat parses it, pulls a
thread out of the pool and runs the process-handling (application) code under that thread. The output is sent out via the reply port as a data stream and Tomcat closes the data stream when the end of data has been reached. So, although multiple clients are coming in, each one can be uniquely defined by its return IP/port address.
That takes care of the coarse-grained differentation. All requests coming into a single webapp look the same, however, which is we we piggyback session information to the request data if we want to operate statefully. Generally either a cookie or an appendage to the incoming URL identifies which session (user) is being handled by that particular request thread. So that all the users of a particular webapp don't get all jumbled together.
As far as SSL goes, there's also the question of negotiation of the encryption tokens and protocols. Ideally, you don't want to re-negotiate on each request, but I've never looked into details. It Just Works. I can tell you that in order to cut some of the overhead on establishing connections, even unencrypted requests are often managed by a connection "keep-alive" mechanism, but I'm not sure how much of the basic keep-alive handles SSL and how much (if any) is managed by some other mechanism.
A good place to find out is to look through the "RFC" documentation. RFCs are the official documents defining the Internet's protocols.