(I post this answer because I always feel it's important to make the logic right.)
I suggest you take a look at the following sample.
http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html
Admittedly, when carrying out TCP/IP communication, all the necessary information can be provided by the Socket class alone for the sole purpose of communication. No matter it is on server side or client side.
As you can see from the above link, server side use the following code to acquire its own Socket instance. That is, another socket is created on the same server local port and the client port pair.
Then, server use this Socket instance to talk to the client.
And to make the picture complete, below code snippet shows client's Socket instance.
So if Socket can do it all already, why do we still need the ServerSocket?
This is because of the working paradigm of communication over TCP/IP protocol.
When 2 programs talk over TCP/IP, usually one will passively listen/wait on a <IP:port> and the other one will actively connect to it.
So you can see, at this very starting phase of the communication, the 2 sides have very different behaviors. So 2 different classes are used to reflect this difference.
Socket class encapsulates the behavior of the active side. (a.k.a. the client)ServerSocket class encapsulates the behavior of the passive side (a.k.a. the server)
Once the ServerSocket accomplished its listening task and detected an incoming connection, it will accept() it and create a new Socket instance to facilitate the communication.
Similarily, in java.nio package, you will find ServerSocketChannel and SocketChannel classes. And still, they behave like this:
ServerSocketChannel -------------> SocketChannel
accept()
So, to some extent, I agree with @JohnK as he pointed out in the comment, it's more or less just a 6-letter difference.
