HTTPS is HTTP over TLS (formerly SSL). TLS is stateful, so it probably won't scale as well as regular HTTP. Also, I think it will render HTTP caches useless.
Something I'm not clear on: isn't HTTPS a stateful protocol (unlike HTTP)? If so, won't that have scalability implications? I assumed that was the reason most retail sites make you shop in HTTP, and then switch over to HTTPS for the payment step.
I believe SSL (TLS) is stateful, though, so HTTPS would be too. The browser would keep the TLS socket connection open for multiple HTTP requests, which would tie up resources on the server.
TLS/SSL can cache the session in order to actually improve performance and scalability. Otherwise you'd have to redo the exchange each time you made a request.
My guess is that the level of caching you'd want TLS/SSL to do is dependent on what kind of content you're serving, the usage patterns of visitors, etc. As an example, Facebook has relatively long user sessions, and would benefit greatly from caching and just refreshing the session keys. Something like Google search, where a user session may only last a few seconds and a couple requests... maybe not so useful. I'm not familiar (off the top of my head) with any in-depth studies on this.
HTTPS connections work just the same as HTTP connections. Connect, perform the request, disconnect.
You can send multiple requests over the same connection for either HTTP or HTTPS via the use of KeepAlive. There's nothing special about HTTPS connections which make them more stateful than HTTP.
