The answer by tim about entropy is perfect on the topic of brute forcing the sessionId.
But note, there are easier ways to steal the session. For example, if you issue the session over HTTPS (authentication) but then bounce back to HTTP, now your session is exposed in clear text. Anything that goes over HTTP can be assumed is screamed out loud and open for everyone who is listening on the line.
A targeted attack may trick a user to click on a HTTP URL to the target website and the attacker eavesdrops until the user clicks on the URL and send the session over HTTP. that's why you should set Secure flag for your session to make sure it is not sent unless over HTTPS.
You can bind the session to IP, but note that many users may share the same IP if they are behind a NAT. So it is not really a great security solution.
Even if you have your entire session over SSL, still vulnerabilities in the browser may allow stealing the session; Cross Site scripting can steal the session. To be secure, you should fix all these issues, but at the end of the day, assume session might get stolen, and think now what?
One advanced solution for Session hijacking is synchronization token; in this way, every time the client browser makes a HTTP request to the server, the server sends back a new random complex enough token to the client as a hidden form field value, and the client must submit this value in the next request as a hidden form value. If the client submits the right session (e.g., stolen from the cookie), but does not have the most recent synch token, then there is something wrong. This solution also prevent cross-site request forgery. If you are over SSL, this solution cannot be broken by man in the middle either.