It's part of the HTTP 1.1 protocol.
Specifically, the HTTP 1.1 protocol includes a header called "host:" which specifies which web site on a particular server the client is attempting to access.
So, if snoopy.net and woodstock.org both share 18.104.22.168 and your browser is trying to get content from
http://snoopy.net/doghouse the specific http request would look like:
GET /doghouse HTTP/1.1
If the desired url is
http://woodstock.org/seeds the request would look like
GET /seeds HTTP/1.1
In both cases, there would be a tcp socket between your computer and port 80 of the server. The server would know to get content from /var/www/snoopy.net or /var/www/woodstock.org/ based on the Host header.
There would be other headers for cookies and other stuff like browser type and allowed content, but the "Host" header specifically is what allows the web server to know which virtual web site is desired.
There's more in the RFC2616.
This is also why https sites *must*** have their own IP address -- the ssl key exchange and certificate verification take place prior to the http transaction, so the http server won't know to give out the certificate for "woodstock.org" or "snoopy.net" when it receives an https connection on port 443 of 22.214.171.124.
** in the comments Grawity points out that there are extensions to SSL in the TLS spec that allow the server to know which web site the user as attempting to access, and that most modern web browsers have these extensions, so must is a bit too strong.