Os servidores mantêm apenas um site?


80

Pelo que entendi, o DNS vincula o nome de domínio ao endereço IP do servidor em que o site está armazenado, isso significa que cada servidor pode conter apenas um site? Caso contrário, como a chamada do endereço IP do servidor saberá qual site eu quero se houver muitos no mesmo servidor?


13
A Wikipedia tem uma boa introdução ao Shared Web Hosting . Se você digitar http: // <IP_ADDR> / no seu navegador, a solicitação HTTP não terá um domínio dentro do 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.).
Jedi

Eu cliquei em links que quebram com mensagens como "este servidor nunca / atualmente não hospeda o site que você está procurando".
Jesvin Jose

1
Caso você esteja procurando uma maneira de executar vários aplicativos em um único servidor - digamos que você tenha dois aplicativos MyApp e YourApp nas portas 8001 e 8002, respectivamente. Você pode ter dois balanceadores de carga ou proxies de aplicativos em: myapp.com e yourapp.com. Faça com que eles recebam solicitações nas portas padrão (80/443) e encaminhem-nos para os servidores reais nas portas 8001 e 8002, respectivamente.
rohithpr

6
Ótima pergunta. Todo site costumava precisar de seu próprio endereço IP (um servidor pode ter mais de um endereço IP). O cabeçalho Host no HTTP / 1.1 foi introduzido para solucionar o problema exato que você descreve. Consulte "Conservação de endereço da Internet" em www8.org/w8-papers/5c-protocols/key/key.html
AE

6
Se o http 1.1 não tivesse o cabeçalho do host, o ipv6 seria implementado agora ;-) :-(
Lenne

Respostas:


149

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:

  1. O usuário fornece uma URL, no formulário http://host:port/path.

  2. 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 hostsarquivo local em sistemas operacionais comuns ignora o DNS).

  3. O navegador abre uma conexão TCP com a porta especificada ou o padrão é a porta 80, nesse endereço IP.

  4. O navegador envia uma solicitação HTTP. Para HTTP / 1.1, é assim:

    GET /path HTTP/1.1
    Host: example.com
    

    (O Hostcabeç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 Hostcabeç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 Hosta 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.


1
Além disso, um site pode ser dividido em vários servidores, como é o caso dos balanceadores de carga, como o Heroku e o Amazon.
precisa saber é o seguinte

1
@phyrfox Sim, pensei em acrescentar isso, mas é apenas tangencialmente relacionado à pergunta e não queria fazer a resposta por muito tempo. Ainda pode acabar adicionando uma seção para ela mais tarde.
21716 Bob

Diz a lenda que subdomínios apontam computadores tão específicos dentro de uma rede. Em teoria
Loupax

"Tradicionalmente, isso era resolvido com um endereço IP (ou porta) dedicado para cada site que requer HTTPS. Obviamente, isso se torna problemático à medida que começamos a ficar sem endereços IPv4." .
Lenne

92

Eu tenho essa explicação para pessoas que não são de tecnologia.

Jack, Jill e Joe moram em um dormitório e não têm celular.

Na lista telefônica, todos são listados com o mesmo número. (Uma gravação)

Você disca o número e alguém atende o telefone; você diz "eu gostaria de falar com Jill" e você a coloca em risco.

Em vez de um registro A (um número de telefone / endereço IP) na lista telefônica, ele pode apenas dizer "Dormitório X", então você deve procurar mais o número do Dormitório X. Este é um registro CNAME.

Se Jill não estiver disponível, você poderá obter

  • 404 Jill não está aqui
  • 410 Jill está morta.
  • 301 Jill é morada com Peter
  • 302 Jill está visitando Peter, ligue para ele

  • 400 Eu não consigo te entender.

  • 401 Quem é você? Qual é a senha? ou Não permitimos ligações depois das 22h
  • 402 Pagamento obrigatório (Você tem certeza de que Jill é o nome verdadeiro dela ;-))
  • 403 Não, essa não é a senha correta.
  • 418 Jill é um bule de chá :-)
  • 429 Jill não pode mais atender chamadas.
  • 451 Você está violando sua ordem de restrição.

  • 500 Nosso sistema de telefonia quebrou.


Para os curiosos a RFC trás 418 é tools.ietf.org/html/rfc2324 e um artigo interessante sitesdoneright.com/blog/2013/03/... :)
Wordzilla

6

Pelo que entendi, o DNS vincula o nome de domínio ao endereço IP do servidor em que o site está armazenado, isso significa que cada servidor pode conter apenas um site?

Primeiro, você precisa entender que existem vários conceitos distintos aqui.

  • Site, um grupo de páginas da Web que formam um todo coerente.
  • Endereço IP, um endereço numérico (32 bits para IPv4, 128 bits para IPv6) usado pelo protocolo da Internet como fonte ou destino do tráfego.
  • Servidor, uma máquina cujo trabalho é atender solicitações de clientes.
  • Nome do host, um nome usado para identificar uma máquina no DNS (por exemplo, "www.example.com" ou "en.wikipedia.org")

Não existe um relacionamento individual entre essas coisas. Um servidor pode ter vários endereços IP; vários nomes de host podem apontar para um endereço IP; um nome de host pode apontar para vários endereços IP. Vários sites podem estar com o mesmo nome de host. Um site pode ser espalhado por vários nomes de host.

Caso contrário, como a chamada do endereço IP do servidor saberá qual site eu quero se houver muitos no mesmo servidor?

Antigamente (HTTP 1.0 e anterior), cada nome de host que o servidor desejava manipular de maneira diferente tinha que ter seu próprio endereço IP. Isso foi um desperdício.

O HTTP 1.1 adicionou o Host"cabeçalho como um campo obrigatório na solicitação HTTP (IIRC, alguns fornecedores já o apoiaram como uma extensão). Isso informava ao servidor qual nome do host havia sido solicitado e, portanto, permitiu que ele servisse conteúdo diferente para nomes de host diferentes no mesmo Endereço IP. O suporte ao HTTP 1.1 nos clientes agora é onipresente.

Infelizmente, o SSL (posteriormente TLS) adicionou uma ruga. O estabelecimento de uma sessão SSL / TLS exige que o servidor apresente um certificado ao cliente que cubra o nome do host solicitado, mas a solicitação HTTP não chega até que a sessão SSL / TLS seja estabelecida.

É possível que um certificado cubra vários nomes de host através do uso do SubjectAltNamecampo ou do uso de curingas no CommonNamecampo. No entanto, isso apresenta desafios administrativos, especialmente se os nomes de host envolvidos estiverem em domínios com propriedade diferente.

Portanto, o TLS introduziu a extensão "SNI (Server Name Indication)". Com essa extensão, o cliente envia o nome do host solicitado ao servidor durante o procedimento de handshake TLS. O servidor pode então apresentar o certificado apropriado. Infelizmente, enquanto as versões atuais de todas as principais implementações de SSL / TLS oferecem suporte ao SNI, demorou muito tempo para que versões mais antigas deixassem de ser usadas.


Você esqueceu de mencionar que o TCP pode escutar em muitos portos, correndo servidores diferentes em cada ...
Toby Speight

Sim, mas você não possui portnumbers no dns e não pode esperar que joe.p.user vá para our.fabulous.site:81 Além disso, alguns firewalls bloqueiam o acesso de saída a portnumbers não padrão.
Lenne

3

A resposta é um pouco mais complicada do que algumas das respostas. Quando você realiza uma pesquisa de DNS, DEVE obter um endereço IP ( Aregistro para IPv4, AAAAIPv6). Você precisa abrir um soquete pelo TCP / IP para se comunicar ou tudo falhará. Esse endereço pode representar um servidor ou um balanceador de carga. Pode até representar um proxy. Se o host estiver atrás do CloudFlare, por exemplo, o endereço que você recebe é de um servidor CloudFlare. O servidor real está em outro lugar. Isso permite que o host evite problemas como ataques de negação de serviço.

A hospedagem virtual é o que você está perguntando (algumas das outras perguntas abordaram isso, mas não em detalhes). A hospedagem virtual pega a solicitação da web e analisa o nome do host (por exemplo, domain.com) para determinar qual site será veiculado. Portanto, no servidor da web HTTP Apache, você teria uma configuração como esta

<VirtualHost *:80>
    ServerName www.domain.com
    ServerAlias domain.com

    DocumentRoot /var/www/domain.com
</virtualHost>

Isso é simplificado, por exemplo. Portanto, estamos dizendo ao Apache para ouvir na porta 80 de qualquer IP (na máquina virtual moderna que hospeda o IP da sua máquina pode ser diferente do seu IP ativo). Em seguida, dizemos que este é o domain.comsite e em que diretório ele vive. Podemos então repetir esse bloco repetidamente para dizer ao Apache para lidar com sites diferentes. Todo servidor da web suporta esse tipo de sistema.

Outra maneira de lidar com isso seria dizer ao servidor da Web para direcionar todo o tráfego da Web para um único script de programação (por exemplo, PHP, ASP.NET, etc) e, em seguida, esse único script determinará qual site e página exibir.


1

Usando o DNS, você pode atribuir tantos nomes a um endereço IP individual quanto desejar (no arquivo de hosts, você pode simplesmente separar cada nome com espaços, por exemplo). Usando um servidor DNS, você também pode atribuir vários endereços IP a um único nome . Não se limita a um relacionamento individual.

Um servidor da web sabe qual site servir examinando o URL solicitado. Ele analisa qual domínio foi solicitado, a porta que foi solicitada e qual protocolo foi usado. Isso não tem nada a ver com o DNS e é tratado pelo protocolo HTTP.


0

Servidor da Web tem o conceito de contêiner de host ( aqui está a documentação para o Tomcat, por exemplo). Vários contêineres de host podem ser configurados para o mesmo endereço IP / caixa, atendendo a vários domínios. Os contêineres têm diretórios de trabalho independentes, regiões de autenticação, diretórios de log e coisas assim.

O servidor encontra o contêiner relevante para a nova solicitação, pois o nome do domínio faz parte dessa solicitação HTTP.

Instâncias de servidor da Web completamente diferentes podem compartilhar o mesmo endereço IP, se executadas em portas diferentes. Isso é usado principalmente em vários ambientes de desenvolvimento e teste nos quais os nomes de domínio podem não estar disponíveis, pois o servidor de produção não pode ser executado em uma porta arbitrária.

Por fim, mesmo que o endereço IP estritamente exclusivo seja necessário para um site, uma caixa de servidor geralmente possui vários adaptadores de rede, por isso é configurada para usar vários endereços IP.


0

O endereço IP do servidor pode conter vários nomes de domínio diferentes ao mesmo tempo.

Quando você acessa o site, seu navegador envia a solicitação HTTP com o nome de domínio e o servidor pode encontrar quais dados do site devem ser enviados naquele momento.

Chama-se hosts virtuais, tão simples assim :)

Dê uma olhada aqui para obter mais informações sobre DNS e hosts virtuais.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.