Artículos

HTTP Strict Transport Security permite que un origen HTTPS indique a los navegadores compatibles que usen HTTPS durante un tiempo determinado. includeSubDomains amplía la política; preload es un mecanismo aparte, propio del ecosistema de los navegadores, y no conviene activarlo a la ligera.

HTTP define las solicitudes y respuestas entre un cliente y un servidor web. HTTPS utiliza la misma semántica web sobre una conexión protegida: los datos se cifran y el cliente comprueba que el servidor está autorizado para el nombre que figura en la barra de direcciones. Esto protege el intercambio durante la transmisión, no la honradez del propietario del sitio.

HTTP/2 multiplexa flujos HTTP sobre una única conexión TCP; HTTP/3 traslada la semántica de HTTP a QUIC sobre UDP. QUIC ofrece flujos independientes e integra TLS 1.3, lo que cambia la recuperación ante pérdidas y el establecimiento de la conexión sin alterar los métodos ni los códigos de estado de HTTP.

HTTP/3 es una versión de HTTP que utiliza QUIC en lugar de la conocida combinación de HTTP/2, TLS y TCP. QUIC funciona sobre UDP, pero añade flujos fiables, control de congestión y un establecimiento seguro de la conexión. Admitir HTTP/3 no hace rápidas por sí solo todas las páginas.

La huella digital de un navegador puede combinar propiedades como la plataforma, la forma de renderizar, el idioma, las características de la pantalla y las API expuestas. Cada señal por separado no tiene por qué ser única, y una huella no debe tomarse como una identidad real y permanente.

ICMP transporta información de control y de error en las redes IP. Ping utiliza ICMP Echo, pero ICMP también informa de situaciones como un destino inaccesible, un paquete demasiado grande o un límite de saltos agotado.

Una dirección IP estática se mantiene fija a propósito para una interfaz o un servicio. Una dirección dinámica se asigna automáticamente y puede cambiar, aunque no tiene por qué hacerlo cada vez que el dispositivo se vuelve a conectar. Estos términos describen cómo se asigna una dirección, no si es pública o privada: cualquiera de los dos tipos puede asignarse de una u otra forma.

Una dirección IP pública se usa para comunicarse a través de Internet y debe ser única dentro del espacio de enrutamiento público. Una dirección IPv4 privada está pensada para una red local: la misma dirección, por ejemplo 192.168.1.10, puede usarse a la vez en hogares distintos. Para entender la dirección que aparece en la configuración, distinga entre el dispositivo, el router y el proveedor.

El tratamiento de IPv4 e IPv6 en las API de IP depende del contrato entre un cliente y una API. Un cliente debe distinguir entre éxito, errores de validación, fallos de autenticación, límites de frecuencia y errores temporales del servidor. Elegir JSON o XML no cambia la semántica de HTTP, y las direcciones IPv4/IPv6 deben guardarse íntegras, sin presuponer la longitud de una IPv4.

IPv4 e IPv6 son dos versiones del protocolo de Internet que conviven en la Internet actual. Las direcciones IPv4 tienen 32 bits y las IPv6, 128. Que IPv6 tenga un espacio de direcciones mayor no hace que una conexión sea automáticamente más rápida ni más segura. El rendimiento y la exposición dependen de la ruta, la red y la configuración.

Un resultado de descarga rápido no garantiza una llamada o una partida fluidas. El tráfico interactivo también depende de la latencia, de las variaciones de la latencia, conocidas como jitter, y de la pérdida de paquetes. Cada una describe un aspecto distinto de la conexión, así que mídalas por separado antes de cambiar de equipo o culpar a un servidor.

Los límites de frecuencia (rate limits) y los reintentos forman parte del contrato entre un cliente y una API. Un cliente debe distinguir entre éxito, errores de validación, fallos de autenticación, límites de frecuencia y errores temporales del servidor. Elegir JSON o XML no cambia la semántica de HTTP, y las direcciones IPv4/IPv6 deben guardarse íntegras, sin presuponer la longitud de una IPv4.

Las máscaras de subred y la notación CIDR describen cómo un host identifica su red local, sus vecinos y la ruta hacia otras redes. En IPv4 intervienen la dirección, la longitud del prefijo y la puerta de enlace; en IPv6, además, el ámbito de la dirección y Neighbor Discovery. Basta un valor erróneo para que la comunicación local siga funcionando, pero no se pueda salir de la subred.

Las velocidades de acceso a Internet suelen anunciarse en megabits por segundo, expresados como Mbps o Mb/s. Los tamaños de archivo y los programas de descarga suelen usar megabytes y MB/s. Un byte contiene ocho bits, así que las cifras difieren en un factor de aproximadamente ocho incluso antes de tener en cuenta la sobrecarga de los protocolos.

El binario, el decimal y el hexadecimal se entienden mejor mediante una regla exacta, una unidad o una representación en bits que con el diagnóstico genérico de redes. Antes de calcular, identifique qué se mide, las unidades de entrada y el formato de salida esperado.

Para interpretar errores DNS como NXDOMAIN, SERVFAIL y REFUSED, siga el trayecto resolutor stub → resolutor recursivo → delegación → servidor de nombres autoritativo. Un resolutor recursivo puede responder desde su caché, por lo que la respuesta que recibe el usuario no procede necesariamente del servidor autoritativo. El TTL, el tipo de registro y el código de respuesta indican de dónde sale el resultado y cuánto tiempo puede seguir siendo válido.

Para comparar el peering y el tránsito IP no basta con la velocidad máxima anunciada o el nombre de la tarifa. Cuentan la tecnología de acceso, los recursos, el aislamiento, el enrutamiento, el peering/tránsito, la política de direcciones y el soporte. Dos servicios con características principales parecidas pueden comportarse de forma distinta bajo carga.

Los permisos chmod de Linux se entienden mejor con una regla exacta, una unidad o su representación en bits que con el diagnóstico genérico de redes. Antes de calcular, identifique qué se mide, las unidades de entrada y el formato de salida esperado.

Los picos de ping y la latencia inestable no pueden evaluarse a partir de una sola cifra en Mbps. El rendimiento, la latencia, el jitter y la pérdida de paquetes describen propiedades distintas, y en los resultados influyen la Wi-Fi o Ethernet, los demás dispositivos que comparten la conexión, las VPN, el enrutamiento y el servidor de prueba. Un rendimiento alto puede convivir con una latencia mala cuando la conexión está cargada.

Ping comprueba si un destino responde a sondas de red y mide cuánto tarda en volver cada respuesta. Es un primer paso de diagnóstico muy útil, pero no mide el ancho de banda de descarga ni basta por sí solo para afirmar que una aplicación o una web funcionan bien.

Una comprobación de puertos indica cómo se vio un intento de conexión desde una ubicación de red concreta. «Abierto», «cerrado» y «filtrado» son etiquetas de diagnóstico útiles, pero un único resultado no puede identificar todos los dispositivos implicados ni determinar si una aplicación es segura.

Los puertos de los servicios habituales se analizan en el trayecto de transporte o de red. Conviene analizar por separado el socket local, la entrega IP, el comportamiento de TCP o UDP, el filtrado del cortafuegos y el NAT. Un ping correcto no demuestra que un puerto TCP sea accesible, y un puerto abierto no demuestra que el protocolo de aplicación funcione correctamente.

Al analizar Punycode y los dominios internacionalizados, determine qué propiedad está comprobando: confidencialidad, integridad, autenticación o menor correlación. Cada mecanismo resuelve un problema distinto: el cifrado no es hashing, una VPN no es lo mismo que un proxy de aplicación y cambiar un identificador visible no proporciona un anonimato completo.

Punycode es una codificación que permite representar caracteres Unicode de forma compatible con ASCII en los nombres de dominio internacionalizados. Por eso, un dominio escrito con caracteres nacionales puede aparecer en los datos técnicos como una etiqueta que empieza por xn--. La codificación solo cambia la representación; no acredita que un sitio web sea auténtico.

Para interpretar el TTL de DNS, siga la consulta por el trayecto resolutor stub → resolutor recursivo → delegación → servidor de nombres autoritativo. Un resolutor recursivo puede responder desde su caché, por lo que la respuesta que recibe el usuario no procede necesariamente del servidor autoritativo. El TTL, el tipo de registro y el código de respuesta indican de dónde sale el resultado y cuánto tiempo puede seguir siendo válido.