The default behaviour of Microsoft SQL Server is for the default instance, MSSQLSERVER, to listen on port 1433/TCP (ms-sql-s). When the client connects this is what it will connect to if no instance name is specified. If this fails, then it will try to connect to the SQL Browser service, which listens on port 1434/UDP (ms-sql-m). The SQL Browser service will then tell the cient which port the SQL Instance requested is listening on, whether that be a static port or a dynamic port.
If you specify an instance name in your connection string then you can also specify a port but normally the SQL Browser service is replied upon.
SQL Server can use static ports or dynamic ports and these can be configured as described at How to configure SQL Server to listen on a specific port on Microsoft's website.
In clustered SQL instance you can changed from static to dynamic ports but the setting will revert as the checkpointed quorum values will be overwrite you change. Therefore with a clustered instance extra steps are required to make the change permanent, this is documented at How to Change the Dynamic Port of the SQL Server Named Instance to an Static Port in a SQL Server 2005 Cluster on MSDN Blogs.
Common issues with changing ports is further documented on How to assign a static port to a SQL Server named instance - and avoid a common pitfall, again on MSDN Blogs. Another useful MSDN artice is Configure the Windows Firewall to Allow SQL Server Access.
The range that SQL Server uses for Dynamic Port allocation is not 100% clear to me, however I believe it uses the standard Dynamic or Private port range as documented by IANA in RFC 6335, which is ports 49152 to 65535, a range of 16,384 (214) ports.
Note that the names in brackets are the IANA Service Names, these are defined at IANA.