Como desenvolvedor de software, você definitivamente terá uma compreensão completa e hierárquica de como os aplicativos de rede funcionam, e isso também inclui as tecnologias usadas nesses aplicativos: como navegadores, HTTP, HTML, servidores da Web, processamento de requisitos, etc.
Este artigo estudará mais aprofundado o que acontece em segundo plano quando você entrar em um URL ~
1. Primeiro de tudo, você deve entrar no URL desejado no navegador : 2. O navegador procura o endereço IP do nome do domínioA primeira etapa da navegação é descobrir seu endereço IP acessando o nome de domínio. O processo de pesquisa do DNS é o seguinte:
Cache do navegador - Os cache do navegador registram registros DNS por um período de tempo. Curiosamente, o sistema operacional não informa ao navegador a hora de armazenar o registro do DNS, para que diferentes navegadores armazenem um tempo auto-fixo (variando de 2 minutos a 30 minutos). Cache do sistema - Se o registro necessário não for encontrado no cache do navegador, o navegador fará uma chamada do sistema (GethostbyName no Windows). Isso permite que você obtenha registros no cache do sistema. Cache do roteador - Em seguida, a solicitação de consulta anterior é enviada ao roteador, que geralmente possui seu próprio cache DNS. Cache do ISP DNS - a próxima coisa a verificar é o servidor em que o ISP cache DNS. É aqui que os registros de cache correspondentes geralmente podem ser encontrados. Pesquisa recursiva-o servidor DNS do seu ISP começa com o servidor de nomes de domínio, desde o servidor de nome de domínio de nível superior .com até o servidor de nomes de domínio do Facebook. Geralmente, haverá nomes de domínio no servidor de nomes de domínio .com no cache dos servidores DNS; portanto, o processo de correspondência com o servidor de nível superior não é tão necessário.A pesquisa recursiva de DNS é mostrada na figura abaixo:
O DNS é um pouco preocupante, ou seja, todo o nome de domínio como wikipedia.org ou facebook.com parece que corresponde a um endereço IP separado. Felizmente, existem várias maneiras de eliminar este gargalo:
O LOOP DNS é a solução ao retornar vários IPs quando a pesquisa do DNS. Por exemplo, o Facebook.com corresponde a quatro endereços IP. Um balanceador de carga é um dispositivo de hardware que escuta em um endereço IP específico e encaminha solicitações de rede para um servidor de cluster. Alguns sites grandes geralmente usam esse balanceador caro de carga de alto desempenho. O DNS geográfico melhora a escalabilidade, mapeando nomes de domínio para vários endereços IP diferentes com base na localização geográfica do usuário. Dessa forma, os servidores diferentes não podem atualizar o status de sincronização, mas é muito bom mapear o conteúdo estático. Anycast é uma tecnologia de roteamento que mapeia vários hosts físicos com endereços IP. A única desvantagem é que o Protocolo de Anycast e TCP não é bem adaptado, portanto, eles raramente são usados nessas soluções.A maioria dos servidores DNS usa Anycast para obter pesquisas de DNS eficientes e de baixa latência.
3. O navegador envia uma solicitação HTTP para o servidor da webComo páginas dinâmicas como as páginas iniciais do Facebook, elas expirarão em breve e mesmo imediatamente no cache do navegador após a abertura, e não há dúvida de que não podem ler delas.
Portanto, o navegador enviará uma solicitação ao servidor onde o Facebook está localizado:
Obtenha http://facebook.com/ http/1.1Aceitar: Aplicação/X-MS-Aplicação, Image/JPEG, Application/Xaml+XML, [...]
Agente de usuário: mozilla/4.0 (compatível; msie 8.0; windows nt 6.1; wow64; [...]
Aceitar-se-codificador: gzip, deflate
Conexão: Keep-alive
Host: Facebook.com
Cookie: datr = 1265876274-[...]; loce = en_us; LSD = WW [...]; c_user = 2101 [...]
Get Esta solicitação define o URL a ser lido: http://facebook.com/. O próprio navegador define (cabeçalho do agente do usuário ) e que tipo de cabeçalho correspondente ( aceite e aceite o codificação ) ele deseja aceitar. O cabeçalho da conexão exige que o servidor não feche a conexão TCP para solicitações subsequentes.
A solicitação também contém cookies para o nome de domínio armazenado pelo navegador. Você já deve saber que, em diferentes solicitações de página, os cookies são valores -chave que correspondem ao status de um site. Dessa forma, os cookies armazenam nome de usuário de login, senha atribuída ao servidor e algumas configurações do usuário. Os cookies são armazenados no cliente como um documento de texto e enviados ao servidor toda vez que solicitarem.
Existem muitas ferramentas para observar a solicitação HTTP original e suas ferramentas correspondentes. O autor prefere usar o Fiddler e, é claro, existem outras ferramentas como o Firebug. Esses software podem ser uma grande ajuda ao otimizar o site.
Além de obter solicitações, há outro tipo de solicitação enviada, que é frequentemente usada ao enviar formulários. Envie uma solicitação para passar seus parâmetros através do URL (por exemplo: http://robozle.com/puzzle.aspx?id=85). Enviar a solicitação envia seus parâmetros após o cabeçalho do corpo da solicitação.
Slashes como http://facebook.com/ são cruciais. Nesse caso, o navegador pode adicionar com segurança barras. Para endereços como http://example.com/FolderorFile, porque o navegador não sabe se o FolderorFile é uma pasta ou um arquivo, ele não pode adicionar automaticamente barras. No momento, o navegador acessará diretamente o endereço sem cortar, e o servidor responderá a um redirecionamento, resultando em um aperto de mão desnecessário.
4. Resposta de redirecionamento permanente do serviço do FacebookA imagem mostra a resposta enviada de volta ao navegador pelo servidor do Facebook:
Http/1.1 301 movido permanentementeControle de cache: privado, sem lojas, sem cache, obrigatória-revalidada, pós-verificação = 0,
pré-check = 0
Expira: SAT, 01 de janeiro de 2000 00:00:00 GMT
Localização: http://www.facebook.com/
P3P: CP = Lei DSP
Pragma: sem cache
Set-cookie: make_write_conn = excluído; expire = qui, 12-feb-2009 05:09:50 gmt;
caminho =/; domain = .facebook.com; httponly
Tipo de conteúdo: texto/html; charset = utf-8
X-Cneção: Feche
Data: sex, 12 de fevereiro de 2010 05:09:51 GMT
Comprimento de conteúdo: 0
O servidor responde a uma resposta de redirecionamento permanente 301, para que o navegador visite http://www.facebook.com/ em vez de http://facebook.com/.
Por que o servidor precisa redirecionar em vez de enviar diretamente o conteúdo da Web que os usuários desejam ver? Existem muitas respostas interessantes para esta pergunta.
Uma das razões está relacionada ao ranking de mecanismos de pesquisa. Veja bem, se uma página tiver dois endereços, como http://www.igoro.com/ e http://igoro.com/, os mecanismos de pesquisa considerarão dois sites, resultando em uma diminuição nos links de pesquisa de cada um e diminuindo as classificações. Os mecanismos de pesquisa sabem o que 301 redirecionam permanentes, para que eles classifiquem o acesso aos endereços com www e sem www no mesmo ranking do site.
Outra coisa é que o uso de endereços diferentes fará com que a simpatia do cache piorasse. Quando uma página tem vários nomes, ela pode aparecer várias vezes no cache.
5. Endereço de redirecionamento do navegadorAgora, o navegador sabe que http://www.facebook.com/ é o endereço correto a ser acessado, por isso enviará outra solicitação GET:
Obtenha http://www.facebook.com/ http/1.1Aceitar: Aplicação/X-MS-Aplicação, Image/JPEG, Application/Xaml+XML, [...]
Aceitar-Language: en-us
Agente de usuário: mozilla/4.0 (compatível; msie 8.0; windows nt 6.1; wow64; [...]
Aceitar-se-codificador: gzip, deflate
Conexão: Keep-alive
Cookie: lsd = xw [...]; c_user = 21 [...]; X-referencial = [...]
Host: www.facebook.com
As informações do cabeçalho têm o mesmo significado que na solicitação anterior.
6. O servidor lida com a solicitaçãoO servidor recebe a solicitação de busca, depois processa e retorna uma resposta.
Parece ser uma tarefa avançada na superfície, mas, na verdade, há muitas coisas interessantes acontecendo no meio - um site simples como o blog do autor, muito menos um site como o Facebook!
Software do servidor da web O software do servidor da web (como IIS e Apache) recebe uma solicitação HTTP e, em seguida, determina qual solicitação de processamento é executado para lidar com isso. O processamento de solicitação é um programa que pode ler a solicitação e gerar HTML para responder (como asp.net, php, ruby ...).Para dar o exemplo mais simples, o processamento de requisitos pode ser armazenado em uma hierarquia de arquivos que mapeia a estrutura de endereço do site. O endereço como http://example.com/folder1/page1.aspx mapeará o arquivo /httpdocs/folder1/page1.aspx. O software do servidor da web pode ser definido como o processamento de solicitação correspondente manualmente pelo endereço, para que o endereço de publicação da página1.aspx possa ser http://example.com/Folder1/Page1.
Solicitar processamento A solicitação lida com a solicitação de leitura e seus parâmetros e cookies. Ele lerá e atualizará alguns dados e diz que os dados são armazenados no servidor. O processamento de requisitos gera uma resposta HTML.Todos os sites dinâmicos enfrentam uma dificuldade interessante - como armazenar dados. Metade dos sites pequenos terá um banco de dados SQL para armazenar dados. O armazenamento de grandes quantidades de dados e/ou sites muito visitados precisam encontrar algumas maneiras de alocar o banco de dados a várias máquinas. As soluções incluem: sharding (com base em valores de chave primária, as tabelas de dados são espalhadas em vários bancos de dados), replicação e bancos de dados simplificados que utilizam fraca consistência semântica.
Delegar trabalho ao processamento em lote é uma tecnologia barata para manter os dados atualizados. Por exemplo, o Facebook precisa atualizar feeds de notícias a tempo, mas as funções das pessoas que você conhece com o suporte de dados só precisam ser atualizadas todas as noites (o autor adivinha que é, não se sabe como melhorar a função). As atualizações de trabalho em lote podem causar desatualizadas alguns dados menos importantes, mas podem tornar as atualizações de dados mais rápidas e concisas.
7. O servidor envia de volta uma resposta HTMLA imagem é a resposta gerada e devolvida pelo servidor:
Http/1.1 200 okControle de cache: privado, sem lojas, sem cache, obrigatória-revalidada, pós-verificação = 0,
pré-check = 0
Expira: SAT, 01 de janeiro de 2000 00:00:00 GMT
P3P: CP = Lei DSP
Pragma: sem cache
Codificação de conteúdo: gzip
Tipo de conteúdo: texto/html; charset = utf-8
X-Cneção: Feche
Codificação de transferência: rolada
Data: sex, 12 de fevereiro de 2010 09:05:55 GMT
2b3tn@[...]
O tamanho inteiro da resposta é de 35kb, a maioria transferida como tipo de blob após a classificação.
O terminal de codificação de conteúdo diz ao navegador que todo o corpo de resposta é comprimido usando o algoritmo GZIP. Depois de descomprimir o bloco Blob, você pode ver o HTML esperado da seguinte maneira:<!http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd>
<html xmlns = http: //www.w3.org/1999/xhtml xml: lang = en
lang = en id = facebook class = no_js>
<head>
<meta http-equiv = content-type content = text/html; charset = utf-8 />
<meta http-equiv = conteúdo-linguagem de conteúdo = en />
...
Em relação à compactação, as informações do cabeçalho explica se esta página está em cache, como fazê -lo se for armazenado em cache, quais cookies devem ser definidos (esse ponto não é encontrado na resposta anterior), informações de privacidade etc.
Observe que o tipo de conteúdo está definido como texto/html no cabeçalho. O cabeçalho permite que o navegador renderize o conteúdo da resposta no HTML em vez de baixá -lo no formulário de arquivo. O navegador decidirá como interpretar a resposta com base nas informações do cabeçalho, mas também considerará outros fatores, como o conteúdo de extensão da URL.
8. O navegador começa a exibir HTMLQuando o navegador não aceita totalmente todos os documentos HTML, ele começa a exibir esta página:
9. O navegador envia para incorporar objetos em htmlQuando o navegador exibe HTML, ele percebe as tags que precisam obter o conteúdo de outros endereços. No momento, o navegador enviará uma solicitação GE para recuperar os arquivos.
Aqui estão alguns URLs que precisamos para visitar o Facebook.com:
foto http://static.ak.fbcdn.net/rsrc.php/z12e0/hash/8q2anwu7.gifhttp://static.ak.fbcdn.net/rsrc.php/zbs5c/hash/7hwy7at6.gif
… Tabela de estilo CSS
http://static.ak.fbcdn.net/rsrc.php/z448z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zane1/hash/cvtutcee.css
… Arquivos JavaScript
http://static.ak.fbcdn.net/rsrc.php/zemoa/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6r9l/hash/cq2lgbs8.js
...
Todos esses endereços passam por um processo semelhante à leitura HTML. Portanto, o navegador procurará esses nomes de domínio no DNS, enviar solicitações, redirecionamentos etc.
Mas, diferentemente das páginas dinâmicas, os arquivos estáticos permitem que o navegador as cache. Alguns arquivos podem não precisar se comunicar com o servidor e são lidos diretamente do cache. A resposta do servidor contém as informações do prazo para arquivos estáticos, para que o navegador saiba quanto tempo eles precisam ser armazenados em cache. Além disso, cada resposta pode conter um cabeçalho ETAG (o valor da entidade da variável solicitada) que funciona como o número da versão. Se o navegador observar que a versão ETAG do arquivo já existe, a transferência do arquivo será interrompida imediatamente.
Tente adivinhar o que o fbcdn.net representa no endereço? A resposta inteligente é a rede de distribuição de conteúdo do Facebook. O Facebook usa a rede de distribuição de conteúdo (CDN) para distribuir arquivos estáticos, como imagens, tabelas CSS e arquivos JavaScript. Portanto, esses arquivos serão backup em muitos data centers de CDN em todo o mundo.
O conteúdo estático geralmente representa o tamanho da largura de banda do site e também pode ser facilmente copiado através de uma CDN. Normalmente, os sites usam CDNs de terceiros. Por exemplo, os arquivos estáticos do Facebook são hospedados pela Akamai, o maior provedor de CDN.
Por exemplo, quando você tenta ping static.ak.fbcdn.net, você pode obter uma resposta de um certo servidor Akamai.net. Curiosamente, quando você ping novamente, o servidor de resposta pode ser diferente, o que significa que o balanceamento de carga nos bastidores está começando a funcionar.
10. O navegador envia uma solicitação assíncrona (AJAX)Guiado pelo Grande Spirit of Web 2.0, o cliente permanece em contato com o servidor após a conclusão da exibição da página.
Tome a função de bate -papo no Facebook como exemplo, ele manterá contato com o servidor para atualizar o status de seus amigos brilhantes e cinza em tempo hábil. Para atualizar o status de amigo desses avatares, o código JavaScript executado no navegador enviará uma solicitação assíncrona ao servidor. Essa solicitação assíncrona é enviada para um endereço específico, que é uma solicitação de busca ou envio de busca de programa. Ou no exemplo do Facebook, o cliente envia uma solicitação para http://www.facebook.com/ajax/chat/buddy_list.php para obter as informações de status on -line em seu amigo.
Quando se trata desse padrão, devemos falar sobre Ajax-JavaScript e XML asntênicos. Embora não haja motivo claro para que o servidor responda no formato XML. Deixe -me dar outro exemplo. Para solicitações assíncronas, o Facebook retornará alguns trechos de código JavaScript.
Entre outras coisas, a ferramenta Fiddler permite que você veja solicitações assíncronas enviadas pelo seu navegador. De fato, você não só pode servir passivamente como espectador dessas solicitações, mas também atacar ativamente para modificá -las e reenviar. Os pedidos do Ajax são tão fáceis de se enganar, mas eles realmente fazem com que os desenvolvedores de jogos on -line que pontuem as pontuações estão deprimidos. (Claro, não minta para outras pessoas assim ~)
A função de bate -papo no Facebook fornece um caso interessante de Ajax: empurrando dados do servidor para o cliente. Como o HTTP é um protocolo de resposta-resposta, o servidor de bate-papo não pode enviar novas mensagens para o cliente. Em vez disso, o cliente precisa pesquisar o lado do servidor a cada poucos segundos para ver se há alguma notícia nova.
A pesquisa para essas situações é uma técnica interessante para reduzir a carga do servidor. Se o servidor não tiver novas mensagens quando pesquisado, ele ignorará o cliente. Quando a nova mensagem do cliente ainda não tiver tempo, o servidor encontrará a solicitação inacabada e retornará a nova mensagem ao cliente como uma resposta.