Antes de comezar o vídeo tutorial de hoxe, quero agradecer a todos os que contribuíron á popularidade do meu curso en YouTube. Cando o comecei hai uns 8 meses, non esperaba tal éxito: hoxe as miñas clases foron vistas por 312724 persoas, teño 11208 subscritores. Nunca soñei que este humilde comezo chegaría a tales alturas. Pero non perdamos o tempo e vaiamos directamente á lección de hoxe. Hoxe imos cubrir os baleiros que se produciron nas últimas 7 leccións de vídeo. Aínda que hoxe é só o día 6, o día 3 dividiuse en 3 leccións de vídeo, polo que hoxe verás a oitava lección de vídeo.
Hoxe trataremos 3 temas importantes: DHCP, transporte TCP e os números de porto máis comúns. Xa falamos dos enderezos IP, e un dos factores máis importantes na configuración de enderezos IP é DHCP.
DHCP significa Dynamic Host Configuration Protocol e é un protocolo que axuda a configurar dinámicamente enderezos IP para hosts. Entón, todos vimos esta fiestra. Cando fai clic na opción "Obter un enderezo IP automaticamente", o ordenador busca un servidor DHCP que estea configurado na mesma subrede e envía varios paquetes e solicitudes para o enderezo IP. O protocolo DHCP ten 6 mensaxes, das cales 4 son fundamentais para asignar un enderezo IP.
A primeira mensaxe é unha mensaxe DHCP DISCOVERY. A mensaxe de descubrimento de DHCP é semellante a unha mensaxe de saúdo. Cando un novo dispositivo se une á rede, pregunta se hai un servidor DHCP na rede.
O que ves na diapositiva parece unha solicitude de difusión onde o dispositivo contacta con todos os dispositivos da rede buscando un servidor DHCP. Como dixen, esta é unha solicitude de emisión, polo que todos os dispositivos da rede poden escoitala.
Se hai un servidor DHCP na rede, envía un paquete: unha oferta de OFERTA DHCP. A proposta significa que o servidor DHCP, en resposta a unha solicitude de descubrimento, envía unha configuración ao cliente solicitando ao cliente que acepte un enderezo IP específico.
O servidor DHCP reserva un enderezo IP, neste caso 192.168.1.2, non o proporciona, senón que reserva este enderezo para o dispositivo. Ao mesmo tempo, o paquete de oferta contén o seu propio enderezo IP do servidor DHCP.
Se nesta rede hai máis dun servidor DHCP, outro servidor DHCP, ao recibir a solicitude de difusión do cliente, tamén lle ofrecería o seu enderezo IP, por exemplo, 192.168.1.50. Non é común ter dous servidores DHCP diferentes configurados na mesma rede, pero ás veces ocorre. Así, cando se envía unha oferta DHCP a un cliente, este recibe 2 ofertas DHCP e agora debe decidir que oferta DHCP quere aceptar.
Supoñamos que o cliente acepta a primeira solicitude. Isto significa que o cliente envía unha solicitude DHCP REQUEST que literalmente di "Acepto o enderezo IP 192.168.1.2 ofrecido polo servidor DHCP 192.168.1.1".
Ao recibir a solicitude, o servidor DHCP 192.168.1.1 responde "vale, admítoo", é dicir, recoñece a solicitude e envía este ACK DHCP ao cliente. Pero lembramos que outro servidor DHCP reservou un enderezo IP de 1.50 para o cliente. Unha vez que recibe a solicitude de difusión dun cliente, saberá sobre o fallo e volverá poñer ese enderezo IP no grupo para poder asignalo a outro cliente se recibe outra solicitude.
Estas son as 4 mensaxes críticas que intercambia DHCP ao asignar enderezos IP. A continuación, DHCP ten 2 mensaxes de información máis. O cliente emite unha mensaxe informativa se require máis información da que recibiu na cláusula DHCP OFFER no segundo paso. Se o servidor non forneceu información suficiente na oferta DHCP ou se o cliente necesita máis información que a contida no paquete de oferta, solicita información adicional de DHCP. Hai unha mensaxe máis que o cliente envía ao servidor - este é o DHCP RELEASE. Infórmalle que o cliente quere liberar o seu enderezo IP existente.
Non obstante, o que máis adoita suceder é que o usuario desconecta da rede antes de que o cliente teña tempo de enviar un RELEASE DHCP ao servidor. Isto ocorre cando apagas o ordenador, o que facemos nós. Neste caso, o cliente de rede, ou o ordenador, simplemente non ten tempo para informar ao servidor para que libere o enderezo utilizado, polo que a LIBERACIÓN DHCP non é un paso obrigatorio. Os pasos necesarios para obter un enderezo IP son: descubrimento de DHCP, oferta de DHCP, solicitude de DHCP e enlace de DHCP.
Nunha das próximas leccións contarei como configuramos un servidor DHCP ao crear un grupo DNCP. Por agrupación queremos dicir que lle indica ao servidor que asigne enderezos IP no intervalo 192.168.1.1 a 192.168.1.254. Así, o servidor DHCP creará un grupo, colocará nel 254 enderezos IP e poderá asignar enderezos aos clientes da rede só desde este grupo. Polo tanto, isto é algo así como unha configuración administrativa que pode facer o usuario.
Agora vexamos a transmisión TCP. Non sei se estás familiarizado co "teléfono" que aparece na imaxe, pero cando eramos pequenos utilizabamos estas latas conectadas por unha corda para falar entre nós.
Desafortunadamente, a xeración actual non pode permitirse tal "luxo". Quero dicir que hoxe os nenos están diante da televisión dende un ano, xogan a PSP e quizais isto sexa discutible, pero creo que tivemos a mellor infancia, saímos fóra e xogamos e os nenos de hoxe non se poden apartar do sofá. .
O meu fillo só ten un ano e xa vexo que é adicto ao iPad, quero dicir que aínda é moi pequeno pero creo que os nenos de hoxe xa nacen sabendo manexar os aparellos electrónicos. Entón, quería dicir que de pequenos, cando xogabamos, facíamos buratos nas latas, e cando as atabamos cun cordel e dicíamos algo nunha lata, polo outro lado a persoa podía escoitar o que se dicía. a el, simplemente poñendo a lata na orella. Polo tanto, é moi semellante a unha conexión de rede.
Hoxe, incluso as transferencias TCP deben ter unha conexión que debe establecerse antes de que comece a transferencia de datos real. Como comentamos en leccións anteriores, TCP é transmisión orientada á conexión mentres que UDP é transmisión orientada á conexión. Poderíase dicir que a UDP é onde lanzo a pelota e tócache a ver se a colles. Se estás preparado para facelo ou non non é o meu problema, só vou deixalo.
TCP é máis parecido a falar cun rapaz e avisarlle con antelación que vas lanzar unha pelota, así que creas un vínculo, e despois lanzas a pelota para que o teu compañeiro teña máis probabilidades de que estea preparado para collela. Entón, TCP realmente constrúe a conexión e despois comeza a facer a transmisión real.
Vexamos como crea esa conexión. Este protocolo usa un apretón de mans de 3 vías para crear unha conexión. Este non é un termo moi técnico, pero hai tempo que se usa para describir unha conexión TCP. O dispositivo de envío inicia un apretón de mans de 3 vías, co cliente que envía un paquete cunha bandeira SYN ao servidor.
Digamos que a nena do primeiro plano, cuxa cara podemos ver, é o dispositivo A, e a rapaza do fondo, cuxa cara non é visible, é o dispositivo B. A rapaza A envía un paquete SYN á rapaza B e ela di: “Estupendo, quen- entón quere comunicarse comigo. Entón, teño que responder que estou preparado para comunicarme!" Como facelo? Pódese simplemente enviar outro paquete SYN e despois un ACK que indica a recepción do paquete SYN orixinal. Pero en lugar de enviar ACK por separado, o servidor forma un paquete común que contén o SYN e o ACK e transmíteo pola rede.
Polo tanto, neste momento, o dispositivo A enviou un paquete SYN e recibiu de volta un paquete SYN/ACK. Agora o dispositivo A debe enviar ao dispositivo B un paquete ACK, é dicir, confirmar que recibiu o consentimento do dispositivo B para establecer a comunicación. Así, ambos os dispositivos recibiron paquetes SYN e ACK, e agora podemos dicir que se estableceu a conexión, é dicir, que se completou un apretón de mans en 3 etapas mediante o protocolo TCP.
A continuación veremos a tecnoloxía TCP Windowing. En pocas palabras, é un método usado en TCP/IP para negociar as capacidades do emisor e do receptor.
Digamos que en Windows estamos tentando transferir un ficheiro grande, digamos 2 GB de tamaño, dunha unidade a outra. Ao comezo da transferencia, o sistema informaranos de que a transferencia de ficheiros levará aproximadamente 1 ano. Pero uns segundos despois, o sistema corrixirase e dirá: "Oh, espera un minuto, creo que tardará uns 6 meses, non un ano". Pasará un pouco máis de tempo e Windows dirá: "Creo que poida transferir o ficheiro nun mes". Estará seguida da mensaxe "1 día", "1 horas", "6 horas", "3 hora", "1 minutos", "20 minutos", "10 minutos". De feito, todo o proceso de transferencia de ficheiros só levará 3 minutos. Como pasou isto? Inicialmente, cando o dispositivo tenta comunicarse con outro dispositivo, envía un paquete e agarda a súa confirmación. Se o dispositivo espera moito tempo para a confirmación, pensa: "se teño que transferir 3 GB de datos a esta velocidade, tardará uns 2 anos". Despois dun tempo, o teu dispositivo recibe un ACK e pensa: "Está ben, enviei un paquete e recibín un ACK, polo que o destinatario pode recibir 2 paquete. Agora intentarei enviarlle 1 paquetes en lugar dun". O remitente envía 10 paquetes e despois dun tempo recibe unha confirmación ACK do dispositivo receptor, o que significa que o destinatario está esperando o seguinte paquete, undécimo. O remitente pensa: "Está ben, xa que o destinatario manexou 10 paquetes á vez, agora intentarei enviarlle 11 paquetes en lugar de dez". Envía 10 paquetes e o destinatario responde que os recibiu e que agora agarda por 100 paquetes. Así, co paso do tempo, o número de paquetes transmitidos aumenta.
É por iso que ves unha rápida diminución do tempo de copia de ficheiros en comparación co que se indicaba orixinalmente; isto débese á maior capacidade de transferir grandes cantidades de datos. Non obstante, chega un momento no que se fan imposibles novos aumentos no volume de transmisión. Digamos que enviou 10000 paquetes, pero o búfer do dispositivo do receptor só pode aceptar 9000. Neste caso, o receptor envía un ACK coa mensaxe: "Recibín 9000 paquetes e agora estou preparado para recibir 9001". A partir diso, o remitente conclúe que o búfer do dispositivo receptor ten unha capacidade de só 9000, o que significa que a partir de agora non enviarei máis de 9000 paquetes á vez. Neste caso, o remitente calcula rapidamente o tempo que lle levará transferir a cantidade de datos restante en porcións de 9000 paquetes e dálle 3 minutos. Estes tres minutos son o tempo de transmisión real. Iso é o que fai TCP Windowing.
Este é un deses mecanismos de limitación do tráfico nos que o dispositivo emisor finalmente comprende cal é a capacidade real da rede. Quizais se estea preguntando por que non poden poñerse de acordo de antemán sobre cal é a capacidade do dispositivo receptor? O caso é que isto é tecnicamente imposible porque hai diferentes tipos de dispositivos na rede. Digamos que tes un iPad e ten unha velocidade de transferencia/receptor de datos diferente á dun iPhone, podes ter diferentes tipos de teléfonos ou quizais teñas un ordenador moi antigo. Polo tanto, todos teñen un ancho de banda de rede diferente.
É por iso que se desenvolveu a tecnoloxía TCP Windowing, cando a transmisión de datos comeza a baixa velocidade ou coa transmisión dun número mínimo de paquetes, aumentando gradualmente a "xanela" de tráfico. Envías un paquete, 5 paquetes, 10 paquetes, 1000 paquetes, 10000 paquetes e abres lentamente esa ventá cada vez máis ata que a "apertura" alcance o máximo volume posible de tráfico enviado nun período de tempo específico. Así, o concepto de Windowing forma parte do funcionamento do protocolo TCP.
A continuación veremos os números de porto máis comúns. A situación clásica é cando tes 1 servidor principal, quizais un centro de datos. Inclúe un servidor de ficheiros, un servidor web, un servidor de correo e un servidor DHCP. Agora, se un dos ordenadores cliente contacta co centro de datos, que está situado no medio da imaxe, comezará a enviar tráfico do servidor de ficheiros aos dispositivos cliente. Este tráfico móstrase en vermello e transmitirase nun porto específico para unha aplicación específica desde un servidor específico.
Como sabía o servidor a onde debería ir certo tráfico? El aprende isto co número de porto de destino. Se miras o cadro, verás que en cada transferencia de datos hai unha mención do número de porto de destino e o número de porto de orixe. Podes ver que o tráfico azul e vermello, e o tráfico azul é o tráfico do servidor web, ambos van ao mesmo servidor físico, que ten diferentes servidores instalados. Se este é un centro de datos, entón usa servidores virtuais. Entón, como souberon que o tráfico vermello debía volver a ese portátil esquerdo con ese enderezo IP? Sábeno grazas aos números de porto. Se te refires ao artigo da Wikipedia "Lista de portos TCP e UDP", verás que enumera todos os números de porto estándar.
Se te desplazas cara abaixo nesta páxina poderás ver o grande que é esta lista. Contén aproximadamente 61 números. Os números de porto do 000 ao 1 coñécense como os números de porto máis comúns. Por exemplo, o porto 1024/TCP é para enviar comandos ftp, o porto 21 é para ssh, o porto 22 é para Telnet, é dicir, para enviar mensaxes sen cifrar. O moi popular porto 23 transporta datos a través de HTTP, mentres que o porto 80 transporta datos cifrados a través de HTTPS, que é semellante á versión segura de HTTP.
Algúns portos están dedicados tanto a TCP como a UDP, e algúns realizan tarefas diferentes dependendo de se a conexión é TCP ou UDP. Entón, oficialmente o porto TCP 80 úsase para HTTP, e non oficialmente o porto UDP 80 para HTTP, pero baixo un protocolo HTTP diferente: QUIC.
Polo tanto, os números de porto en TCP non sempre pretenden facer o mesmo que en UDP. Non necesitas aprender esta lista de memoria, é imposible de lembrar, pero necesitas coñecer algúns números de porto populares e máis comúns. Como dixen, algúns destes portos teñen un propósito oficial, que se describe nos estándares, e algúns teñen un propósito non oficial, como é o caso de Chromium.
Entón, esta táboa enumera todos os números de porto comúns, e estes números úsanse para enviar e recibir tráfico cando se usan aplicacións específicas.
Agora vexamos como se moven os datos pola rede en función da pouca información que coñecemos. Digamos que o ordenador 10.1.1.10 quere contactar con este ordenador, ou con este servidor, que ten o enderezo 30.1.1.10. Debaixo do enderezo IP de cada dispositivo está o seu enderezo MAC. Estou dando o exemplo dun enderezo MAC con só os últimos 4 caracteres, pero na práctica é un número hexadecimal de 48 bits con 12 caracteres. Dado que cada un destes números consta de 4 bits, 12 díxitos hexadecimais representan un número de 48 bits.
Como sabemos, se este dispositivo quere contactar con este servidor, primeiro debe facerse o primeiro paso do apretón de mans de 3 vías, é dicir, enviar un paquete SYN. Cando se faga esta solicitude, o ordenador 10.1.1.10 especificará o número de porto de orixe, que Windows crea de forma dinámica. Windows selecciona aleatoriamente un número de porto entre 1 e 65,000. Pero dado que os números iniciais no rango de 1 a 1024 son amplamente coñecidos, neste caso o sistema considerará números superiores a 25000 e creará un porto de orixe aleatorio, por exemplo, o número 25113.
A continuación, o sistema engadirá un porto de destino ao paquete, neste caso é o porto 21, porque a aplicación que está tentando conectarse a este servidor FTP sabe que debe enviar tráfico FTP.
A continuación, o noso ordenador di: "Está ben, o meu enderezo IP é 10.1.1.10 e teño que contactar co enderezo IP 30.1.1.10". Estes dous enderezos tamén se inclúen no paquete para formar unha solicitude SYN, e este paquete non cambiará ata o final da conexión.
Quero que entendades a partir deste vídeo como se moven os datos pola rede. Cando o noso ordenador que envía a solicitude ve o enderezo IP de orixe e o enderezo IP de destino, entende que o enderezo de destino non está nesa rede local. Esquecín dicir que estes son todos os enderezos IP /24. Entón, se miras os enderezos IP /24, entenderás que os ordenadores 10.1.1.10 e 30.1.1.10 non están na mesma rede. Así, o ordenador que envía a solicitude entende que para saír desta rede debe contactar coa pasarela 10.1.1.1, que está configurada nunha das interfaces do enrutador. Sabe que debería ir a 10.1.1.1 e coñece o seu enderezo MAC de 1111, pero non coñece o enderezo MAC da pasarela 10.1.1.1. Que está facendo? Envía unha solicitude ARP de difusión que recibirán todos os dispositivos da rede, pero só responderá a ela o router con enderezo IP 10.1.1.1.
O router responderá co seu enderezo MAC AAAA e os enderezos MAC de orixe e destino tamén se colocarán neste marco. Unha vez que a trama estea lista, realizarase unha comprobación da integridade dos datos CRC, que é un algoritmo para atopar unha suma de verificación para detectar erros, antes de saír da rede.
CRC de redundancia cíclica significa que toda esta trama, desde o SYN ata o último enderezo MAC, execútase a través dun algoritmo de hash, digamos MD5, o que resulta nun valor hash. O valor hash, ou suma de verificación MD5, colócase entón ao principio do cadro.
Etiqueteino FCS/CRC porque FCS é unha secuencia de verificación de tramas, un valor CRC de catro bytes. Algunhas persoas usan a designación FCS e outras usan a designación CRC, polo que acabo de incluír ambas designacións. Pero basicamente é só un valor hash. É necesario asegurarse de que todos os datos recibidos pola rede non conteñan erros. Polo tanto, cando este marco chega ao router, o primeiro que fará o router é calcular a propia suma de verificación e comparala co valor FCS ou CRC que contén a trama recibida. Deste xeito, pode comprobar que os datos recibidos pola rede non conteñen erros, despois de que eliminará a suma de verificación do marco.
A continuación, o enrutador mirará o enderezo MAC e dirá: "Está ben, o enderezo MAC AAAA significa que o marco está dirixido a min" e eliminará a parte do cadro que contén os enderezos MAC.
Mirando o enderezo IP de destino 30.1.1.10, entenderá que este paquete non está dirixido a el e debe ir máis aló polo router.
Agora o enrutador "pensa" que necesita ver onde se atopa a rede co enderezo 30.1.1.10. Aínda non cubrimos o concepto completo de enrutamento, pero sabemos que os enrutadores teñen unha táboa de enrutamento. Esta táboa ten unha entrada para a rede co enderezo 30.1.1.0. Como lembras, este non é o enderezo IP do host, senón o identificador de rede. O enrutador "pensará" que pode chegar ao enderezo 30.1.1.0/24 pasando polo enrutador 20.1.1.2.
Podes preguntar, como sabe el? Só ten en conta que o saberá tanto polos protocolos de enrutamento como pola súa configuración se vostede, como administrador, configura unha ruta estática. Pero en calquera caso, a táboa de enrutamento deste enrutador contén a entrada correcta, polo que sabe que debería enviar este paquete a 20.1.1.2. Asumindo que o enrutador xa coñece o enderezo MAC de destino, simplemente seguiremos reenviando o paquete. Se non coñece este enderezo, iniciará de novo ARP, recibirá o enderezo MAC do router 20.1.1.2 e o proceso de envío da trama continuará de novo.
Polo tanto, asumimos que xa coñece o enderezo MAC, entón teremos o enderezo MAC de orixe BBB e o enderezo MAC de destino CCC. O router calcula de novo o FCS/CRC e colócao ao principio do cadro.
Despois envía esta trama pola rede, a trama chega ao router 20.1.12, comproba a suma de verificación, asegúrase de que os datos non estean corrompidos e elimina o FCS/CRC. Logo "trunca" os enderezos MAC, mira o destino e ve que é 30.1.1.10. Sabe que este enderezo está conectado á súa interface. O mesmo proceso de formación de cadros repítese, o enrutador engade os valores de enderezo MAC de orixe e destino, fai o hash, engádelle o hash ao cadro e envíao a través da rede.
O noso servidor, recibindo finalmente a solicitude SYN dirixida a el, comproba a suma de verificación hash e, se o paquete non contén erros, elimina o hash. Despois elimina os enderezos MAC, mira o enderezo IP e dáse conta de que este paquete está dirixido a el.
Despois diso, trunca os enderezos IP relacionados coa terceira capa do modelo OSI e mira os números de porto.
Ve o porto 21, que significa tráfico FTP, ve o SYN e, polo tanto, entende que alguén está intentando comunicarse con el.
Agora, segundo o que aprendemos sobre o apretón de mans, o servidor 30.1.1.10 creará un paquete SYN/ACK e enviarao de volta ao ordenador 10.1.1.10. Ao recibir este paquete, o dispositivo 10.1.1.10 creará un ACK, pasalo pola rede do mesmo xeito que un paquete SYN e, despois de que o servidor reciba o ACK, establecerase a conexión.
Unha cousa que debes saber é que todo isto ocorre en menos dun segundo. Este é un proceso moi, moi rápido, que tentei ralentizar para que che quedase todo claro.
Espero que che resulte útil o que aprendiches neste tutorial. Se tes algunha dúbida, escríbeme a [protexido por correo electrónico] ou deixa preguntas debaixo deste vídeo.
Comezando coa seguinte lección, seleccionarei as 3 preguntas máis interesantes de YouTube, que revisarei ao final de cada vídeo. A partir de agora terei unha sección "Preguntas principais" polo que publicarei unha pregunta xunto co teu nome e responderei en directo. Creo que isto será beneficioso.
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, Desconto do 30 % para os usuarios de Habr nun análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD 1 Gbps gratuíto ata o verán ao pagar por un período de seis meses, pode ordenar .
Dell R730xd 2 veces máis barato? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com