Welcome to the JavaRanch, Jerry!
The following is a long post, but it should answer a lot of questions.
The first thing to know is that when a client (web browser) wants to talk to a server (such as Tomcat), the domain name isn't the primary (or even necessary) information that it uses.
Actual communications to a webapp server requires knowing 2 things: 1) the server's IP address and 2) the TCP port being used. The IP address must be a public address if you want the server to be visible world-wide. For LAN-only use you can use one of the private IP addresses such as 192.168.10.3.
Domain Name Services (DNS) is the "telephone book" of the Internet. It's what takes a user-friendly servername such as www.mousetech.com and returns the IP address 96.90.14.153. Note that DNS
only knows IP addresses. The port number is another matter.
DNS is actually linked into a core OS networking system called the "resolver". DNS names can be resolved to IP addresses via quite a few different mechanisms, although the most common ones are the "hosts" file (/etc/hosts in Unix/Linux) and via a DNS server. In Linux, there's a file named /etc/resolv.conf which defines what resolvers are to be used and in what order to use them. Windows has similar mechanisms, but they've been known to move around a bit, and I don't remember what's current there.
A fully-qualified domain name points to the IP of a specific server. Its form is "hostname.domain.tld", where the Top-level domain (tld) is one of the well-down top domains (.com, .au, .net and so forth) and the lower-level domains are secondary. In some cases, you have a second-level domain like ".co.uk". Then there's
your domain, which is unique to you within the selected upper-level domain(s) because you paid for that right. And finally, there's the hostname, which allows multiple servers to have different IP addresses within your domain, if you like. For example, mail.mousetech.com, www.mousetech.com. These servers may be different services on one box or may be different boxes (or VMs).
Now we get to the Hidden Knowledge. By convention, web servers usually have a hostname of "www". This is so common that when a resolver is given just a domain name without hostname (for example, coderanch.com), the first thing that's attempted is a resolution of "www.coderanch.com". Likewise, different Internet apps use a convention of Well-Known Ports. For http, the Well-Known port is 80, for https, it's 443.
Tomcat's default settings are for http to serve from port 8080 and https to serve from 8443. So you have 2 choices if you don't want to have explicit port numbers in your URLs: 1) put a proxy in front of Tomcat so that a client can address port 80, but the proxy (technically, it's a Reverse Proxy) can forward to Tomcat's port 8080, or 2) reconfigure Tomcat to listen on port 80 instead of/in addition to port 8080.
Port numbers below 4096 are "magic" in many OS's, meaning that not just any app can listen there. So to get Tomcat listening on port 80, you not only have to change the server.xml file, you have to run Tomcat as a super-user (root or administrator). That's a potential security hazard, which is one of the reasons why Tomcat is commonly proxied.
Although there are a lot of proxy options, two of the most popular are Apache httpd and Nginx. Linux users can also fake it using IPTABLES port remapping. I think the popular Squid proxy server can do the job as well, although Squid's primary usage is as a Forward Proxy.
I find Nginx to be an efficient and easy-to-configure proxy. Apache's advantage is that it allows hosting non-Java webapps (in PHP, Python, Perl, C, whatever) in addition to acting as a Tomcat frontend. Apache has presently 3 proxy mechanisms: mod_proxy, mod_proxy_ajp and mod_jk. Mod_proxy is the recommended one. Mod_ajp works with mod_proxy to use the ajp connector to Tomcat's port 8009 (mod_proxy does straight HTTP to port 8080), And mod_jk is an older option that also connects to Tomcat port 8009 and may (?) have some options for clustering Tomcat that mod_proxy does not.
In any case, you write a proxy rule(s) that determine how the proxy server will receive and forward incoming URLs. You don't generally need mod_rewrite to do proxying, although mod_jk isn't capable of directly targeting Tomcat webapps, so you may need to do a rewrite in addition to the proxying.
OK, now on to Tomcat itself. Tomcat is a webapp server capable of hosting mulltiple web applications. The way you determine
which application you will be talking to is via its URL
context. In many cases (depends on app configuration), that context will correspond to the directory name of the exploded webapp (WAR). By default, if you drop a WAR file into the TOMCAT_HOME/webapps folder, Tomcat will unzip (explode) it into a directory of the same name and use that name as its context. Once exploded, the original WAR file will be ignored (even if you update it!

)
So for
https://coderanch.com:8080/forums, you'd expect to find a TOMCAT_HOME/webapps/forums folder containing the exploded WAR files.
There's also a ROOT context, which is where the Tomcat default webapp lives. It's attached to "https://coderanch.com:8080/". Since "/" isn't a valid file/directory name, the corresponding TOMCAT_HOME/webapps folder is named ROOT. Standard Tomcat distributions come with ROOT and admin webapps pre-installed.
Now let's connect the dots.
First, the client requests
https://coderanch.com/forums/tomcat/post.jsp (not really, but this is just an example). Their resolver returns 204.144.184.130. The client then opens a TCP network connection to 204.144.184.130 port 80 and pushes the request (URL, headers, attachments, and so forth) to that destination.
Now we're sitting with a copy of Apache at your server (www.coderanch.com), and it contains the following mod_proxy definitions:
The ProxyPass translates the incoming request from port 80 and forwards to the local port 8009, translating the text HTTP data to the binary AJP tunnel format (you could have kept it text and forwarded to
http://localhost:8080 without AJP also).
The ProxyPassReverse handles responses from Tomcat and ensures that outgoing responses reflect the public URL and not Tomcat's internal URLs.
Incidentally, you said your ISP is blocking port 80. Check and see if the "block" isn't actually an existing Apache server that you can enlist as your proxy. If they're really blocking it, then they don't want you doing your own hosting and
you should looks for an ISP that is more accommodating. Unfortunately, DNS has no way to tell clients to use an alternate port, so their requests WILL either target port 80 or have to include an explicit port number. Tomcat and Apache cannot help.
One final caution: When using a reverse proxy, be very careful. Taiwan is FULL of would-be spammers who can and will leverage your proxy as a spam gateway (you can see this in the Tomcat logs as URLs with an explicit port "25" in them).
And another refinement. I used the example URL
https://coderanch.com/forums" with an explicit context (webapp) path in it. What if you want simply "http://forums.coderanch.com"?. Using mod_proxy, that's as easy as this:
You would define an Apache VirtualHost for forums.coderanch.com and a DNS definition so that forums.coderanch.com would have its own IP address defined.