Cómo funciona Internet

Internet une redes gestionadas de forma independiente mediante protocolos compartidos, especialmente el protocolo de Internet (IP). Ninguna organización gestiona todo el sistema.

Dispositivos y enlaces

Un equipo anfitrión, o sistema final, ejecuta aplicaciones. Los teléfonos, las computadoras portátiles, los servidores, los televisores inteligentes y los sensores pueden ser equipos anfitriones. Un cliente solicita un servicio; un servidor lo proporciona. Una computadora puede solicitar un archivo mientras ofrece otro a alguien más.

Los enlaces transportan bits por cable de cobre como señales eléctricas, por fibra óptica como luz o por conexiones inalámbricas como radio. Una ruta puede atravesar varios medios.

Un enrutador doméstico suele combinar funciones de enrutamiento, conmutación y punto de acceso Wi-Fi, a veces con un módem. Siguen siendo funciones diferentes aunque un solo aparato las realice.

Conexión con un proveedor

Una red de acceso conecta una vivienda, una organización o un teléfono con su proveedor. Algunos ejemplos son la fibra, el cable, DSL, Ethernet en oficinas y las redes móviles. Un proveedor de servicios de Internet (ISP) transporta tráfico entre redes de acceso y otras redes.

Los proveedores intercambian tráfico directamente en un punto de intercambio de Internet (IXP), una instalación compartida que puede abarcar varios edificios. También pueden comprar tránsito IP, pagando a otro proveedor para que transporte el tráfico hacia otras redes. Las grandes empresas de contenidos gestionan sus propias redes y centros de datos para acercar los servicios a los usuarios.

La mayoría de los datos intercontinentales viajan por cables submarinos de fibra óptica tendidos en el fondo del mar; los satélites transportan una parte menor. Por tanto, un enlace de acceso inalámbrico puede dar paso a un recorrido largo y principalmente por cable.

Sigue una videollamada

Desde un teléfono en una cafetería se llama a alguien conectado a una red móvil al otro lado del océano:

1. El Wi-Fi lleva los paquetes hasta el punto de acceso de la cafetería.
2. El enrutador de la cafetería los envía por su conexión de acceso hasta el ISP.
3. Las redes de los proveedores los transportan hacia su destino, quizá intercambiándolos en un IXP.
4. Un cable submarino puede llevarlos al otro lado del océano.
5. El proveedor de destino los entrega al otro teléfono a través de su red móvil.

Distintas organizaciones gestionan estas etapas. Los protocolos compatibles les permiten pasar los paquetes a la siguiente red mientras cada operador gestiona su parte. El camino concreto puede cambiar cuando las redes modifican sus conexiones o responden a fallos.

Los archivos grandes viajan en muchos paquetes. Cada paquete transporta una parte de los datos, lo que permite que otras comunicaciones se turnen en los mismos enlaces.

Separa la cabecera y la carga útil

La cabecera de un paquete contiene información de control; su carga útil contiene datos. Una cabecera IP incluye las direcciones de origen y destino. Los enrutadores usan el destino para elegir el siguiente enlace sin interpretar la foto o el mensaje del interior. La aplicación receptora interpreta los bits entregados.

La cabecera se parece a la dirección de un sobre y la carga útil, a su contenido. Dividir un archivo en paquetes pequeños también limita la cantidad que debe reenviarse tras una pérdida. Un límite habitual del camino es un paquete IP de 1500 bytes, derivado del estándar Ethernet. Algunos caminos admiten tamaños mayores.

Cuenta paquetes y sobrecarga de control

Una foto contiene 3 000 000 bytes. Cada paquete admite hasta 1460 bytes de la foto más 40 bytes de cabeceras. Divide entre la capacidad de carga útil:

Redondea hacia arriba a 2055 paquetes, porque el resto también debe entregarse. Tras 2054 cargas útiles completas, la última contiene:

Todos los paquetes necesitan cabecera, incluido el último:

En conjunto, los datos y las cabeceras suman 3 082 200 bytes. Las cabeceras añaden aproximadamente un 2,7 % al tamaño de la foto. Dividir entre 1500 daría menos paquetes de los necesarios, porque 40 bytes de cada paquete no están disponibles para los datos de la foto. En cambio, contar la última carga útil como completa inventaría datos que la foto no contiene.

Reconstruye el orden de los bytes

Los paquetes suelen seguir la misma ruta, pero IP permite rutas diferentes. Los paquetes pueden llegar fuera de orden, llegar dos veces o perderse, incluso cuando se llena el búfer de un enrutador.

El protocolo de control de transmisión (TCP) corrige estos efectos en los equipos de los extremos. Numera los bytes, lo que permite al receptor identificar posiciones y huecos. El emisor retransmite los datos que faltan y el receptor entrega los bytes en orden. Recibir el último fragmento no completa un hueco anterior.

IP solo mueve paquetes individuales; no reconstruye el mensaje ni realiza esa recuperación. El protocolo de datagramas de usuario (UDP) tampoco incluye retransmisión ni reordenación. Las aplicaciones que usan UDP añaden la recuperación que necesitan.

La capacidad de un enlace puede reservarse para una conexión o compartirse entre los paquetes que llegan. La diferencia importa cuando el tráfico se detiene y cuando varios usuarios envían a la vez.

Reserva o comparte

La conmutación de circuitos reserva una parte fija a lo largo de todo el camino. Las llamadas telefónicas fijas tradicionales conservaban esa parte incluso durante los silencios.

La conmutación de paquetes comparte la capacidad según la demanda, lo que se llama multiplexación estadística. Cada paquete usa la tasa del enlace durante su turno. Esto resulta adecuado para el tráfico en ráfagas: la navegación web y la mensajería envían ráfagas cortas separadas por pausas.

Almacena paquetes mientras un enlace está ocupado

Un enrutador usa almacenamiento y reenvío: recibe un paquete completo antes de enviarlo al siguiente enlace. Los paquetes esperan en una cola cuando el enlace de salida está ocupado. Un búfer de memoria contiene esa cola; cuando se llena, no puede aceptar los nuevos paquetes, que se descartan.

Un enlace de 1 Mbit/s puede reservar diez partes de 100 kbit/s:

Con el uso compartido por paquetes, 35 usuarios pueden compartir el enlace si cada uno está activo solo el 10 % del tiempo. Para usuarios activos de forma independiente, la probabilidad de que más de diez estén activos a la vez es de aproximadamente 0,0004. La independencia importa: las ráfagas sincronizadas se comportan de otra manera. También pueden formarse colas breves con menos de diez usuarios activos cuando los paquetes llegan juntos.

Dónde comenzó la conmutación de paquetes

Paul Baran en RAND y Donald Davies en el National Physical Laboratory del Reino Unido desarrollaron ideas de conmutación de paquetes de forma independiente en la década de 1960. Davies acuñó el término «paquete»; Leonard Kleinrock desarrolló los primeros trabajos matemáticos sobre colas de red.

El 29 de octubre de 1969, ARPANET envió su primer mensaje desde UCLA al Stanford Research Institute. El sistema falló después de «LO» de «LOGIN». ARPANET pretendía compartir computadoras de investigación. El trabajo independiente de Baran estudiaba comunicaciones resistentes a ataques, lo que ayuda a explicar el posterior relato sobre la guerra nuclear.

Las redes de paquetes pueden usar rutas alternativas tras un fallo cuando hay otro camino disponible. Hoy la voz sobre IP transporta llamadas en paquetes, incluidas las llamadas en redes 4G y 5G.

La velocidad de una conexión tiene más de un significado. Una transferencia grande necesita una tasa de entrega alta; una conversación necesita retardos breves y estables. Distinguir ancho de banda, tasa de transferencia efectiva y latencia ayuda a explicar ambas situaciones.

Capacidad y entrega real

El ancho de banda es la capacidad de un enlace en bits por segundo. Los prefijos del SI usan potencias de diez: 1 kbit/s equivale a 1000 bit/s; 1 Mbit/s, a 1 000 000 bit/s; 1 Gbit/s, a 1 000 000 000 bit/s. «Mbps» es otra forma habitual de escribir Mbit/s.

La tasa de transferencia efectiva es la tasa a la que se entregan realmente los datos. El enlace más lento de un camino es su cuello de botella. Un enlace de servidor de 1 Gbit/s y uno de proveedor de 10 Gbit/s no pueden hacer que una descarga atraviese una línea doméstica de 50 Mbit/s a más de 50 Mbit/s. Compartir la capacidad y la sobrecarga de control de los protocolos reducen aún más la tasa útil.

Los tamaños de archivo usan bytes, escritos con B mayúscula; un byte contiene 8 bits. Un archivo de 500 MB contiene 4000 Mbit. A 100 Mbit/s, su tiempo ideal de transferencia es:

La respuesta de 5 segundos resulta de dividir bytes entre una tasa en bits sin convertir las unidades.

Cuatro partes del retardo

La latencia es el tiempo de viaje de un extremo al otro. El tiempo de ida y vuelta (RTT) incluye los recorridos de ida y regreso. Una medición con ping indica una ida y vuelta, normalmente en milisegundos.

En cada salto, distingue cuatro retardos:

• Procesamiento: leer una cabecera y decidir adónde enviar el paquete.
• Espera en cola: esperar a un enlace de salida.
• Transmisión: introducir todos los bits del paquete en ese enlace.
• Propagación: el recorrido de la señal por el enlace.

El retardo de transmisión depende del tamaño del paquete y de la tasa:

Un paquete de 1500 bytes tiene 12 000 bits. Transmitirlo lleva 0,12 ms a 100 Mbit/s o 1,2 ms a 10 Mbit/s. Al atravesar tres enlaces de 10 Mbit/s, el almacenamiento y reenvío requiere al menos 3,6 ms de tiempo de transmisión para ese paquete, antes de añadir los demás retardos.

El retardo de propagación depende de la distancia y de la velocidad de la señal:

En la fibra, la señal viaja a unos 200 000 km/s. Recorrer 6000 km lleva 30 ms en un sentido y al menos 60 ms de ida y vuelta. Aumentar el ancho de banda no puede acortar el cable.

Relaciona la medida con la aplicación

Una descarga se beneficia principalmente de la tasa de transferencia efectiva. Las llamadas y los juegos rápidos necesitan una latencia baja y poca variación del retardo. Las colas pueden crecer en las horas de mayor uso aunque la capacidad anunciada del enlace siga siendo la misma.

Una página web puede requerir varios intercambios antes de estar completa. El navegador puede solicitar muchos archivos a la vez, pero algunas solicitudes dependen de respuestas anteriores. El RTT importa para esas dependencias; también importan el trabajo del servidor, la tasa de transferencia efectiva disponible y el procesamiento del navegador. Por tanto, en una misma conexión pueden darse una descarga grande rápida y una página interactiva que se percibe lenta.

Una dirección IP identifica una interfaz de red: la conexión de un dispositivo a una red IP. Una computadora portátil puede tener direcciones diferentes en distintas redes. La dirección indica a la red dónde entregar los paquetes, no quién es una persona.

Lee IPv4 e IPv6

IPv4 usa 32 bits, escritos como cuatro números decimales separados por puntos. Cada número representa 8 bits y va de 0 a 255. Por ejemplo, 192.168.1.10 es 11000000.10101000.00000001.00001010 en binario. Un número final de 256 necesitaría más de 8 bits y no es válido.

Hay 4 294 967 296 valores posibles de 32 bits, unos 4,3 mil millones. La reserva central de IPv4 sin asignar se agotó el 3 de febrero de 2011. Las direcciones existentes siguen funcionando; el agotamiento significa que se terminó la reserva central original de bloques nuevos.

IPv6 usa 128 bits, lo que permite unos 3,4 × 10³⁸ valores. Tiene ocho grupos de cuatro dígitos hexadecimales. Pueden omitirse los ceros iniciales de un grupo y sustituirse una secuencia de grupos formados solo por ceros por ::.

2001:0db8:0000:0000:0000:ff00:0042:8329 se convierte en 2001:db8::ff00:42:8329. Cuenta cinco grupos visibles: los dos puntos dobles sustituyen tres grupos para completar ocho. Usa :: una sola vez para que su expansión sea inequívoca. Muchos equipos anfitriones ejecutan IPv4 e IPv6 en paralelo.

Comprende un prefijo

En 203.0.113.0/24, la barra indica que los primeros 24 bits forman el prefijo de red. Quedan ocho bits:

El bloque abarca desde 203.0.113.0 hasta 203.0.113.255. Una red IPv4 habitual de este tamaño reserva el primer y el último valor, lo que deja 254 direcciones para dispositivos. La barra indica una cantidad de bits de red, no un número de dispositivo.

Reutiliza direcciones en redes privadas

Hay tres rangos IPv4 reservados para redes privadas:

• 10.0.0.0/8
• 172.16.0.0/12, desde 172.16.0.0 hasta 172.31.255.255
• 192.168.0.0/16

Estos rangos se reutilizan en viviendas y organizaciones distintas y no se enrutan en la Internet pública. Por ejemplo, 172.20.5.4 es privada, mientras que 172.32.0.1 queda fuera del rango privado 172.

La traducción de direcciones de red (NAT) permite que los dispositivos privados compartan una dirección IPv4 pública. El enrutador reescribe las direcciones y los puertos de origen salientes y registra las traducciones. Usa la tabla para enviar las respuestas al dispositivo privado correcto. Una conexión nueva desde fuera necesita una forma de atravesar esta correspondencia; la dirección privada por sí sola no puede dirigirla hasta allí.

Conéctate automáticamente a una red

El protocolo de configuración dinámica de equipos (DHCP) proporciona una concesión de dirección, una puerta de enlace predeterminada y un resolvedor DNS. La puerta de enlace predeterminada es el enrutador que se usa para llegar a otras redes. Las concesiones y las asignaciones del proveedor pueden cambiar, y muchos dispositivos pueden compartir una dirección pública mediante NAT.

Una dirección MAC de hardware tiene otro propósito: las direcciones MAC habituales de Ethernet y Wi-Fi son identificadores de 48 bits usados para la entrega en el enlace local. Las direcciones IP permiten la entrega entre redes. Una dirección IP puede sugerir una ubicación aproximada, pero las asignaciones compartidas y cambiantes hacen que sea un mal identificador de una persona.

Un paquete avanza hacia su destino un salto cada vez. Cada enrutador decide por qué enlace enviarlo a continuación. El emisor no proporciona un itinerario completo para un paquete IP ordinario.

Lee una tabla de reenvío

Una tabla de reenvío asocia prefijos de destino con enlaces de salida. Considera estas entradas:

Un paquete dirigido a 203.0.113.57 coincide con la entrada /24 y sale por el enlace 2. Un paquete dirigido a 198.51.100.7 usa el enlace 1. La entrada /0 es la ruta predeterminada, que se usa cuando no coincide ninguna entrada más específica.

Cuando coinciden varias entradas, elige la coincidencia de prefijo más largo, es decir, la que especifica más bits de red. Se trata de la especificidad, no de la dirección escrita más grande ni de la distancia física más corta. Cada enrutador siguiente repite la consulta con su propia tabla.

Un equipo anfitrión inicia un recorrido fuera de su red enviando el paquete a la puerta de enlace predeterminada. En una vivienda, suele ser el enrutador doméstico. La dirección IP de destino del paquete sigue identificando el extremo remoto; la puerta de enlace local es solo su primer salto.

El reenvío y el enrutamiento realizan tareas diferentes

El reenvío es la acción local de mover un paquete a un enlace de salida. El enrutamiento encuentra caminos y rellena las tablas que usa el reenvío. Los protocolos de enrutamiento intercambian información sobre los destinos accesibles y reaccionan cuando aparecen o fallan enlaces. Un cambio puede tardar en propagarse, por lo que disponer de un camino alternativo utilizable no equivale a una reparación inmediata y sin pérdidas.

Un sistema autónomo (AS) es una red o conjunto de redes gestionadas bajo la política de enrutamiento de una organización, identificado por un número de AS. Los proveedores, las universidades y las empresas de contenidos pueden operar sistemas autónomos. Dentro de un AS, el operador elige sus métodos de enrutamiento. Entre sistemas autónomos, el protocolo de puerta de enlace de frontera (BGP) intercambia rutas.

Las decisiones de BGP reflejan acuerdos comerciales y políticas de enrutamiento, además de información sobre el camino. Por tanto, no está garantizado que se elija una ruta que recorra menos kilómetros.

Detén los bucles e inspecciona los saltos

El campo tiempo de vida (TTL) de IPv4 es un límite de saltos. Cada enrutador lo reduce en uno. Cuando llega a cero, el enrutador descarta el paquete y normalmente devuelve un error. Esto impide que un bucle de enrutamiento mantenga un paquete circulando indefinidamente.

Si un paquete comienza con TTL 64 y llega con TTL 52, doce enrutadores lo han reducido:

Traceroute, llamado tracert en Windows, envía sondas con límites de saltos crecientes. Los errores de los sucesivos enrutadores revelan los saltos que responden y sus tiempos de ida y vuelta. Un aumento de 15 ms a 90 ms puede sugerir un enlace largo, pero los tiempos por sí solos no identifican un cable submarino. Algunos enrutadores no responden a las sondas.

IP sigue siendo un servicio de mejor esfuerzo en todos estos pasos. Sus enrutadores intentan entregar los paquetes sin garantizar su llegada, orden ni ausencia de duplicados. Los equipos de los extremos usan protocolos de transporte como TCP cuando una aplicación necesita un flujo completo y ordenado.

Las personas escriben nombres como www.example.com; los enrutadores necesitan direcciones IP. El sistema de nombres de dominio (DNS) proporciona esa correspondencia y otros registros. Un servicio puede conservar su nombre aunque cambie su dirección.

Sigue la jerarquía de nombres

Lee un nombre de dominio de derecha a izquierda. Un punto final que no se escribe representa la raíz. Después viene un dominio de nivel superior (TLD) como com, org, jp o br, luego un dominio de segundo nivel como example y, por último, subdominios opcionales como www o mail.

Ningún servidor almacena todos los registros de dominio. Los servidores raíz dirigen a los resolvedores hacia servidores de TLD. Estos los dirigen hacia los servidores autoritativos de un dominio, que contienen sus registros. El servicio raíz tiene 13 identidades con nombre, gestionadas por 12 organizaciones; en octubre de 2026, estas identidades se servían desde más de 2000 copias en todo el mundo. Por tanto, trece nombres no significa trece máquinas físicas.

Resuelve un nombre que no está en caché

Una computadora portátil pide a su resolvedor DNS recursivo la dirección de www.example.com. El resolvedor puede pertenecer a un ISP, una organización o un servicio DNS público. Si no dispone de información útil en caché, recorre la jerarquía:

1. Pregunta a un servidor raíz, que lo remite a los servidores de com.
2. Pregunta a un servidor de com, que lo remite a los servidores autoritativos de example.com.
3. Pregunta a un servidor autoritativo, que devuelve una dirección como 192.0.2.10.
4. Devuelve esa respuesta a la computadora portátil.

La computadora ya puede conectarse al servidor web. La respuesta DNS no contiene la página web.

Guarda las respuestas en caché por un tiempo limitado

Los resolvedores y dispositivos guardan las respuestas en una caché. El tiempo de vida (TTL) de un registro establece cuánto tiempo puede reutilizarse una respuesta en caché. Un TTL de 3600 segundos permite reutilizarla durante una hora. Así, la mayoría de las consultas evitan un nuevo recorrido por la jerarquía.

Si cambia un registro de dirección, una caché existente puede seguir proporcionando la respuesta antigua hasta que caduque esa entrada. Esta visibilidad tardía suele llamarse «propagación DNS». No significa que el servidor autoritativo esté enviando lentamente el cambio a cada computadora. El TTL del DNS es una duración en segundos; el TTL de IP limita los saltos.

Elige el tipo de registro

Un nombre puede devolver varias direcciones y varios nombres pueden compartir una dirección. Una consulta MX encuentra servidores de correo, no el dispositivo personal del destinatario.

El DNS clásico suele usar el puerto UDP 53 para intercambios breves y también admite TCP, entre otros casos para respuestas más grandes. Las consultas clásicas no están cifradas. DNS sobre HTTPS protege la consulta en tránsito hasta el resolvedor; este sigue procesándola. DNSSEC comprueba la autenticidad de los datos DNS firmados. La autenticidad y la confidencialidad resuelven problemas diferentes: una respuesta firmada puede seguir siendo legible en el camino.

Un protocolo especifica los formatos y el orden de los mensajes, y qué hacen los participantes cuando los envían o reciben. Internet reparte estas tareas entre capas, de modo que una aplicación pueda funcionar sobre muchos tipos de red.

Asigna una tarea a cada capa

La descripción de cinco capas separa las necesidades de las aplicaciones de las señales físicas que transportan los bits.

El protocolo de transferencia de hipertexto (HTTP) define las solicitudes y respuestas web. Puede usar TCP sin necesitar saber si el siguiente enlace es Wi-Fi o fibra. Sustituir ese enlace puede dejar la aplicación web sin cambios. La descripción TCP/IP de cuatro capas agrupa enlace y física. El modelo de referencia OSI usa siete capas; es otra forma de describir las responsabilidades de comunicación en red.

Envuelve los datos para entregarlos

La encapsulación añade información a medida que los datos bajan por la pila. TCP trata los bytes de la aplicación como un flujo y los divide en segmentos, cada uno con una cabecera TCP. IP envuelve un segmento en un paquete IP. Ethernet o Wi-Fi envuelve el paquete en una trama para un enlace. Ethernet también añade un campo final de comprobación de errores.

En el destino, la desencapsulación deshace las envolturas. Cada capa lee su propia información y pasa el contenido restante a la superior. Una capa superior se comunica con su equivalente mediante estos servicios de las capas inferiores; las capas no son una fila de máquinas separadas entre el emisor y el receptor.

Un mensaje HTTP puede abarcar varios segmentos TCP, y un segmento puede incluir bytes de más de un mensaje. Los límites de TCP proceden del transporte de un flujo de bytes, no de los límites de los mensajes de la aplicación.

Cuenta los bytes añadidos

Supón que un segmento transporta 1460 bytes de datos web. Una cabecera TCP de 20 bytes y una cabecera IPv4 de 20 bytes dan:

Ethernet añade una cabecera de 14 bytes y un campo final de 4 bytes, lo que forma una trama de 1518 bytes. Sus 58 bytes de cabeceras y campo final representan aproximadamente el 3,8 % de la trama. Estas cantidades corresponden a las cabeceras indicadas; los campos opcionales pueden alargar las cabeceras TCP e IP.

¿Qué cambia en un enrutador?

Un equipo anfitrión ejecuta toda la pila. Un enrutador suele gestionar funciones físicas, de enlace y de red. Elimina la trama entrante, lee el destino IP, elige un enlace de salida y crea una trama nueva para ese enlace. Un conmutador local suele trabajar en la capa de enlace.

Las tramas cambian salto a salto. Las direcciones IP de extremo a extremo permanecen iguales en una ruta ordinaria, salvo donde NAT las reescribe; otros campos IP, incluido el límite de saltos, pueden cambiar. El procesamiento TCP corresponde a los extremos.

Muchas aplicaciones por encima y muchas tecnologías de enlace por debajo comparten IP. Esta es la cintura estrecha de Internet: una aplicación nueva no necesita rediseñar el núcleo de la red. El Grupo de Trabajo de Ingeniería de Internet (IETF) publica documentos de protocolo abiertos llamados peticiones de comentarios (RFC). La especificación de TCP es la RFC 9293, publicada en 2022.

Un archivo necesita todos sus bytes en el orden correcto, incluso cuando la red descarta paquetes o cambia su orden. El protocolo de control de transmisión (TCP) proporciona ese flujo ordenado de bytes mediante la cooperación de los dos equipos de los extremos.

Identifica los programas y abre una conexión

Una dirección IP identifica una interfaz de red. Un puerto identifica un servicio o un extremo de comunicación en ese equipo. Los puertos son números de 16 bits entre 0 y 65 535. HTTP suele usar el puerto 80; HTTPS, el 443; y DNS, el 53. Un cliente normalmente elige un puerto de origen temporal.

Una conexión TCP se distingue por ambas direcciones IP y ambos puertos. Por ejemplo, 198.51.100.23:51514 puede conectarse a 203.0.113.80:443 mientras otra conexión usa un puerto de cliente diferente. Esto permite que una computadora portátil mantenga muchas comunicaciones a la vez.

TCP comienza con un establecimiento de conexión en tres pasos:

1. El cliente envía SYN, iniciando su numeración de secuencia.
2. El servidor devuelve SYN-ACK, confirmando ese inicio y proporcionando el suyo.
3. El cliente envía ACK.

El establecimiento ordinario añade aproximadamente un RTT antes de que puedan comenzar los datos. Más adelante, cada extremo puede cerrar su sentido de envío con FIN.

Numera los bytes y encuentra un hueco

Los números de secuencia de TCP cuentan bytes, no paquetes. Usa una numeración desde 1 para facilitar la lectura del ejemplo; las conexiones reales comienzan con números de secuencia iniciales elegidos.

Si llegan los tres, el acuse de recibo 3001 significa que han llegado todos los bytes hasta el 3000 y que el siguiente es el 3001.

Si falta el segundo segmento, el receptor sigue enviando acuses de recibo con el número 1001 incluso después de que llegue el tercero. Puede conservar los bytes posteriores, pero aún no puede entregarlos como un flujo continuo. Un tiempo de espera agotado o varios acuses de recibo duplicados hacen que el emisor retransmita los bytes que faltan. Una vez completado el hueco, el receptor puede avanzar su acuse de recibo y entregar los datos en orden.

Una suma de comprobación detecta la mayoría de los segmentos dañados. Los datos dañados se descartan y se recuperan mediante retransmisión, igual que los datos perdidos.

Protege al receptor y a la red

Dos controles limitan la cantidad de datos que un emisor mantiene pendientes de confirmación:

La ventana de recepción impide que un emisor rápido desborde a un receptor lento. El control de congestión responde a un camino ocupado, incluidas las pérdidas y el aumento del retardo, y permite después un crecimiento gradual cuando mejoran las condiciones. Un receptor rápido puede seguir estando al otro lado de una red congestionada.

Comprende el coste

Los enrutadores reenvían paquetes IP; no reparan cada flujo TCP. La recuperación en los extremos permite que se pierdan paquetes mientras la aplicación sigue recibiendo bytes correctos. Esperar un segmento perdido puede retrasar los bytes posteriores. Si el camino sigue interrumpido, TCP acaba informando de un fallo. TCP tampoco proporciona cifrado: TLS añade esa protección al tráfico web seguro.

Un archivo completo y el audio en directo tienen necesidades de entrega diferentes. Antes de elegir un transporte, compara qué se conseguiría esperando un fragmento perdido.

Compara TCP y UDP

La cabecera de 8 bytes de UDP transporta puertos, una longitud y una suma de comprobación. No confirma, retransmite ni reordena datagramas. «No fiable» significa que no hay garantía de entrega; la mayoría de los datagramas pueden llegar correctamente en una red que funciona bien.

Pregúntate si los datos tardíos son útiles

La descarga de un extracto bancario necesita todos los bytes, así que merece la pena esperar la retransmisión. TCP también resulta adecuado para el correo electrónico, las actualizaciones de software y las transferencias HTTP/1.1 o HTTP/2. Su coste incluye el establecimiento y la espera detrás de un hueco en el flujo ordenado.

En el audio en directo, un fragmento que llega 200 ms tarde puede superar su plazo de reproducción. Saltarse un pequeño hueco puede interrumpir menos que pausar la conversación. Las llamadas y los juegos rápidos suelen usar transporte basado en UDP para que sus aplicaciones decidan qué recuperar y qué omitir.

El DNS suele usar UDP para un intercambio breve de pregunta y respuesta. Es una infraestructura esencial, por lo que la importancia es un mal criterio de selección. Lo que importa es la entrega completa, los plazos y qué protocolo gestiona la recuperación.

Añade fiabilidad sobre UDP

QUIC funciona sobre UDP y añade flujos fiables, control de congestión y cifrado integrado. HTTP/3 usa QUIC para entregar recursos web de forma fiable. Otro protocolo situado por encima proporciona el servicio que falta en UDP.

QUIC también combina el establecimiento seguro con más eficiencia que abrir TCP y negociar después TLS por separado. Por tanto, un navegador que usa HTTP/3 dispone de servicios de recuperación y seguridad aunque su transporte UDP subyacente no los proporcione.

Internet transporta paquetes entre redes. La web es una aplicación que funciona sobre ella: recursos enlazados que se solicitan mediante HTTP. El correo electrónico, las llamadas y los juegos también usan Internet.

Cómo comenzó la web

Tim Berners-Lee propuso la web en el CERN en marzo de 1989. El primer sitio, info.cern.ch, funcionaba en su computadora. El CERN puso el software de la web en el dominio público el 30 de abril de 1993. La red de investigación que dio lugar a Internet había comenzado en 1969.

Tres ideas trabajan juntas: los localizadores uniformes de recursos (URL) identifican recursos; el protocolo de transferencia de hipertexto (HTTP) los solicita y entrega; el lenguaje de marcado de hipertexto (HTML) describe documentos con hipervínculos. Los navegadores muestran HTML, usan CSS para la apariencia y ejecutan JavaScript para la interacción.

Lee una URL

Considera https://www.example.com:443/docs/guide.html?lang=en#intro.

El DNS solo resuelve el nombre del equipo anfitrión. La solicitud HTTP transporta la ruta y la cadena de consulta; el navegador conserva el fragmento para gestionarlo localmente, por ejemplo para localizar una sección de la página.

Solicita un servicio

Un navegador actúa como cliente, solicitando recursos a un programa servidor. Un nombre de equipo anfitrión puede conducir a muchos servidores físicos que sostienen un sitio popular.

Otras aplicaciones también pueden usar HTTP. Una aplicación del tiempo llama a una interfaz de programación de aplicaciones (API) web para obtener datos estructurados, a menudo en notación de objetos de JavaScript (JSON). Presenta esos datos en su propia interfaz en lugar de mostrar HTML.

Reutiliza copias cercanas

Una red de distribución de contenidos (CDN) guarda copias de recursos en varios lugares. El DNS o el enrutamiento dirige a los usuarios a servidores adecuados, a menudo cercanos, lo que reduce la latencia y reparte la carga.

Una caché del navegador almacena recursos descargados previamente en el dispositivo del usuario. Reutilizar una imagen válida en caché puede evitar obtenerla de nuevo. Si se necesita una descarga nueva, una copia cercana en una CDN puede acortar el recorrido. Las dos cachés ahorran trabajo en lugares diferentes: una en el dispositivo y la otra en servidores de red.

HTTP define un intercambio entre un cliente y un servidor. Una solicitud indica qué quiere el cliente; una respuesta informa del resultado y puede transportar un recurso. Una sola página suele necesitar muchos intercambios de este tipo.

Lee una solicitud

Una solicitud HTTP/1.1 puede comenzar así:

GET /docs/guide.html HTTP/1.1
Host: www.example.com

La línea inicial contiene el método, la ruta y la versión. GET solicita un recurso. La cabecera Host selecciona el sitio, ya que varios nombres de equipo anfitrión pueden compartir una dirección de servidor. Las cabeceras usan líneas name: value para proporcionar información adicional; un cuerpo opcional transporta los datos enviados.

GET está pensado para recuperar información sin cambiar el estado del servidor. POST envía datos en un cuerpo, como un formulario o un archivo. PUT puede guardar o sustituir un recurso, y DELETE solicita su eliminación.

Lee una respuesta

Una respuesta satisfactoria puede comenzar con:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 5120

Después de las cabeceras y una línea en blanco viene el cuerpo. Content-Type describe cómo interpretarlo; aquí es HTML. Content-Length indica una longitud del cuerpo de 5120 bytes. Una respuesta de imagen podría usar image/png, mientras que una API podría devolver JSON.

HTTP/2 y HTTP/3 transportan esta información en tramas binarias en lugar del formato textual de HTTP/1.1. Los métodos, códigos de estado, cabeceras y cuerpos conservan sus significados.

Interpreta el resultado

Una respuesta 301 proporciona una URL nueva en Location. Un 304 indica que una copia en caché validada sigue vigente. Un 404 significa que el servidor respondió, pero no encontró un recurso en la ruta solicitada. Un fallo del DNS o un servidor inaccesible no producen un estado HTTP, porque no llega ninguna respuesta HTTP.

Da continuidad a las solicitudes repetidas

HTTP es sin estado: el protocolo no vincula automáticamente una solicitud con las anteriores. Un servidor puede enviar Set-Cookie con un identificador de sesión. Después, el navegador incluye una cabecera Cookie en las solicitudes a las que se aplica esa cookie. El servidor usa el identificador para encontrar información de sesión almacenada, como un inicio de sesión o un carrito. Las cookies también permiten el rastreo, que los ajustes del navegador y las normas de privacidad restringen.

Obtener HTML no equivale a obtener un sitio web completo. El navegador lee el HTML y solicita las imágenes, estilos, programas y fuentes que referencia. HTTP/1.1 puede reutilizar una conexión TCP para solicitudes sucesivas. HTTP/2 transporta varios intercambios por una conexión TCP; HTTP/3 lo hace sobre QUIC. La pestaña Red de un navegador muestra estas solicitudes individuales, sus estados y sus tiempos.

Introducir una URL HTTPS inicia una secuencia de protocolos que cooperan. HTTPS significa HTTP protegido por seguridad de la capa de transporte (TLS). Para seguir la secuencia, distingue entre encontrar un servidor, conectarte a él, proteger el intercambio y solicitar contenido.

Sigue una conexión nueva

Para una conexión HTTPS nueva que use HTTP/1.1 o HTTP/2:

1. El navegador comprueba las cachés y, si hace falta, pide al DNS la dirección IP del equipo anfitrión.
2. Abre una conexión TCP al puerto 443 mediante el establecimiento en tres pasos.
3. Una negociación TLS comprueba el servidor y establece las claves de cifrado.
4. El navegador envía un GET HTTP por la conexión protegida.
5. El servidor devuelve una respuesta, normalmente con HTML.
6. El navegador solicita los recursos referenciados y dibuja la página.

Todos los intercambios de red viajan en paquetes IP. HTTP/3 usa QUIC sobre UDP con TLS integrado, por lo que no realiza el establecimiento TCP separado de esta secuencia. Las respuestas en caché y las conexiones reutilizadas también pueden evitar trabajo.

Si el DNS, el establecimiento de TCP, el de TLS y el primer intercambio HTTP requieren cada uno una ida y vuelta de 60 ms, el total antes de que empiece a llegar contenido es aproximadamente:

Ese ejemplo omite el procesamiento del servidor y otros retardos. Una tasa de datos mayor no puede eliminar esas cuatro esperas indicadas, aunque evitar una consulta o reutilizar una conexión puede eliminar un intercambio.

Qué comprueba TLS

TLS proporciona cifrado, que oculta el contenido a quienes observan el camino; integridad, que detecta cambios realizados en tránsito; y autenticación, que verifica el servidor para el nombre solicitado.

Un certificado digital vincula un nombre de dominio con una clave pública. Lo firma una autoridad de certificación (CA) de confianza. El navegador comprueba el nombre, el periodo de validez y la cadena de confianza, y el servidor demuestra que posee la clave privada correspondiente. Un certificado copiado por sí solo no aporta esa prueba, porque los certificados son públicos.

Un nombre que no coincide, un certificado caducado o un firmante no fiable pueden generar una advertencia del navegador. No omitas una advertencia de certificado: hacerlo elimina la protección frente a un servidor suplantador.

Protección de la conexión y confianza en el sitio

HTTPS protege en tránsito el contenido de las páginas, las rutas y cadenas de consulta de las URL, las cookies, las contraseñas y los formularios enviados. Sigue exponiendo la dirección IP del servidor y el volumen y los tiempos del tráfico. El nombre de dominio también sigue siendo visible en muchas conexiones, según la protección del DNS y de la negociación.

Un indicador de conexión segura informa de que la conexión está protegida para ese dominio. Un sitio deshonesto puede obtener un certificado válido para su propio nombre. Comprueba que el dominio sea el que pretendías visitar; un certificado ordinario verifica el control del dominio, no la honradez de cada página. HTTP sin cifrar, normalmente en el puerto 80, deja el intercambio de la aplicación legible y expuesto a modificaciones a lo largo del camino.

Localiza la etapa que ha fallado

«Servidor no encontrado» puede indicar un problema de DNS. Un tiempo de espera agotado puede significar que los paquetes no llegan o que un servidor no responde. Una advertencia de certificado apunta a TLS. Un 404 o 500 significa que llegó una respuesta HTTP: el fallo se refiere entonces al recurso solicitado o al procesamiento del servidor. Estas pistas acotan el problema sin tratar cada página que falla como una pérdida de conexión a Internet.

Las aplicaciones comparten la red de paquetes, pero organizan sus intercambios de forma diferente. El correo puede esperar en servidores a que un lector se conecte. Una llamada necesita audio que llegue a tiempo. Un reproductor de vídeo puede llenar un búfer y elegir una tasa de datos menor.

Sigue un correo electrónico

El protocolo simple de transferencia de correo (SMTP) envía correo de una aplicación a un servidor de correo y entre servidores de correo. El protocolo de acceso a mensajes de Internet (IMAP) permite al lector trabajar con el correo almacenado en el servidor y sincronizar varios dispositivos. El protocolo de oficina de correo, versión 3 (POP3) suele descargar el correo en un dispositivo.

Cuando amira@example.org envía un correo a ben@example.net:

1. La aplicación de Amira entrega el mensaje a su servidor de salida mediante SMTP.
2. Ese servidor pide al DNS los registros MX de example.net.
3. Envía el mensaje mediante SMTP a un servidor receptor indicado en esos registros.
4. El mensaje espera en el buzón de Ben.
5. La aplicación de Ben accede a él mediante IMAP.

La parte ben identifica un buzón; example.net identifica su dominio. Varias entradas MX con valores de preferencia pueden ofrecer servidores receptores alternativos. El remitente y el lector no necesitan estar conectados a la vez. Con el correo web, el navegador usa HTTPS para comunicarse con el proveedor, mientras los proveedores siguen intercambiando correo mediante SMTP.

El diseño original de SMTP no verificaba las identidades que declaraban los remitentes. El marco de políticas del remitente (SPF), el correo identificado mediante claves de dominio (DKIM) y la autenticación, informes y conformidad de mensajes basados en dominios (DMARC) ayudan a los servidores receptores a comprobar la autorización y autenticidad relacionadas con el dominio. Superar estas comprobaciones no hace que todos los mensajes sean deseados u honrados.

Mensajería y pares

Muchas aplicaciones de mensajería usan los servidores de un proveedor para retransmitir mensajes y guardarlos para destinatarios desconectados. Con el cifrado de extremo a extremo, los extremos previstos poseen las claves del contenido. Un servidor de retransmisión puede transmitir contenido cifrado sin leerlo. Esto difiere de cifrar solo la conexión con el proveedor, en cuyo caso este aún puede procesar el contenido sin cifrar.

En la comunicación entre pares (P2P), los equipos anfitriones asumen tanto el papel de cliente como el de servidor. Un par de BitTorrent descarga fragmentos de archivos de otros pares mientras sube los que ya tiene. Más pares pueden añadir capacidad de subida. Las videollamadas pueden enviar contenido multimedia directamente entre dispositivos, pero NAT puede hacer necesario un servidor de retransmisión. Usar un servidor de retransmisión para una llamada no convierte todas las demás aplicaciones de Internet en P2P.

Adapta una transmisión de vídeo

Los servicios de transmisión ofrecen fragmentos cortos de vídeo en varios niveles de calidad. El reproductor mide la tasa de transferencia efectiva y solicita por HTTP una versión adecuada de cada fragmento siguiente. Puede reducir la calidad cuando baja la capacidad disponible, lo que disminuye el riesgo de que se vacíe el búfer de reproducción.

A una tasa constante de 5 Mbit/s, una hora consume:

Divide entre 8 para convertir a bytes: 2 250 000 000 bytes, o 2,25 GB. Esto cuenta los datos de la transmisión indicada; el tráfico adicional de los protocolos puede aumentar el consumo. Multiplicar megabits por segundos da megabits, por lo que un resultado expresado en MB o GB aún necesita la conversión de bits a bytes.

Organizaciones independientes operan las redes de Internet. Necesitan identificadores comunes y estándares técnicos compartidos para intercambiar tráfico. La gobernanza coordina estos recursos compartidos y las políticas que afectan a su uso.

Coordina los identificadores

Los bloques de direcciones IP públicas y los registros de dominios necesitan asignaciones coordinadas. Las asignaciones públicas en conflicto harían ambigua la entrega. Los rangos de IP privadas son deliberadamente reutilizables porque se mantienen dentro de redes privadas separadas.

La Corporación de Internet para la Asignación de Nombres y Números (ICANN) es una entidad sin ánimo de lucro fundada en 1998 y con sede en Estados Unidos. Coordina las políticas del nivel superior del DNS, incluidos los dominios genéricos de nivel superior y la acreditación de registradores. Su entidad afiliada Public Technical Identifiers (PTI) realiza las funciones de la Autoridad de Números Asignados de Internet (IANA): mantener la zona raíz del DNS, las reservas centrales de direcciones y números de AS, y los registros de parámetros de protocolo, como los puertos.

La supervisión contractual del gobierno de Estados Unidos sobre las funciones de la IANA terminó el 1 de octubre de 2016. La transición de la custodia trasladó la supervisión a las comunidades mundiales que usan esas funciones, mediante los procesos correspondientes.

Distingue los nombres de los números

Cinco registros regionales de Internet (RIR) distribuyen direcciones IP y números de sistemas autónomos a proveedores y organizaciones:

Los dominios siguen una cadena diferente. Un operador de registro de dominios gestiona un TLD; Verisign gestiona .com. Un registrador vende registros de dominios y un titular de un dominio mantiene un registro durante un periodo, que suele renovarse cada año. Los dominios de código de país, como .jp y .br, tienen sus propios operadores y normas nacionales. Los RIR no registran nombres de dominio.

Redacta estándares y opera redes

El Grupo de Trabajo de Ingeniería de Internet (IETF) desarrolla protocolos como IP, TCP, DNS, HTTP y TLS mediante un trabajo abierto publicado como RFC. Valora el consenso aproximado y las implementaciones que funcionan. Cualquiera puede participar.

El Consorcio World Wide Web (W3C), fundado por Tim Berners-Lee en 1994, desarrolla estándares web como CSS y las Pautas de Accesibilidad para el Contenido Web (WCAG). WHATWG mantiene HTML. Internet Society (ISOC) apoya al IETF y promueve una Internet abierta.

Los operadores eligen conexiones, establecen acuerdos de tránsito y anuncian rutas mediante BGP. Doce organizaciones operan el servicio raíz del DNS. Los gobiernos establecen leyes territoriales sobre telecomunicaciones, competencia, privacidad y contenido. La Unión Internacional de Telecomunicaciones (UIT) coordina internacionalmente el trabajo de telecomunicaciones y el espectro radioeléctrico; no registra dominios ni asigna bloques de direcciones de Internet.

Incluye varios tipos de participantes

Un modelo de múltiples partes interesadas incluye a gobiernos, empresas, sociedad civil, comunidad técnica y personal académico. El Foro para la Gobernanza de Internet (IGF) facilita el debate entre estos grupos; no emite decisiones vinculantes. Celebrado por primera vez en 2006, se convirtió en un foro permanente de la ONU en diciembre de 2025. La coordinación mediante estos organismos proporciona reglas compartidas a la red sin crear una organización que posea todos los enlaces o controle todos los servicios.

Las decisiones sobre políticas de Internet afectan de forma diferente a usuarios, operadores de redes, servicios en línea y gobiernos. Un argumento útil identifica quién toma la decisión, sigue sus efectos y sopesa un beneficio frente a un coste.

Trato igualitario y tarifa cero

La neutralidad de la red es el principio de que los ISP deben tratar por igual el tráfico lícito, sin favorecer servicios concretos mediante bloqueos, ralentizaciones o cargos especiales. Sus defensores vinculan el trato igualitario con la competencia y la libertad de expresión: un servicio nuevo no debería necesitar un acuerdo favorable con cada ISP. Sus detractores defienden la flexibilidad en la gestión de redes y las ofertas de servicios, y advierten de que unas normas estrictas pueden desincentivar la inversión. Las normas nacionales difieren y pueden cambiar.

Supón que un operador móvil aplica tarifa cero a una aplicación de vídeo: verla no consume el límite de datos. Los usuarios de esa aplicación ganan datos utilizables. La aplicación favorecida obtiene una ventaja frente a sus rivales, cuyo tráfico sigue contando. El operador puede promocionar la oferta y obtener beneficios comerciales. Un regulador debe sopesar la asequibilidad frente a la competencia justa. Decir solo que «los datos gratis son buenos» omite el efecto sobre los servicios competidores; decir solo que «la oferta es injusta» omite el beneficio inmediato del usuario.

Concentración y control gubernamental

Unas pocas grandes empresas de servicios en la nube y distribución de contenidos pueden atender eficientemente a enormes cantidades de sitios. También pueden crear dependencias compartidas: una interrupción de un proveedor puede afectar a muchos servicios que, por lo demás, no guardan relación entre sí. Por tanto, la concentración plantea cuestiones tanto de eficiencia como de resistencia a fallos.

Los gobiernos pueden filtrar sitios, exigir que los datos se almacenen en el país o cortar el acceso. Sus defensores pueden alegar seguridad y orden público; sus críticos señalan la libertad de expresión, los medios de vida, la educación y los daños a usuarios ajenos a un incidente. La fragmentación de Internet, a veces llamada «Internet fragmentada», describe el riesgo de redes nacionales cada vez más separadas.

Direcciones escasas y datos protegidos

La reserva central de IPv4 está agotada. Las transferencias de bloques existentes y el uso extendido de NAT mantienen IPv4 utilizable, mientras IPv6 ofrece un espacio de direcciones mucho mayor. La transición lleva tiempo porque los equipos y servicios deben seguir funcionando juntos durante la coexistencia.

El cifrado protege la información privada frente a la interceptación y la vigilancia. Algunos organismos encargados de hacer cumplir la ley buscan acceso especial a los datos cifrados. Muchos especialistas en seguridad sostienen que integrar ese acceso también crea debilidades que otros podrían explotar. Evaluar la propuesta exige considerar tanto las necesidades de investigación como la seguridad de los usuarios comunes. Las normas de protección de datos varían entre países.

El acceso es más que cobertura

La UIT estimó que unos 6 mil millones de personas estaban conectadas en 2025 y 2,2 mil millones no lo estaban, con gran parte de la brecha en países de menores ingresos y zonas rurales. La asequibilidad, la infraestructura y un acceso utilizable determinan quién se beneficia de los servicios en línea. Que una red llegue a un pueblo no ayuda a todos por igual si su precio sigue fuera de su alcance.

Relaciona cada propuesta con el actor responsable. Los operadores de registro e ICANN coordinan los nombres; los RIR coordinan las direcciones; los organismos de normalización desarrollan reglas técnicas; los operadores eligen las conexiones y los servicios de red; los gobiernos elaboran las leyes. Una política de registro de dominios, el diseño de un protocolo y una restricción nacional de acceso pueden interactuar y seguir siendo tipos de decisión diferentes.