Buen día Paulo, llegué a tus videos y quedé con gusto a poco ya que me llevé la mala sorpresa que los demás videos no están disponibles. se agradece tu disposición y espero poder contar con el dinero para seguir estudiando. Gracias
+Manuel Adolfo Jara Torres hola! Sí, entiendo el "problema", pero lamentablemente el hacer material de estudio también involucra costos que se deben cubrir. De todos modos vamos a hacer el esfuerzo de crear más cursos y ver la posibilidad de bajar los precios y crear packs.
A vuelto! que grande Pablo. La de gente que hay en España estudiando «informática» con tus vídeos porque nuestros profesores son malísimos. Gracias por compartir tus enseñanzas.
+Paulo Colomés Ahora que sé que me lees permite que te de las gracias: Mil y una gracias. Tuvimos que estudiar CCNA en 5 meses con un profesor que era malo como pocos y que leía las diapositivas como el que se sienta frente al periódico. Nadie entendía nada. Alguien nos habló de un tal Pablo de UA-cam, un chileno, que era una maquina y tal... A los pocos dias tus videos estaban en boca de todos. Logré aprobar mi examen gracias a ti y tus explicaciones, sencillas y agradables a pesar de la materia. Ahora, un año después, un amigo que vive a 500 kilometros se ha puesto a estudiar CCNA y al parecer el profe no tiene ni idea. ¿Adivina quien es "su maestro" ahora? Nunca subestimes el poder de tus enseñanzas. Gracias por tu impecable trabajo.
No sabes lo importante que es para uno recibir ese tipo de comentarios. Yo he trabajado muchos años como docente universitario y sé exactamente lo tedioso que es tener un profesor que se dedique a leer PPTs como karaoke. Gracias por tu mensaje! Dale una vuelta a www.netlearning.cl si quieres que es donde estamos armando un proyecto ya mucho más profesional para poder ofrecer capacitación y cursos de especialización.
Al fin entiendo redes gracias a ti, no sabes la claridad que me estás dando HAHAAH, me daba pérdida en redes pero ahora siento que puedo con ello. GRACIAS y no puedo con que no hay más videos ;;.
Hola, Paulo. En el minuto: 19:26, comienzas a explicar la diferencia entre HTTP y HTTPS, eso lo tengo claro. La duda que me generaron las ilustraciones (las dos barras azules) es: ¿Qué sentido tiene una dirección IP con estos protocolos? Explico más a detalle mi pregunta: HTTP/TCP/80. HTTP (Es el protocolo utilizado), TCP (Es el protocolo de transporte) y 80 (Es el número de puerto) ¿Acaso el puerto tiene alguna relación con una dirección IP? o ¿Por qué es que se utiliza una? De antemano, mucha gracias.
+Ya St hola! Mira, es mucho más simple. Cuando se hace una conexión con cualquier protocolo de aplicación, sea HTTP, HTTPS, FTP, SSH, Telnet, SMTP, etc, etc, siempre el paquete IP estará compuesto de 3 cosas: 1) Encabezado IP 2) Encabezado de transporte 3) Datos de aplicación Algo así: [IP][TRANSPORTE][DATOS DE APP] Lo que va dentro del encabezado IP son, principalmente, las IP de origen y destino. Lo que va dentro del encabezado de transporte son, principalmente, los puertos de origen y destino (y varios campos más dependiendo si se usa UDP o TCP) y lo que va dentro de los datos de aplicación son justamente datos propios del protocolo de aplicación que se este úsando (HTTP, FTP, etc.) Ahora bien. En una consulta HTTP que va desde tu máquina hacia el servidor ficticio 88.123.123.123 siempre será algo así: [IP origen= x.x.x.x; IP destino:88.123.123.123][Puerto Origen: 47473; Puerto Destino:80][Datos de HTTP: GET, POST, etc] Algunas aclaraciones: - La IP de origen es la de tu máquina - La IP de destino es la del servidor remoto - El puerto de origen lo genera automáticamente el kernel de tu sistema operativo. Es dinámico y variable. - El puerto de destino es 80 (porque es HTTP) - El encabezado de transporte será TCP. La respuesta del servidor invierte los siguientes valores de destino a origen y viceversa: IP de origen --> IP Destino IP de destino --> IP Origen Puerto de Origen --> Puerto de Destino Puerto de Destino --> Puerto de Origen El hecho es que cuando se utiliza un protocolo de aplicación determinado, siempre se define (por estándar) automáticamente el puerto de destino y el protocolo de transporte. Así, es normal que una consulta HTTP utilice el puerto 80 TCP, mientras que un mensaje FTP utilizara el puerto 23 TCP y una consulta DNS utilizará el puerto 53 UDP. No sé si se entiende bien el ejemplo.
¿Qué tal, Pablo?. En el minuto: 21:56, explicas los datos del encabezado HTTP con el método GET. ¿Esos datos representan la PDU de la capa de aplicación? o ¿Son meramente datos del protocolo HTTP?Gracias.
+Ya St Esos son justamente datos propios del protocolo HTTP. La PDU de aplicación es un concepto genérico solamente para referirse a los datos. Si la transferencia fuese SMTP, parte de los datos serían por ejemplo los comandos EHLO de ese protocolo. Como el ejemplo era con HTTP, mencioné GET ;)
Hola ... buenisimo video ... muchas gracias por compartirlo... pero una cosa....cuando el cliente pide la conexion https y le llega la clave A (Asimetrica) y genera la clave A (Simetrica) y se la manda al server ... ¿la informacion no esta doblemente cifrada? ([Clave Asimetrica] ([Clave Simetrica] XXXXXXX) ) y si es asi... el cliente mantiene las 2 claves para los mensajes? primero cifra con la simetrica y luego con la asimetrica? gracias.
Hola Paulo. Quisiera tomar el curso completo para certificar posteriormente en CCNA. Previamente, me gustaría hacerte algunas consultas. Podremos contactarnos por mail?
Si, hola German. Los archivos de descarga, así como los labs, quizzes y certificados están disponibiles en el curso completo de pago NLA06 en www.netlearning.cl
De acuerdo Paulo, muchas gracias por responder. Haré un esfuerzo para pagar el curso completo, en verdad es muy interesante y de gran aprendizaje. Ojala que ya no suba el dolar :)
+Odraude zellet hola! Por ahora no queremos funcionar bajo el método de subscripción mensual porque simplemente no es conveniente ni para la academia ni para los alumnos. Una vez que generemos suficiente material como para poder ofrecer una subscripción que te permita acceder a todo el contenido, si ofreceremos la mensualidad, pero por el momento estamos construyendo muchos cursos y no queremos perjudicar ni ser aprovechadores con los usuarios.
Hola Steven. Todo eso lo puedes encontrar en www.netlearning.cl. Las opciones de pago son mediante PayPal o Tarjeta de Crédito directo en el sitio. Incluso a veces hemos podido aceptar transferencias via Western Union desde fuera de Chile con un recargo adicional.
Regular explicacion pero me quede corto, porq un DECODIFICADOR puede ver los mensajes encriptados conociendo los patrones encriptados? ejemplo: 1.- Todos los mensajes van encriptados 2.- Usuario A envia mensaje a servidor S (ua-cam.com/users/videox)mensaje QWERTY(encriptado) 3.- Usuario B envia mensaje a servidor S (ua-cam.com/users/videox)mensaje QWERTY(encriptado) Ahora mi duda es: si usuario A o B intercepta el mensaje encriptado del otro usuario no podria acaso conocer la peticion si ambos tienen la misma clave publica del servidor? es decir el servidor siempre responde con mensajes encriptados PREDECIBLES. YA se me diras la clave simetrica del usuario A no es igual a la de By las peticiones jamas seran iguales, pero mi duda es si la respuesta del servidor(mensaje encriptado) es la misma para todos los usuarios independiente ya q a pagina esta encriptada de antemano con una clave publica q esta en FUNCION DE UNA PRIVADA, si es asi por ingenieria inversa y suponiendo q el servidor es publico(como la mayoria) cada respuesta del servidor no esta verdaderamente encriptada solo CODIFICADA, y como dije por ingenieria inversa si se conoce el patron de respuesta del SERVIDOR con X mensajes "encriptados" tambien se conoce las peticiones de cualquier cliente. PD:Haber si alguien me corrige, porq yo no veo encriptacion en la explicacon sino CODIFICACION por parte del servidor q no es lo mismo, si el servidor crea una sesion y encripta cada peticion de cualquier cliente con la clave simetrica del cliente entonces ESTARIA ENCRIPTADA y seria muy dificil desencriptarla, creo q ESTA MUY MAL LA EXPLICACION EN DECIR Q LA CLAVE ASIMETRICA ES SEGURO, cuando en realidad es la ENCRIPTACION SIMETRICA LA Q SE USA y solo se usa la ENCRIPTACION ASIMETRICA PARA PROTEGER LA CLAVE SIMETRICA DEL USUARIO, muchos usuarios, profesores,etc cometen ese error aun asi yo no veo ENCRIPTACION SOLO CODIFICACION ¿porq? porq las paginas webs publicas no son dinamicas y reflejan PATRONES predecibles a menos q me digan q la clave simetrica del usuario es cambiada cada 20 segundos para joder cualquier sniffer metido entremedio, pero bueno para novatos la explicacion esta buena xD. PD2: Una forma sencilla de DECODIFICADOR basandome en el hecho de q las paginas no encriptan IMAGENES ¿porq? mucha carga de CPU en el servidor entonces si una pagina encriptada es solicitada por un usuario X y esta pagina contiene la imagen Y q no esta encriptada y hay un usuario Z sniffeando y ese usuario sabe q en la IP b.b.b.b. hay una 1 sola pagina q referencia a dicha imagen entonces DEDUCE la peticion del GET del usuario X en FUNCION DE DICHA IMAGEN, ahora bien si cambia esa imagen por un GIF animado con codigo malicioso para q ejecute X codigo javascript en el usuario X, entonces esta listo de nada serviria la "encriptacion" todo por unas imagenes no encriptadas, ahora bien supongamos q las imagenes estan encriptadas y el servidor es PODEROSO EN CPU y en encriptacion, aun asi me parece q cualquier codigo q no se mueve como las susodicha imagen es CODIFICACION y no encriptacion predecible por lo demas.
Hola Alanladron. Agradezco tu aporte tan detallado a esta discusión. No obstante, tienes razón en que la explicación es para novatos ya que este video corresponde a la primera parte del curso asociado a la certificación CCENT (Cisco Certified Entry Network Technician) la cual es de nivel inicial. Justamente lo que se busca en este curso es internar a los estudiantes en conceptos generales sin tener que profundizar demasiado a nivel técnico los conceptos. Luego, en cursos más avanzados se ve el detalle de los métodos criptográficos y todo eso. Cuando uno es profesor, debes comprender que uno no puede pretender que un alumno, que generalmente actúa de forma pasiva en una clase, absorba y entienda la totalidad de los conceptos técnicos en materia de redes ya que son muy difíciles para alguien que está comenzando a entender este mundo. Es por eso que quienes hacemos clases recurrimos a diferentes técnicas para lograr que los alumnos puedan asimilar de mejor manera tanto detalle y una de esas técnicas es utilizar explicaciones superficiales como las que hay en este video. Yo no puedo comenzar un curso de este nivel utilizando terminología avanzada como "sniffear" (aunque la palabra no existe, pero se entiende el concepto) y ni siquiera hablar de direcciones IP aún, porque todo es progresivo. Creo que en ese aspecto podemos tener una diferencia de conceptos entre tú y yo, porque tú dices que los profesores cometen el error de no explicar con totalidad los conceptos a nivel profundo y yo considero que justamente hay algunos profesores que cometen el error de comenzar a navegar en las más profundas aguas de los detalles técnicos de las tecnologías desde el día 1 que el alumno se sienta en su clase. Esto último a mi juicio está mal como metodología de enseñanza pero creo que a tu juicio está bien.
@@pcolomes totalmente de acuerdo contigo, en una clase que tengo el profe no explica muy bien porque todos los términos que dice son de carácter muy técnico y además no modula bien🤣🤣
5 años y al fin apareces para explicarme bien, al fin comprendo todo, gracias!!
Buen día Paulo, llegué a tus videos y quedé con gusto a poco ya que me llevé la mala sorpresa que los demás videos no están disponibles. se agradece tu disposición y espero poder contar con el dinero para seguir estudiando.
Gracias
+Manuel Adolfo Jara Torres hola!
Sí, entiendo el "problema", pero lamentablemente el hacer material de estudio también involucra costos que se deben cubrir.
De todos modos vamos a hacer el esfuerzo de crear más cursos y ver la posibilidad de bajar los precios y crear packs.
A vuelto! que grande Pablo. La de gente que hay en España estudiando «informática» con tus vídeos porque nuestros profesores son malísimos.
Gracias por compartir tus enseñanzas.
+Izan Tesla jaja... es que había perdido mi contraseña de UA-cam y me tomó meses recuperarla. Estoy de vuelta :)
+Paulo Colomés Ahora que sé que me lees permite que te de las gracias:
Mil y una gracias.
Tuvimos que estudiar CCNA en 5 meses con un profesor que era malo como pocos y que leía las diapositivas como el que se sienta frente al periódico. Nadie entendía nada. Alguien nos habló de un tal Pablo de UA-cam, un chileno, que era una maquina y tal... A los pocos dias tus videos estaban en boca de todos.
Logré aprobar mi examen gracias a ti y tus explicaciones, sencillas y agradables a pesar de la materia.
Ahora, un año después, un amigo que vive a 500 kilometros se ha puesto a estudiar CCNA y al parecer el profe no tiene ni idea. ¿Adivina quien es "su maestro" ahora?
Nunca subestimes el poder de tus enseñanzas.
Gracias por tu impecable trabajo.
No sabes lo importante que es para uno recibir ese tipo de comentarios. Yo he trabajado muchos años como docente universitario y sé exactamente lo tedioso que es tener un profesor que se dedique a leer PPTs como karaoke.
Gracias por tu mensaje! Dale una vuelta a www.netlearning.cl si quieres que es donde estamos armando un proyecto ya mucho más profesional para poder ofrecer capacitación y cursos de especialización.
+Paulo Colomés Gracias a ti, de verdad. Si algún día pasas por Madrid, buscame y te invito a un buen cocido, jajaja... ¡Qué menos?
jajaja lo tendré muy muy presente jajaja. Un abrazo.
Paulo. Muy buenos vídeos....He aprendido bastante..Estoy estudiando mucho para las certificaciones de CCNA S-R de cisco.
Gracias.
GRACIAS POR LOS VIDEOS SON MUY BUENOS!!!
Al fin entiendo redes gracias a ti, no sabes la claridad que me estás dando HAHAAH, me daba pérdida en redes pero ahora siento que puedo con ello.
GRACIAS y no puedo con que no hay más videos ;;.
Hola! el resto de los videos está en www.netlearning.cl ;)
Saludos desde Guayaquil-Ecuador
Adicto YA. Gracias Paulo
Hola, Paulo. En el minuto: 19:26, comienzas a explicar la diferencia entre HTTP y HTTPS, eso lo tengo claro. La duda que me generaron las ilustraciones (las dos barras azules) es: ¿Qué sentido tiene una dirección IP con estos protocolos? Explico más a detalle mi pregunta: HTTP/TCP/80. HTTP (Es el protocolo utilizado), TCP (Es el protocolo de transporte) y 80 (Es el número de puerto) ¿Acaso el puerto tiene alguna relación con una dirección IP? o ¿Por qué es que se utiliza una? De antemano, mucha gracias.
+Ya St hola! Mira, es mucho más simple. Cuando se hace una conexión con cualquier protocolo de aplicación, sea HTTP, HTTPS, FTP, SSH, Telnet, SMTP, etc, etc, siempre el paquete IP estará compuesto de 3 cosas:
1) Encabezado IP
2) Encabezado de transporte
3) Datos de aplicación
Algo así: [IP][TRANSPORTE][DATOS DE APP]
Lo que va dentro del encabezado IP son, principalmente, las IP de origen y destino. Lo que va dentro del encabezado de transporte son, principalmente, los puertos de origen y destino (y varios campos más dependiendo si se usa UDP o TCP) y lo que va dentro de los datos de aplicación son justamente datos propios del protocolo de aplicación que se este úsando (HTTP, FTP, etc.)
Ahora bien. En una consulta HTTP que va desde tu máquina hacia el servidor ficticio 88.123.123.123 siempre será algo así:
[IP origen= x.x.x.x; IP destino:88.123.123.123][Puerto Origen: 47473; Puerto Destino:80][Datos de HTTP: GET, POST, etc]
Algunas aclaraciones:
- La IP de origen es la de tu máquina
- La IP de destino es la del servidor remoto
- El puerto de origen lo genera automáticamente el kernel de tu sistema operativo. Es dinámico y variable.
- El puerto de destino es 80 (porque es HTTP)
- El encabezado de transporte será TCP.
La respuesta del servidor invierte los siguientes valores de destino a origen y viceversa:
IP de origen --> IP Destino
IP de destino --> IP Origen
Puerto de Origen --> Puerto de Destino
Puerto de Destino --> Puerto de Origen
El hecho es que cuando se utiliza un protocolo de aplicación determinado, siempre se define (por estándar) automáticamente el puerto de destino y el protocolo de transporte. Así, es normal que una consulta HTTP utilice el puerto 80 TCP, mientras que un mensaje FTP utilizara el puerto 23 TCP y una consulta DNS utilizará el puerto 53 UDP.
No sé si se entiende bien el ejemplo.
Claro que sí. Muchas gracias :)
¿Qué tal, Pablo?.
En el minuto: 21:56, explicas los datos del encabezado HTTP con el método GET. ¿Esos datos representan la PDU de la capa de aplicación? o ¿Son meramente datos del protocolo HTTP?Gracias.
+Ya St Esos son justamente datos propios del protocolo HTTP. La PDU de aplicación es un concepto genérico solamente para referirse a los datos. Si la transferencia fuese SMTP, parte de los datos serían por ejemplo los comandos EHLO de ese protocolo. Como el ejemplo era con HTTP, mencioné GET ;)
Hola ... buenisimo video ... muchas gracias por compartirlo... pero una cosa....cuando el cliente pide la conexion https y le llega la clave A (Asimetrica) y genera la clave A (Simetrica) y se la manda al server ... ¿la informacion no esta doblemente cifrada? ([Clave Asimetrica] ([Clave Simetrica] XXXXXXX) ) y si es asi... el cliente mantiene las 2 claves para los mensajes? primero cifra con la simetrica y luego con la asimetrica? gracias.
Hola Paulo. Quisiera tomar el curso completo para certificar posteriormente en CCNA. Previamente, me gustaría hacerte algunas consultas. Podremos contactarnos por mail?
Hola Carlos. Claro: pcolomes@netlearning.cl
Saludos
Que tal Paulo, mencionas que hay un archivo para el ejemplo con wireshark, ¿dónde lo puedo descargar? ¿o ya no está disponible? Que buenos videos.
Si, hola German. Los archivos de descarga, así como los labs, quizzes y certificados están disponibiles en el curso completo de pago NLA06 en www.netlearning.cl
De acuerdo Paulo, muchas gracias por responder. Haré un esfuerzo para pagar el curso completo, en verdad es muy interesante y de gran aprendizaje. Ojala que ya no suba el dolar :)
Qué tal. No hay forma de que la suscripción sea mensual? Ya que el precio anual es muy caro para mi. Suerte con este nuevo proyecto!
+Odraude zellet hola! Por ahora no queremos funcionar bajo el método de subscripción mensual porque simplemente no es conveniente ni para la academia ni para los alumnos. Una vez que generemos suficiente material como para poder ofrecer una subscripción que te permita acceder a todo el contenido, si ofreceremos la mensualidad, pero por el momento estamos construyendo muchos cursos y no queremos perjudicar ni ser aprovechadores con los usuarios.
No encuentro las 37 clases no se si me pueden ayudar por favor
Hola Paulo, me gustaría conocer el costo y como se realizaría el pago para continuar con el Curso. Gracias
Hola Steven. Todo eso lo puedes encontrar en www.netlearning.cl. Las opciones de pago son mediante PayPal o Tarjeta de Crédito directo en el sitio. Incluso a veces hemos podido aceptar transferencias via Western Union desde fuera de Chile con un recargo adicional.
Vale Pualo te agradezco ya que me encuentro en Bogotá - Colombia. de paso te digo que el material esta excelente, pasa buen día.
saludos, tambien existe la comunidad linux jeje
Cuando uno se inscribe en el curso por 35 USD hay que seguir pagando cierta cuota? En netlearning no especifica.
+Oscarlyn Garcia Hola! No hay que seguir pagando. Es solo una vez.
Saludos
que paso con los demas justo comienzo vacaciones y solo veo 04/37 y los demas ???
Hola! Este es un preview gratuito del curso completo que está disponible en www.netlearning.cl
Saludos
Paulo Colomés wowww me demore en verlo antes estaba todo aquí 😔😔😔
HTTPS no garantiza que no se intercepte la información
😩💔
Regular explicacion pero me quede corto, porq un DECODIFICADOR puede ver los mensajes encriptados conociendo los patrones encriptados? ejemplo:
1.- Todos los mensajes van encriptados
2.- Usuario A envia mensaje a servidor S (ua-cam.com/users/videox)mensaje QWERTY(encriptado)
3.- Usuario B envia mensaje a servidor S (ua-cam.com/users/videox)mensaje QWERTY(encriptado)
Ahora mi duda es: si usuario A o B intercepta el mensaje encriptado del otro usuario no podria acaso conocer la peticion si ambos tienen la misma clave publica del servidor? es decir el servidor siempre responde con mensajes encriptados PREDECIBLES.
YA se me diras la clave simetrica del usuario A no es igual a la de By las peticiones jamas seran iguales, pero mi duda es si la respuesta del servidor(mensaje encriptado) es la misma para todos los usuarios independiente ya q a pagina esta encriptada de antemano con una clave publica q esta en FUNCION DE UNA PRIVADA, si es asi por ingenieria inversa y suponiendo q el servidor es publico(como la mayoria) cada respuesta del servidor no esta verdaderamente encriptada solo CODIFICADA, y como dije por ingenieria inversa si se conoce el patron de respuesta del SERVIDOR con X mensajes "encriptados" tambien se conoce las peticiones de cualquier cliente.
PD:Haber si alguien me corrige, porq yo no veo encriptacion en la explicacon sino CODIFICACION por parte del servidor q no es lo mismo, si el servidor crea una sesion y encripta cada peticion de cualquier cliente con la clave simetrica del cliente entonces ESTARIA ENCRIPTADA y seria muy dificil desencriptarla, creo q ESTA MUY MAL LA EXPLICACION EN DECIR Q LA CLAVE ASIMETRICA ES SEGURO, cuando en realidad es la ENCRIPTACION SIMETRICA LA Q SE USA y solo se usa la ENCRIPTACION ASIMETRICA PARA PROTEGER LA CLAVE SIMETRICA DEL USUARIO, muchos usuarios, profesores,etc cometen ese error aun asi yo no veo ENCRIPTACION SOLO CODIFICACION ¿porq? porq las paginas webs publicas no son dinamicas y reflejan PATRONES predecibles a menos q me digan q la clave simetrica del usuario es cambiada cada 20 segundos para joder cualquier sniffer metido entremedio, pero bueno para novatos la explicacion esta buena xD.
PD2: Una forma sencilla de DECODIFICADOR basandome en el hecho de q las paginas no encriptan IMAGENES ¿porq? mucha carga de CPU en el servidor entonces si una pagina encriptada es solicitada por un usuario X y esta pagina contiene la imagen Y q no esta encriptada y hay un usuario Z sniffeando y ese usuario sabe q en la IP b.b.b.b. hay una 1 sola pagina q referencia a dicha imagen entonces DEDUCE la peticion del GET del usuario X en FUNCION DE DICHA IMAGEN, ahora bien si cambia esa imagen por un GIF animado con codigo malicioso para q ejecute X codigo javascript en el usuario X, entonces esta listo de nada serviria la "encriptacion" todo por unas imagenes no encriptadas, ahora bien supongamos q las imagenes estan encriptadas y el servidor es PODEROSO EN CPU y en encriptacion, aun asi me parece q cualquier codigo q no se mueve como las susodicha imagen es CODIFICACION y no encriptacion predecible por lo demas.
Hola Alanladron. Agradezco tu aporte tan detallado a esta discusión. No obstante, tienes razón en que la explicación es para novatos ya que este video corresponde a la primera parte del curso asociado a la certificación CCENT (Cisco Certified Entry Network Technician) la cual es de nivel inicial. Justamente lo que se busca en este curso es internar a los estudiantes en conceptos generales sin tener que profundizar demasiado a nivel técnico los conceptos. Luego, en cursos más avanzados se ve el detalle de los métodos criptográficos y todo eso.
Cuando uno es profesor, debes comprender que uno no puede pretender que un alumno, que generalmente actúa de forma pasiva en una clase, absorba y entienda la totalidad de los conceptos técnicos en materia de redes ya que son muy difíciles para alguien que está comenzando a entender este mundo. Es por eso que quienes hacemos clases recurrimos a diferentes técnicas para lograr que los alumnos puedan asimilar de mejor manera tanto detalle y una de esas técnicas es utilizar explicaciones superficiales como las que hay en este video.
Yo no puedo comenzar un curso de este nivel utilizando terminología avanzada como "sniffear" (aunque la palabra no existe, pero se entiende el concepto) y ni siquiera hablar de direcciones IP aún, porque todo es progresivo. Creo que en ese aspecto podemos tener una diferencia de conceptos entre tú y yo, porque tú dices que los profesores cometen el error de no explicar con totalidad los conceptos a nivel profundo y yo considero que justamente hay algunos profesores que cometen el error de comenzar a navegar en las más profundas aguas de los detalles técnicos de las tecnologías desde el día 1 que el alumno se sienta en su clase. Esto último a mi juicio está mal como metodología de enseñanza pero creo que a tu juicio está bien.
@@pcolomes totalmente de acuerdo contigo, en una clase que tengo el profe no explica muy bien porque todos los términos que dice son de carácter muy técnico y además no modula bien🤣🤣