Google propone modificar la configuración de uno de los principales protocolos sobre el que se sustenta Internet, para adaptarlo a la velocidad de las conexiones de banda ancha actuales. Se trata de un cambio simple, sin ningún coste y que en las pruebas realizadas mejora hasta un 12% la velocidad de navegación en la web.
Uno de los objetivos prioritarios de Google en la actualidad es, además de su cada vez mayor número de servicios, que Internet mejore en cuanto a su rendimiento. La propuesta que van a llevar al organismo estandarizador IETF (Internet Engineering Task Force) es una investigación que gira entorno a ampliar la ventana de congestión inicial al empezar una comunicación empleando el protocolo TCP, con vistas a incrementar la velocidad de navegación al conseguir una rebaja de la latencia.
Pero para entender un poco esto, quizás sea necesario definir muy brevemente, y sin intentar entrar en muchos tecnicismos, qué es esta ventana y para qué sirve.
La ventana TCP
Cuando se establece una conexión entre dos puntos de la red, ambos extremos se comunican la cantidad de datos que pueden enviar y recibir a la vez. Este valor, denominado ventana TCP, es inicialmente de unos 4 KB y va aumentando exponencialmente a medida que transcurre la trasmisión, hasta que una de las partes se congestiona. Cada vez que un extremo recibe una cantidad de información igual al tamaño de la ventana, envía un paquete ACK a la otro para acusar recibo. La otra parte dejará de enviar nuevos datos hasta que no reciba esta confirmación. Pasado un tiempo, si no recibe el paquete ACK, reenviará los datos al entender que se han perdido.
Aumentando el tamaño de la ventana a 15 KB
Actualmente esta ventana se inicializa típicamente en unos 4 KB aproximadamente, y Google quiere elevar esta cifra hasta los 15 KB.
Al incrementar el tamaño mínimo de datos esperados, la comunicación puede ser más rápida ya que, imaginad este supuesto: tenemos que descargar un fichero de 10 KB. Actualmente, al inicializar en 4 KB esta ventana, se enviarían primeramente 4 KB, el receptor tendría que notificar que no ha habido errores, para que luego, con la ventana ya por ejemplo multiplicada por 2 (8 KB), cabrían perfectamente los 6 KB restantes de datos, que volverán a ser notificados para luego finalizar la conexión.
Con un tamaño de ventana de 15 KB como el propuesto por Google, únicamente habría hecho falta un ciclo, ya que todos los datos se habrían enviado en primera instancia.
384 KB, el tamaño medio de una página web
Actualmente el tamaño medio de una página web es de 384 KB, pero se compone por varios elementos (texto, imágenes...), requiriendo normalmente una conexión por cada uno de estos elementos, que individualmente en el 90% de los casos no llegan a estos 15 KB. Lo que hacen los navegadores es enviar varias peticiones en paralelo al servidor para evitar el problema de este "arranque lento", aunque no es eficiente.
Google ha simulado este cambio empleando sus servidores de búsqueda, o para los servicios Maps o iGoogle, en dos contextos distintos. Uno estaba basado en una velocidad de conexión media de 1,2 Mbps y con una presencia testimonial de velocidades por debajo de 256 kbps, que define bastante bien las conexiones fijas. Otro escenario era con un 20% de conexiones por debajo de los 100 kbps y una media de 500 kbps, más adecuado a entornos móviles.
Los resultados arrojan, como principal ventaja, repercusiones positivas en la latencia de las conexiones TCP, mejorando en ambos supuestos de velocidad, aunque algo más en las conexiones más rápidas (11,7% de media contra un 8,7%). Como se ve en la gráfica, el menor valor de latencia se conseguía para una ventana igual a 16 paquetes Ethernet (1500 Bytes cada uno), aunque el que mejor se comportaba en otras pruebas era el de diez paquetes (los ya mencionados 15 KB).
El único punto negativo de este cambio propuesto por el gigante de Internet es el incremento del número de retransmisiones necesarias porque se hayan producido fallos en las comunicaciones, aunque no parece nada preocupante, ya que en un supuesto de conexiones rápidas de los clientes empeora una media de un 0,02% y en conexiones lentas un 0,17%.
Páginas más rápidas
En definitiva, Google espera que este cambio pueda llegar a ser debatido en el IETF pues han comprobado que aumentando el volumen inicial de datos en las conexiones TCP mejora principalmente la latencia de la navegación web sin apenas contrapartidas, lo que significa que las páginas cargarían más rápido.
De este modo, el protocolo se pondría al día respecto a las velocidades actuales que podemos conseguir de conexión a Internet, pero lo mejor que tiene esta modificación respecto a otras propuestas presentadas por otras empresas buscando el mismo objetivo, es que es mucho más simple y barato de implementar, ya que la esencia de la norma original se mantiene, alterando únicamente un parámetro.
Ya hablando de futuro, el objetivo a largo plazo de Google sería eliminar este valor inicial de la ventana para servir a conexiones más rápidas y a páginas web más "pesadas".
Si queréis leer más detenidamente el paper de Google, seguid este enlace [en inglés].
