Dominio principal
Infraestructura de Internet
En la faceta Dominio principal, los análisis de Infraestructura de Internet se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.
Historia de Internet
La consulta vacía que enumeraba a todos: cómo Finger convirtió la presencia humana en respuesta de red
No hacía falta escribir un nombre. Bastaba abrir TCP 79 y enviar CRLF. Para NAME/FINGER, esa línea vacía preguntaba quién estaba usando el sistema remoto en ese instante. La contestación podía traer nombre completo, ubicación del terminal, tiempo de inactividad y un plan…
Historia de Internet
La segunda conexión preguntó quién poseía la primera: cómo IDENT limitó la autoridad de un nombre de usuario
Dos números cambiaron de orden al cruzar la red. Para el servidor que recibió la conexión original eran puerto remoto y puerto local; para el equipo que debía responder a IDENT eran local y remoto. De esa inversión dependía encontrar el proceso correcto. No dependía, sin embargo…
Historia de Internet
El paquete horario que no daba la hora: cómo Kiss-o'-Death convirtió el rechazo de NTP en una acción
Un cliente obediente puede hacer exactamente lo equivocado. Recibe `RATE`, acepta un intervalo desmesurado y deja de consultar su única fuente útil. El servidor queda protegido, pero el reloj pierde servicio. El Kiss-o'-Death de NTP nació para frenar una carga real y terminó…
Historia de Internet
El archivo no llegó desde el puerto 69: cómo TFTP fijó los extremos de cada transferencia
Un equipo que apenas ha arrancado conoce muy poco: una dirección, el nombre de un archivo y el puerto 69 del servidor. Esa escasez explica la utilidad de TFTP, pero no significa que toda la transferencia ocurra en el puerto conocido. La primera respuesta aceptada crea un par…
Historia de Internet
La pregunta que SMTP aprendió a no contestar: cómo VRFY separó la aceptación del correo de la revelación del directorio
En 1982, una máquina remota podía enviar `VRFY Smith` a un servidor SMTP y recibir el nombre completo de Fred Smith junto con su buzón. Era una herramienta de diagnóstico excelente porque hacía visible el directorio. También era peligrosa por esa misma cualidad: el transporte de…
Historia de Internet
El servidor devolvió el nombre nuevo: cómo UIDPLUS hizo verificables las mutaciones IMAP
Copiar tres mensajes parecía una operación sencilla hasta que el servidor respondió que había terminado. En la carpeta de origen seguían llamándose 304, 319 y 320; en la de destino habían recibido otros UID. El cliente conocía el resultado general, pero no la correspondencia.…
Historia de Internet
El comando que cedía la conexión: por qué SMTP sustituyó TURN por ETRN
Un sitio llamaba a su proveedor y pedía que la línea diera la vuelta. El servidor podía devolver por esa misma conexión el correo acumulado. La economía ocultaba una cesión de autoridad: el interlocutor había pronunciado un nombre de host, pero no había probado su derecho a…
Historia de Internet
El plazo que el relé no podía reiniciar: cómo SMTP DELIVERBY hizo heredable el tiempo
Un mensaje salió con 120 segundos y llegó al siguiente diálogo SMTP con 98. Los 22 segundos gastados no eran un detalle contable: eran la parte de la obligación que el primer relé ya había consumido.
Historia de Internet
Dos copias podían compartir el mismo identificador: el límite deliberado de POP3 UIDL
La RFC permitió que un servidor calculara el UID a partir del mensaje y exigió al cliente tolerar dos copias idénticas con el mismo valor. Aquella excepción no debilitó UIDL: definió con precisión qué resolvía. El token reconocía una entidad a través de sesiones en un buzón, pero…
Historia de Internet
El código de error que pidió identificarse al bloqueador
HTTP 451 podía hacer visible un obstáculo legal y señalar a quien lo ejecutaba. No podía obligar a informar, validar la orden ni detectar bloqueos bajo HTTP.
Historia de Internet
La última línea sin comprimir: cómo IMAP cambió el significado de cada byte siguiente
La respuesta parecía rutinaria: una etiqueta, `OK`, una frase breve y CRLF. Pero era la última línea que podía leerse así. Si el servidor aceptaba COMPRESS, el byte siguiente ya no pertenecía directamente al idioma visible de IMAP. Entraba en un flujo DEFLATE cuyo comienzo ambos…
Historia de Internet
El saludo que hubo que repetir: cómo STARTTLS reinició la confianza de SMTP
El primer nombre del cliente y la primera lista de capacidades habían viajado sin protección. Envolver después la misma conexión con TLS no podía volver fiables aquellas palabras anteriores. SMTP resolvió la paradoja con una decisión radicalmente sencilla: al terminar el…
Historia de Internet
La credencial que no podía firmar el mensaje: cómo SMTP AUTH acotó la identidad de envío
Una credencial podía abrir el acceso al servidor de envío, pero no firmaba la carta que entraba. SMTP AUTH resolvió el problema del usuario móvil sin borrar esa diferencia: autenticar una sesión, autorizar una acción, admitir un remitente y atribuir un texto son operaciones…
Institucionales globales
linuxptp y el lazo de control del tiempo de precisión
linuxptp convierte un host Linux, un reloj de hardware y una fuente de sincronización de red en un sistema de tiempo de precisión. Sus demonios coordinan el estado de IEEE 1588, las marcas de tiempo de paquetes, los servos y los relojes del sistema, pero el software por sí solo…
Académicos
Laurent Vanbever y la red que debe probarse mientras cambia
El trabajo de Laurent Vanbever trata la configuración de red como software ejecutable cuyos fallos pueden aparecer antes, durante o después del despliegue. Desde migraciones de enrutamiento seguras y síntesis de configuración hasta la detección de BGP en tiempo de ejecución y las…
Historia de Internet
La dirección que no podía degradarse: cómo SMTPUTF8 convirtió la ruta en parte del nombre
Un nombre visible con acentos podía cruzar el correo antiguo porque rodeaba una dirección ASCII. Un nombre de buzón no ASCII era el destino. SMTPUTF8 exigió que cada relé demostrara que podía transportar esa identidad sin inventar otra.
Académicos
Katerina Argyraki y la búsqueda de pruebas en el reenvío de paquetes
La investigación de Katerina Argyraki persigue un problema que se vuelve más difícil a medida que las redes son más programables: un sistema de procesamiento de paquetes puede ser rápido y flexible, pero operadores y usuarios suelen tener poca evidencia de que se comportó…
Historia de Internet
El recibo que no podía prometer la entrega
SMTP DSN convirtió el rebote en evidencia estructurada sin borrar su límite esencial: el remitente podía pedir un informe, pero este no podía acreditar más de lo observado por el sistema.
Institucionales globales
BIRD y el motor de políticas de enrutamiento tras los puntos de intercambio de Internet
BIRD Internet Routing Daemon pasó de ser un proyecto universitario checo a un sistema de plano de control utilizado en entornos exigentes, como los puntos de intercambio de Internet. Su historia muestra cómo el software abierto reduce la dependencia de plataformas propietarias y…
Historia de Internet
El octavo bit necesitó permiso en cada salto: cómo 8BITMIME cambió SMTP
Un mensaje podía describir una letra acentuada aunque no todos los relés pudieran conservar sus octetos. 8BITMIME convirtió esa incertidumbre en una promesa por conexión: anunciar capacidad y custodiar cada bit aceptado.