When you create a Web application, you actually create a site in IIS. An IIS site has a bindings that contains a separate IP address, a host Header, and a port. IIS uses bindings to determine which site the HTTP request is requesting.
When a user requests a webpage, such as Http://intranet.contoso.com/SitePages/Home.aspx,
The client initiated an HTTP request. The client obtains the IP address of the host (for example, intranet.contoso.com) by querying DNS. The client adds the host name to the Host header field of the HTTP request packet. The client then sends the HTTP request packet to the destination IP address (the default port 80, or other custom port). After IIS receives the request, it parses the packet and discovers that the request is for the Contoso Intranet site.
That is, you can build multiple Web application in SharePoint, which can use the same ports (such as 80), but need different host headers. So that there is no port conflict between these Web application, IIS will determine which Web application should handle the client-initiated request based on the host header.
When IIS finds out which site the client is requesting, it opens a series of operations that eventually return the results to the client. First, IIS looks for the physical path to the Web application, also known as the root directory. When you create a SharePoint Web application, you specify this path. Like what
C:\inetpub\wwwroot\wss\VirtualDirectories\clients.contoso.com80.
For traditional aps.net sites, the real content is stored in this path, but SharePoint is stored in the content database. IIS cannot handle this at this time, but in the Web. config file, the site is specified as SharePoint Web application, so IIS passes this request to SharePoint.
Then, SharePoint resolves this URL to determine which site Collection, which content database. SharePoint obtains this data and returns it back to the user for Iis,iis.
Understanding SharePoint Web Application and IIS Web Sites and HTTP requests