To begin, you should probably look up the OSI model to understand where these "options" stand, because you seem confused about what they are.
For one, sockets are just the programmatic way you deal with a connection, any connection. So, that's not really an "option" because it's just the general term for any network connection, from a software point of view. This makes your "option 2" basically meaningless.
Second, the transport protocol for virtually everything on the internet is TCP/IP. The only other general option is UDP/IP, which is not reliable enough for most tasks (mostly just for specific high-bandwidth tasks on local closed networks). And that is, of course, still pretty low on the OSI model levels, i.e., it's not a solution to your problem because your problem is at the highest OSI level, the "application" level. So, that makes your "option 4" meaningless too (it's too low-level, as if someone asks "How do I build a house?" and you answer "Use a hammer.").
Third, an http server is just one type of web server among many. And a web server is really just a program that listens for client connections (coming from the web). So, obviously, you need to create a web server, because that's what you said yourself, i.e., to create a C++ application that can be accessed from other computers on the internet: we call that a web server. So, that also makes your "option 3" meaningless by virtue of just being a repetition of your problem statement, and not a solution to it.
So, what you really should be concentrating on is determining which application level protocol you could use or could create that would be appropriate for your intended application.
Mature protocols like HTTP are a blessing and a curse at the same time. They are pretty complex, so they can be hard to understand, let alone implement correctly. So, you would probably opt for an off-the-shelf library to deal with that protocol, but that could be a significant (and large and complex) dependency to introduce into your project. But you do get the benefit of a more robust protocol, with easy integration of security as well (e.g., HTTPS). You might want to look at HTSQL for a database specific HTTP-based protocol.
Another option is to just create your own custom and simple protocol. This does not need to be very complex if your tasks are pretty simple. For example if all you want to do is relay database queries, then your protocol could be as simple as just containing the SQL queries.
And finally, there are also a number of libraries out there that implement what is called RPC (Remote Procedure Call), which is a way to seamlessly call a function that gets executed by another program on the another computer (e.g., server). This allows you to essentially remove the protocol from the equation as it's all taken care of by the RPC library. On the server application, you just publish the functions you want to expose, and on the client side, you just establish the connection with server and call the functions as you would any other normal function.
I would say that these are really your three main options: use an existing general protocol like HTTP; create your own simple protocol; or, use a RPC (or similar) library. Which option to choose really depends on the details of the specific tasks that you need to get accomplished between the client and the server.