Shared web hosting can be accomplished in two ways: name-based and IP-based, although some control panels allow a mix of name-based and IP-based on the one server.
In name-based virtual hosting, also called shared IP hosting, the virtual hosts serve multiple hostnames on a single machine with a single IP address.
When a web browser requests a resource from a web server using HTTP/1.1 it includes the requested hostname as part of the request. The server uses this information to determine which web site to show the user.
In IP-based virtual hosting, also called dedicated IP hosting, each virtual host has a different IP address. The web server is configured with multiple physical network interfaces, or virtual network interfaces on the same physical interface. The web server software uses the IP address the client connects to in order to determine which web site to show the user. The primary reason for a site to use a dedicated IP is to be able to use its own SSL certificate rather than a shared certificate.
Name-based virtual hosts have some disadvantages:
They do not properly support secure websites (HTTPS). All name-based virtual hosts using the same IP address must share the same digital certificate. This is because the SSL/TLS handshake takes place before the hostname is sent to the server. Thus the server doesn’t know which encryption key to use when the connection is made. An extension to the TLS protocol, part of RFC 3546 – Transport Layer Security (TLS) Extensions, specifies a way for the client to provide the requested host name as part of the handshake, but it is not yet widely implemented. Some of the shared hosting providers require their customers to get Unique IP in order to properly set up HTTPS.
If the Domain Name System is malfunctioning, it is harder to use a name-based virtually-hosted website. Ordinarily, in this case, the user could fall back to using the IP address to contact the system, as in http://192.0.2.0/ (invalid IP for example only). However, the web browser doesn’t know what hostname to send to the server, but a name-based virtual host requires it. In this case, the default web host is sent back to the browser for that IP address. Therefore most hosters offer an alternative access method like http://192.0.2.0/~virtualhostname to provide access in such cases.
They will not work with browsers that do not send the hostname as part of requests. This is true for older HTTP/1.0 browsers that have not retrofitted the host field feature from the HTTP/1.1 protocol. (The “Host” header that distinguishes between various DNS names sharing a single IP address was optional in HTTP/1.0; it is mandatory in HTTP/1.1, issued in 1999 as RFC 2616.) Since nearly every webbrowser that is currently used supports the HTTP/1.1 protocol and thus also virtual hosting, this is not a real issue.
Improperly configured file permissions with shared file systems might give other (compromised) users or processes system-wide access to these files, such as credential files for database access or modification of existing files.