Antes de comenzar con el video tutorial de hoy, quiero agradecer a todos los que contribuyeron a la popularidad de mi curso en YouTube. Cuando lo comencé hace unos 8 meses, no esperaba tal éxito: hoy mis lecciones han sido vistas por 312724 personas y tengo 11208 suscriptores. Nunca soñé que este humilde comienzo alcanzaría tales alturas. Pero no perdamos el tiempo y vayamos directos a la lección de hoy. Hoy llenaremos los vacíos que ocurrieron en las últimas 7 lecciones en video. Aunque hoy es solo el día 6, el día 3 se dividió en 3 lecciones en video, por lo que hoy verás la octava lección en video.
Hoy cubriremos 3 temas importantes: DHCP, transporte TCP y los números de puerto más comunes. Ya hemos hablado de direcciones IP y uno de los factores más importantes en la configuración de direcciones IP es DHCP.
DHCP significa Protocolo de configuración dinámica de host y es un protocolo que ayuda a configurar dinámicamente direcciones IP para hosts. Entonces todos hemos visto esta ventana. Al hacer clic en la opción “Obtener una dirección IP automáticamente”, la computadora busca un servidor DHCP que esté configurado en la misma subred y envía varios paquetes y solicitudes de la dirección IP. El protocolo DHCP tiene 6 mensajes, de los cuales 4 son críticos para asignar una dirección IP.
El primer mensaje es un mensaje de DESCUBRIMIENTO de DHCP. El mensaje de descubrimiento de DHCP es similar a un mensaje de saludo. Cuando un nuevo dispositivo se une a la red, pregunta si hay un servidor DHCP en la red.
Lo que ve en la diapositiva parece una solicitud de transmisión en la que el dispositivo se comunica con todos los dispositivos de la red en busca de un servidor DHCP. Como dije, esta es una solicitud de transmisión, por lo que todos los dispositivos de la red pueden escucharla.
Si hay un servidor DHCP en la red, envía un paquete: una oferta de OFERTA DHCP. Propuesta significa que el servidor DHCP, en respuesta a una solicitud de descubrimiento, envía una configuración al cliente pidiéndole que acepte una dirección IP específica.
El servidor DHCP reserva una dirección IP, en este caso 192.168.1.2, no la proporciona, sino que reserva esta dirección para el dispositivo. Al mismo tiempo, el paquete de oferta contiene su propia dirección IP del servidor DHCP.
Si hay más de un servidor DHCP en esta red, otro servidor DHCP, al recibir la solicitud de transmisión del cliente, también le ofrecería su dirección IP, por ejemplo, 192.168.1.50. No es común tener dos servidores DHCP diferentes configurados en la misma red, pero a veces sucede. Entonces, cuando se envía una oferta de DHCP a un cliente, recibe 2 ofertas de DHCP y ahora debe decidir qué oferta de DHCP desea aceptar.
Supongamos que el cliente acepta la primera solicitud. Esto significa que el cliente envía una solicitud DHCP REQUEST que literalmente dice "Acepto la dirección IP 192.168.1.2 ofrecida por el servidor DHCP 192.168.1.1".
Al recibir la solicitud, el servidor DHCP 192.168.1.1 responde "está bien, lo admito", es decir, reconoce la solicitud y envía este DHCP ACK al cliente. Pero recordamos que otro servidor DHCP tiene reservada una dirección IP 1.50 para el cliente. Una vez que recibe la solicitud de transmisión de un cliente, sabrá sobre la falla y volverá a colocar esa dirección IP en el grupo para poder asignarla a otro cliente si recibe otra solicitud.
Estos son los 4 mensajes críticos que intercambia DHCP al asignar direcciones IP. A continuación, DHCP tiene 2 mensajes de información más. El cliente emite un mensaje de información si requiere más información de la que recibió en la cláusula DHCP OFERTA en el segundo paso. Si el servidor no proporcionó suficiente información en la oferta DHCP, o si el cliente necesita más información que la contenida en el paquete de oferta, solicita información DHCP adicional. Hay un mensaje más que el cliente envía al servidor: este es DHCP RELEASE. Le informa que el cliente desea liberar su dirección IP existente.
Sin embargo, lo que sucede más a menudo es que el usuario se desconecta de la red antes de que el cliente tenga tiempo de enviar una LIBERACIÓN DHCP al servidor. Esto sucede cuando apagas la computadora, lo cual hacemos. En este caso, el cliente de la red, o la computadora, simplemente no tiene tiempo para informar al servidor que libere la dirección utilizada, por lo que DHCP RELEASE no es un paso obligatorio. Los pasos necesarios para obtener una dirección IP son: descubrimiento de DHCP, oferta de DHCP, solicitud de DHCP y protocolo de enlace de DHCP.
En una de las próximas lecciones te contaré cómo configuramos un servidor DHCP al crear un grupo DNCP. Por agrupación queremos decir que le dice al servidor que asigne direcciones IP en el rango 192.168.1.1 a 192.168.1.254. Por lo tanto, el servidor DHCP creará un grupo, colocará en él 254 direcciones IP y podrá asignar direcciones a clientes en la red solo desde este grupo. Esto es algo así como una configuración administrativa que el usuario puede realizar.
Ahora veamos la transmisión TCP. No sé si estás familiarizado con el "teléfono" que aparece en la imagen, pero cuando éramos niños solíamos usar estas latas conectadas por una cuerda para hablar entre nosotros.
Desgraciadamente, la generación actual no puede permitirse ese “lujo”. Quiero decir, hoy en día los niños están frente al televisor desde que tienen un año, juegan a la PSP y tal vez esto sea discutible, pero creo que tuvimos la mejor infancia, de hecho salíamos y jugábamos y a los niños de hoy no se les puede sacar del sofá. .
Mi hijo solo tiene un año y ya veo que es adicto al iPad, osea aún es muy pequeño pero creo que los niños de hoy en día ya nacen sabiendo manejar los aparatos electrónicos. Entonces, quería decir que cuando éramos niños, cuando jugábamos, hacíamos agujeros en latas, y cuando las atábamos con una cuerda y decíamos algo en una lata, entonces, en el otro extremo, la persona podía escuchar lo que se decía. a él, simplemente poniéndole la lata en la oreja. Es muy similar a una conexión de red.
Hoy en día, incluso las transferencias TCP deben tener una conexión que debe establecerse antes de que comience la transferencia de datos real. Como comentamos en lecciones anteriores, TCP es una transmisión orientada a la conexión, mientras que UDP es una transmisión orientada a la conexión. Se podría decir que UDP es donde tiro la pelota y depende de ti ver si puedes atraparla. Si estás listo para hacerlo o no, no es mi problema, simplemente lo dejaré.
TCP es más como hablar con un chico y advertirle de antemano que vas a lanzar una pelota, entonces formas un vínculo y luego lanzas la pelota para que sea más probable que tu compañero esté listo para atraparla. Entonces TCP realmente construye la conexión y luego comienza a realizar la transmisión real.
Veamos cómo crea tal conexión. Este protocolo utiliza un protocolo de enlace de tres vías para crear una conexión. Este no es un término muy técnico, pero se ha utilizado durante mucho tiempo para describir una conexión TCP. El dispositivo emisor inicia un protocolo de enlace de tres vías y el cliente envía un paquete con un indicador SYN al servidor.
Digamos que la chica en primer plano, cuyo rostro podemos ver, es el dispositivo A, y la chica del fondo, cuyo rostro no es visible, es el dispositivo B. La chica A envía un paquete SYN a la chica B y ella dice: “Genial, quién-entonces quiere comunicarse conmigo. ¡Entonces necesito responder que estoy listo para comunicarme! ¿Cómo hacerlo? Se podría simplemente enviar otro paquete SYN y luego un ACK que indique la recepción del paquete SYN original. Pero en lugar de enviar ACK por separado, el servidor forma un paquete común que contiene SYN y ACK y lo transmite a través de la red.
Entonces, en este punto, el dispositivo A envió un paquete SYN y recibió un paquete SYN/ACK. Ahora el dispositivo A debe enviar al dispositivo B un paquete ACK, es decir, confirmar que ha recibido el consentimiento del dispositivo B para establecer comunicación. Así, ambos dispositivos recibieron paquetes SYN y ACK, y ahora podemos decir que se ha establecido la conexión, es decir, se ha completado un protocolo de enlace de 3 etapas utilizando el protocolo TCP.
A continuación veremos la tecnología de ventanas TCP. En pocas palabras, es un método utilizado en TCP/IP para negociar las capacidades del remitente y el receptor.
Digamos que en Windows estamos intentando transferir un archivo grande, digamos de 2 GB, de una unidad a otra. Al comienzo de la transferencia, el sistema nos informará que la transferencia del archivo tardará aproximadamente 1 año. Pero unos segundos después el sistema se corrige y dice: “oh, espera un minuto, creo que tardará unos 6 meses, no un año”. Pasará un poco más de tiempo y Windows dirá: "Creo que podría transferir el archivo en 1 mes". A esto le seguirá el mensaje “1 día”, “6 horas”, “3 horas”, “1 hora”, “20 minutos”, “10 minutos”, “3 minutos”. De hecho, todo el proceso de transferencia de archivos sólo te llevará 3 minutos. ¿Cómo pasó esto? Inicialmente, cuando su dispositivo intenta comunicarse con otro dispositivo, envía un paquete y espera confirmación. Si el dispositivo espera mucho tiempo la confirmación, piensa: “si tengo que transferir 2 GB de datos a esta velocidad, tardaré unos 2 años”. Después de un tiempo, su dispositivo recibe un ACK y piensa: "Está bien, envié un paquete y recibí un ACK, por lo tanto, el destinatario puede recibir 1 paquete". Ahora intentaré enviarle 10 paquetes en lugar de uno”. El remitente envía 10 paquetes y después de un tiempo recibe una confirmación ACK del dispositivo receptor, lo que significa que el destinatario está esperando el siguiente paquete número 11. El remitente piensa: “genial, como el destinatario manejó 10 paquetes a la vez, ahora intentaré enviarle 100 paquetes en lugar de diez”. Envía 100 paquetes y el destinatario responde que los recibió y ahora está esperando 101 paquetes. Por tanto, con el tiempo, aumenta el número de paquetes transmitidos.
Es por eso que observa una rápida disminución en el tiempo de copia de archivos en comparación con lo que se indicó originalmente; esto se debe a la mayor capacidad para transferir grandes cantidades de datos. Sin embargo, llega un momento en que resulta imposible seguir aumentando el volumen de transmisión. Supongamos que envió 10000 9000 paquetes, pero el búfer del dispositivo del receptor solo puede aceptar 9000. En este caso, el receptor envía un ACK con el mensaje: "He recibido 9001 paquetes y ahora estoy listo para recibir 9000". De esto, el remitente concluye que el buffer del dispositivo receptor tiene una capacidad de sólo 9000, lo que significa que de ahora en adelante no enviaré más de 9000 paquetes a la vez. En este caso, el remitente calcula rápidamente el tiempo que le llevará transferir la cantidad restante de datos en porciones de 3 paquetes y le da XNUMX minutos. Estos tres minutos son el tiempo real de transmisión. Eso es lo que hace TCP Windowing.
Este es uno de esos mecanismos de limitación del tráfico en los que el dispositivo emisor finalmente comprende cuál es la capacidad real de la red. Quizás se pregunte por qué no pueden ponerse de acuerdo de antemano sobre cuál es la capacidad del dispositivo receptor. El caso es que esto es técnicamente imposible porque existen diferentes tipos de dispositivos en la red. Digamos que tienes un iPad y tiene una velocidad de transferencia/recepción de datos diferente a la de un iPhone, es posible que tengas diferentes tipos de teléfonos o tal vez tengas una computadora muy antigua. Por lo tanto, cada uno tiene un ancho de banda de red diferente.
Es por eso que se desarrolló la tecnología TCP Windowing, cuando la transmisión de datos comienza a baja velocidad o con la transmisión de un número mínimo de paquetes, aumentando gradualmente la “ventana” de tráfico. Envías un paquete, 5 paquetes, 10 paquetes, 1000 paquetes, 10000 paquetes y lentamente abres esa ventana cada vez más hasta que la “apertura” alcanza el volumen máximo posible de tráfico enviado en un período de tiempo específico. Así, el concepto de Windowing forma parte del funcionamiento del protocolo TCP.
A continuación veremos los números de puerto más comunes. La situación clásica es cuando tienes 1 servidor principal, quizás un centro de datos. Incluye un servidor de archivos, un servidor web, un servidor de correo y un servidor DHCP. Ahora, si una de las computadoras cliente se comunica con el centro de datos, que se encuentra en el medio de la imagen, comenzará a enviar tráfico del servidor de archivos a los dispositivos cliente. Este tráfico se muestra en rojo y se transmitirá en un puerto específico para una aplicación específica desde un servidor específico.
¿Cómo supo el servidor adónde debía ir cierto tráfico? Lo aprende del número del puerto de destino. Si observa el cuadro, verá que en cada transferencia de datos se menciona el número de puerto de destino y el número de puerto de origen. Puede ver que el tráfico azul y rojo, y el tráfico azul es tráfico del servidor web, ambos van al mismo servidor físico, que tiene diferentes servidores instalados. Si se trata de un centro de datos, entonces utiliza servidores virtuales. Entonces, ¿cómo supieron que se suponía que el tráfico rojo regresaría a la computadora portátil izquierda con esa dirección IP? Lo saben gracias a los números de puerto. Si consulta el artículo de Wikipedia "Lista de puertos TCP y UDP", verá que enumera todos los números de puerto estándar.
Si se desplaza hacia abajo en esta página, podrá ver cuán grande es esta lista. Contiene aproximadamente 61 números. Los números de puerto del 000 al 1 se conocen como los números de puerto más comunes. Por ejemplo, el puerto 1024/TCP es para enviar comandos ftp, el puerto 21 es para ssh, el puerto 22 es para Telnet, es decir, para enviar mensajes no cifrados. El muy popular puerto 23 transporta datos a través de HTTP, mientras que el puerto 80 transporta datos cifrados a través de HTTPS, que es similar a la versión segura de HTTP.
Algunos puertos están dedicados tanto a TCP como a UDP, y algunos realizan diferentes tareas dependiendo de si la conexión es TCP o UDP. Entonces, oficialmente el puerto TCP 80 se usa para HTTP, y extraoficialmente el puerto UDP 80 se usa para HTTP, pero bajo un protocolo HTTP diferente: QUIC.
Por lo tanto, los números de puerto en TCP no siempre tienen la misma función que en UDP. No es necesario que se aprenda esta lista de memoria, es imposible recordarla, pero sí necesita conocer algunos de los números de puerto más populares y comunes. Como dije, algunos de estos ports tienen un propósito oficial, el cual está descrito en los estándares, y otros tienen un propósito no oficial, como es el caso de Chromium.
Entonces, esta tabla enumera todos los números de puerto comunes, y estos números se usan para enviar y recibir tráfico cuando se usan aplicaciones específicas.
Ahora veamos cómo se mueven los datos a través de la red en función de la poca información que conocemos. Digamos que la computadora 10.1.1.10 quiere contactar esta computadora, o este servidor, que tiene la dirección 30.1.1.10. Debajo de la dirección IP de cada dispositivo está su dirección MAC. Estoy dando el ejemplo de una dirección MAC con solo los últimos 4 caracteres, pero en la práctica es un número hexadecimal de 48 bits con 12 caracteres. Dado que cada uno de estos números consta de 4 bits, 12 dígitos hexadecimales representan un número de 48 bits.
Como sabemos, si este dispositivo quiere contactar con este servidor, primero se debe realizar el primer paso del protocolo de enlace de 3 vías, es decir, enviar un paquete SYN. Cuando se realiza esta solicitud, la computadora 10.1.1.10 especificará el número de puerto de origen, que Windows crea dinámicamente. Windows selecciona aleatoriamente un número de puerto entre 1 y 65,000. Pero dado que los números iniciales en el rango de 1 a 1024 son ampliamente conocidos, en este caso el sistema considerará números mayores que 25000 y creará un puerto de origen aleatorio, por ejemplo, el número 25113.
A continuación, el sistema agregará un puerto de destino al paquete, en este caso es el puerto 21, porque la aplicación que intenta conectarse a este servidor FTP sabe que debe enviar tráfico FTP.
A continuación, nuestra computadora dice: "Está bien, mi dirección IP es 10.1.1.10 y necesito comunicarme con la dirección IP 30.1.1.10". Ambas direcciones también se incluyen en el paquete para formar una solicitud SYN, y este paquete no cambiará hasta el final de la conexión.
Quiero que entiendas con este vídeo cómo se mueven los datos a través de la red. Cuando nuestra computadora que envía la solicitud ve la dirección IP de origen y la dirección IP de destino, entiende que la dirección de destino no está en esa red local. Olvidé decir que todas estas son direcciones IP /24. Entonces, si observa las direcciones IP /24, se dará cuenta de que las computadoras 10.1.1.10 y 30.1.1.10 no están en la misma red. Así, el ordenador que envía la solicitud entiende que para salir de esta red debe contactar con la puerta de enlace 10.1.1.1, que está configurada en una de las interfaces del router. Sabe que debe ir a 10.1.1.1 y conoce su dirección MAC de 1111, pero no conoce la dirección MAC de la puerta de enlace 10.1.1.1. ¿Qué está haciendo? Envía una solicitud ARP de difusión que recibirán todos los dispositivos de la red, pero solo el enrutador con la dirección IP 10.1.1.1 responderá.
El enrutador responderá con su dirección MAC AAAA y tanto la dirección MAC de origen como la de destino también se colocarán en esta trama. Una vez que la trama esté lista, antes de abandonar la red se realizará una verificación de integridad de datos CRC, que es un algoritmo para encontrar una suma de verificación para detectar errores.
Redundancia cíclica CRC significa que toda esta trama, desde SYN hasta la última dirección MAC, se ejecuta a través de un algoritmo hash, digamos MD5, lo que da como resultado un valor hash. Luego, el valor hash, o suma de comprobación MD5, se coloca al principio del cuadro.
Lo llamé FCS/CRC porque FCS es una secuencia de verificación de trama, un valor CRC de cuatro bytes. Algunas personas usan la designación FCS y otras usan la designación CRC, así que incluí ambas designaciones. Pero básicamente es sólo un valor hash. Es necesario asegurarse de que todos los datos recibidos a través de la red no contengan errores. Por lo tanto, cuando esta trama llegue al enrutador, lo primero que hará el enrutador será calcular la suma de comprobación y compararla con el valor FCS o CRC que contiene la trama recibida. De esta forma puede comprobar que los datos recibidos a través de la red no contienen errores, tras lo cual eliminará la suma de comprobación del marco.
A continuación, el enrutador mirará la dirección MAC y dirá: "Está bien, la dirección MAC AAAA significa que la trama está dirigida a mí" y eliminará la parte de la trama que contiene las direcciones MAC.
Al observar la dirección IP de destino 30.1.1.10, comprenderá que este paquete no está dirigido a él y debe continuar a través del enrutador.
Ahora el enrutador "piensa" que necesita ver dónde se encuentra la red con la dirección 30.1.1.10. Aún no hemos cubierto el concepto completo de enrutamiento, pero sabemos que los enrutadores tienen una tabla de enrutamiento. Esta tabla tiene una entrada para la red con dirección 30.1.1.0. Como recordará, esta no es la dirección IP del host, sino el identificador de red. El enrutador "pensará" que puede alcanzar la dirección 30.1.1.0/24 pasando por el enrutador 20.1.1.2.
Te preguntarás, ¿cómo sabe esto? Solo tenga en cuenta que lo sabrá por los protocolos de enrutamiento o por su configuración si usted, como administrador, ha configurado una ruta estática. Pero en cualquier caso, la tabla de enrutamiento de este enrutador contiene la entrada correcta, por lo que sabe que debe enviar este paquete a 20.1.1.2. Suponiendo que el enrutador ya conoce la dirección MAC de destino, simplemente continuaremos reenviando el paquete. Si no conoce esta dirección, iniciará ARP nuevamente, recibirá la dirección MAC 20.1.1.2 del enrutador y el proceso de envío de la trama continuará nuevamente.
Entonces asumimos que ya conoce la dirección MAC, entonces tendremos la dirección MAC de origen BBB y la dirección MAC de destino CCC. El enrutador calcula nuevamente el FCS/CRC y lo coloca al comienzo de la trama.
Luego envía esta trama a través de la red, la trama llega al enrutador 20.1.12, verifica la suma de verificación, se asegura de que los datos no estén dañados y elimina el FCS/CRC. Luego "trunca" las direcciones MAC, mira el destino y ve que es 30.1.1.10. Sabe que esta dirección está conectada a su interfaz. Se repite el mismo proceso de formación de tramas, el enrutador agrega los valores de las direcciones MAC de origen y destino, realiza el hash, adjunta el hash a la trama y lo envía a través de la red.
Nuestro servidor, después de recibir finalmente la solicitud SYN dirigida a él, verifica la suma de comprobación del hash y, si el paquete no contiene errores, elimina el hash. Luego elimina las direcciones MAC, mira la dirección IP y se da cuenta de que este paquete está dirigido a él.
Después de eso, trunca las direcciones IP relacionadas con la tercera capa del modelo OSI y mira los números de puerto.
Ve el puerto 21, que significa tráfico FTP, ve el SYN y, por lo tanto, comprende que alguien está intentando comunicarse con él.
Ahora, según lo que aprendimos sobre el protocolo de enlace, el servidor 30.1.1.10 creará un paquete SYN/ACK y lo enviará de regreso a la computadora 10.1.1.10. Al recibir este paquete, el dispositivo 10.1.1.10 creará un ACK, lo pasará a través de la red de la misma manera que un paquete SYN y, después de que el servidor reciba el ACK, se establecerá la conexión.
Una cosa que debes saber es que todo esto sucede en menos de un segundo. Este es un proceso muy, muy rápido, que intenté ralentizar para que todo quede claro para ustedes.
Espero que encuentres útil lo que aprendiste en este tutorial. Si tienes alguna pregunta, por favor escríbeme a [email protected] o deja preguntas debajo de este video.
A partir de la siguiente lección, seleccionaré las 3 preguntas más interesantes de YouTube, que revisaré al final de cada vídeo. De ahora en adelante tendré una sección de "Preguntas principales", así que publicaré una pregunta junto con tu nombre y la responderé en vivo. Creo que esto será beneficioso.
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, 30% de descuento para usuarios de Habr en un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD 1 Gbps gratis hasta el verano al pagar por un período de seis meses, puede ordenar .
Dell R730xd 2 veces más barato? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com