When I implement PBKDF2 in a server and client, it is my understanding (could be way wrong, sorry), that the server keeps the encrypted/hashed password in the database, and the user sends his or her password over the net and then it is checked by the server for validity.
This is basically correct. When setting up an account the user sends user and pass to the server. The server stores user and PBKDF2(pass) and then discards pass. When logging in the server looks up against the user column and compares PBKDF2(pass_as_submitted) to the value stored when the account was set up. If they match, the user is authenticated.
Do I just depend on the networking library or SSL to protect this information?
In the sort of situation you're talking about, yes.
Would it be wise to perform an SHA2 hash on the password client side, and then send that to the server and then check the sha2 has against the PBKDF2 hash?
No. The problem here is you're just changing the thing you're keeping from the user's password to a hash of the user's password. It's still known to an attacker who can read the database.
(There are reasons this is marginally better than knowing the password, most particularly in case of password reuse. However, these do not justify such an approach.)
It's worth pointing out as well that SHA2(password) will not match PBKDF2(password).
What kinds of these things are done normally by the professionals?
First, use TLS (aka SSL). Having a good, encrypted connection between client and server is first priority. For a website, you should use TLS on every page, not just when sending the password. At the very least it must be used on the login page and on the request that receives username and password information.
Your TLS connection should be set up properly: it should use HSTS if appropriate (and it's a website). It should avoid outdated algorithms (only support TLS 1.1+ if possible). It should use appropriate cipher modes.
Beyond that, it depends on your use case. Perhaps it's worth implementing two factor authentication - be it using TOTP or SMS codes or similar. Perhaps you should be looking at logins without passwords, for example using client-side TLS certificates or OAuth2 tokens. Maybe you should use an existing authentication library like Kerberos. Maybe you need to look at password policies to ensure users are setting good passwords or pass phrases.
These questions are complex and depend on your use case. Thinking about them is the big first step most people don't take. Using PBKDF2 is a great start but there's no universal answer. If possible, get an expert to do your security analysis. If not, open source plus some promo can often get people to look at it. Worst case scenario, read up on security, check out the OWASP Top 10 and think about every part of the system. Where possible use existing libraries made by experts. If you have to roll your own, you're probably doing it wrong.
