A donde van realmente los milisegundos

La latencia no es un solo numero sino una suma de cuatro retardos distintos, y se comportan de manera completamente diferente. El retardo de propagacion es el tiempo que la senal necesita para cubrir la distancia, fijado por la velocidad de la luz en el medio. El retardo de transmision es el tiempo de empujar todos los bits de un paquete hacia el enlace, fijado por la tasa del enlace y el tamano del paquete. El retardo de cola es el tiempo que un paquete espera en un bufer detras de otros paquetes, fijado por lo ocupada que este la red en ese momento. El retardo de procesamiento es el tiempo minimo que un enrutador dedica a mirar una cabecera y elegir una salida. Solo dos de los cuatro responden al dinero de forma obvia, y el mas grande no responde en absoluto.

London to New York        5 550 km    one way
speed in fibre           200 000 km/s
one way delay            27.8 ms
minimum round trip       55.5 msEl mismo calculo para cualquier par de ciudades: distancia, distancia, distancia.

La luz en el vacio viaja a 300 000 km por segundo. En la fibra optica el nucleo tiene un indice de refraccion cercano a 1.47, asi que la senal avanza a unos 200 000 km por segundo, mas o menos dos tercios de aquella cifra. Esto no es una limitacion del equipo. Es una propiedad del vidrio, y ninguna cantidad de ingenieria la elimina. Cada kilometro cuesta por lo tanto unos 0.005 ms en un sentido, y como una conversacion necesita una respuesta, cuesta unos 0.01 ms por kilometro de ida y vuelta. Ese numero es el piso por debajo de todo diseno de red en el mundo.

El retardo de transmision depende de cuantos bits estas enviando y de lo rapido que sea el enlace, y de nada mas. Una trama Ethernet de tamano maximo tiene 1500 bytes, es decir 12 000 bits. En un enlace de 1 Gbit/s tarda 0.012 ms en colocarse en el cable, y en un enlace de 100 Mbit/s exactamente diez veces mas. Fijate en lo que esto significa: para un solo paquete pequeno la tasa del enlace es casi irrelevante frente a un cruce de oceano de 50 ms. El ancho de banda decide cuanto tarda una transferencia grande; no decide cuanto tarda una sola peticion.

1500 bytes = 12 000 bits

1 Gbit/s    serialisation  0.012 ms
100 Mbit/s  serialisation  0.120 msDoce mil bits, dos enlaces muy distintos.

Los enrutadores no atraviesan los paquetes. Un enrutador tiene que recibir el paquete completo, verificarlo, decidir a donde va y solo entonces empezar a transmitirlo por el siguiente enlace. Asi que el tiempo total es una suma sobre los saltos, no un maximo, y cada salto aporta tanto su propio retardo de transmision como su propio procesamiento. En una ruta de veinte saltos eso son veinte sumas pequenas, y por eso una red local rapida igual pierde decenas de milisegundos a lo largo de una ruta larga.

La cola es el unico de los cuatro retardos que es realmente impredecible, y es la razon de que dos peticiones identicas puedan tardar tiempos muy distintos. Cuando un enlace esta casi ocioso, un paquete no espera nada. Cuando el enlace esta cargado, los paquetes se alinean en un bufer, y esa espera puede ser de microsegundos o de cientos de milisegundos segun el trafico que tu no controlas. Cuando el bufer se desborda, los paquetes se descartan, lo que para TCP significa retransmision, lo que significa al menos una ida y vuelta adicional. Esta es tambien la razon de que un enlace pueda parecer rapido en una prueba a las 3 de la manana y lento durante una videollamada a las 8 de la noche.

Lo que los usuarios perciben son las idas y vueltas, no el retardo en un sentido, porque casi todos los protocolos son una conversacion. Una consulta DNS es una ida y vuelta, abrir una conexion TCP es otra, un handshake TLS sobre una conexion nueva es una o dos mas, y solo entonces viaja la peticion de la pagina. Abrir una pagina con una conexion en frio paga por lo tanto tres o cuatro idas y vueltas antes de que llegue el primer byte util, y cada una de ellas cuesta la distancia completa hasta el servidor y de regreso.

$ curl -w "dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n" -o /dev/null -s https://example.org
dns 0.004 connect 0.058 tls 0.117 total 0.171

$ curl -o /dev/null -s -w "total %{time_total}\n" https://example.org
$ curl -o /dev/null -s -w "total %{time_total}\n" https://example.org
total 0.171
total 0.062Medir las fases de una peticion real y luego medirla otra vez sobre una conexion reutilizada.

Por eso la reutilizacion de conexiones no es una optimizacion sino el asunto principal. Mantener una conexion abierta permite al cliente saltarse por completo los handshakes de TCP y TLS en la siguiente peticion, y convierte una carga de pagina de 170 ms en una de 60 ms al otro lado del oceano. Tambien es la razon de que HTTPS cueste mas que HTTP en una conexion en frio y casi nada en una conexion caliente, y de que un servidor que cierra las conexiones inactivas con demasiada prisa haga que todo se sienta mas lento.

La unica respuesta real al retardo de propagacion es acortar la distancia. Una CDN mantiene copias del contenido en muchas ubicaciones y responde a cada usuario desde la mas cercana, de modo que una peticion que antes cruzaba un oceano ahora cruza una ciudad. No puede ayudar con datos dinamicos que deben generarse en un lugar especifico, y no puede hacer rapida la primera conexion a una cache en frio. Lo que hace es convertir un problema de fisica en un problema de logistica, y la logistica si se puede resolver.