Those aren't directories. They're
contexts.
In
J2EE, a webapp context is the part of a URL that tells the server
which of the possibly many webapps that the server manages will actually be picked to satisfy a URL request.
For better or worse, the syntax of a URL and the syntax of a filesystem path closely resemble each other, but there's one very critical difference.
In a filesystem path, the path precisely locates a
file at the end of a chain of directories. This file can then be opened, read/written, deleted, or whatever (allowing for access rights).
In a URL, the path means mostly just
patterns that various stages of the URL request-handling process can cue on. Once matched, the associated subsystem can do pretty much anything it wants. Generate a PDF, copy a resource out of the WAR, locate a file or database somewhere outside the WAR and do whatever it wants to with it. And, of course, generate HTML response.
The first stage pattern match is done on the client side, where the client breaks out the basic network characteristics. For example, "https://coderanch.com:1234/". The "http" is the protocol ID, and it tells the client to send the request in HTTP (unencrypted) form. The "www.coderanch.com" is the Internet domain hostname, resolved by the client's URL-to-IP-address resolution mechanisms, which often include a "hosts" file, DNS, and possibly other lookup mechanisms. These days, smart clients will also play around with the domain name, so that if you simply type "coderanch", it will try "coderanch.com" and "www.coderanch.com".
The ":1234" determines the server port to address. DNS lookup returns only IP addresses, not port numbers. The conventional port number is defined as part of the protocol. For example, for http, it's conventionally port 80. Putting a ":1234" after the hostname overrides this to port 1234.
Having selected the specific target server and port, the client then opens a connection and sends the URL request. On the
Tomcat side, Tomcat parses the URL, looking at what immediately follows the server definition, matching it against the list of deployed webapp contexts. You've defined a context named "subdir", so Tomcat looks for a "subdir" context. This context is often created (automatically) when you slap a WAR named "subdir" into the TOMCAT_HOME/webapps directory, but Tomcat has a lot more flexibility than that - the WAR can be located in other places and its context name and WAR name don't have to be the same.
Now Tomcat knows what webapp you're interested in, so it further scans the URL looking for matches on the rest of the URL path. It matches up the name "/servlet" against its list of servlet patterns generated from the "subdir" webapp's WEB-INF/web.xml, and that's how it knows to send the URL request to that particular servlet. If it doesn't find a match, Tomcat has a default servlet that gets the unmatched requests, and this is how static content and directory listings get returned to the client.
A webapp context can, in theory be anything that looks like (but isn't!) a filesystem path fragment. Providing your filesystem uses Unix-style path syntax. No Windows backslashes here! So, for example you
could have a context like "/subdir/wednesday/morning". But it's not very common. In fact, you're more likely to see a proxy ahead of Tomcat that translates a URL such as "http://subdir.coderanch.com" into the Tomcat URL "https://coderanch.com/subdir".
The root context is a special context named simply "/". Because all context names are prefixed with "/", therefore, the root context is only considered if no other deployed context path matches. Also, since you cannot name a directory under TOMCAT_HOME to be "/", the default WAR mapping for "/" is TOMCAT_HOME/webapps/ROOT.
