Tomcat is not a file server, so when you "request a file", what you are actually doing is sending a URL to a URL processor which is programmed to translate the URL into a server-local filesystem path, open the file at that path location, and copy the bytes in that file to the HttpResponse output stream which is sent back to the client. What the client does with those bytes depends on what it was configured to do with them. The bytes in an image file, for example, would usually be rendered into a browser window as an image. Generic data requests might result in the browser opening/creating a client-side file and copying the bytes into that file - in other words, a "File Download".
Usually, a "file copy" webapp function won't read the entire file into server RAM, it will read in slices of the file to a byte buffer, copy the buffer to the HTTP output stream, then repeat until all bytes in the file have been copied. However you can write a copy operation however you like.
There's a generic copy function built into J2EE appservers. When a URL comes in, the appserver attempts to match it against the URL patterns defined in WEB-INF/web.xml. If a match is made, the corresponding application servlet is passed the request. If a match is not made and the URL ends with ".jsp", the appserver attempts to locate a file whose path and name match the JSP path component of the URL, and if a resource is found at that location in the WAR, the JSP is compiled and executed. If the URL does NOT end in ".jsp", the URL is used to locate a resource, but the resource is simply copied to the HTTP output stream, and how much (if any) server RAM is used to do that depends on how the server logic was written.
Just for completeness, I should add that the JSP and general copy built-in rules have an additional qualification, which is that the WEB-INF directory and its sub-directories are excluded from the default resource locating rules.
An IDE is no substitute for an Intelligent Developer.