Una red permite intercambiar información mediante acuerdos llamados protocolos. Para comprender una consulta distinguimos enlace, configuración de red y aplicación. El enlace conecta una interfaz por cable o radio; la configuración permite localizar destinos; la aplicación intercambia mensajes para una tarea. Son dependencias relacionadas, no resultados equivalentes. Una conexión WiFi puede existir aunque no haya salida a Internet, y un servicio local puede funcionar sin salir de la red del aula.

El diagnóstico comienza expresando un síntoma concreto: no se establece enlace, falla un destino, no se resuelve un nombre o la aplicación devuelve un error. Cada observación limita las hipótesis siguientes. Una dirección asignada no demuestra que sea la correcta, y una página visible puede contener datos antiguos. Comprueba la dependencia pertinente en lugar de reiniciar todo sin registrar cambios. El laboratorio está aislado y autorizado; sus pruebas no modifican la infraestructura general del centro. Esa delimitación permite cambiar una condición, observar y restaurar el estado de partida.

Cliente y servidor describen funciones en un intercambio: el cliente solicita y el servidor ofrece un servicio. Un ordenador puede actuar de ambas maneras en procesos distintos. Un conmutador comunica dispositivos dentro de una red de enlace, un punto de acceso permite asociación inalámbrica y un router conecta redes. Una carcasa doméstica puede reunir esas funciones y servicios adicionales, sin que sus tareas se vuelvan idénticas.

La topología representa equipos, enlaces y funciones de la red utilizada. Dibujar una nube llamada Internet para todo oculta qué se necesita en una consulta local. Sigue el recorrido desde cliente hasta servidor y pregunta si cruza realmente a otra red. La estación ESP32 puede conectarse como estación a un punto de acceso o proporcionar su propio punto de acceso, según el firmware preparado. El modo se consulta y registra, no se adivina por el aspecto de la placa. Un servidor simulado permite razonar sobre servicios, pero no acredita haber conectado físicamente un sensor.

Una dirección IP identifica una interfaz dentro de su contexto de red. Para decidir qué destinos se consideran locales, el equipo utiliza también la máscara o prefijo: la dirección aislada no expresa toda esa relación. En el supuesto IPv4 192.168.50.0/24, la máscara es 255.255.255.0 y las direcciones terminadas en .10 y .21 pueden compartir subred. En ese /24 convencional, .0 identifica la red y .255 corresponde a difusión; ninguna se asigna a clientes. Las interfaces distintas necesitan direcciones únicas dentro de ese contexto para que la identificación no resulte ambigua.

Cuando el destino pertenece a otra red, la puerta de enlace ofrece una ruta hacia ella. DNS cumple otra función: relaciona nombres con direcciones. Por eso, consultar una dirección numérica local conocida no exige resolver un nombre, aunque consultar un nombre preparado sí depende de esa resolución. DHCP puede proporcionar configuración automáticamente, pero recibir valores no demuestra que coincidan con los previstos. Cada función resuelve una parte diferente del recorrido.

El plan autorizado permite interpretar la configuración observada: dirección, máscara, puerta y DNS se registran desde el sistema y se comparan con ese plan. Así se comprueba una relación concreta entre interfaces y destinos, en vez de copiar cifras sin comprenderlas. Una dirección privada no funciona como contraseña ni garantiza anonimato. El supuesto sirve para aprender; otras redes pueden utilizar prefijos diferentes o IPv6, y requieren sus propios valores autorizados.

Un enlace cableado depende de cable, conectores, interfaces y equipos compatibles. WiFi añade condiciones de radio como distancia, obstáculos, interferencias y ocupación, además de autenticación. Las barras de cobertura describen una señal de forma aproximada, no la disponibilidad del servidor ni una velocidad garantizada. La tasa de enlace anunciada tampoco equivale al caudal útil de una transferencia: protocolos, carga y dispositivos influyen en el resultado.

La latencia expresa retraso en una operación y no debe confundirse con cantidad transferida por segundo. Para comparar medios, utiliza el mismo servicio y tarea, documenta ubicación, dispositivo e interfaz activa y registra lo que realmente observas. Si cambias cliente, distancia y servidor a la vez, no puedes atribuir la diferencia solo al cable o WiFi. Dos interfaces activas pueden seguir rutas distintas y confundir el ensayo. Usa la configuración preparada y no sobrecargues la red. Una comparación escolar justifica conclusiones limitadas a sus condiciones, sin declarar un medio siempre superior para cualquier uso.

Una dirección localiza una interfaz, pero la aplicación necesita además protocolo, puerto y recurso. En http://192.168.50.10:8000/panel, HTTP indica protocolo, 8000 el puerto de destino y /panel la ruta. Es un ejemplo del laboratorio, no una dirección para copiar en cualquier red. Debe existir un proceso escuchando y el acceso estar permitido. El panel y la lectura pueden tener rutas y condiciones de autenticación distintas.

Una respuesta HTTP 401 indica que falta autenticación válida; 403 expresa acceso prohibido y 404 que el recurso no se encuentra en el servicio que respondió. Ninguna equivale a falta de WiFi. Un tiempo de espera agotado sin respuesta necesita más pruebas y no debe confundirse automáticamente con un estado HTTP concreto. Ping utiliza otra comprobación: puede filtrarse y, aunque responda, no garantiza servicio web. Prueba la tarea de aplicación autorizada. Una lectura válida necesita valor, unidad y contexto de actualización, además de una respuesta recibida. Las claves del servicio no aparecen en la entrega.

Un diagnóstico por dependencias utiliza lo que ya está comprobado para escoger la siguiente prueba. Un enlace caído, una dirección fuera del plan y un servicio detenido son situaciones distintas aunque produzcan una página que no carga. Para diferenciarlas, observa interfaz, configuración y disponibilidad de aplicación con herramientas del entorno. No es necesario repetir un ritual completo si una evidencia concreta permite empezar por una parte pertinente.

El docente prepara un fallo cada vez y restaura la configuración antes del siguiente ensayo. Registra síntoma, hipótesis, resultado esperado, acción, observado, corrección y comprobación final. Una prueba discriminante distingue al menos dos explicaciones; cambiar varios parámetros oculta cuál influyó. Si un reinicio autorizado recupera servicio sin identificar la causa, anótalo así. Conserva una hipótesis revisada cuando la evidencia la contradiga. No se exploran destinos ajenos ni se inspecciona tráfico de compañeros. La simulación sirve para ensayar razonamiento, pero debe declararse y no acredita una configuración física realizada.

La documentación de red reúne topología, plan de configuración y registro de incidencias. El dibujo muestra qué conecta con qué; la tabla conserva funciones e interfaces; el registro explica cómo cambió una hipótesis. Deben corresponder al mismo montaje y versión. Una captura del resultado final no cuenta qué comprobación descartó una causa ni permite repetir el procedimiento desde el estado inicial. Los parámetros de acceso se mantienen fuera de las entregas compartidas.

Una guía útil indica condición previa, acción autorizada, resultado esperado y siguiente decisión si no coincide. Otra pareja puede usarla ante un caso nuevo sin memorizar direcciones. La transferencia se comprueba explicando qué dependencia examina la primera prueba y qué resultado haría cambiarla. Registra limitaciones de material, simulación y condiciones del ensayo. Si el montaje cambia, actualiza el dibujo antes de reutilizar conclusiones. La mejora debe verificarse en acceso y en la tarea de consulta; restablecer un enlace no demuestra por sí solo que el servicio vuelva a entregar información útil.

En una consulta IoT, abrir el panel solo comprueba una parte del recorrido. Una lectura útil reúne valor, unidad y contexto temporal. El dispositivo puede registrar el instante de medida y el servidor el de recepción: cada momento describe una operación distinta. La antigüedad tiene sentido cuando se conoce a qué registro se refiere y cómo se calcula. Si los relojes no están sincronizados, comparar sus horas puede producir una interpretación incorrecta. La unidad física también necesita respaldo en la ficha del sensor; el número por sí solo no la determina.

La información visible puede mantenerse aunque deje de renovarse. El cliente puede conservar la pantalla y el servidor la última lectura cuando el emisor se detiene. Por eso se distinguen acceso al panel, respuesta a la consulta y renovación efectiva del dato. Una marca temporal o secuencia que avanza aporta evidencia sobre el registro que representa; sus límites dependen del mecanismo preparado. Una secuencia muestra sucesión, pero no equivale por sí sola a una duración. Repetir un valor tampoco demuestra avería, porque la magnitud puede permanecer estable.

Un diagnóstico relaciona esas evidencias con una hipótesis y una comprobación. Si el panel abre pero el registro no avanza, la conectividad del navegador no explica por sí sola dónde se ha detenido el recorrido. Comparar los registros disponibles del emisor, del servidor y del cliente ayuda a acotar el problema. Cambiar una sola condición y repetir la consulta permite observar si la intervención tuvo el efecto previsto. Identificar cuándo usamos hardware real, un servidor simulado o datos ficticios delimita qué parte hemos comprobado y qué afirmaciones siguen pendientes.