Message queues vs sockets
The two are totally different in the sense that;
Socket allows connection between clients who know themselves whiles (eg between a client and a backend service or between backend services).
Message queue mostly acts as an interface between different backend services in a message-driven system. The services don't need to know whom they are communicating with except the Message broker (eg, rabbitMQ, activeMQ, Kafka). This makes sure that messages are not lost even if one of the services is down. Immediately the service comes up, the Message broker sends the message to the consumer.
The two are incomparable, as they represent different layers. It's like comparing a relational database to a file on a disk or comparing a house to a brick (i.e. certainly you need files to build databases and bricks to build houses, and sometimes all you need is a file or a brick, but that does not make them comparable).
Messaging queue is a piece of software that glues senders and receivers so that they can communicate without knowing much about each other (they both need to know about the queue, of course) and do not need to implement networking code, handling failure, routing one message to many receivers etc. The system works even if senders and receivers are never alive at the same time, as queues also serve as a temporary storage for undelivered messages. Aside from that, queues can provide additional services, like authorization, transactions etc.
A socket connection is a low-level network abstraction that says: "currently two programs can send data over a network to each other, at least until connection breaks for some reason". So yes, usually a messaging queue will use a socket connection to work across a network.
By the way: MDB (Message Driven Bean) that you mention is not a message queue (just like JDBC isn't a databasae). It's an API for consuming transactional messages. They may come from a queue, but they don't have to.