How Web.xml work

Question 1: Where does the web.xml fit into things (when is it used/called, and where is it called from)?
Code sample 1:

    <servlet>
    <servlet-name>qrst</servlet-name>
        <display-name>qrst Servlet</display-name>
    <servlet-class>
        org.springframework.web.servlet.DispatcherServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

What does the above snippet do (or, what does it cause to happen)? At some point in my web app qrst.jsp gets used; is it the DispatcherServlet that calls qrst.jsp using the servlet name? Else what is the significance of the servlet name? What is load on startup?
Code sample 2:

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /someLocation/some-servlet.xml
    </param-value>
</context-param>

Links or explanation of what the above does? I can see from looking at the XML file that it contains bean definitions and I do understand what beans are and how they are used, but I don't know any other details about this and would like to.
Code sample 3:

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <display-name>DWR</display-name>
  <servlet-class>
        org.directwebremoting.servlet.DwrServlet
</servlet-class>
    <init-param>
        <param-name>classes</param-name>
        <param-value>
            somepackage.someclass
        </param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
</servlet>

Sol:

Servlets are JavaEE's idiom for answering HTTP requests. You program the behavior of your application in a Servlet which will respond to a request.
Tomcat is a Servlet container, which means you deploy your application in Tomcat and it will manage all the communication infrastructure for you: it accepts connections, manages database connections(*) and will call upon your servlets to handle incoming requests.
web.xml is part of any JavaEE application, not Spring. Your code sample 1 declares that your app will use an instance of class org.springframework.web.servlet.DispatcherServlet to handle incoming requests.
Although servlets are the basic foundations for JavaEE development, it is not advised to create your own; instead, with Spring, you create MVC controllers. Then the DispatcherServlet will call upon these controllers to handle the requests. It's just another indirection (but a very powerful one!)

is it the DispatcherServlet that calls qrst.jsp using the servlet name?

Not directly. It's just a coincidence that your servlet and the JSP file have the same name.

What is loaded on startup?

Your code sample 2 instructs the DispatcherServlet to load the beans from file /someLocation/some-servlet.xml. If there are controller beans in this file and according to how you configured the url mapping, beans from this file will answer the incoming requests. See the reference.

I believe those init-param elements are just parameters that get set in the servlet's java class

The init-param elements in web.xml are for the servlet class.

The web app somehow "knows" when an AJAX (dwr) call is happening versus when the web app is being loaded for the first time (when its loading for the first time it should use qrst.jsp). How does it know this?

Missing from the question are either the <servlet-mapping> element (found in web.xml), or the url mappings (found in the spring files). These are responsible for deciding whether an URL should be handled by the dispatcher servlet or the dwr servlet.
For instance, with an servlet mapping like below:

<servlet-mapping>
    <servlet-name>qsrt</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>dwr</servlet-name>
    <url-pattern>*.dwr</url-pattern>
</servlet-mapping>

Then all URLs ending in .do will be answered by the dispatcher servlet, and those ending with .dwr will be handled by the dwr servlet. Here's where the names of the servlets are important.
JSP files are a different story. The container will simply use them to handle a URL ending in *.jsp. Do not create your onw servlet mapping for URLs ending in *.jsp. This will only cause headaches. This is probably unspecified behavior.
Edit:

However, the URL in the browser's address bar always looks the same: it would always invoke the qrst servlet

Then it is possible that your servlet-mapping is so broad (something like: <url-pattern>/*</url-pattern>) that it will handle anything you throw at the server and never give a chance for the other servlets to handle it.
Last but not least, when working with DWR or any Ajax technology, install the HttpFox extension for Firefox so you can monitor the Ajax calls of your application.

 Ref: https://stackoverflow.com/questions/5837122/can-someone-explain-the-spring-web-xml-file

http://shengwangi.blogspot.in/2015/08/understand-webxml-in-spring-mvc-project.html 

How does the DispatcherServlet, Resolver and Controllers interact?

When sending a request to your application the following happens:

• The request arrives at your server (e.g. Tomcat). Depending on the context path in the url the server decides to which application the request belongs.
• Depending on the url and the servlet mapping in the web.xml file of your application the server knows which servlet should handle the request.
• The request is passed to the servlet filter chain which can modify or reject requests
• The servlet takes control over the request. In case of your Spring application the spring Dispatcherservlet receives the request. Now Spring kicks in
• The request is processed by mvc intercepters preHandle methods
• The request is mapped to a controller based on the url. The corresponding controller method will be called.
• Your controller is processing the request. Many different responses can be returned in controllers (jsp, pdf, json, redirects, etc.). For now i assume you want to render a simple jsp view. Result of the controller are two things: a model and a view. The model is a map that contains the data you want to access later in your view. The view at this stage is most of the time a simple string containing a view name.
• Registered springs mvc interceptors can kick in again using the postHandle method (e.g. for modifying the model)
• The 'view' result of your controller is resolved to a real View using a ViewResolver. Depending on the ViewResolver the result can be jsp page, a tiles view, a thymeleaf template or many other 'Views'. In your case the ViewResolver resolves a view name (e.g. 'myPage') to a jsp file (e.g. /WEB-INF/jsp/myPage.jsp)
• The view is rendered using the model data returned by your controller
• The response with the rendered view will be passed to mvc interceptors again (afterCompletion method)
• The response leaves the dispatcher servlet. Here ends spring land.
• The response passes servlet filters again
• The response is send back to client

 ref: https://stackoverflow.com/questions/14015642/how-does-the-dispatcherservlet-resolver-and-controllers-interact