the web server serves a very minor role and is installed on a regular PC
Well, that's not a good decision. Web is stateless, so you don't keep a connection open. If the web server is not on the same server as MSSQL, it should still run on a server, or needing to reconnect with every request becomes a pita, all aspects aside that make it feasible, still.
And you shouldn't take it as challenge to make your web server stateful, the web is stateless by intentional design, not as a design flaw.
Admitted: Someone with web application development experience might say I'm telling bullshit, and isn't even wrong, as the stateless nature of the http protocol doesn't mean that no states are kept. A clear example you experience as a web user is that you only log in once, and then a session is established until you either log out or the session times out. There is a state that's kept, but then it's also not kept up as the state of a desktop application that is the process it is and runs until the user exits or shuts down the computer.
There are mainly two modes of operations regarding sessions: Eithter the login sets a session coookie in the users browser and that is repeatedly sent over to the server with each request so the server can look up what user the request comes from or there's a bearer token, that's likewise sent to the server with every subsequent request after the login. The two options are quite well descirbed here:
https://www.criipto.com/blog/session-token-based-authentication
1. I don't think you ever thought about that and now you're at programming the user frontend to that you're not getting all that automatically, as the browser does, but would need to program it into your frontend.
2. These mechanisms keep a state, the user reidentification. Look into the details of the linked article and you see the more recent modern bearer token approach is still described as having a stateless nature. Because every request has to contain the info, session id or bearer token, to know who made that request. There's the oAuth 1.0a scheme where every subsequent request is signed and there's not just a constant value to reassure which user the request is from, the signature uses a key pair mechanism and allows the verification that's a prove of authantic request and not just proving to know a token or session id that could be stolen.
3. Still, most any usual web scripts open and close a database connection for every request, you don't keep a connection open.
Now you can ask, why not keep a connection open that's not even specific to a user but just a general connection to the database server. Well, the way a web request is handled is the PHP script or your web connection script ending, there's no variable kept, no state kept, so what you would need to introduce is a persistent object or process that does so. I doubt you get that much of it, I don't have used web connection myself to know or tell you whether something like that may be foreseen, but it's not the normal nature of a web application to have anything that's kept running aside from the web server itself to receive and forward requests to the single scripts executed that respond and finally close down again.
There's the relativela new concept of web workers, that's a client side (JS) feature, not a server side feature, though. So if you want to keep something up and running that keeps a SQL Server connection the only feasible mechanism you have, I think is running a COM Server EXE on the web server PC in paralle to IIS that could be started like an OLE automatable appication could be started and that you "connect" to by a web connection script via GetObject() instead of CreateObject(), that would only always instanciate a new COM object instance. The stability of that depends on how stable that COM Server would be and the security of it, too, how you enable any process to attach to it that way or require some means of authentication, too. And overall, you're going through more hoops, just to have an SQL connection handle kept open. Which is the reason for 3, again, server side code just is there to answer one request with a response and then "die".
What's commonly saved are the responses, ie. you cache a response when it is potentially the same result for a time out, if no forever, and cache it, there's a lot about cahing mechanism, but you don't keep open a database connection for convenience. What's happening on that level is what I also already described in my firs post, the connection pooling, making it faster to reconnect.