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.
IETF
El paquete marcado antes de perderse: la larga discusión de ECN sobre la congestión
ECN introdujo una idea poco intuitiva en Internet: un router puede advertir de la congestión sin destruir el paquete que transporta el aviso. Dos bits bastan para codificar la señal, pero no para garantizar su significado; eso exige cooperación entre la cola, el receptor, el…
Historia de Internet
La prueba que triunfaba sin decir nada: qué podía demostrar Discard
El emisor entrega bytes al puerto 9 y no recibe un “correcto”, una suma ni un contador. Según RFC 863, eso es lo esperado: Discard elimina los datos y no contesta. La ausencia puede facilitar una prueba unidireccional, pero no demuestra por sí misma que el proceso remoto haya…
Historia de Internet
La respuesta del reloj sin gramática: Daytime estaba hecho para personas
El servidor de puerto 13 responde y la red no ha fallado. Sin embargo, otro servidor puede escribir la misma hora con campos, año y zona distintos sin infringir la norma. Daytime estandarizó el acto de contestar; dejó deliberadamente fuera la sintaxis que un programa necesitaría…
Historia de Internet
Las respuestas de una en una que nunca terminaron: el bucle entre Echo y Chargen
Dos timbres mecánicos están conectados de modo que el sonido de uno pulsa el botón del otro. Ninguno toca dos veces por orden; aun así, la sala no vuelve al silencio. Echo y Character Generator reprodujeron ese problema en UDP: una respuesta limitada dejó de ser final cuando…
Historia de Internet
La tecla que tenía tres contratos: cómo Telnet separó Enter, CR y una línea nueva
Pulsar Enter parece un gesto indivisible. En Telnet podía atravesar tres contratos distintos: la tecla física del usuario, la representación del Network Virtual Terminal y la convención del sistema remoto. `CR LF` y `CR NUL` existieron para que esos contratos pudieran traducirse…
Historia de Internet
El servidor que cambió de oficio a mitad de conexión: cómo NNTP hizo explícitos sus papeles
Un cliente ve primero capacidades para transferir artículos entre servidores. Envía `MODE READER`, vuelve a preguntar y encuentra herramientas de lectura. El host y el puerto siguen ahí; lo que cambió fue el trabajo autorizado dentro de esa sesión.
Historia de Internet
La retractación que viajó como noticia: por qué Usenet dejaba la cancelación en manos de cada servidor
Una cancelación alcanza tres servidores de noticias. El primero ya guarda el artículo y deja de mostrarlo. El segundo no confía en la solicitud y la descarta. El tercero todavía no ha recibido el original: memoriza su Message-ID para impedir que aparezca más tarde. El mensaje de…
Historia de Internet
El borrado que esperaba la despedida: cómo POP3 separó la marca de la eliminación irreversible
El servidor responde `+OK message 4 deleted` y la conexión se rompe antes de `QUIT`. En la sesión siguiente, el mensaje 4 reaparece. No es una resurrección: la primera respuesta confirmó una marca reversible dentro de una vista bloqueada; el borrado real pertenecía a UPDATE, un…
Historia de Internet
Los bytes que esperaban permiso: la frontera que IMAP movió para ahorrar un viaje
El cliente ya había contado la carga. Escribía `{11}`, cerraba la línea y, aun así, no enviaba los once octetos. Faltaba un `+` del servidor. Esa pausa no era una torpeza del transporte: era el lugar donde el receptor aún podía negarse antes de asumir el coste. LITERAL+ eliminó…
Historia de Internet
El punto de reinicio que no era un número de bytes: cómo FTP aprendió a reanudar un archivo
Un archivo podía estar a medio camino y, aun así, FTP seguía conversando. Por la conexión de control aparecía `110 MARK ssss = rrrr`, mientras los datos no debían detenerse. A la izquierda figuraba una posición que sólo el emisor sabía restaurar; a la derecha, otra que sólo el…
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.