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 cabecera que desapareció entre paquetes
RFC 1144 hizo casi desaparecer cuarenta octetos de cabecera en enlaces lentos: dos vecinos guardaban el mismo estado y enviaban sólo la diferencia.
Historia de Internet
La línea que parecía el final en SMTP
SMTP cerraba el correo de longitud desconocida con una línea de un punto. Duplicarlo volvió reversible la señal; CHUNKING contó después los octetos.
Historia de Internet
HTTP 100 Continue: permiso sin aceptación
HTTP 100 Continue permite rechazar por las cabeceras antes de enviar un cuerpo grande, sin confundir el permiso provisional con la aceptación final.
Historia de Internet
El silencio que no era un fallo: por qué TCP keepalive siguió siendo opcional
Una conexión TCP establecida puede callar durante horas y funcionar correctamente. Keepalive nació para interrogar ese silencio sin atribuirle una causa: provocar un ACK, obtener evidencia limitada y dejar a la aplicación la decisión sobre cuánto tiempo puede convivir con la…
Historia de Internet
¿Quién abrió demasiado pronto la ventana TCP? El costo del permiso inmediato
Un receptor TCP podía publicar cada byte recién liberado y el emisor consumir inmediatamente cada oferta. La apertura parecía exacta y cooperativa. Al repetirse, obligaba a la conexión a gastar casi todo su trabajo en paquetes diminutos. La reparación histórica dio a cada extremo…
Institucionales globales
Public Suffix List: el archivo que traza las fronteras de confianza web
El DNS puede mostrar que shop.example.co.uk está bajo co.uk, pero no puede decirle a un navegador dónde comienza el registro independiente. La Public Suffix List aporta ese mapa de política que falta. Un archivo de texto mantenido por voluntarios informa ahora cookies, agrupación…
Historia de Internet
La actualización de ventana que podía perderse: por qué TCP aprendió a persistir en cero
Una ventana cero no significa que la conexión haya muerto. Significa que el receptor no admite bytes nuevos ahora. El problema histórico apareció cuando recuperó espacio y el ACK que abría la ventana se perdió: sin una pregunta excepcional, dos extremos correctos podían esperar…
Historia de Internet
El veredicto que UDP se reservó: ¿de quién era el riesgo del cero?
En UDP, cero no era un resultado favorable: avisaba que el emisor no entregaba veredicto. La transición de IPv4 a IPv6 fue así una disputa por la responsabilidad. ¿Quién podía retirar una prueba compartida y cuándo debía el beneficiario del ahorro poseer también el riesgo?
Historia de Internet
Cuando ambos extremos llamaron a la vez: la apertura simultánea de TCP no era una colisión
La historia más repetida del establecimiento TCP empieza con un cliente que llama y un servidor que espera. En 1981, el protocolo ya permitía algo menos ceremonial: dos procesos podían iniciar la misma asociación al mismo tiempo. Sus SYN se cruzaban, ambos cambiaban de estado y…
Historia de Internet
El precio de la tolerancia: cómo la indulgencia del receptor convirtió errores en ley de protocolo
La regla más famosa del Internet imperfecto permitió que implementaciones distintas conversaran. El receptor absorbía la ambigüedad para poner la red en marcha. Al perpetuarse, la concesión ocultó defectos, convirtió rarezas en obligaciones y cargó a cada implementación futura…
Historia de Internet
El puntero que nunca estuvo fuera de banda: cómo la urgencia TCP se apartó de su propio flujo
TCP quiso avisar a una aplicación ocupada sin inventar otra conexión. La señal señalaba un límite dentro de la secuencia normal; las API separaron un byte, las implementaciones eligieron otra aritmética y el camino terminó decidiendo si la urgencia llegaba.
Historia de Internet
El mensaje que Internet aprendió a ignorar: por qué ICMP Source Quench perdió su autoridad
La Internet temprana permitía que un gateway saturado enviara una orden separada para que una fuente distante redujera su ritmo. La experiencia invirtió el acuerdo: la congestión seguía necesitando señales, pero un mensaje ICMP desnudo ya no merecía gobernar la tasa de un…
Historia de Internet
La suma que tenía dos ceros: cómo el checksum de Internet acotó el error, no la confianza
El checksum de Internet permitió descartar muchas alteraciones con una operación barata. Su historia muestra una disciplina mayor: el resultado sólo habla de los bits que suma, y ni siquiera sus dos ceros pueden confundirse sin consecuencias.
Historia de Internet
El informe que el emisor no podía creer: por qué SACK siguió siendo un aviso
TCP permitió que el receptor describiera con precisión los bloques que ya tenía y, al mismo tiempo, ordenó al emisor conservar una copia. Esa cautela convirtió SACK en evidencia útil sin confundir una observación revocable con entrega definitiva.
Historia de Internet
El acuse que aprendió a señalar: cómo SACK hizo visibles las pérdidas de TCP
El ACK acumulativo podía confirmar una corriente continua, pero guardaba silencio sobre los bloques que esperaban detrás del primer hueco. SACK añadió coordenadas para esos bloques y mantuvo una frontera decisiva: informar pertenece al receptor; reparar sigue siendo…
Historia de Internet
El router señaló al lado: por qué ICMP Redirect fue local
Un router podía recomendar un vecino mejor sin ser dueño de la ruta. ICMP Redirect sólo tenía autoridad dentro del enlace que produjo el consejo.
Historia de Internet
El número que se volvió más nuevo después de cero: cómo DNS ordenó versiones sin reloj
Un servidor DNS puede recibir el serial 0 y considerarlo posterior a 4.294.967.295. Esa decisión, contraintuitiva sólo si se mira una recta numérica, permitió comparar copias distribuidas sin imponer una hora universal. También obligó a reconocer un límite: hay pares que el…
Historia de Internet
La zona que llamó: DNS NOTIFY, IXFR y autoridad al día
Al principio del DNS, un secundario ignoraba su atraso hasta el siguiente control. NOTIFY lo despertó; IXFR llevó sólo las diferencias.
Historia de Internet
La dirección que necesitaba DNS para ser encontrada: cómo el glue rompió el bucle de delegación
Una delegación DNS puede nombrar al servidor que conoce la respuesta y, al mismo tiempo, dejar al resolvedor sin forma de alcanzarlo. El glue fue la excepción limitada y no autoritativa que permitió cruzar esa frontera sin entregar al padre los hechos de la zona hija.
Historia de Internet
La dirección que preguntó al cable: cómo ARP hizo revisable la conectividad local
Una tabla de rutas puede elegir el próximo salto y aun así dejar a Ethernet sin destinatario. ARP convirtió esa última incertidumbre en una pregunta local, una respuesta observable y una memoria con fecha de caducidad.