I'm answering this based on the TLS v1.2 certificate based client authentication feature. Other protocols may vary in the details.
Can anybody tell me what is being sent from the user's side for
getting authentication from the server?
The overhead to a normal handshake consists only of the user's certificate (+ intermediate certificates eventually, really uncommon) and the signature over some previsouly exchanged data.
Generally, how and what is sent from the user so that the server can
identify the user?
During the course of a standard TLS handshake a bunch of data is exchanged. This includes the server's certificate, random nonces of both parties and cipher suite negotiation data.
If the server requests a client certificate (which will also include a list of the valid CAs it's going to accept), the client will sign the whole transcript up to this point and will send the signature and the certificate to the server. The inclusion of the nonces prevent re-use of the signature, the inclusion of the server's certificate prevents out-of-context use of the signature and the cipher suite signature prevents downgrade attacks.
How is certificate based authentication able to replace password based
authentication, and how exactly does it work?
The server receives the signature and the certificate. It can then verify the correctness of the signature using the public key embedded in the certificate. If the signature is valid, the server knows that the client has the private key belonging to the certificate. As the server can choose the trustworthy CAs himself (including himself), he can trust the CA to have bound the correct public key to the correct person. So he knows that only the person ownging the certificate could have signed this handshake and thereby the client is the person owning the certificate.
This directly authenticates the handshake to the server and there's no need to subsequently send a password for the sake of authentication.