You are right that you need to make sure that your session ID's can not be brute forced. The trick is to make the session ID long and random (and when I say random, I mean [securely random](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator)). If the session ID comes together with a user ID it would be harder to brute force, since the attacker would need to guess ID's for one user at a time. That means the session ID could be somewhat shorter. But since it doesn't cost you anything to have a long session ID, there is no need to try to shorten it.

If you use 64 bit session ID's and a billion users, an attacker would have to make on average 2<sup>64</sup>/10<sup>9</sup> * 1/2 ≈ 10<sup>10</sup> guesses before she gets one right. Without causing any performance problems you could double it and use 128 bit session ID's, and you will have a ridiculous margin. 

So, there is no harm in sending the user ID together with the session ID. But if you use long enough session ID's, there isn't really a need. If you do opt for the user ID solution, remember this:
 
 * Obviously, you need to actually check the user ID server side, and not blindly trust the client.
 * Assume the hacker knows all user ID's. That means that the session ID still needs to be long and random.