Antes de começarmos o vídeo tutorial de hoje, quero agradecer a todos que contribuíram para a popularidade do meu curso no YouTube. Quando comecei, há cerca de 8 meses, não esperava tanto sucesso - hoje minhas aulas foram visualizadas por 312724 pessoas, tenho 11208 assinantes. Nunca sonhei que esse começo humilde alcançaria tais alturas. Mas não vamos perder tempo e ir direto para a lição de hoje. Hoje iremos preencher as lacunas que ocorreram nas últimas 7 videoaulas. Embora hoje seja apenas o dia 6, o dia 3 foi dividido em 3 videoaulas, então hoje você realmente assistirá à oitava videoaula.
Hoje iremos cobrir 3 tópicos importantes: DHCP, transporte TCP e os números de porta mais comuns. Já falamos sobre endereços IP e um dos fatores mais importantes na configuração de endereços IP é o DHCP.
DHCP significa Dynamic Host Configuration Protocol e é um protocolo que ajuda a configurar dinamicamente endereços IP para hosts. Então, todos nós vimos esta janela. Ao clicar na opção “Obter um endereço IP automaticamente”, o computador procura um servidor DHCP que esteja configurado na mesma sub-rede e envia diversos pacotes e solicitações de endereço IP. O protocolo DHCP possui 6 mensagens, das quais 4 são críticas para a atribuição de um endereço IP.
A primeira mensagem é uma mensagem DHCP DISCOVERY. A mensagem de descoberta do DHCP é semelhante a uma mensagem de saudação. Quando um novo dispositivo entra na rede, ele pergunta se existe um servidor DHCP na rede.
O que você vê no slide parece uma solicitação de transmissão em que o dispositivo entra em contato com todos os dispositivos da rede em busca de um servidor DHCP. Como eu disse, esta é uma solicitação de transmissão, para que todos os dispositivos da rede possam ouvi-la.
Se houver um servidor DHCP na rede, ele envia um pacote - uma oferta DHCP OFFER. Proposta significa que o servidor DHCP, em resposta a uma solicitação de descoberta, envia uma configuração ao cliente, solicitando que ele aceite um endereço IP específico.
O servidor DHCP reserva um endereço IP, neste caso 192.168.1.2, não o fornece, mas reserva este endereço para o dispositivo. Ao mesmo tempo, o pacote de oferta contém seu próprio endereço IP do servidor DHCP.
Caso exista mais de um servidor DHCP nesta rede, outro servidor DHCP, ao receber a solicitação de broadcast do cliente, também lhe oferecerá seu endereço IP, por exemplo, 192.168.1.50. Não é comum ter dois servidores DHCP diferentes configurados na mesma rede, mas às vezes isso acontece. Portanto, quando uma oferta DHCP é enviada a um cliente, ele recebe 2 ofertas DHCP e agora deve decidir qual oferta DHCP deseja aceitar.
Vamos supor que o cliente aceite a primeira inscrição. Isso significa que o cliente envia uma solicitação DHCP REQUEST que diz literalmente "Aceito o endereço IP 192.168.1.2 oferecido pelo servidor DHCP 192.168.1.1."
Ao receber a solicitação, o servidor DHCP 192.168.1.1 responde “ok, admito”, ou seja, reconhece a solicitação e envia esse DHCP ACK ao cliente. Mas lembramos que outro servidor DHCP reservou um endereço IP 1.50 para o cliente. Assim que receber uma solicitação de broadcast de um cliente, ele saberá da falha e colocará esse endereço IP de volta no pool para que possa atribuí-lo a outro cliente caso receba outra solicitação.
Estas são as 4 mensagens críticas que o DHCP troca ao atribuir endereços IP. Em seguida, o DHCP possui mais 2 mensagens informativas. Uma mensagem informativa é emitida pelo cliente se ele precisar de mais informações do que as recebidas na cláusula DHCP OFFER na segunda etapa. Se o servidor não fornecer informações suficientes na oferta de DHCP ou se o cliente precisar de mais informações do que as contidas no pacote de oferta, ele solicitará informações adicionais de DHCP. Há mais uma mensagem que o cliente envia ao servidor - esta é a DHCP RELEASE. Informa que o cliente deseja liberar seu endereço IP existente.
Porém, o que acontece com mais frequência é que o usuário se desconecta da rede antes que o cliente tenha tempo de enviar um DHCP RELEASE ao servidor. Isso acontece quando você desliga o computador, o que nós fazemos. Nesse caso, o cliente da rede, ou computador, simplesmente não tem tempo de informar ao servidor para liberar o endereço utilizado, portanto DHCP RELEASE não é uma etapa obrigatória. As etapas necessárias para obter um endereço IP são: descoberta de DHCP, oferta de DHCP, solicitação de DHCP e handshake de DHCP.
Em uma das próximas lições contarei como configuramos um servidor DHCP ao criar um pool DNCP. Por pooling queremos dizer que você diz ao servidor para atribuir endereços IP no intervalo 192.168.1.1 a 192.168.1.254. Assim, o servidor DHCP criará um pool, colocará nele 254 endereços IP e poderá atribuir endereços a clientes na rede somente a partir deste pool. Então isso é algo como uma configuração administrativa que o usuário pode fazer.
Agora vamos dar uma olhada na transmissão TCP. Não sei se você conhece o “telefone” da foto, mas quando éramos crianças costumávamos usar essas latas conectadas por um barbante para conversarmos.
Infelizmente, a geração de hoje não pode se dar ao luxo de tal “luxo”. Quer dizer, hoje as crianças estão na frente da TV desde um ano de idade, jogam PSP e talvez isso seja discutível, mas acho que tivemos a melhor infância, na verdade saíamos para fora e jogávamos e as crianças de hoje não podem ser afastadas do sofá .
Meu filho tem apenas um ano e já posso perceber que ele é viciado em iPad, quer dizer, ele ainda é muito pequeno, mas acho que as crianças de hoje já nascem sabendo manusear aparelhos eletrônicos. Então, eu queria dizer que quando crianças, quando brincávamos, fazíamos furos nas latas, e quando amarrávamos com um barbante e falávamos alguma coisa em uma lata, aí na outra ponta a pessoa conseguia ouvir o que estava sendo dito para ele, simplesmente colocando a lata em seu ouvido. Portanto, é muito semelhante a uma conexão de rede.
Hoje, mesmo as transferências TCP devem ter uma conexão que deve ser estabelecida antes do início da transferência real de dados. Conforme discutimos nas lições anteriores, TCP é uma transmissão orientada a conexão, enquanto UDP é uma transmissão orientada a conexão. Você poderia dizer que UDP é onde eu jogo a bola e cabe a você ver se consegue pegá-la. Se você está pronto para fazer isso ou não, não é problema meu, vou simplesmente deixá-lo.
TCP é mais como você conversando com um cara e avisando-o com antecedência que você vai jogar uma bola, então você forma um vínculo e então joga a bola para que seu parceiro esteja mais pronto para pegá-la. Então o TCP realmente constrói a conexão e então começa a fazer a transmissão propriamente dita.
Vejamos como isso cria essa conexão. Este protocolo usa um handshake de três vias para criar uma conexão. Este não é um termo muito técnico, mas tem sido usado há muito tempo para descrever uma conexão TCP. Um handshake triplo é iniciado pelo dispositivo remetente, com o cliente enviando um pacote com um sinalizador SYN para o servidor.
Digamos que a garota em primeiro plano, cujo rosto podemos ver, seja o dispositivo A, e a garota no fundo, cujo rosto não está visível, seja o dispositivo B. A garota A envia um pacote SYN para a garota B, e ela diz: “Ótimo, quem- então ele quer se comunicar comigo. Então, preciso responder que estou pronto para me comunicar!” Como fazer isso? Pode-se simplesmente enviar de volta outro pacote SYN e então um ACK indicando o recebimento do pacote SYN original. Mas em vez de enviar ACKs separadamente, o servidor forma um pacote comum contendo SYN e ACK e o transmite pela rede.
Portanto, neste ponto, o dispositivo A enviou um pacote SYN e recebeu de volta um pacote SYN/ACK. Agora o dispositivo A deve enviar ao dispositivo B um pacote ACK, ou seja, confirmar que recebeu consentimento do dispositivo B para estabelecer comunicação. Assim, ambos os dispositivos receberam pacotes SYN e ACK, e agora podemos dizer que a conexão foi estabelecida, ou seja, foi concluído um handshake de 3 estágios utilizando o protocolo TCP.
A seguir, veremos a tecnologia TCP Windowing. Simplificando, é um método usado no TCP/IP para negociar as capacidades do remetente e do destinatário.
Digamos que no Windows estamos tentando transferir um arquivo grande, digamos de 2 GB, de uma unidade para outra. Logo no início da transferência, o sistema nos informará que a transferência do arquivo levará aproximadamente 1 ano. Mas alguns segundos depois o sistema se corrigirá e dirá: “ah, espere um minuto, acho que vai demorar cerca de 6 meses, não um ano”. Passará um pouco mais de tempo e o Windows dirá: “Acho que consigo transferir o arquivo em 1 mês”. Será seguido pela mensagem “1 dia”, “6 horas”, “3 horas”, “1 hora”, “20 minutos”, “10 minutos”, “3 minutos”. Na verdade, todo o processo de transferência de arquivos levará apenas 3 minutos. Como isso aconteceu? Inicialmente, quando o seu dispositivo tenta se comunicar com outro dispositivo, ele envia um pacote e aguarda a confirmação. Se o aparelho esperar muito pela confirmação, ele pensa: “se eu tiver que transferir 2 GB de dados nessa velocidade, vai demorar uns 2 anos”. Depois de algum tempo, seu dispositivo recebe um ACK e pensa: “ok, enviei um pacote e recebi um ACK, portanto o destinatário pode receber 1 pacote. Agora vou tentar enviar-lhe 10 pacotes em vez de um.” O remetente envia 10 pacotes e depois de algum tempo recebe uma confirmação ACK do dispositivo receptor, o que significa que o destinatário está aguardando o próximo 11º pacote. O remetente pensa: “ótimo, já que o destinatário movimentou 10 pacotes de uma vez, agora vou tentar enviar 100 pacotes para ele em vez de dez”. Ele envia 100 pacotes e o destinatário responde que os recebeu e agora está aguardando 101 pacotes. Assim, com o tempo, o número de pacotes transmitidos aumenta.
É por isso que você observa uma rápida diminuição no tempo de cópia de arquivos em comparação com o que foi declarado originalmente - isso se deve à maior capacidade de transferência de grandes quantidades de dados. No entanto, chega um ponto em que novos aumentos no volume de transmissão se tornam impossíveis. Digamos que você enviou 10000 pacotes, mas o buffer do dispositivo receptor só pode aceitar 9000. Nesse caso, o receptor envia um ACK com a mensagem: "Recebi 9000 pacotes e agora estou pronto para receber 9001." A partir disso, o remetente conclui que o buffer do dispositivo receptor tem capacidade de apenas 9000, o que significa que a partir de agora não enviarei mais de 9000 pacotes por vez. Nesse caso, o remetente calcula rapidamente o tempo que levará para transferir a quantidade restante de dados em porções de 9000 pacotes e dá 3 minutos. Esses três minutos são o tempo real de transmissão. Isso é o que o TCP Windowing faz.
Este é um daqueles mecanismos de limitação de tráfego em que o dispositivo remetente eventualmente entende qual é a capacidade real da rede. Você deve estar se perguntando por que eles não concordam antecipadamente sobre qual é a capacidade do dispositivo receptor? O fato é que isso é tecnicamente impossível porque existem diferentes tipos de dispositivos na rede. Digamos que você tenha um iPad e ele tenha uma velocidade de transferência/recepção de dados diferente de um iPhone, você pode ter diferentes tipos de telefones ou talvez tenha um computador muito antigo. Portanto, cada pessoa tem largura de banda de rede diferente.
É por isso que foi desenvolvida a tecnologia TCP Windowing, quando a transmissão de dados começa em baixa velocidade ou com a transmissão de um número mínimo de pacotes, aumentando gradativamente a “janela” de tráfego. Você envia um pacote, 5 pacotes, 10 pacotes, 1000 pacotes, 10000 pacotes e aos poucos vai abrindo aquela janela cada vez mais até que a “abertura” atinja o volume máximo possível de tráfego enviado em um determinado período de tempo. Assim, o conceito de Windowing faz parte do funcionamento do protocolo TCP.
A seguir, veremos os números de porta mais comuns. A situação clássica é quando você tem 1 servidor principal, talvez um data center. Inclui um servidor de arquivos, servidor web, servidor de correio e servidor DHCP. Agora, se um dos computadores clientes entrar em contato com o data center, localizado no meio da imagem, ele começará a enviar tráfego do servidor de arquivos para os dispositivos clientes. Este tráfego é mostrado em vermelho e será transmitido em uma porta específica para uma aplicação específica de um servidor específico.
Como o servidor sabia para onde determinado tráfego deveria ir? Ele aprende isso com o número da porta de destino. Se você olhar o quadro, verá que em cada transferência de dados há uma menção ao número da porta de destino e ao número da porta de origem. Você pode ver que o tráfego azul e vermelho, e o tráfego azul é o tráfego do servidor web, ambos vão para o mesmo servidor físico, que possui servidores diferentes instalados. Se for um data center, ele usa servidores virtuais. Então, como eles sabiam que o tráfego vermelho deveria voltar para o laptop esquerdo com aquele endereço IP? Eles sabem disso graças aos números das portas. Se você consultar o artigo da Wikipedia “Lista de portas TCP e UDP”, verá que ele lista todos os números de porta padrão.
Se você rolar esta página para baixo, poderá ver o quão grande é essa lista. Ele contém aproximadamente 61 números. Os números de porta de 000 a 1 são conhecidos como os números de porta mais comuns. Por exemplo, a porta 1024/TCP é para envio de comandos ftp, a porta 21 é para ssh, a porta 22 é para Telnet, ou seja, para envio de mensagens não criptografadas. A muito popular porta 23 transporta dados por HTTP, enquanto a porta 80 transporta dados criptografados por HTTPS, que é semelhante à versão segura do HTTP.
Algumas portas são dedicadas tanto para TCP quanto para UDP, e algumas executam tarefas diferentes dependendo se a conexão é TCP ou UDP. Portanto, oficialmente a porta 80 TCP é usada para HTTP, e não oficialmente a porta 80 UDP é usada para HTTP, mas sob um protocolo HTTP diferente - QUIC.
Portanto, os números de porta no TCP nem sempre têm a mesma função que no UDP. Você não precisa memorizar esta lista, é impossível lembrar, mas você precisa saber alguns números de porta populares e comuns. Como eu disse, algumas dessas portas têm uma finalidade oficial, que está descrita nas normas, e algumas têm uma finalidade não oficial, como é o caso do Chromium.
Portanto, esta tabela lista todos os números de porta comuns e esses números são usados para enviar e receber tráfego ao usar aplicativos específicos.
Agora vamos ver como os dados se movem pela rede com base nas poucas informações que conhecemos. Digamos que o computador 10.1.1.10 queira entrar em contato com este computador, ou este servidor, que possui o endereço 30.1.1.10. Abaixo do endereço IP de cada dispositivo está seu endereço MAC. Estou dando o exemplo de um endereço MAC com apenas os últimos 4 caracteres, mas na prática é um número hexadecimal de 48 bits com 12 caracteres. Como cada um desses números consiste em 4 bits, 12 dígitos hexadecimais representam um número de 48 bits.
Como sabemos, se este dispositivo quiser entrar em contato com este servidor, primeiro deve ser feito o primeiro passo do handshake de 3 vias, ou seja, enviar um pacote SYN. Quando esta solicitação for feita, o computador 10.1.1.10 especificará o número da porta de origem, que o Windows cria dinamicamente. O Windows seleciona aleatoriamente um número de porta entre 1 e 65,000. Mas como os números iniciais no intervalo de 1 a 1024 são amplamente conhecidos, neste caso o sistema considerará números maiores que 25000 e criará uma porta de origem aleatória, por exemplo, o número 25113.
A seguir, o sistema irá adicionar uma porta de destino ao pacote, neste caso é a porta 21, pois a aplicação que está tentando se conectar a este servidor FTP sabe que deve enviar tráfego FTP.
Em seguida, nosso computador diz: “Ok, meu endereço IP é 10.1.1.10 e preciso entrar em contato com o endereço IP 30.1.1.10”. Ambos os endereços também são incluídos no pacote para formar uma solicitação SYN, e esse pacote não será alterado até o final da conexão.
Quero que você entenda neste vídeo como os dados se movem pela rede. Quando nosso computador que envia a solicitação vê o endereço IP de origem e o endereço IP de destino, ele entende que o endereço de destino não está nessa rede local. Esqueci de dizer que todos esses são endereços IP /24. Portanto, se você observar os endereços IP /24, perceberá que os computadores 10.1.1.10 e 30.1.1.10 não estão na mesma rede. Assim, o computador que envia a solicitação entende que para sair desta rede deverá entrar em contato com o gateway 10.1.1.1, que está configurado em uma das interfaces do roteador. Ele sabe que deveria ir para 10.1.1.1 e conhece seu endereço MAC 1111, mas não conhece o endereço MAC do gateway 10.1.1.1. O que ele está fazendo? Ele envia uma solicitação ARP de transmissão que todos os dispositivos da rede receberão, mas apenas o roteador com endereço IP 10.1.1.1 responderá a ela.
O roteador responderá com seu endereço MAC AAAA, e os endereços MAC de origem e destino também serão colocados neste quadro. Assim que o quadro estiver pronto, uma verificação de integridade de dados CRC, que é um algoritmo para encontrar uma soma de verificação para detectar erros, será realizada antes de sair da rede.
Redundância Cíclica CRC significa que todo esse quadro, desde o SYN até o último endereço MAC, é executado por meio de um algoritmo de hash, digamos MD5, resultando em um valor de hash. O valor hash, ou soma de verificação MD5, é então colocado no início do quadro.
Eu o rotulei de FCS/CRC porque FCS é uma sequência de verificação de quadro, um valor CRC de quatro bytes. Algumas pessoas usam a designação FCS e outras a designação CRC, então incluí apenas as duas designações. Mas basicamente é apenas um valor hash. É necessário garantir que todos os dados recebidos pela rede não contenham erros. Portanto, quando esse quadro chegar ao roteador, a primeira coisa que o roteador fará é calcular a própria soma de verificação e compará-la com o valor FCS ou CRC que o quadro recebido contém. Desta forma ele poderá verificar se os dados recebidos pela rede não contêm erros, após o que removerá o checksum do quadro.
Em seguida, o roteador examinará o endereço MAC e dirá: “Ok, endereço MAC AAAA significa que o quadro está endereçado a mim” e excluirá a parte do quadro que contém os endereços MAC.
Olhando para o endereço IP de destino 30.1.1.10, ele entenderá que este pacote não é endereçado a ele e deve seguir adiante pelo roteador.
Agora o roteador “pensa” que precisa ver onde está localizada a rede com o endereço 30.1.1.10. Ainda não cobrimos o conceito completo de roteamento, mas sabemos que os roteadores possuem uma tabela de roteamento. Esta tabela possui uma entrada para a rede com endereço 30.1.1.0. Como você lembra, este não é o endereço IP do host, mas o identificador da rede. O roteador “pensará” que pode chegar ao endereço 30.1.1.0/24 passando pelo roteador 20.1.1.2.
Você pode perguntar: como ele sabe disso? Apenas tenha em mente que ele saberá disso pelos protocolos de roteamento ou pelas suas configurações se você, como administrador, tiver configurado uma rota estática. Mas em qualquer caso, a tabela de roteamento deste roteador contém a entrada correta, então ele sabe que deve enviar este pacote para 20.1.1.2. Supondo que o roteador já conheça o endereço MAC de destino, simplesmente continuaremos encaminhando o pacote. Caso ele não conheça esse endereço, ele iniciará o ARP novamente, receberá o endereço MAC 20.1.1.2 do roteador e o processo de envio do quadro continuará novamente.
Portanto, presumimos que ele já conhece o endereço MAC, então teremos o endereço MAC de origem BBB e o endereço MAC de destino CCC. O roteador calcula novamente o FCS/CRC e o coloca no início do quadro.
Em seguida, ele envia esse quadro pela rede, o quadro chega ao roteador 20.1.12, verifica a soma de verificação, certifica-se de que os dados não estão corrompidos e exclui o FCS/CRC. Em seguida, ele "trunca" os endereços MAC, olha o destino e vê que é 30.1.1.10. Ele sabe que esse endereço está conectado à sua interface. O mesmo processo de formação de quadro é repetido, o roteador adiciona os valores dos endereços MAC de origem e destino, faz o hash, anexa o hash ao quadro e o envia pela rede.
Nosso servidor, tendo finalmente recebido a solicitação SYN endereçada a ele, verifica a soma de verificação do hash e, se o pacote não contiver erros, exclui o hash. Aí ele remove os endereços MAC, olha o endereço IP e percebe que esse pacote é endereçado a ele.
Depois disso, ele trunca os endereços IP relacionados à terceira camada do modelo OSI e analisa os números das portas.
Ele vê a porta 21, que significa tráfego FTP, vê o SYN e portanto entende que alguém está tentando se comunicar com ele.
Agora, com base no que aprendemos sobre o handshake, o servidor 30.1.1.10 criará um pacote SYN/ACK e o enviará de volta ao computador 10.1.1.10. Ao receber este pacote, o dispositivo 10.1.1.10 irá criar um ACK, passá-lo pela rede da mesma forma que um pacote SYN, e após o servidor receber o ACK, a conexão será estabelecida.
Uma coisa que você deve saber é que tudo isso acontece em menos de um segundo. Este é um processo muito, muito rápido, que tentei desacelerar para que tudo ficasse claro para vocês.
Espero que você ache útil o que aprendeu neste tutorial. Se você tiver alguma dúvida, escreva para mim em [email protegido] ou deixe perguntas neste vídeo.
A partir da próxima lição, selecionarei as 3 questões mais interessantes do YouTube, que analisarei ao final de cada vídeo. A partir de agora terei uma seção "Principais Perguntas", então postarei uma pergunta junto com seu nome e responderei ao vivo. Acho que isso será benéfico.
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, 30% de desconto para usuários do Habr em um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD 1 Gbps grátis até o verão ao pagar por um período de seis meses, você pode solicitar .
Dell R730xd 2 vezes mais barato? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com