Basicamente: o navegador inclui o nome de domínio na solicitação HTTP, para que o servidor web saiba qual domínio foi solicitado e possa responder de acordo.
Solicitações HTTP
Veja como sua solicitação HTTP típica acontece:
O usuário fornece uma URL, no formulário http://host:port/path
.
O navegador extrai a parte do host (domínio) da URL e a converte em um endereço IP, se necessário, em um processo conhecido como resolução de nomes . Essa tradução pode ocorrer via DNS, mas não precisa (por exemplo, o hosts
arquivo local em sistemas operacionais comuns ignora o DNS).
O navegador abre uma conexão TCP com a porta especificada ou o padrão é a porta 80, nesse endereço IP.
O navegador envia uma solicitação HTTP. Para HTTP / 1.1, é assim:
GET /path HTTP/1.1
Host: example.com
(O Host
cabeçalho é padrão e requerido no HTTP / 1.1. Ele não foi especificado na especificação HTTP / 1.0, mas alguns servidores o suportam de qualquer maneira.)
A partir daqui, o servidor da web possui várias informações que podem ser usadas para decidir qual deve ser a resposta. Observe que é possível que um único servidor da Web seja vinculado a vários endereços IP.
- O endereço IP solicitado, do soquete TCP
- O endereço IP do cliente também está disponível, mas isso raramente é usado - às vezes para bloqueio / filtragem
- A porta solicitada, do soquete TCP
- O nome do host solicitado, conforme especificado no
Host
cabeçalho pelo navegador na solicitação HTTP.
- O caminho solicitado
- Quaisquer outros cabeçalhos (cookies, etc.)
Como você deve ter notado, a configuração de hospedagem compartilhada mais comum atualmente coloca vários sites em um único endereço IP: combinação de portas, deixando apenas Host
a diferenciação entre sites.
Isso é conhecido como host virtual baseado em nome no Apache-land, enquanto o Nginx os chama de nomes de servidor em blocos de servidor e o IIS prefere o servidor virtual .
E o HTTPS?
HTTPS é um pouco diferente. Tudo é idêntico até o estabelecimento da conexão TCP, mas depois disso um túnel TLS criptografado deve ser estabelecido. O objetivo é não vazar nenhuma informação sobre a solicitação.
Para verificar se o servidor realmente possui esse domínio, o servidor deve enviar um certificado assinado por terceiros confiáveis. O navegador comparará esse certificado com o domínio solicitado.
Isso apresenta um problema. Como o servidor sabe qual certificado do host (site) enviar, se precisar fazer isso antes que a solicitação HTTP seja recebida?
Tradicionalmente, isso era resolvido com um endereço IP (ou porta) dedicado para cada site que requer HTTPS. Obviamente, isso se torna problemático quando começamos a ficar sem endereços IPv4.
Digite SNI (indicação do nome do servidor). O navegador agora passa o nome do host durante as negociações do TLS, para que o servidor tenha essas informações com antecedência suficiente para enviar o certificado correto. No lado do servidor, a configuração é muito semelhante à forma como os hosts virtuais HTTP são configurados.
A desvantagem é que o nome do host agora é passado como texto sem formatação antes da criptografia e é essencialmente uma informação vazada. Isso geralmente é considerado uma troca aceitável, considerando que o nome do host é normalmente exposto em uma consulta DNS de qualquer maneira.
E se você solicitar um site apenas por endereço IP?
O que o servidor faz quando não sabe qual host específico que você solicitou depende da implementação e configuração do servidor. Normalmente, há um site "padrão", "catchall" ou "fallback" especificado que fornecerá respostas a todas as solicitações que não especificam explicitamente um host.
Este site padrão pode ser seu próprio site independente (geralmente mostrando uma mensagem de erro) ou pode ser qualquer um dos outros sites no servidor, dependendo da preferência do administrador do servidor.
Host:
cabeçalho. No caso de hospedagem compartilhada, o servidor da Web pode ser configurado pelo provedor para lidar com isso de diferentes maneiras (por exemplo, ter um padrão, redirecionar para o provedor etc.).