Quais são as etapas detalhadas do modelo OSI envolvidas na conexão com um site?

Quais são as etapas detalhadas envolvidas na conexão com um site, como a página inicial do superuser.com usando um computador recém-conectado (http e nada em cache)? O que realmente está acontecendo em segundo plano para construir o bit final enviado pela Ethernet?

Entendo que, por exemplo, é feita uma consulta DNS para resolver o FQDN para um endereço IP (camada 7) ou o handshake de três vias para estabelecer uma conexão (camada 4). Mas como isso acontece enquanto o bit está sendo construído? As várias camadas mantêm os dados que farão parte do bit final, enquanto eles próprios enviam consultas / dados pela Ethernet para coletar as informações relevantes / fazer conexões etc.? Como isso funciona exatamente?

Quando o modelo OSI, ou modelo TCP / IP, é discutido, as coisas geralmente são apresentadas como dados sendo construídos e fluindo sequencialmente pelas camadas até que sejam enviados um pouco, mas não consegui encontrar uma explicação mais detalhada quanto aos detalhes envolvidos em cada aspecto, em um exemplo simples de conexão com um site.

Atualmente, os aplicativos usam bibliotecas abstratas de alto nível para endereçar a rede; portanto, muito disso é feito automaticamente pelo sistema operacional. Quanto menor o OSI, mais automático é e menos codificadores se importam com isso. Como sua pergunta é sobre estruturas e camadas de dados, você está realmente mais preocupado com as camadas superiores, pois as inferiores são mais engenharia elétrica, firmware e drivers do que qualquer outra coisa. nessa camada são apenas bits ou sinais elétricos.

A camada de aplicativo faz muito mais do que é aparente no modelo OSI, portanto, a primeira coisa que você deve entender é que a camada de aplicativo conduz tudo. O trabalho real de criar estruturas de dados nas camadas 3 e 4 é tratado por métodos (funções programadas) que operam nessas camadas, mas a camada de aplicação coordena cada operação e passa para cada método os parâmetros necessários, de modo que as camadas não "mantenha" seus dados em si, e as coisas não são necessariamente "transmitidas" para a camada subseqüente (embora em alguns casos, elas sejam literalmente). Em vez disso, pense nisso como um conjunto de chamadas de função que definem uma tarefa, de modo que a saída de uma função seja a entrada para outra. O ponto é que o local de controle está sempre na camada de aplicação.

Então, como eu disse no meu comentário, a maioria dos aplicativos modernos usa uma variante do padrão da API Berkley Sockets API . Esta biblioteca contém métodos que operam nas camadas OSI 7, 4, 3 e ganchos na API do IP do SO.

1. O aplicativo ligará Sockets.Socket(type)para criar uma nova porta e retornará o novo número de portas. Esta é uma função layer4.

2. O aplicativo perguntará ao sistema operacional qual é o seu endereço IP e depois ligará Sockets.Bind(newPort, localIPAddr, addrLen)para conectar o novo soquete à interface IP. Esta é uma função layer3.

3. O aplicativo ligará Sockets.Connect(newPort, remoteAddrandPort, addrlen)para iniciar uma conexão através do handshake de três vias TCP.

4. Depois que tudo isso estiver concluído, o Aplicativo poderá usar as funções Sockets.Send()e Sockets.Recv()para ler e gravar de e para o soquete como se fosse um vapor de E / S. Internamente, Send () / Recv () chama métodos privados definidos na biblioteca de soquetes que encapsulam os dados em cada camada, usando a saída da estrutura anterior como entrada para a próxima inferior, até que ele informe à pilha IP local para enviar o pacote. Na maioria dos casos, os aplicativos sabem ou não se importam com nada abaixo da camada 3 e, quando se preocupam com as camadas 3 ou 4, fornecem apenas valores de parâmetro válidos.

O aplicativo também é responsável pelas seqüências de comandos do protocolo. por exemplo, para se conectar ao superusuário, o aplicativo deve se comunicar em sequências de comandos HTTP .

Para recuperar a página padrão aqui em superuser.com, o navegador construiria a sequência:

GET / \HTTP/1.1;

O aplicativo pode simplesmente gravar essa string na porta e será automaticamente encapsulado em um segmento TCP, um pacote IP e um quadro 802.11n, e convertido em sinal elétrico pelo hardware.

O aplicativo pode ler do fluxo de E / S da rede para recuperar uma resposta como

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model....

O navegador retira o 200 (um valor indicando que o comando HTTP funcionou e a marcação a seguir) e renderiza a página.

Portanto, não estou totalmente satisfeito com essa resposta, porque me levou anos e anos em redes e códigos para obter uma imagem mental holística de como tudo isso funciona na realidade (em oposição ao OSI altamente abstrato) e sei que existem Existem pelo menos três perspectivas distintas que você pode adotar para analisar a conectividade de rede. Nesse caso, o processamento do sinal está correto e parece que você já está aprendendo sobre a perspectiva dos profissionais de rede, por isso espero que essa perspectiva ajude a completar sua compreensão de onde a teoria encontra a realidade.

Editar:

Ah, e desde que você mencionou o DNS, a maioria dos aplicativos usa os métodos getaddrinfo / getnameinfo do Sockets para executar uma consulta rápida de DNS, usando um FQDN como entrada. Esses métodos criam internamente, bind (), connect (), encapsulam um datagrama UDP (observe: o DNS geralmente é executado por UDP, embora a maioria dos sistemas possa ser configurada para usar TCP) e enviá-lo, ouvir uma resposta, analisá-lo em uma estrutura e retorne-a ao aplicativo, tudo com uma chamada. é bem arrumado. De fato, agora que penso nisso, é o epítome do que significa Encapsulamento.

Estou meio que ignorando seu primeiro parágrafo, o que foi útil, porque parece que você estava tentando ser mais específico no segundo parágrafo. Então esse parágrafo é o que eu respondo em detalhes.

Mas como isso acontece enquanto o bit está sendo construído?

Você propôs sua própria resposta, com a próxima pergunta.

As várias camadas mantêm os dados que farão parte do bit final, enquanto eles próprios enviam consultas / dados pela Ethernet para coletar as informações relevantes / fazer conexões etc.?

Sim.

Como isso funciona exatamente?

O usuário disse ao navegador que as informações são desejadas em um site. À medida que o usuário digita esse endereço na barra de endereços, nenhuma rede está envolvida ainda; o modelo OSI consideraria este o modelo OSI Layer 7: Application Layer.

O navegador da Web especificou que uma comunicação insegura está correta. (Se a segurança fosse necessária, o HTTPS teria sido feito. No entanto, o HTTP trabalhará para fornecer uma comunicação insegura.) Portanto, o HTTP é como a comunicação deve ocorrer (camada de apresentação, camada 6, ainda geralmente usada pelo aplicativo). HTTP não usa EBCDEC; a comunicação usará ASCII (outro detalhe relacionado à camada de apresentação, camada 6 do modelo OSI).

Comunicação confiável deve ocorrer. Usaremos uma sessão para que a conversa ocorra através de uma "conexão" HTTP que pode envolver vários pacotes. A ideia de ter essa conexão é Session Layer (OSI Model Layer 5)

As comunicações de transporte permitem que várias conversas (como várias transferências simultâneas de dados) ocorram no mesmo endereço IP. Quando há dados recebidos ou enviados, essas conversas são acompanhadas usando vários números de "porta". O navegador especifica que deseja conversar com a porta TCP 80 do www.superuser.com. A especificação do número da porta está chegando ao domínio da Camada de Transporte (OSI MOdel Layer 4).

O aplicativo (o navegador da web) se comunica com a "pilha de rede TCP / IP", que normalmente é incorporada ao sistema operacional (atualmente ... nos dias do Windows 3.1, talvez você precise instalar o "Trumpet Winsock", um pilha de terceiros ou use a pilha da Microsoft que pode ser instalada com o MS Internet Explorer for Win 3.1).

A pilha de rede percebe que "www.superuser.com" é um nome de rede. Portanto, o código "resolvedor" é usado. Esse nome não está no cache "resolução de nomes" ("resolvedor") e tentar procurá-lo no "arquivo hosts" não revela o nome. Portanto, uma consulta DNS será enviada.

Ah, sim, sua pergunta fez referência a "http" e "DNS", portanto, essa resposta se torna um pouco mais complicada ao observar a comunicação DNS e a comunicação HTTP. Veremos primeiro a comunicação DNS, porque é isso que acontecerá antes que o OSI Model Layer 3 tenha algo a ver com qualquer tráfego HTTP.

O resolvedor inicia o processo de fazer uma comunicação DNS. O computador receberá a resposta como um datagrama DNS (porta UDP 53, Camada de Transporte, Camada 4).

O servidor DNS está em um computador. Vamos fingir que está em um computador remoto. Portanto, isso envolverá a comunicação com o endereço IP de um computador diferente. Portanto, um pacote IP será usado (ou seja, Camada de rede, Camada de modelo OSI 3). Apenas por diversão, digamos que este é um pacote IPv4 (sem motivo). (Na verdade, comecei a escrever isso como IPv6 ... decidi voltar ao IPv4 para obter endereços de amostra mais curtos. Mas o IPv6 poderia ser feito.)

Vamos fingir que o computador é um roteador. Com base no endereço IP da camada 3, não queremos seguir a rota que enviará o tráfego para o quarto do adolescente. Queremos seguir uma rota que vá para a Internet. Esse pacote IPv4 pode ser enviado pela rede sem fio ou pela rede com fio. Optaremos por usar o endereço IPv4 que usa a rede com fio.

Como o servidor DNS está em uma sub-rede diferente, precisamos enviar o tráfego para um gateway. Como não tenho uma rota mais específica (por exemplo, para o quarto do adolescente), usarei um "gateway padrão" usado sempre que não houver uma opção mais específica disponível. Saber qual o caminho para enviar o tráfego é "roteamento", o principal recurso da Camada 3.

Digamos que a rede com fio será usada para esta comunicação. O pacote IP precisa chegar ao servidor DNS (8.8.8.8, Camada 3), mas a tabela de roteamento indica que essas comunicações são roteadas através de um endereço de gateway em 198.51.100.1 (Camada 3). (A propósito, 198.51.100.1 não é algo que você deveria usar em uma rede real, mas posso usá-lo neste exemplo, porque estou seguindo a seção 3 da RFC 5737

Podemos nos comunicar com 198.51.100.1 usando um quadro Ethernet. O cache do ARP (equivalente do IPv4 ao NDP do IPv6) não possui detalhes; portanto, precisamos de um quadro ARP WHO-HAS (equivalente à descoberta de vizinhos do IPv6) para descobrir para onde o quadro Ethernet deve ser enviado. Essa descoberta vizinha envia transmissão Ethernet para FF-FF-FF-FF-FF-FF (o IPv6 pode usar multicast como parte do NDP) para descobrir quem possui esse endereço Ethernet. Quando uma resposta é recuperada, as informações são inseridas no cache (cache do ARP ... se estivéssemos usando o IPv6, seria o cache do NDP).

Agora podemos enviar um quadro Ethernet para o sistema que está em 192.168.0.1. Portanto, a "pilha de rede TCP / IP" coloca o datagrama UDP em um pacote IP que irá para o endereço IP 8.8.8.8 e o encapsula em um quadro Ethernet que vai para 01-23-45-67-89-AB . Esse quadro Ethernet é enviado na Camada 2.

A pilha de rede TCP / IP envia esse quadro Ethernet na camada 2, comunicando-se com o driver da placa de rede (que pode se comunicar com a Ethernet). No entanto, a pilha de rede TCP / IP esquece os bits desse datagrama UDP. Afinal, o UDP não é confiável. A pilha de rede TCP / IP não é feita com a solicitação HTTP, porque o "resolvedor" ainda está aguardando uma resposta com base no endereço de rede "origem" do pacote UDP de saída. Mas a pilha de rede TCP / IP não mantém uma cópia dos bits enviados de maneira confiável nesse datagrama UDP. (Se o datagrama UDP se perder, acredito que o "resolvedor" provavelmente falhará e o navegador da Web poderá decidir tentar novamente. De qualquer forma, a parte "repetir" não é tratada pela parte não confiável de cuidar de um datagrama UDP. )

O driver Ethernet fica preso no pacote por tempo suficiente para garantir que o pacote não seja corrompido por nenhuma colisão Ethernet na camada 1 do modelo OSI. Depois que a Ethernet é transmitida sem problemas, o driver de rede esquece.

O gateway padrão recebe o quadro Ethernet. Por ser um roteador, ele encaminha o tráfego, o que significa que precisa examinar um pouco os pacotes IP que não são endereçados a si mesmos. Eu considero isso "promíscuo". O roteador verifica para onde o tráfego deve ir e segue um processo semelhante para obter o tráfego para outro roteador. O pacote IP é modificado reduzindo o TTL em 1 e o roteador usa a Camada 2 para obter o tráfego para o próximo roteador. Esse processo se repete através do número de roteadores necessário e deve funcionar bem, desde que o nível TTL não fique baixo; nesse caso, uma resposta "ICMP TTCE Excedido" do ICMP retornará. Por simplicidade, o restante deste exemplo fingirá que isso não aconteceu.

Mais tarde, talvez depois de milhares de milissegundos que ocupam milhões de megahertz de tempo de CPU, o driver de rede (no computador com o navegador da Web) percebe uma comunicação Ethernet. Esse quadro Ethernet possui um endereço MAC de destino (OSI Model Layer 2) que pertence a este computador com o navegador da web. O quadro possui um campo Protocolo que diz que é um pacote IP; especificamente, o termo "pacote IP" é de um padrão antigo e significa um pacote IPv4 (OSI Model Layer 3). Como o endereço de destino corresponde a este computador, o computador não precisa verificar se há algum software em execução no "modo promíscuo". Portanto, o driver de rede envia para a pilha de rede TCP / IP. O pacote IP acaba contendo um datagrama UDP (OSI Model Layer 4) do servidor DNS. Portanto, a pilha de rede TCP / IP verifica a lista de portas abertas (que você pode ver executando "netstat -na" no Unix ou no Microsoft Windows). A lista de portas abertas é verificada quanto à porta "LISTENING" e verifica-se que uma resposta está sendo procurada pelo resolvedor. Portanto, a pilha de rede TCP / IP envia esse datagrama UDP ao resolvedor.

Agora que o resolvedor descobriu que www.superuser.com é 203.0.113.50 (como exemplo, permitido pela seção 3 da RFC 5737), a pilha de rede TCP / IP pode ficar à vontade para criar um segmento TCP que conterá um pacote IP que vai para 203.0.113.50. O primeiro pacote IP da conversa realmente não contém nenhuma carga útil interessante e é apenas parte do handshake TCP de três vias. Após uma resposta, a parte de manipulação de TCP da pilha de rede TCP / IP enviará um segmento TCP dentro de um pacote IP. O processo é bem parecido com o manuseio do datagrama UDP, exceto quando a pilha de rede TCP / IP pega o pacote IP que contém o segmento TCP e envia esses pacotes para o driver de rede (para manipular o quadro Ethernet), o TCP / IP A pilha de rede IP lembrará todo o conteúdo desse pacote TCP, até que o pacote seja reconhecido em um segmento TCP de resposta. Se o pacote TCP for perdido em trânsito, eventualmente, a extremidade remota reclamará ou um cronômetro de expiração será concluído, e o pacote TCP / IP enviará outro segmento TCP com uma cópia duplicada da carga útil essencial. Essa tentativa de "tentar novamente" é o motivo pelo qual o TCP é chamado de "confiável".

Dessa vez, em vez de aguardar um datagrama UDP contendo tráfego DNS enviado ao resolvedor, a Pilha de rede TCP / IP aguarda uma resposta TCP. Alguma porta aleatória, por exemplo, a porta 12345, é usada como a "porta de origem" da solicitação inicial.

O segmento TCP de saída contém a solicitação "GET" que faz parte da comunicação HTTP enviada pelo navegador da web.

Agora, vamos avançar com o manuseio do pacote IP (e do quadro Ethernet).

Depois que a solicitação é recebida pelo servidor da web, o servidor envia dados para o navegador. Isso pode acontecer como vários segmentos TCP. O servidor da Web lembra o conteúdo de cada segmento TCP que envia, até que esse segmento seja reconhecido pelo computador que está executando o navegador.

À medida que o computador com o navegador obtém informações do servidor da Web, ele nota os quadros Ethernet (Camada OSI 2) que contêm pacotes IP (Camada OSI 3) que contêm segmentos TCP (Camada OSI 4) provenientes da porta TCP 80 (na navegador da web) a uma porta TCP local que esteja escutando (por exemplo, 12345, mencionado anteriormente). A pilha de rede TCP / IP perceberá que deve ir para o navegador da web.

O navegador da Web processa as informações da conexão (Camada 5, sessão), percebe que o tráfego não é criptografado (Camada 6, apresentação) e não torna a barra de endereço vermelha (como faria se houvesse um problema com a segurança HTTPS) . A decisão sobre a cor da barra de endereço é um problema da "interface do usuário", considerado parte da Camada 7 do Modelo OSI de 7 camadas.